♪ From «solved» a «closed»: When threat intelligence changes the weight of a vulnerability

A vulnerability classified as media can become urgent from day to day, and an installed patch does not guarantee that the risk is gone. We are working on two SentinelSuite features that address these two points.

> Status: development features, available only in the PRO edition of SentinelSuite. In this article we tell the method and benefits; we do not announce release dates.

> Why only PROS: both scenarios arise from integration between tools and require CyberSheppard and IntelliDog, which are not part of the Community edition.

> What integration means: tools are connected to each other in the configuration phase, switching keys with which they recognize each other. Once connected, events are sent («I found this»), ask for information («Is this IP in your inventory?») and react according to rules, the playbooks, defined in CyberSheppard and enabled one by one. Without this configuration each tool works on its own, and the scenarios described are not possible. They are also independent of llm and mcp agents, it is possible to use them together but in fact they are not too close to each other, they are the tools that dialogue with each other to exploit all their potential to the best.

♪ The problem: risk is not a fixed number

Most of the processes of vulnerability management reassess the risk to the rhythm of scans. Meanwhile the context changes: a CVE that no one used yesterday can be at the centre of an active campaign. And when the patch is installed the ticket closes, even if the host may have been compromised before the update.

SentinelSuite consists of tools that see different parts of the same problem:

– SentinelCore manages vulnerabilities and recoveries based on the real risk of asset, KEV and EPSS;

– FireDog controls network traffic and assigns a risk score to IPs;

– CyberSheppard apply hardening and correlate host events on the MITRE ATT& matrix CKK

– IntelliDog, CyberSheppard's threat intelligence module, collects compromise indicators from sources such as MISP, Shodan, AbuseIPDB and AlienVault.

The two features arise from working them together.

## Scenario 1: from the compromise indicator to the coordinated remediation

1. Hunting the historian. IntelliDog acquires continuous indicators. Once a week he performs a search on the history of data of all tools; when a strong signal arrives, like a CVE added to the KEV catalog or an active campaign reported in MISP, immediately a targeted research on that only vulnerability begins.

2. Risk changes. The search finds on our servers a CVE that the risk engine had classified as an average. Now it is exploited in an active campaign: SentinelCore raises the risk, remediation becomes a priority, asset managers receive the request and a remediation plan. The correction is first tested on the test clones and preproduction of the hosts, then brought into production.

3. Those who have already spoken to the attacker. IntelliDog crosses indicators with traffic observed by FireDog and finds hosts who contacted botnet IPs and command and control servers linked to the same campaign. Hosts are divided into three groups:

– CVE present and contact occurred: probable accident, to be managed as such;

– contact without CVE: different carrier or false positive, to investigate;

– CVE without contact: priority remediation.

4. Keep traffic. FireDog blocks the external IPs involved and from that moment saves direct traffic to them. The block takes into account the reliability and age of each indicator, because many IPs belong to shared infrastructure such as CDN and hosting, and blocking them blindly would interrupt legitimate services.

5. Watch the hosts. CyberSheppard checks whether the exposed service has an AppArmor profile and activates audit rules on typical exploitation behaviors, for example starting from public Sigma rules for the CVE, all vulnerable hosts or contacting suspicious IPs.

6. One case. All actions are related to the same campaign. When the case closes, the temporary rules expire on their own; those that are worth keeping remain.

Automatic responses are divided into two classes. Monitoring, which doesn't block anything, can start alone. Those intrusives pass by AI agents who use only predefined tools, never free commands, are tested on test clones and, unless different customer choice, require a person’s approval.

## Scenario 2: solved does not mean closed

We distinguish two states:

– Fixed: correction is installed. We verify it by comparing the packages or updates present on the host with official vendor alerts, in OVAL format for Linux and CSAF distributions where available.

– Closed: the vulnerability is resolved and exceeded three controls:

– CyberSheppard reloads hardening controls on the host;

– FireDog checks that the service is no longer exposed as before;

– IntelliDog performs a targeted research to exclude that the attacker has left a persistence.

Only when all three are negative the case closes, and the outcome of the controls remains recorded with date and source as evidence for audits.

## How mature this feature is

Think of vulnerability management as a scale:

1. scan and patch in CVSS score order;

2. Real risk-based priorities: known exploitation (KEV), probability of exploitation (EPSS), asset importance. It is the point where SentinelCore already works today;

3. updated threat intelligence priorities and coordinated response between network, host and vulnerability management;

4. verified closure, with preserved evidence.

The two features described lead to steps 3 and 4. It is a level that requires already solid processes: an updated inventory, test environments, team with clear responsibilities. For this the feature is optional, it activates playbooks for playbooks and is designed for organizations that follow security standards rigorously and address periodic audits.

♪ What requirements helps to meet

A tool alone does not comply, but provides the process and evidence on which compliance is demonstrated.

– NIS2, Art. 21(2): (b), management and dissemination of vulnerabilities (lettra e), evaluation of the effectiveness of measures (letter f).

– Annex A: 5.7 Threat intelligence, 8.8 Technical vulnerability management, 8.16 Monitoring activity.

– NIST CSF 2.0: ID.RA-01 and ID.RA-02 (vulnerability and threat intelligence), ID.RA-05 and ID.RA-06 (priority and risk response), DEAE-07 (threat intelligence in analysis), RS.MI (immigration of accidents).

## Built on open standards

Where there is a recognized standard, we use it: STIX and MISP for threat intelligence, OVAL and CSAF for the notices of the vendors, Sigma for detection rules, MITRE ATT& CK to map behaviors. It means verifiable, interoperable and unrelated data to a proprietary format.

# Status and next steps

Features are in development for the PRO edition of SentinelSuite, which includes CyberSheppard and IntelliDog. If your organization is subject to NIS2 or ISO/IEC 27001 certified and you want to understand how this approach fits into your processes, contact us.

# From "resolved" to "closed": when threat intelligence changes what a vulnerability means

A vulnerability rated medium can become urgent overnight, and an installed patch does not guarantee that the risk is gone. We are working on two SentinelSuite that capabilities exactly these two points.

> Status: capabilities in development, available only in the PRO edition of SentinelSuite. This article describes the method and the benefits; we are not announcing release dates.

> Why PRO only: both scenarios rely on integration between the tools and require CyberSheppard and IntelliDog, which are not part of the Community edition.

> What integration means: the tools are connected to each other during setup by exchanging keys that let them recognize one another. Once connected, they send each other events ("I detected this"), ask each other for information ("is this IP in your inventory? ") and according react to rules, the playbooks, defined in CyberSheppard and enabled one by one. Without this setup each tool works on its own, and the scenarios described here are not possible.

♪ The problem: risk is not a fixed number

Most vulnerability management processes reassess risk at the peace of their scans. Meanwhile the context changes: a CVE nobody was exploiting yesterday can be at the centre of an active campaign today. And once the patch is installed the ticket gets closed, even though the host may have been compromised before the update.

SentinelSuite is made of tools that each see a different part of the same problem:

– SentinelCore manages vulnerabilities and re-prioritises them by the assets’s real risk, KEV and EPSS;

– FireDog controls network traffic and scores the risk of IP addresses;

– CyberSheppard applicable hardening and correlates host events against MITRE ATT& CKK

– IntelliDog, CyberSheppard’s threat intelligence module, collects indicators of compromise from sources such as MISP, Shodan, AbuseIPDB and AlienVault.

Both capabilities as from making them work together.

## Scenario 1: from indicator of compromise to coordinated remediation

1. Hunting through history. IntelliDog ingests indicators continue. Once a week it hunts through the historical data of all the tools; when a signal strong arrives, such as a CVE added to the KEV catalogue or an active campaign reported in MISP, a targeted hunt on that single vulnerability starts immediately.

2. The risk changes. The Hunt finds a CVE on our servers that the risk engine had rated medium. It is now exploited in an active campaign: SentinelCore raises the risk, remediation becomes a priority, and the responsible teams for the assets receive the request and a remediation plan. The fix is tested first on the test and pre-production clones of the hosts, then rolled out to production.

3. Who has already spoken to the attacker. IntelliDog cross-references the indicators with the traffic observed by FireDog and find hosts that contacted botnet IPs and command-and-control servers tied to the same campaign. Hosts fall into three groups:

– CVE present and contact made: probable incident, to be handled as such;

– contact without the CVE: a different vector or a false positive, to be investigated;

– CVE without contact: priority remediation.

4. Containing the traffic. FireDog blocks the external IPs involved and from then on captures the traffic directed at them. Blocking takes into account the confidence and age of each indicator, because many IPs belong to shared infrastructure such as CDNs and hosting, and blocking them blindly would break legitimate services.

5. Watching the hosts. CyberSheppard checks whether the exposed service has an AppArmor profile and enables audit rules for typical exploitation behaviour, for example starting from public Sigma rules for that CVE, on every host that is vulnerable or contacted the suspicious IPs.

6. One houses. All actions are tied to the same campaign. When the case is closed, temporary rules expire on their own; the honest worth keeping stay.

Automated responses as in two classes. Monitoring responses, which block nothing, can run on their own. Intrusive honest go through AI agents that can only use predefined tools, never free-form commands; they are tested on test clones and, unless the customer chooses otherwise, require a person’s approved.

## Scenario 2: resolved does not mean closed

We distinguish two states:

– Resolved: the fix is installed. We verify it by comparing the packages or updates on the host against the vendors’ official advisories, in OVAL format for Linux distributions and CSAF where available.

– Closed: the vulnerability is resolved and has passed three checks:

– CyberSheppard re-runs the hardening checks on the host;

– FireDog verifies that the service is no longer exposed as before;

– IntelliDog runs a targeted hunting to rule out persistence left by the attacker.

Only when all three come back negative is the case closed, and the outcome of the checks is recorded with date and source as evidence for audits.

♪ How mature this capability is

We see vulnerability management as a ladder:

1. scanning and patching in CVSS order;

2. principles based on real risk: known exploitation (KEV), likelihood of exploitation (EPSS), importance of the asset. This is where SentinelCore already works today;

3. updated by threat intelligence, with coordinated response across network, hosts and vulnerability management;

4. verified closure, with evidenceed.

The two capabilities described here take you to steps 3 and 4. This level requires solid processes: an up-to-date inventory, test environments, teams with clear responsibilities. That is why the capability is optional, playbook enabled by playbook, and designed for organizations that follow security standards rigorously and face regular audits.

# Which requirements it helps

A tool alone does not make you compliant, but it provides the process and the evidence on which compliance is demonstrated.

– NIS2, Article 21(2): incident handling (point b), vulnerability handling and disclosure (point e), assessing the effectiveness of measures (point f).

– Annex A: 5.7 Threat intelligence, 8.8 Management of technical vulnerabilities, 8.16 Monitoring activities.

– NIST CSF 2.0: ID.RA-01 and ID.RA-02 (vulnerabilities and threat intelligence), ID.RA-05 and ID.RA-06 (risk prioritisation and response), DEAE-07 (threat intelligence analysis), RS.MI (incident mitigation).

## Built on open standards

Where a widespread standard exists, we use it: STIX and MISP for threat intelligence, OVAL and CSAF for vender advisories, Sigma for detection rules, MITRE ATT& CK for mapping behaviour. That means date that can be verified, that interoperates, and that is not locked into a proprietary format.

# Status and next steps

These capabilities are in development for the PRO edition of SentinelSuite, which includes CyberSheppard and IntelliDog. If your organization is subject to NIS2 or certified to ISO/IEC 27001 and you want to see how this approach fits your processes, get in touch.