Przygotowanie

W tej sekcji omówimy szczegółowo, jak przygotować organizację do uruchomienia i przeprowadzenia skutecznego programu ujawniania luk w zabezpieczeniach, w tym praktyczne porady dotyczące wypełniania wykrytych luk.

Znajdowanie błędów

Wzbogacenie obecnego programu o bezpieczeństwo przy pomocy zewnętrznych badaczy zabezpieczeń to świetny sposób na wykrywanie złożonych problemów i ukrywanie luk w zabezpieczeniach. Jednak używanie VDP do wykrywania podstawowych problemów z bezpieczeństwem, które można wykryć wewnętrznie, to strata zasobów.

Zarządzanie komponentami

Poszukiwanie błędów wymaga jedynie dobrego pojęcia o nich. Możesz kupić nawet sto narzędzi zabezpieczających, ale nic się nie stanie, jeśli zespoły bez Twojej wiedzy będą bez Twojej wiedzy tworzyć własne aplikacje, systemy i usługi. Jest to ważne zwłaszcza wtedy, gdy nie masz możliwości wykrycia i przeprowadzenia oceny zabezpieczeń tych zasobów. Skontaktuj się z osobami i zespołami, które pomagają w tworzeniu nowych aplikacji, systemów i usług, aby dowiedzieć się, czy mają odpowiedni proces tworzenia i utrzymywania magazynów informacji, które się rozbijają i kto jest ich właścicielem. Jeśli obecnie nie ma innego procesu, jest to świetna okazja, by wspólnie z tymi zespołami opracować własny. Na początek zapoznaj się z zasobami organizacji. W ramach tego procesu zespół ds. bezpieczeństwa powinien być zaangażowany w opracowywanie nowej infrastruktury, aby zapewnić weryfikacje bezpieczeństwa. Dobrą praktyką jest posiadanie rozbudowanego spisu zasobów i właścicieli. Ten rodzaj zasobów reklamowych jest przydatny przy wprowadzaniu nowych poprawek, które wymagają tymczasowego wyłączenia niektórych systemów. Stanowi też plan działania osób lub zespołów, które muszą otrzymać informacje, i wskazują, których systemów to dotyczy. Odpowiedni proces zarządzania zasobami sprawia, że właściciele są identyfikowani na wcześniejszym etapie procesu, są regularnie aktualizowany, a wszystkie systemy w organizacji działają zgodnie z zamierzeniami.

Oprócz proaktywnego zarządzania zasobami zastanów się, jakie działania reaktywne możesz zastosować, jak również w celu identyfikacji zasobów należących do organizacji, które zostały jednak pominięte przez ustandaryzowane procesy zarządzania zasobami. Może to obejmować korzystanie z tych samych procesów „wykrywania błędów”, które są stosowane przez badaczy bezpieczeństwa, którzy uczestniczą w programach VDP i programach wykrywania błędów. Możesz na przykład skorzystać z bezpłatnych narzędzi open source, które skanują i wyliczają dostępne w internecie zakresy adresów IP lub domeny, które mogą należeć do Twojej organizacji. Po wpisaniu w wyszukiwarce Google hasła bugy bounty recon wyświetli się szereg wskazówek i wskazówek, które pomogą Ci znaleźć zasoby organizacji, o których nie wiesz.

Podstawowe skanowanie pod kątem luk w zabezpieczeniach

Teraz, gdy wiesz już, gdzie musisz szukać problemów z bezpieczeństwem, przyjrzyjmy się temu, jak to działa. Jest wiele poziomów wiedzy, które możesz zagłębić w zależności od zasobów organizacji, ale musisz znaleźć równowagę między wewnętrznymi działaniami w zakresie bezpieczeństwa a zewnętrzną społecznością hakerów. Ta równowaga jest inna dla każdej organizacji w zależności od dostępnych zasobów.

Wybierz narzędzia

Istnieje wiele różnych narzędzi, które pomagają w wykrywaniu luk w zabezpieczeniach. Niektóre narzędzia do skanowania pod kątem luk w zabezpieczeniach są dostępne bezpłatnie, a inne – płatne. To, które narzędzia należy wybrać, zależy od indywidualnych potrzeb.

• Wymagania Twojej organizacji
• Jak dane narzędzie spełnia te wymagania
• Czy korzyści z używania tego narzędzia przewyższają koszty (finansowe i wdrożeniowe).

Możesz użyć tego szablonu wymagań (OpenDocument .ods, Microsoft Excel .xlsx), aby ocenić różne narzędzia pod kątem Twoich wymagań. Szablon zawiera przykładowe wymagania, ale musisz je omówić z zespołami ds. bezpieczeństwa, IT i zespołu inżynierów, aby dostosować wymagane funkcje. Przed uruchomieniem programu ujawniania luk w zabezpieczeniach musisz mieć możliwość przeprowadzania skanowania pod kątem luk w zabezpieczeniach wszelkich zasobów zewnętrznych (takich jak witryny, interfejsy API czy aplikacje mobilne). Pomoże Ci to znajdować i naprawiać łatwo wykrywalne luki w zabezpieczeniach, zanim zaprosisz zewnętrznych badaczy ds. bezpieczeństwa do testowania tych zasobów i usług.

Konfiguracja skanowania

Automatyczne skanowanie pod kątem luk w zabezpieczeniach pozwala wykryć wiele problemów, ale może też prowadzić do fałszywych trafień. Dlatego niezbędne są zasoby umożliwiające weryfikowanie wyników przed udostępnieniem ich zespołom, których dotyczy ten problem. Aby mieć pewność, że skanowanie będzie wykonywane regularnie, a wyniki tych skanowań będą faktycznie zamierzone, musisz wdrożyć procesy. Będzie to wyglądać inaczej w każdej organizacji, ale przynajmniej należy określić:

• Częstotliwość skanowania
  • Ciągła
  • Co tydzień
  • Co miesiąc
• Które zasoby są skanowane
• Dane logowania
  • Skanowanie uwierzytelnione i nieuwierzytelnione
  • (wskazówka: jeśli nie skanujesz danych logowania, a badacz ds. bezpieczeństwa testuje je przy uruchamianiu VDP, możesz zauważyć znaczny wzrost liczby wykrytych luk w zabezpieczeniach).
• Role i obowiązki
  • Zidentyfikuj członków zespołu odpowiedzialnych za skanowanie
  • W razie potrzeby ustaw rotację
• Wyniki skanowania
  • Weryfikowanie wyników skanowania
  • Zgłaszanie błędów związanych ze zweryfikowanymi lukami w zabezpieczeniach
  • Identyfikacja właścicieli, do których należy naprawić błędy
  • Kontakt z właścicielami w sprawie działań naprawczych

Sposób rozwiązywania wykrytych problemów z bezpieczeństwem omówimy bardziej szczegółowo w sekcji Usuwanie błędów w dalszej części tego przewodnika.

Proces kontroli bezpieczeństwa

Skanowanie pod kątem luk w zabezpieczeniach jest świetnym sposobem na reaktywne wykrywanie problemów z bezpieczeństwem w organizacji, ale wdrożenie procesów kontroli bezpieczeństwa może przede wszystkim zapobiec ujawnieniu luk w zabezpieczeniach. W tym przewodniku termin kontrola zabezpieczeń odnosi się do każdej sytuacji, w której użytkownik z zespołu ds. bezpieczeństwa musi ręcznie sprawdzić witrynę. Zwykle obejmuje to posiadanie uprawnień do blokowania zmiany, jeśli jest ona uznana za zbyt ryzykowną. Jeśli zespół ds. zabezpieczeń nie może blokować ryzykownych zmian, warto wdrożyć procedury pozwalające dokumentować ryzyko. Dzięki temu osoba, która domaga się zmian, będzie znać związane z nim ryzyko i aktywnie je zaakceptować.

Kryteria kontroli bezpieczeństwa

Kiedy należy przeprowadzać kontrole bezpieczeństwa? Stworzenie zestawu kryteriów, które uruchamiają kontrolę bezpieczeństwa, pomaga mieć pewność, że wszyscy są na bieżąco. Poniżej znajdziesz kilka przykładów sytuacji, które mogą aktywować kontrolę bezpieczeństwa.

• Planujemy nową funkcję związaną z poufnymi danymi użytkownika
  • Nowa funkcja umożliwiająca użytkownikom udostępnianie swojej lokalizacji na mapie
  • Żądanie od użytkowników prośby o podanie potencjalnie poufnych informacji, takich jak adres domowy, data urodzenia czy numer telefonu
• Dokonano poważnych aktualizacji istniejących funkcji
  • Przejęcie istniejących danych użytkowników i wykorzystanie ich w nowy sposób, którym użytkownicy mogą się nie spodziewać, bez możliwości rezygnacji
  • zmian dotyczących funkcji związanych z uwierzytelnianiem, autoryzacją i zarządzaniem sesjami.
• Zmiany w środowisku produkcyjnym firmy
  • zmiany w konfiguracji sieci, w szczególności takie, które mogą powodować udostępnianie usług poza organizację.
  • Instalacja nowego oprogramowania do obsługi poufnych danych użytkownika, które w razie przejęcia może posłużyć pośrednio do uzyskania dostępu do tych danych.
  • Promowanie nowych systemów lub usług
• Interakcja z nowym dostawcą lub zmiana sposobu współpracy z dotychczasowym
  • wprowadzenie nowego dostawcy, który będzie zajmować się poufnymi danymi użytkowników.
  • zmiany sposobu współpracy z dotychczasowym dostawcą, które skutkują obsługą poufnych danych użytkowników przez dostawcę.

Ta lista nie jest wyczerpująca, ale powinna pomóc Ci zastanowić się, jakie zmiany wymagają kontroli bezpieczeństwa. Gdy określisz kryteria określające, co wymaga kontroli bezpieczeństwa, a co jej nie wymaga, ustal to z najważniejszymi osobami w organizacji, aby upewnić się, że:

• Zainteresowane osoby mają możliwość sprawdzenia kryteriach i przesłania opinii na ich temat
• Zainteresowane osoby zgadzają się na kryteria
• Interesujące osoby zgadzają się na aktywne zgłaszanie próśb o kontrolę bezpieczeństwa

Udokumentuj te kryteria oraz sposób zgłaszania prośby o kontrolę bezpieczeństwa (np. przesyłając błąd do kolejki monitorowanej przez zespół ds. bezpieczeństwa), aby jak najbardziej ułatwić Twojej organizacji przeprowadzenie tego procesu.

Materiały dotyczące kontroli bezpieczeństwa

W przeciwieństwie do skanowania automatycznego kontrole zabezpieczeń mogą wymagać więcej zasobów. Każdy zespół ds. bezpieczeństwa ma w ciągu dnia tyle czasu, by wykonać mnóstwo zadań. Musisz więc oszacować, ile kontroli bezpieczeństwa może wygenerować na podstawie Twoich kryteriów. Jeśli czujesz, że Twój zespół jest przytłoczony i ma problemy z jego funkcjonowaniem, to osoby czekające na wprowadzenie nowych funkcji będą niezadowolone z pomocy zespołu ds. bezpieczeństwa. Może to spowodować zmiany kulturowe w organizacji, w wyniku czego zespół ds. bezpieczeństwa będzie postrzegany jako osobę blokującą, a nie partnera. Jeśli proces weryfikacji bezpieczeństwa nie jest efektywny, wiele osób i zespołów będzie próbowało go całkowicie obejść. Jeśli masz ograniczone zasoby, rozważ zrzeczenie się kryteriów wymagania kontroli bezpieczeństwa i zaakceptuj inne ryzyko resztowe. Jeśli incydenty występują w wyniku braku zasobów do przeprowadzania kontroli zabezpieczeń, uzasadnia to potrzebę dodatkowych zasobów związanych z bezpieczeństwem.

Sprawdzanie zabezpieczeń

Podejmując decyzje o tym, które kontrole zabezpieczeń należy przeprowadzić i jak je przeprowadzić, potrzebna jest priorytetowa kolejka. Utwórz ustandaryzowany sposób przesyłania próśb o kontrolę bezpieczeństwa przez inne osoby w organizacji, podając wszelkie informacje, których potrzebujesz, aby nadać im odpowiedni priorytet. Rozważmy na przykład kwestionariusz zawierający elementy takie jak charakter zmiany, w tym jej krótkie podsumowanie oraz typy danych użytkownika, których ona dotyczy. Na podstawie odpowiedzi na te pytania możesz automatycznie dzielić potencjalne kontrole zabezpieczeń na zmiany o wysokim, średnim i niskim stopniu ryzyka. Jeśli zmiana wiąże się z dużym ryzykiem, może być konieczne przeprowadzenie bardziej szczegółowej kontroli bezpieczeństwa. Jeśli zmiana wiąże się z mniejszym ryzykiem, możesz wdrożyć prostszy proces sprawdzania zabezpieczeń, który pomoże ograniczyć ilość potrzebnych zasobów i przyspieszyć ten proces. Rozważ zaplanowanie rotacji w zespole, aby zarządzać kolejką kontroli bezpieczeństwa, zadbać o to, aby nowe kontrole bezpieczeństwa były przejmowane przez członków zespołu, oraz śledzić postępy istniejących kontroli bezpieczeństwa. Rzeczywisty proces kontroli bezpieczeństwa będzie się różnił w zależności od przedmiotu badania. Na przykład nowa funkcja aplikacji mobilnej może wymagać sprawdzenia przez inżyniera ds. bezpieczeństwa kodu i poszukiwania potencjalnych luk w zabezpieczeniach. Może być konieczne sprawdzenie instalowanego oprogramowania, aby mieć pewność, że kontrola dostępu jest skonfigurowana prawidłowo. To zupełnie inny proces współpracy z dostawcami z zewnątrz. W celu porównania zapoznaj się z opracowanym przez Google kwestionariuszem oceny bezpieczeństwa dostawców.

Naprawianie błędów

Wykrywanie błędów jest ważne, ale bezpieczeństwo poprawia się dopiero po ich naprawieniu. Wiedza o zagrożeniach, jakie stwarza organizacja, jest przydatna, ale możliwość skutecznego radzenia sobie z nim jest jeszcze lepsza.

Zarządzanie lukami w zabezpieczeniach

Luki w zabezpieczeniach pochodzą z różnych źródeł, w tym z działań wewnętrznych (np. skanowania pod kątem luk w zabezpieczeniach i kontroli zabezpieczeń), zewnętrznych testów penetracyjnych i kontroli, a nawet zewnętrznych badaczy zabezpieczeń, którzy powiadamiają użytkowników przez kanały pomocy przed oficjalnym wprowadzeniem VDP. Twoja organizacja potrzebuje sposobu kategoryzowania nowych i istniejących luk w zabezpieczeniach, aby mieć pewność, że zostaną one przekazane odpowiednim zainteresowanym stronom, nadane im priorytety i szybko naprawione. Po uruchomieniu VDP otrzymasz nowy strumień luk w zabezpieczeniach, który zacznie wpływać na procesy zarządzania lukami w zabezpieczeniach. Odpowiednie procedury postępowania z tymi lukami w zabezpieczeniach pomagają śledzić postępy w działaniach naprawczych i reagować na prośby zewnętrznych badaczy zabezpieczeń o aktualizacje. Szybkie określanie priorytetów luk w zabezpieczeniach i informowanie uczestników VDP o harmonogramie działań naprawczych zwiększa zaangażowanie społeczności badaczy zabezpieczeń i poprawia reputację bezpieczeństwa organizacji. W poniższych sekcjach opisano różne aspekty programu zarządzania lukami w zabezpieczeniach, które należy wdrożyć przed uruchomieniem VDP.

Ustal standardy ważności i harmonogram działań naprawczych.

Stworzenie wspólnego języka dotyczącego wagi luk i idealnych harmonogramów działań naprawczych związanych z każdym z nich ułatwia określenie w organizacji standardowych oczekiwań. Jeśli każda luka w zabezpieczeniach zostanie potraktowana jak sytuacja alarmowa, organizacja wyczerpie swoje zasoby i będzie miała poczucie niechęci do zespołu ds. bezpieczeństwa. Jeśli każda luka w zabezpieczeniach zostanie uznana za o niskim priorytecie, luki w zabezpieczeniach nigdy nie zostaną naprawione, a ryzyko naruszenia bezpieczeństwa wzrasta. Każda organizacja ma ograniczone zasoby, dlatego należy określić ranking ważności. Ten ranking zawiera kryteria, które pomagają organizacji zrozumieć stopień ważności luki w zabezpieczeniach i oczekiwane terminy działań naprawczych powiązane z każdym z tych poziomów. Przygotuj wersję roboczą zestawu wytycznych dotyczących wagi i udostępnij go najważniejszym osobom w organizacji do przekazywania opinii. Jeśli na przykład w opracowaniu standardów wagi zajmują się inżynierowie, chętniej się do nich przestrzegają, gdy trzeba usunąć lukę w zabezpieczeniach w określonym czasie. Te wskazówki mogą się różnić w zależności od ryzyka w Twojej firmie. Możesz rozważyć modelowanie zagrożeń, aby określić, jakie zagrożenia są najbardziej prawdopodobne i najskuteczniejsze dla Twojej organizacji, oraz podać przykłady problemów, które należą do poszczególnych kategorii wagi. Poniżej znajdziesz przykłady standardów wagi i harmonogramów działań naprawczych w organizacji finansowej.

Poziom ważności	Opis	Harmonogram działań naprawczych	Przykłady
Krytyczny	Problemy, które stanowią bezpośrednie zagrożenie dla użytkowników lub naszej firmy.	Właściciel: główny właściciel, który pilnuje usunięcia luki w zabezpieczeniach, powinien zostać zidentyfikowany w ciągu 8 godzin. W razie potrzeby możesz korzystać z zasobów do połączeń i stron, nawet poza zwykłymi godzinami pracy. Rozwiązanie: sam problem należy rozwiązać lub ograniczyć ryzyko tak szybko, jak to możliwe, a maksymalnie w ciągu 3 dni roboczych.	Naruszenie bezpieczeństwa produkcyjnej bazy danych obejmującej dane finansowe wszystkich użytkowników. Osoba atakująca uzyskująca dostęp do tajemnic handlowych, takich jak nasze zastrzeżone algorytmy inwestycyjne. Aktywny incydent, w którym osoba przeprowadzająca atak uzyskała dostęp do naszej sieci wewnętrznej lub poufnych systemów produkcyjnych.
Wysoka	Problemy, których wykorzystanie może spowodować poważne szkody.	Właściciel: głównego właściciela należy zidentyfikować w ciągu jednego dnia roboczego. Rozwiązanie: w ciągu 10 dni roboczych (ok. 2 tygodni).	Luki w zabezpieczeniach, które mogą umożliwić dostęp do poufnych danych użytkownika lub funkcji (np. możliwość kradzieży funduszy od innego użytkownika).
Medium	Problemy, które są trudniejsze do wykorzystania lub nie prowadzą do bezpośrednich szkód.	Właściciel: głównego właściciela należy zidentyfikować w ciągu 5 dni roboczych. Rozwiązanie: w ciągu 20–40 dni roboczych (ok. 1–2 miesięcy).	Zweryfikowane problemy zidentyfikowane przez automatyczne skanery, np. poprawki aktualizacji zabezpieczeń bez znanych luk w zabezpieczeniach. Problemy z ujawnianiem informacji, które prawdopodobnie pomogłyby w dalszych atakach. Częstotliwość ograniczania problemów, które mogą zostać wykorzystane (np. ciągłe odgadywanie haseł użytkownika).
Niska	Problemy o minimalnym wpływie; głównie na potrzeby rejestrowania znanych problemów.	Nie ma wymagań dotyczących znalezienia właściciela lub naprawienia problemu w określonym czasie.	Ujawnienie informacji, które nie stwarzają prawdopodobnego ryzyka, ale gdy nie muszą być dostępne z zewnątrz.

Uprawianie owadów

Nie mówimy tu o strzyżeniu, ale o zapewnieniu poprawnego formatu błędów, które można łatwo naprawić. Korzystając z poprzedniej tabeli jako wytycznych, ustal własne definicje wagi. Te definicje służą do klasyfikowania błędów o różnej wadze i przekazywania ich właścicielom.

Oprócz przypisywania poziomu ważności każdej luki w zabezpieczeniach musisz zadbać o to, aby błędy były w standardowym formacie, który ułatwi przetwarzanie danych zespołów. W przypadku luk w zabezpieczeniach procesy zarządzania lukami w zabezpieczeniach będą miały różne formaty (np. wyniki ze skanera automatycznego lub ręczne zapisy na podstawie kontroli bezpieczeństwa). Poświęcenie czasu na przekształcenie każdej luki w zabezpieczeniach na format standardowy zwiększy szanse zespołu odbierającego dane na szybkie zrozumienie i rozwiązanie problemu.

Ten format lub szablon może się różnić w zależności od organizacji i tego, jakie informacje są najbardziej istotne, by pomóc właścicielom w naprawianiu przypisanych do nich błędów. Oto przykładowy szablon, którego możesz użyć. Możesz go użyć później, gdy będziesz tworzyć dla badaczy formularz przesyłania informacji o lukach w zabezpieczeniach.

Tytuł: <jeden wiersz opisu problemu; zwykle rodzaj luki w zabezpieczeniach oraz rodzaj zasobu, usługi lub innego zasobu, którego dotyczy problem; opcjonalnie uwzględnij poziom ważności lub zmapuj go do pola w narzędziu do śledzenia problemów> Podsumowanie: <krótki opis luki w zabezpieczeniach i jej znaczenie> Kroki umożliwiające odtworzenie problemu: <krok po kroku i porada, jak wyeliminować daną lukę w zabezpieczeniach;

Oto przykład potencjalnie dużej luki w zabezpieczeniach:

Title: [HIGH] Niezabezpieczone odwołanie do obiektu bezpośredniego (IDOR) na stronach profilu Podsumowanie: w funkcjach stron profilowych naszej aplikacji wykryto IDOR, które umożliwiałyby uzyskiwanie nieuprawnionego dostępu do wyświetlania i edytowania profilu innego użytkownika. Obejmuje to pełne imię i nazwisko, adres domowy, numer telefonu i datę urodzenia innego użytkownika. Sprawdziliśmy dzienniki i wygląda na to, że problem nie został jeszcze wykorzystany. Ten problem został wykryty wewnętrznie. Etapy odtworzenia:

1. skonfiguruj serwer proxy (np. Burp Suite), aby przechwytywać ruch na urządzeniu mobilnym z zainstalowaną aplikacją.
2. Przejdź na stronę swojego profilu i przechwyć powiązane żądanie HTTP.
3. Zmień profileID=###### na profileID=000000 (to użytkownik testowy) i wyślij żądanie HTTP.
4. W aplikacji wyświetli się profil użytkownika 000000, a Ty będziesz mieć możliwość wyświetlania i edytowania jego informacji.

Scenariusz ataku / wpływ: każdy użytkownik może wykorzystać tę lukę w zabezpieczeniach, aby wyświetlić i edytować profil innego użytkownika. W najgorszym scenariuszu osoba przeprowadzająca atak może zautomatyzować proces pobierania informacji o profilach każdego użytkownika do całego naszego systemu. Choć naszym zdaniem nie zostały one jeszcze wykorzystane, musimy traktować to jako standardowy problem o dużej wadze. Jeśli znajdziemy dowody na wykorzystywanie, możemy narazić się na wagę KRYTYCZNĄ. Działania naprawcze: zaimplementuj kontrole po stronie serwera, aby mieć pewność, że użytkownik przesyłający żądanie powinien mieć uprawnienia do wyświetlania i edytowania żądanego profilu za pomocą wartości profileID. Jeśli na przykład Alicja jest zalogowana i ma identyfikator profilu 123456, ale zaobserwowano, że zażądała identyfikatora profileID 333444, użytkownik powinien zobaczyć błąd i próba uzyskania dostępu do profilu innego użytkownika powinna być rejestrowana. Więcej informacji na temat IDOR i sposobu rozwiązania tego problemu znajdziesz w materiałach na temat tego błędu udostępnionych przez OWASP.

Możesz zaoszczędzić czas i wysiłek fizyczny, znajdując sposoby na automatyzację konwertowania luk w zabezpieczeniach z różnych źródeł na format standardowy. Wraz z tworzeniem kolejnych luk w zabezpieczeniach możesz zauważyć typowe motywy podczas działań naprawczych. Oprócz ogólnego szablonu formatu błędów możesz utworzyć dodatkowe szablony dla typowych rodzajów luk w zabezpieczeniach.

Znajdowanie właścicieli

Jednym z najtrudniejszych aspektów zarządzania lukami w zabezpieczeniach jest wyznaczanie właścicieli, którzy pomogą w naprawianiu błędów, oraz zachęcenie ich do poświęcenia zasobów na rzecz naprawiania błędów zgodnie z harmonogramem. Jeśli masz skonfigurowane procesy zarządzania zasobami, będzie to trochę łatwiejsze. Jeśli nie, może to być dla Ciebie motywacją do podjęcia decyzji. W zależności od wielkości organizacji znalezienie właściciela może być proste lub niezwykle skomplikowane. Wraz z rozwojem organizacji rośnie wysiłek w określeniu, kto jest odpowiedzialny za rozwiązanie nowo wykrytych problemów z bezpieczeństwem. Rozważ przeprowadzenie rotacji operacyjnej. Dyżurny użytkownik jest odpowiedzialny za sprawdzanie nieprzypisanych luk w zabezpieczeniach, śledzenie właścicieli i ustalanie priorytetów na podstawie poziomu ważności. Nawet jeśli jesteś w stanie określić, kto jest odpowiedzialny za usunięcie luki w zabezpieczeniach i przypisać ją do błędu, musisz przekonać jej członków, żeby poświęcili czas na jej naprawienie. To podejście może różnić się w zależności od zespołu lub osoby oraz od innych elementów, nad którymi pracuje. Jeśli udało Ci się zdobyć poparcie organizacyjne dotyczące standardów poziomu ważności i harmonogramów działań naprawczych, możesz się do nich odwołać. Czasami jednak potrzeba dodatkowej motywacji, aby kogoś poprawić. Oto kilka ogólnych wskazówek dotyczących usuwania luk w zabezpieczeniach:

• Wyjaśnij: gdy ktoś ma lukę w zabezpieczeniach, którą trzeba naprawić, jest to zwykle nieoczekiwana praca. Wyjaśnij, dlaczego ten problem należy rozwiązać w odpowiednim czasie (np. scenariusz wpływu lub ataku), i upewnij się, że właściciel go rozumie.
• Przygotuj kontekst: czasami tylko jedna osoba ma wiedzę niezbędną do naprawienia błędu, a może ma inne zadania, nad którymi pracuje. Poświęć trochę czasu, aby się tego dowiedzieć. Możliwe, że inne zadania mogą być ważniejsze od usunięcia w najbliższej perspektywie tej luki w zabezpieczeniach. Wykażenie się empatią i elastycznością w zakresie terminów działań naprawczych pomoże Ci uzyskać renomę i wzmocnić relacje z osobami, które muszą naprawić luki w zabezpieczeniach. Tylko uważaj, aby nie zostawiać zbyt wielu pytań. Jeśli tego nie zrobisz, Twoja organizacja nie będzie poważnie traktować harmonogramu działań naprawczych.
• Wyjaśnij, jak to zrobić: nawet jeśli uwzględnisz w opisie porady na temat rozwiązywania problemów, właściciel, który zajmuje się rozwiązaniem problemu, może być zdezorientowany lub potrzebować pomocy, aby się dowiedzieć, jak go naprawić. Jeśli potrzebują pomocy w rozwiązaniu tego problemu, pomóż mu. Samo zarzucanie właścicielom błędów bez pomagania im, może negatywnie wpłynąć na relację organizacji z zespołem ds. bezpieczeństwa. Możliwa pomoc dla innych pozwoli im usuwać obecne i przyszłe luki w zabezpieczeniach oraz pomagać innym w nauczaniu.
• Dostosuj swoją prośbę: różne zespoły i poszczególni użytkownicy mogą mieć własne procesy związane z akceptacją i priorytetem otrzymywanych zgłoszeń. Niektóre zespoły mogą chcieć, aby wszystkie prośby były przekazywane przez ich menedżerów. Inni będą chcieli, aby prośby o pomoc były przesyłane w standardowym formacie. Niektóre działają tylko na wstępnie zdefiniowanych wartościach sprintu. Niezależnie od sytuacji poświęcenie więcej czasu na dostosowanie prośby do formatu, z jakiego zespół lub dana osoba zwykle przyjmuje prośby o pomoc, zwiększy prawdopodobieństwo potraktowania prośby priorytetowo i podjęcia działań.
• Przekazywanie w ostateczności: jeśli po wykonaniu wszystkich opisanych wyżej czynności, a osoba lub zespół odpowiedzialny za usunięcie luki w zabezpieczeniach nie znajdzie czasu na rozwiązanie poważnego problemu z bezpieczeństwem, w razie potrzeby przekaż sprawę kierownictwu. Należy to zawsze zrobić w ostateczności, ponieważ może to zaszkodzić relacjom z daną osobą lub zespołem.

Analiza przyczyn źródłowych

Oprócz wyszukiwania i usuwania poszczególnych luk w zabezpieczeniach analiza głównych przyczyn (RCA) może pomóc w wykrywaniu i rozwiązaniu problemów z bezpieczeństwem systemowym. Każdy ma ograniczone zasoby, dlatego warto pominąć ten krok. Warto jednak poświęcić czas na analizę trendów w danych o lukach w zabezpieczeniach oraz na dokładniejszą analizę krytycznych i dużych błędów. Pozwoli to zaoszczędzić czas i zmniejszyć ryzyko w dłuższej perspektywie. Załóżmy, że w aplikacji często pojawia się ten sam typ luki w zabezpieczeniach (np. przekierowywanie intencji). Postanawiasz porozmawiać z zespołami, które wprowadzają te luki w zabezpieczeniach aplikacji, i uświadamiasz sobie, że znaczna większość z nich nie wie, czym jest przekierowanie intencji, dlaczego ma znaczenie ani jak mu zapobiegać. Przygotowaliśmy krótką prezentację i przewodnik, aby pomóc deweloperom w organizacji w związku z tą luką w zabezpieczeniach. Ta luka w zabezpieczeniach prawdopodobnie nie zniknie całkowicie, ale szybkość, z jaką się pojawia, najprawdopodobniej zmaleje. Po uruchomieniu VDP każda luka w zabezpieczeniach zgłoszona przez osobę trzecią to coś, co prześlizgnęło się przez Twoje wewnętrzne procesy zabezpieczeń. Przeprowadzanie RCA w przypadku błędów z VDP da Ci jeszcze więcej informacji na temat systematycznego ulepszania programu bezpieczeństwa.

Wykrywanie i reagowanie

Wykrywanie i reagowanie odnosi się do wszelkich narzędzi i procesów pozwalających wykrywać potencjalne ataki na organizację i reagować na nie. Takie rozwiązania mogą przybierać formę zakupionych lub opracowanych samodzielnie rozwiązań, które analizują dane w poszukiwaniu podejrzanych zachowań. Na przykład w sekcji Błędy związane z pielęgnacją błędów omawialiśmy rejestrowanie każdej próby uzyskania nieautoryzowanego dostępu do profilu innego użytkownika. Jeśli zauważysz, że użytkownik generuje w krótkim czasie dużą liczbę nieudanych prób uzyskania dostępu do profili innych użytkowników, możesz zobaczyć sygnał lub alert. Możesz nawet zautomatyzować proces blokowania użytkownikowi dostępu do usług na określony czas lub na czas nieokreślony, dopóki problem nie zostanie sprawdzony i ręcznie przywrócony. Jeśli nie masz jeszcze wdrożonych mechanizmów wykrywania i reagowania, rozważ współpracę z ekspertem, który pomoże Ci stworzyć dla organizacji program w dziedzinie kryminalizmu i reagowania na incydenty (DFIR). Jeśli korzystasz już z mechanizmów wykrywania i reagowania, warto pomyśleć o konsekwencjach, w których 5, 10, a nawet 100 specjalistów ds. bezpieczeństwa przeprowadzających testy na Twoich platformach ataku z wykorzystaniem internetu. Może to mieć duży wpływ na wszystkie używane przez Ciebie systemy wykrywania włamań i zapobiegania włamaniom (IPS).

Możliwe zagrożenia:

• Przeciążenie alertów: zalew alertów lub sygnałów, które wyglądają jak złośliwe ataki, ale w rzeczywistości są normalnymi, zatwierdzonymi testami prowadzonymi przez badaczy bezpieczeństwa uczestniczących w programie VDP. Taki hałas generuje się w takim stopniu, że trudno jest odróżnić prawdziwe ataki od rzetelnych testów bezpieczeństwa.
• Fałszywe alarmy w reakcji na incydenty: jeśli wdrożysz procesy dotyczące użytkowników tej strony o godzinie 2:00 w sobotę, nie będą oni zadowoleni z budowania i sprawdzania potencjalnych naruszeń, które w rzeczywistości były wykonywane przez badacza ds. bezpieczeństwa, który przeprowadza legalne testy.
• Blokowanie badaczy zabezpieczeń: jeśli masz agresywne systemy zapobiegania włamaniom (IPS), możesz zablokować adres IP badacza zabezpieczeń, który próbuje przeprowadzać skanowanie, testy ręczne itp., aby zidentyfikować luki w zabezpieczeniach i Ciebie je zgłosić. Zwłaszcza w przypadku VDP, jeśli badacz ds. bezpieczeństwa zostanie zablokowany po 5 minutach testowania, może stracić zainteresowanie i skupić się na programie innej organizacji. Może to prowadzić do ogólnego braku zaangażowania badaczy bezpieczeństwa w Twój program, co zwiększa ryzyko nieodkrytych luk w zabezpieczeniach (i tym samym nieznanych Twojej organizacji). Chociaż możesz nie chcieć tonować swojego IPS, możesz podjąć inne działania, aby zmniejszyć ryzyko zniechęcenia badaczy.

Sposób radzenia sobie z tymi zagrożeniami zależy w dużej mierze od tego, jakie podejście przyjmiesz we współpracy z zewnętrznymi badaczami zabezpieczeń. Jeśli interesuje Cię bardziej czarna skrzynka, która symuluje prawdziwe ataki, nie musisz nic robić. W takiej sytuacji ruch badaczy będzie generować alerty, a Twój zespół może podjąć działania, by zbadać problem i odpowiednio zareagować. Pomaga to Twojemu zespołowi przećwiczyć reagowanie na prawdziwe ataki, ale może zmniejszyć zaangażowanie badaczy bezpieczeństwa, zwłaszcza jeśli nie mają oni dostępu do testów. Może to też spowodować pominięcie prawdziwego ataku podczas sprawdzania uzasadnionych testów. Jeśli chcesz korzystać z szarych pól, możesz nawiązać współpracę z badaczami zabezpieczeń, aby samodzielnie identyfikować ruch związany z testami. W ten sposób możesz dodać do białej listy ruch pochodzący z testów i wywołanych z nich alertów lub w inny sposób odfiltrować ruch z testów. Twój zespół będzie mógł lepiej odróżniać prawdziwe ataki od zatwierdzonych testów, a badacze będą mogli znajdować i zgłaszać luki w zabezpieczeniach bez utrudniania im dostępu do systemów zapobiegania włamaniom. Niektóre organizacje proszą badaczy ds. zabezpieczeń o przesłanie formularza wniosku o unikalny identyfikator, który może być dołączany do nagłówków w żądaniach generowanych przez badacza. Dzięki temu organizacja może dodać ruch do białej listy dla badacza, a także określić, czy wykracza poza uzgodniony zakres testów. W takim przypadku możesz skontaktować się z badaczem i poprosić go, aby wstrzymał się do czasu, gdy uda Ci się wspólnie opracować plan testów.