"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.
