Skip to content

Page048

Budget and Metrics

When combined with Risk Analysis, the Total Cost of Ownership and Return on Investment calculations factor into proper budgeting. Some organizations have the enviable position of ample information security funding, yet they are often compromised. Why? The answer is usually because they mitigated the wrong risks. They spent money where it may not have been necessary and ignored larger risks. Regardless of staff size or budget, all organizations can take on a finite amount of information security projects. If they choose unwisely, information security can suffer.

Metrics can greatly assist the information security budgeting process. They help illustrate potentially costly risks and demonstrate the effectiveness (and potential cost savings) of existing controls. They can also help champion the cause of information security.

The CIS Security Benchmarks lists the following metrics:

  • Application Security
  • Number of Applications
  • Percentage of Critical Applications
  • Risk Assessment Coverage
  • Security Testing Coverage
  • Configuration Change Management
  • Mean-Time to Complete Changes
  • Percent of Changes with Security Review
  • Percent of Changes with Security Exceptions
  • Financial
  • Information Security Budget as % of IT Budget
  • Information Security Budget Allocation
  • Incident Management
  • Mean-Time to Incident Discovery
  • Incident Rate
  • Percentage of Incidents Detected by Internal Controls
  • Mean-Time Between Security Incidents
  • Mean-Time to Recovery
  • Patch Management
  • Patch Policy Compliance
  • Patch Management Coverage
  • Mean-Time to Patch
  • Vulnerability Management
  • Vulnerability Scan Coverage
  • Percent of Systems Without Known Severe Vulnerabilities
  • Mean-Time to Mitigate Vulnerabilities
  • Number of Known Vulnerability Instances

Risk Response

Once we have assessed risk, we must decide what to do. Options include accepting the risk, mitigating or eliminating the risk, transferring the risk, and avoiding the risk.

Accept the Risk

Some risks may be accepted: in some cases, it is cheaper to leave an asset unprotected due to a specific risk, rather than make the effort (and spend the money) required to protect it. This cannot be an ignorant decision: the risk must be considered, and all options must be considered before accepting the risk.

Learn by Example

Accepting the Risk

A company conducted a Risk Analysis, which identified a mainframe as a source of risk. The mainframe was no longer used for new transactions; it served as an archive for historical data. The ability to restore the mainframe after a disk failure had eroded over time: hardware aged, support contracts expired and were not renewed, and employees who were mainframe subject matter experts left the company. The company was not confident it could restore lost data in a timely fashion, if at all.

The archival data needed to be kept online for 6 more months, pending the installation of a new archival system. What should be done about the backups in the meantime? Should the company buy new mainframe restoration hardware, purchase support contracts, or hire outsourced mainframe experts?

The risk management team asked the team supporting the archive retrieval, “What would happen if this data disappeared tomorrow, 6 months before the new archival system goes live?” The answer: the company could use paper records in the interim, which would represent a small operational inconvenience. No laws or regulations prohibited this plan.

The company decided to accept the risk of failing to restore the archival data due to a mainframe failure. Note that this decision was well thought out. Stakeholders were consulted, the operational impact was assessed, and laws and regulations were considered.