Cybersecurity teams are subject to a complicated web of compliance and regulatory frameworks.
These aim to ensure organizations implement appropriate security controls… but they present a significant challenge. Each framework has slightly different recommendations and priorities, forcing teams to expend a huge amount of effort to keep track of and enforce their requirements. But that’s not the only problem.
The “Special Snowflake” Approach to Compliance
What makes a compliance framework difficult to implement? While there are several factors, perhaps the most significant is that most frameworks take a descriptive approach—they tell organizations what to achieve but not how to achieve it.
Tony Sager, SVP and Chief Evangelist at The Center for Internet Security (CIS) explains:
"Compliance requirements are what I call cosmic frameworks. They proclaim ‘thou shalt achieve this,’ but aren’t prescriptive about how to do that. It creates an industry of tea leaf readers trying to interpret requirements, which is great for job security but very poor for business outcomes."
Tony explains that this approach creates a ‘special snowflake’ approach that forces each organization to find its own solution to each requirement. This alone creates a huge amount of work for cybersecurity teams, reducing the resources available to protect against threats.
The vague nature of requirements creates a ‘Wild West’ approach to cybersecurity, where thousands of vendors spring up to fill organizations’ perceived security and compliance needs—which are often contrary to the simple objective of minimizing the frequency, severity, and duration of breaches.
Prescriptive Controls in Action
While there are undeniable differences between organizations, most are more similar than they are different. While descriptive frameworks make sense on paper, prescriptive frameworks that actually tell organizations what to do are far easier to implement—and more effective. The first of these prescriptive frameworks was developed on behalf of the NSA.
In 2001, the NSA released its security guides into the public domain, prompted by several high-profile breaches of its commercial partners. The boundaries between government agencies and their partners were disappearing, and there was a pressing need to help those partners ensure the security and integrity of government data.
There was a problem, though. The NSA guides were extremely thorough and provided far more guidance than a partner organization could implement in a short period. Further guidance was available from organizations like NIST, but this had the same challenge—too many controls, and too little time.
This resulted in a conversation at the NSA—led by lifelong NSA security expert Tony Sager—about producing a small, prioritized list of essential security controls. After many additions and several changes of ownership, this list became the CIS Controls, a list of just 18 best practice controls.
Unlike typical descriptive frameworks, the CIS Controls take a prescriptive approach, telling organizations exactly what to do to protect against pervasive cyber threats. To give an idea of their effectiveness, several independent studies of version 6.1 of the CIS Controls found that just the first five controls protected against 85% of all cyber attacks.
Today, the first five controls are:
- Inventory and Control of Enterprise Assets
- Inventory and Control of Software Assets
- Data Protection
- Secure Configuration of Enterprise Assets and Software
- Account Management
At a basic level, these controls require an organization to establish a continually updated baseline for hardware, software, data, user accounts, and asset configuration—and then track and remediate changes from that baseline.
Contributing to that baseline, CIS also maintains the CIS Benchmarks, a set of 140+ configuration guides to help organizations establish hardened systems to protect against evolving cyber threats. In line with ITIL’s service design principle, the Benchmarks provide a baseline for the asset configuration.
If the baseline remains current, it’s easy to identify activity that isn’t acceptable—i.e., unauthorized changes that negatively affect configuration—and block it at the source.
System Integrity Assurance
How do you establish and enforce a trusted baseline from which to track and remediate changes?
System integrity assurance is a completely different approach to cybersecurity that focuses on the fundamentals. Instead of trying to identify and categorize all bad things, it instead identifies everything that is allowed in an environment and uses that information to establish a trusted baseline. If something happens that isn’t included in the baseline, it gets blocked at the source.
Some level of management by exception is needed, of course. But fundamentally, system integrity assurance gives organizations complete control over what happens in their environment.
This begs another question:
What happens if you know every time something is added, removed, or changed in your environment, and you stop anything that isn’t authorized… and you expand this capability across all asset classes?
- Ransomware and other malware can’t run in the environment.
- Attackers can’t traverse the network or exfiltrate data.
- Nobody can change files or configurations to make them dangerous or non-compliant.
- Users can’t accidentally run malicious attachments.
- Nobody (even privileged administrators) can alter critical system files.
This approach takes away a massive proportion of the threats that can arise in an IT environment with minimal human involvement.
To find out exactly how system integrity assurance addresses the major issues in cybersecurity, download the Authoritative Guide to System Integrity Assurance.
