Because I'm all about the "good enough."

Thursday, September 25, 2014

Shock treatment.

Another day, another bug ... although this one is pretty juicy. One of the most accessible primers on the Bash Bug is on Troy Hunt's blog.

As many are explaining, one of the biggest problems with this #shellshock vulnerability is that it's in part of the Unix and Linux operating systems -- which means it's everywhere, particularly in things that were built decades ago and in things that were never meant to be updated. There will be a lot of hand-wringing over this one.

But I think I have a way to address it.

It's a worn-out analogy, but bear with me here. Windows in buildings. Now, we know glass is fragile to different extents, depending on how it's made. Imagine that we had hundreds or thousands of "glass researchers" who published things like this:
"Say, did you know that a 5-pound rock can break this kind of glass?" 
Whereupon business owners and homeowners say: 
"Oh jeez, okay, I guess we'd better upgrade the glass in our windows." 
"Say, did you know that a 10-pound rock can break this kind of glass?" 
Business- and homeowners:
"Sigh ... all right ... it's going to be expensive, but we'll upgrade." 
"Say, did you know that if you tap on a corner of the glass right over here that it'll break?" 
Business- and homeowners:
" ... " 
"Say, did you --" 
Business- and homeowners:

Yes, glass is fragile. So is IT. We all know that. And we don't expect everyone in the world to have the same level of physical security that, say, bank vaults do.

If there's a rash of burglaries in a neighborhood, we don't blame the residents for not having upgraded to the Latest and Greatest Glass.* No, we go after the perps.

Without falling too much into the tactical-vest camp, I think we ought to invest more money and time into defending the Internet as a whole, by improving our ability to tag, find and neutralize prosecute attackers. Right now, the offerings in the security industry are heavily on the enterprise side -- because after all, especially in the case of the finservs, that's where the money is. There are some vendors who are trying to address critical infrastructure, automotive and health care, which are three areas where people can and eventually will die as a result of software breaches. But we shouldn't wait until that happens to go on the offensive. We need a lot more investment in Internet law enforcement.

This is a case where expecting the world at large to defend itself against an infinite number of attacks just doesn't make sense.

*If you think it's cheap to patch, you haven't worked in a real enterprise.

Thursday, September 18, 2014

A tenuous grasp on reality.

"Don't blog while angry," they say. Well, it's too late now.

One thing that has bothered me for years is the tendency for security recommendations to lean towards the hypothetical or the ideal. Yes, many of them are absolutely correct, and they make a lot of sense. However, they assume that you're starting with a blank slate. And how many people ever run into a blank IT slate in the real world?

Here are some examples.

"Don't have a flat network." Well, that's very nice. And it's too late; we already have one. Any idea how much time and effort and money it will cost to segment it out? Start with buying more/new network equipment; think about the chaos that IP address changes bring to multiple layers of the stack. Firewall rule changes (assuming you have them), OS-level changes, application changes (and you can bet that IP addresses are hard-coded all over the place). Think about the timing that a migration needs -- maybe Saturday after midnight until Sunday 6am in the local time zone? And figuring out the policies around which hosts really need to talk to other hosts, on which ports, because while you're playing 52-node pickup, you might as well put in some least privilege.

"Build security into applications early in the SDLC." Yes, absolutely, great idea. What are we going to do with the applications that are already there? Remember those calculations on how much it will cost to fix something that's already in production as opposed to fixing it in development? There's no way around it: you're going to need a bigger checkbook.

"Stay up-to-date on commercial software." Well, what if you're two years behind? (It really does happen.) Again, you're looking at a Project to implement this seemingly simple idea. From the ERP implementation that isn't supported by the vendor yet on the newest operating system, to the dozens of different JVM versions you've got running in production, this is a much more expensive recommendation than you realize.

And yes, these recommendations all hold true for what enterprises should do going forward. But in most cases, they need help making the changes from what they have and what they're doing today.

It would help so much more if instead of couching recommendations and standards in terms of where you should already be, you talked about them in terms of how to get there. After all, security is a process, not an end state; a journey, not a destination. Everyone starts out from different points, and needs different directions to know where to go. There are some ways an organization with 200 security staff and thousands of applications can pivot that will be different from the ways an enterprise can pivot with 2 security staff and with everything hosted by a third party.

So recommendations might look like this: "From now on, you should not automatically grant administrative rights to each desktop user. And here's how you go about taking those rights away from the ones who already have it." I believe incorporating more flexible and realistic security principles will make them easier to swallow by the people who have to implement them.