I've given talks on this before, and published a report (available for free here), but I haven't really put everything in one place until now. I coined the term "security poverty line" to describe those organizations that, for one reason or another (usually a lack of IT funds), can't afford to reach an effective level of security, much less compliance with security regulations.
When you don't have a lot of IT money, you can't afford your own IT staff (or you go with whatever you can borrow or rent). This means you don't have in-house expertise to maintain a decent level of security controls and monitoring, even assuming you get systems and networks configured right to begin with. As we all know, security is an ongoing process, and if you have Jane the IT Girl as your sole resource, she's going to be too busy troubleshooting problems and installing new systems to be able to maintain the existing ones in a proactive fashion.
Organizations below the SPL tend to be inordinately dependent on third parties for this reason, and since they're so dependent, they have less direct control over the security of the systems they use. They also end up ceding risk decisions to third parties that they ideally should be making themselves.
And they don't have resources for luxuries, such as separate systems for different tasks, or different personnel to achieve segregation of duties. They'll tend to throw everything on the existing old hardware until it breaks, or until the performance is so unacceptable that they're forced into paying for more. (This is why nobody should be surprised that the public sector has to struggle with crowded, antiquated systems. How many taxpayers are going to pay for upgrades just to keep everything new and shiny, when the old systems were working just fine?) They'll share data and networks with partners. They'll use the cheapest software they can find regardless of its quality or security. And they'll have all sorts of kludges and back doors to make administration easier for whoever they can convince to do it.
So although some people see the failure to achieve compliance or effective security as simply a matter of attitude ("if you really cared about auto safety, you'd buy a Mercedes!"), it's not that simple. Even upgrading and untangling a set of legacy systems can double the cost of migration to a new platform, due to system inertia and missing institutional knowledge. Any consultant who has had to step in to one of these environments to fix something knows what it's like to pull on one thread that appears to have an obvious solution, and discover that it's attached to too many other things that can't be easily changed.
Not only that, but certain types of security technology are more expensive than others. In a talk I gave at the UNITED Security Summit this year, I showed some figures from some back-of-the-envelope surveying I did on what $2,000 can buy you; slides are available here. (Even $2k is a lot of money to justify spending on security for a lot of these organizations.) As it turns out, most of the affordable security technology is the oldest kind, the least effective, and mostly preventive in nature -- firewalls, antivirus, and a scanner that will tell you what's wrong with your systems that you can't afford to fix. The newer stuff, especially anything that involves proactive work and monitoring, is out of reach. Enterprises below the SPL are not only stuck with the equivalent of burgers and fries, they can't afford any vegetables (thanks to Alan Shimel for making this more explicit).
Open source, you say? Tell me if your dentist's office uses open source software, and who there knows how to install and maintain it. Open source software is expensive when you include the expertise needed for support. (I chatted with Alan about this one time when a recording was running.)
What this means is that many organizations that slip into security poverty tend to get trapped there. Unless they can afford to do a greenfield transfer to a provider with a squeaky-clean new network and managed security services, they will just keep patching what they have, and only do the minimum that is going to fend off their biggest, most visible risk: the auditor. Rather than continuing to beat them with the compliance stick until morale improves, we need to make security services more affordable (and there are some providers who are working on just that). We need to build security into products and deliver them already secured, so that security isn't an add-on luxury. We also need to create more hands-on resources -- perhaps as a community service -- that poorer organizations can draw on, not just to give them guidelines, but to adapt them to what they can afford to do.
And finally, we need to be able to state clearly what effective security looks like. The great thing about compliance (yes, I really did just write that) is that you know when you're done. When the last box has been checked, you have that sense of accomplishment, and it's straightforward to know whether you pass or not. I challenge anyone in the security community to tell me what, say, a 50-person company needs to buy -- even assuming they have a blank check -- to make sure they are doing everything necessary to manage their risk. (Hell, I challenge anyone to tell me what their risk is without using colors.)
At least there's a food pyramid (or plate, or whatever -- they keep changing it) to describe the minimum daily requirements for nutrition. What should be on the security plate for a healthy organization?
Update: I talked with Tracy Kitten at BankInfoSecurity.com about the topic here.
