10 błędów w zarządzaniu politykami bezpieczeństwa sieci

Dlaczego Twój firewall ma 4000 reguł, z których realnie działa 1200?

W wielu firmach polityka bezpieczeństwa sieci nie jest już spójnym dokumentem. Jest raczej warstwą reguł odkładanych przez lata: po migracjach, audytach, wdrożeniach aplikacji czy sytuacjach typu „wpuśćmy to na chwilę”.
Problem pojawia się wtedy, gdy nikt nie wie już, dlaczego dana reguła istnieje, kto za nią odpowiada i co się stanie po jej usunięciu.
W środowiskach multi-vendor jest to szczególnie trudne. Palo Alto, Fortinet, Check Point, Cisco, AWS czy Azure często są zarządzane z różnych konsol i przez różne zespoły.
Oto 10 błędów, które najczęściej prowadzą do chaosu w politykach bezpieczeństwa oraz sposoby, jak je ograniczyć.

1. Brak jednej mapy ruchu w środowisku multi-vendor

Objaw: Palo Alto, Fortinet, Check Point, Cisco, do tego security groups w AWS i NSG w Azure. Każde zarządzane z innej konsoli, przez inny zespół, według innej konwencji nazewniczej. 
Dlaczego to boli: Nikt nie potrafi odpowiedzieć na pytanie "czy host A dogada się z hostem B i przez które urządzenia przejdzie ten pakiet". Analiza trwa godziny, a odpowiedź i tak jest hipotezą. 
Jak naprawić: Zbuduj model topologii, który uwzględnia routing i wszystkie punkty egzekwowania polityki, a nie pojedyncze konfiguracje. Symulacja ścieżki ruchu powinna być zapytaniem, nie projektem. 
AlgoSec: Horizon Security Analyzer (dawniej Firewall Analyzer) mapuje całe środowisko hybrydowe i odpowiada na pytania typu "traffic simulation query" w kilka sekund. 

2. Reguły any-any traktowane jako rozwiązanie tymczasowe 

Objaw: Reguła z source: any, service: any, opis "temp - do wyjaśnienia", data utworzenia: 2019. 
Dlaczego to boli: To nie jest tylko dług techniczny, to gotowy korytarz do ruchu lateralnego. W audycie NIS2 czy PCI DSS taka reguła jest pierwszym znaleziskiem. 
Jak naprawić: Zamiast ręcznego przeglądu wprowadź automatyczne wykrywanie reguł nadmiarowo permisywnych i zawężanie ich na podstawie realnego ruchu (traffic logs), a nie na podstawie deklaracji właściciela aplikacji. 

3. Reguły osierocone - bez właściciela i bez daty ważności 

Objaw: 30 procent reguł w polityce nie zarejestrowało trafienia od kilkunastu miesięcy. Nikt ich nie usuwa, bo nikt nie wie, czyje są. 
Dlaczego to boli: Każda nieużywana reguła to niepotrzebna powierzchnia ataku i niepotrzebne obciążenie sprzętu. A brak właściciela oznacza, że ryzyko nie ma adresata. 
Jak naprawić: Każda reguła musi mieć trzy atrybuty: właściciela biznesowego, powiązaną aplikację i datę wygaśnięcia. Reguły bez tych atrybutów powinny trafiać do kolejki recertyfikacji automatycznie. 

4. Zmiany wdrażane ręcznie, przez CLI, po godzinach 

Objaw: Ticket w systemie ITSM, inżynier loguje się na urządzenie, wkleja komendy, zamyka ticket. Weryfikacja: "no przecież działa". 
Dlaczego to boli: Literatura branżowa od lat wskazuje błąd ludzki w konfiguracji jako główną przyczynę niedostępności usług sieciowych. Do tego dochodzi brak powtarzalności - ta sama zmiana wykonana przez dwie osoby wygląda inaczej. 
Jak naprawić: Proces zmiany musi być workflow, a nie zwyczajem. Wniosek, analiza wpływu, projekt reguły, akceptacja, wdrożenie, walidacja po wdrożeniu. 
AlgoSec: Horizon FireFlow integruje się z ServiceNow czy BMC Remedy i prowadzi zmianę od wniosku do wdrożenia zero-touch, z automatyczną weryfikacją, czy zmiana faktycznie została zaaplikowana. 

5. Analiza ryzyka wykonywana po wdrożeniu, nie przed 

Objaw: Dowiadujemy się, że nowa reguła narusza segmentację, kiedy przychodzi raport z kwartalnego skanu. 
Dlaczego to boli: Koszt wycofania zmiany w produkcji jest wielokrotnie wyższy niż koszt jej odrzucenia na etapie wniosku. Poza tym okno ekspozycji trwa tygodniami. 
Jak naprawić: Wprowadź predykcyjną analizę ryzyka: zanim reguła powstanie, system ma powiedzieć, jakie zasady segmentacji narusza, czy otwiera dostęp do systemu z krytyczną podatnością i czy istnieje już reguła, która realizuje to samo połączenie. 

6. Myślenie urządzeniami zamiast aplikacjami 

Objaw: Zespół sieciowy zarządza firewallami. Zespół aplikacyjny zarządza aplikacjami. Nikt nie zarządza połączeniem między nimi. 
Dlaczego to boli: Przy wycofywaniu aplikacji reguły zostają w polityce na zawsze. Przy migracji do chmury nikt nie wie, jakiego dostępu aplikacja faktycznie potrzebuje, więc kopiuje się wszystko "na wszelki wypadek". 
Jak naprawić: Odwróć perspektywę. Podstawową jednostką zarządzania powinna być aplikacja biznesowa i jej wymagania łączności, a reguły na urządzeniach powinny być z niej wyprowadzane. 
AlgoSec: Horizon AppViz odkrywa aplikacje i ich łączność oraz wiąże reguły z konkretną aplikacją. AppChange pozwala modyfikować dostęp na poziomie aplikacji, a nie pojedynczych ACL. 

7. Zgodność traktowana jako projekt raz w roku 

Objaw: Na sześć tygodni przed audytem trzy osoby robią zrzuty konfiguracji i sklejają dowody w Excelu. 
Dlaczego to boli: Raport z audytu opisuje stan z jednego dnia. Dzień później środowisko jest już inne. Przy NIS2 i DORA, gdzie liczy się ciągłość i udokumentowany proces zarządzania ryzykiem, taki model przestaje wystarczać. 
Jak naprawić: Zgodność ma być stanem ciągłym i mierzalnym. Raporty do PCI DSS, ISO 27001, NIS2 czy SOX powinny być generowane na żądanie z aktualnych danych, a odchylenia od baseline zgłaszane w momencie ich powstania. 

8. Chmura poza zakresem polityki bezpieczeństwa 

Objaw: Polityka on-premise jest przeglądana kwartalnie. Security groups w chmurze zmienia zespół DevOps przez Terraform, bez przeglądu. 
Dlaczego to boli: Powstają dwa równoległe modele bezpieczeństwa i ruch, który przechodzi między nimi. Błędne konfiguracje w chmurze należą do najczęstszych przyczyn ekspozycji zasobów. 
Jak naprawić: Jeden model polityki dla środowiska hybrydowego. Reguły w chmurze podlegają tym samym zasadom segmentacji i tym samym przeglądom co reguły on-premise. 
AlgoSec: AlgoSec Cloud obejmuje polityki w chmurze publicznej i SDN, a Prevasio dokłada warstwę CNAPP, w tym skanowanie kontenerów. 

9. Brak ścieżki audytowej i automatycznej dokumentacji 

Objaw: Pytanie "kto dodał tę regułę, kiedy i na czyj wniosek" kończy się przeszukiwaniem skrzynki pocztowej. 
Dlaczego to boli: Bez powiązania zmiany technicznej z decyzją biznesową nie da się ani rozliczyć incydentu, ani obronić się w audycie. To także jeden z najczęstszych braków w dokumentacji systemu zarządzania bezpieczeństwem. 
Jak naprawić: Każda zmiana w polityce musi mieć automatycznie generowany rekord: wnioskodawca, uzasadnienie, wynik analizy ryzyka, akceptujący, czas wdrożenia, wynik walidacji. 

10. Optymalizacja polityki bez analizy kolejności reguł 

Objaw: Ktoś usuwa "zdublowane" reguły ręcznie i po tygodniu wraca zgłoszenie, że przestała działać integracja z systemem partnera. 
Dlaczego to boli: Reguły przesłonięte (shadowed), zdublowane i skonsolidowane wyglądają podobnie tylko z daleka. Bez analizy kolejności i realnego pokrycia ruchu porządkowanie polityki staje się generatorem incydentów. 
Jak naprawić: Optymalizacja musi opierać się na analizie zależności między regułami i na danych z logów, a nie na intuicji. Zmiany wprowadzaj partiami, z możliwością wycofania. 

Jak uporządkować polityki bezpieczeństwa?

Jeżeli rozpoznajesz u siebie więcej niż cztery z powyższych punktów, problemem nie jest konkretna reguła, tylko brak procesu. Kolejność działań, która zwykle się sprawdza: 

AlgoSec – inteligentne zarządzanie polityką bezpieczeństwa sieci

AlgoSec to wiodący dostawca rozwiązań do zarządzania polityką bezpieczeństwa sieci w przedsiębiorstwach, pomaga największym organizacjom na świecie dostosować ich wymagania bezpieczeństwa do procesów biznesowych w całym przedsiębiorstwie. 
Dzięki AlgoSec użytkownicy mogą odkrywać, mapować i migrować połączenia aplikacji biznesowych; proaktywnie analizować ryzyko z perspektywy biznesowej; oceniać wpływ potencjalnych ataków hakerów na operacje biznesowe; oraz inteligentnie automatyzować zmiany w zakresie bezpieczeństwa sieci w siedzibie firmy, w chmurze lub w sieci zdefiniowanej programowo.

Chcesz dowiedzieć się więcej o AlgoSec?

Umów się na bezpłatne demo narzędzia, przygotuj pytania i dowiedz się czy AlgoSec odpowiada potrzebom Twojej organizacji.