Een beveiligingsprogramma van nul opbouwen

Als eerste beveiligingsperson aangenomen worden bij een bedrijf is een specifiek soort chaos. Er is geen ticket queue, geen ingeburgerde tooling en meestal geen begrotingspost die op je wacht. Wat volgt is een ruw overzicht van hoe die eerste 90-180 dagen gewoonlijk verlopen, en wat echt verschil maakt versus wat zich productief voelt.

Wat "niets" meestal betekent

Als mensen zeggen dat een bedrijf geen beveiligingsfunctie heeft, bedoelen ze zelden nul controles. Ze bedoelen geen dedicated eigenaar. Engineering heeft waarschijnlijk enkele basis AWS IAM-beleidsregels ingesteld, IT heeft antivirus uitgerold via een MDM-tool, en iemand in finance heeft meningen over SOC 2 omdat een klant ernaar vroeg. Je eerste taak is inventaris, niet implementatie. Voordat je een enkel beleid schrijft, ontdek wat al draait: cloudaccounts (en hoeveel er niemand zich herinnert te hebben aangemaakt), SaaS-tools met beheerderstoegang tot broncode, en of er één bron van waarheid is voor offboarding van werknemers. Een spreadsheet is prima hiervoor. Een GRC-platform is nog niet de prioriteit.

De eerste 30 dagen: zichtbaarheid boven controle

Weersta de drang om in week één een acceptabel gebruiksbeleid te schrijven. Niemand zal het lezen en het zal de werkelijke risico's niet stoppen. Verkrijg in plaats daarvan zichtbaarheid in drie dingen:

• Identiteit: haal een volledige gebruikerslijst op van je identiteitsprovider (Okta, Google Workspace, Azure AD) en cross-reference met de actieve werknemerslijst van HR. Je zult spookaccounts vinden.
• Cloud-voetafdruk: voer iets uit als aws organizations list-accounts als je op AWS bent, of controleer GCP's Asset Inventory, om te zien hoeveel omgevingen bestaan versus hoeveel iemand uit geheugen kan noemen.
• Blootstelling van code en secrets: voer gitleaks detect of trufflehog filesystem . uit tegen je hoofdrepo's. Een hardcoded API-sleutel in commitgeschiedenis van twee jaar geleden vinden is vrijwel gegarandeerd en het is een snelle manier om waarde aan te tonen.

Documenteer bevindingen, maar maak hiervan geen 40-pagina rapport dat niemand opent. Een één-pagina risicosamenvatting met vijf bullets wordt gelezen door een CTO. Een lange PDF niet.

Je eerste drie controles kiezen

Zonder personeelssterkte en zonder toolingbudget kun je niet alles tegelijk doen. Volgorde die gewoonlijk werkt:

1. MFA overal waar het nog niet is, te beginnen met de identiteitsprovider, dan GitHub/GitLab, dan cloudconsoles. Dit sluit alleen al het meest voorkomende account-overnamepad af.
2. Gecentraliseerde logging voor cloud- en auth-events. Zelfs een gratis tier van een SIEM-achtig tool, of gewoon CloudTrail/GCP audit logs naar een bucket met retentie sturen, is beter dan niets als een incident gebeurt.
3. Een geschreven, kort incident response plan, zelfs als het twee pagina's zijn: wie krijgt gebeld, wie praat met klanten, wie heeft gezag om iets uit te schakelen. Niemand herinnert zich dit te bouwen totdat ze het nodig hebben, en tegen die tijd is het te laat.

Merk op dat geen van deze grote vendorcontracten vereisen. Ze vereisen beslissingen en opvolging.

Buy-in krijgen zonder beveiligingsbudgetpost

De snelste manier om geloofwaardigheid te verliezen als eerste beveiligingsmedewerker is om met een wensenlijstje van tools aan te komen voordat je resultaten hebt laten zien. Bind in plaats daarvan elk verzoek aan iets concreets: "we vonden drie IAM-users met niet-geroteerde toegangssleutels van 2021" valt beter uit dan "we hebben een CSPM-tool nodig." Frame verzoeken in termen waar engineering en finance al om geven: verkleinde impact, snellere audits, minder 2 uur-pagina's. Als het bedrijf SOC 2 of ISO 27001 nastreeft, is die nalevingstermijn vaak je beste hefboomcijfer voor middelen, zelfs als naleving zelf niet het doel is.

Veelvoorkomende fouten in het eerste jaar

Een duur platform kopen (SIEM, EDR, CSPM) voordat je het proces of personeelssterkte hebt om het werkelijk mee te werken is de enige meest voorkomende verspilling van vroeg budget. Een $50k tool die niemand afstemt genereert ruis, geen detectie. Evenzo garandeert het schrijven van beleidsregels gekopieerd van een template zonder aan te passen hoe het bedrijf werkelijk werkt dat ze worden genegeerd zodra iemand een uitzondering nodig heeft. En alles alleen na de eerste zes maanden willen bezitten is een burnout-pad; op het moment dat er tracties zijn, zou de volgende hire gewoonlijk iemand moeten zijn die detectie en respons kan bezitten zodat jij de programmastructuur kunt blijven bouwen.

Beveiliging van nul is vooral over volgorde: zie wat bestaat, sluit de luidste gaten, bouw genoeg proces zodat beslissingen niet afhangen van je geheugen, en breid van daar uit.

Als dit soort grondvlak-programmaaufbouw je interesseert, heeft Korra Studio gerelateerde segmenten over incident response-basisprincipes en cloud security posture die goed met dit segment samengaan.