Construirea unui program de securitate de la zero

A fi angajat ca prima persoană în domeniul securității la o companie este un fel specific de haos. Nu există o coadă de ticket-uri, nu există instrumente stabilite și, de obicei, nu există o linie bugetară care să te aștepte. Ceea ce urmează este o hartă aproximativă a cum se desfășoară de obicei acele primele 90-180 de zile și ce efectiv aduce rezultate versus ce doar pare productiv.

Ce înseamnă de obicei „nimic"

Când oamenii spun că o companie nu are funcție de securitate, rar înseamnă zero controale. Înseamnă nicio persoană dedicată responsabilă. Ingineria probabil a activat deja niște politici AWS IAM de bază, IT-ul are antivirus implementat printr-un tool MDM, și cineva din finanțe are opinii despre SOC 2 pentru că un client a întrebat. Prima ta sarcină este inventarierea, nu implementarea. Înainte de a scrie o singură politică, află ce rulează deja: conturi cloud (și câte nu mai amintește nimeni că a creat), instrumente SaaS cu acces admin la codul sursă, și dacă există o sursă unică de adevăr pentru offboarding-ul angajaților. O foaie de calcul este acceptabilă pentru asta. O platformă GRC nu este prioritatea încă.

Primele 30 de zile: vizibilitate peste control

Rezistă la dorința de a scrie o politică de utilizare acceptabilă în săptămâna unu. Nimeni nu o va citi și nu va opri riscurile reale. În schimb, obține vizibilitate asupra a trei lucruri:

• Identity: extrage o listă completă de utilizatori de la furnizorul tău de identitate (Okta, Google Workspace, Azure AD) și fă referință încrucișată cu lista angajaților activi din HR. Vei găsi conturi fantomă.
• Cloud footprint: rulează ceva asemănător aws organizations list-accounts dacă ești pe AWS, sau verifică GCP's Asset Inventory, pentru a vedea câte medii există versus câte poate numi cineva din memorie.
• Code and secrets exposure: rulează gitleaks detect sau trufflehog filesystem . împotriva repo-urilor tale principale. A găsi o cheie API hardcodată în istoricul commit de acum doi ani este aproape garantat și este un mod rapid de a demonstra valoare.

Documentează constatările, dar nu transforma asta într-un raport de 40 de pagini pe care nimeni nu îl deschide. Un rezumat de risc cu o pagină și cinci puncte este citit de un CTO. Un PDF lung nu este.

Alegerea primelor trei controale

Fără efectiv și fără buget pentru instrumente, nu poți face totul deodată. Ordinea operațiilor care tinde să funcționeze:

1. MFA peste tot unde nu este deja, începând cu furnizorul de identitate, apoi GitHub/GitLab, apoi consolele cloud. Acest lucru singur închide calea cea mai comună de preluare a contului.
2. Logging centralizat pentru evenimentele cloud și autentificare. Chiar și un nivel gratuit al unui tool asemănător SIEM, sau doar trimiterea CloudTrail/GCP audit logs într-un bucket cu retenție, este mai bună decât a nu avea nimic când se întâmplă un incident.
3. Un plan scris, scurt de răspuns la incidente, chiar dacă este două pagini: cine primește pagina, cine vorbește cu clienții, cine are autoritate să oprească ceva. Nimeni nu se gândește să construiască asta până în ziua în care au nevoie, și atunci este prea târziu.

Observă că niciunul din acestea nu necesită un contract mare cu un vendor. Necesită decizii și urmărire.

Obținerea acceptării fără o linie de buget de securitate

Cel mai rapid mod de a-și pierde credibilitatea ca prima angajare în securitate este să apari cu o listă de dorințe de instrumente înainte de a arăta vreun rezultat. În schimb, leagă fiecare cerere de ceva concret: "am găsit trei utilizatori IAM cu chei de acces nerotite din 2021" funcționează mai bine decât "avem nevoie de un tool CSPM." Formulează cererile în termeni pe care ingineria și finanța deja se gândesc: rază de explozie redusă, audituri mai rapide, mai puține pagini la 2 dimineața. Dacă compania urmărește SOC 2 sau ISO 27001, termenul final de conformitate este de obicei cel mai bun punct de pârghie pentru a obține resurse, chiar dacă conformitatea în sine nu este scopul.

Greșeli comune în primul an

Cumpărarea unei platforme scumpe (SIEM, EDR, CSPM) înainte de a avea procesul sau efectivul pentru a o opera de fapt este cea mai comună risipă de buget timpuriu. Un tool de 50k dolari pe care nimeni nu îl reglează generează zgomot, nu detecție. La fel, scrierea politicilor copiate dintr-un șablon fără a le adapta la cum funcționează de fapt compania garantează că vor fi ignorate prima dată când cineva are nevoie de o excepție. Și a încerca să deții totul solo după primele șase luni este o cale către burnout; în momentul în care există traction, următoarea angajare ar trebui să fie de obicei cineva care poate deține detecția și răspunsul pentru ca tu să poți continua să construiești structura programului.

Security de la zero este în mare parte despre secvențiere: vezi ce există, închide golurile cele mai evidente, construiește suficient proces pentru ca deciziile să nu se bazeze pe memoria ta, și extinde de acolo.

Dacă felul acesta de construire a programului la nivel de bază te interesează, Korra Studio are segmente conexe despre fundamentele răspunsului la incidente și postura de securitate cloud care se potrivesc bine cu acesta.