Architektura bezpieczeństwa na dobry początek

Data: 2020-06-09
Autor: Sebastian Konkol
Architektura bezpieczeństwa na dobry początek

Naruszenia bezpieczeństwa dotyczą najczęściej nie tych, którzy są uzbrojeni po zęby lecz tych, którzy są bezbronni – często na własne życzenie. Pracując w projektach IT obserwuję często „drogi na skróty”, także w sferze bezpieczeństwa. Najczęstsze samousprawiedliwienie – „ten projekt ma zrobić <to, czy tamto>, a nie naprawiać cały świat w zakresie bezpieczeństwa” – działa doskonale. Wszak, skoro nikt wcześniej nie zrobił tego „zgodnie i od początku do końca”, to „ja też nic nie muszę z tym zrobić”. W efekcie każdy projekt pogarsza sytuację, choć wystarczyłoby zachować minimalną higienę działania. I to naprawdę kosztem niewielkiego wysiłku.

Z bezpieczeństwem jest podobnie jak z jakością – to jest zadanie dla wszystkich i każdego. Naprawdę. Naturalnie, nie chodzi o to, aby każdy stał się ekspertem od bezpieczeństwa, lecz aby słuchał Kazika i „miał świadomość”. Bezpieczeństwa nie buduje się odgórnymi, czy centralnymi projektami bezpieczeństwa – zapewnia się je codziennymi działaniami w różnych sferach. Są takie działania, które powinny być ostoją dla rutynowego włączania zagadnień bezpieczeństwa, na elementarnym choćby poziomie:

  • Projektowanie infrastruktury. Strefy sieciowe służą nie tylko inżynierii ruchu – służą także do oddzielania podsieci o wyższym zaufaniu od stref o niższym zaufaniu, czy oddzielaniu grup systemów, które nie muszą się ze sobą komunikować (swoiste Need to Know). Już dawno nie ma podziału na Internet, DMZ i Intranet – stref bezpieczeństwa i segmentów sieci jest zwykle więcej i pełnią różne role. Czasy, kiedy urządzenia sieciowe to były switche i routery, wspomagane przez firewall, minęły. Dzisiaj standardowymi urządzeniami sieciowymi są IDS/IPS, Anti-DDoS, Content Filtering, WAF, Load Balancer na poziomie sieci i aplikacji. Na dziś to po prostu infrastruktura komunikacyjna, a nie fanaberie. W każdym projekcie należy ich po prostu użyć we właściwy sposób, nawet jeśli będzie to sposób domyślny.
  • Monitoring bezpieczeństwa. Dla mnie, jak dla każdego inżyniera telekomunikacji, monitoring sieci jest sprawą klasy oczywista oczywistość. Żaden bank nie próbuje swych sił bez monitoringu i wykrywania nadużyć. Żaden zakład produkcyjny nie działa bez automatyki przemysłowej. Prowadzenie ciągłego monitoringu bezpieczeństwa to element wbudowany w koszty posiadania informatyki, jak dyspozytor w logistyce. Do kanonu procesów zarządzania informatyką weszły zagadnienia operacji bezpieczeństwa, nadzoru nad działaniem nie tyle systemów co zdarzeń o charakterze bezpieczeństwa, identyfikacja incydentów na podstawie zdarzeń zdarzeń (w tym narzędzia klasy SIEM) oraz inicjowanie odpowiednich akcji. W każdym projekcie należy po prostu przekazać strumień zdarzeń do systemu klasy SIEM i pozwolić podziałać na tym specjalistom, choćby przy minimum wysiłku.
  • Platformy technologiczne. Ostatnie lata to gloryfikacja heterogeniczności. Każdy zespół ma sobie dobierać, jak mu wygodnie, byle tylko działało. MVP, MVA, prototypy, DevOps… Jak zawsze, cele są szczytne, a w praktyce, „na produkcji” zostają całe systemy działające na dawno już niewspieranych frameworkach i przestarzałych technologiach, nad którym to „bagażem” już nikt nie panuje (a zwykle nawet nie wie, że on jest). Nie namawiam do hegemonii compliance, bo  żeby biznes czynić bezpiecznym, biznes musi najpierw działać. Nie można jednak zaczynać każdego przedsięwzięcia od naszpikowania go ryzykiem, którego nikt nawet nie rozważa. Niech przyjmie to choćby formę przemyślenia wytworzenia kolejnej instancji technologii, a nie bezkrytyczne wprowadzenie zupełnie nowego, egzotycznego frameworku. Jak pomysłodawca przekona wszystkich do wykorzystania tego egzotycznego – super, bo będzie to przegadane i zostanie w pamięci. W każdym projekcie powinna być więc refleksja o wykorzystaniu wspólnych platform.
  • Zarządzanie oparte o analizę ryzyka. Działania oceniania ryzyka i zarządzać nim stały się już podstawą dla działań menedżerskich, wymaganą już nawet niektórymi regulacjami (jak RODO). Dla części branż aktywnie i świadomie zarządzanie oparte o ryzyko jest wymogiem regulacyjnym działalności podstawowe, dla pozostałych – zdrowym rozsądkiem. Jeśli nie ma klasyfikacji danych pomagającej ocenić ryzyko, warto przeprowadzić choć elementarną analizę, bo to zwykle oznacza inwestycję pojedynczych dni pracy (cały zespół). W każdym projekcie powinna przejść refleksja choćby nad najważniejszymi obiektami danych, ocena ekspozycji i potencjalnych konsekwencji dla systemu i procedur współdziałania z systemem, próba ograniczenia uprawnień zgodnie z zasadą Need to Know.

Oczywiste, prawda? Niestety jedynie w przypadku organizacji najbardziej świadomych zagadnień bezpieczeństwa (np. telekomunikacja) oraz takich, w których działalności silną rolę pełni regulator (np. bankowość). Średnia jest jednak zupełnie inna, nawet dla firm o obrotach liczonych w dziesiątkach czy setkach milionów złotych. Realizacja takich działań nie jest już na dziś wiedzą tajemną i stanowi raczej element dobrych praktyk. Pamiętajmy o jednym. Incydent bezpieczeństwa nie objawia się widowiskowo – to dopiero konsekwencje są takie. Gdyby zastosować analogię militarną, brak powyższych oznacza nie tylko brak obrony – oznacza przede wszystkim, że atakowany nie dowie się o tym, że został skutecznie (sic!) zaatakowany. Dowie się dopiero, jakie straty poniósł.

Wiedza o powyżej wspomnianych zagadnieniach jest powszechnie dostępna. Nie namawiam od razu do przejścia w tryb Zero Trust, a bezpieczeństwo w chmurze to już znacznie wyższa liga. Zacznijcie od mniejszych kroczków, od samych podstaw. Nie powiem, że „wystarczy chcieć”, ale bez wątpienia chcieć trzeba i warto. Możemy się jednak podzielić – Ty chcesz, ja mogę. Jak mogę pomóc?

Pozostaw komentarz