Decisions abound, and choosing the right metrics involves a clear understanding of the area being analyzed. In most cases, security professionals want to leverage metrics that help define risk and security posture within their financial organization. It also happens that these are the hardest things to measure.
Requirements
One of the key requirements for selecting aspects of security metrics is recognizing the role security plays in the financial firm. Security is almost always a cost center positioned to protect computing events that support the business units of the organization. The functional responsibilities in a security group revolve around minimizing risk associated with business unit functions. There is an expectation that the highest level of risk reduction will be gained with the lowest level of resource allocation.
The process of selecting strategic security metrics requires an understanding of the strategic use of technology by an organization. It assumes an understanding of value, computing activity, control events, and loss incidents within the scope of resources allocated to the problem.
Information asset value
You completely negate your ability to understand impact if you don't have a valuation. It is important to understand that valuation is inherently fickle, even with monetary instruments (we don't have moving exchange rates for nothing). Time sensitivity and changes in perception can significantly impact a value judgment. The key is to run with the value information provided by senior management.
Another way is to consider the amount spent on the asset in question. Even a qualitative purchase decision must conclude that the spending is worth it at the point in time the purchase is made. This means that the amount spent, and any related costs can be used as a conservative estimate for value -- the asset must be worth at least as much as its costs (else the system should be shut down and/or r...
To continue reading for free, register below or login
To read more you must become a member of SearchFinancialSecurity.com
eplaced).
Transactions
In a broad sense, think of a transaction as any activity shared between a source and destination (or consumer and provider) that can result in a negative outcome. Network-layer attacks, for example, occur within flows, and program operations, application sessions, messages, and other forms of communication all fit this model. The important idea here is that the bad activities (i.e. attacks) are part of a set of activities that include a substantial portion of good activities. This helps provide historical information that can be used to measure risk.
Control events (successes and failures)
Security professionals deploy tools that scrutinize various aspects of the transactions above to make decisions about its efficacy. Sometimes, those decisions are correct and sometimes they are incorrect. Within this paradigm, then, there are four possible outcomes:
- A good transaction that is allowed to occur. This is a control success.
- A good transaction that is denied. This is a control failure.
- A bad transaction (e.g. attack) that is allowed. This is a control failure.
- A bad transaction that is denied. This is a control success.
Every time an inline security tool makes a decision, it can be put into one of these buckets for aggregation and analysis.
This model can be used to assess the effectiveness of authentication, user access control, firewalls, network and host intrusion prevention, antivirus and other forms of antimalware, and any other tool that is inline between the client and server for any session or transaction.
Incidents
Incidents are the special case outcome from the control events – the bad, allowed transaction. Clearly, these are the cases we want to minimize, though not necessarily at all costs. There may be diminishing marginal returns at some point.
Strategic metrics
It is common when considering metrics to think about high-level, strategic objectives like assessing risk levels and evaluating resource optimization strategies. It is important to recognize that strategic metrics aggregate data that might seem somewhat unrelated at first glance. This is no different than any strategic metrics in other areas, like price/earnings ratio in finance or sales per square foot in retail.
Here are a set of ten strategic metrics to shoot for in your own metrics program (first described by the author while at Burton Group):
- Transaction Value (TV) = (Total Value of IT and Information Assets $ / Total Transactions)
- Transaction Cost (TC) = (Total Cost of IT and Information Assets $ / Total Transactions)
- Controls per Transaction (CPT) = (Total Number of Inline Control Events / Total Transactions)
- Cost per Control (CPC) = (Total Cost of Control $ / Total Number of Inline Control Events)
- Security to Value Ratio (STV) = (Total Security Costs $ / Total Value of IT and Information Assets $)
- Loss to Value Ratio (LTV) = (Total Losses $ / Total Value of IT and Information Assets $)
- Control Effectiveness Ratio (CE) = ((Good Allowed Control Events + Bad Denied Control Events) / Total Number of Inline Control Events)
- Incidents per Million (IPM); Incidents per Billion (IPB) = ((Total Number of Incidents / Total Transactions) x One Million or Billion)
- Incident Prevention Rate (IPR) = (1 – (Total Incidents / (Good Denied + Total Incidents)))
- Risk Aversion Ratio (RAR) = (Good Denied / Total Incidents)
These are the metrics that add value to strategic decisions in information security. They may seem difficult, but any financial organization can start today with existing information. Pick a smaller, receptive business unit, a particular application, or even a security function and begin to identify value, cost, transactions, control effectiveness, and incidents to fully assess your security program.
About the author:
Pete Lindstrom is Research Director for Spire Security, an industry analyst firm focused on information security issues and market research.
