Take a deep, cleansing breath, and say it with me: “Compliance is not security.”
Good. One more time. “Compliance is not security.”
It’s okay. We’re all friends here. No need for false pretenses. We all know how much truth is contained in those four simple words.
Information Security is a tricky business, due largely in part to the fact that both the good guys and the bad guys are an innovative, creative, and (sometimes) devious bunch.
A compliant organization can demonstrate that they have implemented the bare minimum in information security controls. That, or they can sweet talk an auditor into believing that the “compensating controls” are strong enough to meet the intent of the compliance requirement.
Not that it matters, though, since compliance is not security.
You protect your servers with a locked door. I bypass the lock with a lock pick (or a modified hotel keycard, or a coat hanger, or… you get the point). So what do you do? You replace the pin and tumbler lock with something stronger.
Well, shucks. I guess I’m out of luck. Time to throw in the towel (said no determined criminal EVER).
You install a stronger lock, I adapt with a stronger (more devious) attack. Motion and heat sensors? No problem. I’ll just use a Mylar balloon, a warm washcloth, and a little bit of helium (props to Chris Nickerson).
Let’s shift gears and talk about more technical controls. You patch your operating systems? Fine. I’ll target the desktop applications. You keep those patched, too? Well, smell you! Sounds like your web apps might be my best bet, except that your security-minded developers test both their code and their deployed apps for vulnerabilities.
Fine. It looks like you’ve decided to give me a run for my money. I guess I’ll have to resort to (gasp) SOCIAL ENGINEERING.
If I want in… if I really want to deface the website / steal the data / encrypt all the things and then extort payment… then compliance isn’t going to stop me.
Security, though… that’s another matter.
It is absolutely possible (even probable) that a security-minded organization, one that chooses to go above and beyond compliance, will know when they’re being attacked and be able to prevent, detect, and respond to the attack in a manner that minimizes the damage.
So how do we get from here to there? The answer has been right in front of us the entire time: assessments.
Notice I said assessments (plural).
Attackers are going to look at your business, your customers, your employees, your locations, and your infrastructure from multiple perspectives. They’ll keep at it until they find the chink in your armor.
In order to effectively (and proactively) defend against those attacks, you should be doing the following:
- Compliance Assessment(s). Wait a minute. I JUST said that compliance is not security. I also said that compliance is the bare minimum. Love ’em or hate ’em, compliance requirements like PCI, HIPAA, and NERC/CIP are based on leading information security practices. If you want a good baseline for how prepared you are to defend against attackers who want your data, start with a compliance assessment.
- Security Controls Assessment. The next assessment you should perform is a security controls assessment based on the security framework that your organization aligns with. NIST (FISMA) is popular among companies who do business with the U.S. Federal Government, while the ISO 27000 series works well for organizations with an international footprint. The CIS Critical Security Controls are another fan favorite, although smaller organizations may find the Common Sense Security Framework a little easier to tackle.
- Risk Assessment. These assessments are a little trickier. The goal of a risk assessment is to identify potential threats to your organization, to determine how likely it is that those attackers could do damage, and how bad would it be if they were successful. Risk assessments can cover everything from the physical safety of your employees to the mobile apps you have in iTunes and Google Play.
- Vulnerability Assessments / Penetration Tests. This is where the rubber meets the road. By the time you get to these assessments, you should have a decent understanding of where you’re most exposed (and where an attacker could do the most damage). Vulnerability Assessments help you validate that all your technical controls are working as intended (e.g., your patch management solution is really patching your Internet-facing servers).Penetration Tests allow authorized (ethical) attackers to test your defenses and identify gaps that have gone unnoticed by your security team (and, hopefully, by your attackers).
If you’re doing all of these assessments on a regular basis, then the bad guys are going to have a HELLUVA time getting what they’re after. If you’re skipping any of these assessments, then you have a blind spot, one that criminals won’t hesitate to exploit.
Depending on your organization’s business model, a Privacy Assessment might also be on the table, but that’s an article for another day.
Once you find an assessment process and schedule that works for your organization, turn your attention to automation. There’s no reason to exhaust your people (and your budget) with manual processes that can be replaced by a very small shell script.
Don’t automate everything, though, ESPECIALLY the pen test. If you think automated pen tests are sufficient, then it’s only a matter of time before your organization ends up on a list of publicly disclosed data breaches.
The short version: assess all the things! Your employees, your customers, and your shareholders will thank you for it.
