NIS2 bezpieczna komunikacja: połowa art. 21(2)(j), którą większość programów pomija

Między lutym a czerwcem 2026 r. Sophos śledził kampanię, którą nazywa STAC4749. Atakujący założyli konta Microsoft Teams na domenach o „informatycznych" nazwach, dzwonili do pracowników podając się za helpdesk i namawiali ich do otwarcia sesji Quick Assist. Co najmniej trzy z tych włamań zakończyły się ransomware Chaos. Jedno przeszło od pierwszej rozmowy w Teams do zaszyfrowanych plików w niecałe 17 godzin.

Zastanówcie się teraz, czego te organizacje użyły do koordynacji reakcji. Teams. Outlook. Tego samego tenanta, do którego atakujący już wszedł.

To właśnie problem, który mają rozwiązać wymogi NIS2 dotyczące bezpiecznej komunikacji. Art. 21(2)(j) to środek, który go obejmuje, i jest to ta połowa artykułu, której większość programów zgodności nigdy nie wdraża.

Art. 21(2)(j) ma dwie połowy, a większość programów buduje tylko jedną

Brzmienie dyrektywy jest krótkie: „stosowanie uwierzytelniania wieloskładnikowego lub ciągłego, zabezpieczonej komunikacji głosowej, wideo i tekstowej oraz zabezpieczonych systemów łączności alarmowej w obrębie podmiotu, w stosownych przypadkach".

Wszyscy czytają pierwszą część. MFA dostaje budżet, projekt i wiersz w raporcie dla zarządu. Na początku roku wyjaśniliśmy, dlaczego samo MFA nie przechodzi już audytu.

Druga część jest ignorowana. Zawiera dwa odrębne obowiązki: zabezpieczyć codzienne kanały głosowe, wideo i tekstowe oraz mieć system łączności awaryjnej, który nadal działa, gdy kanały codzienne przestają.

„W stosownych przypadkach" to nie furtka. To kwalifikator oparty na ryzyku. Jeśli uznacie, że dany środek nie jest stosowny, decyzja musi znaleźć się w ocenie ryzyka wraz z uzasadnieniem. Audytor traktuje milczenie jako lukę, nie jako decyzję.

Artykuł 21 — 10 Środków Cyberbezpieczeństwa NIS2
🛡️
Artykuł 21
10 Środków Cyberbezpieczeństwa
📊Zarządzanie & Strategia
1Analiza ryzyka & polityki bezpieczeństwa informacji
6Ocena skuteczności środków bezpieczeństwa
🚨Incydenty & Ciągłość
2Obsługa incydentów & zgłaszanie
3Ciągłość działania & odtwarzanie po awarii
🔗Łańcuch Dostaw & Systemy
4Bezpieczeństwo łańcucha dostaw
5Bezpieczeństwo w rozwoju systemów sieciowych i informatycznych
🔐Kontrole Techniczne
8Kryptografia & szyfrowanie
10Uwierzytelnianie wieloskładnikowe & bezpieczna komunikacja
👥Ludzie & Zasoby
7Cyberhigiena & szkolenia
9Bezpieczeństwo HR & kontrola dostępu

Rozporządzenie wykonawcze rozprasza wymóg po pięciu sekcjach

Rozporządzenie wykonawcze Komisji (UE) 2024/2690 to szczegółowy zbiór zasad dla infrastruktury cyfrowej, zarządzania usługami ICT i dostawców usług cyfrowych. Oznacza to, że MSP i MSSP podlegają mu bezpośrednio. Organy krajowe w innych sektorach używają go jako punktu odniesienia dla tego, co znaczy „stosowne".

Nie ma w nim sekcji zatytułowanej „bezpieczna komunikacja". Kto jej szuka, dojdzie do wniosku, że obowiązek jest wątły. Nie jest. Jest rozproszony:

Punkt 3.5.3 wymaga planów i procedur komunikacji w ramach reagowania na incydenty: z CSIRT lub właściwym organem, między własnymi pracownikami oraz z zewnętrznymi interesariuszami.

Punkt 4.1.2(c) wymaga, aby plan ciągłości działania i odtwarzania po awarii zawierał kluczowe kontakty oraz wewnętrzne i zewnętrzne kanały komunikacji.

Punkt 4.2.4(d) wymaga co najmniej częściowej redundancji „odpowiednich kanałów komunikacji", obok redundancji systemów, obiektów i personelu.

Punkt 4.3.2(b) wymaga, aby proces zarządzania kryzysowego określał środki komunikacji z właściwymi organami, zarówno dla zgłoszeń obowiązkowych, jak i wymiany nieobowiązkowej.

Punkty 6.7.2(i) i (k) wymagają zaufanych, odizolowanych kanałów między systemami oraz planu wdrożenia nowoczesnych standardów komunikacji e-mail.

Punkt 11.7 obejmuje połowę dotyczącą MFA.

Praktyczna konsekwencja: audytor nie zapyta „czy macie bezpieczną komunikację?". Poprosi o procedurę reagowania na incydenty, plan BC/DR i proces zarządzania kryzysowego, i w każdym z nich będzie szukał kanału komunikacji. Jeśli we wszystkich trzech odpowiedź brzmi „e-mail i Teams", ustalenie pisze się samo.

Wasza reakcja na incydent działa na systemie, w którym siedzi atakujący

Załóżcie kompromitację. To nie paranoja, to udokumentowane zachowanie.

Microsoft i CISA opisują, jak Octo Tempest, lepiej znany jako Scattered Spider, przeszukuje Slacka, Teams i Exchange Online ofiary w poszukiwaniu rozmów o własnym włamaniu i dołącza do rozmów zespołu reagowania, żeby dowiedzieć się, jak obrońcy go tropią. W czerwcu 2026 r. zaobserwowano afiliantów DragonForce kierujących ruch command-and-control przez legalne przekaźniki Microsoft Teams, aby wtopić się w normalny ruch narzędzi do współpracy.

Jeśli atakujący ma uprzywilejowane konto Entra ID, każdy kanał uwierzytelniający się w Entra ID jest dla niego czytelny. Łącznie z „zapasowym" kanałem Teams, który utworzyliście dla sztabu kryzysowego.

System łączności awaryjnej przechodzi trzy testy:

Odrębna tożsamość. Nie uwierzytelnia się przez wasz główny dostawca tożsamości. Jeśli SSO was wpuszcza, skompromitowane SSO wpuszcza atakującego.

Odrębna infrastruktura. Nie jest hostowany w tym samym tenancie, na tej samej domenie ani za tym samym DNS, który być może trzeba będzie wyłączyć.

Przygotowany z wyprzedzeniem i przećwiczony. Lista kontaktów istnieje offline, konta istnieją przed incydentem, a kanał został użyty w teście. Punkt 4.1.4 wymaga testowania planów BC/DR w zaplanowanych odstępach. Kanał awaryjny jest częścią tego planu, więc jest częścią tego testu.

W praktyce nie jest to drogie. Grupa na Signalu lub Threemie na urządzeniach zarządzanych przez MDM, z kontami niepowiązanymi z firmowym SSO. Wydrukowana karta kontaktów w segregatorze kryzysowym. Awaryjna skrzynka pocztowa u innego dostawcy. Koszt nie tkwi w narzędziu. Koszt tkwi w dyscyplinie utrzymywania go w aktualności.

Jeszcze jeden pomijany szczegół: wczesne ostrzeżenie w ciągu 24 godzin z art. 23 musi dotrzeć do waszego CSIRT nawet wtedy, gdy to właśnie wasz serwer pocztowy nie działa. Dane kontaktowe przekazane krajowemu rejestrowi podmiotów przy rejestracji to te, których CSIRT użyje, żeby do was oddzwonić. Jeśli to skrzynka w skompromitowanym tenancie, macie problem ze zgłoszeniem na dodatek do problemu z bezpieczeństwem. Procedura obsługi incydentów powinna wprost wskazywać zapasową ścieżkę do CSIRT.

Harmonogram Zgłaszania Incydentów NIS2
24h
⚡Wczesne Ostrzeżenie
Powiadom właściwy organ (CSIRT/KNB) w ciągu 24 godzin od uzyskania informacji o znaczącym incydencie.
Krok 1
72h
📋Zgłoszenie Incydentu
Złóż szczegółowe zgłoszenie w ciągu 72 godzin z wstępną oceną powagi, wpływu i wskaźników naruszenia bezpieczeństwa.
Krok 2
1mo
📊Raport Końcowy
Dostarcz kompleksowy raport końcowy w ciągu jednego miesiąca obejmujący przyczynę źródłową, podjęte działania naprawcze i wpływ transgraniczny.
Krok 3
24h
⚡Wczesne Ostrzeżenie
Powiadom właściwy organ (CSIRT/KNB) w ciągu 24 godzin od uzyskania informacji o znaczącym incydencie.
72h
📋Zgłoszenie Incydentu
Złóż szczegółowe zgłoszenie w ciągu 72 godzin z wstępną oceną powagi, wpływu i wskaźników naruszenia bezpieczeństwa.
1mo
📊Raport Końcowy
Dostarcz kompleksowy raport końcowy w ciągu jednego miesiąca obejmujący przyczynę źródłową, podjęte działania naprawcze i wpływ transgraniczny.

NIS2 bezpieczna komunikacja to standard konfiguracji, a nie zakup produktu

Teams, Google Meet i Zoom szyfrują w transporcie. Nikt nie oblewa audytu dlatego, że jego rozmowy wideo są nieszyfrowane. Pytanie, które rozporządzenie naprawdę zadaje, brzmi: kto może dotrzeć do waszych ludzi, jakimi kanałami i pod jakimi kontrolami?

Przełóżcie to na konkretne ustawienia, a obraz staje się jasny.

Dostęp zewnętrzny. STAC4749 i wcześniejsza kampania Black Basta opierały się na tym, że zewnętrzne konta Teams mogły pisać do pracowników i do nich dzwonić. Ograniczenie federacji zewnętrznej do listy dozwolonych domen partnerów albo zablokowanie zewnętrznych czatów i połączeń dla większości użytkowników usuwa punkt wejścia. Punkt 6.7.2(c) już wymaga zapobiegania komunikacji sieciowej niepotrzebnej do działania. To wersja tej reguły dla warstwy współpracy.

Uwierzytelnianie poczty. Punkt 6.7.2(k) wymaga planu wdrożenia „uzgodnionych na szczeblu międzynarodowym i interoperacyjnych nowoczesnych standardów komunikacji e-mail". Wytyczne techniczne ENISA z czerwca 2025 r. wskazują SPF, DKIM i DMARC do uwierzytelniania nadawcy oraz MTA-STS lub DANE do szyfrowania transportu. Rekord DMARC z p=none to monitoring, nie ochrona. Audytorzy nauczyli się tej różnicy.

Zatwierdzone narzędzia według klasyfikacji. Wasza polityka kryptograficzna z art. 21(2)(h) powinna określać, które narzędzia komunikacji i wideokonferencji są zatwierdzone dla którego poziomu klasyfikacji aktywów. Zarząd omawiający incydent na WhatsAppie na prywatnych telefonach to ustalenie audytowe, bo żadna polityka na to nie pozwala i żadna kontrola tym nie zarządza.

Higiena spotkań. Włączona poczekalnia, uwierzytelnione dołączanie do spotkań wewnętrznych, udostępnianie ekranu i nagrywanie tylko przez gospodarza oraz zasada, że nikt na rozmowie kryzysowej nie jest anonimowy.

Głos. Trunki SIP i VoIP przez TLS i SRTP oraz, w lokalizacjach, gdzie to istotne, możliwość połączeń alarmowych niezależna od działania sieci firmowej.

Nic z tego nie wymaga zakupu nowego produktu. Wszystko wymaga kogoś, kto odpowiada za konfigurację i potrafi wyeksportować dowody.

O co audytor naprawdę poprosi

Organy nadzoru zaczęły prosić o pakiety dowodów zamiast deklaracji polityk. Ogólną listę dowodów omówiliśmy dwa tygodnie temu. Dla art. 21(2)(j) spodziewajcie się tych ośmiu elementów:

Sekcja komunikacji w procedurze reagowania na incydenty, wskazująca kanały podstawowe i zapasowe wraz z właścicielami.
Sekcja kluczowych kontaktów i kanałów w planie BC/DR, datowana w bieżącym cyklu przeglądu.
Oświadczenie o redundancji kanałów komunikacji zgodnie z punktem 4.2.4(d).
Zapis testu pokazujący, że kanał awaryjny został użyty podczas ćwiczenia.
Eksport konfiguracji dostępu zewnętrznego w Teams lub Google Workspace.
Rekordy DNS dla DMARC, MTA-STS i, jeśli używane, DANE.
Lista zatwierdzonych narzędzi komunikacji powiązana z poziomami klasyfikacji aktywów.
Wpisy w ocenie ryzyka uzasadniające ewentualne decyzje „niestosowne".

Jeśli możecie dostarczyć wszystkie osiem w jeden dzień, ten środek macie zamknięty. Jeśli możecie dostarczyć trzy, wiecie, gdzie zaczyna się analiza luk.

Dla MSP ten środek obowiązuje podwójnie

MSP to podmiot zarządzania usługami ICT w rozumieniu załącznika I NIS2. Rozporządzenie 2024/2690 ma do niego zastosowanie bezpośrednio. To wasz własny obowiązek.

Potem jest strona klienta. Polityka bezpieczeństwa łańcucha dostaw każdego klienta z punktu 5.1 ma oceniać praktyki cyberbezpieczeństwa jego dostawców usług. Wasza zdolność do komunikacji z klientem podczas incydentu, kanałem, który nie jest ani skompromitowanym tenantem klienta, ani waszym skompromitowanym tenantem, jest jedną z tych praktyk.

Przećwiczcie ten scenariusz: wasz RMM lub tenant M365 jest skompromitowany. Czterdziestu klientów musi się o tym dowiedzieć w ciągu kilku godzin. Wasza poczta jest właśnie tym, co zostało skompromitowane. Jaka jest lista, gdzie leży i kto ma ją na telefonie, który nie synchronizuje się z firmowym SSO?

Jeśli nie ma odpowiedzi, to pierwszy punkt waszego własnego planu naprawczego. Holenderska Cyberbeveiligingswet obowiązuje od 15 sierpnia 2026 r., a RDI nadzoruje zarządzanie usługami ICT bezpośrednio. Niemieckie BSI i belgijskie CCB robią to od dłuższego czasu. Podwójny obowiązek MSP nie jest już teorią na żadnym z tych rynków.

Eskalacja sankcji NIS2 — Poza karą finansową
!
Zdarzenie wyzwalające
Wykryto niezgodność lub wystąpił incydent
Organ nadzorczy identyfikuje lukę w zgodności lub organizacja nie spełnia wymagań NIS2
Organy mogą nałożyć▼
Sankcje niefinansowe
1
Nakazy zgodności z wiążącymi terminami
2
Obowiązkowe audyty bezpieczeństwa na Twój koszt
3
Publiczne ujawnienie naruszeń
4
Wiążące instrukcje dotyczące konkretnych środków bezpieczeństwa
Eskaluje do▼
Konsekwencje operacyjne i osobiste
1
Zawieszenie certyfikatów lub licencji operacyjnych
2
Tymczasowy zakaz pełnienia funkcji zarządczych dla osób
3
Publiczne wskazanie odpowiedzialnych osób fizycznych
Zdarzenie wyzwalające
Niefinansowe
Operacyjne / osobiste

Od czego zacząć w tym miesiącu

To nie projekt z komitetem sterującym. To cztery zadania.

Wybierzcie kanał awaryjny i go przygotujcie. Odrębna tożsamość, odrębna infrastruktura, lista kontaktów przechowywana offline.

Zapiszcie to. Dodajcie kanał do procedury reagowania na incydenty w punkcie 3.5.3 i do sekcji kluczowych kontaktów planu BC/DR w punkcie 4.1.2(c).

Zamknijcie drzwi frontowe. Ograniczcie federację zewnętrzną w Teams. Przełączcie DMARC na p=reject, gdy raporty potwierdzą waszych legalnych nadawców.

Przetestujcie. Pierwsza wiadomość w waszym następnym ćwiczeniu tabletop idzie wyłącznie kanałem awaryjnym. Jeśli nikt jej nie zobaczy, dowiedzieliście się czegoś ważnego w dogodnym momencie.

Jeśli chcecie wiedzieć, gdzie art. 21(2)(j) plasuje się obok pozostałych dziewięciu środków u konkretnego klienta, quick scan NIS2Certify obejmuje wszystkie dziesięć w około dziesięć minut i daje wam spriorytetyzowaną listę luk do pracy.