Il Compliance Blade come misura continua della policy

Il Compliance Software Blade non è un report da lanciare a mano una volta l’anno: è un monitoraggio continuo, il Continuous Compliance Monitoring, che confronta l’infrastruttura Check Point — gateway, Software Blade, policy e configurazioni — con una libreria di Security Best Practices e con i requisiti degli standard normativi.

Si abilita da SmartConsole: vista Gateways & Servers, proprietà del Security Management Server, voce Compliance nella sezione Management. Da quel momento la lama esegue una scansione giornaliera, che intercetta le modifiche fatte da CLI o da script, e una scansione innescata dagli eventi, dopo che un amministratore ha pubblicato in SmartConsole. Resta possibile la scansione manuale, con il pulsante Rescan nella sezione Engine Status.

Il punteggio è percentuale e ha cinque gradini: Poor da 0 a 50%, Medium da 50 a 75%, Good da 75 a 99%, Secure al 100%, N/A quando la Software Blade non è installata o la funzione non è supportata. N/A non è una promozione: è assenza di misura.

Best Practices, Regulatory Compliance, Action Items

La vista Security Best Practices espone la libreria di test che Check Point definisce come baseline per una buona configurazione di firewall e policy. Ogni test porta con sé una Description, un Action Item con i passi necessari a diventare conformi e gli scenari alternativi, le Dependencies (altri test che devono essere conformi prima) e, quando ha senso, la sezione Relevant Objects con gli oggetti correlati e il loro stato: è lì che si legge quale gateway o quale cluster fa scendere il punteggio.

La vista Regulatory Compliance non introduce test nuovi: mappa i requisiti degli standard sulle stesse Best Practices e, per ogni requisito, mostra le pratiche applicabili con il loro stato di conformità. Di default tutti gli standard supportati sono attivi; si selezionano dall’icona di configurazione in alto a destra, nella finestra Select Regulations and Standards.

Gli Action Items nascono da soli: quando un test Best Practice rileva una carenza, la lama genera l’elemento con la descrizione della correzione. Ognuno espone data di scadenza (facoltativa), lama correlata, Compliance ID, nome e descrizione del requisito e stato, e si ordina in Upcoming (entro 30 giorni), Future (oltre 30 giorni), Unscheduled (senza data) e Overdue. Si pianificano da Logs & Events, scheda Compliance, Action Items and Messages, Pending Action Items, Unscheduled items, con Schedule Now. Una volta corretta la configurazione, l’Action Item viene eliminato alla scansione successiva: non si chiude a mano.

Eventi su misura: il wizard New Custom Event

Quando nessuna definizione predefinita descrive lo schema di log che interessa, si costruisce un evento definito dall’utente. Il percorso è: vista Logs & Monitor, nuova scheda, SmartEvent Settings & Policy, menu Actions, New Custom Event. Il wizard ha sette passi.

  1. Partire da una definizione esistente oppure da zero.
  2. Nome, descrizione facoltativa e severità.
  3. Tipo di innesco: Single log, quando un solo log descrive già l’evento (il caso classico è il log di un antivirus), oppure Multiple logs, obbligatorio quando l’evento si riconosce solo dalla combinazione di più log, come un tasso di connessioni anomalo.
  4. I prodotti che generano l’evento.
  5. Se modificare tutti i filtri di prodotto o solo quelli appena selezionati.
  6. I filtri sui campi di log: si sceglie il campo, si aggiungono i valori e si decide fra All Conditions e Any Conditions.
  7. La soglia, nella forma «at least X logs occurred over Y seconds», con la scelta se creare Event Candidate distinti in base a certi campi e se contare i valori unici di un campo.

L’evento finisce in Event Policy, User Defined Events. Come per qualsiasi altra modifica alla policy degli eventi: File, Save e poi Actions, Install Event Policy. Solo allora si può collegare una Automatic Reaction e l’alert diventa operativo. Le stesse leve si usano sulle definizioni già esistenti: soglie e criteri si cambiano proprio per ridurre i falsi allarmi.

Trappole tipiche d’esame

  • Regole di evento definite male che seppelliscono di alert. Il vendore lo indica come errore frequente, e la conseguenza è l’assuefazione: quando tutto è critico, niente lo è. Un evento Multiple logs con soglia di due log su sessanta secondi produce rumore; con una soglia realistica e i campi giusti in Event Candidate produce un allarme che qualcuno legge. Le soglie si tarano, non si lasciano al valore predefinito.
  • Ignorare le raccomandazioni del Compliance Blade. Gli Action Items restano lì e l’ambiente resta esposto a errori di configurazione comuni. Le voci in Poor vanno risolte per prime, e le Dependencies vanno rispettate: un test può risultare non conforme solo perché un altro test, da cui dipende, non lo è ancora.
  • Leggere N/A come «tutto a posto». N/A significa che la Software Blade non è installata o la funzione non è supportata: quel controllo non è stato eseguito.
  • Credere che il Compliance Blade veda solo SmartConsole. La scansione dopo il publish copre le modifiche fatte in console; quelle fatte da CLI o da script le intercetta la scansione giornaliera.
  • Dare per scontato che i log arrivino a SmartEvent. Un evento personalizzato perfetto non scatta mai se la Correlation Unit non ha in elenco i Log Server giusti: prima si verifica la catena dei log, poi si accusa la regola.