Organizations need an Information Security strategy, regardless of their industry or annual revenue. But where do you start? And once you start, how do you ensure that the security strategy is being implemented correctly and maintained over time? “Architecting an Information Security Program for the Enterprise” discusses a practical approach, start to finish, on how to plan, build, implement and maintain an information security program for the modern-day enterprise.
The first step in taking a risk-based approach to information security is, not surprisingly, to understand our current state of risk. We acquire information about our current risks by performing a security assessment of the environment. The security assessment results will be the foundation upon which we will build our roadmap and goals for the information security program.
NIST (the National Institute for Standards and Technology) published NIST SP 800-30 as a guide for conducting risk assessments. Other sources of documents and tools exist for conducting security risk assessments. However, NIST documents are often recommended because of their age, maturity, and adoption within U.S. government agencies.
Regardless of document or methodology, a security risk assessment should accomplish the following:
- Catalog information systems and assets
- Catalog current or potential threats to those systems and assets
- Catalog current vulnerabilities within those systems and assets
- Catalog current security controls in place
- Assess the likelihood of threats exploiting vulnerabilities against systems and assets
- Assess the impact of threats exploiting vulnerabilities against systems and assets
- Provide risk level determinations
- Provide recommendations for security controls
- Provide documentation on expected results for employing additional security controls
Vulnerabilities are a weakness that lacks protective countermeasure. Threats are the danger that something will take advantage of a vulnerability. Risks are the likelihood that a threat will exploit a vulnerability. Controls are something we add to the environment to mitigate risk. The security risk assessment process, shown in Figure 1 below, depends on a continuous cycle to evaluate these factors.
Figure 1: The Security Risk Assessment Cycle
Once compiled, we can then use the resulting security risk assessment recommendations to create a roadmap of our information security goals for the organization or to formalize the information security program itself, if necessary. Our goals will be achieving some desired level of security and the distance between our desired security level and the actual security level can be identified by the output of our risk assessment, in particular the control recommendations. We should identify the gaps in security and prioritize based on the risks they pose to our information assets.
Our goals will determine our projected resource needs and form the basis for conversations with senior leadership on information security budgets.
CATALOG, CLASSIFY, CLARIFY
For an information security program to succeed, it is vital to have an accurate and up-to-date catalog of all information assets. From a practical perspective, the process of cataloging information assets should be integrated into the business procurement and deployment process so we don’t find ourselves retroactively having to discover and inventory. The preferred time to discover systems running unpatched software is before and not after they are compromised.
In addition to knowing what assets we have we need to classify those systems into different levels of importance and categories of risk. Does the asset face the Internet? Does it house sensitive data? Does it support a critical process? Does it represent a single point of failure?
With cloud-based resources, it is important to know WHERE data is stored and what boundaries it crosses. We need to properly understand what our assets are and classify them accordingly. Proper classification will allow us to prioritize the order of remediation and budget allocation.
FIPS (federal information processing standards publication) offers publication 199, “Standards for Security Categorization of Federal Information systems”, as a model and guiding structure for classifying your information assets. To summarize the process at a high-level, we can use the CIA (Confidentiality, Integrity, Availability) triad and ask ourselves these questions:
- Confidentiality – What happens if the wrong person gains access to the data?
- Integrity – What happens if someone unauthorized changes the data?
- Availability – What happens if someone unauthorized deletes the data or makes it unavailable?
Once the above questions are answered, FIPS publication 199 provides three risk classification levels for our assets:
- High Impact
- Moderate Impact
- Low Impact
With respect to classifying the data on our assets, the goal is to make sure the data is correctly classified so employees know how to properly handle the data – or the information assets on which the data is housed.
The Federal/DoD “classified national security information” document provides these data classification labels:
- Top secret
- Secret
- Confidential
- SBU – sensitive but unclassified
- SSI – sensitive security information
- CUI – controlled unclassified information
Here are some examples of corporate / non-government data classification labels:
- Protected (SSNs, HIPAA)
- Proprietary (intellectual property)
- Confidential (internal use only, don’t share externally)
- Public
Combining the risk classification levels with data classification allows us to assign mitigation priorities (see Figure 2). Highly valuable data that has serious repercussions if compromised will be targeted much more than low-value data, even when protected.
Figure 2: Severity vs. Likelihood of Compromise Priority Chart
A tool that can assist in classifying the severity and priority of vulnerabilities discovered within information assets is the CVSS (common vulnerability scoring system) calculator, available at: https://www.first.org/cvss/calculator/3.0
Once we understand what assets we possess and the criticality of those assets, we need to clarify the difference between our current security level and our desired security level. Bringing greater levels of clarity and specificity to these goals will help provide us with a framework in which we can approach the security of our organization and assets. Without a formal plan, our results are likely to be sporadic and vary greatly, depending on who is involved in the effort, as they provide their own interpretation of the desired result and the path to get there.
Most security program processes, including the risk-based approach we have been discussing, are iterative processes. When we get to the last step of the process (the Mitigate Risk step shown in Figure 1), we return to the first step and start all over again, hopefully continuing to refine and improve the program with each iteration of the process.
Once we know what assets we have and their value, we can clearly articulate where we want to go in terms of security for our assets. It’s then time to plan our strategy for how to get there.
In the next blog in this series, we will discuss building out our information security strategy in greater detail.