Comprendere i risultati desiderati: come abbiamo selezionato il set di funzionalità di Cloud Defense Free

Quando abbiamo deciso di lanciare una versione gratuita di FireMon Cloud Defense sapevamo di dover bilanciare due sfide fondamentali:

• Sapevamo già che la nostra piattaforma era in grado di scalare, ma potevamo adattarla affinché scalasse in modo economicamente sostenibile a supporto di grandi aziende sul lungo periodo? Inutile dire che non potevamo semplicemente rilasciarla e sperare che le nostre fatture AWS non ci portassero all'amministrazione controllata.
• Con tali limitazioni economiche, potevamo offrire un set di funzionalità in grado di fornire valore reale agli utenti? In che cosa sarebbe consistito questo valore? Quali problemi avrebbe risolto?

La realtà è che "gratuito" (nel senso di gratis) non è mai del tutto gratuito, poiché utilizzare qualsiasi cosa richiede tempo e impegno. Non consideriamo il piano gratuito di Cloud Defense come briciole che lasciamo cadere dal tavolo: sappiamo che, se chiediamo agli utenti di registrarsi, effettuare il deployment e utilizzare la piattaforma, lo faranno solo se li aiuteremo a portare a termine il loro lavoro.

(E noi che cosa ne ricaviamo? Sappiamo che una certa percentuale passerà ai nostri piani a pagamento, ma la piattaforma gratuita ci aiuterà a ottenere feedback estremamente preziosi su ciò che le persone si aspettano dal loro CSPM e su come lo utilizzano, permettendoci di sperimentare nuove idee).

In futuri articoli approfondiremo la tecnologia, ma oggi vogliamo illustrare il processo con cui abbiamo deciso quali funzionalità includere nel piano gratuito. Poiché consideriamo questa versione della piattaforma un prodotto a sé stante, abbiamo deciso di adottare lo stesso approccio metodologico che guida gran parte della nostra strategia.

Definire i risultati desiderati

Noi di FireMon siamo grandi sostenitori del framework Jobs to be Done per la strategia di prodotto. Il nome è già abbastanza esplicativo, ma il framework orienta le decisioni di prodotto concentrandosi sul lavoro che il cliente sta cercando di svolgere e sui risultati specifici che si aspetta. Si tratta di una semplificazione estrema del framework JTBD, ma rende l'idea. Anziché concentrarsi sulle funzionalità, ci si concentra sui risultati che un potenziale cliente desidera ottenere utilizzando un prodotto, e li si usa poi per progettare le funzionalità.

Dopo un processo approfondito che ha incluso ricerche, esperienza e interviste, abbiamo definito una bozza di possibili risultati desiderati per i professionisti della sicurezza cloud:

• Migliorare la mia conoscenza e comprensione della nostra postura cloud sull'intera impronta cloud. (visibilità)
• Ridurre al minimo la probabilità che venga introdotta una configurazione errata nell'intera impronta cloud. (prevenzione)
• Ridurre le nostre esposizioni in materia di sicurezza e conformità cloud (volume e tempo) sull'intera impronta cloud in un ambiente decentralizzato. (remediation)
• Migliorare la nostra capacità di comunicare le problematiche di sicurezza cloud al management e alle autorità di regolamentazione.
• Ridurre il rischio di perdita e abuso degli accessi IAM ai nostri ambienti cloud.
• Migliorare la nostra capacità di prevenire, rilevare e rispondere agli attacchi cloud
• Mantenere la nostra sicurezza allineata alle modifiche dei servizi e delle piattaforme cloud di più provider.
• Ridurre gli attriti e i costi della sicurezza per i team di sviluppo e cloud senza aumentare i nostri rischi di sicurezza.
• Ridurre il rischio di una violazione della sicurezza quando effettuiamo il deployment tramite container.
• Ridurre il tempo che dedico all'integrazione della sicurezza cloud nel mio programma grazie ad API e strutture dati standard.

È evidente che esistono molti modi per affrontare ciascuno di questi problemi, quindi la domanda per noi era: quali potevamo offrire entro i vincoli economici della gestione di una piattaforma gratuita e ospitata? È molto diverso dal fornire software open source che qualcuno deve implementare ed eseguire per conto proprio. Volevamo costruire qualcosa di rapido e facile da usare quanto un prodotto commerciale (anzi, si spera più rapido e più semplice di molti prodotti che avete utilizzato in passato).

Tradurre i risultati in funzionalità

Con quell'elenco alla mano, era il momento di vedere che cosa potevamo adattare o costruire:

• Migliorare la mia conoscenza e comprensione della nostra postura cloud sull'intera impronta cloud. (visibilità)

La postura non riguarda necessariamente solo la sicurezza; la postura è il modo in cui le cose sono configurate. Poiché fornire semplicemente un elenco di configurazioni errate non avrebbe comunicato la postura, sapevamo di dover realizzare un inventario cloud, su scala enterprise, entro i nostri vincoli di costo. La nostra piattaforma supportava già un inventario in tempo reale, ma non era economicamente sostenibile estenderlo al piano gratuito.

Abbiamo concluso che potevamo bilanciare i costi e offrire comunque valore con scansioni una volta al giorno e uno storico dell'inventario di 30 giorni con tracciamento delle modifiche. Noterete che non stiamo ancora parlando di configurazioni errate di sicurezza, ma ci arriveremo. Dopo alcune analisi di modellazione dei costi, abbiamo capito che potevamo gestire tutto questo su scala enterprise (migliaia di account monitorati) rientrando nel nostro budget: in questo modo abbiamo soddisfatto entrambi i requisiti, offrire valore e controllare i costi.

Ciò ha in realtà richiesto un notevole sforzo ingegneristico, poiché il prodotto commerciale supportava principalmente aggiornamenti dell'inventario in tempo reale anziché scansioni periodiche. Tuttavia, abbiamo raggruppato tali aggiornamenti con alcune altre modifiche che volevamo apportare per migliorare l'efficienza complessiva: si allineavano bene, il che ha reso la decisione semplice.

• Ridurre al minimo la probabilità che venga introdotta una configurazione errata nell'intera impronta cloud. (prevenzione)

Prevenire le configurazioni errate nel cloud è un problema molto più complesso del rilevarle. Le si blocca nella pipeline CI/CD se si utilizza l'Infrastructure as Code? E le modifiche manuali? Come si gestiscono i flussi di lavoro senza aggiungere troppi attriti o compromettere il funzionamento?

Sapevamo di non poter implementare al momento una prevenzione completa all'interno di un prodotto gratuito. La nostra piattaforma attuale gestisce questo aspetto tramite automazione, la cui esecuzione su larga scala sarebbe troppo onerosa per un'offerta gratuita. Abbiamo però alcune idee che potrebbero funzionare e che ora sono nel nostro backlog di sviluppo.

• Ridurre le nostre esposizioni in materia di sicurezza e conformità cloud (volume e tempo) sull'intera impronta cloud in un ambiente decentralizzato. (remediation)

Questo è stato il pane quotidiano di Cloud Defense fin dalle prime versioni del prodotto. Sebbene la remediation automatizzata non fosse adatta al nostro piano gratuito (di nuovo, per bilanciare costi e complessità), non c'era ragione di non eseguire l'intera suite di controlli di sicurezza.

Ma ricevere un lungo elenco di potenziali problemi di sicurezza non aiuta necessariamente a risolverli. Un'altra funzionalità centrale del nostro prodotto è la profonda integrazione ChatOps. Da subito supportavamo Slack e Teams, ma Teams avrebbe richiesto maggiore assistenza perché… beh… è Teams. Abbiamo quindi deciso di abilitare completamente le nostre notifiche Slack granulari (per account o progetto), dato che per noi non comportavano costi significativi e offrivano molto valore agli utenti.

• Migliorare la nostra capacità di comunicare le problematiche di sicurezza cloud al management e alle autorità di regolamentazione.

I nostri costi interni per generare un report di conformità sono trascurabili, anche per ambienti di grandi dimensioni. Per la conformità, le valutazioni una volta al giorno tendono a soddisfare ampiamente questo risultato desiderato. Abbiamo dovuto investire in un nuovo sviluppo per supportare report PDF migliori per deployment di grandi dimensioni (ad esempio centinaia di account), ma ne avevamo comunque bisogno per i nostri clienti commerciali.

• Mantenere la nostra sicurezza allineata alle modifiche dei servizi e delle piattaforme cloud di più provider.

Poiché i nostri prodotti gratuito e commerciale utilizzano la stessa libreria di controlli, che aggiorniamo costantemente, questa funzionalità era disponibile fin da subito. Il nostro sforzo ingegneristico iniziale si è concentrato sull'ottimizzazione dei costi per AWS, quindi abbiamo deciso di lanciare inizialmente senza il supporto per Azure o GCP. Azure è quasi pronto, perciò gli utenti otterranno col tempo il supporto multi-cloud completo gratuitamente.

• Ridurre il rischio di perdita e abuso degli accessi IAM ai nostri ambienti cloud.

Disponiamo di una funzionalità davvero notevole chiamata Authorization Control che migliora sensibilmente la sicurezza IAM, ma le condizioni economiche non consentivano di includerla nel prodotto gratuito.

• Migliorare la nostra capacità di prevenire, rilevare e rispondere agli attacchi cloud

Il nostro prodotto commerciale supporta il rilevamento delle minacce in tempo reale, ma anche in questo caso le condizioni economiche non consentivano di supportarlo in una piattaforma gratuita, a causa dell'elevato volume di attività che dobbiamo monitorare in tempo reale.

• Ridurre gli attriti e i costi della sicurezza per i team di sviluppo e cloud senza aumentare i nostri rischi di sicurezza.
• Ridurre il rischio di una violazione della sicurezza quando effettuiamo il deployment tramite container.
• Ridurre il tempo che dedico all'integrazione della sicurezza cloud nel mio programma grazie ad API e strutture dati standard.

Tutti questi risultati comportavano costi e/o complessità che non ritenevamo di poter affrontare adeguatamente nel prodotto gratuito, per ragioni di costi di infrastruttura, supporto o sviluppo.

Comporre il set di funzionalità

I risultati desiderati, uniti alla nostra analisi dei costi, ci hanno aiutato a decidere quali funzionalità includere:

• Scansioni una volta al giorno
• Inventario delle risorse con uno storico di 30 giorni
• L'intera suite di controlli di sicurezza
• Report di conformità di base
• Integrazione con Slack
• AWS per ora, Azure e GCP con i prossimi aggiornamenti della piattaforma

Non sono state sempre decisioni facili. Ad esempio, anche un inventario di 30 giorni comporta dei costi, ma non ritenevamo che limitarsi a fornire report sulle configurazioni errate rispondesse adeguatamente alle esigenze di visibilità di un utente. Abbiamo inoltre concluso che limitare i controlli di sicurezza o richiedere il passaggio al prodotto commerciale per i report di conformità avrebbe prodotto un prodotto incapace di offrire un risultato sufficiente.

Questo insieme risponde ai principali risultati desiderati in termini di visibilità della sicurezza, e ai risultati relativi alla comunicazione, per migliorare la reportistica e ridurre i tempi di remediation. E sappiamo che qui c'è valore, poiché sono proprio i risultati desiderati per cui furono inizialmente creati gli strumenti OSS di sicurezza cloud, all'origine dell'intero mercato del Cloud Security Posture Management.

Il framework JTBD ci ha davvero aiutato a mantenere il focus sul miglioramento dei risultati per i clienti, invece di limitarci a scorporare alcune funzionalità che, insieme, non servono realmente a nessuno. Riteniamo che il risultato finale sia una piattaforma gratuita che offre valore reale ed è al tempo stesso così efficiente in termini di costi da poter essere supportata da noi sul lungo periodo.

La provi e ci dica cosa ne pensa. FireMon Cloud Defense è un progetto in evoluzione e un ottimo modo per migliorare la nostra capacità di aiutare i professionisti della sicurezza cloud a svolgere il proprio lavoro.