The purpose of reporting board-level security information is to both succinctly communicate the status of the information security program, and request investments and support for improvements. The purpose of collecting operational metrics is to drive
behavior within a specific information security domain. By unifying board-level and operational-level communications, a CISO can better align and control the overall security program. This piece lists some commonly employed operational metrics and
demonstrates how they can be used to spark meaningful conversations with the board and deliver value to the organization.
Reporting to the Board on Information Security
A typical approach reporting information security the board-level might
consist of:
- One slide on the state of the security program
- One slide recapping any security incidents
- One slide recapping the status of legal and regulatory compliance
- One slide on the status of security initiatives and projects
- A recap and ask slide
The state of the security program should reflect the operational status of the security activities and controls. In effect, this is a roll-up of the operational metrics. Consider presenting the domains of the security program with red/yellow/green status.
Supplemental slides for any red domains can then delve into the specific operational concerns.
RELATED CONTENT: Guidance for CISOs Presenting to the C-Suite
Security Domains for Reporting to the Board
When rolling up the security capabilities into domains, group them logically and aim for either six (two rows, three columns) or nine (three by three) so you can effectively communicate it all on one slide.
Figure 1 shows an example of a nine-domain security program.
Common Operational Metrics Across Security Domains
Some commonly used operational metrics across the nine domains with the information security function are outlined here.
Security Domain: Asset Management
- Metric: Hardware inventory coverage
- How It's Tracked - Number of inventoried and managed devices divided by total number of devices scanned
- Purpose - Drives efforts toward an accurate configuration management database (CMDB)
- Metric: Software inventory coverage
- How It's Tracked - Number of inventoried and company-authorized applications divided by total number of applications scanned
- Purposes – 1) Drives efforts toward an accurate CMDB; 2) Drives efforts toward application whitelisting
- Metric: Obsolete operating systems
- How It's Tracked - Number of obsolete and unsupported OSes divided by the total number of inventoried assets
- Purpose – 1) Drives IT modernization efforts; 2) Impacts vulnerability management metrics
- Metric: Anti-malware coverage
- How It's Tracked - Number of devices with properly configured and operational endpoint protection divided by total number of devices
- Purpose - Drives efforts toward endpoint detection and response (EDR)
Security Domain: BC/DR
- Metric: Recovery point objective (RPO)
- How It's Tracked - Most recent point in time critical systems can be recovered to
- Purpose - Frequency of backups from the backup and recovery system
- Metric: Recovery time objective (RTO)
- How It's Tracked - Duration of downtime to recover systems to the RPO
- Purpose - Time to execute recovery procedure (validated by exercises)
- Metric: Backup coverage
- How It's Tracked - Number of systems with successful backups divided by total number of systems
- Purpose - Drives efforts to expand the backup and recovery system
- Metric: Effectiveness of previous BC/DR exercises
- How It's Tracked - Frequency and outcome of BC/DR exercises
- Purpose - Demonstrates the BC/DR capability in practice
Security Domain: Detection and Prevention
- Metric: Mean time to detect (MTTD)
- How It's Tracked - The time it takes to detect security threats
- Purpose - Drives efforts for improved tooling, additional staffing, enhanced procedures and improved training
- Metric: Host monitoring coverage
- How It's Tracked - The number of hosts with logging divided by the total number of hosts
- Purpose - Drives efforts to increase host-level visibility
- Metric: Network monitoring coverage
- How It's Tracked - The number of networks with logging divided by the total number of networks
- Purpose - Drives efforts to increase network-level visibility
- Metric: Vulnerabilities per host
- How It's Tracked - The total number of vulnerabilities divided by the total number of hosts in the vulnerability management program
- Purpose - Drives remediation efforts, including patch management
Security Domain: Governance
- Metric: Program maturity
- How It's Tracked - The maturity of control implementation (e.g., NIST 800-53b) compared to baseline
- Purpose - Drives investments in controls and security technologies
- Metric: Peer security rating
- How It's Tracked - The security rating of the organization compared to peers (e.g., BitSight rating)
- Purpose - Demonstrates due diligence relative to the market and relative to industry peers
- Metric: Compliance
- How It's Tracked - Compliance rating to regulatory requirements as measured by internal audit or external audit
- Purpose - Demonstrates due diligence relative to industry standards
- Metric: Policy coverage
- How It's Tracked - Number of controls codified in policy divided by total number of controls
- Purpose - Drives updates and maintenance of policies and procedures
Security Domain: Identity Management
- Metric: On-boarding time
- How It's Tracked - Average number of days to fully provision a user
- Purpose - Can signal the need to improve provisioning and on-boarding processes
- Metric: Off-boarding time
- How It's Tracked - Average number of days to fully de-provision a user
- Purpose - Can signal the need to improve de-provisioning and off-boarding processes
- Metric: Separation of duties exceptions
- How It's Tracked - Number of violations
- Purpose - Aim for zero
- Metric: Least privilege exceptions
- How It's Tracked - Number of violations
- Purpose - Aim for zero
Security Domain: Incident Management
- Metric: Mean time to resolve (MTTR)
- How It's Tracked - The time it takes to respond and resolve a security incident
- Purpose - Drives efforts for improved tooling, additional staffing, enhanced procedures and improved training
- Metric: Mean time to contain (MTTC)
- How It's Tracked - The time it takes to secure the attacked location and resume normal operations
- Purpose - Drives efforts for improved tooling, additional staffing, enhanced procedures and improved training
- Metric: Incidents
- How It's Tracked - Number of events within the reporting time period
- Purpose - Demonstrates the stopping power of the current security program
- Metric - Effectiveness of previous security exercises
- How It's Tracked - Frequency and outcome of security incident exercises
- Purpose - Demonstrates the capability in practice
Security Domain: Risk Management
- Metric: Risk exposure
- How It's Tracked - Provided from the governance, risk management and compliance (GRC) tool
- Purpose - Indicates the overall risk calculated with a standard risk management formula
- Metric: Technical risk exposure rate
- How It's Tracked - Rate at which new technical risk is exposed, e.g., from software vulnerabilities or code-level vulnerabilities
- Purpose - Drives efforts for training and additional staffing
- Metric: Risk assessment
- How It's Tracked - Score from recent risk assessment performed internally or by a third-party
- Purpose - Facilitates conversation around current state and future initiatives
- Metric: Number of risks occurred
- How It's Tracked - The number of issues within the time period directly correlated to the risks identified and tracked in the risk register
- Purposes – 1) Demonstrates the accuracy and efficacy of the risk register; 2) Drives efforts toward specific risk reduction for realized risks
Security Domain: Security Culture
- Metric: Security awareness training completion rate
- How It's Tracked - The number of employees completing training divided by the total number of employees
- Purpose - Identifies when people are not completing the training
- Metric: Security awareness score
- How It's Tracked - The average security awareness training score for the time period
- Purpose - Identifies when people are not learning from the training
- Metric: Successor identification
- How It's Tracked - The number of positions with a successor identified divided by the total number of key positions
- Purpose - Reflects the resiliency of key positions and the awareness of cross-training and successor requirements
- Metric: Testing results
- How It's Tracked - Phishing test results
- Purpose - Indicates the efficacy of security awareness training toward stopping a key adversary tactic
Security Domain: Supplier Assurance
- Metric: Vendor coverage
- How It's Tracked - The number of vendors assessed for risk divided by the total number of vendors
- Purpose - Drives efforts to expand the vendor risk management program
- Metric: Vendor risk assessment
- How It's Tracked - Aggregate score from recent assessments performed on vendors
- Purpose - Facilitates conversation around vendor security requirements
- Metric: Number of vendor personnel with critical access
- How It's Tracked - The number of contract personnel with access to critical data and systems
- Purpose - Determines emphasis on third-party contract employee security
- Metric: Number of contracts awarded without proper security sign-off
- How It's Tracked - The number that did not receive proper security scrutiny or sign-off beforehand within the time period
- Purpose - Increased collaboration between the procurement function and the security assessment function
Using Metrics to Communicate with the Board
To effectively use these information security metrics to communicate to executive leadership and board:
Collect a broad range of measures. This provides historical context that will be useful when evaluating potential changes in the program.
Combine metrics with action. Most metrics are descriptive or diagnostic. By using forecasting and running improvement initiatives, metrics can be predictive or prescriptive.
Roll-up and summarize. Roll up the operational metrics for specific security capabilities into a small number (six or nine recommended) domains, and report on the efficacy of those domains in the board presentation.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in
connection with such information, opinions, or advice.