Since the National Institute of Standards and Technology Cyber Security Framework (NIST CSF) was established, it has become the framework of choice for organizations to align with to establish “best practice”, and is the foundation for most US cyber compliance requirements.
We get the most questions about NIST CSF and how to use it, and this is part one of a series of posts where we will break down the sections.
The Framework is the result of a February 2013 Executive Order titled “Improving Critical Infrastructure Cybersecurity” and 10 months of collaborative discussions with more than 3,000 security professionals. It comprises a risk-based compilation of guidelines that can help organizations identify, implement, and improve cybersecurity practices, and creates a common language for internal and external communication of cybersecurity issues. The Framework is designed to evolve in sync with changes in cybersecurity threats, processes, and technologies.
Despite being developed for ‘Critical Infrastructure’ specifically, the Framework provides an assessment mechanism that enables organizations to determine their current cybersecurity capabilities, set individual goals for a target state, and establish a plan for improving and maintaining cybersecurity programs.
The framework establishes the five core functions of effective cybersecurity as Identify, Protect, Detect, Respond, and Recover. Each of the five functions are then expanded into 23 categories with 108 subcategories to provide a logical flow of objectives. First is to identify the business standards for risk and to provide governance to the employees tasked with the implementation of the organizations documented and defined standards.
Identify calls for organizations to develop a better understanding of how to manage risks associated with the systems, data and capabilities that are included in their critical infrastructure.
Do you know what systems and data the organization processes, where it is, how it is used? How can we identify risks without that knowledge? We certainly can’t move to the next function and protect things that we don’t know we have.
Also key is identifying regulations or laws the data we have may be make us subject to. Many organizations fail to identify data like employment records, background checks, or workman’s compensation claims that fall under HIPAA or perhaps the state PII laws. What about data we may collect on our customers – do we know what that is, how we store, use, and secure it? Does it fall under other states or nations privacy laws? Many times a business may mistakenly believe that they don’t have regulated data.
An example of Identify in action, look at the breach that impacted Equifax. The breach was caused by a vulnerability in an application called Apache Struts. Let’s assume that Apache Struts was running on Windows 2012 servers, and that Equifax knew it had Windows 2012 servers and kept them patched up, but they didn’t identify that they were running Apache Struts, and therefore missed the critical patch. Or perhaps they did know it was there, but decided the vulnerability (and therefore the patch) was not severe enough to warrant action. Clearly these would be failures in identifying either the actual system or the risk.
It’s critical to view “Identify” as an ongoing task not a single time task. No matter how static the environment, vulnerabilities change, as do regulations and laws. Identifying our assets and assessing the risk should become part of our organizations process.
Next we will dive a little deeper into the function ‘Protect’. Stay tuned!