Sono le due di notte. SentinelCore scopre una vulnerabilità attivamente sfruttata (catalogo CISA KEV) su un server esposto in DMZ. Nessun analista è sveglio per leggerlo. Nel modello che conosciamo oggi, quella vulnerabilità aspetta l’inizio del turno del mattino — e nel frattempo resta lì, sfruttabile. È esattamente lo scenario che l’architettura introdotta con SentinelCore v1.2.0 comincia a rendere superabile, e vale la pena capire perché.

Un solo linguaggio per parlare a tutta la suite

Con questa versione, il server MCP (Model Context Protocol) di SentinelCore passa dalla sola lettura alla fase 2: un agente AI autorizzato non può più solo consultare vulnerabilità e rischio, può agire — cambiare lo stato di una vulnerabilità, assegnarla a un team, avviare una scansione — con la stessa identica autorizzazione (RBAC, scope, audit) che avrebbe un utente umano loggato in console. Niente scorciatoie: ogni chiamata di un agente passa dagli stessi controlli di un click su un pulsante.

La parte più interessante, però, non è il singolo tool. È che questa fase 2 è costruita sopra un contratto MCP condiviso a livello di suite — stesso protocollo, stessa forma di autenticazione, stessa struttura delle risposte — pensato fin dal primo giorno per SentinelCore, FireDog e CyberSheppard insieme, non per un prodotto isolato.

Uno scenario: quando il rischio si traduce in un’azione, non in un ticket

Proviamo a immaginare dove porta questa direzione. SentinelCore rileva la vulnerabilità KEV di cui parlavamo, calcola un risk score fuori scala (severità reale, non CVSS “di targa”) e lo segnala. Un agente orchestratore, parlando lo stesso linguaggio MCP, potrebbe:

• Oggi, già possibile: interrogare SentinelCore sul dettaglio della vulnerabilità, verificare l’asset e l’esposizione, assegnare automaticamente il caso al team competente in base alle skill dichiarate — e, dall’altra parte, interrogare il server MCP di FireDog (già attivo, stesso contratto condiviso) per sapere se quell’host è già coperto da una regola, se risulta tra gli IP bloccati, o qual è lo stato della policy sul target — tutto senza aprire due console diverse. Il server MCP di FireDog oggi è già fase 2, lettura e scrittura — legge regole, minacce e IP bloccati, e può crearne di nuove o modificarle, lo stesso agente orchestratore può chiudere il cerchio: chiedere a FireDog di applicare una micro-regola di contenimento sull’host esposto — non una patch, ma un guadagno di tempo mentre il team umano interviene — senza che nessuno debba copiare un IP da uno strumento all’altro.

Non è fantascienza, e la parte di lettura incrociata tra i due prodotti è già una realtà concreta oggi, non solo un’intenzione. Il pezzo che manca — la scrittura lato FireDog — è l’obiettivo esplicito della stessa architettura, e SentinelCore v1.2.0 è il primo prodotto della suite ad arrivarci per intero.

NIS2 e ISO 27001 non sono solo un modulo da spuntare

Chi deve rendicontare la conformità NIS2 (art. 21, gestione del rischio e gestione degli incidenti) o un SGSI ISO/IEC 27001 (in particolare il controllo A.8.8 sulla gestione delle vulnerabilità tecniche) conosce bene il problema: non basta avere uno strumento di vulnerability management, serve poter dimostrare che il rischio è tracciato, prioritizzato con un criterio coerente e gestito entro tempi definiti.

Qui il risk score/tier reale di SentinelCore (non il CVSS grezzo, sostituito ovunque con questa versione) smette di essere un dettaglio estetico dei report: è l’evidenza stessa che il criterio di prioritizzazione richiesto da NIS2 e ISO 27001 esiste, è applicato in modo uniforme, ed è tracciabile — SLA per severità, audit log completo, report eseguibili in un click per l’auditor o per il CISO che deve rispondere al board.

Cosa serve perché tutto questo non resti teoria

Un’istanza che gira in HTTP in chiaro, senza un modo sicuro per essere aggiornata, non è la base su cui costruire automazione critica. Per questo v1.2.0 porta anche le fondamenta: HTTPS abilitato di default su ogni nuova installazione, e un vero meccanismo di aggiornamento in-place (upgrade.sh) con backup automatico e rollback se qualcosa va storto — requisito minimo, non un optional, se l’obiettivo è che SentinelCore diventi il punto centrale da cui orchestrare azioni, non solo un cruscotto da consultare.

A completare il quadro: notifiche granulari per evento (email, Slack, Telegram) invece del “tutto o niente” di prima, scoperta di rete più affidabile grazie a mDNS e NetBIOS, e un manuale utente completo in italiano — consultabile online o scaricabile in PDF. Il changelog tecnico completo, con tutti i dettagli e i bug corretti lungo il percorso dalla beta a questa release, è su GitHub.

Per scaricare SentinelCore v1.2.0 (pacchetto binario, appliance OVA o qcow2), la pagina di riferimento è sentinelsuite.dognet-technologies.online.

---

Potrebbe interessarti anche

• Autonomous Response: come MCP e AI Agent stanno rivoluzionando la Cybersecurity con SentinelSuite
• Continuous Monitoring: perché fare Vulnerability Management non significa solo eseguire scansioni. Come usare Openvas + SentineCore per il tuo CM
• CVSS ed EPSS: Gli Standard Chiave per Prioritizzare le Vulnerabilità di Sicurezza