1) Make it difficult for bad guys to move around inside your network.
This includes employing strict and disciplined use of access controls to manage where each employee can go in the network. That way if some assistant's account gets compromised, the bad guy can't just log into the email server or file share root.
It also includes keeping every machine's software patched and up to date. That makes it more difficult for bad guys to use known exploits to escalate privileges within the network.
It also includes enforcing strong password policies--and giving every employee a secure password management solution. (So they don't use Excel.)
2) Keep an eye on the internal network.
Network admins and security folks can use software tools (example: Netwitness) to know what traffic typically looks like on the network, and to detect anomalies. For example, if a lot of data starts flowing from a file share to a computer that typically does not access that share. Or if a lot of data starts heading out of the firewall to an address that no one has ever connected to before. Or if a VPN account authenticates at a weird hour or from a new address.
For example, at my employer, if I VPN in after about 10pm, I get an email or phone call from Net Sec asking if that is really me. If I connect to IRC from within the LAN--same thing. Any file transfer larger than a certain size gets flagged for follow up. Etc.
Along these lines, overlay VPNs can be used behind the firewall to segment the internal network, e.g. to isolate developers -- finance -- task workers. This limits the scope of any breach and makes it easier to contextualize activity.
I work for a company, ExtraHop Networks, that is starting to see some use in cases like this. We do passive packet analysis from L2 to L7. Things like network traversal, odd tunnelling behaviors (DNS, reverse SSH, etc), even nmap scans can be investigated with our platform. ExtraHop doesn't position itself as security company, but is focused on application and network visibility using the communication itself, and security starts with visibility after all.
Organizations with very valuable networks that are completely disconnected from the internet and have strong policies and procedures about sneakernetting data back and forth.
For example, I might work at a R&D company working on some kind of new magic technology. All of the R&D work happens on the disconnected LAN (call it R-NET) and that's our daily driver. All the computers have software on them to prevent USB drives and other removable media from being plugged in, and no wireless anything, and if I have to move data onto the R-NET from the internet, there's a designated security admin person who does the move. They do it with a physical drive, sneakernetting the data between the networks.
Their process is to get the data, scan with every kind tool known and toss out certain prohibited files (executables, scripts etc.)
If you need an executable or script on the R-NET, you go through another procedure that does a full security audit on that software, and only once it's approved and added to a special list of installable things can it be put on your machine.
Going from the R-NET to the Internet requires a reverse of the process, but everything getting moved out gets reviewed, every document, piece of data, etc. to make sure it doesn't contain anything that shouldn't be sent out.
Everything on R-NET is logged. Everything, log ins, log outs, what software you opened, what libraries that software used, everything.
There might be a security team who monitors the R-NET and the moment they see something suspicious they have a "kill switch" to disable the network and all the machines that are one it until the problem is sorted out.
It sounds extreme, and it is, but it can be reasonably effective. Some places even have different networks for different projects to provide further isolation.
I'm a security guy and I've worked in these kinds of environments and it really sucked.
These days whenever someone proposes creating an air gapped network for a secret project I spend a lot of time enumerating the extreme costs of this configuration. Some of these costs are lowered development productivity, additional hardware and the extra people required for the more intense monitoring.
Air gapped networks are unpleasant to work on but can be a good security mechanism if you truly appreciate the costs.
Yeah, it's a classic risk/cost assessment. You can weigh what a scheme like this costs to implement vs. how valuable your information is and make a decision.
I think it's a good idea for some places to do this, but not all. It really depends.
I once worked on an air-gapped network. I programmed my own Klondike Solitaire, Freecell Solitaire, and Hunt the Wumpus games. The project was named "LBus", which was short for "look busy". I made the user interface look like log entries in a console window.
That's why perimeter defense doesn't work. You always have to let at least one person in, and any person you let in can become an insider threat--especially if their job is to write source code, compile it, and run it. If I need a script or simple program, I wouldn't bother trying to clear someone else's through security if it were easier to just type it in myself.
I feel slightly bad about slacking off at work in that manner, but I still completed all the tasks that were expected of me, and even got actual cash bonuses for exceeding work expectations. That workplace had absolutely no mechanism in place for exercising ambition or creativity, so if that entire department hadn't been destroyed by unethical (and, as I later learned, illegal) contracting practices, I probably would have also eventually devised a way to make Tetris look like the TPS Reports.
It wasn't the worst job ever.
But yes, internal security is a must. At minimum, keep the overly clever people with access to compilers in their own sandbox, away from everyone else. It seems odd to tell someone they can't have a compiled binary when they can just sit at a keyboard and type in "int main (void){ while(1) fork(); }" just for giggles. It's like giving someone a .50-cal rifle and then denying them a 9mm pistol.
It is an actual security issue, but really, as a developer, I just want different security restrictions on me than the non-developer users.
I have a compiler and the ability to execute any code I can imagine. In what network would you not want to wall me off from everyone else?
How much if this problem is solved when you have only accept Linux and Apple workstations in your network?
Years ago, Google discovered some kind of intruders inside their network, and mandated everyone to leave Windows and accept only Mac or Linux desktops. This has a cost of course, but I think something to think about.
I'm not telling that Linux or Macs has no malware/security problems, but is a very small problem compared with Windows today.
It would, however, make it a bit more difficult. Windows has more valid attack vectors than Unix-like systems do. Windows simply has more known vulnerabilities. It's not impossible to break into a Unix-like system, but for a dedicated attacker, it's almost trivial to break into a Windows environment. I can send someone an EXE that they can double click and install and I'm in. On Linux, that's much more rare of an occurrence. Try convincing someone to compile your malware from source...
The fact that most Windows users run as Administrator doesn't help. Using root in Unix-like systems is frowned upon unless absolutely necessary is one of the basic security advantages Unix-like systems have.
That hasn't been true for the vast majority Enterprise environments for the last decade or so, and even before for places which dumped the the Windows 9x lineage earlier.
Even home users on anything beyond XP rarely run with default Administrator privileges anymore, although they're still a click away for most users, through UAC.
Curiously enough, while Linux power users frown upon running as root, in Windows it's usually the power users who choose to disable UAC, although it's less bothersome than sudo (no password needed).
True it's possible. Which is why I said it's not impossible. But it's very rare to find Linux binaries, especially Linux binaries that are not distro-specific. It's much harder to throw an infected binary at a user when you need to know more about them than "they run Windows 7".
I wonder if I post on HN/proggit about my cool new ruby project, and start it off with curl | sh, but put something malicious, how many people will blindly install it?
Security is all about raising the bar. If we could get every single machine/device to "only be breached through targeted attacks", I think that would be quite good.
I don't think the Android ecosystem should be compared to an enterprise Linux ecosystem.
Android is pretty secure on its own, I think with a security/sandboxing design that beats Windows's design for example. It even has SELinux enforced by default now, something even most Linux distros don't have. But every piece of software has bugs, some of which are catastrophic to the security of the device (GoTo Fail, Heartbleed, etc). Therefore updates are critical to the security of the ecosystem of machines.
An enterprise environment can (should?) get updates much more easily than the vast majority of Android phones out there right now. Many of them get no updates and people keep them for 2-4 years. Many others get only one update in that same time, and only a smaller percentage are updated for like 18 months, even though many of those same users keep using them longer.
Android's main security problem is the lack of updates. Windows' main security problem is its bad design - apps/malware can do almost anything once they are installed, and we all know people do stupid things such as installing exe's from email attachments. Heck, Windows even gives you admin privileges by default, and we are still surprised Windows has so much malware built for it? It's like asking for it.
Android's main security problem is the lack of updates. Windows' main security problem is its bad design - apps/malware can do almost anything once they are installed
Do you know there have been windows releases since Windows 98se?
Ones with real user accounts, ACLs, firewalls and UAC? You onky get limited access by default, admin access requires you to approve the UAC checks.
And you're still comparing a home Windows system with an "Enterprise Linux ecosystem". No normal business Windows deployment will give anyone admin rights by default.
Once software is installed on any OS using administrative/root permissions, it can do anything. Run a software installer on Linux as root and it could disable SELinux, for example.
A large part of the problem is on the human side of things. Folks are very easily socially engineered regardless of what OS is underneath.
There are likely exploits for root in almost anything. In recent memory, we saw ntpd, which often runs as root, get hammered. And of course everyone remembers heartbleed.
As a thought experiment, on your linux command line, do a 'top' and ask yourself who has audited all those programs for security. Or, what the heck are all those things doing?
And as a second thought experiment, open wireshark inside a totally linux-based enterprise and see what information is flowing there. Do linux-based enterprises run TLS internally everywhere? Encrypt all file sharing protocols? My bet is the answer is no.
Additionally, breaches aren't all about getting root. Very common vector of exfiltration is SQL injection along with other injections. These happen at the application level.
Remember a little while ago when IE had a forever bug that led to a remote code execution? I think in the same week Chrome did as well.
While I grant that but is a very small problem compared with Windows today may well be true, small does not mean zero. All it takes is one improperly secured server sitting on the internet or one goofy neglected corner-case application page to lead to a total compromise. It only takes one tiny pinprick to deflate an inner tube flotation device.
I'm guessing you are correct that there would be less problem if they used Mac and Linux. For whatever reason Microsoft does not seem to prioritise security that much. Just the fact that you can infect the system by clicking on an email attachment is a bad idea. On a Mac you have to click on the attachment and type your system password which makes it much less likely for a secretary to get malware on the system by clicking an attachment. The technical difficulty of implementing that is pretty much nothing. It seems more a question of attitude and not taking it seriously. I'm reminded of https://news.ycombinator.com/item?id=6978626 where the guy took a virus course. Better designed systems seem the way forward.
It's funny - I knew I'd be downvoted but I'm not a Mac fan boy especially - I've got a pc and a Mac and find Apple annoying in many ways but I just think it's a fact that the security engineering is better on some systems than others. I see Apple now have over 40m people on Mavericks/later and have sold over 800m ios devices but have way less than 1% of the malware. It's hard to explain that by just being a small target.
If on Windows and in Outlook I click on
an email attachment that has extension
EXE, WHAT happens? You are saying that
Outlook will run the EXE? Really??????
Hm. I think the most important lesson here is that we need to treat "communication data"[0] more like we treat financial or medical data. If there isn't already there should be a rule in security that says that anything that's actively being used can't also be secure. They had year and year of data just lying around that people had mentally filed under "communication". It's kind of like web security where you lock down all your servers and then some developer leaks all the credentials on pastebin.
[0] There's probably a better word for this. A basically mean volatile data i.e. e-mail, working documents, logs etc.
Easier said than done. I routinely pull up emails from a year and a half ago for reference, and it'd be a giant pain if I had to request access to some sort of secure archive for them.
Maybe it's necessary to move in that direction (and maybe emails stick around only if you've specifically flagged them?), but you're going to have to drag people kicking and screaming into that kind of system. Gmail search has spoiled us.
My proposition: Anything worth referencing later is worth filing properly.
That may mean transcribing instructions into a stand-alone checklist, writing up formal user stories, or the like. However, those acts also clear away a lot of cruft that can otherwise make it nigh-impossible to find the needed info. I've run many a Gmail search, only to find that a valuable email was buried under innumerable "Not quite what I wanted" ones.
For a lot of internal data it's having and using the appropriate systems in the first place. It's like VCS. You don't e-mail someone code anymore. You make a branch or whatever and then reference that in your communication.
You do need a good alternative systems of course. But once those old e-mails isn't around anymore you would have to use the other system to still have access to the data.
I'm not even sure current e-mail systems are such a good tool. I would think chat for internal things and some CRM type system (leveraging e-mail) would be better. But yes as you said, easier said than done.
It's not easier said than done because it's technically difficult, it's easier said than done because you have to shove it down users throats and they're not going to be happy about it. And because there's an associated cost to productivity.
Worth it to avoid something like Sony's indecent? Probably. Easy to convince the non-technical decisionmakers of that? I'd bet not.
The industry term for this is unstructured data, basically anything that isn't kept in a database.
There's more you have to consider as well, you don't want to actually just archive anything older than a year. You want to set a rule that says: "archive anything created more than a year ago that hasn't been accessed in the last 3 months".
Further, there's all sorts of documents like the ones mentioned in the article that should be continuously monitored for and quarantined "passwords.txt" or Word docs with Social Security or Credit Card numbers in them.
Then you can get really sophisticated and start doing heuristic analysis of user behavior, setting alerts when Jim in accounting's account starts accessing marketing plans or when the account activity spikes beyond 5x what their regular usage is tracked at.
Full disclosure: the company I work for - http://www.varonis.com - makes software that does all of these kind of tasks.
So, I commented elsewhere on HN: https://news.ycombinator.com/item?id=8819389 about the move away from the current network security rules we have. I think that network-oriented defenses are not the right semantic for modern applications, as modern applications are no longer tied to physical semantics, or the semantics that modern hardware filters on.
-----
I have a different view on security. A lot of people are talking about defense in depth, and security being enforced by the network. I think although that kind of works, it's largely a mistake. Security, as enforced by middleboxes is fundamentally flawed, especially as we see the proliferation of systems that are too complex, and rapidly changing for middleboxes to understand. Although, they can be a tool in laying defensive trenches, they are nothing more than a simple barrier.
1) Isolating components: Components, and processes themselves should be isolated from one another, and the operating system. A web server should be able to run malicious code without fear of it easily getting root access. We have tools to make this possible today, like Apparmor, and SELinux. The fact that distributing Apparmor, or SELinux profiles with applications today isn't normal, makes me sad. This also probably means more unikernels, and lightweight hypervisors.
2) Modularization: We should do our best to split the components of a system up into small, well-understood pieces. Rather than trying to combine multiple components into one monolithic process, breaking up components into their individual components. I think Cloudflare's work around Keyless SSL was great, but we've had HSMs for years -- that could have easily avoided such disasters as Heartbleed.
3) Decent abstractions: With the advent of further distributed systems, and modularization, we're going to see more and more interfaces between systems crop up. Largely, CISOs are limited to what the systems, and networking team can do. These limits typically manifested themselves at layer 4 on the network side of the house, and limited layer 7 capabilities like URL filtering, and file system ACLs. I think we need better stories around resource access and authorization. For years, we've had systems like Kerberos which would have been a great building block, but yet goes unused. I hope we see X509, and GPG become more ubiquitous for access management, and encryption.
39 comments
[ 2.6 ms ] story [ 95.2 ms ] threadThis includes employing strict and disciplined use of access controls to manage where each employee can go in the network. That way if some assistant's account gets compromised, the bad guy can't just log into the email server or file share root.
It also includes keeping every machine's software patched and up to date. That makes it more difficult for bad guys to use known exploits to escalate privileges within the network.
It also includes enforcing strong password policies--and giving every employee a secure password management solution. (So they don't use Excel.)
2) Keep an eye on the internal network.
Network admins and security folks can use software tools (example: Netwitness) to know what traffic typically looks like on the network, and to detect anomalies. For example, if a lot of data starts flowing from a file share to a computer that typically does not access that share. Or if a lot of data starts heading out of the firewall to an address that no one has ever connected to before. Or if a VPN account authenticates at a weird hour or from a new address.
For example, at my employer, if I VPN in after about 10pm, I get an email or phone call from Net Sec asking if that is really me. If I connect to IRC from within the LAN--same thing. Any file transfer larger than a certain size gets flagged for follow up. Etc.
https://www.blackhat.com/docs/webcast/bh-wb-May12-Making_Lif...
For example, I might work at a R&D company working on some kind of new magic technology. All of the R&D work happens on the disconnected LAN (call it R-NET) and that's our daily driver. All the computers have software on them to prevent USB drives and other removable media from being plugged in, and no wireless anything, and if I have to move data onto the R-NET from the internet, there's a designated security admin person who does the move. They do it with a physical drive, sneakernetting the data between the networks.
Their process is to get the data, scan with every kind tool known and toss out certain prohibited files (executables, scripts etc.)
If you need an executable or script on the R-NET, you go through another procedure that does a full security audit on that software, and only once it's approved and added to a special list of installable things can it be put on your machine.
Going from the R-NET to the Internet requires a reverse of the process, but everything getting moved out gets reviewed, every document, piece of data, etc. to make sure it doesn't contain anything that shouldn't be sent out.
Everything on R-NET is logged. Everything, log ins, log outs, what software you opened, what libraries that software used, everything.
There might be a security team who monitors the R-NET and the moment they see something suspicious they have a "kill switch" to disable the network and all the machines that are one it until the problem is sorted out.
It sounds extreme, and it is, but it can be reasonably effective. Some places even have different networks for different projects to provide further isolation.
These days whenever someone proposes creating an air gapped network for a secret project I spend a lot of time enumerating the extreme costs of this configuration. Some of these costs are lowered development productivity, additional hardware and the extra people required for the more intense monitoring.
Air gapped networks are unpleasant to work on but can be a good security mechanism if you truly appreciate the costs.
I think it's a good idea for some places to do this, but not all. It really depends.
That's why perimeter defense doesn't work. You always have to let at least one person in, and any person you let in can become an insider threat--especially if their job is to write source code, compile it, and run it. If I need a script or simple program, I wouldn't bother trying to clear someone else's through security if it were easier to just type it in myself.
I feel slightly bad about slacking off at work in that manner, but I still completed all the tasks that were expected of me, and even got actual cash bonuses for exceeding work expectations. That workplace had absolutely no mechanism in place for exercising ambition or creativity, so if that entire department hadn't been destroyed by unethical (and, as I later learned, illegal) contracting practices, I probably would have also eventually devised a way to make Tetris look like the TPS Reports.
It wasn't the worst job ever.
But yes, internal security is a must. At minimum, keep the overly clever people with access to compilers in their own sandbox, away from everyone else. It seems odd to tell someone they can't have a compiled binary when they can just sit at a keyboard and type in "int main (void){ while(1) fork(); }" just for giggles. It's like giving someone a .50-cal rifle and then denying them a 9mm pistol.
It is an actual security issue, but really, as a developer, I just want different security restrictions on me than the non-developer users.
I have a compiler and the ability to execute any code I can imagine. In what network would you not want to wall me off from everyone else?
Years ago, Google discovered some kind of intruders inside their network, and mandated everyone to leave Windows and accept only Mac or Linux desktops. This has a cost of course, but I think something to think about.
I'm not telling that Linux or Macs has no malware/security problems, but is a very small problem compared with Windows today.
Even home users on anything beyond XP rarely run with default Administrator privileges anymore, although they're still a click away for most users, through UAC.
Curiously enough, while Linux power users frown upon running as root, in Windows it's usually the power users who choose to disable UAC, although it's less bothersome than sudo (no password needed).
I can do that with linux binaries too? The difference is that a Windows user is more likely to install untrusted software.
But where Linux is dominant there is malware. Reportedly, Android mobile OS malware is up exponentially in the last two years.
http://bitcast-maa1.bitgravity.com/quickheal/documents/other...
Android is pretty secure on its own, I think with a security/sandboxing design that beats Windows's design for example. It even has SELinux enforced by default now, something even most Linux distros don't have. But every piece of software has bugs, some of which are catastrophic to the security of the device (GoTo Fail, Heartbleed, etc). Therefore updates are critical to the security of the ecosystem of machines.
An enterprise environment can (should?) get updates much more easily than the vast majority of Android phones out there right now. Many of them get no updates and people keep them for 2-4 years. Many others get only one update in that same time, and only a smaller percentage are updated for like 18 months, even though many of those same users keep using them longer.
Android's main security problem is the lack of updates. Windows' main security problem is its bad design - apps/malware can do almost anything once they are installed, and we all know people do stupid things such as installing exe's from email attachments. Heck, Windows even gives you admin privileges by default, and we are still surprised Windows has so much malware built for it? It's like asking for it.
Do you know there have been windows releases since Windows 98se?
Ones with real user accounts, ACLs, firewalls and UAC? You onky get limited access by default, admin access requires you to approve the UAC checks.
And you're still comparing a home Windows system with an "Enterprise Linux ecosystem". No normal business Windows deployment will give anyone admin rights by default.
Once software is installed on any OS using administrative/root permissions, it can do anything. Run a software installer on Linux as root and it could disable SELinux, for example.
There are likely exploits for root in almost anything. In recent memory, we saw ntpd, which often runs as root, get hammered. And of course everyone remembers heartbleed.
As a thought experiment, on your linux command line, do a 'top' and ask yourself who has audited all those programs for security. Or, what the heck are all those things doing?
And as a second thought experiment, open wireshark inside a totally linux-based enterprise and see what information is flowing there. Do linux-based enterprises run TLS internally everywhere? Encrypt all file sharing protocols? My bet is the answer is no.
Additionally, breaches aren't all about getting root. Very common vector of exfiltration is SQL injection along with other injections. These happen at the application level.
Remember a little while ago when IE had a forever bug that led to a remote code execution? I think in the same week Chrome did as well.
While I grant that but is a very small problem compared with Windows today may well be true, small does not mean zero. All it takes is one improperly secured server sitting on the internet or one goofy neglected corner-case application page to lead to a total compromise. It only takes one tiny pinprick to deflate an inner tube flotation device.
[0] There's probably a better word for this. A basically mean volatile data i.e. e-mail, working documents, logs etc.
Maybe it's necessary to move in that direction (and maybe emails stick around only if you've specifically flagged them?), but you're going to have to drag people kicking and screaming into that kind of system. Gmail search has spoiled us.
That may mean transcribing instructions into a stand-alone checklist, writing up formal user stories, or the like. However, those acts also clear away a lot of cruft that can otherwise make it nigh-impossible to find the needed info. I've run many a Gmail search, only to find that a valuable email was buried under innumerable "Not quite what I wanted" ones.
I'm not even sure current e-mail systems are such a good tool. I would think chat for internal things and some CRM type system (leveraging e-mail) would be better. But yes as you said, easier said than done.
What you describe is "I want less company security, more personal convenience". (As almost everyone wants, almost all the time).
Worth it to avoid something like Sony's indecent? Probably. Easy to convince the non-technical decisionmakers of that? I'd bet not.
There's more you have to consider as well, you don't want to actually just archive anything older than a year. You want to set a rule that says: "archive anything created more than a year ago that hasn't been accessed in the last 3 months".
Further, there's all sorts of documents like the ones mentioned in the article that should be continuously monitored for and quarantined "passwords.txt" or Word docs with Social Security or Credit Card numbers in them.
Then you can get really sophisticated and start doing heuristic analysis of user behavior, setting alerts when Jim in accounting's account starts accessing marketing plans or when the account activity spikes beyond 5x what their regular usage is tracked at.
Full disclosure: the company I work for - http://www.varonis.com - makes software that does all of these kind of tasks.
-----
I have a different view on security. A lot of people are talking about defense in depth, and security being enforced by the network. I think although that kind of works, it's largely a mistake. Security, as enforced by middleboxes is fundamentally flawed, especially as we see the proliferation of systems that are too complex, and rapidly changing for middleboxes to understand. Although, they can be a tool in laying defensive trenches, they are nothing more than a simple barrier.
I think that endpoint security is what needs to be enhanced. Looking at what's been disclosed about malware recently (APTs: https://en.wikipedia.org/wiki/Advanced_persistent_threat), we need to focus on a few things:
1) Isolating components: Components, and processes themselves should be isolated from one another, and the operating system. A web server should be able to run malicious code without fear of it easily getting root access. We have tools to make this possible today, like Apparmor, and SELinux. The fact that distributing Apparmor, or SELinux profiles with applications today isn't normal, makes me sad. This also probably means more unikernels, and lightweight hypervisors.
2) Modularization: We should do our best to split the components of a system up into small, well-understood pieces. Rather than trying to combine multiple components into one monolithic process, breaking up components into their individual components. I think Cloudflare's work around Keyless SSL was great, but we've had HSMs for years -- that could have easily avoided such disasters as Heartbleed.
3) Decent abstractions: With the advent of further distributed systems, and modularization, we're going to see more and more interfaces between systems crop up. Largely, CISOs are limited to what the systems, and networking team can do. These limits typically manifested themselves at layer 4 on the network side of the house, and limited layer 7 capabilities like URL filtering, and file system ACLs. I think we need better stories around resource access and authorization. For years, we've had systems like Kerberos which would have been a great building block, but yet goes unused. I hope we see X509, and GPG become more ubiquitous for access management, and encryption.