“What gets measured gets managed,” the famous words from Peter Drucker.
I’ve tried many ways of putting metrics around security initiatives. Some have been successful, some have been a failure, the worst have added confusion. Reporting cybersecurity metrics does have an important place in the security program. Visibility into initiatives and progress shows how successful or struggling a focus area can be. It allows leadership to help support issues. But with this reporting should come purpose and a clear story. It should also be a platform to bring up areas of concern and supporting it with numbers and data. I want to share three key principles on how to use metrics in your information security program.
How to use metrics in cybersecurity? Report on measurements that shows status and progress on cybersecurity initiatives and agreed upon goals. Show how systems are improving or degrading over time and be transparent. Be prepared to recommend how to address risk. Don’t report on static systems that don’t have a purpose of reporting metrics on.
Measure Initiatives
First, metrics should be used, whenever possible to measure progress on initiatives and goals. For example, if it was discovered that the vulnerability management program was lacking, and only 34% of assets were being reported on, then it might be agreed upon as a security initiative for the next six months to improve the vulnerability management program. From this initiative, an attainable goal can be set. That goal might be to ‘improve the vulnerability management program so that all server assets are scanned twice a month and a 20% sampling of workstations are scanned twice a month”.
This might be a poor example, but it is great in the sense that it’s a clear goal that can be measured.
The next step, now that we know it can be measured, is setting up a way to measure it. Most likely, in this case, you can take the total number of assets from your asset database, or from a map scan, and derive the goal numbers to measure progress against.
The last step is to decide how to report this. How you report can largely be influenced by your audience. Personally, I like to use the same axis we use for measuring risk, which is ‘time’ and ‘impact’. In this case, I will list time across the horizontal axis and impact on the vertical. The impact will be measured by assets scanned, and ideally, show an increase over time getting closer to a floating line that represents the goal.
Here are some examples of initiatives and metrics you can use:
- Remove all un-encrypted traffic outbound –> # of unique FTP sources communicating outbound
- Reduce PII data repositories to approved shares –> % of workstations / % of server shares scanned for PII syntax records
- Reduce End of Life Software by 50% –> # of applications identified / % of applications owners made aware.
So what happens when the initiative reaches its goal? Do we keep recording metrics and reporting on it?
That brings me to my next point.
Show Progress
Second, metrics should only be reported to show change and/or improvement in accordance with an initiative. Said another way; don’t keep recording metrics and reporting after the goal has been accomplished. The only exception I can think of where this makes sense is for security issues relating to compliance or governance. These are efforts that may need visibility consistently over time to ensure work is not being overlooked or neglected. Having metrics in these areas can ensure these day to day (or month to month) tasks are being handled and completed successfully.
An example of this might be:
- % security exceptions reviewed this month that were expiring
- % local admins reviewed for expiration
- % malware console in DMZ validated as receiving up to date signatures
- % of malware alerts responded to and investigated (or reverse it)
- # of malware alerts NOT investigated
- Time to respond, Time to Contain, Time to Remediate – for all security incidents
Why would I report to leadership how many malware alerts I did NOT respond to?
That brings me to my third point on cybersecurity metrics.
Metrics that Concern You
Third, report on things that concern YOU. Bring up the things that no one else would think about, the areas being neglected, the risk keeping you up at night, the bogey man in the closet that no one wants to talk about. Think about it past the fear, and put in the work to create some measurement around it. This takes effort. This is where you can shine and show your expertise. This is your opportunity to set yourself apart as an expert and show that your knowledge combined with your particular and unique experience is valuable. Throw an extra slide, or dashboard up there that your audience was not expecting and say, “in addition, I wanted to bring this issue to your attention.” If you put the time in, feel this is a real risk and issue, and communicate it (using metrics), it can also drive budget and additional staff. Some metrics I’ve created in the past for this purpose have been:
- # employees with USB write exceptions –> level of confidence of PII data leaving
- # of service account logins originating from user workstations –> privileged account access
- % of unknown application traffic traversing DMZ firewall –> known unknown
Red Flag Areas
I mentioned at the beginning, that in my attempt to create “great metrics” I’ve instead created confusion, and additional questions that in effect created time burdens. Here are some red flags areas I do NOT recommend putting metrics around:
- # attacks against our external firewall
- Leads to: Is this normal? What’s causing this? How do we reduce this? How do we compare to other companies?
- # failed login attempts
- # machines not rebooted in over 90 days (just report this directly to the desktop support team)
Conclusion
Cybersecurity metrics can greatly support the focus, efforts, and initiatives by the cybersecurity staff. They can also be useful to tell a story about why you as a cybersecurity professional are concerned about something. When you support your ideas and philosophies with numbers and measurements it can gain a lot more support and traction.
It’s good to be transparent with metrics meaning show the good with the bad. If the number of exploits in the wild that could impact your systems continues to grow, report on it. But be ready with a list of ideas and suggestions on what you can do as a business to address this risk through increasing your security capabilities, remediating systems, or other mitigation technics.
Metrics should focus on cybersecurity initiatives. They should be displayed in a way that is short, to the point, and clear. Don’t report metrics that are outside your focus area, and don’t report more just to show more data. Also, don’t report metrics on systems that are stable on don’t have dynamic data.
What are some security metrics that you’ve used or think are valuable? Please share them in the comments section so we can all use them to build better cybersecurity programs.
Asher Security helps Minnesota businesses lower their risk by partnering with them to increase the maturity of their cybersecurity programs. If you’re interested in learning more call us directly or fill out the contact form. We look forward to speaking with you.
Recent Comments