[ad_1]
(By Andy Green, August 2017) Did you know that the 462-page NIST 800-53 data security standard has 206 controls with over 400 sub-controls1? And as aside, you can check out the convenient XML-formatted version here. PCI DSS is no slouch either with hundreds of sub-controls in its requirements’ document. And then there’s the sprawling IS0 27001 data standard.
Let’s not forget about security frameworks, such as COBIT and NIST CSF, which are kind of meta-standards that map into other security controls. As well as whatever your local regulations require. Together there is enough technical and legal complexity within to keep teams of IT security pros, the legal fraternity, auditors, and diplomats busy till the end of time.
As a security blogger, I’ve also puzzled and pondered over the aforementioned standards and regulations. I’m not the first to notice the obvious: data security standards fall into patterns that make them all very similar.
Security Control Connections
If you’ve mastered and implemented one, then very likely you’re compliant to others as well. In fact, that’s one good reason for having frameworks. For example, with, say NIST CSF, you can leverage your investment in ISO 27001 or ISA 62443 through their cross-mapped control matrix (below).
Got ISO 27001? Then you’re compliant with NIST CSF!
I think we can all agree that most organizations will find it impossible to implement all the controls in a typical data standard with the same degree of attention— when was last time you checked the physical access audit logs to your data transmission assets (NIST 800-53, PE-3b)?
So to make it easier for companies and the humans that work there, some of the standards group have issued further guidelines that break the huge list of controls into more achievable goals.
The PCI group has a prioritized approach to dealing with their DSS—they have six practical milestones that are broken into a smaller subset of relevant controls. They also have a best practices guide that views — and this is important — security controls into three broader functional areas: assessment, remediation, and monitoring.
In fact, we (Varonis) wrote a white paper explaining these best practices ,and how you should be feeding back the results of monitoring into the next round of assessments. In short: you’re always in a security process.
NIST CSF, which itself is a pared down version of NIST 800-53, also has a similar breakdown of its controls into broader categories, including identification, protection, and detection. If you look more closely at the CSF identification controls, which mostly involve inventorying your IT data assets and systems, you’ll see that the main goal in this area is to evaluate or assess the security risks of the assets that you’ve collected.
File-Oriented Risk Assessments
In my mind, the trio of assess, protect, and monitor is a good way to organize and view just about any data security standard.
In dealing with these data standards, organizations can also take a practical short-cut through these controls based on what we know about the kinds of threats appearing in the our world — and not the one that data standards authors were facing when they wrote the controls!
We’re now in a new era of stealthy attackers who enter systems undetected, often though phish mails, leveraging previously stolen credentials, or zero-day vulnerabilities. Once inside, they can fly under the monitoring radar with malware-free techniques, find monetizable data, and then remove or exfiltrate it.
Of course it’s important to assess, protect and monitor network infrastructure, but these new attack techniques suggest that the focus should be inside the organisation.
And we’re back to a favorite IOS blog theme. You should really be making it much harder for hackers to find the valuable data — like credit card or account numbers, corporate IP — in your file systems, and detect and stop the attackers as soon as possible.
Therefore, when looking at the how to apply typical data security controls, don’t forget file systems!
For, say, NIST 800.53, that means scanning file systems, looking for sensitive data, examining the ALCs or permissions and then assessing the risks (CM-8, RA-2,RA-3). For remediation or protection, this would involve reorganizing Active Directory groups and resetting ACLs to be more exclusive (AC-6). For detection, you’ll want to watch for unusual file system accesses that likely indicate hackers borrowing employee credentials (SI-4).
I think the most important point is not view these data standards as just an enormous list of disconnected controls, but instead to consider them in the context of assess-protect-monitor, and then apply them to your file systems.
I’ll have more to say on a data or file-focused view of data security controls in the coming weeks.
1 How did I know that NIST 800-53 has over 400 sub-controls? I took the XML file and ran this amazing two lines of PowerShell:
[xml]$books = Get-Content 800-53-controls.xml
$books.controls.control|%{$_.statement.statement.number}| measure -line
[ad_2]