20 seconds to comply: Achieving security compliance at scale
October 22, 2020
When it comes to security compliance, there are a few key things to keep in mind. A good basis of quantitative metrics. Compliance checks. RoboCop. You know, the usual important cybersecurity stuff.
Back in dystopian 1997 compliance was easy thanks to OmniCorp, the folks that brought us RoboCop and the ED-209 compliance droid. If ED-209 was talking to you, there was one rule you were violating. It was probably obvious. All you had to do was drop what was in your hand within 20 seconds and all was good. Unless there was a system malfunction and then all bets were off. Unfortunately, compliance has since become a lot more complicated.
But in the real world of security compliance, it is really just a question of security compliance at scale. If we only had one regulation or one system to keep track of, life would be easier. The thought of compliance would not result in so many sleepless nights for IT and security staff the world over, not to mention boards, CEOs, CFOs – after all, compliance can be a headache for a lot of people. Just like in RoboCop, 20 seconds to comply may even have been enough time. But it’s not 1997, and that is far from reality.
The reality is there are many, many security regulations, policies, controls and systems to stay on top of. And even one dropped ball can result in problems that range from a slap on the wrist, to a major fine, to a data breach.
So, the question is: how do we keep so many balls in the air? And, how do we do it at scale?
Metrics are data-driven, measurable values that give you an objective view of something. Proper metrics can and should also be based on some sort of standard and devoid of any opinions. When used as a building block, good metrics can be a huge benefit when it comes to your quest for security compliance. Kind of like the instructions on the shampoo bottle. Lather, rinse, repeat. Only continuously.
Let’s look at an example.
Let’s say you had a corporate policy that all access for an employee needs to be disabled within 3 days of their employment ending. If you only employed 10 people, this would be relatively easy. Pretty much just eyeball your Active Directory and say, “Hey, why is Bob’s account still active, didn’t we let him go last week?”
But if Bob is (or was) one of 10,000 employees, or access is controlled by more than just Active Directory, things can be a little more challenging.
Let’s borrow an idea from NASA, or at least from a movie about NASA. Admittedly I have never actually been part of NASA, but I have seen The Martian. “Work the problem.” In the above example, what are we really trying to determine? Is a person’s account (e.g. in Active Directory) still active, greater than 72 hours from when human resources data shows the person’s employment status as not active? So…
Employment Status is NOT “Active”
Account Status is “Active”
Date is more than 72 hours from the Employment Status change
You are not compliant with that one policy for that one person.
When it comes down to it, you can reduce much of the compliance challenge to these basic “checks” and when you do that, it really makes scaling it up less challenging. It starts approaching the directions on the shampoo bottle. Gather data, calculate, repeat.
And this is what Panaseer and Continuous Controls Monitoring (CCM) does so well. Data science at scale.
Enter: Continuous Controls Monitoring
One of the basic building blocks of Continuous Controls Monitoring is the concept of a Control Check for compliance needs. These checks are built around data points from everything including people, accounts, devices, vulnerabilities, patches, time and more. They facilitate automatic auditing of a wide range of policies, from something like the active leavers case described earlier, to things like the remediation of critical vulnerabilities on critical systems within established SLAs. And that is really just the start of it.
Remember, we started by breaking a complex challenge into smaller components as we worked the problem. Now let’s go the other way. As you develop your security compliance at scale, these simple checks can be combined into more complex scenarios.
Example: you have a policy that says devices with open, known vulnerabilities must have mitigating controls in place. The compliance check, in that case, might be a combination of checks, i.e. “is there a DEVICE with an OPEN vulnerability that has a status of CRITICAL, AND is that device missing AV”? That toxic combination may be what violates the policy.
That’s the beauty of building blocks, you can actually build stuff with them.
Ok, so what about maintaining compliance with a framework or a regulation? Again, work the problem. By breaking down the rule you can identify the basic blocks.
From NIST we may see something like:
‘The organization, upon termination of individual employment:
a. Disables information system access within [Assignment: organization-defined time period];’
This may look familiar. It was the active leaver example from earlier. And that is really the point. Reduce the regulation to a simple check, gather the data, calculate, repeat. Compliance becomes a lot less challenging.
New capability: Continuous Controls Monitoring for Risk and Compliance
This brings us round to our new capability, which aims to provide this kind of support for security, risk, audit and compliance teams – enabling them to achieve security compliance at scale.
Users can rely on automated, data-backed, quantitative assessment versus subjective opinions to conduct audits, assess internal policy compliance, and substantiate regulatory compliance. Historical time-stamped data that is held in perpetuity allows them to do so for any given time-frame on any given device. The capability also allows users to configure the measurement criteria to reflect their internal policies and standards, tailoring measurements to individual organizations.
For more about the new capability, take a look at our Continuous Controls Monitoring for Risk and Compliance Overview.