Costruire un Programma di Security da Zero

Essere assunti come prima persona di security in un'azienda è un tipo specifico di caos. Non c'è una coda di ticket, nessuna strumentazione consolidata e di solito nessuna linea di budget che ti aspetta. Quello che segue è una mappa approssimativa di come questi primi 90-180 giorni tipicamente vanno, e cosa effettivamente muove l'ago della bilancia rispetto a quello che sembra solo produttivo.

Cosa di solito significa "niente"

Quando le persone dicono che un'azienda non ha una funzione di security, raramente intendono zero controlli. Intendono nessun proprietario dedicato. L'engineering ha probabilmente abilitato alcune policy AWS IAM di base, l'IT ha dell'antivirus implementato tramite uno strumento MDM, e qualcuno in finance ha opinioni su SOC 2 perché un cliente ha chiesto. Il tuo primo lavoro è inventariare, non implementare. Prima di scrivere una singola policy, scopri cosa sta già girando: account cloud (e quanti nessuno ricorda di aver creato), strumenti SaaS con accesso amministrativo al codice sorgente, e se c'è un'unica fonte di verità per l'offboarding dei dipendenti. Un foglio di calcolo va bene per questo. Una piattaforma GRC non è la priorità ancora.

I primi 30 giorni: visibilità rispetto al controllo

Resisti alla tentazione di scrivere una policy di uso accettabile nella prima settimana. Nessuno la leggerà e non fermerà i rischi effettivi. Invece, ottieni visibilità su tre cose:

• Identity: estrai un elenco completo di utenti dal tuo identity provider (Okta, Google Workspace, Azure AD) e incrocia rispetto all'elenco dei dipendenti attivi delle HR. Troverai account fantasma.
• Cloud footprint: esegui qualcosa come aws organizations list-accounts se sei su AWS, o controlla l'Asset Inventory di GCP, per vedere quanti ambienti esistono rispetto a quanti qualcuno riesce a ricordare.
• Esposizione di codice e segreti: esegui gitleaks detect o trufflehog filesystem . contro i tuoi repository principali. Trovare una chiave API hardcoded nella cronologia dei commit da due anni fa è quasi garantito ed è un modo veloce per dimostrare valore.

Documenta i risultati, ma non trasformarlo in un report di 40 pagine che nessuno apre. Un riepilogo dei rischi di una pagina con cinque bullet point viene letto da un CTO. Un PDF lungo no.

Scegliere i tuoi primi tre controlli

Senza risorse umane e senza budget per gli strumenti, non puoi fare tutto in una volta. L'ordine delle operazioni che tende a funzionare:

1. MFA ovunque non sia già attivo, iniziando con l'identity provider, poi GitHub/GitLab, poi console cloud. Questo da solo chiude il percorso più comune di account takeover.
2. Logging centralizzato per eventi cloud e auth. Anche il tier gratuito di uno strumento simile a un SIEM, o solo spedire i log CloudTrail/GCP audit a un bucket con retention, è meglio di non avere niente quando accade un incidente.
3. Un piano di risposta agli incidenti scritto e breve, anche se è due pagine: chi viene contattato, chi parla ai clienti, chi ha autorità di spegnere qualcosa. Nessuno ricorda di costruire questo fino al giorno in cui ne ha bisogno, e a quel punto è troppo tardi.

Nota che niente di questo richiede un grande contratto con un fornitore. Richiede decisioni e follow-through.

Ottenere il supporto senza una linea di budget per la security

Il modo più veloce di perdere credibilità come first security hire è arrivare con una lista dei desideri di strumenti prima di mostrare alcun risultato. Invece, collega ogni richiesta a qualcosa di concreto: "abbiamo trovato tre utenti IAM con access key non ruotate dal 2021" funziona meglio di "abbiamo bisogno di uno strumento CSPM." Inquadra le richieste in termini di cui l'engineering e la finance si preoccupano già: ridotto blast radius, audit più veloci, meno pagine alle 2 del mattino. Se l'azienda sta inseguendo SOC 2 o ISO 27001, quella scadenza di compliance è spesso il tuo punto di leva migliore per ottenere risorse, anche se la compliance stessa non è l'obiettivo.

Errori comuni nel primo anno

Acquistare una piattaforma costosa (SIEM, EDR, CSPM) prima di avere il processo o le risorse umane per operarla effettivamente è lo spreco più comune del budget iniziale. Uno strumento da $50k che nessuno regola genera rumore, non detection. Allo stesso modo, scrivere policy copiate da un template senza adattarle a come l'azienda effettivamente lavora garantisce che vengano ignorate la prima volta che qualcuno ha bisogno di un'eccezione. E cercare di possedere tutto da solo oltre i primi sei mesi è un percorso verso il burnout; nel momento in cui c'è trazione, la prossima assunzione dovrebbe di solito essere qualcuno che possa possedere detection e response così potrai continuare a costruire la struttura del programma.

La security da zero è principalmente una questione di sequenziamento: vedi cosa esiste, chiudi i gap più evidenti, costruisci abbastanza processo che le decisioni non si affidino alla tua memoria, e espandi da lì.

Se questo tipo di construction di programmi a livello base ti interessa, Korra Studio ha segmenti correlati su incident response fundamentals e cloud security posture che si abbinano bene con questo.