Enterprise
Risk and Compliance Reporting
By Gideon T. Rasmussen, CISSP, CISA, CISM, CIPP
Document each security function's mission as a first step towards reporting. Mission can be loosely defined as the high-level goals of a team. A mission statement explains the purpose of a team from a business perspective. Vision can be defined as how the team accomplishes its mission.
A basic goal of reporting is to determine the effectiveness and current state of a given function. It becomes easier to determine at a high-level which elements should be included in reporting with mission and vision statements in hand.
Reports and Data Sources
Meet with each team or function and request access to their reporting. Critically evaluate each report. Determine whether reporting accurately reflects status based upon mission.
At a high-level, risk and compliance reporting should meet the following goals:
· Reflect security posture and the associated risk to core business products, services and strategic goals
· Consider assessment subjects from a variety of perspectives
· Enable management to make informed decisions
· Provide reporting in a timely manner, preferably through real-time automation
· Identify a point of contact associated with each subject/finding. Accountability is critical to remediation.
· Support compliance with laws, regulations and contracts
The process of gathering existing reports also identifies reporting points of contact and data sources. Take note of each. Begin documenting a reporting methodology at this phase as well.
Risk vs. Compliance
Business management may be of the mindset that compliance is an ideal state, similar to nirvana. Identify which mandate each control corresponds to. When a control is tied back to an external requirement, management may support compliance to avoid penalties.
Risk can be subjective, which is where a well-documented reporting methodology becomes crucial. Executives want reporting in relatively simple terms. The use of high, medium and low findings with corresponding red, yellow and green colors is common. Include supporting data as well. Create a reporting methodology based upon sound principles, with management as the intended audience.
II. Identify Reporting Types
Baseline Controls
It is necessary to have well-defined information security standards before reporting compliance status. Start by establishing a control baseline in accordance with regulations, laws and contractual obligations. A control baseline also clarifies policy into specific requirements. Refer to NIST SP 800-53 as an example. Use a control framework such as ISO 27002 or COBIT to bolster the baseline. Conduct a risk assessment to close remaining gaps.
Classify each baseline control to facilitate reporting when findings are present.
Security Metrics
Determine what types of reporting are necessary based upon mission, audience and available data. Here are a few examples and free reporting resources for inspiration.
The large number of metrics within the above resources may seem overwhelming. Create a spreadsheet and sort them by data sources (teams and tools), audience throughout management tiers and metric implementation phases. Dan Geer's Measuring Security Tutorial contains a wealth of information. Refer to it as well.
Risk Priority
Compliance is binary, either a control is in place or not. One missing control will result in a non-compliant status, which does not represent the risk associated to business. Use risk scoring to assign potential business impact to each report finding. Start by applying a risk rating to each baseline control. Refer to the Microsoft Security Risk Management Guide to determine impact levels and associated exposure ratings. Failure Modes and Effects Analysis has risk scoring built in. Define which ratings threshold should constitute a control that is risky and needs to be shored up.
Establish a common reporting language. The meaning and related impact of high, medium and low findings should be uniform throughout each report. Refer to NIST 800-30 for sample risk impact definitions.
This interim approach assigns a risk value to each baseline control to assist with remediation priority. Establish a comprehensive Enterprise Risk Management Methodology and incorporate it into reporting in a future phase of development.
II. Implement Appropriate Reporting
W. Edwards Deming said "What cannot be measured cannot be managed". Business management is likely to be of the same opinion. Establish a single risk and compliance application for the entire company. The application should accept data from a variety of sources. Questionnaire functionality is needed to facilitate security self-assessments and annual security awareness training and testing. The application should accept data feeds from a variety of sources such as log and security monitoring software. Security team members will need the ability to manually enter findings from on-site assessment reports. The application should also produce security reports to support internal and external audits such as Sarbanes Oxley and PCI.
Reporting is a data-centric pursuit. Therefore, it makes sense to copy reporting data to a central repository. From a single location, it is possible to analyze data and provide reporting. It will be necessary to have a phased implementation. If a large organization is in scope, start with a line of business and scale to the enterprise over time. Duplicate existing reports in the initial phase and add new reports later. Use role-based access control to restrict reporting to those with a need-to-know. Monitor manually entered report data to ensure it is kept current.
Establish a Risk and Compliance Dashboard
Establish enterprise reporting by management tiers. Reporting should start at a high-level, detailing risk and compliance statuses for the enterprise and individual lines of business.
Take care when aggregating enterprise risk and compliance statuses to provide a high-level executive view. It can be difficult to accurately accomplish this task due to the complexity of the underlying reporting. The executive dashboard should also include security metrics and trending. Management needs the ability to drill down from high-level reporting to specific issues within underlying populations, subjects and findings. That functionality is crucial. Include a link to the reporting methodology document at the bottom of the screen for quick reference.
Consider the Audience
Reporting by tiers is an effective way to present information in a manner that is meaningful to each audience. Report findings must be actionable.
· Company executives want to know the state of risk and compliance throughout the enterprise. Reporting at this level may be presented to shareholders and the audit committee.
· Line of Business management needs coordinated reporting from security teams to understand what the issues are and how they can impact business. Once an issue is confirmed, it is necessary to offer a solution, ideally with options.
· IT managers need reporting by population and low-level details used by their reports to resolve findings.
· Individual contributors need specific findings that apply to the systems and applications they administer.
Prioritize risk and compliance statuses within each reporting tier. Work closely with business and IT management to assign a remediation contact to each finding for accountability. Each finding should also include details of the issue, planned remediation activity and target remediation date.
Using the methodology detailed above, an executive should be able to click down from the line of business, to a high risk subject, associated findings and remediation plans. In practice, that functionality is a powerful way to gain visibility and funding to address critical issues.
III. Present to Management
Finalize the Reporting Methodology document. This article can be used as a framework. Explain the rationale behind each report including data sources such as teams, tools, manual data entry, automation and data refresh periods. Include the importance of risk mitigation over minimum compliance. A methodology document has utility for training, continuity and audit.
Prepare a management slide presentation to introduce the reporting application, executive dashboard and remaining implementation phases. Conduct a live demo of the application during the presentation. Manage expectations up front. Be transparent about current functionality and areas for improvement. Provide a roadmap for future reporting enhancements.
An accurate reporting system is bound to identify high risk findings. Encourage management to foster a culture where high risk findings are permissible, providing remediation contacts and target remediation dates are promptly identified.
IV. Maintenance
Reporting must evolve to adapt to changes in business practices, technology and emerging threats. Keep acceptable risk and compliance ranges tied to a methodology based upon risk and reward (versus tightening ranges as metrics improve). Future phases of development can include feeds from other departments (e.g. audit), inclusion of financial risk reporting and implementation of new metrics.
If a security department does its job well, nothing happens. Business continues to function without disruption or impact. Therein lies the challenge, especially in a tight budget year. Reporting reduces subjectivity and uncertainty. Comprehensive reporting demonstrates the value of the information security program and helps drive future initiatives and funding.
About the author:
Gideon T. Rasmussen is a Charlotte-based Information Security Vice President with a background in Fortune 50 and military organizations. His website is www.gideonrasmussen.com.
By Gideon T. Rasmussen, CISSP, CISA, CISM, CIPP
Modern companies are challenged by the need to demonstrate compliance, mitigate risk and fund security initiatives. Reporting is the pursuit of simple truth. Like many technical challenges, the underlying complexity can be daunting. This article addresses a variety of techniques to report risk and compliance statuses, raise awareness and influence remediation.
Mission / VisionDocument each security function's mission as a first step towards reporting. Mission can be loosely defined as the high-level goals of a team. A mission statement explains the purpose of a team from a business perspective. Vision can be defined as how the team accomplishes its mission.
A basic goal of reporting is to determine the effectiveness and current state of a given function. It becomes easier to determine at a high-level which elements should be included in reporting with mission and vision statements in hand.
Reports and Data Sources
Meet with each team or function and request access to their reporting. Critically evaluate each report. Determine whether reporting accurately reflects status based upon mission.
At a high-level, risk and compliance reporting should meet the following goals:
· Reflect security posture and the associated risk to core business products, services and strategic goals
· Consider assessment subjects from a variety of perspectives
· Enable management to make informed decisions
· Provide reporting in a timely manner, preferably through real-time automation
· Identify a point of contact associated with each subject/finding. Accountability is critical to remediation.
· Support compliance with laws, regulations and contracts
The process of gathering existing reports also identifies reporting points of contact and data sources. Take note of each. Begin documenting a reporting methodology at this phase as well.
Risk vs. Compliance
Business management may be of the mindset that compliance is an ideal state, similar to nirvana. Identify which mandate each control corresponds to. When a control is tied back to an external requirement, management may support compliance to avoid penalties.
Risk can be subjective, which is where a well-documented reporting methodology becomes crucial. Executives want reporting in relatively simple terms. The use of high, medium and low findings with corresponding red, yellow and green colors is common. Include supporting data as well. Create a reporting methodology based upon sound principles, with management as the intended audience.
II. Identify Reporting Types
Baseline Controls
It is necessary to have well-defined information security standards before reporting compliance status. Start by establishing a control baseline in accordance with regulations, laws and contractual obligations. A control baseline also clarifies policy into specific requirements. Refer to NIST SP 800-53 as an example. Use a control framework such as ISO 27002 or COBIT to bolster the baseline. Conduct a risk assessment to close remaining gaps.
Classify each baseline control to facilitate reporting when findings are present.
|
Control Name |
ACME0001 |
ACME0002 |
ACME0003 |
|
Requirement |
Maintain a security awareness and training program. |
Sensitive authentication data must not be stored after authorization. |
Monitor system and network performance and capacity levels. |
|
Environment |
Enterprise |
Payment Card |
Enterprise |
|
Source(s) |
|||
|
Control Category |
Administrative |
Technical |
Technical |
|
Control Type |
Preventive |
Preventive |
Detective |
|
Risk Impact |
Medium |
High |
Medium |
|
Domain |
Personnel Security |
Data Retention |
Monitoring |
Security Metrics
Determine what types of reporting are necessary based upon mission, audience and available data. Here are a few examples and free reporting resources for inspiration.
|
Metric |
Source |
|
Percentage (%) of high vulnerabilities mitigated within organizationally defined time periods after discovery. |
NIST: SP 800-55: Performance Measurement Guide for Information Security |
|
Percentage of business unit heads and senior manager who have implemented operational procedures to ensure compliance with approved information security policies and controls |
Corporate Information Security Working Group: Report of the Best Practices and Metrics Teams |
|
% of systems configured to approved standards |
Center for Internet Security: Consensus Information Security Metrics Service |
The large number of metrics within the above resources may seem overwhelming. Create a spreadsheet and sort them by data sources (teams and tools), audience throughout management tiers and metric implementation phases. Dan Geer's Measuring Security Tutorial contains a wealth of information. Refer to it as well.
Risk Priority
Compliance is binary, either a control is in place or not. One missing control will result in a non-compliant status, which does not represent the risk associated to business. Use risk scoring to assign potential business impact to each report finding. Start by applying a risk rating to each baseline control. Refer to the Microsoft Security Risk Management Guide to determine impact levels and associated exposure ratings. Failure Modes and Effects Analysis has risk scoring built in. Define which ratings threshold should constitute a control that is risky and needs to be shored up.
Establish a common reporting language. The meaning and related impact of high, medium and low findings should be uniform throughout each report. Refer to NIST 800-30 for sample risk impact definitions.
This interim approach assigns a risk value to each baseline control to assist with remediation priority. Establish a comprehensive Enterprise Risk Management Methodology and incorporate it into reporting in a future phase of development.
II. Implement Appropriate Reporting
W. Edwards Deming said "What cannot be measured cannot be managed". Business management is likely to be of the same opinion. Establish a single risk and compliance application for the entire company. The application should accept data from a variety of sources. Questionnaire functionality is needed to facilitate security self-assessments and annual security awareness training and testing. The application should accept data feeds from a variety of sources such as log and security monitoring software. Security team members will need the ability to manually enter findings from on-site assessment reports. The application should also produce security reports to support internal and external audits such as Sarbanes Oxley and PCI.
Reporting is a data-centric pursuit. Therefore, it makes sense to copy reporting data to a central repository. From a single location, it is possible to analyze data and provide reporting. It will be necessary to have a phased implementation. If a large organization is in scope, start with a line of business and scale to the enterprise over time. Duplicate existing reports in the initial phase and add new reports later. Use role-based access control to restrict reporting to those with a need-to-know. Monitor manually entered report data to ensure it is kept current.
Establish a Risk and Compliance Dashboard
Establish enterprise reporting by management tiers. Reporting should start at a high-level, detailing risk and compliance statuses for the enterprise and individual lines of business.
Take care when aggregating enterprise risk and compliance statuses to provide a high-level executive view. It can be difficult to accurately accomplish this task due to the complexity of the underlying reporting. The executive dashboard should also include security metrics and trending. Management needs the ability to drill down from high-level reporting to specific issues within underlying populations, subjects and findings. That functionality is crucial. Include a link to the reporting methodology document at the bottom of the screen for quick reference.
Consider the Audience
Reporting by tiers is an effective way to present information in a manner that is meaningful to each audience. Report findings must be actionable.
· Company executives want to know the state of risk and compliance throughout the enterprise. Reporting at this level may be presented to shareholders and the audit committee.
· Line of Business management needs coordinated reporting from security teams to understand what the issues are and how they can impact business. Once an issue is confirmed, it is necessary to offer a solution, ideally with options.
· IT managers need reporting by population and low-level details used by their reports to resolve findings.
· Individual contributors need specific findings that apply to the systems and applications they administer.
Prioritize risk and compliance statuses within each reporting tier. Work closely with business and IT management to assign a remediation contact to each finding for accountability. Each finding should also include details of the issue, planned remediation activity and target remediation date.
Using the methodology detailed above, an executive should be able to click down from the line of business, to a high risk subject, associated findings and remediation plans. In practice, that functionality is a powerful way to gain visibility and funding to address critical issues.
III. Present to Management
Finalize the Reporting Methodology document. This article can be used as a framework. Explain the rationale behind each report including data sources such as teams, tools, manual data entry, automation and data refresh periods. Include the importance of risk mitigation over minimum compliance. A methodology document has utility for training, continuity and audit.
Prepare a management slide presentation to introduce the reporting application, executive dashboard and remaining implementation phases. Conduct a live demo of the application during the presentation. Manage expectations up front. Be transparent about current functionality and areas for improvement. Provide a roadmap for future reporting enhancements.
An accurate reporting system is bound to identify high risk findings. Encourage management to foster a culture where high risk findings are permissible, providing remediation contacts and target remediation dates are promptly identified.
IV. Maintenance
Reporting must evolve to adapt to changes in business practices, technology and emerging threats. Keep acceptable risk and compliance ranges tied to a methodology based upon risk and reward (versus tightening ranges as metrics improve). Future phases of development can include feeds from other departments (e.g. audit), inclusion of financial risk reporting and implementation of new metrics.
If a security department does its job well, nothing happens. Business continues to function without disruption or impact. Therein lies the challenge, especially in a tight budget year. Reporting reduces subjectivity and uncertainty. Comprehensive reporting demonstrates the value of the information security program and helps drive future initiatives and funding.
About the author:
Gideon T. Rasmussen is a Charlotte-based Information Security Vice President with a background in Fortune 50 and military organizations. His website is www.gideonrasmussen.com.
Originally published in (IN)SECURE Magazine (June 1, 2009)