Compliance is a joke. Seriously. Its definition has gotten so skewed that compliance can mean just about anything to anyone, depending on the circumstances that happen to be in their favor. Even with all the evidence of the complexities involved with compliance today, I still hear people say things like, "We have a secure network, so we're compliant." Or, "Our auditor checked things over and we're compliant." Or, in the case of many physicians' practices, one of my favorites: "We give a notice of privacy practices to all patients who come see us, so we're compliant." Compliant? Compliant with what? Their own made-up concept of what reasonable privacy and security should be?
I have friends, colleagues and clients who are of the mind-set that some basic documentation, strong passwords and a firewall make them compliant with whatever law or regulation you ask them about. Interestingly, in my work performing security assessments -- which are almost always driven by regulatory compliance -- I see a different story. By and large, there are a lot of compliance officers, security managers and sometimes -- in the case of small and medium-sized businesses -- network administrators who focus most, if not all, of their efforts on the operational "soft" side of security and privacy, completely overlooking the technical issues at hand. They say they're compliant, but the devil's in the details.
Here are some things to keep in mind about compliance:
A compliance officer is not enough. As with a chief information officer, chief technology officer or CEO, just because the person's in the compliance officer position doesn't mean he or she is fit for the job. Compliance requires both business and technical expertise, with a whole lot of people savvy sprinkled in between.
A policy manual is not enough. It's easy to download policy templates off the Internet, fill in the blanks and assume that's enough to please the auditors and regulators. The reality is talk is cheap. It's one thing to say you're doing something but quite another to actually have a set of controls and processes that make things work the way they're supposed to.
Trusting what IT or development says is not enough. A colleague of mine earns his living performing compliance assessments, and not a single one of them involves technical vulnerability assessments. Sometimes, he'll run a high-level auditing tool that does minimal operating system version checking and port scanning, but most of the time, he tells me, he just relies on the security scans that a network admin or developer has run against the network or Web application. They're often outdated and of minimal depth. Talk about the fox guarding the henhouse. Third-party validation (be it in-house or through a consultant or security firm) really needs to be done.
Security scans are not enough. There's no doubt that running a quality vulnerability scanner such as QualysGuard against your operating systems or Acunetix Web Vulnerability Scanner against your Web applications is vital. As good as tools like these are, you still have to take your security vulnerability scanning results with a grain of salt. A monkey could be taught to run most scans. It's what you do with the results (i.e., filter the false positives and focus on what matters in the context of your business) that's going to make the difference. Furthermore, scans don't tell the whole story. Manual analysis using ethical hacking techniques easily makes up 40% to 50% of your overall security testing. Doing both scans and manual analysis is the only way you're going to find all the things that matter.
A secure network architecture is not enough. You can have the most well-designed network with fancy firewalls separating the LAN segments, a demilitarized zone for your Internet-facing systems, virtual LANs scattered about and so on, but bad things can still happen. Internal users still, almost always, have unfettered access to your network and sensitive information they shouldn't be getting into. They also have unprotected laptops and smartphones that are likely exposing sensitive "regulated" information this very minute. Take a look at the publicized data breaches. It's your internal users you've got to worry about -- something a strong network is not going to do much for.
 |
|
|
|
|
[The definition of compliance] has gotten so skewed that compliance can mean just
about anything to anyone, depending
on the circumstances that happen to be in their favor.
|
|
|
|
|
|
|
|
|
|
Passwords aren't enough. There are a lot of assumptions about passwords that get people into trouble. The general consensus I've seen is that as long as passwords are required, then the sensitive information behind the login mechanism is safe. This is a dangerous mind-set that can create a false sense of security with your operating systems, Web applications and especially the security of your laptop computers and mobile devices. Not good for compliance.
Certificates and products are not enough. I see a lot of organizations claim that their data center is SAS 70 Type II compliant, therefore they're secure. Likewise with all these compliance management products. The assumption is compliance can be bought. It really can't. Compliance does not come in a box, nor does it come in an annual report. It comes from the top in the form of leadership, culture and support for doing what's right.
Past processes aren't enough. Sure, patches may have been applied recently, backups have probably been kicked off, and security scans were run not too long ago, but what are you doing on a periodic and consistent basis that's going to keep sensitive information protected today, tomorrow and beyond? Compliance is not a one-time deal.
Doing an assessment or a higher-level gap analysis against any of the current laws and regulations may not uncover much, and things may look quite rosy now. But you probably haven't looked hard enough. You have to dig deeper into your operations and systems to truly find out where you stand.
I'm not trying to be a pessimist. Nor am I trying to spread fear, uncertainty and doubt to create work. I'm just calling it like it is. I don't like government and industry intrusion into how we do business any more than the other guy. But it's here and something we've got to deal with in the right way.
Bottom line: Be careful claiming compliance when you haven't looked at the whole picture. Don't fall for the compliance by checklist or the compliant-now-equals-compliant-always misconceptions. They'll surely come back to bite you. The reality of it all may be quite different than how you see it from your perspective. It may not matter for now, and it may not matter for a while. But the truth will come out when someone such as a customer, business partner or concerned employee questions your compliance status, or worse: once a breach occurs.
Kevin Beaver is an information security consultant and expert witness, as well as a seminar leader and keynote speaker at Atlanta-based Principle Logic LLC. He can be reached at www.principlelogic.com.
