# Da «risolto» a «chiuso»: quando la threat intelligence cambia il peso di una vulnerabilità

Una vulnerabilità classificata come media può diventare urgente da un giorno all’altro, e una patch installata non garantisce che il rischio sia sparito. Stiamo lavorando a due funzionalità di SentinelSuite che affrontano proprio questi due punti.

> Stato: funzionalità in sviluppo, disponibili solo nell’edizione PRO di SentinelSuite. In questo articolo raccontiamo il metodo e i benefici; non annunciamo date di rilascio.

> Perché solo PRO: entrambi gli scenari nascono dall’integrazione tra i tool e richiedono CyberSheppard e IntelliDog, che non fanno parte dell’edizione Community.

> Cosa significa integrazione: i tool vengono collegati tra loro in fase di configurazione, scambiandosi chiavi con cui si riconoscono a vicenda. Una volta collegati si inviano eventi («ho rilevato questo»), si chiedono informazioni («questo IP è nel tuo inventario?») e reagiscono secondo regole, i playbook, definite in CyberSheppard e abilitate una per una. Senza questa configurazione ogni tool lavora da solo, e gli scenari descritti non sono possibili. Inoltre sono indipendenti dagli agenti llm e dall’mcp, è possibile usarli assieme ma di fatto non sono troppo legati tra di loro, sono i tool che dialogano tra di loro per sfruttare tutte le loro potenzialità al meglio.

## Il problema: il rischio non è un numero fisso

La maggior parte dei processi di vulnerability management rivaluta il rischio al ritmo delle scansioni. Nel frattempo il contesto cambia: una CVE che ieri nessuno sfruttava oggi può essere al centro di una campagna attiva. E quando la patch viene installata il ticket si chiude, anche se l’host potrebbe essere stato compromesso prima dell’aggiornamento.

SentinelSuite è composta da strumenti che vedono parti diverse dello stesso problema:

– SentinelCore gestisce le vulnerabilità e le riprioritizza in base al rischio reale dell’asset, a KEV ed EPSS;

– FireDog controlla il traffico di rete e assegna un punteggio di rischio agli IP;

– CyberSheppard applica l’hardening e correla gli eventi degli host sulla matrice MITRE ATT\&CK;

– IntelliDog, il modulo di threat intelligence di CyberSheppard, raccoglie indicatori di compromissione da fonti come MISP, Shodan, AbuseIPDB e AlienVault.

Le due funzionalità nascono dal farli lavorare insieme.

## Scenario 1: dall’indicatore di compromissione alla remediation coordinata

1. La caccia sullo storico. IntelliDog acquisisce indicatori di continuo. Una volta alla settimana esegue una ricerca sullo storico dei dati di tutti i tool; quando arriva un segnale forte, come una CVE aggiunta al catalogo KEV o una campagna attiva segnalata in MISP, parte subito una ricerca mirata su quella sola vulnerabilità.

2. Il rischio cambia. La ricerca trova sui nostri server una CVE che il motore di rischio aveva classificato come media. Ora è sfruttata in una campagna attiva: SentinelCore alza il rischio, la remediation diventa prioritaria, i team responsabili degli asset ricevono la richiesta e un piano di remediation. La correzione viene provata prima sui cloni di test e preproduzione degli host, poi portata in produzione.

3. Chi ha già parlato con l’attaccante. IntelliDog incrocia gli indicatori con il traffico osservato da FireDog e trova host che hanno contattato IP di botnet e server di comando e controllo legati alla stessa campagna. Gli host si dividono in tre gruppi:

– CVE presente e contatto avvenuto: probabile incidente, da gestire come tale;

– contatto senza CVE: vettore diverso o falso positivo, da investigare;

– CVE senza contatto: remediation prioritaria.

4. Contenere il traffico. FireDog blocca gli IP esterni coinvolti e da quel momento salva il traffico diretto verso di essi. Il blocco tiene conto dell’affidabilità e dell’età di ogni indicatore, perché molti IP appartengono a infrastrutture condivise come CDN e hosting, e bloccarli alla cieca interromperebbe servizi legittimi.

5. Sorvegliare gli host. CyberSheppard verifica se il servizio esposto ha un profilo AppArmor e attiva regole di audit sui comportamenti tipici dello sfruttamento, per esempio partendo dalle regole Sigma pubbliche per quella CVE, su tutti gli host vulnerabili o che hanno contattato gli IP sospetti.

6. Un unico caso. Tutte le azioni sono legate alla stessa campagna. Quando il caso si chiude, le regole temporanee scadono da sole; quelle che vale la pena tenere restano.

Le risposte automatiche sono divise in due classi. Quelle di monitoraggio, che non bloccano nulla, possono partire da sole. Quelle intrusive passano da agenti AI che usano solo strumenti predefiniti, mai comandi liberi, vengono provate sui cloni di test e, salvo diversa scelta del cliente, richiedono l’approvazione di una persona.

## Scenario 2: risolto non vuol dire chiuso

Distinguiamo due stati:

– Risolto: la correzione è installata. Lo verifichiamo confrontando i pacchetti o gli aggiornamenti presenti sull’host con gli avvisi ufficiali dei vendor, in formato OVAL per le distribuzioni Linux e CSAF dove disponibile.

– Chiuso: la vulnerabilità è risolta e ha superato tre controlli:

– CyberSheppard ripassa i controlli di hardening sull’host;

– FireDog verifica che il servizio non sia più esposto come prima;

– IntelliDog esegue una ricerca mirata per escludere che l’attaccante abbia lasciato una persistenza.

Solo quando tutti e tre sono negativi il caso si chiude, e l’esito dei controlli resta registrato con data e fonte come evidenza per gli audit.

## Quanto è matura questa funzionalità

Pensiamo al vulnerability management come a una scala:

1. scansione e patch in ordine di punteggio CVSS;

2. priorità basate sul rischio reale: sfruttamento noto (KEV), probabilità di sfruttamento (EPSS), importanza dell’asset. È il punto in cui SentinelCore lavora già oggi;

3. priorità aggiornate dalla threat intelligence e risposta coordinata tra rete, host e gestione delle vulnerabilità;

4. chiusura verificata, con evidenze conservate.

Le due funzionalità descritte portano ai gradini 3 e 4. È un livello che richiede processi già solidi: un inventario aggiornato, ambienti di test, team con responsabilità chiare. Per questo la funzionalità è opzionale, si attiva playbook per playbook ed è pensata per le organizzazioni che seguono gli standard di sicurezza in modo rigoroso e affrontano audit periodici.

## Quali requisiti aiuta a soddisfare

Uno strumento da solo non rende conformi, ma fornisce il processo e le evidenze su cui la conformità si dimostra.

– NIS2, art. 21(2): gestione degli incidenti (lettera b), gestione e divulgazione delle vulnerabilità (lettera e), valutazione dell’efficacia delle misure (lettera f).

– ISO/IEC 27001:2022, Annex A: 5.7 Threat intelligence, 8.8 Gestione delle vulnerabilità tecniche, 8.16 Attività di monitoraggio.

– NIST CSF 2.0: ID.RA-01 e ID.RA-02 (vulnerabilità e threat intelligence), ID.RA-05 e ID.RA-06 (priorità e risposta al rischio), DE.AE-07 (threat intelligence nell’analisi), RS.MI (mitigazione degli incidenti).

## Costruito su standard aperti

Dove esiste uno standard riconosciuto, lo usiamo: STIX e MISP per la threat intelligence, OVAL e CSAF per gli avvisi dei vendor, Sigma per le regole di rilevamento, MITRE ATT&CK per mappare i comportamenti. Significa dati verificabili, interoperabili e non legati a un formato proprietario.

## Stato e prossimi passi

Le funzionalità sono in sviluppo per l’edizione PRO di SentinelSuite, che comprende CyberSheppard e IntelliDog. Se la vostra organizzazione è soggetta a NIS2 o certificata ISO/IEC 27001 e volete capire come questo approccio si inserisce nei vostri processi, contattateci.

# 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 capabilities that tackle 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 recognise one another. Once connected, they send each other events (“I detected this”), ask each other 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 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 pace 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 asset’s real risk, KEV and EPSS;

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

– CyberSheppard applies hardening and correlates host events against MITRE ATT\&CK;

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

Both capabilities come from making them work together.

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

1. Hunting through history. IntelliDog ingests indicators continuously. Once a week it hunts through the historical data of all the tools; when a strong signal 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 teams responsible 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 talked to the attacker. IntelliDog cross-references the indicators with the traffic observed by FireDog and finds 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 case. All actions are tied to the same campaign. When the case is closed, temporary rules expire on their own; the ones worth keeping stay.

Automated responses come in two classes. Monitoring responses, which block nothing, can run on their own. Intrusive ones 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 approval.

## 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 hunt 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. priorities based on real risk: known exploitation (KEV), likelihood of exploitation (EPSS), importance of the asset. This is where SentinelCore already works today;

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

4. verified closure, with evidence retained.

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, enabled playbook by playbook, and designed for organisations that follow security standards rigorously and face regular audits.

## Which requirements it helps meet

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).

– ISO/IEC 27001:2022, 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), DE.AE-07 (threat intelligence in analysis), RS.MI (incident mitigation).

## Built on open standards

Where a recognised standard exists, we use it: STIX and MISP for threat intelligence, OVAL and CSAF for vendor advisories, Sigma for detection rules, MITRE ATT&CK for mapping behaviour. That means data 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 organisation is subject to NIS2 or certified to ISO/IEC 27001 and you want to see how this approach fits your processes, get in touch.