A moment of candor - at first look I didn’t get the National Institute of Standards and Technology (NIST) Cyber Security Framework. It just looked like a list of sensible things to do. Being in the Cyber industry for more years than I care to mention, I have seen it grow from its infancy. Well, I was fortunate to play around with Checkpoint Firewall-1 when it was released as a set of floppies and ran on Solaris.
Alongside the amazing development of the cyber security industry I also witnessed the significant growth of IT and cyber related regulations. I was unfortunate enough to be involved in certifying our company for ISO-9000 before the 2000 release. I got a taste of ISO bureaucracy and since then have tried to avoid getting too close to regulations and compliance.
So, when I was asked to look at how Cymulate Breach and Attack Simulation maps to the NIST Cyber Security Framework (CSF) I was forced to investigate and as I wrote, I didn’t get it. I didn’t understand its utility or added value to the more detailed standards and regulations that I so wanted to avoid.
You can read about the history of the CSF here. What surprised me about the CSF Core is that it is useful and adaptable and hurrah, it is in plain English. It is indeed a list of sensible things organizations should do (activities and outcomes) to induct cybersecurity into its fabric and hopefully its corporate culture without forcing people to deal with information technology and cybersecurity gobbledygook.
For example, one CSF outcome (subcategory PR.AC-5) is that “Network integrity is protected (e.g., network segregation, network segmentation)”. You can decide how to segment and how much segregation is required. And yes, Cymulate will validate that your network segmentation policies are effectively enforced by simulating a hacker and/or worm attempting to propagate within your network. It shows you what it was able to discover, propagate to, and how, in addition to providing remediation guidance.
The CSF core does not specify the “how and the how much” for each subcategory, enabling it to remain clear and concise. What it does provide is a list of Informative References. These support the Core by providing broad references that are more technical than the Framework itself. Organizations may use some, none, or all of these references to achieve the outcome described in the Subcategory. Typically, companies will use the references that apply to their regulatory requirements, such as PCI or FIPS regulations. More on that when we get to profiles.
If you like a challenge, look at just one of the informative references of the same PR.AC-5 subcategory mentioned above. For example the Security and Privacy Controls for Federal Information Systems and Organizations NIST SP 800-53 Rev. 4 AC-4. If you took a gander at AC-4 and if you are not involved in compliance, then you can probably relate to my pleasant surprise that CSF is indeed written for (almost) regular people.
The key component of CSF is the Framework Core which a set of desired cybersecurity activities and outcomes. Most of the items are clear for anyone to understand, some require a minimal understanding of IT concepts. The five functions of the Framework Core make it clear that NIST assumes that no organization is immune to a breach, as it covers prevention, detection and response activities and outcomes, in addition to activities required to restore operations after a breach.
The five functions are:
- Identify – What processes and assets need protection.
- Protect – What safeguards are available.
- Detect – What techniques can identify incidents.
- Respond – What techniques can contain impacts of incidents.
- Recover – What techniques can restore capabilities.
The five functions of the Framework Core are broken down into 23 categories and 108 subcategories, these describe the “what” of a cybersecurity practice or technique. The “how” or “how much” is provided through Informative References to other standards and regulations. By separating the technical informative references, CSF remains clear and easy to understand, it provides a common language between operations and upper management and it enables companies from different industries to adapt CSF to their specific profile.
Even the ratings of CSF implementation are clear. Termed the Framework Implementation Tiers, it’s a simple, qualitative measure of organizational cybersecurity risk management practices on a scale of 1-4.
The tricky part is to decide the implementation level that is right for your organization, this is where Framework Profiles come into play. It is a unique mapping of an organizations existing security practices and controls onto the 108 subcategories of the framework core. By mapping company specific business objectives, technical inputs (threats & vulnerabilities) and industry specific regulations and constrains to the core it becomes apparent which are the most meaningful subcategories to your organization. Taking this a step further an organization can create a target profile based on its risk tolerance. The gaps between the current profile and the target profile can then be prioritized for remediation.
Taking a step back it becomes apparent that CSF as a language and a structure is useful to reporting and expressing the level of compliance to your own security requirements. This enables an organization not only to communicate clearly between operations, middle management, and executive levels but to create an iterative process for constant improvement of an organization’s cybersecurity framework.
Going back to the task of mapping Cymulate Security Validation capabilities to the CSF core subcategories. We have listed about 60 of the 108 subcategories where Cymulate can test, verify, and/or support their implementation. Click here for more on Cymulate and the NIST Cyber Security Framework.