Budowanie programu bezpieczeństwa od zera

Zatrudnienie się jako pierwsza osoba zajmująca się bezpieczeństwem w firmie to szczególny rodzaj chaosu. Nie ma kolejki zgłoszeń, nie ma ustalonych narzędzi i zwykle nie ma pozycji budżetowej czekającej na ciebie. Poniżej znajduje się rough map tego, jak zwykle przebiegają pierwsze 90-180 dni i co naprawdę zmienia sytuację versus co tylko się wydaje produktywne.

Co "nic" zwykle oznacza

Gdy ludzie mówią, że firma nie ma funkcji bezpieczeństwa, rzadko mają na myśli zero kontroli. Mają na myśli brak dedykowanego właściciela. Engineering prawdopodobnie włączył już jakieś podstawowe AWS IAM policies, IT ma jakiś antywirus rozprowadzony przez narzędzie MDM, a ktoś z finansów ma zdanie na temat SOC 2, bo klient zapytał. Twoja pierwsza praca to inwentaryzacja, nie implementacja. Zanim napiszesz jedną politykę, sprawdź co już działa: konta cloud (i ile ich nikt nie pamięta, że stworzył), narzędzia SaaS z dostępem administratora do kodu źródłowego i czy istnieje jedno źródło prawdy dla offboardingu pracowników. Arkusz kalkulacyjny jest w porządku. Platforma GRC nie jest jeszcze priorytetem.

Pierwsze 30 dni: widoczność ponad kontrolą

Oprzij się pokusie napisania acceptable use policy w pierwszym tygodniu. Nikt jej nie będzie czytać i nie zatrzyma faktycznych zagrożeń. Zamiast tego uzyskaj widoczność trzech rzeczy:

• Identity: pobierz pełną listę użytkowników z dostawcy usług tożsamości (Okta, Google Workspace, Azure AD) i zestawić ją z listą aktywnych pracowników z HR. Znajdziesz konta-duchy.
• Cloud footprint: uruchom coś w rodzaju aws organizations list-accounts jeśli jesteś na AWS, lub sprawdź Asset Inventory w GCP, aby zobaczyć ile środowisk istnieje versus ile ktokolwiek potrafi nazwać z pamięci.
• Code and secrets exposure: uruchom gitleaks detect lub trufflehq filesystem . przeciwko twoim głównym repozytoriom. Znalezienie hardcoded API key w historii commitów z dwa lata temu jest prawie gwarantowane i to szybki sposób na zademonstrowanie wartości.

Zdokumentuj znaleziska, ale nie zamieniaj tego w 40-stronnicowy raport, który nikt nie otworzy. Jednostronicowe streszczenie ryzyka z pięcioma punktami przeczyta CTO. Długi PDF nie.

Wybór twoich pierwszych trzech kontroli

Bez pracowników i bez budżetu na narzędzia, nie możesz robić wszystkiego naraz. Kolejność operacji, która zwykle działa:

1. MFA wszędzie, gdzie jeszcze nie jest, zaczynając od dostawcy usług tożsamości, potem GitHub/GitLab, potem konsoli cloud. To samo w sobie zamyka najczęstszą ścieżkę przejęcia konta.
2. Scentralizowane logowanie dla zdarzeń cloud i auth. Nawet darmowy tier narzędzia SIEM-adjacent, lub po prostu wysyłanie CloudTrail/GCP audit logs do bucketu z retencją, jest lepsze niż nic, gdy zdarzenie się zdarzy.
3. Napisany, krótki plan reagowania na incydenty, nawet jeśli to dwie strony: kto dostaje alert, kto rozmawia z klientami, kto ma uprawnienia do wyłączenia czegoś. Nikt nie pamięta, żeby to zbudować, aż do dnia, gdy tego potrzebuje, a wtedy jest za późno.

Zwróć uwagę, że żaden z nich nie wymaga dużego kontraktu z dostawcą. Wymagają decyzji i konsekwencji.

Uzyskanie poparcia bez linii budżetu bezpieczeństwa

Najszybszy sposób na utratę wiarygodności jako pierwsza osoba zajmująca się bezpieczeństwem to pojawić się z listą życzeń narzędzi zanim pokażesz jakiekolwiek wyniki. Zamiast tego wiąż każdą prośbę z czymś konkretnym: "znaleźliśmy trzech IAM users z nieobróconymi access keys z 2021" działa lepiej niż "potrzebujemy narzędzie CSPM." Formułuj prośby w kategoriach, którymi zajmują się engineering i finance: zmniejszona stefa rażenia, szybsze audyty, mniej 2 rano alertów. Jeśli firma goni deadline SOC 2 lub ISO 27001, ten termin compliance jest zwykle twoim najlepszym punktem dźwigni do uzyskania zasobów, nawet jeśli samo compliance nie jest celem.

Popularne błędy w pierwszym roku

Kupienie drażliwej platformy (SIEM, EDR, CSPM) zanim będziesz mieć proces lub pracowników, aby faktycznie ją obsługiwać, jest najbardziej powszechnym marnowaniem wczesnego budżetu. Narzędzie za 50k dolarów, które nikt nie tunuje, generuje szum, nie detektywne. Podobnie, pisanie polityk skopiowanych z szablonu bez dostosowania do tego, jak firma faktycznie działa, gwarantuje, że będą ignorowane za pierwszym razem, gdy ktoś będzie potrzebować wyjątku. I próba bycia właścicielem wszystkiego samemu po pierwszych sześciu miesiącach to ścieżka do wypalenia; w momencie gdy jest traction, następne zatrudnienie powinno zwykle być kimś, kto może być właścicielem detektywnej i response, aby mogłeś nadal budować strukturę programu.

Bezpieczeństwo od zera to głównie sekwencja: zobacz co istnieje, zamknij najgłośniejsze luki, zbuduj tyle procesu, że decyzje nie zależą od twojej pamięci, i rozwijaj się od tam.

Jeśli ten rodzaj budowania programu na poziomie podstawowym cię interesuje, Korra Studio ma powiązane segmenty na temat fundamentów incident response i cloud security posture, które dobrze się do tego pasują.