Did you know that the 462-page NIST 800-53 data security standard has 206 controls with over 400 sub-controls1? By the way, you can gaze upon 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. For organizations in health or finance that are subject to US federal data security rules, HIPAA and GLBA’s data regulations need to be considered as well. And if you’re involved in the EU market, there’s GDPR; in Canada, it’s PIPEDA; in the Philippines, it’s this, etc., etc.
Get the Free Essential Guide to US Data Protection Compliance and Regulations
There’s enough technical and legal complexity out there to keep teams of IT security pros, privacy attorneys, 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).
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 wrote a fascinating 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 assessing, protecting, and monitoring 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 shortcut through these controls based on what we know about the kinds of threats appearing in our world — and not the ones 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 through 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 company.
And we’re back to a favorite IOS blog theme. You should really be making it much harder for hackers to find 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 how to apply typical data security controls, think 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 to 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 these amazing two lines of PowerShell:
[xml]$books = Get-Content 800-53-controls.xml
$books.controls.control|%{$_.statement.statement.number}| measure -line
