While I continue another implementation of my Security Enterprise Risk Management Program (SERMP), I am also continuing to explore the program's flexibility, to help my colleagues in the information technology security field explain to others in the organization the level of risk they face and the progress being made in managing it. The SERMP tool and process can adapt to multiple frameworks, so I asked my colleague Steve Zalewski, a chief security architect, if he would share his thoughts on alternative frameworks that he might "drop" into the SERMP.
Steve:
The concept of SERMP is well grounded in practical experience, as you outlined in your previous article. It creates a great tool to start the dialogue between the two risk management functions: the established business risk team and the nascent IT cyber security risk function. You have accurately represented ISO 27000 with the 12 security domains outlined as a starting point to bring the teams to the table, providing a meaningful set of definitions to the IT security domains.
As these SERMP teams gain momentum and maturity, there are alternative security frameworks available that can provide additional perspectives for the business discussion. This will improve our outcomes against the ultimate goal of a balanced analysis of total risk based on the key business processes and business continuity plans.
Let me explain what I mean by this. Based on the "technical" security controls of ISO 27000 being populated into the SERMP tool, you have established a productive dialogue based on security capabilities, which is a bottom-up approach.
Grace:
Using a crowdsourcing approach, we have a diverse team that is gathering information and populating the SERMP tool, which is a "bottom-up approach," though I would liken it more to a "hunting gathering" approach, as we are collecting data and documentation related to governance, which is "top down." And, because we are seeking dialogue and information from various groups on the information that is readily available at the time, we are approaching the issue "sideways" too.
This might seem chaotic, but because of the SERMP tool and the disciplined procedure, we are able to make that tradeoff.
The ISO 27000 has been used for both of my implementations thus far, as this framework was chosen by the organization as the standard, but I'm eager to integrate other frameworks into the process.
Figure 1: Standard Technical Security Controls ISO 27000
Steve:
Compare this with the cyber security framework that was released based on security risk:
Figure 2: Cyber security Risk Function and Category Unique Identifiers. Source: NIST Framework for Improving Critical Infrastructure Cyber security Version 1.0
As you can see, this aligns to the notional information and decision flows as represented in the diagram below.
Figure 3: Notional Information and Decision Flows Within an Organization. Source: NIST Framework for Improving Critical Infrastructure Cyber security Version 1.0
Grace:
I can see incorporating the NIST framework by layering in additional categories with the current domains and functions. I would continue to document the strategies for each.
Note: The reporting houses the above information for each domain, plus how the organization is managing the program: Establish, assess, treatment, monitor, review activities and metric tracking for: risk statement, risk impact, key risk indicators (KRIs), risk remediation initiatives, current state (KPI), target state (KRI) and projects.
Steve:
Information security risk frameworks are still maturing as the practice begins to mature. No single security framework is correct, so be flexible based on the maturity of your SERMP implementation, and don't be afraid to experiment with the newer risk-based frameworks as the team gains confidence in the information security arena.
Grace:
Steve can you outline for me how you see the difference between a security risk assessment (SERMP) and an IT security assessment?
Steve:
A security risk assessment methodology is based on the guidelines found in:
- ISO/IEC 27001:2005, information technology - security techniques - information security management systems - requirements
- NIST SP 800-30, risk management guide for information technology systems
- BS 7799-3:2006, guidelines for information security risk assessment
A risk assessment scope is defined based on the most "critical" or "valuable" business information assets identified in regard to the potential impact to the business if the asset's confidentiality, integrity or availability was breached. Through data gathering and analysis, including business continuity plans, critical business processes analysis and critical business impact analysis, the assessment questionnaires, interviews and tests are determined. The observed organizational vulnerabilities to the threats, based on existing security controls, are assessed, and a risk analysis is performed.
The completion of a security risk gap analysis is to determine the organization's compliance with the appropriate regulations, laws and security standards. In addition, a security improvement plan is defined for each risk and "gap" identified, and the implementation of the risk treatment plan is prioritized according to the highest risk scores. The result is to reduce the organization's business risks to an "acceptable" level.
A security assessment methodology is based on the guidelines found in:
- NIST SP 800-53, security and privacy controls for federal information systems and organizations
The goal of an IT security assessment (also known as a security audit, security review or network assessment), is to ensure that necessary security controls are integrated into the design and implementation of a project.
A properly completed security assessment should provide documentation outlining any security gaps between a project design and approved corporate security policies.
Management can address identified security gaps in three ways:
- Management can decide to cancel the project
- Management can allocate the necessary resources to correct the security gaps
- Management can accept the risk based on an informed risk/reward analysis
In summary, the characteristics are: IT Security Assessment
- Narrower scope and current state focus
- Start and end date, with a final report
- Conducted by IT security experts
- Is a "point in time" assessment
SERMP
- Broader scope and continuous improvement focus
- Continuous review
- Has a periodic re-evaluation date with a "living document" report
- Conducted by mixture of personnel with varied backgrounds
- Focus on reducing business process security risk by analyzing the associated security risks
Grace:
Steve, that was very helpful in distinguishing between these two very important, but distinct assessments. For SERMP, we use the high-level findings of the IT security assessment as one of the sources of content, so the IT security assessment is critical to the SERMP process. The SERMP provides a high-level report of the current risk levels and the maturity of the mitigations in place that will drive improvement in the IT security assessment.
As always it is great to collaborate with you, and I encourage other risk professionals to work closely with their information technology colleagues.
About Steve:
Steve Zalewski has spent 10-plus years in the cybersecurity field and is currently the chief security architect at Levi Strauss, responsible for the company's enterprise security strategy. Before this, Steve was the enterprise security architect at Pacific Gas & Electric, leading the security architecture team responsible for the company's cybersecurity technical strategy and architecture. Other positions have included security manager at Kaiser Permanente and senior engineering/management positions developing storage networking, data protection solutions and operating systems. He has five patents in data protection and multi-processor operating system design and holds CISSP, CISM and CRISC security certifications.
