W ciągu ostatnich kilku lat współpracowałem z dziesiątkami zespołów SecOps i Detection and Response i stało się dla mnie jasne, jak ważne jest naprawienie jak największej liczby problemów z bezpieczeństwem w górę rzeki . Lub, jak jest to powszechnie znane, „Przesunięcie w lewo bezpieczeństwa” . Ogólnie rzecz biorąc, widzę trzy obozy w kwestii „Przesunięcia w lewo bezpieczeństwa” — 1) nie rozumiem tego, 2) rozumiem to, ale nie wdrażam, 3) rozumiem to, ale wdrażam. Możesz być w tym trzecim obozie i myśleć, że przesunięcie w lewo jest oczywiste i powszechnie znane. Pozwól, że pokornie przypomnę, że świat jest duży, a przeciętna organizacja jest żałośnie niedojrzała w kwestii bezpieczeństwa. Innymi słowy, obozy pierwszy i drugi razem wzięte znacznie przewyższają liczebnie obóz trzeci.
Dlaczego? Dobrze „Zmiana zabezpieczenia w lewo” jest nowy, ale co ważniejsze, jest trudny. To tak, jakby konsekwentnie jeść warzywa w obliczu innych słodkich pokus. Wszyscy dostawcy zabezpieczeń twierdzą, że przesunięcie w lewo umożliwia szybszą dostawę i niższe koszty, ale moim zdaniem nigdy nie należy tego w znaczący sposób określać ilościowo. W tej analizie spróbuję wyposażyć praktyków w dane na temat „Shift Left Security”, które zrozumie każdy dyrektor i kontroler budżetu — ekonomia biznesu. Wpisuje się to w ważny, szerszy temat, jakim jest konieczność ułożenia zabezpieczeń w osiąganiu wyników biznesowych — rozwijanie TAM, przyspieszenie cykli sprzedaży, szybsza wysyłka produktu — a nie tylko działanie jako ćwiczenie mające na celu zmniejszenie ryzyka.
Po pierwsze, definicja poziomu. Przesunięcie bezpieczeństwa w lewo oznacza przesunięcie zabezpieczeń na wyższy poziom i częste ich wdrażanie w cyklu rozwoju organizacji, który zdefiniowałbym jako rozszerzenie typowego cyklu rozwoju oprogramowania. Obejmuje to wszystko, co dotyczy pracowników, dostawców, mechanizmów kontroli bezpieczeństwa i cyfrowego śladu organizacji. Problemy bezpieczeństwa, którym zapobieżono lub które wykryto wcześniej, zanim rozprzestrzenią się w całej organizacji, są łatwiejsze i tańsze we wdrożeniu.
A teraz analiza. Moim zdaniem, ten temat jest zbyt skomplikowany, aby przeprowadzać analizę na wysokim poziomie i twierdzić coś w stylu: „przesunięcie w lewo przyspiesza o 10% i oszczędza 30%” , ponieważ jest zbyt wiele zmiennych. Moje podejście polega na modelowaniu bardzo konkretnych, mikroprzykładów hipotetycznej organizacji przesuwającej się w lewo i zobaczeniu, czego można się z tego nauczyć.
Jeśli chodzi o parametry w poniższych modelach — istnieją bardzo przybliżone szacunki (lub nawet pełne szacunki w niektórych miejscach), które próbuję zebrać, gdy dostępne dane są słabe. Przeczytaj źródła mojego komentarza i daj mi znać, jeśli znasz bardziej wiarygodne badania! Ponadto „naruszenia danych” nie są jedyną formą cyberwydarzeń, o które należy się martwić, zakotwiczyłem je, ponieważ istnieją solidne badania dotyczące kosztów w porównaniu z bardziej mglistymi skutkami marki, zaufania itp.
Model 1 – MSZ wdrożony w całej organizacji
Zacznijmy od czegoś prostego. Jeśli myślisz, że „każda organizacja ma włączoną autoryzację wieloskładnikową wszędzie” , potrzebujesz zderzenia z rzeczywistością. Niemniej jednak, MFA jako pojedyncza kontrola wdrożona w całej organizacji jest świetnym, intuicyjnym przykładem. MFA jest postrzegane jako przesunięcie w lewo, ponieważ zapobiega wielu ryzykownym zachowaniom związanym z uwierzytelnianiem. Ten model porównuje hipotetyczną organizację z prawidłowo wdrożoną autoryzacją wieloskładnikową wszędzie z taką, która korzysta tylko z uwierzytelniania jednoskładnikowego (1FA).
Koszty modelu:
- SOC Koszty personelu = (Alerty logowania na użytkownika na dzień, związane tylko z 1FA) * (Wielkość organizacji) * (Średnia roczna SOC Koszt analityka) / (Liczba alertów triażowanych na analityka na dzień)
- SOC Koszty oprogramowania = (Alerty logowania na użytkownika na dzień, związane tylko z 1FA) * (Wielkość organizacji) * (Koszt oprogramowania na alert w celu pomocy w dochodzeniu) * (365 dni)
- Utrata produktywności w dolarach = (Średnia liczba MFA na dzień na użytkownika) * (Wielkość organizacji) * (Czas do MFA w sekundach) / (1 minuta / 60 sekund) / (1 godzina / 60 minut) / (1 dzień / 24 godziny) * ( Średni roczny koszt pracownika)
- Oczekiwana wartość kosztu naruszenia = (Średni koszt naruszenia danych) * (Prawdopodobieństwo naruszenia danych)
Parametry modelu:
- Wielkość organizacji: 10000 Pracowników (Użytkownicy)
- Czas do MFA (Uwierzytelnianie Google lub odpowiednik): 10 sekund [1]
- Średnia liczba MFA na dzień na użytkownika: 1 [2]
- Średni roczny koszt pracownika: $100,000
- Alerty logowania na użytkownika na dzień związane tylko z 1FA (dostęp nietypowy, udostępnianie hasła itp.): 0.01 [3]
- Alerty segregowane na analityka na dzień: 100 [4]
- Średnia roczna SOC Koszt analityka: $100,000
- Koszt oprogramowania na alert, aby pomóc w dochodzeniu: 0.10 USD [5]
- Procent naruszeń danych w wyniku kradzieży lub naruszenia danych uwierzytelniających: 19% [6]
- Średni koszt naruszenia danych: 4.35 mln USD [7]
- Podstawowe prawdopodobieństwo naruszenia danych: 1.13% [8]
- Prawdopodobieństwo naruszenia danych przez MFA: 0.92% [9]
Szczerze mówiąc byłem trochę zaskoczony, jak bardzo tarcia tradycyjnej pomocy makrofinansowej zsumowały się w przeliczeniu na dolary z tej analizy. Tym bardziej warto stosować niewidoczne rozwiązania MFA.
Model 2 — DevSecOps prawidłowo wykonane
DevSecOps to prawdopodobnie najlepiej rozwinięta kategoria „Shift Left Security” i istnieje wiele świetnych narzędzi skoncentrowanych na testowaniu bezpieczeństwa aplikacji lub infrastruktury . Świetne w tym przypadku oznacza narzędzia wbudowane w proces pracy programisty bez żadnych tarć. Złe, czyli takie, które są trzymane z boku, oznacza zespół ds. bezpieczeństwa oderwany od rozwoju i wykrywający problemy z bezpieczeństwem po wdrożeniu oprogramowania do produkcji. Ten model porównuje organizację zajmującą się rozwojem oprogramowania z w pełni wdrożonym DevSecOps z organizacją stosującą czysto reaktywne podejście do bezpieczeństwa oprogramowania.
Koszty modelu:
- Koszty programisty = (różne aplikacje produkcyjne opracowane przez organizację) * (średnia liczba luk w aplikacji produkcyjnej) * (średnia liczba godzin opracowywania w celu usunięcia luki w godzinach) * (1 rok / 52 tygodnie) * (1 tydzień / 40 przepracowanych godzin) * (średnia roczna Koszt programisty)
- Koszty analityka bezpieczeństwa = (różne aplikacje produkcyjne opracowane przez organizację) * (średnia liczba luk na aplikację produkcyjną) * (średnia liczba godzin pracy zespołu ds. bezpieczeństwa w celu usunięcia luki wykrytej w produkcji w godzinach) * (1 rok / 52 tygodnie) * (1 tydzień / 40 przepracowanych godzin) * (Średni roczny koszt analityka bezpieczeństwa)
- Oczekiwana wartość kosztu naruszenia = (Średni koszt naruszenia danych) * (Prawdopodobieństwo naruszenia danych)
Parametry modelu:
- Odrębne aplikacje produkcyjne opracowane przez organizację: 17 [10]
- Średnia liczba luk na aplikację produkcyjną: 30.59 [11]
- Średnia liczba godzin opracowywania w celu usunięcia każdej luki w rozwoju: 3.61 godziny [12]
- Średnia liczba godzin opracowywania w celu usunięcia każdej luki w zabezpieczeniach wykrytej w produkcji: 10.71 godziny [13]
- Średni roczny koszt programisty: $150,000
- Średnia liczba godzin pracy zespołu ds. bezpieczeństwa na usunięcie każdej luki w zabezpieczeniach wykrytej w środowisku produkcyjnym: 3.10 [14]
- Średni roczny koszt analityka bezpieczeństwa: $100,000
- Średni średni czas usuwania luk — niska częstotliwość skanowania — 1–12 skanów dziennie (zabezpieczenie Shift Right): 217 dni [15]
- Średni średni czas usuwania luk — wysoka częstotliwość skanowania — ponad 260 skanów dziennie (przesunięcie po lewej stronie zabezpieczenia): 62 dni [15]
- Zakładana redukcja luk w zabezpieczeniach dzięki wysokiej częstotliwości skanowania: 71% [16]
- Procent naruszeń danych w wyniku luk w aplikacjach: 43% [17]
- Średni koszt naruszenia danych: 4.35 mln USD [6]
- Podstawowe prawdopodobieństwo naruszenia danych: 1.13% [7]
- Prawdopodobieństwo naruszenia danych przy wysokiej częstotliwości skanowania: 0.79% [18]
DevSecOps posiada solidne badania wspierające dotyczące kosztów naprawy luk w zabezpieczeniach na różnych etapach rozwoju (testy jednostkowe, testy integracyjne, testy systemowe, etapy testowania, produkcja itd.), więc nie było zaskoczeniem, że w tym modelu tak bardzo różnią się od siebie tendencje przesunięcia w lewo i w prawo. W 2022 roku nie ma żadnego usprawiedliwienia dla braku poparcia dla DevSecOps — dotyczy to organizacji zajmujących się tworzeniem oprogramowania, niezależnie od ich wielkości (organizacje te mogą być jednostkami w ramach większych organizacji).
Model 3 — wdrażanie i usuwanie solidnych pracowników i zasobów
Onboarding i offboarding pracowników i zasobów to bardzo niedoceniane przepływy pracy związane z bezpieczeństwem. Zrobione dobrze, oferuje możliwość tworzenia czystych danych i gwarantuje ścisłą kontrolę (EPDR, VPN, Email Security, szyfrowanie dysku, przeglądarka kontrolowana przez organizację itp.) oraz stany dostępu w czasie onboardingu i offboardingu. Źle wykonane, tworzy dodatkową pracę i pozostawia wiele przypadkowi lub ręcznemu przepływowi pracy przez ludzi. Istnieje wiele systemów, które pomagają pokierować tymi procesami. Ten model porównuje organizację z doskonałym wdrażaniem i odrzucaniem zabezpieczeń w porównaniu z organizacją z ręcznymi, podatnymi na błędy przepływami pracy.
Koszty modelu:
- Koszty czasu konfiguracji narzędzia do wdrażania pracowników = (Wielkość organizacji) * (Wskaźnik obrotu organizacji) * (Czas na ręczne wdrożenie IT w minutach) * (1 godzina / 60 minut) * (1 tydzień / 40 godzin pracy) * (1 rok / 52 tygodnie) * (średni roczny pracownik Koszt)
- Płatne SOC Koszty: = (Organizacja SOC Rozmiar) * (Średnia roczna SOC Koszt analityka) * (Dostępne współczynniki efektywności)
- Oczekiwana wartość kosztu naruszenia = (Średni koszt naruszenia danych) * (Prawdopodobieństwo naruszenia danych)
Parametry modelu:
- Wielkość organizacji (stała przez rok): 10000 Pracowników (Użytkownicy)
- Roczny wskaźnik obrotu organizacji: 47.2% [19]
- Średni roczny koszt pracownika: $100,000
- Czas na ręczną instalację i konfigurację EPDR i VPN na nowych laptopach: 20 minut [20]
- Organizacja SOC Rozmiar: 3 FTE
- Średnia roczna SOC Koszt analityka: $100,000
- SOC Wzrost efektywności dzięki przejrzystemu mapowaniu „kto jest właścicielem czego” w wyniku wdrażania pracowników i aktywów: 10% [21]
- Procent naruszeń danych w wyniku phishingu: 16% [22]
- Odsetek naruszeń danych w wyniku niewłaściwego odesłania pracowników: 10% [23]
- Średni koszt naruszenia danych: 4.35 mln USD [6]
- Podstawowe prawdopodobieństwo naruszenia danych: 1.13% [7]
- Prawdopodobieństwo naruszenia danych z gwarantowanymi prawidłowymi kontrolami na każdym laptopie pracownika i automatycznym odejściem na pokład: 0.85% [24]
Ludzie popełniają błędy; zachowaj powtarzalne zadania maszynom. Nawet jeśli założysz, że w zadaniu takim jak onboarding i offboarding ludzie popełniają błędy tylko w 5% przypadków, to 472 błędy w tym modelu, które obejmują wszystkich tych pracowników, którzy są onboardingowi i offboardingowi. To jest dużo niskiego ryzyka wiszącego owocu, aby zdjąć ze stołu. Zainwestuj w solidne narzędzie, które zarządza tym dla Twojej organizacji, to się zwróci.
wnioski
Bezpieczeństwo to skomplikowana sieć kompromisów, a przesunięcie zabezpieczeń w lewo nie jest niczym innym. Najczęściej badałem to ćwiczenie analityczne, ponieważ nie mogę uwierzyć, że nadal widzę alerty na wolności, które są możliwe tylko dlatego, że organizacja nie wdraża MFA. Rozumiem jednak, że podstawy mogą być trudne, między walką ze starym długiem IT a biurokracją. Niezależnie od twojej roli, miejmy nadzieję, że dostarczyło ci to nowej amunicji, w jaki sposób „Shift Left Security” może napędzać wyniki biznesowe i płacić za wszelkie nowe narzędzia wymagane wyłącznie z punktu widzenia ekonomii.
Teraz idź i zjedz swoje warzywa.
