Wednesday, August 20, 2014

The Indelicate Balance Between "Keep it Working" and "Keep It Safe"

Security professionals continue to fool themselves into believing we walk a delicate balance between keeping the business functional, and keeping it safe (secure). This is, in many people's belief including me, a lie. There is no delicate balance. The notion of being able to balance these on a teeter-totter looks like this:

Guess which one the 'safe and secure' is? Exactly.

An interesting conversation (warning: profanity, not so safe for office) happened earlier today. And as per the usual, someone very smart and seasoned in the enterprise side of defense made the point clear.

The bottom line is this:
  You can't ever cross the line into 'breaking business stuff' because you likely never get the chance again.

Each time the pendulum swings into the "secure" side of the spectrum it stays only for a tiny fraction of time, and we as security professionals have to work very hard to make it stick, or it swings back the other way... quickly.

So the question then is, how do we "make it stick"?

Simple! We demonstrate the business value of good security (aka keeping the enterprise safe). Of course, there are few things that are more simple than this, including tightrope walking the Grand Canyon, being an astronaut, and nuclear physics. Whoops, hyperbole ran away with me there for a moment, sorry. Back to reality.

So the key is to make security sticky. You need to align security to something the business can get behind. Hence, business value is so important to measure. But if you're still stuck reporting useless metrics - like how many port scans your firewall blocked, or how many SQL Injection instances your Software Security program identified - you're miles away from demonstrating business value.

This brings me back to KPIs, and the development of data points which strongly align to business/enterprise goals. All of this is predicated on someone in the security organization (or everyone?) being alert and aware to what the business is trying to accomplish at the board/strategic level. Does your organization have this type of awareness and knowledge? Are you leveraging it?

I can tell you that if you're not, the picture above will continue to be your fate... from yesterday to today and on into the future.

Wednesday, August 13, 2014

Getting in Our Own Way

The security community has this widely-understood reputation for self-destruction. This is not to say that other communities of professionals don't have this issue, but I don't know if the negative impact potential is as great. Clearly I'm not an expert in all fields, so I'll just call this a hunch based on unscientific gut feeling.

What I do see, though, much like with the efforts of the "I am the Cavalry" movement which has sent an open letter via to the auto industry, is resentment and dissent without much backing. In an industry which still has more questions than answers - and it gets worse every day - when someone stands up with a possible effort towards pushing a solution you quickly become a lightning rod for nay-sayers. Why is that?

One of my colleagues who is the veteran CISO has a potential answer - which for the record I'm uncomfortable with. He surmises that the collective "we"(as in security community) aren't actually interested in solving problems because the real solutions require "soft skills like personality" and business savvy in addition to technical accumen. It turns out that taking the time to understand the problem, and attempt to solve it (or at least move the ball forward) is very hard. With the plethora of security problems in nearly everything that has electricity flowing to it, it's near-trivial to find bugs. Some of these bugs are severe, some of them are the same 'ol, same 'ol SQL injection and buffer overflows which we identified over a decade ago but still haven't solved. So finding problems isn't rocket science - actually presenting real, workable solutions is the trick. This is just my humble opinion based on my time in the enterprise and consulting in.

I once worked for a CISO who told his team that he didn't want to hear about more problems until we had a proposed solution. Furthermore, I'm all for constructive criticism to help contribute to the solution - but don't attack the person or the proposed solution just to do it. Don't be that person.

I think it may have been Jeff Moss that I heard say it - "Put up or shut up"... so give me your solution idea, or stop whining things are broken.

Friday, August 8, 2014

Why Your Enterprise Most Likely Doesn't Have a Zero-Day Problem

It should come as no surprise that at Black Hat 2014 this week there were an enormous amount of invaluable conversations, as always. We talked about attacks, exploits and exploitation techniques as well as defenses basic and exotic. A few of these ended up in the same place, logically, and have led me to conclude that the majority of enterprises out there don't have a zero-day problem. Let me explain...

It should by now be clear if you're a security professional that the average enterprise struggles with even the most basic security hygiene. This of course makes life difficult when we start to pile on cross-silo dependancies - for example configuration management - for security effectiveness. While I certainly don't mean to imply that every enterprise can't do the basics, I have yet to meet a CISO who is comfortable with the fundamentals of asset, configuration and user management on an enterprise scale and in a timely fashion.

That being said, I further submit that zero-day attacks and exploits are an advanced level of attack typically reserved for targeted organizations which have significant levels of security capability mandating these advanced levels of effort. Basically if you've got your fundamentals right, and you're doing good block and tackle security, your users are well educated to be skeptical of links and things sent to them the determined attacker will be forced to turn to exploiting yet unknown and unpatched weaknesses in your software to get through your defenses. The truth is, I have come to believe, that the vast majority of enterprises just don't have their act together enough to merit that level of effort from the attacker.

From what I know, an attacker burning a zero-day exploit is a non-trivial matter. Zero-days, while still fairly plentiful, have a cost associated with them and an attacker will use one of these once he or she has exhausted the typical, and often easy, methods of breaching your security. There are simply too many options further down the chain. You have to look no further than a conversation with David Kennedy of TrustedSec who makes it clear exploits aren't required to break in. All that's required, in still far too many instances, is sending someone in the organization a malicious link, or a malicious file and they'll open the door and show you their closely-guarded intellectual property ... and probably hold the door for you as you walk out with it. Yes, indeed it is that simple to exploit corporate security with brain-boggling results.

So why burn a zero-day? Attackers typically won't unless they've encountered roadblocks in other avenues. Since PowerShell is installed on every new Windows PC, it's the perfect tool to use to execute an attack, legitimately, on a target host. All the user has to do is let you in...and we all know that most users will still click on the lure of a dancing bear or the promise of nude photos of their favorite celebrity.

So while your enterprise security organization may actually encounter some malware with zero-day exploits in them, they likely aren't targeted at your organization. The problem your average enterprise has is poor fundamentals - leaving you open to all manner of exploit and penetration without the use of any more advanced techniques than "asking the user for permission". So why would an attacker burn a precious zero-day against you? They likely wouldn't. Unless, you know, you're a target.

Friday, August 1, 2014

Security on a Weak IT Foundation

The interesting question of maturity

Earlier this week, Bill Burns asked me this question...
"can a security team have a higher level of maturity than the IT team that handles its operational tasks?"
It's an interesting question, and one that certainly requires some level of thought. My top-of-my-head response was - well ... no. This is clearly a "lowest common denominator" problem.

The more I thought about it, the more this seemed like an obvious answer - a CMMI level 2 IT organization was never going to support a CMMI level 3-5 security organization. That should seem rather obvious. But the more I thought about this, the more I think that a CMMI level 2 IT organization can't support anything but an n-1 security organization. Let me explain my thinking here-

Weak foundations, weak security

It should be rather obvious that a weak foundation cannot support a tall, strong structure. You simply don't have the stuff it takes to hold it all up, from a building perspective.

In the IT world, if you have weak operational IT practices, you'll never get anything better than weak security practices. For example, let's look at how IT views and assesses assets on the corporate network. If IT can't tell you every asset on the corporate network right now in an on-demand manner, with troves of accurate meta-data then you can't possibly expect to build a strong security operations program on top of that. Security needs foundational things such as the ability to know what's on the network and loads of meta-data about each asset in order to make decisions on the risks these assets pose.

Decomposing that even further to the most simple blocks - if IT doesn't know what's most critical to the business in terms of supporting function, security has absolutely zero chance of successfully crafting a defensive response strategy or operational plan. If an asset is suspected of being malicious or compromised (an IP address, for example) meta-data is needed to decide whether the alert could potentially be a false-positive, or if it even warrants a response (maybe it's just some lab machine which can simply be turned off). As a kid G.I. Joe taught us that knowing was half the battle - and not knowing means you're lost.

Weak foundations, weaker security

In an effort to try to understand this more, my line of thinking leads me to believe that organizations with a particular CMMI score when it comes to general IT, can only support an n-1 CMMI score for security maturity.

The reason I believe this is that security operations, by their very nature, cross many IT silos and require well-thought-out and precisely executed workflows and communication to function well. When you cross team boundaries, silos and responsibilities these inherently break down even a little - thus diminishing what you can build on top of them. Like the great pyramids - the higher you build the more you have to stack inward. Security - at least in my narrow view - is sitting right at the top of the IT ladder, thus making it fairly difficult to do well if the base of the IT operations is shaky.


The long and short of it is this - if your enterprise has poor IT hygiene, and ranks low on the CMMI scale - focus security effort and resources on helping IT level up before you start to drop in expensive and complicated security kit. In essence, flashy boxes or solutions won't do you much good when you try to operationalize them on top of poorly functioning IT infrastructure, processes and methodologies.