Garanzia di rilascio indipendente per gli aggiornamenti degli endpoint
Kestrel è un piano di controllo indipendente posizionato tra i tuoi fornitori di software e il tuo parco endpoint di produzione. Intercetta un aggiornamento del fornitore prima che raggiunga qualsiasi endpoint, dimostra deterministicamente la firma di errore di classe CrowdStrike, vincola il rollout con policy che un modello consultivo non può scavalcare ed esporta un registro di prove firmato che un consiglio di amministrazione e un'autorità di regolamentazione possono rieseguire. Ciò che puoi osservare qui è una demo su un parco sintetico di 8.500 endpoint, non una pipeline distribuita.
20 → 21
La discrepanza nel conteggio dei campi che ha mandato in crash il parco macchine
Causa principale CrowdStrike, RCA agosto 2024
12/12
Decisioni di rilascio corrette
Su un set di 12 fixture etichettate, deterministico
0/6
Falsi blocchi sugli aggiornamenti benigni
6 fixture benigne nello stesso set
Il parco endpoint, il fornitore SentinelEdge e il suo agente di classe Falcon sono sintetici. Lo scenario C-00000291 riproduce la firma di errore documentata di CrowdStrike del 19 luglio, non i sistemi di alcun cliente reale.
Il 19 luglio 2024, un singolo channel file di Rapid Response Content di CrowdStrike ha mandato in crash milioni di macchine Windows in meno di 90 minuti. La causa principale pubblicata non era un attacco informatico né un modello difettoso. Era una discrepanza di schema: il validatore cloud ha approvato un aggiornamento a 21 campi mentre l'interprete del kernel ne attendeva ancora 20, generando una lettura fuori limite e un BSOD istantaneo. Poiché il crash si è verificato così precocemente all'avvio, l'agente in crash non ha mai potuto reinizializzarsi per ricevere un comando di rollback, rendendo necessario il ripristino manuale delle macchine una alla volta in Safe Mode. (CrowdStrike Root Cause Analysis, agosto 2024.)
Il validatore che ha approvato l'aggiornamento apparteneva allo stesso fornitore che lo ha distribuito. Una pipeline che si autocontrolla non prevede alcuna parte indipendente che legga il payload durante il suo transito verso il tuo parco di produzione.
Gli strumenti SBOM e SCA coprono le dipendenze open source, non i channel file proprietari di un fornitore. La sicurezza dei contenuti monitora i prompt e l'identità controlla gli accessi. Nessuno legge l'aggiornamento proprietario del fornitore in entrata.
Un'azienda con 5.000 endpoint esegue da 8 a 12 agenti con privilegi a livello di kernel di fornitori che non controlla, ciascuno in grado di inviare un channel file direttamente in ring 0. I comitati di approvazione delle modifiche approvano gli aggiornamenti dei fornitori sulla fiducia, perché non c'è nulla tra quella pipeline e la produzione.
Un gruppo consultivo ragiona su ciascun aggiornamento, ma non può decidere. Kestrel instrada ogni pacchetto attraverso una pipeline che lo normalizza, lo ancora ai dati del parco endpoint, lascia che il gruppo si confronti e poi affida la decisione a un verificatore deterministico e gate di policy scritto in puro Python. Un agente consultivo favorevole al rilascio non può mai annullare un rilievo deterministico critico, perché la fiducia in un prodotto di governance non deve dipendere dal fatto che l'entità governata garantisca per se stessa.
01 / SCHEMA-COMPATIBILITY DIFF
Il controllo confronta il conteggio dei campi dichiarato di un aggiornamento con quanto atteso dall'interprete del kernel distribuito. Un aggiornamento a 21 campi che raggiunge un interprete a 20 campi rappresenta la causa principale letterale del 19 luglio, intercettata tramite aritmetica prima che qualsiasi endpoint si riavvii.
02 / SANDBOX REBOOT-CYCLE MODEL
Una sandbox simulata modella il comportamento di BSOD e cicli di avvio per ciascun profilo del sistema operativo attraverso i cicli di riavvio, a partire da un segnale di compatibilità dei driver indipendente dal controllo dello schema. Quando segnala il fallimento di 5 profili su 6, ciò corrobora il rilievo sullo schema anziché limitarsi a ripeterlo.
03 / BLAST-RADIUS AND CANARY MATH
Il controllo calcola la prima ondata rispetto alla tua policy di canary massimo. Un rollout al 100% del parco in una sola volta, o privo di un piano canary dichiarato, viola la policy e viene respinto, mentre una prima ondata scaglionata dell'1,2% rientra nei limiti previsti.
04 / DEAD-AGENT AND CONFLICT DETECTOR
Il controllo contrassegna un agente pre-boot che è esso stesso il destinatario del rollback, tale per cui un crash renderebbe orfano l'endpoint costringendo al ripristino in Safe Mode macchina per macchina, e segnala due fornitori che modificano lo stesso callback del kernel nella medesima finestra temporale. Questo è l'errore che ha trasformato il 19 luglio in un ripristino manuale.
Il gruppo consultivo è sviluppato su Pydantic AI: un normalizzatore, un interprete di sandbox e due revisori contrapposti, uno che sostiene che l'aggiornamento sia sicuro da distribuire e uno che sostiene che causerà un arresto anomalo. Questa coppia oppositiva sottopone a red-team il verdetto da entrambe le direzioni prima che il codice decida. Il verdetto stesso è una di quattro disposizioni: ALLOW per rilasciare al canary, HOLD per inoltrare a revisione, BLOCK per rifiutare il rollout e ABSTAIN per indirizzare un payload non analizzabile a un operatore umano, poiché il gate non dà mai il via libera a ciò che non può dimostrare.
Il gruppo è indipendente dal provider, con Anthropic, OpenAI o Gemini selezionabili tramite una variabile di ambiente e un modello predefinito claude-opus-4-8, ed è in grado di funzionare completamente offline senza alcuna chiave API grazie a un fallback consultivo deterministico. In ogni modalità, il verificatore e il gate rimangono invariati e producono comunque il verdetto completo e il registro di prove. Il verificatore e il gate risiedono deliberatamente al di fuori del framework degli agenti.
La demo governa un parco sintetico, Acme Financial: Global Endpoint Fleet, composto da 8.500 endpoint distribuiti su 6 profili OS e 8 agenti con privilegi, 5 dei quali a livello ring-0. Il fornitore SentinelEdge invia due aggiornamenti Rapid Response Content. Guarda cosa fa Kestrel con ciascuno di essi.
La scheda View Benchmark esegue l'intero set di fixture etichettate e calcola un tabellone di punteggio. Leggi ogni numero considerando l'ambito che la demo vi associa. Si tratta di risultati di copertura della governance su un set fisso, non di una garanzia a mondo aperto, e sono deterministici, pertanto gli stessi input producono le medesime decisioni a ogni esecuzione.
| Domanda | Cosa fa Kestrel in questa demo | Cosa rimane al di fuori della demo |
|---|---|---|
| Accuratezza del gate | 12 decisioni corrette su 12 su un set di 12 fixture etichettate, comprese 6 benigne, diversi blocchi e sospensioni, e 1 onesta astensione. | Una garanzia universale che ogni aggiornamento dannoso venga intercettato. Il risultato riguarda un set fisso, non uno scenario a mondo aperto. |
| Tempo di inattività prevenuto | Un valore stimato di $13.3M sull'intero set, di cui $5M sull'aggiornamento bloccato di classe CrowdStrike, derivante da un modello visualizzato a schermo: quota interessata moltiplicata per una tariffa oraria moltiplicata per una soglia minima di un'ora. | Denaro risparmiato da un cliente reale o un rendimento garantito. Si tratta di una stima sintetica su fixture sintetiche. |
| Copertura della sandbox | Un modello di esito deterministico per singolo profilo su 5 profili del parco macchine su 6, con gli host legacy Server 2012 contrassegnati ed esclusi anziché presunti sicuri. | Una vera farm sandbox di macchine virtuali Windows. La matrice mostrata qui è un modello simulato, non VM reali in esecuzione, e la farm è prevista nella roadmap. |
| Integrazioni | Legge un feed del canale di aggiornamento del fornitore e lo instrada a una coda ITSM sotto forma di stub di fixture, firmando il registro con uno SHA-256 locale. | ITSM bidirezionale in tempo reale, un feed reale del fornitore e la firma con PKI aziendale. Nella demo si tratta di integrazioni simulate. |
Kestrel non è un EDR e non compete con Falcon, Defender o Cortex XDR. Non scansiona gli endpoint, non applica patch né rimuove malware, e non richiede mai l'accesso al kernel. La matrice di sandbox è un modello deterministico di esito per profilo, non vere macchine virtuali Windows; la firma delle prove è uno SHA-256 locale, non una PKI aziendale; e il feed del canale di aggiornamento del fornitore e la coda ITSM sono stub di fixture, non connettori attivi. Acme Financial, SentinelEdge e l'agente di classe Falcon sono fittizi, e nessun fornitore reale è cliente, partner o sostenitore di Veriprajna. I risultati 12 su 12 e 0 su 6 sono ottenuti su un set fisso di 12 fixture etichettate, e gli importi in dollari rappresentano il modello di stima dei tempi di inattività prevenuti proprio della demo, non una certificazione, una consulenza legale o un ritorno economico garantito. Una reale farm sandbox di VM, un ITSM bidirezionale live, un audit di responsabilità contrattuale dei fornitori, la verifica formale del kernel e l'hardening per l'integrazione nel sito sono in roadmap e non ancora realizzati. Questa pagina è una guida esplicativa con un video, screenshot, analisi dei meccanismi e risposte, non un'applicazione utilizzabile da qui.
No. Kestrel non è un EDR e non necessita mai di accesso al kernel. Si colloca un livello al di sopra dei tuoi agenti di EDR, DLP, crittografia e applicazione delle patch, e governa ciò che tali fornitori sono autorizzati a distribuire nel tuo parco di produzione. Non esegue scansioni degli endpoint, non installa patch né rimuove malware. Legge l'aggiornamento proposto da un fornitore, dimostra se sia sicuro da rilasciare e ne vincola il rollout tramite policy: un compito che nessuno dei tuoi agenti a livello di kernel svolge per il fornitore a monte.
Le aziende che si sono ritrovate bloccate il 19 luglio 2024 non gestivano la pipeline del fornitore, ma ne hanno subito le conseguenze. Il vuoto strutturale risiede nell'assenza di un livello indipendente tra la pipeline di aggiornamento del fornitore e gli endpoint di produzione: il validatore del fornitore si autocontrolla, gli strumenti SBOM e SCA coprono le dipendenze open source anziché i channel file proprietari, e i comitati di gestione dei cambiamenti tendono ad approvare gli aggiornamenti dei fornitori sulla fiducia. Kestrel costituisce quel livello mancante. Legge il payload effettivo che il fornitore sta per distribuire e stabilisce, tramite codice sotto il tuo controllo, se debba raggiungere o meno la produzione.
Il gruppo consultivo si limita a ragionare sull'aggiornamento. Il verdetto viene stabilito da un verificatore deterministico e da un gate di policy scritto in puro Python: un'aritmetica ricalcolabile che un'autorità di regolamentazione può rieseguire, in modo che un agente consultivo incline al rilascio non possa mai scavalcare un riscontro deterministico critico. Poiché la decisione è affidata al codice e non a un'autovalutazione del modello, il medesimo input produce la stessa decisione a ogni esecuzione senza alcuna varianza legata al modello. La demo funziona inoltre completamente offline senza alcuna chiave API grazie a un fallback consultivo deterministico, e in tale modalità il gate e il suo verdetto rimangono invariati.
È un gate, non un controllore inflessibile che blocca qualsiasi cosa. Nella demo, un aggiornamento Rapid Response Content benigno dello stesso fornitore supera i controlli e viene rilasciato in pochi secondi a un anello canary dell'1,2%, mentre quello pericoloso viene bloccato. Sulle 6 fixture benigne nel set etichettato non si è verificato alcun falso blocco (0 falsi blocchi). Kestrel interviene in modo restrittivo solo di fronte a un pericolo reale, e gli host legacy che non è in grado di modellare vengono segnalati ed esclusi anziché presunti sicuri.
Un singolo clic esporta un registro di prove firmato sotto forma di visualizzazione HTML unita a un file JSON contenente un hash del contenuto SHA-256, il verdetto, le prove deterministiche, i risultati della sandbox per ciascun profilo, i verdetti degli agenti consultivi con il relativo ID del modello, le regole di policy attivate e una traccia di valutazione dettagliata con la latenza di ciascun passaggio. Il registro include inoltre la contestualizzazione rispetto all'EU Cyber Resilience Act, agli obblighi di informativa SEC e al precedente Delta, risultando così adatto a una documentazione di conformità. La firma è uno SHA-256 locale per garantire l'integrità, non una PKI aziendale, e il registro è strutturato per allinearsi a tali esigenze di rendicontazione anziché costituire una certificazione formale.
No. Il gruppo consultivo è basato su Pydantic AI ed è neutrale rispetto ai provider: Anthropic, OpenAI o Gemini sono selezionabili tramite una variabile di ambiente, con un modello predefinito claude-opus-4-8 accessibile tramite un bridge locale o l'API di Anthropic. Funziona inoltre completamente offline senza alcuna chiave API grazie a un fallback consultivo deterministico. In ogni modalità, il verificatore deterministico e il gate di policy rimangono invariati e continuano a produrre l'intero verdetto e il registro di prove, poiché la garanzia non è mai stata una proprietà del modello.
La ricerca alla base di questa demo: l'architettura, la progettazione della verifica e il modello aziendale di riferimento.
Soluzione completa
Esplora la soluzione Software Update Deployment Integrity →Siamo un team di ingegneria dell'AI, non un fornitore di middleware. Costruiamo il livello indipendente che decide tramite codice ciò che un fornitore è autorizzato a inviare al tuo parco di produzione, e ti consegna la ricevuta.
Un primo confronto utile è concreto: gli agenti con privilegi kernel eseguiti dal tuo parco macchine, i percorsi di aggiornamento dei fornitori che arrivano in produzione senza alcuna verifica indipendente e la policy di rollout e canary che desideri applicare. Possiamo analizzare i controlli deterministici, il gate di policy e il formato del registro delle prove insieme ai tuoi team dedicati agli endpoint e alla conformità.
