Security is the pest of the IT industry and, unfortunately, you can't ignore it.
Just as power usage effectiveness (PUE) is the gold standard for data center efficiency, security metrics prevent disasters, and deserve the same diligence. But the right metrics are hard to quantify.
Increasingly, CIOs rely on tangible evidence generated by metrics to guide big decisions. Data center metrics play a prominent role in corporate financial reports, and for good reason. The same strategy that gave data center managers the PUE metric can move into less tangible areas, like data center infrastructure security.
Here are some security metrics examples.
In terms of security metrics, blocked attacks or intrusion events are a logical starting point. Security administrators have tools that quantify data, visualize specific events and accommodate various scripting languages without much hassle. Easily graphed and easily understood by management, blocked intrusions offer tangible evidence that a security solution works. Next-generation firewalls, host-based intrusion systems and various antivirus software track what incoming traffic has been blocked or quarantined for later examination.
Any given data center will be victimized to one extent or another by intrusion events, and once such an event is discovered, it in fact becomes a metric.
Data centers force all incoming packets to traverse one or multiple gateways before reaching their final destination inside the IT architecture. At these gateways, existing security tools can obtain valuable information.
These sample security metrics are not as easily quantifiable as blocked attacks: How many connection refused messages are in the firewall logs? How many times a day does the firewall block packets that match certain signatures? Which signatures generate the most blocks? While not easily answered, these questions reveal vital information about firewall activity.
Intrusions not blocked
Antithetical to intrusions blocked, the intrusions not blocked security metric provides information that is equally important. Unfortunately, this metric is only examined when someone or something successfully attacks the network. For an investigation to ensue, the IT team must actually discover the intrusion.
In this hypothetical example, Data Center XYZ hosts various networks that geographically span the globe. Like most data centers, Data Center XYZ has a variety of intrusion prevention mechanisms implemented at the access layer. Unfortunately, criminals devise a new intrusion method for which no existing firewall signature exists. Malicious packets successfully traverse XYZ's access layer and infiltrate the network of one of its hosting clients in the data center. If the system administrators responsible for the target network don't maintain the utmost vigilance, the intrusion will go undetected for quite some time.
Invariably, any given data center will be victimized to one extent or another by intrusion events, and once such an event is discovered, it in fact becomes a metric. No one enjoys a trend analysis of intrusions they failed to stop, but the lessons learned from studying such events cannot be attained through any other means.
Some questions that can have metrics applied to them in XYZ's attack include: How many successful intrusions occurred within a given timeframe? How much time elapsed between the actual intrusion and its discovery, and what is the standard deviation?
Which firewall to choose