Stanowisko
Bezpieczeństwo IT
Jak szybko dowiadujecie się o podatności krytycznej w systemie, który macie u siebie? Od tej liczby zależy, czy okno między ujawnieniem a łatą jest ryzykiem, czy tylko zadaniem.
Rozmowa wstępna
Cztery pytania, od których byśmy zaczęli
Jak szybko dowiadujecie się o nowej podatności w używanym komponencie?
Jeśli z newslettera raz w tygodniu, to okno reakcji jest tygodniowe niezależnie od wagi.
Ile razy dziennie alert okazuje się fałszywy?
Jeśli zespół przestał czytać alerty, to monitoring działa formalnie, a nie faktycznie.
Kiedy zapada decyzja o wyłączeniu podatnej usługi?
Jeśli nigdy, bo biznes nie pozwoli, to warto wiedzieć o tym wcześniej niż w trakcie incydentu.
Co odkładacie pierwsze, kiedy zgłoszeń jest więcej niż ludzi?
Zwykle: podatności średnie i przeglądy - czyli to, z czego biorą się incydenty za pół roku.
Zdejmujemy zbieranie i priorytetyzowanie, zostawiamy ocenę i decyzje
Zbieranie informacji o podatnościach, odsiewanie szumu z alertów, zbieranie kontekstu przy incydencie i prowadzenie dokumentacji dają się odciążyć. Ocena zagrożenia i decyzja o reakcji zostają przy specjaliście.
- Podatność jest wiązana z Waszym środowiskiem. - Nie każda krytyczna podatność dotyczy Was, a priorytet zależy od tego, gdzie komponent jest używany i czy jest wystawiony.
- Alert przychodzi z kontekstem. - Co jeszcze działo się w tym oknie, jakie zdarzenia są powiązane, czy wzorzec już występował.
- Incydent ma zapisaną chronologię. - W trakcie, nie po - bo rekonstrukcja po tygodniu jest zawsze gorsza i zawsze droższa.
Zakres
Co da się odciążyć w bezpieczeństwie IT
Dziewiętnaście przykładowych zadań. Każde ma punkt zatwierdzenia po stronie człowieka. Poniżej wybrane, a zakres dopasowujemy do Waszej powierzchni ataku.
Podatności i ich priorytety
- Powiązanie ogłoszonej podatności z używanymi komponentami
- Wskazanie systemów, w których komponent jest wystawiony
- Propozycja priorytetu wedle wystawienia i krytyczności (decyzja: specjalista)
- Status usuwania podatności wedle systemów
- Sygnał o podatności krytycznej otwartej dłużej niż uzgodniono
Monitoring i alerty
- Alert z kontekstem zdarzeń z tego samego okna
- Grupowanie alertów o wspólnej przyczynie
- Wskazanie reguł o najwyższym udziale trafień fałszywych, z wyłączeniem reguł o wysokiej wadze
- Sygnał o systemie bez pokrycia monitoringiem
Incydenty
- Kompletowanie danych do oceny zdarzenia
- Chronologia incydentu zapisywana w trakcie
- Powiadomienie uzgodnionych osób wedle wagi (decyzja: specjalista)
- Projekt raportu po incydencie (treść: specjalista)
Świadomość pracowników
- Harmonogram szkoleń i testów socjotechnicznych
- Zestawienie wyników wedle działów, bez wskazywania osób
- Materiał przypominający dla obszarów o najniższym wyniku
Zgodność i audyty
- Zestawienie dowodów wymaganych przez standard
- Status działań naprawczych po audycie
- Rejestr wyjątków bezpieczeństwa z terminem przeglądu
Dzień pracy
Dzisiaj
- O podatnościach dowiadujecie się z list i newsletterów
- Ustalanie, czy dotyczy Was, zajmuje godziny na system
- Alerty przychodzą w liczbie, której nikt nie przegląda w całości
- Przy incydencie zaczynacie od zbierania logów z kilku miejsc
- Chronologię incydentu odtwarzacie po fakcie
- Dowody na audyt zbieracie przez dwa tygodnie
Z asystą AI
- Podatność jest wiązana z komponentami, które faktycznie macie
- Widzicie, gdzie komponent jest wystawiony, i priorytet ma podstawę
- Alerty są grupowane, a reguły generujące szum wskazane
- Incydent zaczyna się od zebranego kontekstu
- Chronologia zapisuje się w trakcie zdarzenia
- Dowody na audyt są zbierane na bieżąco
- Czas usunięcia podatności krytycznej
krótsze okno między ujawnieniem a łatą
podatność jest od razu wiązana ze środowiskiem
- Szum w alertach bezpieczeństwa
zespół czyta alerty, bo jest ich mniej
reguły generujące szum są wskazywane
- Czas reakcji na incydent
mniej czasu na zbieranie, więcej na decyzje
kontekst jest przy zgłoszeniu
- Odporność na phishing
widać, które obszary wymagają przypomnienia
wyniki testów są zestawiane wedle działów
Zaczynamy od powiązania podatności z Waszym środowiskiem, bo to najszybciej skraca czas reakcji.
- Krok 1
Podatności wobec używanych komponentów
Co faktycznie macie, gdzie jest wystawione, jaki priorytet ma to dla Was.
- Krok 2
Porządek w alertach
Grupowanie, kontekst i wskazanie reguł generujących szum.
- Krok 3
Obsługa incydentu
Kontekst przy zgłoszeniu i chronologia zapisywana w trakcie.
- Krok 4
Zgodność i świadomość
Dowody na audyt i zestawienia z testów socjotechnicznych. Na końcu, bo opiera się na uporządkowanych podatnościach i alertach.
Częste pytania
Pytania, które padają na pierwszym spotkaniu
Czym to się różni od utrzymania systemów i zarządzania dostępami?
Administrator dba o to, żeby systemy działały; zarządzanie dostępami - o to, kto co widzi. Tu przedmiotem są podatności, zagrożenia i incydenty. Obszary stykają się przy aktualizacjach i przy uprawnieniach nadmiarowych, ale codzienne pytania są zupełnie inne.
Czy to znaczy, że potrzeba mniej osób w bezpieczeństwie?
Zespoły bezpieczeństwa są niemal wszędzie za małe wobec liczby alertów - i to jest powód, dla którego alerty przestają być czytane. Odciążenie szumu nie zmniejsza zespołu; przywraca mu zdolność zauważenia rzeczy nietypowej. Przy wysyconej kolejce atak celowany ginie tym pewniej i o tym jest tu cała rozmowa.
Czy to podlega AI Act?
Bezpieczeństwo IT nie jest zastosowaniem wysokiego ryzyka. Granica przebiega przy danych o zachowaniu pracowników: wyniki testów socjotechnicznych i analiza zdarzeń mogą wskazywać na konkretne osoby, więc zestawienia prowadzimy wedle działów i systemów, a nie wedle nazwisk - inaczej byłoby to monitorowanie pracowników.
Zostało pytanie, którego tu nie ma? Umów rozmowę
Następny krok
Ile Waszych podatności krytycznych jest otwartych dłużej niż miesiąc?
Pokażemy Wam, jak wygląda praca zespołu bezpieczeństwa, w której podatność jest wiązana ze środowiskiem, a incydent zaczyna się od kontekstu.