Cosa smette di farsi a mano quando il programma di Cybersecurity awareness ha un’API

Il primo giorno lavorativo di ogni mese qualcuno del tuo team entra nella piattaforma di Cybersecurity awareness, scarica un file, lo incolla in un foglio di calcolo e prepara la slide che vedrà il comitato di direzione. Poi ripete l’operazione con gli altri strumenti dello stack. Il lavoro viene fatto bene e il numero che arriva in alto è corretto. Si fa una volta al mese perché farlo costa un’intera mattinata.

Quello sforzo non si spiega con la mancanza di dati. I dati ci sono, ogni piattaforma li possiede e li mostra nella propria dashboard. Manca la porta da cui escono senza che nessuno li ricopi a mano.

Guido il team di ingegneria di SMARTFENSE e nelle conversazioni tecniche con i clienti quella porta quasi mai si presenta come una richiesta di API. Si presenta come il report mensile senza la mattinata di lavoro, l’attivazione che scatta da sola quando entra una persona nuova, l’evidenza pronta il giorno in cui chiama l’auditor. L’API della piattaforma è ciò che sta sotto a tutte e tre le richieste.

Cosa significa che un programma di Cybersecurity awareness ha un’API?

L’API di una piattaforma di Cybersecurity awareness è l’interfaccia che permette a un altro sistema di consultare e modificare i dati del programma senza passare dallo schermo. Dove una persona entra e clicca, un programma effettua una chiamata e riceve lo stesso dato in formato JSON.

Detta così sembra un dettaglio implementativo, ma ci sono quattro scelte di progettazione che cambiano parecchio il lavoro di chi dovrà consumarla.

È REST su HTTPS obbligatorio, il disegno che qualsiasi team IT sa già consumare senza formazione preliminare. Restituisce JSON, quindi il risultato entra direttamente in uno strumento di BI (Business Intelligence) senza uno strato di trasformazione intermedio. Le risposte sono paginate, dettaglio che conta quando l’anagrafica ha ventimila persone e la query non può portarle tutte insieme. E le date viaggiano in UTC con formato ISO 8601, che è ciò che permette di confrontare il risultato di una campagna in Messico con una in Spagna senza discutere su che ora sia iniziata ciascuna.

Nessuna delle quattro è esotica. Sono quelle che fanno sì che l’integrazione la chiuda il team IT del cliente, invece di trasformarsi in un progetto con il nostro team dall’altra parte.

Quali dati escono dal programma e verso dove?

Ci sono cinque aree di dati disponibili e conviene guardarle per ciò che risolvono, non per il loro nome.

I risultati di campagne e attività di awareness sono la materia prima del report, ciò che oggi esce come file scaricato. Lo scoring di rischio è il punteggio per persona, gruppo e organizzazione che la piattaforma già calcola e mostra come mappa di calore nei suoi report. La gestione di utenti e organizzazione è l’anagrafica, con le attivazioni, le disattivazioni e la struttura delle aree. L’audit e la tracciabilità sono il registro delle azioni, quello che chiede l’auditor. E i contenuti sono l’inventario di ciò che è pubblicato e assegnato.

La destinazione abituale di queste cinque aree sono tre sistemi che l’organizzazione ha già. Lo strumento di BI, dove il dato del programma si affianca al resto degli indicatori invece di vivere in una dashboard a parte. Il SIEM o il GRC (Governance, Risk and Compliance), che sommano il rischio per persona alla telemetria che già elaborano. E il repository delle evidenze, che smette di riempirsi di screenshot.

Vale la pena segnare la direzione, perché è il punto in cui si confondono due conversazioni diverse. Quando ho scritto di costruire il punteggio di rischio umano con i segnali del SIEM, il flusso andava verso l’interno, la telemetria entrava nel calcolo. Qui il flusso va verso l’esterno, il risultato del programma esce verso i sistemi dell’organizzazione. Sono due integrazioni distinte, e si contrattano e si autorizzano separatamente.

Quali attività smettono di dipendere da una persona?

Queste sono le cinque che compaiono per prime quando un cliente collega l’API, ordinate per la frequenza con cui ce le chiedono.

1. Il report periodico. Il dato viaggia da solo verso lo strumento di BI e il report si aggiorna senza che nessuno lo componga. È la mattinata della chiusura di mese che si recupera, ed è anche ciò che rende praticabile portare tre risposte concrete al comitato di direzione il giorno in cui il comitato le chiede, e non il giorno che segna il calendario.
2. L’attivazione e la disattivazione delle persone. Il sistema HR spinge il movimento e l’anagrafica del programma lo riflette. Chi entra riceve la sua formazione dal primo giorno e chi esce smette di averla assegnata, senza che nessuno debba ricordarsene.
3. Le evidenze di conformità normativa. Invece di ricostruire a mano chi ha completato cosa e quando, il repository delle evidenze si alimenta dalla fonte. È la meccanica che sostiene un cruscotto di conformità che si aggiorna in tempo reale invece di una fotografia trimestrale.
4. Il punteggio di rischio dentro il cruscotto di sicurezza. Lo scoring per persona arriva al SIEM o al GRC e si incrocia con il resto dei segnali, senza che il team di sicurezza debba aprire un altro strumento per consultarlo.
5. Il consolidamento tra organizzazioni. Quando il programma è distribuito su più organizzazioni, ognuna con la propria amministrazione, l’API è ciò che permette di leggere l’insieme senza entrare una per una.

Lo schema delle cinque è lo stesso. La piattaforma continua a fare quello che faceva e cambia chi lo avvia. Ognuna è un’attività che oggi ha un titolare, un calendario e un rischio di dimenticanza, e che passa a eseguirsi da sola.

Come si autorizza un’integrazione senza aprire troppo la piattaforma?

Collegare due sistemi è la parte facile. Che quel collegamento sia sicuro dipende da tre domande, e nessuna obbliga a entrare nella specifica.

Per conto di chi agisce l’integrazione? Ci sono due modalità. Una è quella del processo automatico che gira di notte senza nessuno dietro e ha un’identità propria. L’altra è quella di un’applicazione che agisce per conto di una persona concreta e ne eredita i permessi. Confonderle costa caro. Un processo automatico che gira con le credenziali di un amministratore umano trasforma quell’account in un account condiviso, e il giorno in cui quella persona lascia l’organizzazione nessuno sa cosa si rompe disattivandolo.

Quanto può toccare? OAuth 2.0, lo standard su cui si appoggia l’autenticazione, permette di restringere ogni integrazione a un permesso minimo, il suo scope. Il sistema che costruisce il report mensile può restare limitato alla lettura dei risultati senza toccare l’anagrafica delle persone. È la differenza tra dare accesso all’archivio intero e darlo a un solo cassetto. Che si possa fare non significa che si faccia, perché la via comoda è sempre concedere il permesso totale e andare avanti. Due dei dieci principali rischi di sicurezza delle API pubblicati da OWASP sono, appunto, falle nei permessi.

Cosa resta registrato? Ogni chiamata di un’integrazione è un’azione sui dati delle tue persone. Se il registro di audit non permette di ricostruire quale sistema ha consultato cosa e quando, hai un accesso che nessuno può rivedere dopo. Conviene chiederlo prima di firmare.

Quando conviene l’API e quando basta ciò che è già integrato?

Questa è la parte che un fornitore tende a saltare ed è quella che fa risparmiare più tempo.

Buona parte di ciò che un cliente crede di dover programmare è già risolto nel catalogo di integrazioni e si configura senza scrivere codice. L’autenticazione si delega al provider di identità con SAML 2.0, LDAP, Microsoft Entra ID, Google o Auth0, e il flusso completo è raccontato in come funziona l’integrazione SSO end to end. La consegna via Slack o Microsoft Teams, l’invio della formazione a Moodle, il collegamento con SAP SuccessFactors o con Vanta hanno il proprio connettore.

L’API entra dove il catalogo non arriva, e quasi sempre si tratta di ciò che è specifico di ogni organizzazione: il tuo strumento di BI, il tuo flusso interno di onboarding, il tuo GRC, l’incrocio dei risultati con un dato che esiste solo nei tuoi sistemi.

La regola pratica che uso in quelle conversazioni è semplice. Se il sistema dall’altra parte è un prodotto noto del mercato, cerca prima il connettore. Se il sistema dall’altra parte è tuo, è lì che entra l’API. E in entrambi i casi il collegamento avviene tra server, senza distribuire nulla sul dispositivo di ogni persona, che è la ragione per cui ci integriamo via API e non con un agente.

Domande frequenti

Cos’è l’API di una piattaforma di Cybersecurity awareness?
È l’interfaccia che permette a un altro sistema di consultare e modificare i dati del programma senza passare dallo schermo. Dove una persona entra e clicca, un programma effettua una chiamata e riceve lo stesso dato in formato JSON.

Cosa si può automatizzare con l’API di un programma di awareness?
Il report periodico verso uno strumento di BI, l’attivazione e la disattivazione delle persone a partire dal sistema HR, la raccolta delle evidenze di conformità, l’invio del punteggio di rischio per persona al SIEM o al GRC e il consolidamento dei risultati quando il programma è distribuito su più organizzazioni.

Serve l’API per collegare il programma al provider di identità?
No. L’autenticazione si risolve con i connettori del catalogo, come SAML 2.0, LDAP, Microsoft Entra ID, Google o Auth0, che si configurano senza scrivere codice. L’API serve per ciò che nessun connettore copre, come il tuo strumento interno di BI o il tuo flusso di onboarding.

Come si autorizza un’integrazione via API senza concedere accessi eccessivi?
Con OAuth 2.0 e accesso per scope. Lo scope delimita cosa ogni integrazione può leggere o scrivere, così il sistema che costruisce il report mensile resta limitato alla lettura dei risultati senza toccare l’anagrafica degli utenti.

Che differenza c’è tra integrare via API e installare un agente?
L’API si collega ai sistemi dell’organizzazione da server a server, senza distribuire né mantenere software sul dispositivo di ogni persona. Non c’è alcun componente da aggiornare sull’endpoint né una nuova superficie da amministrare.

Se stai valutando come collegare il programma a ciò che hai già, la documentazione dell’API e il catalogo dei connettori sono pubblici. Partire da lì di solito fa risparmiare la riunione in cui si scopre che il connettore esisteva già.