|
In recent years, IT security has been taking on an ever greater significance in the enterprise due to the recurrence of high profile security breaches and data losses, underscoring the importance of IT security and scrutiny by executives. With IT security becoming a primary concern, the need for measuring it has been clearly recognized. As a consequence, there have been various efforts to define and calculate security metrics and risk, in particular. Examples of such efforts are a scoring system for the "exploitability" of a vulnerability and systems to calculate security risk metrics for data and availability of a server or device in the context of its infrastructure environment. With these efforts, managing security risk is emerging as its own discipline with new interesting technologies having now become generally available this year.
While the efforts described above are important steps towards measuring information security, interesting challenges remain to make such metrics useable for IT staff of enterprises and service providers – defining metrics for multiple audiences, making security risk feedback actionable, change and causality, and streamlining security data gathering.
Well-Defined Semantics
Let’s say a risk score calculation shows that risk = 42 for a database server, does that risk score mean the same thing to the IT operations person, the CIO and even the CFO? Is it a way to prioritize servers, so that another server with risk = 56 needs to be mitigated first? Or is it a way to assess the risk in absolute terms (e.g, risk = 42 is always acceptable, but risk = 56 is always bad)? Or is this number related to financial or revenue loss? Different answers determine the suitability of an audience of the metrics and how they need to be calculated.
Currently, there does not seem to be a well-defined distinction of metrics along those lines. As a result efforts are underway with interested parties in the field, like those participating in Metricon (see: www.securitymetrics.org) to help define such a scale for broad use. At the same time, systems providing a security risk scoring system to end users assess risk scores within the context of a network or security environment. Its output is a score of the security posture of network elements (i.e. servers and subnets) based on an analysis of that specific environment. This is essential because without such a system, there is no way for an IT or security administrator to gauge how defense systems are performing together and what their overall contribution is to the network’s security posture.
The Question of Actionability
Simply showing that the risk of a given server is high is not nearly as useful as showing the most promising available actions to mitigate that given risk. There are potentially a multitude of operational tasks that can mitigate a given risk factor, such as deploying a patch on the server with the risk, changing a network device configuration (e.g., firewall, router) to block the flow of a threat, or even patching a different server that causes the exposure/risk of the given server. Typically, attack graphs are used to calculate and visualize some aspects of causality. But such graphs are typically complex and not actionable. Graphs however still offer some promise in terms of breaking down complexity to clearly visualize and map threat flow through the network, clearly indicating where to most effectively initiate remediation.
Initial work on these graphs has labeled these graphical depictions as “threat maps.” The basic premise is to graphically display in the form of arrows how an attacker from the Internet or other untrusted sources can traverse the network and gain unauthorized access to critical resources. Groups such as Metricon are working towards a standard way of conducting and visualizing this sort of analysis. At the same time, some vendors currently offer systems that present threat graphs, but as is the case when there is no prevalent standard, these offerings do so from the perspective and competency of the vendor. Consequently the degree of intuitiveness and usability of these threat graphs varies greatly. It is important that end users of such systems conduct hands on evaluation of such products as well as participate in discussions and efforts to standardize the output.
Change and Causality
In large environments, operations people are already presented with more security data than they possibly can consume. This data often comes in from multiple sources such as vulnerability assessment scan results, patch system information, security product logs and events, etc. When a security breach occurs, a new threat becomes known, or changes are made to the security policies of devices, network administrators must often manually pore over the copious amount of data in order to find out what damage if any has been incurred in the network. In such situations, a view into the complete infrastructure is less useful than a concise summary of what has changed since the breach, threat release or change.
What network administrators and security professionals are looking for in this data is the degree to which these events have been responsible for catalyzing a negative change in the security effectiveness of the network. Another way of stating this challenge, is a question of what has changed since the last time risk had been calculated and what is the current risk score. This knowledge becomes very important in determining the amount of resources and effort that are applied toward mitigation. In some instances, for example, a certain amount of risk may be acceptable and thus there is no need to comb through large amounts of data.
A delta view should also be coupled with a sense of causality: “Why has the risk of the credit card database server gone up by 50 percent?” Root cause analysis is by now an established discipline for network event management (with commercial products such as SMARTS/EMC and NerveCenter), but until recently, no such solution has existed for network security risk, a discipline that deals in the configuration of the network and the analysis of that configuration before a security event or network breach occurs.
Intelligent Input Gathering
In most environments, a wide variety of inputs are needed to arrive at an informative risk score. The best and most accurate risk calculation is not very useful in practice when there is a lot of manual, time-consuming input gathering. Such a manual process will invariably lead to error-prone and stale inputs -- not to mention a hurdle to adoption.
To add intelligence to input gathering, a technology is required that can prioritize input requirements, automatically collect and merge obtained data, and, quite possibly, run calculations in the presence of incomplete data. For instance, some networks only use firewall and router access control lists at the perimeter of the network to enforce authorized access and would need to base any risk score on only firewall and routers data. Other enterprises supplement their routers and firewalls with additional security in the form of intrusion prevention systems, vulnerability scanners, and patch management systems, to name a few.
Regardless of the technologies in place, however, all enterprises need to understand the overall security picture for their network and how to best take action to maintain the security score at a desired level. The process and system for creating the aggregate network view therefore should be flexible enough to be able to work with merely firewall data and adjust to accommodate any additional detail about the network and its elements when that data becomes available. In this way for instance, an IT administrator who plans to add vulnerability scanning or system patching to the network sometime in the future, does not have to wait to implement proactive security risk management. Rather, the system will draw the aggregate network threat picture and fine tune its granularity with the output of VA scans once they become available.
Proactive security risk management as a discipline has enormous potential, due to the proactive risk mitigation that it represents. However, to achieve this potential, systems for managing security risk will have to address the four key challenges described in the previous section. The good news is these shortcomings are spurring, in short order, interesting research and innovative technologies to address a prevalent challenge in most IT organizations -- quantifying and mitigating network security risk ahead of a breach. Given the interest in this space, we hope that standardizations and infrastructure benchmarking will receive sufficient attention. In the meantime, technologies to accomplish security risk management have become generally available, and are broadening in use. As such, security risk management systems are providing a good reference point for any discussion on standardizing risk scoring and risk visualization.
About the Author:
Johnnie Konstantas, Senior Product Director, RedSeal Systems.
Go Back
|
