Większość organizacji inwestuje w nowoczesne systemy bezpieczeństwa, zakładając, że to technologia jest głównym źródłem ryzyka. Tymczasem problem najczęściej leży znacznie bliżej – w konfiguracji polityk firewall. Zastanówmy się, dlaczego zarządzanie regułami firewall staje się dziś kluczowym elementem cyberbezpieczeństwa.
Gartner wskazuje jednoznacznie: „99% naruszeń firewalla wynika z błędnej konfiguracji, nie z problemu sprzętowego.”
To nie są luki w oprogramowaniu. Nie jakieś super zaawansowane ataki typu zero-day, przed którymi nic nie zrobisz. Chodzi o konfigurację. Błąd ludzki. Reguła, którą ktoś dodał lata temu dla jakiegoś projektu i zapomniał usunąć. Albo coś, co otwiera dostęp do strefy DMZ, bo nikt nie wiedział, że tam siedzi.
To diagnoza, która powinna wywrócić do góry nogami to, jak myślisz o bezpieczeństwie swojej sieci. Bo przez ostatnią dekadę wszyscy inwestowali w coraz lepszy sprzęt, coraz sprytniejsze systemy wykrywania, coraz droższe centra zarządzania bezpieczeństwem. A tymczasem największe ryzyko nie siedzi w algorytmach atakującego – siedzi w Twoich własnych, zaniedbanych regułach.
Zanim przejdziemy do liczb, zróbmy szybki eksperyment myślowy.
Wyobraź sobie firmę, która pięć lat temu zainstalowała solidnego firewalla. Dobry producent, wszystko grało. Przez te pięć lat sieć się zmienia: nowe systemy, nowe projekty, nowe potrzeby. Każde z nich wymaga zmian w polityce bezpieczeństwa. Zmian, które trzeba wprowadzić szybko, bo „biznes czeka”.
Dodajemy reguły. Nic praktycznie nie usuwamy – bo kto weźmie odpowiedzialność za usunięcie czegoś, jeśli nie wie, do czego to służy? Obiekty serwisowe mnożą się jak króliki. Każdy projekt dodaje swoje, nie sprawdzając, czy czegoś podobnego już nie ma.
Po pięciu latach masz setki reguł. Część obsługuje systemy, które zostały wyłączone dwa lata temu. Część jest po prostu „zasłonięta” przez inne, wcześniejsze reguły i nigdy nie zostanie aktywowana. Część ma właściciela, który od półtora roku pracuje już w innej firmie.
To nie jest wymyślony scenariusz. To opisy sytuacji, które FireMon regularnie odkrywa podczas audytów u klientów.
Oto suche liczby z tych audytów:
Pytanie nie brzmi „czy masz problem z 'policy sprawl’ (rozrostem polityk)?”. Pytanie brzmi „jak duży jest Twój problem?”.
1. Shadowrules – reguły, których nie widzisz
„Shadow rule” to taka reguła firewalla, która nigdy nie zostanie uruchomiona, bo wcześniej w kolejce stoi inna, bardziej ogólna reguła, która „przechwytuje” pasujący ruch.
Przykład: Masz regułę numer 47, która zezwala na ruch TCP z konkretnej podsieci do konkretnego serwera na porcie 443. Ale wyżej, pod numerem 23, masz regułę, która zezwala na cały ruch TCP z tej samej podsieci do całego segmentu sieci. Reguła 47 staje się „shadow rule”. Nigdy się nie wykona. Nigdy nie pojawi się w logach. Ale nadal istnieje – jako coś, co kiedyś miało być zabezpieczeniem, a teraz nikt tym nie zarządza.
2. Policysprawl– reguły bez właściciela, bez kontekstu, bez końca
Każdy projekt generuje reguły. Projekty się kończą. Reguły zostają.
Problem: Nikt nie chce brać odpowiedzialności za usunięcie reguły, jeśli nie jest w 100% pewien, co ona robi. W każdym dziale IT, w każdym zespole security, w każdej firmie usłyszysz: „A nuż coś na tym jedzie?”. Efekt? Baza reguł rośnie i rośnie. Nigdy nie maleje.
Z czasem reguły tracą kontekst. Brakuje dokumentacji wyjaśniającej, dlaczego reguła nr 312 pozwala na ruch z 10.0.4.0/24 do 172.16.8.15 na porcie 8080. Inżynier, który ją tworzył, już dawno nie pracuje w firmie. Ticket w systemie ITSM jest nieaktualny od roku. Reguła zostaje – i nikt nie wie, czy można ją ruszyć.
Dane z audytów FireMon:
3. Objectbloat– niewidzialna złożoność
Obiekty serwisowe, obiekty aplikacyjne, grupy adresów IP. Każda zmiana reguły może potencjalnie stworzyć nowy obiekt, bo szybciej jest dodać nowy niż sprawdzić, czy identyczny już nie istnieje. Przez lata w systemie gromadzą się tysiące obiektów – z których ogromna większość nigdy nie jest używana.
To nie tylko estetyczny problem. Nieużywane obiekty komplikują analizę każdej nowej zmiany. Utrudniają audyty. Zasłaniają prawdziwe zależności. A co najważniejsze – zwiększają ryzyko popełnienia błędu przy przyszłych zmianach. Inżynier, który widzi 400 obiektów zamiast 40, ma znacznie większą szansę się pomylić.
Często słyszymy: „Mamy SIEM. Widzimy anomalie. Jesteśmy bezpieczni.” SIEM jest kluczowy, nikt tego nie kwestionuje. Ale SIEM analizuje zdarzenia – ruch, który już się wydarzył, logi, które już zostały wygenerowane. SIEM powie Ci, że coś się stało. Nie powie Ci, dlaczego Twoja polityka bezpieczeństwa na to pozwoliła.
Zarządzanie politykami firewalla to inna liga analizy. To nie „co się dzieje?”, ale „co może się dziać, biorąc pod uwagę aktualne reguły?”. To analiza struktury, nie zdarzeń. A SIEM tego nie robi – bo nie do tego został stworzony.
Oba podejścia się uzupełniają. Ale firmy, które inwestują tylko w wykrywanie i reagowanie, ignorując analizę stanu polityk, mają fundamentalną lukę: wiedzą, kiedy coś się dzieje, ale nie wiedzą, czy ich polityki są w ogóle skonfigurowane tak, by temu zapobiec.
Błędy w politykach firewalla generują trzy rodzaje kosztów. Dwa z nich są niewidoczne w standardowych raportach.
Koszt widoczny: incydent
Naruszenie danych kosztuje globalnie średnio około 5 milionów dolarów i rośnie o 10% rocznie. To liczba, którą zarządy widzą w raportach. To ryzyko, które wszyscy rozumieją.
Koszt niewidoczny nr 1: operacyjny
Każda zmiana polityki firewalla w środowisku bez odpowiednich narzędzi wymaga ręcznej analizy. Ile reguł ta zmiana dotknie? Czy nie otworzy nowej ścieżki dostępu? Czy nie naruszy PCI-DSS? W przeciętnej firmie taki proces zajmuje od kilku godzin do dwóch tygodni. Pomnóż to przez 100 zmian tygodniowo. Policz potrzebne zasoby ludzkie. Zastanów się, co te zespoły mogłyby robić zamiast manualnej analizy reguł.
Koszt niewidoczny nr 2: regulacyjny
Kara za NIS2 może sięgnąć 10 milionów euro lub 2% globalnego przychodu, a co ważniejsze – wprowadza osobistą odpowiedzialność zarządu za niedociągnięcia. DORA z kolei nakłada drastyczne kary za brak kontroli nad ryzykiem ICT i operacyjną odpornością. Ale zanim kary, jest koszt przygotowania do audytu: ręczne generowanie raportów, zbieranie danych z wielu platform, udowodnienie, że każda zmiana przeszła przez właściwą ocenę ryzyka. Te koszty są w większości firm „rozmyte” – wliczane jako czas inżynierów, godziny pracy konsultantów, koszty zewnętrznych audytów. Nikt ich nie sumuje. Dopóki nie jest za późno.
FireMon: zarządzanie politykami firewall, nie kolejny monitoring
FireMon powstał w 2001 roku, żeby rozwiązać jeden, konkretny problem: nikt nie miał pełnego obrazu tego, co tak naprawdę robią polityki firewalla w skomplikowanym, wielostandardowym środowisku.
Dwie dekady i ponad 1700 klientów w 70 krajach później – problem wciąż ten sam. Środowiska są tylko bardziej złożone.
Mechanizm działania FireMon opiera się na czterech filarach:
Real-time inventory
FireMon zbiera polityki (a także pliki konfiguracyjne, tabele routingu, reguły NAT itp.) ze wszystkich urządzeń – on-premises, w chmurze, SD-WAN, SASE – i przekłada je na jeden, centralny model danych. Obsługuje ponad 80 producentów i ich wersji od razu. Cisco, Fortinet, Palo Alto, Check Point, AWS Security Groups, Azure Network ACLs – jeden widok, jeden język analizy.
Policy intelligence
Na podstawie zunifikowanego modelu, FireMon identyfikuje „shadow rules”, nieużywane reguły, obiekty bez właściciela, reguły nadmiernie liberalne („permit any any”), duplikaty, redundancje. Nie jako jednorazowy raport – ale jako ciągły, aktualizowany w czasie rzeczywistym obraz stanu polityk.
Change management z oceną ryzyka
Przed każdą proponowaną zmianą – automatyczna analiza wpływu. Które reguły zostaną naruszone? Czy zmiana tworzy nową ścieżkę dostępu między segmentami? Jaki jest poziom ryzyka tej zmiany w kontekście aktualnych polityk i wymagań zgodności? To nie jest analiza „po fakcie” – to certyfikacja zmiany przed wdrożeniem.
Continuous compliance
FireMon mapuje stan polityk bezpieczeństwa na wymagania regulacyjne: PCI-DSS, NIST, HIPAA, ISO 27001, DORA – od razu. Przy każdej zmianie polityki system automatycznie sprawdza, czy nie narusza danego standardu. Raport dla audytora? Generowany na żądanie, nie przygotowywany trzy tygodnie przed audytem.
Jeden z klientów FireMon – instytucja finansowa z rozbudowaną siecią oddziałów – miał klasyczny problem: audyt PCI-DSS wykazał niezgodności, których nie potrafili dokładnie zlokalizować. Wiedzieli, że coś jest nie tak z politykami firewalla. Nie wiedzieli co i na ile.
Po podłączeniu FireMon do środowiska – w ciągu kilku dni – obraz stał się jasny:
Żaden z tych problemów nie był widoczny w standardowych raportach generowanych przed audytem. Wszystkie były ukryte w codziennych operacjach – jak cicha korozja pod farbą.
Ile reguł ma Twój firewall? Ile z nich stworzono w ciągu ostatnich dwunastu miesięcy? Ile ma przypisanego właściciela? Ile z nich jest faktycznie używanych – nie tylko „istnieje w bazie”?
Jeśli nie znasz odpowiedzi na te pytania – to właśnie jest problem, o którym mówi Gartner. Nie masz luki w oprogramowaniu. Masz lukę w widoczności własnych polityk bezpieczeństwa.
99% naruszeń firewalla wynika z błędów konfiguracji. Pierwszym krokiem do wyeliminowania tego ryzyka jest wiedza, co masz w swojej konfiguracji.
PANOPTICUM to podejście firmy VECTOR do budowania cyfrowej pewności w infrastrukturze sieciowej. Jako niezależny adwokat infrastruktury, dobieramy rozwiązania pod konkretny problem – nie pod ekosystem producenta. FireMon jest jednym z kluczowych elementów naszego stosu do zarządzania politykami bezpieczeństwa. Chcesz zobaczyć, co FireMon znajdzie w Twoim środowisku? Zaproponujemy analizę rulebase’u bez instalowania agentów w środowisku produkcyjnym.
