Scaling the Security Chasm

by Paul Rubens

It takes more than mere compliance to keep your organization truly secure.

More on security

Many people wear seatbelts because they could get fined if they don't, rather than because wearing them might save their life, security consultant Dr. Anton Chuvakin observed during his keynote speech at the Hack In The Box security convention in Amsterdam in early July. It's an interesting observation, and one that has interesting implications for server security.

Chuvakin points out that before governments made seatbelts compulsory, seatbelt use was low even though most people understood the benefits of wearing them. It was only when seatbelt laws were passed that usage went up significantly.

There's a parallel here with the server security measures that many organizations take to protect customer data, he said. Most companies understand poor server security potentially is harmful to their business, but it's often the threat of breaching compliance regulations rather than potential harm to their business that prompts them to take any sort of action. "To me that's weird and illogical on many levels," said Chuvakin. "Why would we secure our networks because some regulation tells us to do it and not because some hacker might break in and steal things?"

This can lead to what Chuvakin terms "the security chasm": the gap between meeting compliance requirements and drawing up high-level security policies on one hand, and actually rolling up one's sleeves and taking practical measures to secure an IT environment on the other. "What we see are two security realities. One is conceptual and fuzzy, and the other is painfully real. The reality is we have security policy experts who never do anything, and the blokes who work every day to save your network.

The problem as Chuvakin sees it is that compliance rules were introduced to establish a baseline of security because many organizations weren't taking even the minimum sensible security precautions to protect the data they held as custodians. "Compliance isn't about doing anything useful or new, it is simply about beating up organizations that don't do basic stuff," he said. "Now what's happening is that many organizations spend all their energy pleasuring PCI or other compliance people and not on other important things. They forget that losing their own data can be disastrous, even though it is not regulated."

The ideal situation would be for organizations to protect their own data -- such as intellectual property and trade secrets -- and data such as the health records and social security numbers of which they are custodians. These types of organizations are "security leaders," Chuvakin said. Without compliance regulations it would be natural to see companies that protect their own data -- which after all they value highly -- while taking a more lax approach to custodial data, which is of less value to their business. These companies he terms "risk takers." However, thanks to the current regulatory zeal, many companies focus on custodial data compliance while failing to adequately protect their own data.

These companies he termed "idiots."

Why do some companies fall into the trap of becoming security idiots? Chuvakin said he believes that although compliance regulations were meant to establish a security baseline and a motivation for companies to actually reach this baseline and eventually move beyond it, many choose to treat regulations as a security ceiling.

"PCI and other compliance regulations give us a To Do list of tasks which can be counted and ticked off," said Chuvakin. "Running though a list like this is much easier than working towards real security, which is open-ended and can never be just done. Of course, compliance regulations were never meant to be a checklist -- they were intended to be a sledgehammer to be used to move people from a state of complete ignorance to a slightly less ignorant state."

The "security chasm" actually goes far beyond the issue of compliance versus real security, Chuvakin said and is to be found anywhere where people focus on high-level theorizing without actually fixing anything. For example, he is highly skeptical of "proactive security" efforts.

"I freak out when I hear people talk about being proactive. What's important is to keep businesses running. You need to focus on being quickly reactive rather than talking about being proactive." He warned that organizations can write as many policy documents as they like, but PCs will still be compromised because in practice most system administrators will be too busy responding to issues to take much notice of these documents.

"You can get a security consultant to come in and look at your policies, and he can produce a high-level security assessment. The snag is that problems don't occur at a high level, and in any case the admin who looks after your Web server will probably never see the consultant's work. The real problem is that these consultants never actually touch metal: You'll still have machines with passwords like PASSWORD," Chuvakin said. On top of that, "the consultant will probably come in with a laptop that's been infected with viruses anyway," he added for good measure.

He is equally scathing about people who come in to an organization to conduct risk assessments. "These people rarely have an idea what they are talking about," he said. "What's important is the action you take to reduce risks."

So what advice does Chuvakin have for organizationals to help them avoid his security chasm? Three maxims sum up his philosophy:

  • Use compliance to drive security, don't just whine about it
  • Never conceptualize about security without actually doing anything
  • Start to close the security chasm by connecting mission with "metal"

His final piece of advice is practical in the extreme: "Go out and practice incident response!"

Paul Rubens is a journalist based in Marlow on Thames, England. He has been programming, tinkering and generally sitting in front of computer screens since his first encounter with a DEC PDP-11 in 1979.

Follow ServerWatch on Twitter

This article was originally published on Tuesday Aug 24th 2010
Mobile Site | Full Site