Risk // Compliance
5/7/2012
02:46 PM
Connect Directly
RSS
E-Mail
50%
50%
Repost This

10 Symptoms Of Check-Box Compliance

These telltale signs show you care more about what the auditors think than what the attackers do

Security and risk pundits have long lamented the practice of going through the motions just to satisfy security regulations and standards like PCI, SOX, and HIPAA. Phoning it in may keep the auditors in check, but it won't mitigate the risks of attack. According to security and compliance pundits, the following are some of the telltale signs an organization is falling into the trap of check-box compliance.

1. Arguing over which standards are best.
Check-box-oriented organizations tend to get caught up in the regulatory minutiae so that they can't see the forest for the trees.

"Some organizations claim that they take the best of various policies and then go to work on a 'deeper policy,'" says Ron Gula, CEO and CTO of Tenable Network Security. "However, if you look closer at these sorts of things, they often target the union of various compliance standards and not the aggregation of all checks."

2. Losing sleep over an audit.
"If you are losing sleep about passing an upcoming security audit, you've got the check-box compliance disease -- and it's probably rampant in your organization," says Lamar Bailey, director of security research and development for nCircle.

As he puts it, security standards are the point of embarkation for the risk-management journey. They're not meant to be the end-all, be-all for securing an organization. They just get you started. Organizations that have a hard time even satisfying these beginner requirements should lose sleep over how insecure their systems are, not whether the auditor will break out a rubber stamp.

"These standards are like training missions in video games: They can help you acclimate, but they in no way represent the real game," Bailey says. "If you can't pass them with two hands tied behind your back, your need to quit and find another game."

[ Staying out of the checkbox compliance mentality is hard work. Recent studies show organizations are struggling to keep up with GRC See Risk And Regulatory Overload. ]

3. Putting line-of-business managers through spreadsheet hell.
If you make line-of-business managers fill in voluminous review forms, your organization is probably on the compliance-for-compliance-sake bandwagon, says Jason Garbis, vice president of marketing for Aveksa.

"Many times, enterprises approach access compliance by manually creating and emailing large, complex, and unwieldy spreadsheets," Garbis says. "If you're asking line-of-business managers to review a jargon-filled spreadsheet with hundreds of rows, chances are that this is a check-box review."

4. Viewing penetration testing as a panacea.
With so many compliance regulations requiring a penetration test, unsophisticated organizations seeking to cover only their bases view pen testing as an all-purpose security curative. If you're an organization that seeks to use pen testing instead of monitoring or vulnerability management, odds are you suffer from check-box compliance.

"If a company wanted to do the bare minimum, they could hire unsophisticated penetration testers and, when they don’t break in, claim 100 percent security," Gula says. "Of course, this type of penetration test is not a substitute for a full audit."

5. Using tools geared for forensics rather than prevention.
Unduly focusing on monitoring tools for the sake of establishing audit trails, without ever thinking about attack prevention, is a strong signal that your organization has its head so far in the regulations that it has forgotten the reason they're there in the first place.

"Most compliance regulations do not have security enforcement restrictions; they mainly focus on monitoring," says David Maman, CTO of GreenSQL. "Having a monitoring system instead of a prevention system is a modern take on closing the barn door after the cows have gotten out."

Next Page: Confusing logging and log storage with monitoring.

Previous
1 of 2
Next
Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-3946
Published: 2014-04-24
Cisco IOS before 15.3(2)S allows remote attackers to bypass interface ACL restrictions in opportunistic circumstances by sending IPv6 packets in an unspecified scenario in which expected packet drops do not occur for "a small percentage" of the packets, aka Bug ID CSCty73682.

CVE-2012-5723
Published: 2014-04-24
Cisco ASR 1000 devices with software before 3.8S, when BDI routing is enabled, allow remote attackers to cause a denial of service (device reload) via crafted (1) broadcast or (2) multicast ICMP packets with fragmentation, aka Bug ID CSCub55948.

CVE-2013-6738
Published: 2014-04-24
Cross-site scripting (XSS) vulnerability in IBM SmartCloud Analytics Log Analysis 1.1 and 1.2 before 1.2.0.0-CSI-SCALA-IF0003 allows remote attackers to inject arbitrary web script or HTML via an invalid query parameter in a response from an OAuth authorization endpoint.

CVE-2014-0188
Published: 2014-04-24
The openshift-origin-broker in Red Hat OpenShift Enterprise 2.0.5, 1.2.7, and earlier does not properly handle authentication requests from the remote-user auth plugin, which allows remote attackers to bypass authentication and impersonate arbitrary users via the X-Remote-User header in a request to...

CVE-2014-2391
Published: 2014-04-24
The password recovery service in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 makes an improper decision about the sensitivity of a string representing a previously used but currently invalid password, which allows remote attackers to obtain potent...

Best of the Web