pracowałem z dziesiątkami SecOps oraz Wykrywanie i reagowanie zespołów w ciągu ostatnich kilku lat i stało się dla mnie jasne, jak ważne jest naprawienie jak największej liczby problemów związanych z bezpieczeństwem pod prąd. Lub jak to jest powszechniej znane, „Zmiana zabezpieczenia w lewo”. Ogólnie widzę trzy obozy na „Zmiana zabezpieczenia w lewo” — 1) nie rozumiem, 2) rozumiem, nie wykonujemy, 3) rozumiem, wykonujemy. Możesz być w tym trzecim obozie i myśleć, że przesunięcie w lewo jest oczywiste i powszechnie znane. Pozwolę sobie pokornie przypomnieć, że tam jest wielki świat, a przeciętna organizacja jest żałośnie niedojrzała w kwestii bezpieczeństwa. Innymi słowy, obozy pierwszy i dwa łącznie 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.
Najpierw definicja zestawu poziomów. Do zrobienia „Zmiana zabezpieczenia w lewo” oznacza podniesienie poziomu bezpieczeństwa wcześnie i często w cyklu rozwoju rozwoju organizacji, który określiłbym jako nadzbiór zwykłego cyklu rozwoju oprogramowania. Obejmuje to wszystko, co ma związek z pracownikami, dostawcami, kontrolami bezpieczeństwa i cyfrowym śladem organizacji. Problemy z zabezpieczeniami, którym zapobiegano lub zostały wykryte wcześniej, zanim rozprzestrzenią się w całej organizacji, są łatwiejsze i tańsze do wdrożenia.
Teraz do analizy. Moim zdaniem ten temat jest zbyt skomplikowany, aby przeprowadzić jakąś analizę na wysokim poziomie i twierdzić, że coś takiego „przesunięcie w lewo sprawia, że jesteś o 10% szybszy i oszczędzasz 30%”, jest za dużo zmiennych. Moje podejście będzie modelowaniem bardzo konkretnych, mikroprzykładów hipotetycznej organizacji przesuwającej się w lewo i zobaczenia, 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
Proste rozpoczęcie. Jeśli myślisz „każda organizacja ma wszędzie włączoną usługę MFA”, potrzebujesz sprawdzenia rzeczywistości. Niemniej jednak MFA jako pojedyncza kontrola wdrożona w całej organizacji jest doskonałym, intuicyjnym przykładem. Uważa się, że MFA przesuwa się w lewo, ponieważ przede wszystkim zapobiega wielu ryzykownym zachowaniom związanym z uwierzytelnianiem. Ten model porównuje hipotetyczną organizację z usługą MFA wdrożoną wszędzie prawidłowo z taką, która używa tylko 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 jest prawdopodobnie najlepiej rozwiniętą kategorią „Zmiana zabezpieczenia w lewo”i istnieje wiele świetnych narzędzi skoncentrowanych na aplikacji lub bezpieczeństwo infrastruktury testowanie. Świetnie tutaj wygląda oprzyrządowanie osadzone w przepływie pracy programisty bez tarcia. Źle lub bezpieczeństwo trzymane na właściwym poziomie, wygląda na to, że zespół ds. bezpieczeństwa oderwał się od programowania i znajdowania problemów z bezpieczeństwem po dostarczeniu rzeczy do produkcji. Model ten porównuje organizację zajmującą się tworzeniem oprogramowania z DevSecOps w pełni wdrożone, w przeciwieństwie do takiego, który przyjmuje czysto reaktywne podejście do bezpieczeństwo 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 ma świetne badania pomocnicze dotyczące kosztów naprawy luk bezpieczeństwa na różnych etapach rozwoju (testy jednostkowe, testy integracyjne, testy systemowe, etapowanie, produkcja itp.), więc nie było zaskoczeniem, gdy zobaczyłem dramatyczne różnice w przesunięciu w lewo i w prawo w tym modelu. Naprawdę nie ma wymówki w 2022 roku, aby nie być mistrzem DevSecOps — dotyczy to każdej wielkości organizacji zajmujących się tworzeniem oprogramowania (organizacje te mogą być jednostkami w ramach szerszych 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.
