How many security frameworks or compliance standards does IT need? If you ask compliance professionals, the answer would be, “Oh, just one more.” If you ask any IT professional, the most likely answer would be, “Oh gosh, not one more!” And yet organizations have been inundated with compliance standards; and it’s not always clear how well they comply or how good their internal processes are when stacked up against industry-wide accepted standards.
In general, security standards all attempt to do very similar things. Namely, wrapping some sort of structure around processes and helping to define a baseline posture. Some standards take a general and all-encompassing road, while others attempt to focus on a particular technical area or business sector. Because of this, a natural and significant overlap emerges.
Security standards all attempt to do very similar things … Because of this, a natural and significant overlap emerges
For example, take asset inventory recommendations. Many standards have a section devoted to inventory management, which has been well documented by experienced professionals as a key first step in assessing risk. NIST 800-53 defines some of this in section CM-8, CSC in CSC-1, the NIST Cybersecurity Framework (CSF) uses ID.AM-1, and so on. In fact, the overlap is so common that CSF includes a whole section devoted to which standards each of its controls map to.
The overlap may seem initially like a weakness, but quickly proves to be the opposite. If you look at the overlap as redundancy-not-wastefulness the strength of this overlap comes into focus. The redundant items across standards begin to take on the tone of a common language, and from there the small differences between industries or departments become manageable edge cases and outliers.
Compliance standards and Tenable audit files
The majority of the Nessus® compliance audit files and the checks within can be traced directly back to a benchmark or other source document such as a DISA STIG (Defense Information Systems Agency, Security Technical Implementation Guide) or CIS (Center for Internet Security) guide. These source documents lay out the items that should be tested and the specific values that have been deemed acceptable. These source documents didn’t just appear out of nowhere; in most cases, they grew from an attempt to turn the general structures in one (or more) of the security standards into actionable items.
For example, here’s a check from the CIS Windows 7 Configuration Benchmark:
1.1.1 Enforce password history
which in turn maps directly to NIST 800-53 control IA-5, PCI-DSS item 8.2.5 and CSF section PR.AC-1 and many others as you can see in the example below. There are countless such examples throughout the audit files.
<custom_item>
type : PASSWORD_POLICY
description : "1.1.1 Ensure 'Enforce password history' is set to '24 or more password(s)'"
see_also : "https://ift.tt/2cHmEwR;
reference : "800-53|IA-5,HIPAA|164.308(a)(5)(ii)(D),PCI-DSSv3.1|8.2.5,800-171|3.5.10,800-171|3.5.7,800-171|3.5.8,800-171|3.5.9,CSF|PR.AC-1,ISO/IEC-27001|A.9.4.3"
value_type : POLICY_DWORD
value_data : [24..MAX]
password_policy : ENFORCE_PASSWORD_HISTORY
</custom_item>
Cross-references in Nessus audit files
Over the last few months, Tenable has invested time in adding extensive compliance cross-references across all the audit files, in both Nessus and SecurityCenter™. So for example, if you run a CIS Benchmark Compliance scan as part of your normal process, you will also be collecting information in relation to NIST 800-53, CIS CSC and ISO 27001 at the same time. All of these results are immediately available, attached to each check result when your scan has completed, and then you can run more specific SecurityCenter dashboards for the relevant standards.
Standards cross-referenced in Nessus audits
Currently, Tenable has also added cross-references to Nessus audits for many different standards, ranging from general ones like NIST 800-53 and ISO 27001 to industry-specific standards like NERC CIP. Keep in mind though, that not every audit item maps to every other standard. Only those items that are specifically related to a given control within a standard have been assigned a cross-reference.
Here’s a short list of standards for which cross-references have been added:
- NIST 800-53 – Security and Privacy Controls for Federal Information Systems and Organizations
- Payment Card Industry (PCI) Data Security Standard (DSS)
- NIST Framework for Improving Critical Infrastructure Cybersecurity (NIST CSF)
- CIS Critical Security Controls for Effective Cyber Defense v6.0
- ISO/IEC 27001:2013
- Health Insurance Portability and Accountability Act of 1996 (HIPAA)
- North American Electric Reliability Corporation Critical Infrastructure Protection (NERC-CIF)
- NIST 800-171 – Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations
Benefits to end users
Even if your specific environment is only concerned with one or two security standards, having the ability to communicate outward to partners or outside organizations will often pay dividends. The cross-reference enables you to communicate internally in terms that different audiences find useful. The cross-reference gives you the ability to speak in terms of PCI to compliance teams, NIST 800-53 to technical and security groups, and ISO 27001 to policy makers and executives.
Here’s a sample SecurityCenter NIST 800-53 Dashboard using the 800-53 cross-references:
Wrap-up
While working with standards isn’t likely to replace a good movie or book as your first choice for a lazy weekend, if we take a step back and forget all the times that standards have been misused as an insurmountable roadblock, you might see something interesting that can improve your security posture.
via https://ift.tt/2cEj4Cb