Measuring the Effectiveness of Your IT Security Program
An article review.
Simple metrics to measure your return on infosec investment
As with any investment, you want your infosec solutions to work and work well! You want to make sure that you’re getting a good return on your investment – a lot of bang for your buck. The question becomes: how do you actually measure your infosec ROI?
The folks over at DarkReading.com, a sister publication of Information Week, conducted a survey recently that asked that exact question of “security practitioners and pundits.” They wanted to see what metrics these professionals use to measure the effectiveness of their IT security solutions. This is the top 10 list that DarkReading.com put together based on their results.
- Average Time To Detect And Respond – This is simply how long it takes from the time an incident occurs to the time that your team is aware and responds to the incident. It’s worth noting that if you’re using infotex to monitor your network; our average response time (excluding automated blocks which are measured in microseconds) is less than 15 minutes.
- False Positive Reporting – Tracking the rate at which false positives are reported can tell you how well your first level of analysis is working.
- Mean Time To Fix Software Vulnerabilities – This metric is really crucial for companies that build their own custom software. In many cases, this time is not even tracked, so potentially crippling vulnerabilities remain in production for lengthy periods of time.
- Patch Latency – The length of time it takes for a patch to be installed from the time it was released.
- Incident Response Volume – By keeping track of the number of incident cases that are opened versus those that are closed or pending will measure how well issues are being noticed and fixed.
- Fully Revealed Incidents Rate – This metric takes into account how well your response team understands the reason for the security alert, along with its cause, effects, and other implications. If this metric is lower in comparison to overall volume of security cases that are opened, it could indicate a lack of training.
- Analytic Production Time – Measuring the time from data collection to data analysis can help you determine if your security program is experiencing information overload.
- Percent of Projects Completed On Time And On Budget – A simple calculation of both time and money can show accountability by realistically measuring if your recent security improvement projects are meeting their marks.
- Percentage Of Security Incidents Detected By An Automated Control – This metric can really pay off when trying to justify new equipment, because it proves that your automated controls are working and saving you money.
- Employee Behavior Metrics – Plainly, test your staff. Try some social engineering or phishing campaigns to test and measure how well your awareness training program is working. Then, help your staff learn from their mistakes.
Metrics are very important in governance, and this article proposes several creative measurements we don’t often see used in banks. Consider adding a few of these metrics into your security program assessments.
Click Here To Read the Full Article
The above is what we call an “Article Review.” It is part of our attempt to help our readers find excellent reading materials to back up important technology risk management concepts. We try not to include articles that are merely news or additional news about mainstream issues. Instead, we try to highlight articles that our “typical clients” should be sure to read, or that are about concepts “outside the mainstream media.” infotex does not intend to endorse views represented by the writers of the articles we review, nor do we try to keep our Clients aware of EVERYTHING. For example, if a particular story concept is being reported upon in many different media sources, infotex usually chooses to ignore the story concept altogether, unless we can find a “unique take” on the story concept.
Original article by Ericka Chickowski of DarkReading.com.