Most practitioners in the security space are, by now, quite familiar with the NIST Cybersecurity Framework. One...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
of the primary reasons why it is so compelling for practitioners is that it provides a lingua franca for security activities; meaning, it serves as a way to normalize security discussions regardless of the specific regulatory, compliance or risk drivers that an organization might have. This enables an open and direct dialog between teams, companies and industries.
Regardless of the type of organization or its mission, the activities, countermeasures, responsibilities and objectives associated with ensuring a robust security posture can be generalized and discussed using the vocabulary of the NIST Cybersecurity Framework (CSF). This, in turn, makes the management of security more streamlined and easier to affect, and enables better information sharing.
One of the initial criticisms of the cybersecurity framework, when it was released in February 2014, was that it was not sufficiently specific about cloud environments. Since then, additional documentation has been furnished by cloud providers that helps not only address ambiguities about the use of the CSF in the cloud, but also, for the savvy practitioner, can serve as a convenient shortcut -- a shortcut to cloud security efforts generally, but also to compliance, assessment and ongoing due diligence efforts for the cloud.
Specifically, major cloud service providers have taken steps to align their offerings to the CSF. While the specific mechanisms for communicating this information vary by provider, the contents can be of direct value to customers. With that in mind, let's look at a few of the specific artifacts created and published by providers in detail and, from there, discuss how they can be used for cloud security efforts.
Cloud provider support for CSF
Amazon published a whitepaper in May 2017 entitled, "Aligning to the NIST CSF in the AWS Cloud." It's a short, concise breakdown of the features built into Amazon Web Services (AWS), aligned to each of the five CSF domains. The document goes area-by-area through each of the CSF domains -- Identify, Protect, Detect, Respond and Recover -- and correlates Amazon features and functions to each.
For example, within the Detect section, Amazon includes its simple notification service, access logs -- for example, from Amazon Simple Storage Service -- database logs, Redshift, Elastic MapReduce and other features that support detection. Included in this breakdown are not only tools that directly support logging and analytics, but also others that facilitate visualization or otherwise enhance the ability of a customer to detect threats.
Other areas of the CSF are likewise addressed within the report. It also includes independent attestation from Coalfire that the mappings provided "... demonstrated the alignment of its adherence to the NIST CSF ..." In other words, this report provides a roadmap of the AWS feature set through the lens of the CSF.
For the Azure platform, Microsoft has likewise -- in July 2017 -- published a series of documents, each one mapped to one of the NIST CSF domains. For example, the document "Using Microsoft Azure to Enables NIST CSF Compliance: Recover Function" outlines specific guidance related to using the Azure platform to accomplish recovery goals. Presented in a more narrative format compared to the report from Amazon, the document likewise outlines features available on the Azure platform that support the intent of the CSF.
Microsoft's documentation also discusses areas of shared responsibility between the customer and the service provider, which are areas where customers need to take action to accomplish their goals. These documents, available via the Documents section of the Microsoft Service Trust Portal, include an independent attestation from Kratos Defense of Azure's alignment with the NIST CSF.
Supporting your program with this documentation
The next logical question for practitioners is how they can employ this documentation to make life easier for them. There are a few ways that this can happen, but the first and probably most obvious way is to leverage the mapping between the Informative References, which is in the right-most column of the Framework Core.
Because each of the categories and subcategories within the NIST Cybersecurity Framework is correlated directly to highly visible external references -- such as ISO/IEC 27001:2013, NIST SP 800-53 and COBIT 5 -- a roadmap from the service providers that indexes service features across this spectrum can help directly facilitate compliance activities.
As a consequence of the way in which the CSF is structured, there exists -- for pretty much any regulation -- a mapping or crosswalk between these informative references and any other regulation an organization might have in scope. Often, these are made available directly from regulators themselves.
For example, in February of 2016, the U.S. Department of Health and Human Services -- via the Office for Civil Rights -- published the "HIPAA Security Rule Crosswalk to NIST Cybersecurity Framework." So, if you're a covered entity under HIPAA, you now -- by using these documents in tandem -- have not only a direct mapping to the CSF from HIPAA, and thereby an indirect one to a number of other references, guidance and standards, but you also now have a direct path between services the cloud providers offer and your organization's HIPAA compliance via the documentation from the cloud providers.
This is certainly valuable for compliance activities, but a practically minded security professional might have less use for this than an audit, assurance or compliance-focused practitioner. That said, there are also ways that security teams can employ this documentation productively. For example, this documentation effectively serves as a function-aligned taxonomy of security features and services offered by a cloud provider.
How is that valuable? In a few different ways. It can be used, for example, as input into risk mitigation discussions. It can also be used to help control selection to address issues that arise as part of threat modeling analyses, and it can be used to help identify compensating controls where other issues are identified.
Alternatively, it can just serve as a reference source for customers to highlight features they have access to and, depending on the documentation in use, responsibilities they might not otherwise know they have.