Evolving Vulnerability Management with SIEMs: VM with Elastic

How I utilise Elastic SIEM for maturing vulnerability management and improving cyber security culture.

Vulnerability Management (VM) generates a lot of data. A Windows workstation misses one Microsoft Patch Tuesday and all of a sudden detections are throwing up 700 inherited CVEs that you’re vulnerable to. You finally convince your system architects to deploy your Tenable/Qualys agent and now your network is lit up like a very insecure Christmas tree. Managing the data in-platform can often be restrictive, and exporting too many CSVs into MS Office can lead to a weird Stockholm Syndrome-type relationship with Excel (they’ll never take you away from me).

One of the biggest game-changers for me in VM was getting comfortable with using a SIEM to tailor the vulnerability management approach for the way I wanted it to work. No more playing with clunky dashboard interfaces and a moderate reduction in PivotTables and spreadsheets.

This post will cover my high-level approach to managing an effective data flow for VM using Elastic. I’ll be following this post up with a deep-dive into the dashboards I use and some principles for effective VM dashboarding. Consider subscribing if you’d like to be informed when this goes live.

Why SIEM for Vulnerability Management?

First things first, why bother with this approach? There are pros and cons to this type of implementation and you have to understand both the benefits realised and the undertaking to get there.

Pros

• Combines multiple vulnerability feeds in one place, no more hopping between tools.

• Correlate vulnerability data with security event data to better feed into incident response process.

• Utilise multiple sources of data, not just reliant on what vulnerability tools will give you.

• Single Pane of Glass approach to VM that consolidates with other internal data sources

Cons

• Additional licensing costs beyond existing VM tools.

• Requires specialised knowledge for setup, configuration, and management (or the cost of hiring skilled personnel)

• Can be some time before you have a ready-to-go solution that’s appropriately scalable.

Don’t underestimate the time, knowledge, and cost required to effectively maintain a SIEM, even if just for vulnerability purposes. SaaS options like Elastic Cloud available; however, you must still be comfortable managing APIs, data indices, data normalisation, and all the other ‘fun stuff’ to get the solution off the ground.

Principles of VM in SIEMs

How can you identify if a SIEM integration is needed and, if already implemented, whether it is providing the value it could be? There are 4 key principles I follow:

1. Completeness - I have all the vulnerability data I need for all of my assets.

2. Maturity - I can use enhanced vulnerability intelligence to better filter and control my vulnerability data.

3. Fit for purpose - The solution works within the organisation’s operating parameters and provides value that directly aligns with organisational goals.

4. Scalability - The solution can grow seamlessly as our VM needs expand.

Architecture and Data Flow

I’ve included two high-level diagrams (HLDs) that represent how I matured one organisation’s vulnerability management process.

This environment has over 20,000 VM-scannable endpoints and two VM tools in place. The organisation has opted to scan server devices with Tenable and workstations with CrowdStrike. Two vulnerability scanning tools in the same environment can create inconsistency in VM approach, however it is essential to this organisation’s end user strategy and thus must be catered to.

Original Implementation and Process

In the above HLD, there are various elements that make the VM approach clunky and not fit for purpose:

• VM Team central to all processes

  • High degree of dependency.

  • Time-consuming manual processes.

  • Not enough staff to handle an organisation of this size.

• End users access platforms directly

  • Potential issues with separation of duties / RBAC / PAM - you don’t want users impacting scans or accepting their own vulnerabilities.

  • Two different platforms for vulnerability data adds complexity/barriers and reduces buy-in from stakeholders.

  • Data is presented inconsistently across platforms.

  • Filtering based on stakeholder requirements is complicated or unachievable.

• Additional vulnerability intelligence is manually integrated

  • Increases time to respond and fully consider impact of identified / emerging vulnerabilities.

  • No ability to do more effective filtering of data based on certain characteristics, i.e. ownership, service, network location, exploitability.

• Manual reporting using inefficient processes/tooling

  • Can be more difficult to present concise and valuable data to stakeholders.

  • Lack of consistency in VM Team approach to reporting, dependent on Excel competency and individual approach to data presentation / attention to detail.

  • No use of automation. Increases response time to send detail to stakeholders.

While there are some significant issues with this design, this is a relatively common, albeit immature approach to an organisation’s vulnerability management. The organisation has invested in a vulnerability scanning tool, and now they want their vulnerabilities dealt with as quickly as possible. It’s workable, but it doesn’t meet our principles.

Matured Process with SIEM

The above HLD shows the improvements made to the VM process through introduction of a SIEM.

The input feeds are split into 3 sections:

• Vulnerability Scanning - Any VM scanning performed by the organisation on its owned technology assets.

• Vulnerability Intelligence - External information sources that enhance VM capabilities by providing additional intelligence/insights.

• Proprietary Enriching Information - Internal data that adds further context or intelligence, further enriching VM capabilities.

All the data is consolidated into Elasticsearch, where it is indexed into usable fields. Kibana is then used to create user-facing dashboards and reports by leveraging this data.

Through making the changes, several problems are addressed:

• Centralisation of Elastic SIEM

  • All data is now fed into Elastic and normalised.

  • Overheads on VM Team are reduced, freeing up resource to focus on strategic improvements, vulnerability research, and threat hunting.

  • Enables consistent dashboarding.

  • Enables automated alerting.

  • Enables secure stakeholder access for strategic vulnerability response.

• Automatic data feeds and integrated intelligence

  • Both VM products now present the same data within the SIEM, creating a ‘source of truth’ for stakeholders.

  • Intelligence feeds are integrated which enriches data from VM product.

  • Greater ability to prioritise vulnerabilities to focus on material security threats.

• Internal asset information integrated

  • Accurate ownership assigned to vulnerabilities enables accountability.

  • Allows ‘gamification’ of vulnerability remediation across organisation.

  • Internal environmental information helps to determine asset criticality, and thus better prioritisation.

• Better dashboards, reporting, user access, RBAC, and PAM

  • Single Pane of Glass approach to VM.

  • Non-security stakeholders have a secure, role-based access mechanism to view their vulnerabilities.

  • Defined rules send automated alerts to stakeholders at point of data ingestion, significantly reducing ‘time to respond’ (TTR).

  • Dashboards are easily tailored to each stakeholder’s needs, from operational engineers to senior leaders.

The new process addresses some of the major issues in the original design and meets the key principles defined earlier.

1. Completeness - Solution can ingest all VM data in scope.

2. Maturity - With integrated internal and external intelligence feeds, I can better prioritise my vulnerabilities and enable my stakeholders to remediate them.

3. Fit for purpose - The organisation’s technical product strategy remains intact and the solution can handle a future shift if necessary. New approach ensures that invested resources are more efficient and provide a greater return on investment.

4. Scalability - The solution will scale for the organisation’s needs for the foreseeable future.¹

In conclusion…

As someone who has worked in organisations both with and without a SIEM, I’ve become a bit of a convert to having one. There is an incredible amount of control that SIEMs give over data and presentation of that data that I think has a significant impact on culture and buy-in for vulnerability management.

VM can sometimes be a bit of a war of attrition. There are new vulnerabilities reported every day and there isn’t enough time or neurons available in my head to care about all of them. If you can give people the data that they need, in the format that they want it in, with as few barriers as possible, that clearly states ‘FIX THESE’, with intelligence to back up why… then you’re already winning half the battle. SIEMs help me to get there quickly and achieve these goals.

There is a fundamental difference between security and patching. Not all patching improves security, but security will suffer without patching. It’s your job to laser focus on the material security threats to the organisation and to invest your time into the processes and procedures that enable you to do this.

My next post will be all about dashboarding with Elastic where I’ll show off some of my creations and discuss my approach to dashboards and how I make them readable and effective. Consider subscribing to be notified when this is released!

Acknowledgements

My Elastic goblins Security Engineers who are excellent at what they do and keep the platform running (relatively) smoothly.

Clement Fouque, whose blog I saw 18 months ago that inspired a lot of work that was done internally for this process (and who’s architecture design I shamelessly repurposed for this blog). Consider following him for far more detailed technical guides for enhancing VM with Elastic and Qualys.

Elastic in general, who were very helpful with tips on setting up a test environment for this and future posts.

Extra Reading

1. With appropriate investment and support/maintenance.