A Risk Model is a useful tool for defining how a security function identifies and mitigates risk. This article explains how to document your current risk model, evaluate its effectiveness and plan for changes to better mitigate risk moving forward.

I. Document the Program Risk Model
Start by documenting the existing program at a mid-level. Most of the content can be found in process diagrams, procedures manuals, team websites, slide decks, etc. The act of documenting a risk model should give rise to lively discussion and healthy debate. Those new to the team can provide a fresh perspective. Existing members can provide historical details and rationale for why the current processes and technology are in place.

Mission / Vision
Start by documenting mission and vision statements for the program or team. Describe what the function is responsible for. Provide a high-level overview of goals and processes to ensure they are met. The emphasis should be phrased in terms of risk identification and management.

Risk Appetite
Identifying the company's risk appetite is one of the first steps in developing a risk model. Ask executive management for their opinion to give them a sense of ownership. The ISACA Risk IT Framework provides additional guidance for documenting risk appetite.

Risk Profile
Risk should not be discussed in a security vacuum. It needs to tie back to business objectives. Explain inherent risks the program is meant to address and the potential for business impact. Describe high-level challenges, potential control deficiencies and best practices to address them.

Roles and Responsibilities
Start this section by describing roles within the program. If it is comprised of multiple teams, call that out. Identify others whose support is necessary for the function to succeed such as IT personnel, security teams, senior leaders and risk partners.

Population
Describe the subjects the function is meant to address. Examples of populations include systems, applications, service providers, or businesses in the case of a venture capital firm. Include how entities within the population are identified for inclusion in your process. Provide criteria that exclude entities from the population.

Selection Criteria
Describe the intake process, to ensure each entity is accounted for. Next, explain how each entity is selected for evaluation such as questionnaire versus on-site assessment or automated scan versus a penetration test. Describe how entities are scheduled for evaluation based upon risk criteria. Frequency of evaluation is also a consideration.

Evaluation Methodology
Describe how entities are evaluated for risk. Explain which processes, technology and personnel are deployed. Describe how a finding is generated. Explain how risk ratings are calculated and assigned. Include company standards timelines for remediation by risk rating.

Remediation
Provide details of how findings are communicated to report recipients. Document how target remediation dates are identified and how remediation is confirmed and tracked to closure.

Escalation
Describe how findings are addressed when remediation timelines are exceeded. Include communications routines for escalation and which parties are included. Describe how findings in extended remediation are escalated to senior management and tracked to closure.

Reporting
Reporting starts with process. Processes should explain how a risk is identified and managed. Assign metrics to process control points, such as when a security vulnerability is detected. Clearly define metric calculations and thresholds. Refer to my 'Enterprise Risk and Compliance Reporting' article for additional details.

Program Maintenance
Explain how the program is kept current from a risk perspective. This is necessary to ensure emerging threats are addressed in alignment with the company's risk appetite. Include how alignment to standards is maintained.

References
Provide references to supporting documentation and company standards throughout the risk model. Include links to industry standards and best practices as well. That helps validate the program and underlying methodologies.

Parking Lot
Throughout the process of documenting a risk model, it will become clear that a number of practices need to change or require further evaluation at the very least. Document those observations on the side, in a 'parking lot'. This will keep the focus on documenting the existing risk model. It is possible to streamline processes and follow the risk with those details in hand.

II. Determine Which Changes are Necessary

This section includes techniques to refine the risk model over time. Enhancements should take into account people, process and technology.

Risk Model Maturity Levels

Information security controls cost money and have an impact on the bottom line. Business management may question the need for controls beyond minimum compliance requirements. Maturity levels are a good way to communicate program enhancements in alignment with company risk appetite.

Maturity Level 1: Adherence to Compliance Requirements
Adherence to compliance requirements provides a form of risk mitigation. However, they are biased towards the governing body. For example, the Payment Card Industry Data Security Standard does not include business continuity and disaster recovery requirements. The card brands are only concerned with the security of their credit card numbers. As new controls are identified, incorporate them into a control baseline.

Maturity Level 2: Control Framework Alignment
Evaluate the program by mapping to an IT security framework such as ISO 27001 or ISACA COBIT. Control frameworks are used to identify controls to prevent, detect and respond to security issues. This step identifies missing controls. The results wrap a presentation layer around your program to demonstrate how it measures up to best practices.

Maturity Level 3: Implementation of Functional Best Practices
Evaluate program functions/teams by best practices documents. NIST has published standards for many information security functions such as incident response and security awareness programs. Application security resources include the OWASP Top 10 and the Building Security in Maturity Model (BSIMM).

Maturity Level 4: Risk Assessment
Adherence to compliance requirements, control frameworks and best practices will not adequately protect sensitive or valuable information. Those documents are written to be one size fits all and are not customized to the unique aspects of your organization. A common theme among each of them is a requirement for risk assessment. Conduct risk assessments taking into account assets and the controls in place to protect them.

Threat Management

Research security vulnerability and compromise trends and develop strategies to combat emerging threats.

Maturity Level 1: Gather Threat Information
Establish good sources of security vulnerability and incident advisories. Open source intelligence can be tracked through RSS feeds. Subscribe to a paid threat intelligence service and leverage government outreach programs such as FBI InfraGard and the U.S. Secret Service Electronic Crimes Task Force (ECTF).

Maturity Level 2: Communicate Threats to Personnel
Map technologies and services and to associated roles throughout the organization. Send targeted advisories to the people that need them. For organizations that have established role-based access control, this form of communication can leverage that framework.

Maturity Level 3: Establish Accountability
Use an automated system to send a subset of threat advisories. Require recipients to select: (a) This threat has been mitigated; (b) There are compensating controls in place that reduces this risk to an acceptable level. They are X; (c) This threat is being addressed. Target remediation date is X and Remediation contact is Y; (d) I accept the risk associated with this threat; (e) This risk does not apply to my environment.

Assessments

Attributes
Identify as much detail about information assets as possible. Determine their exposure and how they are protected and monitored. Examples of data attributes include: Internet-facing, confidentiality rating and business impact analysis.

Selection Criteria
Use available data to determine which entities should receive an assessment. Refer to systems of record such as Configuration Management Databases (CMBD) and Application Inventories. Use the data value and its exposure to determine what type of assessment is necessary. This is a business impact versus threat model.

Scope
Consider how assessments are planned. Seek out ways to identify targets and boundaries of the assessment. Confirm information provided by the assessment contact. For example, conduct independent verification with multiple contacts and use spider scans to identify website structure. Find out of band processes and records that are difficult or impossible to bypass. Examples include purchase orders, contracts, IP addresses and DNS host entries.

Finding Risk Ratings
Use the Six Sigma technique for assigning numerical ratings to categories. Examples include whether a control is preventive, corrective or detective or whether it is high medium or low risk. Establish clear definitions and conduct blind risk ranking with a group of information security professionals to limit variation. Reference scoring resources for inspiration such as Calabrese's Razor, NIST 800-53 appendix and the Common Vulnerability Scoring System (CVSS).

Rotation
Rotate audit and risk assessment methodologies. Rotate members on and off the team every two to three years to keep the program fresh.

Innovation
Employ new techniques to identify and mitigate risk. Employ hybrid techniques, such as using Failure Mode and Effects Analysis with a data flow diagram to conduct a risk assessment. Details are included in my 'Payment Card Security: Risk & Control Assessments' article.

Adversarial Assessments
Employ ethical hackers to penetrate your defenses. If they are skilled, that is exactly what they will do. Use professionals with Red Team experience if possible. They take on the guise of an adversary and use technical, physical and social engineering techniques to compromise data or physical assets. Consider using a different firm each year for high risk environments.

Control Assignment

Data Classification
Determine whether new or replacement controls are necessary. Start by asking senior management to complete a business impact matrix.