Vulnerability Intelligence

Vulnerability Intelligence is a foundational capability introduced in Alert Manager Enterprise (AME). It empowers organizations to identify, prioritize, and manage vulnerabilities efficiently, bridging the gap between raw detection data and actionable security operations.

Thanks to its robust integration with Splunk and its deep visibility into organizational logging data, AME stands out as a powerful enabler of the Vulnerability Intelligence process.

info

Vulnerability Intelligence requires an AME Security Pack Subscription: Please contact Datapunctum Sales for an evaluation license

What You Can Do with AME's Vulnerability Intelligence

• Correlate vulnerability data with asset intelligence to expose security weaknesses and blind spots
• Manage the entire vulnerability lifecycle, from detection through confirmation, acceptance, and remediation
• Leverage Observables and Risk frameworks to identify critical business assets and focus efforts where they matter most
• Apply granular SLAs to establish patch compliance across different tiers of your infrastructure
• Enforce and track vulnerability exclusions and acceptances to meet compliance and audit standards
• Achieve alignment with frameworks such as PCI DSS, ISO 27001, and NIST for vulnerability controls

Terminology

info

Familiarise yourself with the following terms used in AME and the Vulnerability Intelligence Framework

Vulnerability: A known weakness or flaw in a system or application
Realization: A live instance of a vulnerability detected and ingested by AME (e.g., a CVE detected on a specific host)
Realization Rule: Defines how a Realization is processed to create an AME Event
Risk Event: A container tied to an AME Event that models active or inactive risk associated with Observables
Alert: A triggered signal within AME, part of a larger Event
Event: An aggregation of alerts and/or realizations in AME
Ticket: A linked issue in a third-party ticketing tool (eg: ServiceNow) created optionally from an AME Event
SLA: A Service Level Agreement defining expected remediation timelines

Overview

Pre-Requisits

To fully utilize Vulnerability Intelligence, ensure the following components are in place:

• An active API key from the NVD
• Asset data ingested through the AME Observable Engine
• Vulnerability data indexed in Splunk (with CVEs and asset identifiers such as IP or hostname)
• Optionally, third-party ticketing system integration (e.g., ServiceNow)

AME makes extensive use of the Observables Framework to manage vulnerabilities and risks across organizational assets. Customers may also use Ticketing Integration for escalation workflows.

Implementation Steps

Overview

1. Leverage the Observable Framework to ingest organizational assets. Use Observable Groups to define logical units such as departments or PCI zones. Tag each asset's criticality to enhance integration with the Risk Framework and improve prioritization.
2. Ensure your Vulnerability Data is available in Splunk

• AME does not have any prescription on the data source, save for the presence of the identified vulnerability (CVE) as well as the identified asset (hostname, ip, etc)
• Feeds can be from your internal or external vulnerability scanners, as long as the data is present in Splunk and the Vulnerability and Asset fields are present

3. Build a search to target your vulnerability data

• A simple search to bring back the asset and vulnerability data
• You can support multiple vulnerability sources using multiple searches
• Ingest the results to the Vulnerability Management Engine via the AME Realization Alert Action to start tracking your vulnerabilities

4. Build a realization rule to turn Vulnerability Data into actionable AME Events

• (Optionally) Integrate with your Ticketing System to track third-party remediation efforts

5. Build any Exclusion rules to track exceptions and acceptances in your environment
6. Track Remediation and Metrics

Implementation Guide

1. Ingest your Asset data via the Observable Framework

A complete page is available detailing how to ingest assets through the Observable Framework. This integration ensures vulnerabilities are accurately modeled against their corresponding assets. Observable Groups—representing departments, business units, or PCI zones—enable logical segmentation for targeted vulnerability management.

To maximize effectiveness, ensure that imported asset data includes accurate criticality ratings. This alignment allows full integration with AME's Risk Framework.

The Screenshot below shows an example of a successful import of asset data via the Observable Framework:

2. Ensure your vulnerability data (detections) are available in Splunk

Results of vulnerability feeds and logs vary differently across vendors and products. It is typical for an organization to have one or more of the following:

• Results of on-prem scanning engines; including network scanners, authenticated scanning engines, etc
• Results of cloud based scanning engines, or externally facing scans
• Curated feeds of exposed vulnerabilities data from Service Providers
• Any feed producing Vulnerability data containing CVEs, State and Asset Identifier (ip, hostname, etc)

Typically these scanning engines run at set intervals to continuously identify vulnerabilities in your environment. They report on active vulnerabilities discovered or present in the environment. The Vulnerability Feed can be integrated into AME by crafting a Saved Alert with defined Schedule for your source.

3. Build a search to target your vulnerability data

Once you have identified the data source that targets the vulnerability data you wish to ingest into AME, you can setup a Saved Search.

Build a search to target a Vulnerability Source as per above. You should save this search as an Alert, together with an execution frequency. It is important that the results of the alert is sent to the Ingest Vulnerability Realizations Alert Action:

For each matching search entry and Observable, a realization is created. As per the dialogue above, your search needs to supply the following fields:

info

Search Requirements (fields)

status: active OR fixed
cve: The identifier of the CVE, eg: CVE-2025-21311
value: The value to compare against the Observable field (match_field). Eg: for IP, the IP address of the Observable.
match_field: A name of an Observable field, this field will be used as comparison, together with the value field above. It is important to note that this is a field in your observable data, and can be ip, hostname, etc; depending on what is used in your environment.
first_seen, last_seen (optional): To set the first and last seen dates of the Realization

The Alert Action also requires the following parameters to be set. The target tenant, together with the Observable type and match field

For optimal results, set the “Trigger Once” attribute for the event. This ensures the Alert Action is called once for all results, and not executed many times individually:

Once you have saved the search, and it has executed once, you should now find these Realizations under the Vulnerability Intelligence section of the AME UI:

4. Build a realization rule to turn Vulnerability Data into actionable AME Events

Realization rules are the bridge that can be used to actively manage and track Vulnerabilities. Realization rules also define other interactions with Alert Manager Enterprise, such as the ability to modify risk_scores for assets matching a Vulnerability.

For our example, we will only start to track Realizations as Events once our realiztions satisfy certain conditions. For our first realization rule, we wish to create AME events for all of the critical vulnerabilities, as soon as they are processed by the Realization Engine

info

Realization Rules are processed once daily by default

We have also defined an AME event template (under Tenant configuration), to distinguish Events created from the Realization Engine, vs other events in our environment:

We are able to group AME events by fields of our Realizations. This makes sense if we want to track a group of vulnerabilities as part of a single AME event. You could implement one of the following by selecting a corresponding group by element:

• Create an AME event for a vulnerability for all assets in a department (Observability Group): Group by CVE and Observable Group
• Create an AME event for a vulnerability across all departments: Group by CVE
• Create an AME event for all vulnerabilities on an observable: Group by Observable

For the example above, we create an AME event for each Observable Group where a CVE is identified (group by: Observable Group + CVE)

We include a Risk Modifier, which will be applied to the matching Observable, together with the evaluation logic that selects critical vulnerabilities from Realizations.

You can add any number of fields to the created event that is available in the event context. For the full list of options, please refer to the following page ((default contexts))

Once the Realization Engine matches a Realization Rule, an AME event will be created for the Realization.

info

Multiple Realization Rules can match the same Realization (vulnerability) on an Observable (Asset) depending on your matching rules. In such cases there will be more than one AME Event for the matched Realization as well as a corresponding Risk Event entry.

Once the event has been created by the Realization Engine, it can be managed as par the normal processes you have defined in AME.

5. Build Exclusion Rules to Track Accepted Risks

Often Vulnerabilities need to be excluded from tracking, often for some legitimate business reason, for a number of reasons, such as availability. These exclusions need to be carefully managed and defined, and often applies for a limited time-period. Some environments may also require these exclusions to be signed off by a risk-offer.

The exclusion rules allows you to satisfy these use-cases and define rules to manage these exclusions. The Vulnerability Intelligence framework still allows you to report on these matching exclusions, without creating corresponding AME events.

In the example below, we add a specific exclusion for a Vulnerability for the Defined Observability group (Legacy Systems):

It is important that Exclusion Rules are periodically reviewed and removed when/if the exclusion rule no longer applies.

Track Remediation and Metrics

There are two reporting options available in AME, dashboards to track the Realization metrics in real-time (execution time of Realization Modular Input), or general indicators. You will find these under the Reports section of the Main AME menu and the Realizations dashboard in the Vulnerability Intelligence sections respectively.

We intend to extend the dashboards and reports in future versions.

Advanced User

Staged Realizations

As mentioned in the requirements, to make optimal use of the Vulnerability Intelligence framework it is important to ensure your observables (Assets) are available in the Observable Framework. In the case where a Vulnerability was seen for an unknown Observable, this could point to a gap in visibility of your asset data, and a vulnerability on a potentially un-managed host.

The Staged Overview Screen provides an interface where these can be identified. For any identified items it is recommended to augment the Observable data with the asset in question. Staged Realizations are automatically removed after a defined period of time, see Configuration Options for Tenant below.

As mentioned, these staged realizations can provide a view of tangible risks in the organisation which may by not be visible when considering standard asset management process. It is highly recommended that these Realizations are fed back into your asset augmentation and discovery processes.

Overwriting information on CVEs

For advanced use-cases it is possible that you wish to overwrite certain CVE metadata for a vulnerability. This can be done on an individual CVE ID. An Overwrite rule can be defined to match a CVE and overwrite any of the CVE meta fields. For example, a secondary work around could exists that has been implemented to render the exploitability of a CVE redunant. In this case the Exploitability value for this vulnerability can be set explicitly to “No/False” in the environment.

info

The following fields can be overwritten:

Title
CNA
Description
CVSSVersion
CVSSScore
CVSSSeverity
CVSSVector
CVSSSource
Exploitable
EPSS
CWE
CAPEC
Vendor
Products

Reporting

Scheduled Reporting

AME Vulnerability Intelligence contains extensive Reporting Capabilities.

Reports can be scheduled and customized and send to specific recipients based on Observables Reporting Groups.

To create a new reporting configuration open the Reporting tab and select Add Vulnerability Report. Following Modal is opened:

Enter the recipient, the cron schedule and customize the report by uploading a base64 logo and color scheme.

Additionally filter the realizations to be reported by Realization Status, Time field and Lookback days. Reporting can be enabled/disabled using the Active checkbox.

After saving the base configuration, the report content must be configured:

A report consists of one or more section. A section can be of type:

• Markdown Content
• Page Break
• Obeservable Group Summary

Markdown Summary

Markdown can be placed in the report to describe the content.

Page Break

The report can be broken into multiple pages, This is used if the HTML Report is printed.

Observable Group Summary

This section is used to configure the Vulnerability Report Data.

Following options are available:

• Observable Type: Asset or Identity
• Observable Groups: A list of Observable Groups to be included in the report
• Observable Reporting Groups: A list of Observable Reporting Groups to be included in the report
• CVE Fields: The CVE fields that will be displayed in the report table
• Observable Fields: The Observable Fields that will be displayed in the table
• Observable Group Fields. The Observable Group Fields that will be displayed in the table.

Reporting Commands

amevulnintrealizations

All Realization Rules are evaluated daily by the Vulnerability Intelligence Framework. To gain more insights into the daily activities of the Realization Engine, the results can be perused with the reporting command amevulnintrealizations.

For command options see here

Configuration Options for Tenant

You can configure the individual tenant options for the Vulnerability Intelligence Engine. The following configuration items are available:

Days until a unfixed, unseen realization is marked as fixed

Vulnerabilities are continuously evaluated in your environment. It is often possible that Vulnerabilities are not explicitly reported as fixed when the Vulnerability is no longer reported by the scanning engine. In these cases, you can set them to fixed after this set period of time. Please note that it is till important to track any assets that may disappear from the environment through the Observable Framework

Days until a fixed realization is removed

Once a Realization is fixed, it is still kept in the KV-store for reporting purposes. The information is also written to an index for long term storage. This setting can be used to manage the history period to be kept until removal.

Days until a staged realization is removed

For Realizations not matching any Observable data, these are reported under the Staged Realizations section of the VI UI. This setting defines the period that these will be kept, until automatically removed.

Days into the future realization rules are evaluated for matching

The Vulnerability Engine allows for multiple realization rules to be evaluated, also featuring the age of vulnerabilities. This defines the number of days into the future these metrics should be evaluated. This opens up reporting and tracking options to manage maturing Vulnerabilities

Auto-Resolve status

For created AME Events; once all of the active risk events created by the Realization Engine have been remediated, these can be closed automatically with a defined status.

Configuration Options for AME

Global configuration options for the Vulnerability Intelligence engine can be found under the Vulnerability Config tab on the main Configuration page.

AME Supports fetching Vulnerabilities from an authoritative source, in this case utilizing the NIST NVD API. The NIST National Vulnerability Database (NVD) is a service that is available for Public Use, that users and developers can use to obtain CVE information. These are fetched once per day. The API is free to use according to the terms laid out by NIST. More information can be found here: [ https://nvd.nist.gov/developers/request-an-api-key ]

The following configuration parameters are available:

API-Key: As described above

Start Date: Do not ingest Vulnerabilities published before this date

For more information, see:
Observables, SLAs, Tenants