Security Balance

For HBGary, it was a less important website. For CardSystems, it was just a research database, not the critical payment processing systems. For Heartland it was also a minor web application. RSA initial compromise point was an end user workstation.

As we can see, big breaches not necessarily happen through an organization’s most important systems. That’s actually quite similar to security breaches in the physical world, it’s not common to see the attacker coming through the front door.

Even if that in mind, security decisions are still being made to protect the critical systems only, what is normally seen as appropriate “Risk Management”. I have no doubt we should protect critical systems first, but we also need to make executives aware that attackers are not picky about their targets. If they find what they are looking for (passwords, credit card numbers) in secondary, less important systems, they’re still happy with the outcome. And the breach will still be quite damaging; it doesn’t matter they didn’t reach your critical systems; they got what they want from somewhere else, and for everyone else it was just “they got it from your network”. It doesn’t matter which system was that.

Even if there’s no valuable data on secondary systems (are you really, really sure about that??), they still can be used as bridgeheads for attacks against the major data repositories. So, pay attention to your compartmentalization strategy (are those different levels really segregated from each other?) and your network wide monitoring capabilities. Those secondary systems may be part of critical processes or be responsible for any of your revenue, but they are still juicy targets for whoever is interested in your data.

Complexity is always a key factor for security decisions. In general, less complexity means more security, as simple is usually easier to protect than complex. A few days ago I read something about cloud and security (again J), something along the lines of CSOs concerned that cloud means more complexity so it’s insecure. Well, an interesting thing about complexity is that it doesn’t necessarily make things harder; generally it doesn’t matter how complexity the entire system is, but how much of that complexity affects you and your ability to provide security.

Take, for instance, ABS brakes; they are far more complex than plain simple brakes. However, they provide more security. Still on cars, the electronic fuel injection is more complex but easier to operate, at least in the driver’s perspective. Same thing for fly-by-wire systems and many others; they are more complex, but they reduce the complexity presented to the operator of the system. When that happens, it makes the device/system easier to handle, reducing the opportunity for human mistakes. There are more moving parts (and more parts that can fail), but the operator has to handle less variables.

Cloud computing is the same thing; highly complex environments such as Amazon EC2 will make a lot of things easier for you. You’ll have to directly handle less security aspects than you’d usually have by controlling your own data center, servers, etc. The security issues related to those components are still there, but they are being managed by someone else, who is probably relying on heavy automation in order to make this new system viable. That someone else can be Amazon, or can be the maker of your car; Microsoft or Apple, for your Operating Systems; and so on.

In the same way as ABS brakes had been first introduced in Formula 1 cars and later came to the “end user”, the same thing happens with computing technology. I remember when electronic injection cars were being introduced; a lot of car aficionados would complain that they were losing control to those little computer boxes that couldn’t be as good as the old carburetor they could fine tune by ear. Cloud computing has been maturing for quite some time, and is now being adopted by end users. The complexity is still there, but it’s so well managed that the end user perception in the end is a less complex system. In their security point of view, an system that is easier to protect.

ABS, Electronic Injection, Fly-by-wire, all those systems are trade-offs. Relying more on technology and automation to reduce the complexity presented to the human operator. It’s a fact, proven by numbers, that it works for those technologies. Does it work for IT security?

I noticed an interesting thing about security policies the last time I started in a new job. Every time I start with a new company I read the entire Security Policy. (It should be required reading for anyone in a security job for an organization, but I’m impressed that I usually end up becoming the “Security Policy Authority” after that exercise, just because nobody bothers going through it J). The impression is generally that a good set of security controls are in place. However, as  time passes, I start to see the exceptions, the new controls that are still being implemented, the legacy stuff that should have been retired but is still lingering around, etc. It always takes time to understand the gap between the policy and its current implementation.

After seeing that so many times, I wonder: why aren’t organizations monitoring the policy implementation? In fact, it should be one of their key metrics! You measure your policy against the threat landscape and your risk appetite, than check if that policy is in fact being enforced.

Unrealistic expectations about the implementation of the security policy are extremely common. The executive sees a document to be approved and signs it. It probably has the same feeling as Capt. Picard saying his famous “Engage!”. But after that, he doesn’t pay attention to the huge number of exceptions granted or just delegates that process, in such a way that what’s on paper ends up being  very far from what’s actually being done. An Internal Audit department might be able to help, but I’m not just making the point of verifying, I’m talking about actively monitoring it as a guidance metric. Audit usually doesn’t go that far. I’m also talking about benchmarking different Lines of Business and Technologies, in a way that a CISO would be able to understand where he’s getting more support from, who is resisting the implementation of the policy and even whether it makes more sense to drive investments to more enforcement or to deploy additional controls. I think some would call it an “actionable metric”.

I’m interested in hearing from people currently monitoring their security policy implementation level? How are you doing it? How are you using that data? Any tools being used (maybe GRC)?

There are two ways to automate log reviews. There's the common approach:

Buy a product with PCI Compliance reports, check the box for each of those, send the reports by email to someone who will say they are being reviewed. done.

A lot of organizations do that, but it's really just checkbox compliance with the standard and does not add anything in terms of security value. Ask yourself, what are those "PCI Compliance Reports"? How can someone know what needs to be reviewed in our logs if the standard itself does not specify that?

The other way can use the same product mentioned above, but on this case you have real people (with knowledge about what's in those logs and what you need to look for) writing the rules for alerts and reports. A process for periodical reviews of those conditions are also necessary.

There's no "Enable PCI" solution for log review. Only dumb QSAs buy that.

Michelle Kinger has a very good post at infosec island talking about the harm from exceptions to security policies. I also mentioned that in my unrealistic expectations posts.

There are many discussions about security and risk metrics, but it’s rare to see anyone mentioning something to control the number of exceptions granted; a key indicator to any security program should be related to the exceptions granted/revoked ratio and to the exceptions stock. If you have an always upwards trend in your chart, it’s time to review the policy or the incentives for people to follow the policy. Having a policy with good controls that no one adheres to is just the same as having no controls, with the down side of giving the wrong perception about your security state.  

I can’t disagree with Simon Crosby when he says “virtualization holds a key to better security”. Isolation is the basic security building block here, being achieved by virtualization.  And that just makes me sad. Relying on virtualization for that just shows how unsuccessful  we’ve been on building decent Operating Systems.

Operating Systems are generally built with the isolation concept in mind, trying to prevent one application from interfering with others. Almost all modern OSes have that concept as part of their design goals. Yet, we go deep into wasting resources to duplicate the OS and emulate the hardware layer to each virtual machine. Really, can anyone tell me why would we have to rely on virtualization for isolation if Operating Systems were capable of doing that?  

Very good summary of what OpenFlow means to security by my friend Fernando.

The interesting part in his post is this one:

“Well, for all the power that OpenFlow offers, it can still only visualize flows in the context of L2-L4 attributes: what port is connected, what the IP address is, what protocol, etc... In the meantime, it comes as no surprise to anyone that the threat profile has long since changed to the application layers, exploiting Adobe PDF, Flash, SQL Injections, Cross-Site Scriptings, ... To me, what this will mean is that these higher-layer security controls - be they Web Application Firewalls (WAFs), Data Loss Prevention (DLP), Network Forensics, Host Security Agents ... - still need to intercept and inspect traffic.” 

That’s true, but the real value from OpenFlow is how it allows us to perform security interventions dynamically; you’ll still need to inspect traffic at higher layers to find trouble, but once  you’ve found reasons to believe there’s malicious activity going on OpenFlow can be used to selectively add more inspection capabilities and apply damage control measures.

It’s always good to get some new tools to our arsenal. The bad guys are far ahead in that aspect, so better start thinking about improving our instrumentation capabilities too.

I'm happy to see how the security community is realizing the importance of detection and monitoring. I'm reading a lot of good stuff recently, but as there's a lot of "re-discovering" happening it's important to know the results of research done in the past to avoid falling into the same mistakes. That's why it's so important to whoever is thinking about security monitoring to consider the "base-rate fallacy". This paper written by Axelsson dates back to 1999, but the basic idea is still valid and must be always considered when we are designing a detection system. 

I won't write here about it, you can read it directly from Axelsson's paper. The basic lesson is to not spend too much time on being able to find every possible attack, the must important thing is to reduce false positives as much as possible. Otherwise, you'll end up with a huge team looking for needles in montains of hay. 

There is another great post by Brian Krebs at his blog Today, about APT. However, the best part of it is a quote from Cisco's Gavin Reid:

“One of the areas where we’ve failed as a security community is that we’ve got an over-reliance on automation,” Reid said. “We’ve sold this idea that we can automate it, in a way that will not only help your security staff identify threats, but that you can cut your staff down because these technologies are going to do the work of a lot of people. That has failed. We’re still stuck with [the reality that] you need smart people who understand computer, applications and networks, and a logging solution becomes a tool they can use to identify some of these things. Hopefully this has been a little bit of a wake-up call, and we can start looking at things a little differently and start putting people back into the equation.”

When you see organizations believing that their simplistic set of IDS or SIEM rules is enough for security, it's a sure sign that there's too much trust on automation.