Maksim Kabakou - Fotolia
As a tool for the construction of stable and useful cyber security practice in an organisation, security analytics is as versatile as they come. With multiple uses, if deployed correctly and efficiently, it can set the tone for the rest of the security efforts, introducing efficiencies, covering gaps and alerting managers to potential risks.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
All organisations of any reasonable size can benefit from some degree of security analytics. At the most basic, this might just be to have a single, master analysis of the open security risks.
At the beginning, to see what security analytics an organisation might benefit from, I would typically analyse the primary products and services it delivers, then how any security events had impacted or interfered with those operations. It is essential that an organisation’s security analytics fits the business itself, and that means a high degree of tailoring.
By running some basic root cause analysis on the most significant incidents, it is usually possible to identify what analytics might help to get those situations under control. This will have the benefit of allowing the security team to demonstrate to the business executive overseeing the programme where we are – and show the progress as we address the primary security problems.
However, when it comes to security analytics, each organisation can easily be overwhelmed by the options. One of the most frequent problems I see is simply that an organisation fails to understand from the start which security metrics and analysis results will provide it with the best return for its efforts.
If an organisation first establishes which questions it expects the security analytics to answer – and how it will use those metrics once they are available – it is more likely to be able to use the information to help improve its security position by identifying its remediation priorities.
I have found that a good approach is to first consider and design which metrics and key performance indicators (KPIs) the business executive overseeing the programme will expect and need. One option is to design the executive summary view of the metrics first, then define what operational analytical information will need to be collated to make that view possible.
Where to look
With that caveat, there are a lot of areas where security analytics can provide serious value.
When security analytics is working effectively, it can provide an easy way to visualise large amounts of information in order to identify trends or patterns more easily. Those patterns often highlight both strengths and weaknesses in an organisation’s security position.
As a first example, imagine you are performing frequent penetration testing across a large number of applications. Each of the test results in isolation has value, as you will be testing a specific area of the business and discovering vulnerabilities. However, an aggregated view of all the “live” or open issues can identify potential patterns that will allow more efficient rectification.
Read more about Security Think Tank articles about security analytics
Perhaps you have a number of applications that have the same major or critical issue that can be addressed by a single action, instead of leaving multiple teams to invent and implement their own solutions independently.
The same kind of approach can be applied in incident management metrics. Understanding patterns of when security problems are detected, which problems are repeating, and how quickly or slowly they are resolved can help to drive improvements more efficiently to ensure fewer incidents are experienced, and that those that do come through are detected earlier and resolved sooner.
Which security analytics will be most important to each organisation will be driven by what it does. Going back to our first example, aggregating penetration test results would only make sense if an organisation is running many different applications and running those types of tests regularly.
Risks and pitfalls
One big problem with security analytics is that it can only analyse what you are measuring. An organisation can look great on the security analytics dashboard, but still have major, and invisible, gaps in areas that are simply not being measured by the system.
Another problem can be the phenomenon known as “analysis paralysis”. If an organisation collects a huge amount of data without a way to understand the comparative priority of the issues, or if the source data itself is a mess, the output can be equally messy. As the old phrase goes – if you put garbage in, you get garbage out.
With a lot of market competition from suppliers, buyers must beware of nebulous or low-value solutions that offer to “do anything you ask for”. It is quite hard for an individual organisation to be expert in how to design security analytics. So, when looking for a solution, I would ask any supplier questions like these:
- How long will the security analytics take to set up?
- What tangible value and business benefits will they bring within the first few months once they are implemented?
- Does the set-up depend on how well we (the customer) can define our needs or is the configuration made ready for us based on the suppliers’ industry experience?
Probably the two most important questions I ask myself when designing a system like this are:
- Is the interface easy to understand and use?
- Could I put a summary of the metrics in front of an executive so they can understand the value it is delivering?
If the audience (the executive) does not find value and insight in the analytics, then we should go back to the drawing board.
Although the technology is complex, the solution need not be. A good security analytics solution should be:
- Easy to set up.
- Quick to implement.
- Able to deliver high-value results quickly.
- Easy for my staff to operate and for my executives to understand.
- Include easy ways to filter and analyse the information.