Crushed by compliance tyrants

It was a dark and stormy day. Tornadoes had touched down within 100 miles of the bank’s data center. The data center was at the top floor of a tall building. Phil Wherry, a consultant currently serving telecom and healthcare clients, had driven over to the bank that day—a few years ago—to do a gig as security auditor. Wherry got to the facility and started asking the IT people about disaster recovery. “I said, ‘You’ve got this nice data center up on top of this building—what do you do if a tornado takes the roof up?’ The guy said, ‘We have a backup facility in New Jersey. We have all the equipment necessary to failover bank operations,'” Wherry recalled. OK, Wherry thought. Not bad. “We test it annually,” the staffer said. OK, Wherry thought, You’ve done your homework. “One of these years we hope it works,” the bank employee concluded.

You can laugh, but you probably won’t if you’re one of the many security staffers throughout the land who are subject both to the whims of badly written regulatory compliance rules and to the tyrants—a.k.a. auditors—who have the power to enforce them, often at the expense of actually securing anything at all, as well as at the expense of security budgets that could actually secure something. [Also read: Your guide to good-enough compliance.]

In this case, there was an audit requirement that the bank—which Wherry declined to identify—have an annual failover test. Unfortunately, the requirement didn’t require the failover to succeed or that it had to be remediated if it failed. So that’s what the bank was doing: testing and hoping it would work. . .someday. [Also read: Compliance, convergence and how IT fits.]

In the security field, these are the people causing the most damage for CIOs: the “security and compliance people who have no real knowledge about what’s needed,” says Alan Paller, director of the SANS Institute.

The problem isn’t limited to failover tests that don’t require success. The problem also encompasses, for example, wasting money on purchasing consultants to write reports that collect dust on a shelf or other budget blunders, Paller says. “You take money out of the budget to buy a report that no one will read because some compliance guy says you have to,” he says.

The disconnect between regulations and security has even caught the attention of Capitol Hill. One example: Fisma (Federal Information Security Management Act) compliance is up. The Office of Management and Budget reported that in 2007, 92 percent of information systems were certified and accredited, 86 percent of agencies had a tested contingency plan and 95 percent had tested security controls. The appropriate response: something along the lines of “whoopty do.”

A panel of witnesses told a Senate subcommittee on March 12 that Fisma compliance isn’t translating into bolstered security, given the lack of consistent assessments of the effectiveness of the work being done, mounting data breaches and continuous system penetrations.

Dave Chronister is cofounder of Parameter Security, a firm of certified ethical hackers that hack companies to identify the pitfalls a penetration test can’t weed out. He says that the problem with the banking industry in particular is with the federally employed or state-employed regulators who come in to perform audits. At a bank worth $2 billion or less, those will typically be loan officers or security officers, Chronister says.

One of the problems banks run into, he says, is that such regulators look at the protection of the safe and the database upstairs as being “exactly the same.”

“The state will attempt to apply IT regulations onto the bank, and they’ll have an accountant come in and try to explain these,” Chronister says.

His war story: One banking client under the pressure of GLB (Gramm-Leach-Bliley) compliance had to log every single thing its data administrator did. Chronister told the client that it could simply audit its servers.

The examiner said no. Instead, the examiner said, the bank had to hire somebody to watch what the administrator did. Then an internal auditor had to verify that everything the administrator did every day was safe. A non-IT staffer, that is, looking over the shoulder of an IT professional and being responsible for ascertaining which of his actions were “safe”—constantly.

These are only a few horror stories. What are the workarounds?

Chronister says his firm has started educating the examiners themselves. They’ve even begun to educate IT departments and federal examiners and are trying to initiate training with governing bodies to explain how GLB works and how they should do their jobs.

Some are receptive; some just aren’t. “Some figure that after an 8-hour class on how all security works, they’re experts on it, so it sometimes gets tough,” Chronister says.

Kevin McDonald, executive vice president for managed services provider Alvaka Networks, a member of the national board of directors of the AeA (American Electronics Association) and author of several books on cybersecurity, says that the problem with auditors is that they come at it with “the purest defense of regulation.”

If an IT pro doesn’t actually understand the given regulation, he or she is “at the mercy of that auditor,” McDonald says.

However, the IT pro who knows the regulation inside and out can spout chapter and verse right back at an auditor. A security pro who arms himself with regulatory knowledge can actually argue against auditors’ over-reaching or unreasonable demands and hence can take up legitimate security concerns with management.

Taking up a conversation with management and curbing auditor idiocy is an art, however. “From a professional’s perspective, there’s no comparison,” McDonald says. “I walk in to [talk to a prospective client], and [a competing] provider throws around acronyms like HIPAA [Health Insurance Portability and Accountability Act] and Gramm-Leach, and the exec’s eyes glaze over.”

What works is turning a geek conversation about security into a business conversation, McDonald says. “If you say ‘Users want [a given technology],’ it doesn’t matter. It’s a direct violation of regulations if you do it simply for convenience. If you say ‘I must do it because I need to manufacture a missile,’ fine. [Regulatory literacy] makes it easy for me to argue against an employee that says ‘I want an iPod or a PDA or a network printer.'”

One last piece of advice comes from Anthony Scalzitti, a security engineer at a major security software company. When dealing with overzealous compliance personnel, Scalzitti encourages their enthusiasm and reminds them of the importance of due diligence. He then suggests that they interview other organizations of similar size to learn details of their security posture.

“Not only is this useful work but it gives them the opportunity to learn correct controls and later present them as their own,” Scalzitti says.

He suggests seeding the list with an organization or two that are known to be well-run. In other words, not those with un-backed-up data centers located in Tornado Alley.

Related reading:

• 7 compliance mistakes to avoid
• 5 biggest IT compliance headaches and how to address them
• The top 6 governance, risk and compliance (GRC) certifications
• 5 ways to reduce compliance costs with AI and automation