Threat Prevention è il secondo livello di ispezione di un gateway Check Point: non decide se una connessione può passare, ma che cosa sta viaggiando dentro una connessione già consentita. Tenere ferma questa distinzione è il modo più rapido per rispondere alle domande di questo dominio.

Perché l’Access Control da solo non basta

Una regola della Access Control Policy valuta sorgente, destinazione, servizio, applicazione e identità: è un giudizio sul canale. Se consenti la navigazione web all’azienda, hai autorizzato anche il documento infetto scaricato da un sito legittimo compromesso e la mail con l’allegato armato. Il contenuto resta fuori dal perimetro di quella decisione.

Threat Prevention si occupa esattamente di quel contenuto. Ispeziona file, payload e pattern di comunicazione dentro il traffico che l’Access Control ha già ammesso, con un insieme di Software Blade dedicate governate da una policy propria. Sono due Rule Base distinte, con Layer distinti, che convivono nello stesso Policy Package.

Una difesa a più livelli, prima e dopo l’infezione

La documentazione R82 descrive Threat Prevention come una difesa multi-livello, pre e post infezione. Le due metà contano entrambe.

La metà pre-infezione cerca di impedire l’ingresso: firme in tempo reale sui file in transito, protezioni contro exploit e abusi di protocollo, analisi comportamentale dei file mai visti prima. La metà post-infezione parte dal presupposto opposto, cioè che qualcosa sia già entrato — via chiavetta USB, via portatile personale, via una falla che nessuno aveva ancora chiuso — e si concentra sul riconoscere l’host compromesso e sul tagliargli la comunicazione verso il Command and Control.

Il punto d’esame è che nessun singolo motore copre entrambe le metà. Una firma ferma il malware conosciuto ma non lo zero-day; una sandbox riconosce il comportamento malevolo di un file sconosciuto ma non vede il PC già infetto che chiama casa; l’intercettazione del traffico C&C individua quel PC ma non ha impedito l’infezione. Il valore della soluzione sta nella somma, non in un singolo componente.

ThreatCloud: una difesa che vale finché è viva

ThreatCloud è il servizio di intelligence condivisa che alimenta le blade: viene aggiornato di continuo con i dati raccolti dai prodotti Check Point installati nel mondo e ridistribuisce a tutti le firme e gli indicatori appena identificati da uno.

È la ragione per cui Threat Prevention va pensato come un servizio in esercizio, non come una configurazione fatta una volta. Una policy scritta bene un anno fa e mai aggiornata protegge dalle minacce di un anno fa. Ed è anche la ragione per cui la connettività del gateway verso il cloud Check Point è un tema ricorrente nelle domande: senza quel canale la policy è perfetta sulla carta e cieca sul campo.

Che cosa deve accadere perché il traffico venga davvero ispezionato

Tre condizioni, tutte necessarie e spesso confuse fra loro:

  1. La Software Blade è abilitata sull’oggetto Security Gateway in SmartConsole. Una blade non attivata non ispeziona nulla, qualunque cosa dica la Rule Base.
  2. Una regola di Threat Prevention include quel traffico nella colonna Protected Scope. Attenzione: non è la coppia sorgente-destinazione. Copre il traffico da e verso gli oggetti indicati, anche quando non è stato l’oggetto indicato ad aprire la connessione.
  3. La policy è installata sul gateway. La colonna Install On stabilisce su quali gateway la regola vale, e il default è All.

Resta la colonna Track, che decide che cosa sopravvive dell’evento: da None fino ad Alert, Packet Capture e Forensics. È la colonna che trasforma un blocco in una prova utilizzabile durante un’analisi.

Trappole tipiche d’esame

  • Falso positivo: la risposta non è spegnere la blade. Se uno scenario descrive un’applicazione interna legittima bloccata, la soluzione attesa è un’exception rule mirata — un’eccezione sotto la regola, numerata come E-1.1, che per quello specifico Protected Scope o per quella protezione porta l’azione a Detect — oppure una voce in Global Exceptions se deve valere su tutta la Rule Base. Disabilitare la blade o cambiare il profilo dell’intera regola sono i distrattori.
  • Più aggressivo non significa più corretto. Quando la domanda descrive un gateway già al limite delle prestazioni, la scelta giusta non è l’impostazione più severa: le protezioni hanno un performance impact dichiarato, e il profilo è proprio la leva che permette di escludere quelle ad alto impatto invece di rinunciare all’ispezione.
  • Detect registra, non blocca. In Detect il traffico identificato passa e viene loggato. Chi legge in fretta lo scambia per un blocco silenzioso: è l’errore che fa sbagliare la domanda pur conoscendo la materia.
  • Scaricare un aggiornamento non è applicarlo. Anti-Virus, Anti-Bot e Threat Emulation si aggiornano scaricando direttamente dal cloud Check Point. Per IPS, su gateway R80.20 e superiori privi di connettività Internet, gli aggiornamenti vanno comunque resi effettivi con un’installazione della policy: senza quel passo il gateway continua a far valere protezioni vecchie.
  • Threat Prevention non sostituisce l’Access Control. Se una regola di Access Control scarta la connessione non c’è alcun contenuto da ispezionare; se la ammette, è Threat Prevention a guardarci dentro. Le domande che mescolano le due Rule Base contano sul fatto che tu le tratti come una sola.