Doing it Wrong – Uncryption of the Enterprise
Doing it Wrong (DiW)
Jay Jacobs and David Meier
Dave: First I'd like to take this opportunity to say "Hi!" to all three SecurityStallion readers out there. I know things have been a bit sparse since September last year but that's changing in 2010. The Digs are back and there's also some new article formats we're going to be throwing around. So with that lead in I'd like to welcome the infamous Jay Jacobs. Jay is one of the more realistic security practitioners I've had the chance to work with (albeit indirectly) and I'm pleased that we can do this type of spot together respectably titled: "Doing it Wrong". But what is this and why should you care? Over to Jay for the explanation...
Jay: Dave and I have had many discussions on various topics and "doing it wrong" stuck out as a title because that's what I kept thinking about Dave and I think Dave kept thinking about me. These posts should reflect that mutual respect. I also like the title, not just the initial Ha-Ha-ness, but also because it reminds me that we learn best from mistakes. If I would have gotten Sendmail working right away, I might not be able to spoof email with telnet. Realizing I'm doing it wrong means that I may be able to fix it. I look forward to challenging my way of thinking here.
Dave: Seriously Jay, you're still using Sendmail? That's a whole other DiW I guess! But, back to the meat: Uncryption of the Enterprise. So what does that really mean? Well, I've been around the track a few times (from a consulting perspective - it's really just like NASCAR, left turn, left turn, left turn...) and I tend to get riled up when things in the enterprise, that should be encrypted, are being tossed around the network, well, unencrypted. In fact often times when I bring up the fact that maybe those NTP updates should be encrypted or that OSPF adjacency is left ripe for the picking, or even FTP still being used as a primary transport facility in very, very, very large enterprises! WTF people? W-T-F? The best (and oft heard) excuse by far has to be from a monitoring perspective: "well then we can't see what's going on". The simple answer to that: if it's important enough to encrypt (PII, authentication data, sensitive information, etc...) and you don't have access to a point where you can extract, or view that data in flight - then maybe, just maybe, you shouldn't be privy to said data in the first place. I know, this might be a real shocker, but just because you're sitting in the SOC or NOC doesn't mean that because you can control the data flow that it's implied you should be able to read it. Encrypt if you have it, right? Jay? I mean, really, why not?
Jay: Yeah, I was still using Sendmail on my 286, but decided to upgrade for Y2K. Encrypt if you have it? There's a saying around cryptography, encrypting data is easy, it's the decryption that gets you. It's really easy to sit on a high horse (or Stallion, Dave) and say that everything should be encrypted, it's a whole different ball game to actually do it. As soon as data gets encrypted, a key is created, and then two things happen:
- Auditors flip to a new tab in their spreadsheet because a whole new set of controls around cryptography and key management must be understood, or at least implemented. Most IT folks, rather than view this as a development opportunity, see this as just more ways to screw up, which leads to...
- The typical IT admin gets a glazed look on their face and a mad rush ensues to find someone else to dump this crazy "encryption" on. Normally intelligent people all of a sudden look like their being asked to captain the Titanic on her maiden voyage.
These two things are exasperated by overly-protective frameworks and compliance controls that treat all the keys like they are dipped in gold then encrusted with diamonds. Generally speaking, a key is just a long password (with a few caveats). So, while encrypting NTP is a no-brainer in theory, in reality the key management in the products stink and nobody wants to sign a form saying that they understand and accept their key custodian responsibilities (thanks for that one PCI).
Where to Fix (WTF)
Dave: I can see Jay's point (to a degree). To manage keying (as a process) and the keys themselves is a complex undertaking in large organizations. Fundamentally, however, encryption is a component of the enterprise. The task is simplifying it where it can be simplified. Use it as it was meant to be used: to keep things private. And don't, I repeat, don't use it as an afterthought or add-on unless there is no other option. If encryption wasn't designed into your system of systems from the beginning adding it after the fact usually buys you as much improved posture as the hunchback of Notre Dame.
Jay: That's the rub, nobody is capable of designing encryption in because everyone does it differently, people should get together and make some type of open and interoperable key management protocol. Because rather than simply saying everyone ought to turn on encryption everywhere, I think it's more appropriate to say that we need to focus on the support structure to implement encryption. Something like meetings once a week, "Cryptos Anonymous" I'd call it, where normally well-adjusted admins show up and say, "Hi, I'm Jay and I'm a key custodian". Either that, or a well defined key management governance structure with tools to back it up. Then we can start talk about encrypting the world.
Dave: "Encrypting the world" - <sinister laugh>Mua ha ha ha hahhhhhh!</sinister laugh>
