Przygotowania

W tej sekcji omówimy szczegółowo, jak przygotować organizację do uruchomienia i prowadzenia skutecznego programu ujawniania luk w zabezpieczeniach. Dowiesz się też praktyczne wskazówki, jak uzupełnić wykryte luki.

Znajdowanie błędów

Uzupełnienie obecnego programu bezpieczeństwa o zewnętrznych badaczy bezpieczeństwa może być doskonałym sposobem na znalezienie złożonych problemów i zatuszenie luk w zabezpieczeniach. Korzystanie z platformy VDP do znajdowania podstawowych problemów z bezpieczeństwem, które można wykryć wewnętrznie, jest stratą zasobów.

Zarządzanie aktywami

Jeśli chodzi o wykrywanie błędów, jedynym sposobem na rozpoczęcie gry od razu jest sprawdzenie, co się dzieje. Możesz kupić sto narzędzi zabezpieczających, ale nie będzie to miało wpływu na to, w jakim stopniu Twoje aplikacje, systemy i usługi działają bez Twojej wiedzy. Zwłaszcza jeśli nie masz możliwości wykrycia tych zasobów ani przeprowadzenia oceny ich bezpieczeństwa. Skontaktuj się z osobami i zespołami odpowiedzialnymi za pomoc w tworzeniu nowych aplikacji, systemów i usług, aby dowiedzieć się, czy są w stanie przeprowadzić proces tworzenia i utrzymywania załatwienia sprawy. Jeśli w trakcie tego procesu nie ma obecnie procesu, to doskonała okazja, aby nawiązać z nimi współpracę. Znajomość zasobów organizacji jest najlepszym miejscem na rozpoczęcie ataku. W ramach tego procesu zespół ds. zabezpieczeń powinien brać udział w tworzeniu nowej implementacji infrastruktury, która ma przeprowadzać kontrole bezpieczeństwa. Warto dysponować obszernym asortymentem zasobów i właścicieli. Ten typ zasobów reklamowych jest przydatny podczas stosowania nowych poprawek, które wymagają tymczasowego wyłączenia niektórych systemów. Zawiera on plan działania obejmujący osoby lub zespoły, które muszą zostać poinformowane, i których systemów dotyczy. Solidny proces zarządzania zasobami sprawia, że właściciele są identyfikowani na wcześniejszych etapach, regularnie aktualizowana i wszystkie systemy w organizacji działają zgodnie z oczekiwaniami.

Oprócz aktywnego zarządzania zasobami zastanów się, jakie działania naprawcze możesz podjąć, aby zidentyfikować zasoby należące do Twojej organizacji, ale które mogą nie przejść przez standardowe procesy zarządzania zasobami. Mogą one obejmować te same „procesy przywracania” używane przez badaczy bezpieczeństwa, którzy uczestniczą w programach VDP i wykorzystują programy umożliwiające poszukiwanie błędów. Możesz na przykład skorzystać z bezpłatnych narzędzi typu open source, które skanują i obliczają zakresy adresów IP lub domeny należące do internetu, które mogą należeć do Twojej organizacji. Wyszukiwanie w Google raportu o błędach może przynieść wiele wskazówek i podpowiedzi, które pomogą Ci zidentyfikować zasoby w organizacji.

Podstawowe skanowanie pod kątem luk w zabezpieczeniach

Skoro już wiesz, gdzie szukać problemów związanych z bezpieczeństwem, przejdźmy do sposobu, w jaki to faktycznie robisz. W zależności od zasobów organizacji możesz stosować różne poziomy głębokości, ale musisz znaleźć równowagę między wewnętrznymi działaniami związanymi z bezpieczeństwem a zewnętrzną społecznością hakerską, wykorzystując program ujawniania luk w zabezpieczeniach. To saldo różni się w zależności od dostępnych zasobów.

Wybierz narzędzia

Istnieje wiele różnych narzędzi, które pomagają zidentyfikować luki w zabezpieczeniach. Niektóre narzędzia do wykrywania luk w zabezpieczeniach są dostępne bezpłatnie, a inne są płatne. Wybór narzędzi, które warto wybrać, zależy od indywidualnych potrzeb.

• Wymagania Twojej organizacji
• Jak dobrze wszystkie narzędzia spełniają te wymagania
• Jeśli zalety narzędzia przewyższają koszty (finanse i wdrożenie).

Aby ocenić przydatność różnych narzędzi, możesz skorzystać z tego szablonu (OpenDocument .ods, Microsoft Excel .xlsx). Szablon zawiera przykładowe wymagania, ale należy omówić je z zespołami ds. bezpieczeństwa, IT i inżynierów, aby dostosować je do wymaganych funkcji. Przed uruchomieniem programu ujawniania luk w zabezpieczeniach musisz mieć co najmniej możliwość skanowania zasobów pod kątem luk w zabezpieczeniach (np. witryn internetowych, interfejsów API czy aplikacji mobilnych). Pomoże Ci to znajdować i łatwiej wykrywać luki w zabezpieczeniach, zanim zaprosisz zewnętrznych badaczy bezpieczeństwa do testowania tych zasobów i usług.

Konfiguracja skanowania

Automatyczne skanowanie pod kątem luk w zabezpieczeniach może pomóc w znalezieniu wielu problemów, ale może również powodować występowanie fałszywych dopasowań. Dlatego przed udostępnieniem wyników zespołom, których dotyczy problem, musisz mieć odpowiednie zasoby. Musisz wdrożyć procesy, aby regularnie skanować strony i zadbać o ich wyniki. Będzie to wyglądać inaczej w przypadku każdej organizacji, ale warto określić co najmniej:

• Częstotliwość skanowania
  • Ciągłe
  • Co tydzień
  • Co miesiąc
• Które zasoby są skanowane
• Dane logowania
  • Uwierzytelnione a nieuwierzytelnione skanowania
  • (Wskazówka: jeśli nie skanujesz przy użyciu danych logowania, podczas uruchamiania VDP testerzy zabezpieczeń testują je za pomocą danych logowania, co może spowodować duży wzrost zidentyfikowanych luk w zabezpieczeniach).
• Role i obowiązki
  • Wskaż członków zespołu odpowiedzialnych za przeprowadzanie skanowania
  • W razie potrzeby skonfiguruj rotację
• Skanuj wyniki
  • Weryfikowanie wyników skanowania
  • Zgłaszanie błędów dotyczących zweryfikowanych luk w zabezpieczeniach
  • Identyfikowanie właścicieli w celu naprawienia błędów
  • Kontaktowanie się z właścicielami w sprawie działań naprawczych

Więcej informacji o tym, jak rozwiązywać problemy związane z bezpieczeństwem, znajdziesz w sekcji Naprawianie błędów w dalszej części tego przewodnika.

Proces weryfikacji zabezpieczeń

Skanowanie pod kątem luk w zabezpieczeniach to doskonały sposób na precyzyjne identyfikowanie problemów z bezpieczeństwem w organizacji, jednak zaimplementowanie procesów sprawdzania zabezpieczeń może w pierwszej kolejności zapobiec wprowadzeniu luk w zabezpieczeniach. W tym przewodniku termin kontrola zabezpieczeń odnosi się do sytuacji, w przypadku których członkowie zespołu ds. bezpieczeństwa wykonują ręczną weryfikację. Zwykle obejmuje to autoryzację do zablokowania zmiany, jeśli zostanie ona uznana za zbyt ryzykowną. Jeśli Twój zespół ds. zabezpieczeń nie jest w stanie blokować ryzykownych zmian, warto mieć do dyspozycji odpowiednie procesy do udokumentowania tego ryzyka. Dzięki temu zyskasz pewność, że osoba, która domaga się zmiany, zdaje sobie sprawę z związanego z nią ryzyka i aktywnie ją akceptuje.

Kryteria weryfikacji zabezpieczeń

Kiedy powinno się odbywać sprawdzanie zabezpieczeń? Utworzenie zestawu kryteriów uruchamiających kontrolę zabezpieczeń pomaga zapewnić, że wszyscy znajdują się na tej samej stronie. Poniżej znajdziesz kilka przykładów scenariuszy, w których może pojawić się weryfikacja bezpieczeństwa.

• Zaproponowano nowe funkcje związane z poufnymi danymi użytkowników
  • Nowa funkcja, która umożliwia użytkownikom udostępnianie swojej lokalizacji na mapie
  • Żądanie od użytkowników potencjalnie poufnych informacji, takich jak adres domowy, data urodzenia czy numer telefonu
• Wprowadzono istotne aktualizacje istniejących funkcji
  • udostępnianie istniejących danych i korzystanie z nich w nowy sposób, którego użytkownicy mogą nie spodziewać się, bez możliwości rezygnacji;
  • Zmiany w funkcjach dotyczących uwierzytelniania, autoryzacji i zarządzania sesją
• Zmiany w środowisku produkcyjnym firmy
  • Zmiany w konfiguracji sieci, zwłaszcza takie, które mogą skutkować ujawnieniem usług
  • Instalacja nowego oprogramowania, które postępuje z poufnymi danymi użytkownika, a w przypadku naruszenia zabezpieczeń
  • Udostępnianie nowych systemów lub usług
• Współpraca z nowym dostawcą lub zmiana sposobu współpracy z obecnym dostawcą.
  • wprowadzenie nowego dostawcy, który będzie obsługiwał poufne dane użytkownika.
  • Zmiany w sposobie współpracy z dostawcą, który skutkuje obsługą poufnych danych użytkownika

Ta lista nie jest wyczerpująca, ale powinna Cię zainteresować, jakiego rodzaju zmiany wymagają sprawdzenia przez zespół ds. bezpieczeństwa. Po zdefiniowaniu kryteriów tego, co wymaga, a co nie wymaga kontroli bezpieczeństwa, porozmawiaj z kluczowymi osobami w organizacji na temat:

• Zainteresowane osoby mogą zapoznać się z kryteriami i wyrazić swoją opinię na ich temat
• Zainteresowane osoby zgadzają się z kryteriami
• Zainteresowane osoby zgadzają się na aktywne proś o sprawdzenie zabezpieczeń

Dokumentuj te kryteria oraz dowiedz się, jak poprosić o sprawdzenie zabezpieczeń (np. zgłosić błąd w kolejce monitorowanej przez zespół ds. zabezpieczeń), aby ułatwić Twojej organizacji proces weryfikacji.

Ponowne udostępnianie kontroli bezpieczeństwa

W przeciwieństwie do skanowania automatycznego sprawdzanie zabezpieczeń może być bardziej pracochłonne. Każdy zespół ds. bezpieczeństwa ma tylko tyle czasu w ciągu dnia, aby wykonać mnóstwo zadań, więc musisz oszacować, ile z nich możesz wygenerować na podstawie swoich kryteriów. Jeśli stwierdzisz, że Twój zespół jest przytłoczony, niepotrzebnie czeka na uruchomienie jego funkcji. Może to spowodować zmianę kulturową organizacji, przez co zespół ds. bezpieczeństwa jest postrzegany jako partner blokujący, a nie partner. Jeśli proces weryfikacji bezpieczeństwa nie jest skuteczny, wiele osób i zespołów spróbuje całkowicie go pominąć. Jeśli zasoby są ograniczone, zastanów się nad zwolnieniem kryteriów wymaganych do przeprowadzenia oceny bezpieczeństwa oraz akceptacji innych zmian. Jeśli incydenty zdarzają się ze względu na brak zasobów do sprawdzenia bezpieczeństwa, uzasadni to potrzebę dodatkowych zasobów bezpieczeństwa.

Przeprowadzanie kontroli bezpieczeństwa

Jeśli chcesz zdecydować, które testy bezpieczeństwa chcesz przeprowadzić, i jak je przeprowadzić, musisz mieć priorytetową kolejkę. Utwórz zintegrowany sposób, w jaki inne osoby w organizacji będą mogły prosić o sprawdzenie zabezpieczeń, podając wszelkie informacje potrzebne do odpowiedniego potraktowania go priorytetowo. Weźmy na przykład kwestionariusz zawierający elementy, takie jak charakter zmiany, w tym krótkie podsumowanie i typ danych, których może ona dotyczyć. Na podstawie odpowiedzi na te pytania możesz automatycznie kategoryzować potencjalne oceny bezpieczeństwa jako zmiany o wysokim, średnim lub małym ryzyku. Jeśli zmiana wiąże się z dużym ryzykiem, możesz potrzebować bardziej szczegółowego procesu sprawdzania bezpieczeństwa. Jeśli zmiana wiąże się z niższym ryzykiem, możesz spróbować wdrożyć prostszy proces weryfikacji zabezpieczeń, który zmniejszy liczbę wymaganych zasobów i przyspieszy cały proces. Rozważ ustawienie rotacji członków zespołu, która będzie odpowiadać za zarządzanie kolejką kontroli bezpieczeństwa, sprawdzanie, czy członkowie zespołu odbierają nowe kontrole bezpieczeństwa i monitorowanie postępów w zakresie istniejących weryfikacji. Rzeczywisty proces sprawdzania zabezpieczeń różni się w zależności od tego, co jest sprawdzane. Na przykład nowa funkcja w Twojej aplikacji mobilnej może wymagać od inżynierów zajmujących się bezpieczeństwem sprawdzania kodu pod kątem potencjalnych luk w zabezpieczeniach. Konieczne może być sprawdzenie, czy nowe oprogramowanie jest odpowiednio skonfigurowane. Współpraca z zewnętrznymi dostawcami może przebiegać zupełnie inaczej. Więcej informacji znajdziesz w kwestionariuszu Google do oceny zabezpieczeń.

Naprawianie błędów

Znajdowanie błędów jest ważne, ale poprawia się dopiero po ich naprawieniu. Znajomość potencjalnych zagrożeń w organizacji jest poważna, ale lepiej jest radzić sobie z nim.

Zarządzanie lukami w zabezpieczeniach

Luki w zabezpieczeniach pochodzą z różnych zasobów, w tym z wewnętrznych działań (np. zeskanowania urządzeń pod kątem luk w zabezpieczeniach i kontroli bezpieczeństwa), testów i kontroli penetracji przeprowadzanych przez zewnętrzne firmy analityczne, a nawet zewnętrznych badaczy bezpieczeństwa, którzy powiadamiają Cię za pomocą kanałów pomocy przed oficjalną premierą VDP. Twoja organizacja musi mieć możliwość skategoryzowania nowych i istniejących luk w zabezpieczeniach, aby mieć pewność, że zostaną one odpowiednio zakomunikowane odpowiednim osobom, które zostaną potraktowane priorytetowo i na czas. Gdy uruchomisz VDP, otrzymasz nowy strumień luk w zabezpieczeniach wchodzących w procesy zarządzania lukami w zabezpieczeniach. Zastosowanie solidnych procesów obsługi tych luk umożliwia śledzenie postępów w kontekście działań naprawczych i reagowanie na żądania pochodzące od zewnętrznych badaczy bezpieczeństwa. Dzięki temu możesz ustalić priorytety luk w zabezpieczeniach i komunikować się z uczestnikami VDP w sprawie harmonogramu działań naprawczych, co zaowocuje większym zaangażowaniem ze strony społeczności badaczy bezpieczeństwa, a także podnosi reputację bezpieczeństwa organizacji. Poniżej opisujemy różne aspekty programu zarządzania lukami w zabezpieczeniach, które warto wdrożyć przed uruchomieniem VDP.

Określ standardy ważności i harmonogramy działań naprawczych

Utworzenie wspólnego języka na temat wagi luk w zabezpieczeniach i idealnych ram czasowych działań naprawczych związanych z każdym poziomem ważności ułatwia określenie standardowych oczekiwań względem organizacji. Jeśli każda luka w zabezpieczeniach zostanie potraktowana jako sytuacja alarmowa, organizacja wyczerpie zasoby i rozrosnie się w stosunku do zespołu ds. bezpieczeństwa. Jeśli każda luka w zabezpieczeniach jest uznawana za niską, nie zostaną one usunięte, a ryzyko włamania się wzrośnie. Każda organizacja ma ograniczone zasoby, więc należy określić jej wagę. Ten ranking określa kryteria, które pomogą Twojej organizacji ocenić stopień ważności luki, oraz oczekiwane terminy rozwiązywania problemów związane z każdym poziomem ważności. Przygotuj zestaw wytycznych dotyczących wagi i udostępnij go zainteresowanym osobom w organizacji, aby uzyskać opinię. Na przykład programiści, którzy zajmują się opracowywaniem standardów ważności, prawdopodobnie stworzą odpowiednie standardy i będą je przestrzegać, gdy będzie trzeba naprawić luki w zabezpieczeniach w określonym terminie. Wskazówki te mogą się różnić w zależności od zagrożeń dla Twojej firmy. Możesz utworzyć ćwiczenie modelowania zagrożeń, aby zastanowić się, jakie zagrożenia są największe i najbardziej istotne dla Twojej organizacji, oraz podać przykłady problemów należących do każdej kategorii ważności. Poniżej znajdziesz przykłady standardów i czasów rozwiązywania problemów dla organizacji finansowej.

Poziom ważności	Opis	Harmonogram działań naprawczych	Przykłady
Krytyczne	Problemy, które mogą stanowić bezpośrednie zagrożenie dla naszych użytkowników lub naszej firmy.	Właściciel: główny właściciel, który chce usunąć lukę w zabezpieczeniach, powinien zostać zidentyfikowany w ciągu 8 godzin. w razie potrzeby poza standardowymi godzinami pracy. Rozwiązanie: sam problem powinien zostać rozwiązany albo przynajmniej zminimalizować ryzyko w najkrótszym możliwym czasie albo w ciągu maksymalnie 3 dni roboczych.	przejęcie produkcyjnej bazy danych, w tym dokumentacji finansowej wszystkich użytkowników; Osoba przeprowadzająca atak uzyskuje dostęp do tajemnic handlowych, takich jak nasze zastrzeżone algorytmy inwestycyjne. Aktywny incydent, w tym intruz mający dostęp do naszych wewnętrznych sieci lub poufnych systemów produkcyjnych.
Wysoki	Problemy, które, jeśli zostały wykorzystane, mogą spowodować znaczne szkody.	Właściciel: główny właściciel powinien zostać zidentyfikowany w ciągu 1 dnia roboczego. Rozwiązanie: w ciągu 10 dni roboczych (ok. 2 tygodni).	Luki w zabezpieczeniach, które mogą skutkować dostępem do poufnych danych użytkownika lub jego funkcjonalności (np. możliwość przejęcia przez kogoś pieniędzy).
Medium	Problemy, które są trudne w użyciu lub nie prowadzą do bezpośrednich obrażeń.	Właściciel: główny właściciel powinien zostać zidentyfikowany w ciągu 5 dni roboczych. Rozwiązanie: w ciągu 20–40 dni roboczych (około 1–2 miesięcy).	Zweryfikowane problemy wykryte przez automatyczne skanery, takie jak poprawki aktualizacji zabezpieczeń bez znanych luk w zabezpieczeniach. Problemy z ujawnianiem informacji, które mogą pomóc w dalszym atakowaniu. Problemy z ograniczeniem liczby potencjalnych zagrożeń (np. ciągłe odgadywanie haseł przez użytkowników).
Niska	Problemy o minimalnym wpływie; używane głównie do logowania znanych problemów.	Nie ma wymagań dotyczących znalezienia właściciela ani naprawy w określonym przedziale czasu.	Ujawnianie informacji, które nie niesie ze sobą ryzyka, ale które nie musi być dostępne z zewnątrz.

Błędy w pielęgnacji

Nie mówimy tu o strzyżeniu. Chcemy poprawić błędy, żeby można było je łatwo naprawić. Korzystając z poprzedniej tabeli jako odniesienia, ustal własne definicje wagi. Te definicje służą do klasyfikowania błędów na różnych poziomach i przekazywania ich właścicielom.

Oprócz przypisywania wagi każdej luki w zabezpieczeniach musisz użyć standardowego formatu, który ułatwi przetwarzanie zespołów. Luki w zabezpieczeniach pojawiają się w ramach procesów zarządzania lukami w zabezpieczeniach w różnych formatach (np. wyników automatycznego skanera lub ręcznego zapisywania ze sprawdzania zabezpieczeń). Poświęcenie czasu na przekonwertowanie każdej luki w zabezpieczeniach na standardowy format zwiększy ryzyko, że zespół odbierający będzie mógł szybko zrozumieć i rozwiązać ten problem.

Ten format lub szablon może się różnić w zależności od organizacji i jakie informacje są najbardziej przydatne dla właścicieli w celu usunięcia błędów. Poniżej znajdziesz przykładowy szablon. Możesz użyć tego szablonu później, gdy będziesz tworzyć formularz przesyłania informacji o lukach w zabezpieczeniach dla badaczy.

Tytuł: <jeden wiersz opisu problemu, zwykle typ luki w zabezpieczeniach i rodzaj zasobu/usługi itp.; (opcjonalnie) określ wagę lub zmapuj wagę na pole w narzędziu do śledzenia błędów> Podsumowanie: <krótki opis luki w zabezpieczeniach i jej znaczenie> tutaj, o której tutaj warto przeczytać w tym przypadku

Oto przykład potencjalnej luki w zabezpieczeniach o dużej wadze:

Tytuł: [HIGH] Bezpośrednie odwołanie do niezabezpieczonego obiektu (IDOR) na stronach profilu Podsumowanie: funkcja IDOR została wykryta w funkcjach strony profilu naszej aplikacji, która umożliwia każdemu użytkownikowi uzyskanie nieautoryzowanego dostępu do wyświetlania i edytowania profilu innego użytkownika, w tym imienia i nazwiska, adresu domowego, numeru telefonu i daty urodzenia. Sprawdziliśmy logi i wygląda na to, że problem nie został jeszcze wykorzystany. Ten problem został wykryty wewnętrznie. Kroki odtworzenia:

1. Skonfiguruj serwer proxy, na przykład Burp Suite, aby przechwytywać ruch na urządzeniu mobilnym z zainstalowaną aplikacją.
2. Wejdź na stronę swojego profilu i przechwyć powiązane żądanie HTTP.
3. Zmodyfikuj profileID=###### na profileID=000000 (to użytkownik testowy) i wyślij go razem z żądaniem HTTP.
4. Aplikacja wyświetli profil użytkownika 000000, a Ty będziesz mieć możliwość wyświetlania i edytowania jego informacji.

Scenariusz / wpływ: każdy użytkownik może użyć tej luki w zabezpieczeniach, aby wyświetlić i edytować profil innego użytkownika. W najgorszym przypadku atakujący może zautomatyzować proces pobierania informacji o profilach wszystkich użytkowników w naszym systemie. Uważamy, że nie jest to jeszcze możliwe, jednak ważne jest, aby traktować go jako standardowy problem o wysokim poziomie ważności. Jeśli wykryjemy dowody wykorzystania tego wskaźnika, eskalacja będzie miała kluczowe znaczenie. Kroki rozwiązywania problemów: zaimplementuj mechanizmy weryfikacji po stronie serwera, aby mieć pewność, że użytkownik przesyłający prośbę powinien mieć uprawnienia do wyświetlania/edytowania profilu, którego dotyczy żądanie, używając wartości profileID. Jeśli na przykład Alicja jest zalogowana i ma identyfikator profilu 123456, ale Alicja zgłosiła żądanie profilu ID 333444, użytkownik powinien widzieć błąd, a ta próba uzyskania dostępu do profilu innego użytkownika powinna zostać zarejestrowana. Więcej informacji o systemie IDOR i jego naprawieniu znajdziesz w materiałach na temat tego błędu.

Możesz zaoszczędzić czas i pracować ręcznie, znajdując sposoby na automatyzację konwertowania luk w zabezpieczeniach z różnych źródeł na format standardowy. W miarę tworzenia nowych luk w zabezpieczeniach mogą pojawiać się typowe tematy. Oprócz ogólnego szablonu formatu błędu możesz utworzyć dodatkowe szablony dla typowych typów luk w zabezpieczeniach.

Szukam właścicieli

Jednym z najtrudniejszych aspektów zarządzania lukami w zabezpieczeniach jest identyfikowanie właścicieli w celu ich naprawiania oraz zachęcanie użytkowników do kupna zasobów w celu ich naprawienia w ramach harmonogramu. Jeśli masz skonfigurowane procesy zarządzania zasobami, będzie to trochę prostsze. Jeśli nie, to może to być motywacja. W zależności od wielkości organizacji znalezienie właściciela może być dość proste lub niezwykle skomplikowane. W miarę rozwoju Twojej organizacji rośnie też wysiłek, aby określić, kto jest odpowiedzialny za rozwiązywanie nowo wykrytych problemów z zabezpieczeniami. Rozważ wdrożenie rotacji czynnej. Każdy, kto pracuje, jest odpowiedzialny za sprawdzanie nieprzypisanych luk w zabezpieczeniach, śledzenie właścicieli i ustalanie priorytetów na podstawie ich wagi. Nawet jeśli jesteś w stanie określić, kto jest odpowiedzialny za naprawienie luki w zabezpieczeniach i przypisać ją do błędu, musisz też przekonać tę osobę, żeby zainwestowała czas w jej usunięcie. Różni się ona w zależności od zespołu lub osoby, nad którą pracuje, Gdy już osiągniesz standardowy poziom ważności i czas realizacji działań naprawczych, możesz się z nimi zapoznać, ale czasem może być konieczne skierowanie swojej decyzji do rozwiązania błędu. Oto kilka ogólnych wskazówek dotyczących naprawiania luk w zabezpieczeniach:

• Wyjaśnij: kiedy ktoś otrzymuje lukę w zabezpieczeniach, którą chce usunąć, zwykle jest to nieoczekiwana praca. Wyjaśnij, dlaczego ten problem jest ważny, aby szybko rozwiązać problem (np. wpływ lub scenariusz ataku), i upewnij się, że właściciel go rozumie.
• Gromadzenie kontekstu: w niektórych przypadkach tylko jedna osoba ma wiedzę potrzebną do naprawienia błędu i może wykonywać inne zadania, nad którymi pracuje. Poświęć chwilę, aby je poznać. Możliwe, że w najbliższym czasie inne zadania mogą być ważniejsze niż usunięcie tej luki w zabezpieczeniach. Okazywanie empatii i elastyczności w zakresie działań naprawczych pomoże Ci zyskać szacunek i wzmocnić relacje z klientami, którym musisz naprawić luki w zabezpieczeniach. Pamiętaj tylko, aby nie pozostawiać zbyt wiele nadzoru, bo inaczej Twoja organizacja nie będzie traktować ram czasowych działań naprawczych poważnie.
• Wyjaśnij: nawet jeśli uwzględnisz w błędzie porady dotyczące rozwiązywania problemów, właściciel może poczuć się zagubiony lub potrzebować pomocy w naprawieniu błędu. Jeśli dziecko potrzebuje pomocy w znalezieniu rozwiązania problemu, możesz je wyjaśnić. Samo zgłaszanie błędów bez zgody może negatywnie wpłynąć na relacje organizacji z zespołem ds. bezpieczeństwa. Maksymalne pomaganie innym w rozwiązaniu problemów związanych z obecnymi i przyszłymi lukami w zabezpieczeniach oraz pomoc w nauczaniu innych.
• Dostosowywanie żądania: różne zespoły i osoby mogą mieć procedury, w których przyjmują i ustalają priorytety nadchodzących próśb o pracę. Niektóre zespoły mogą chcieć, aby wszystkie przychodzące prośby pochodziły od ich menedżerów. Inni użytkownicy zgłaszają prośby o pomoc w standardowym formacie. Niektóre działają tylko w przypadku haseł określonych w sprintie. Niezależnie od tego, ile czasu potrzebujesz, aby dostosować go do formatu, w jakim zwykle zespół lub inna osoba prosi o pomoc, zwiększy prawdopodobieństwo priorytetowego traktowania Twojej prośby i podjęcia działań.
• Przekaż sprawę w ostateczności: jeśli znasz wszystkie powyższe rozwiązania, a osoba lub zespół odpowiedzialny za naprawę luki w zabezpieczeniach nie poświęca czasu na naprawienie poważnego problemu z zabezpieczeniami, rozważ eskalację do kierownictwa. W ostateczności zawsze warto ucierpieć, ponieważ może to zaszkodzić Twoim relacjom z wybraną osobą lub zespołem.

Analiza przyczyn źródłowych

Oprócz wyszukiwania i naprawiania poszczególnych luk w zabezpieczeniach – analiza głównej przyczyny (RCA) może pomóc w wykrywaniu i rozwiązywaniu problemów systemowych dotyczących zabezpieczeń. Każdy ma ograniczone zasoby, dlatego pokusa można pominąć ten krok. Warto jednak poświęcić więcej czasu na analizę trendów związanych z tymi lukami w zabezpieczeniach, a także na analizowanie krytycznych i poważnych błędów, co w dłuższej perspektywie może przynieść mniejsze ryzyko i ryzyko. Załóżmy na przykład, że w aplikacji nieustannie pojawia się ten sam typ luk w zabezpieczeniach (np. przekierowanie intencji). Postanawiasz rozmawiać z zespołami, które wprowadzają tę lukę w zabezpieczeniach, i rozumiesz, że większość z nich nie rozumie, czym jest przekierowanie, dlaczego jest ważne lub jak mu zapobiec. Na początek przygotujesz prezentację i przewodnik, które ułatwią zapoznanie się z tą funkcją dla deweloperów w Twojej organizacji. Taka luka w zabezpieczeniach najprawdopodobniej nie zniknie, ale częstotliwość, z jaką się ona pojawia, prawdopodobnie zmaleje. Gdy uruchamiasz VDP, wszystkie luki w zabezpieczeniach zgłaszane przez osoby trzecie są elementami, które umknęły Twojej obecnej procedurze bezpieczeństwa. Przeprowadzanie RCA na podstawie błędów z VDP zapewnia jeszcze więcej informacji o tym, jak systematycznie ulepszać program bezpieczeństwa.

Wykrywanie i reagowanie

Wykrywanie i reagowanie to wszelkie narzędzia i procesy, których używasz do wykrywania potencjalnych ataków i reagowania na nie w swojej organizacji. Mogą one pochodzić z kupionych lub samodzielnie opracowanych rozwiązań, które analizują dane pod kątem podejrzanego zachowania. Przykład: w sekcji Błędy w aplikacji Grooming opisaliśmy logowanie się za każdym razem, gdy użytkownik próbuje uzyskać nieautoryzowany dostęp do profilu innego użytkownika. Jeśli zauważysz, że w krótkim czasie użytkownik uzyskuje dużą liczbę nieudanych prób dostępu do profili innych użytkowników, może się pojawić sygnał lub alert. Możesz nawet zautomatyzować proces blokowania temu użytkownikowi dostępu do jakichkolwiek usług na określony czas lub na czas nieokreślony, dopóki sytuacja nie zostanie sprawdzona i odzyskana ręcznie. Jeśli nie masz jeszcze wdrożonych mechanizmów wykrywania i reagowania, zastanów się nad skonsultowaniem się z ekspertem, który pomoże Ci utworzyć program analizy kryminalistycznej i odpowiedzi na incydenty (DFIR) dla Twojej organizacji. Jeśli dysponujesz mechanizmami wykrywania i reagowania, zastanów się nad konsekwencjami przeprowadzenia testów na 5, 10 lub nawet 100 badaniach bezpieczeństwa na platformach ataku internetowego. Może to mieć duży wpływ na używane przez Ciebie systemy identyfikacji i zapobiegania włamaniom (IDS/IPS).

Potencjalne zagrożenia to:

• Przeciążenie alertów: seria alertów lub sygnałów, które wyglądają jak złośliwe ataki, ale są normalnym, zatwierdzonym przez badaczy bezpieczeństwa uczestniczącym w Twojej platformie VDP. Wygenerowanych jest tyle szumów, że trudno jest odróżnić prawdziwe ataki od prawdziwych testów bezpieczeństwa.
• Fałszywe alarmy w odpowiedzi na incydenty: jeśli w sobotę masz na stronie procesy o 2:00 w nocy, nie będą oni mogli przebudzić i zbadać potencjalne naruszenie, które faktycznie było prowadzone przez wiarygodnego badacza.
• Blokowanie badaczy bezpieczeństwa: jeśli korzystasz z agresywnego systemu IPS (systemów zapobiegania włamaniom), może się okazać, że zablokujesz adres IP badacza zabezpieczeń, który próbuje skanować, przeprowadzać ręczne testy itp., aby zidentyfikować luki w zabezpieczeniach i zgłosić je Tobie. W szczególności w przypadku VDP, jeśli po 5 minutach badania ekspert ds. bezpieczeństwa zablokuje projekt, może stracić zainteresowanie i skoncentrować się na programie innej organizacji. Może to dostrzec ogólny brak zaangażowania w Twój program związany z badaniami bezpieczeństwa, co zwiększa ryzyko wystąpienia nieznanych luk w zabezpieczeniach (a tym samym nieznanych w Twojej organizacji). chociaż możesz zepsuć swój adres IPS, możesz podjąć inne działania w celu zmniejszenia ryzyka zniechęcenia badaczy.

Sposób, w jaki należy postępować w przypadku tych zagrożeń, zależy głównie od podejścia do współpracy z zewnętrznymi badaczami bezpieczeństwa. Jeśli potrzebujesz bardziejczarnego pudełka, który symuluje rzeczywiste ataki, nic nie musisz robić. W takim przypadku ruch generowany przez badacza będzie generować alerty, a Twój zespół może podjąć działania w celu zbadania sprawy i podjęcia odpowiednich działań. Pomoże to Twojemu zespołowi przećwiczyć reagowanie na typowe ataki, ale może zmniejszyć zaangażowanie badaczy bezpieczeństwa, zwłaszcza tych, którzy mają zablokowane testowanie. Może to również spowodować brak prawdziwego ataku podczas poświęcania czasu na badanie uzasadnionych testów. Jeśli chcesz zastosować bardziej szare pudełko, możesz nawiązać współpracę z ekspertami ds. bezpieczeństwa, aby samodzielnie zidentyfikować ruch związany z testowaniem. Dzięki temu możesz dodać ruch do białej listy oraz odfiltrować ruch z wyników testów i wygenerowanych alertów. Twój zespół będzie w stanie lepiej odróżniać prawdziwe ataki od zatwierdzonych testów, a badacze zyskają możliwość wykrywania i zgłaszania luk w zabezpieczeniach bez naruszania Twoich systemów zapobiegania włamaniom. Niektóre organizacje proszą badaczy bezpieczeństwa o przesłanie formularza zgłoszeniowego mającego unikalny identyfikator, który można dołączać do nagłówków w żądaniach generowanych przez badacza. Dzięki temu organizacja może umieścić ruch na tej liście na potrzeby białej listy, a także ustalić, czy badacz chce wyjść poza uzgodniony zakres testów. Jeśli tak się stanie, skontaktuj się z badaczem i poproś, by wstrzymał się do czasu, aż wspólnie przygotujesz plan testów.