Czy Twoja firma jest gotowa na NIS2? 

Jak Network Expert i Elastic Security może w tym pomóc?

Dyrektywa NIS2 obejmie swoim zasięgiem niemal tuzin sektorów kluczowych, są to:

• Energetyka
• Bankowość i infrastruktura rynków finansowych
• Transport
• Ochrona zdrowia (w tym podmioty produkujące leki, wyroby medyczne, oraz oczywiście szpitale i placówki medyczne)
• Wodociągi i spółki wodno-kanalizacyjne
• Infrastruktura cyfrowa (między innymi dostawcy usług chmurowych, ośrodki przetwarzania danych, dostawcy punktu wymiany ruchu internetowego)
• Administracja publiczna
• Sektor przestrzeni kosmicznej
• Usługi ICT

Ponadto dyrektywa wymienia sektory ważne, są to:

• Usługi pocztowe i kurierskie
• Gospodarowanie odpadami
• Produkcja, wytwarzanie i dystrybucja chemikaliów
• Produkcja, przetwarzanie i dystrybucja żywności
• Produkcja, w bardzo szerokim zakresie m. in.:
  • Produkcja wyrobów medycznych i wyrobów medycznych do diagnostyki in vitro
  • Produkcja komputerów, wyrobów elektronicznych
  • Produkcja urządzeń elektrycznych
  • Produkcja maszyn i urządzeń
  • Produkcja pojazdów samochodowych, przyczep i naczep
  • Produkcja pozostałego sprzętu transportowego
• Dostawcy usług cyfrowych
• Organizacje badawcze

Czy Twoja firma znajduje się w jednym z tych sektorów? Jeżeli tak, to ten artykuł jest dla Ciebie.

Jeśli nie wiesz czym jest NIS2 warto przypomnieć czym jest… NIS i dlaczego na horyzoncie pojawia się druga wersja tej dyrektywy.

Co to jest NIS i dlaczego czas na zmiany?

NIS, czyli Network and Information Systems Directive, jest ustawą skupiającą się na bezpieczeństwie sieci, na poprawie zdolności w zakresie cyberbezpieczeństwa na poziomie krajowym, powoływaniu odpowiednich organów jak CSIRT. Punktów jest więcej, natomiast koniec końców celem jest poprawa bezpieczeństwa podmiotów publicznych i prywatnych w wielu kluczowych sektorach. Co jest zatem nie tak z NIS?

Źródło: Elastic

Wg. danych firmy Elastic aż 35% organizacji w całej Unii Europejskiej będącymi operatorami usługi kluczowej zgłasza istnienie niejasnych oczekiwań w zakresie różnych wymagań NIS. Ustawa o Krajowym Systemie Cyberbezpieczeństwa (która jest polską implementacją unijnego NIS) narzuca na organizacje wiele obowiązków, które opisane są w Artykule 8 w/w ustawy.

Można tam znaleźć zapisy takie jak:

• wdrożenie odpowiednich i proporcjonalnych do oszacowanego ryzyka środków technicznych i organizacyjnych;
• objęcie systemu informacyjnego […] systemem monitorowania w trybie ciągłym;
• stosowanie środków zapobiegających i ograniczających wpływ incydentów na bezpieczeństwo;

Zauważyłem, że jednym z największych wyzwań, które stoją przed organizacjami, jest objęcie monitorowania systemów w trybie ciągłym, tj. całodobowo. Stosowanie środków zapobiegających również jest zadaniem proaktywnym. Braki kadrowe sprawiają, że niekiedy jest to niemal niewykonalne. Często dostajemy zapytania o outsourcing takiej usługi – nasz SOC może pomóc w spełnieniu tego wymogu – Security Operations Center.

Oczywiście bardzo trudne jest oszacowanie proporcjonalnych środków technicznych i organizacyjnych względem oszacowanego ryzyka. O zasadach zarządzania ryzykiem w kontekście bezpieczeństwa możemy mówić odnosząc się do norm międzynarodowych. Jedna z najpopularniejszych, jak nie najpopularniejsza to norma ISO/IEC 27001. Znowu – szacowanie ryzyka to całościowy, bardzo drobiazgowy proces identyfikacji, podzielony na różne etapy.

Na przykładzie niedawnego ataku na firmę ALAB (o czym w dalszej części artykułu) można wdrożyć naprawdę całe spektrum środków zabezpieczających, a i tak paść ofiarą ataku. Według przytaczanego przez firmę Elastic raportu „2020 ENISA Investments Report” podmioty skarżą się na to, że NIS nie mówi wprost w jaki sposób mają wdrażać zabezpieczenia oraz jakie one mają w ogóle być. Podmioty chcąc spełnić wygórowane oczekiwania podchodzą do audytów – które jak się potem okazuje i o czym napisałem – nie zawsze zwracają szczegółową uwagę na to JAK zabezpieczenia zostały wdrożone, a ILE. Compliance =/= security, zapamiętajcie.

Czy NIS2 jest receptą na całe zło?

Unia Europejska reagując na te i inne wyzwania wprowadza dyrektywę NIS2, która zacznie obowiązywać od października 2024.

Jakie są różnice pomiędzy NIS a NIS2?

1. Przede wszystkim dodanych zostało więcej sektorów w zależności od tego, jak istotne są dla danego państwa członkowskiego.
2. Wymagania dotyczące zgłaszania incydentów zostały bardziej precyzyjnie opisane.
3. Środki nadzorcze dla organów krajowych staną się bardziej rygorystyczne.

Teoretycznie NIS2 ma być bardziej „sztywny” i ma nie pozwalać na zmiany interpretacyjne w konkretnych państwach. Zmiany pewnie będą – polskiej interpretacji NIS2 jeszcze nie ma, nie jest wciąż do końca pewne kto i do jakiej kategorii wejdzie (poza tymi krytycznymi, które już w NIS1 są).

Securewashing

Jest to stworzenie fałszywego przeświadczenia na temat zdolności cybernetycznej poprzez zbytnią ufność i wiarę w mechanizmy, procedury i skonfigurowane systemy.

Czy na przykładzie niedawnego ataku na firmę ALAB można mówić o securewashingu? Moim zdaniem nie. Portal Z3S pisał o wdrożonych zabezpieczeniach przez tę firmę – pozwólcie, że zacytuję stronę:

Źródło cytatu: Co stało się w ALAB-ie, czyli jakie zabezpieczenia nie chronią przed hakerami, Zaufana trzecia strona

Bardzo spodobał mi się cytat-przytyk redaktora: „co prawda przyczyniłem się do wypadku o poważnych skutkach, ale przynajmniej jechałem samochodem bezpiecznej marki”.

Może się zdarzyć, że organizacja zechce dążyć do zapewnienia zgodności z NIS1/KSC ponieważ jest ona namacalna, zasadniczo łatwo ją osiągnąć, wykazać że osiągnęła ją wdrażając klaster firewalli, system ochrony poczty czy IPS/IDS. Co z tego, że wdrożymy IPS-a, skoro 80% ruchu przechodzącego przez internet jest szyfrowane, a nie posiadamy niczego co mogłoby w stanie ten ruch deszyfrować? Każdy taki system będzie zwyczajnie ślepy na realne zagrożenie, jeśli będzie to HTTPS albo DNSSEC. Niemniej przed instytucjami audytującymi łatwo jest wykazać koszty i poniesiony nakład – dobrze postarawszy się można dostać nawet ISO27001 machając fakturami i krzycząc „o, zobaczcie jak dużo wydajemy i inwestujemy w cyberbezpieczeństwo!”

fot: Kadr z filmu „Kiler-ów 2-óch” reż. Juliusz Machulski, 1999

Nie do końca. Przede wszystkim wdrażanie systemów bezpieczeństwa należy zostawiać specjalistom od bezpieczeństwa. To znaczy, nie chcę się kłócić, compliance jest bardzo ważny, ale compliance =/= security. I niestety osoby od compliance często nie mają pojęcia o bezpieczeństwie…

Elastic Security na pomoc

Poza narzekaniem chciałem poruszyć temat w jaki sposób Network Expert we współpracy z Elastic Security może pomóc w poprawnej implementacji NIS2. Skupię się na Artykule 21 – są to środki zarządzania ryzykiem w cyberbezpieczeństwie. Jego zapisy są bardzo podobne względem aktualnej ustawy o KSC, czyli – podejmowanie odpowiednich i proporcjonalnych środków technicznych w celu zarządzania bezpieczeństwem.

Źródło: Elastic

Zacznijmy od punktu B, czyli incident handling. Elastic Security oferuje bardzo rozbudowany moduł Detection Engine umożliwiający wykorzystanie Machine Learningu, prekonfigurowanych reguł detekcyjnych, workflowów składających się z eventów pochodzących z różnych źródeł (firewalle, systemy ochrony poczty, IPS, proxy, Windowsy, Linuxy itd.), zewnętrzne źródła threat intelligence (np. open-source’owe Abuse.CH czy OTX). Ponadto Elastic Security oferuje narzędzia do wizualizacji, korelowania, analizowania, tworzenia timeline’ów czy eskalowania alertów oraz odpowiedzi na nie, co jest bardzo przydatne zwłaszcza zespołom SOC/IRT.

Źródło: Elastic

Elastic umożliwia zbieranie przykładowo zapytań DNS pochodzących z endpointów oraz flowów, można zauważyć wiele przydatnych informacji takich jak rodzaj zapytania, serwer DNS odpowiadający na te zapytania oraz czego to zapytanie dotyczyło. Informacje te umożliwiają tworzenie reguł pozwalających zapobieganiu atakom na protokół, w tym tunelowanie czy spoofing DNS.

Elastic zapewnia także różne sposoby gromadzenia i wzbogacania danych za pomocą zewnętrznych źródeł informacji. Feedy, które można uzyskać z różnych źródeł zarówno open-source’owych jak i komercyjnych dostarczają ogromną ilość informacji na temat zagrożeń – wyróżniamy przede wszystkim hashe plików, adresy IP, FQDN-y itd. – ogólnie określane jako indicators of compromise (IOC) – a takie informacje odgrywają bardzo ważną rolę w SOC.

Źródło: Elastic

Gdy zostanie wygenerowany alert, Elastic wyświetla informacje analitykowi w bardzo przystępnej formie, które zawiera podsumowanie alertu.

Źródło: Elastic

Źródło: Elastic

Punkt E odnosi się bezpośrednio do wdrażania, rozwoju i utrzymywania systemów, jest to także obsługa luk w zabezpieczeniach. O ile Elastic Security nie wdroży firewalla, tak jest w stanie pobrać z nich logi.

Źródło: Elastic

Mamy możliwość pobrania logów do Elastic Security za pomocą ogromnej liczby integracji, moim zdaniem najpopularniejsze to między innymi:

• Cisco (w tym urządzenia sieciowe, firewalle, produkty Cisco Security jak np. Umbrella, Cisco for Endpoint, Email Secure itd.)
• Fortinet
• Palo Alto
• F5
• OS’y Windows, Linux, MacOS
• Produkty chmurowe takie jak AWS, GCP czy MS Azure
• Kontenery
• Netflowy, logi z DNS-ów, DHCP itd.
• Możliwość wydajnej obsługi pełnej kopii ruchu (!)
• Nessus czy Rapid7 (dla obsługi luk w zabezpieczeniach)
• Źródła threat intelligence wspomniane wyżej

Pełna lista integracji dostępna jest pod elastic.co/integrations.

Wróciwszy do punktu Incident Handling uznaję, że bogatość źródeł danych wzbogaca w sposób znaczący możliwości narzędzi detekcyjnych opisanych wyżej. Czy jest to produkt gotowy po wyjęciu z pudełka? Moim zdaniem nie – ale żaden taki nie będzie, każde środowisko jest inne, natomiast dużą przewagą jest to, że zespoły SOC/IRT mogą układać te klocki pod swoje potrzeby i środowiska na którym pracują.

Punkt F Artykułu 21 dotyczy polityk i procedur oceny skuteczności zarządzania ryzykiem. Elastic Security wykorzystuje framework MITRE ATT&CK w celu modelowania zagrożeń – jest po prostu zbiorem wiedzy o zachowaniach atakujących, które są pogrupowane w postaci „matryc” taktyk i technik, począwszy od rekonesansu (np. skanowanie wykryte przez IPS) poprzez atak (initial access/execution – np. phishing wykryty przez system bezpieczeństwa poczty itd.) skończywszy na eskalacji uprawnień do praw administratora, zestawionym kanale C&C, eskfiltracji ważnych danych, zaszyfrowaniu dysków i usunięciu śladów.

Źródło: Elastic

Dla dociekliwych polecam film wyjaśniający w szczegółach czym jest MITRE ATT&CK.

Moim zdaniem idealistycznie MITRE ATT&CK można użyć w następujących środowiskach:

• Enterprise – środowiska wykorzystujące systemy Windows, Linux czy MacOS.
• Cloud – taktyki i techniki stosowane na platformach takich jak AWS, GCP, Azure, Office i ogólnie SaaS.
• Mobile – iOS i Android.
• ICS – techniki które można stosować w atakach ukierunkowanych na systemy OT.

Podsumowanie

Wiele przedsiębiorstw niezobowiązanych pierwszą iteracją ustawy o KSC może wpaść do dużego worka sektorów kluczowych i ważnych. NIS2 może wywrócić postrzeganie bezpieczeństwa do góry nogami. Bezpieczeństwo jest jak LEGO – z nami to proste, bo znamy instrukcję na pamięć i umiemy w te klocki 😊