My 9-year-old son likes baseball. But during the winter, with cold temperatures and snow on the ground, playing outside is not an option.
So, I move the cars into the driveway, and we play in the garage. Granted, it’s not Fenway — the two rakes hanging against the back wall are our proxy for the “Green Monster” — but it keeps him active and we have a lot of fun.
The other day, when we were done playing, we hopped into the car so I could pull it back inside. I was about to hit the gas when my son said, “Wait dad, we need to put our seat belts on!”
“Seatbelts?” I said. “When I was your age, your uncle and I drove halfway across the country in the backseat of our parents’ car. Not only did we not wear seatbelts, when we got tired, they put the seats all the way back and we slept with our feet in the trunk. You and I are only going 10 feet into the garage here.”
Unfortunately, nuance is not high on the list of fourth grade skills. So, I put my belt on and we began our journey.
Compliance is Not the Same as Security
My son would make a fine compliance officer: This is the rule, it applies in all situations.
And while this type of blanket approach certainly simplifies things from both a policy and enforcement perspective, as a practical matter, using it as a blunt instrument in this way can burn precious resources without making anybody any safer.
Consider the example of DLP (Data Loss Prevention). Some of our clients have been pushed to adopt these tools in order to sign a contract with a (typically much larger) client. DLP makes sense if you are processing credit card transactions or handling social security numbers. But if your company doesn’t deal with either of these things, most of the DLP recommendations would not even make it onto our top 10 list from a security perspective.
And it’s more than just wasted time and money. Resources spent on lower priority risks endangers the security program overall, by lessening your ability to apply those same scarce resources on more important controls.
Because compliance and security are managed by the same internal groups of people, there is a tendency to lump them together. But they are not the same thing. At best, compliance is 70% aligned with security. At worst, it might be 40%, at which point a particular compliance regime can become a blueprint for wasting resources.
How to Choose a Compliance Framework
Am I opposed to compliance? Absolutely not.
Certain activities — internal audits, for example, in which system access is reviewed on an individual basis — are super valuable from a security perspective. Further, compliance can be useful in prompting a company to take certain security steps that they might otherwise avoid absent an audit or prospect request.
But choosing a framework needs to be done with eyes open. Here are some things to consider:
#1. Is it risk-based?
Risk-based compliance means differentiating among activities and assets and applying varying degrees of scrutiny based on those differences. Spend more on X and less on Y.
Wearing a seatbelt when pulling your car into the garage is a waste of effort; wearing one when you’re going 75 miles an hour on the highway isn’t. By the same token, it makes sense to have a much higher bar for the security of your internal network than for your marketing web server, which contains no customer data and is not connected to the rest of your organization.
One drawback of a risk-based approach is worth noting, however. Because it involves judgement, there exists the potential for inattentive auditors to allow things to happen that probably shouldn’t.
#2. Does it align with industry expectations?
Every industry and market has certain norms, some of which apply to compliance standards. For example, if many of your customers are in healthcare, HIPAA is the price of admission.
With that in mind, it’s in your best interest to adopt the standards that those in your industry live by. After all, part of the reason for requiring certain standards in the first place is that it’s a shortcut for companies hiring vendors — if I know you comply with standard X, I don’t have to evaluate your procedures on an item-by-item basis.
The point is, it’s to your detriment to go your own way without a good reason.
#3. Does what I am being asked to do make sense?
Often, we take part in conversations with our clients’ prospective customers or auditors in which we push back on compliance requests that make little business sense (e.g., anti-virus software on AWS EC2 servers). We come in and say “Let’s do this instead,” or “That doesn’t really make sense and here’s why.”
This type of pushback is critical — you need to make sure you are not committing to something you can’t match. And even if you can, you may end up with a product roadmap filled with things of mediocre value in the marketplace, as well as spending money that you could have invested elsewhere.
Might you lose a potential customer? Absolutely. But blindly saying yes to compliance requests can have much more serious ramifications for your overall business and profitability.
Final Thoughts
Is it possible to be injured while pulling your car into the garage? Yes. Could wearing a seatbelt in that situation reduce your chances of injury? It’s not out of the question.
But those aren’t really the right questions to ask.
In a world of limited resources, anticipated safety gains — whether in your car or in your business — need to be balanced against the opportunity cost of not spending time, money, or attention elsewhere on things which are potentially more likely and more dangerous.
Gotta run, our next garage baseball game starts in a few minutes. (I wonder if I need to wear a batting helmet?)
Want to get great cybersecurity content delivered to your inbox? Click here to sign up for our monthly newsletter, Tales from the Click.
