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

Tuesday, March 27, 2012

For great justice. I mean security.

The Verizon Data Breach Investigations Report (available here) was basically another year of "all your POS are belong to us."  Which is depressing, but not at all surprising.  As you know, I talk a lot about what I call the Security Poverty Line, and how smaller organizations that are IT-poor tend also to be security-poor.  Moreover, because security and IT are so often separate, security becomes optional, a luxury and an omission for the small business that doesn't know it has something to lose -- or even if it does, it hasn't got the faintest idea of how to go about addressing it.

Enter the DBIR, and what I think is one of the most helpful steps ever taken to address this security-poor population.  On page 62, the redoubtable Verizon Risk Team has created a cutout sheet that you can hand out to your favorite retail, hospitality and food establishments.
Greetings. You were given this card because someone likes your establishment. They wanted to help protect your business as well as their payment and personal information.
It may be easy to think “that’ll never happen to me” when it comes to hackers stealing your information. But you might be surprised to know that most attacks are directed against small companies and most can be prevented with a few small and relatively easy steps.
 And the cutout doesn't get too fancy or preachy; it basically recommends two main things:  change your default passwords, and make sure you have a firewall.  And if you're not the one who is in charge of these things, make sure your vendor does them.

The beautiful simplicity of this is hard to overstate.  The cutout doesn't invoke FUD; it just says, "Hey, we've seen a lot of this and you might want to be careful."  The language makes it accessible to someone who is busy running a business, and who doesn't have time to delve into arcane IT concepts.  It tells them the most important things they need to do, and puts it in a digestible format.

I hope people will go to the trouble of making copies of this cutout and giving them to as many franchises and local businesses as possible.  It would also help to have a simple and cheap answer to the question, "How do I find out more about this?" if the business owner should ask.  I know of at least one security professional who makes a point of going to speak about security at chamber of commerce meetings, and we need more of this kind of outreach.

For the security-poor organizations, the best thing we can start with is to arm them with information -- the kind of information that is useful to them.  If we made a concerted effort to reach out to this underserved population, I'm hoping the DBIR numbers would get smaller over time.

Saturday, March 3, 2012

Going back to the stack.

In the spirit of trying to suggest solutions, here are a couple of thoughts about what an enterprise can do first off to make security a little better.

It's bothered me that infrastructure is being administered more horizontally than vertically these days.  Everyone specializes in a different layer: network, OS, utilities (such as Exchange), middleware, applications, etc.  And this gets worse when you outsource one or two layers to "the cloud" (think IaaS, PaaS and SaaS), so that you have to coordinate with a third party to troubleshoot something.

Back in the Pleistocene era, system administrators knew their systems like they were their babies.  They knew everything that was running on them, how they were configured, who they talked to, and they knew when something was "off."  I know sysadmins that would regularly help a developer debug code, and they were often better at it than the developer, because they also understood the underlying environment better.  They could troubleshoot all the way up and down the stack, and you went to one source to do it instead of having to get a conference call together with 3rd level engineers from four different companies.  (Seriously, I know of a data center that had five different networks owned by five separate entities.  Think you could figure out what happened to a packet?  Think again.)

So one thing that enterprises can do is simply to get control of their layers as much as possible.  Know what you have, know where it is, and be able to cause changes to it when you want to.  That sounds so obvious as to be not worth saying, but I don't know of any admins who know more than about 500 hostnames by heart, and many times the environment is so dynamic that boxes come and go without any centralized tracking keeping up with it.  (And I'm not even talking about VMs.)

If you already have parts of your infrastructure outsourced, go over your contracts and strengthen your relationships with your providers.  You want them to be able to give you logs, for example, within a few minutes of the request.  You also need to have the right technical level support people on call without having to fight your way through first-level script-readers.

And finally, go back to designating "stack admins," who are generalists rather than specialists in one particular technology.  It should be their job to know as much as possible about any given system.  You can fit this into DevOps if the developers truly know the lower layers.  A stack admin is your best hope for knowing what normal operation is, and for alerting you when something doesn't smell right; they're also the best at understanding the implications of any given planned change (such as changing the ports an application uses without creating the corresponding firewall rules).

Start with knowledge, and then work your way to control.  Notice we haven't really touched on security yet; that'll come later.  But knowledge and control are basic building blocks of security.