Nadzór nad osieroconymi rekordami DNS w kontekście NIS2, DORA i GDPR

Dyrektor ds. bezpieczeństwa informacji (CISO) otrzymuje wiadomość w poniedziałek o 07:12.

Badacz bezpieczeństwa znalazł promo.company.com, które wskazuje na porzuconą aplikację chmurową. Rekord DNS nadal działa. Zasób chmurowy już nie istnieje. Tenant SaaS, który kiedyś obsługiwał kampanię, został usunięty sześć miesięcy wcześniej, krótko po tym, jak marketing przeszedł na inną platformę. Nikt nie usunął rekordu CNAME.

O 08:30 pytanie nie brzmi już: „Czy ktoś może przejąć subdomenę?”. Brzmi: „Dlaczego nikt nie wiedział, że to aktywo istnieje?”.

O 09:15 w sprawę zaangażowany jest dział prawny, ponieważ subdomena kiedyś zbierała adresy e-mail na potrzeby listy oczekujących na produkt. Zaangażowany jest dział zakupów, ponieważ platformą kampanii zarządzała agencja. Zaangażowany jest zespół ds. zgodności, ponieważ spółka przygotowuje się do audytu nadzoru ISO/IEC 27001:2022, gotowości do NIS2 i kwestionariuszy zapewnienia dla klientów. IOD pyta, czy ekspozycja może stać się naruszeniem ochrony danych osobowych zgodnie z GDPR, jeżeli subdomena zostanie wykorzystana w ataku. CFO pyta, czy ta sama słabość może dotyczyć portalu płatności w regulowanym środowisku usług finansowych grupy.

Naprawa techniczna może zająć kilka minut. Problem nadzorczy może wymagać miesięcy porządkowania, jeżeli organizacja nie potrafi wykazać, że każde aktywo dostępne z Internetu jest znane, ma właściciela, podlega przeglądom, jest monitorowane i wycofywane w kontrolowanym procesie.

Dlatego osieroconych rekordów DNS i zapobiegania przejęciu subdomen nie można traktować jako wąskiego zadania porządkowania DNS. Nieaktualny rekord DNS jest często widocznym objawem głębszych nieskuteczności kontroli: niekompletnego inwentarza aktywów, słabej własności, brakujących dowodów wycofania z eksploatacji, niewystarczającego zarządzania zmianami, nieadekwatnego procesu zakończenia współpracy z dostawcą, niewystarczającego monitorowania zewnętrznej powierzchni ataku oraz niejasnej klasyfikacji incydentów.

Dla klientów Clarysec osierocony rekord DNS jest testem systemu zarządzania. Pokazuje, czy polityki, zabezpieczenia, rejestry, dowody i rozliczalność faktycznie działają, gdy zapomniana zależność chmurowa staje się okazją dla atakującego.

Co naprawdę oznaczają osierocone rekordy DNS

Przejęcie subdomeny staje się możliwe, gdy rekord DNS, często CNAME, wskazuje na zasób, który już nie istnieje albo nie jest już kontrolowany przez organizację. Jeżeli atakujący może przejąć lub odtworzyć zasób docelowy na platformie chmurowej albo SaaS, może być w stanie publikować treści pod zaufaną subdomeną organizacji.

Typowe przykłady obejmują:

• Rekord CNAME wskazujący na nieistniejącą usługę aplikacyjną w chmurze.
• Niestandardową nazwę hosta SaaS pozostawioną w DNS po anulowaniu subskrypcji.
• Dystrybucję CDN usuniętą z konsoli dostawcy, ale nadal wskazywaną w publicznym DNS.
• Marketingowy mikrosite wycofany przez agencję bez usunięcia rekordu DNS.
• Punkt końcowy pamięci masowej lub mapowanie statycznej strony internetowej, które można ponownie zarejestrować.
• Subdomenę deweloperską eksponowaną przez zapomniany projekt platform-as-a-service.

Wpływ biznesowy może być poważny. Atakujący mogą hostować strony phishingowe, przechwytywać dane uwierzytelniające, rozpowszechniać złośliwe oprogramowanie, nadużywać reputacji domeny, przechwytywać dane sesji albo szkodzić zaufaniu do marki. Jeżeli subdomena wcześniej przetwarzała dane osobowe, nawet krótkotrwałe przejęcie może uruchomić analizę naruszenia zgodnie z GDPR. Jeżeli dotknięta usługa wspiera regulowane operacje finansowe, incydent może również wymagać oceny w ramach DORA albo wewnętrznych ram zarządzania ryzykiem ICT.

Audytorzy coraz częściej traktują osierocone rekordy DNS jako dowód dojrzałości kontroli. Pojedynczy nieaktualny rekord może wskazywać, że organizacja nie wie, co posiada, kto jest właścicielem danego aktywa, jak przeglądane są zmiany, jak kończy się korzystanie z usług chmurowych ani jak monitorowane są aktywa dostępne z zewnątrz.

Dlatego Clarysec mapuje ten problem na oczekiwania audytowe ISO/IEC 27001:2022 ISO/IEC 27001:2022, ISO/IEC 27002:2022 ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST CSF 2.0 i COBIT 2019.

Dlaczego ISO 27001:2022 jest praktycznym fundamentem

Najmocniejszym sposobem nadzorowania osieroconych rekordów DNS nie jest tworzenie odrębnych programów dla NIS2, DORA i GDPR. Jest nim wykorzystanie ISO/IEC 27001:2022 jako fundamentu systemu zarządzania oraz jednokrotne tworzenie dowodów na potrzeby wielu wymagań zapewnienia.

Właściwe wymagania zaczynają się przed Załącznikiem A. Klauzule 4.1 do 4.4 wymagają, aby organizacja rozumiała swój kontekst, wymagania stron zainteresowanych, zakres SZBI oraz zależności od innych organizacji. W przypadku nadzoru nad osieroconymi rekordami DNS zakres powinien obejmować zewnętrzny DNS, domeny, rejestratorów, usługi chmurowe, platformy SaaS, agencje, hosting zarządzany, CDN oraz każdą stronę trzecią, która może tworzyć lub wycofywać usługi dostępne z Internetu.

Klauzule 5.1 do 5.3 czynią z tego zagadnienie przywództwa i rozliczalności. Kierownictwo musi dostosować SZBI do kierunku biznesowego, zapewnić zasoby, komunikować znaczenie bezpieczeństwa informacji i przypisać odpowiedzialności. Jeżeli marketing może uruchomić mikrosite, inżynieria może tworzyć punkty końcowe w chmurze, a zakupy mogą wypowiadać umowy SaaS, organizacja potrzebuje modelu ładu, który jasno przypisuje własność DNS i usług pomiędzy wszystkie te funkcje.

Klauzule 6.1.1 do 6.1.3 określają logikę oceny ryzyka, postępowania z ryzykiem oraz Deklaracji stosowania. Osierocony DNS powinien być ujęty jako realistyczny scenariusz ryzyka, a nie tylko wynik skanera. Wpływa na poufność, integralność i dostępność oraz często mapuje się na obowiązki prawne, regulacyjne i umowne.

Klauzule 7.5, 8.1, 8.2 i 8.3 przekształcają zarządzanie w dowody. Wymagają nadzorowanej udokumentowanej informacji, zaplanowanych i kontrolowanych procesów operacyjnych, uwzględnienia niezamierzonych zmian, kontroli procesów dostarczanych zewnętrznie, okresowych ocen ryzyka oraz udokumentowanych wyników postępowania z ryzykiem.

Załącznik A dostarcza następnie katalog zabezpieczeń. W projektach Clarysec podstawowe powiązania ISO/IEC 27002:2022 zwykle wyglądają następująco:

Wniosek jest prosty. ISO/IEC 27001:2022 nie wymaga jednorazowej, heroicznej akcji porządkowej. Wymaga kontrolowanego modelu operacyjnego, który zapobiega ponownemu wystąpieniu problemu.

Perspektywa Zenith Controls: jedno ryzyko, trzy kotwice kontrolne

W Zenith Controls: The Cross-Compliance Guide Zenith Controls Clarysec wykorzystuje właściwe zabezpieczenia ISO/IEC 27002:2022 jako kotwice mapowania zgodności między ramami. W przypadku nadzoru nad osieroconymi rekordami DNS i przejęciem subdomen kluczowe są trzy zabezpieczenia.

Zabezpieczenie 5.9, Inwentaryzacja informacji i innych powiązanych aktywów, jest klasyfikowane jako zapobiegawcze, wspiera poufność, integralność i dostępność, jest zgodne z koncepcją cyberbezpieczeństwa Identify oraz znajduje się w obszarze zarządzania aktywami jako zdolność operacyjna, z ładem, ekosystemem i ochroną jako domenami bezpieczeństwa.

Zabezpieczenie 5.23, Bezpieczeństwo informacji w korzystaniu z usług chmurowych, jest klasyfikowane jako zapobiegawcze, wspiera poufność, integralność i dostępność, jest zgodne z Protect oraz znajduje się w obszarze bezpieczeństwa relacji z dostawcami jako zdolność operacyjna, z ładem, ekosystemem i ochroną jako domenami bezpieczeństwa.

Zabezpieczenie 8.8, Zarządzanie podatnościami technicznymi, jest klasyfikowane jako zapobiegawcze, wspiera poufność, integralność i dostępność, jest zgodne z Identify i Protect oraz znajduje się w obszarze zarządzania zagrożeniami i podatnościami jako zdolność operacyjna, z ładem, ekosystemem, ochroną i obroną jako domenami bezpieczeństwa.

Ma to znaczenie, ponieważ osierocony DNS nie jest wyłącznie nieskutecznością kontroli aktywów, wyłącznie nieskutecznością kontroli chmury ani wyłącznie podatnością. Jest wszystkimi tymi trzema elementami. Organizacja musi wykazać, że inwentarz aktywów, nadzór nad korzystaniem z chmury i zarządzanie podatnościami wzajemnie się wzmacniają.

Clarysec często dodaje praktyki wspierające wokół tych kotwic: ISO/IEC 27005 dla dyscypliny oceny ryzyka i postępowania z ryzykiem, ISO/IEC 27017 dla ładu bezpieczeństwa usług chmurowych, ISO/IEC 27018 tam, gdzie usługi chmurowe przetwarzają PII, ISO/IEC 27701 dla systemu zarządzania informacjami o prywatności oraz ISO 22301 tam, gdzie istotne są ciągłość działania i reakcja kryzysowa.

Dowody z polityk, które już wymagają kontroli cyklu życia DNS

Wiele organizacji ma już polityki, które przy prawidłowym wdrożeniu zapobiegałyby osieroconym rekordom DNS. Luka polega na tym, że kontrola cyklu życia DNS nie jest wyraźnie powiązana z tymi politykami.

Asset Management Policy-sme - SME Clarysec Asset Management Policy-sme - SME, Wymagania dotyczące wdrożenia polityki, klauzula 6.6.1 stanowi:

Aktywa oparte na chmurze, takie jak konta pamięci masowej, platformy SaaS i domeny internetowe, muszą również zostać uwzględnione w inwentarzu.

Ta sama polityka dodaje w klauzuli 6.6.2:

Własność, cel, uprawnienia dostępu i terminy odnowienia muszą być udokumentowane.

Dla nadzoru nad osieroconymi rekordami DNS oznacza to, że każda subdomena produkcyjna oraz istotna subdomena nieprodukcyjna powinna mieć wskazanego właściciela, cel biznesowy, powiązaną usługę, model dostępu i datę przeglądu.

Najważniejsze jest jednak to, że klauzula 6.6.3 stanowi:

Usługi wygasłe lub nieużywane muszą zostać dezaktywowane i usunięte z inwentarza.

W przypadku DNS należy interpretować to ostrożnie. Samo usunięcie usługi z inwentarza nie wystarczy. Należy również przejrzeć rekord DNS, powiązanie chmurowe, roszczenie do domeny niestandardowej SaaS, certyfikat, regułę WAF, konfigurację CDN oraz wpis monitorowania.

Wersja dla przedsiębiorstw wzmacnia szersze rozumienie aktywów. Asset Management Policy Clarysec Asset Management Policy, Zakres, klauzula 2.2.5 stanowi:

Aktywa logiczne: nazwy domen, licencje, konta użytkowników, konfiguracje bazowe.

Nazwy domen i konfiguracje nie są administracyjnymi detalami. Są aktywami przenoszącymi zaufanie, które mogą stać się ścieżkami ataku.

Równie ważne jest powiązanie z kontrolą zmian. Change Management Policy Clarysec Change Management Policy, Cel, klauzula 1.1 stanowi:

Niniejsza polityka ustanawia formalne ramy inicjowania, oceniania, zatwierdzania, wdrażania i przeglądu zmian w systemach informatycznych, infrastrukturze, aplikacjach i powiązanych procesach organizacji.

Usunięcie DNS, zakończenie SaaS, usunięcie aplikacji chmurowej, migracja CDN albo wycofanie marketingowego mikrosite powinny zatem generować dowody zmiany. Brak zgłoszenia zmiany jest często pierwszym sygnałem ostrzegawczym podczas audytu.

Należy również powiązać nadzór nad chmurą. Cloud Usage Policy Clarysec Cloud Usage Policy, Wymagania dotyczące ładu, klauzula 5.5 stanowi:

Zespół ds. bezpieczeństwa informacji musi rutynowo oceniać ruch sieciowy, aktywność DNS i logi w celu wykrywania nieautoryzowanego korzystania z chmury, czyli shadow IT. Wykryte naruszenia muszą być niezwłocznie badane.

W zapobieganiu przejęciom subdomen monitorowanie aktywności DNS nie dotyczy wyłącznie shadow IT. Dotyczy również „stale IT”, czyli aktywów, które kiedyś były autoryzowane, ale nie są już kontrolowane.

Praktyczny przepływ pracy Clarysec dla nadzoru nad osieroconymi rekordami DNS

Skuteczny program nadzoru nad osieroconymi rekordami DNS nie jest skomplikowany. Musi być zdyscyplinowany, powtarzalny i powiązany z SZBI, zarządzaniem podatnościami, zarządzaniem zmianami oraz cyklem życia dostawcy.

W MŚP może to zaczynać się od uproszczonego rejestru. W przedsiębiorstwach zwykle integruje się eksporty DNS, zarządzanie zewnętrzną powierzchnią ataku, inwentarze aktywów chmurowych, zapisy CMDB, skanery podatności, alerty SIEM i systemy zgłoszeniowe.

Pytanie nadzorcze pozostaje takie samo: czy potrafisz wykazać, że każda subdomena osiągalna z zewnątrz jest znana, ma właściciela, jest monitorowana i może zostać usunięta w kontrolowanym procesie?

Porzucona subdomena kampanii obsłużona właściwie

Wróćmy do poniedziałkowego incydentu. promo.company.com wskazuje na porzuconą witrynę kampanii SaaS.

Po pierwsze, kierownik ds. bezpieczeństwa tworzy zapis podatności, ponieważ aktywo jest dostępne z zewnątrz. Vulnerability and Patch Management Policy Clarysec Vulnerability and Patch Management Policy, Wymagania dotyczące wdrożenia polityki, klauzula 6.1.1 stanowi:

Wszystkie systemy muszą być skanowane co najmniej raz w miesiącu; aktywa wysokiego ryzyka lub eksponowane zewnętrznie muszą być skanowane co tydzień.

W przypadku MŚP równoważna polityka wzmacnia priorytetyzację. Vulnerability and Patch Management Policy-sme - SME Vulnerability and Patch Management Policy-sme - SME, Wymagania dotyczące wdrożenia polityki, klauzula 6.5.1 stanowi:

Systemy, które przetwarzają dane osobowe, zapewniają dostęp zdalny albo są dostępne z zewnątrz, muszą być priorytetowo uwzględniane w skanowaniu i aktualizacjach.

Po drugie, właściciel jest identyfikowany przez rejestr aktywów. Jeżeli właściciel jest nieznany, staje się to nieskutecznością kontroli w zakresie nadzoru nad aktywami. Rejestr jest aktualizowany o nazwę DNS, dostawcę docelowego, pierwotnego właściciela biznesowego, klasyfikację danych, dostawcę i status.

Po trzecie, IT sprawdza platformę chmurową albo SaaS. Jeżeli konto chmurowe zostało usunięte, bezpośrednio istotna jest Cloud Usage Policy-sme - SME Clarysec Cloud Usage Policy-sme - SME, Wymagania dotyczące wdrożenia polityki, klauzula 6.3.6:

Usunięte konta chmurowe muszą zostać przejrzane przez dostawcę IT lub dyrektora generalnego (GM) pod kątem dostępu resztkowego, osieroconych danych albo przeoczonych treści.

Po czwarte, właściciel zmiany zgłasza zmianę awaryjną albo przyspieszoną, aby usunąć rekord DNS albo tymczasowo przejąć zasób przed jego usunięciem. Zgłoszenie obejmuje ocenę wpływu, plan wycofania zmian, zatwierdzenia, dowody wdrożenia i walidację po zmianie.

Po piąte, osoba odpowiedzialna za prywatność ocenia, czy subdomena przetwarzała albo mogła ujawnić dane osobowe. PII Security and Access Control Policy Clarysec PII Security and Access Control Policy, Bezpieczna konfiguracja i zarządzanie podatnościami, klauzula 4.7.4 stanowi:

[Oba przypadki] Właściciel systemu / właściciel aplikacji MUSI rejestrować pokrycie ocenami podatności dla systemów przetwarzających PII w REG12 co najmniej kwartalnie oraz po istotnej zmianie technicznej.

Klauzula 4.7.5 dodaje:

[Oba przypadki] Osoba odpowiedzialna za bezpieczeństwo informacji MUSI rejestrować nierozwiązane podatności wysokiego ryzyka dotyczące PII w REG12 w ciągu pięciu dni roboczych od walidacji.

Te klauzule mają zastosowanie niezależnie od tego, czy organizacja działa jako administrator, czy podmiot przetwarzający, ponieważ są oznaczone jako [Oba przypadki]. W przypadku problemu osieroconego DNS obejmującego PII dowody nie mogą znajdować się wyłącznie w zgłoszeniu technicznym. Muszą zostać odzwierciedlone w rejestrze dowodów podatności dotyczących PII.

Po szóste, jeżeli kampanię hostowała agencja albo dostawca SaaS, dział zakupów sprawdza zapisy dotyczące stron trzecich. Processor, Subprocessor and Third-Party Privacy Management Policy Clarysec Processor, Subprocessor and Third-Party Privacy Management Policy, Identyfikacja i klasyfikacja relacji, klauzula 4.1.2 stanowi:

[Wszystkie] Właściciel procesu / właściciel biznesowy MUSI zidentyfikować każdą proponowaną relację ze stroną trzecią, która będzie przetwarzać, uzyskiwać dostęp, otrzymywać, przechowywać, transmitować, wspierać albo w inny sposób wpływać na PII w REG08 przed zakupem, onboardingiem, odnowieniem albo istotną zmianą prywatności dotyczącą strony trzeciej.

Klauzula 4.5.5 wymaga:

[Oba przypadki] Właściciel dostawcy / zakupów MUSI rejestrować lokalizacje przetwarzania, lokalizacje hostingu i wskaźniki transferów międzynarodowych w REG08 oraz powiązać właściwe dowody transferu z REG09 przed zatwierdzeniem podmiotu przetwarzającego, podwykonawcy przetwarzania, zmiany lokalizacji albo zmiany usługi istotnej dla transferu.

Na koniec osoba odpowiedzialna za zgodność przygotowuje pakiet dowodów. Audit and Compliance Monitoring Policy Clarysec Audit and Compliance Monitoring Policy, Cele, klauzula 3.4 wskazuje, że jednym z celów jest:

Generowanie możliwych do obrony dowodów i ścieżki audytowej na potrzeby zapytań regulacyjnych, postępowań sądowych lub wniosków klientów o zapewnienie.

Taki wynik jest potrzebny CISO, gdy klient, organ regulacyjny albo audytor pyta: „Skąd wiecie, że to się nie powtórzy?”.

Gdzie pasuje Zenith Blueprint

Zenith Blueprint: An Auditor’s 30-Step Roadmap Clarysec Zenith Blueprint przekształca zabezpieczenia w praktyki operacyjne gotowe do audytu. Osierocone rekordy DNS silnie mapują się na cztery obszary.

W fazie Controls in Action krok 22 obejmuje zabezpieczenia organizacyjne 5.1 do 5.18, w tym zabezpieczenie 5.9 ISO/IEC 27002:2022. Zenith Blueprint stwierdza:

Żadna organizacja nie może chronić tego, o czym nie wie, że posiada. Zabezpieczenie 5.9 formalizuje tę fundamentalną zasadę, wymagając ustanowienia i utrzymywania aktualnego inwentarza wszystkich informacji i powiązanych aktywów istotnych dla SZBI.

Następnie dodaje:

W najbardziej strategicznej postaci inwentarz aktywów działa jak centralny układ nerwowy SZBI.

Inwentarz subdomen nie jest listą poboczną. Zasila decyzje dostępowe, skanowanie podatności, rejestrowanie, zarządzanie dostawcami, mapowanie prywatności i reagowanie na incydenty.

W kroku 20 Zenith Blueprint obejmuje zabezpieczenia techniczne 8.18 do 8.26. Dla zabezpieczenia 8.21, Bezpieczeństwo usług sieciowych, instruuje organizacje, aby walidowały bezpieczeństwo usług sieciowych:

Wypisz wszystkie wewnętrzne i zewnętrzne usługi sieciowe (DNS, VPN, SMTP, DHCP, bramy API itd.).

Dlatego dostawcy DNS, rejestratorzy, cloud DNS, platformy CDN oraz funkcje domen niestandardowych SaaS powinny znajdować się w rejestrze usług.

W kroku 19 Zenith Blueprint obejmuje zabezpieczenia techniczne 8.1 do 8.17. Dla zabezpieczenia 8.8 stwierdza:

Zarządzanie podatnościami jest jednym z najważniejszych obszarów nowoczesnej cyberhigieny. Chociaż zapory sieciowe i oprogramowanie antywirusowe zapewniają ochronę, mogą zostać osłabione, jeżeli niezałatane systemy lub błędnie skonfigurowane usługi pozostają eksponowane.

Osierocony rekord DNS jest błędnie skonfigurowaną zewnętrzną ścieżką do usługi. Nawet gdy nie ma CVE, powinien być obsługiwany w ramach zarządzania podatnościami: zweryfikuj, oceń, przypisz, napraw, przetestuj ponownie i zamknij.

W kroku 23 Zenith Blueprint odnosi się do zabezpieczeń organizacyjnych 5.19 do 5.37. Dla zabezpieczenia 5.23 zaleca:

Wypisz wszystkie usługi chmurowe aktualnie używane (5.23), w tym znane przypadki shadow IT. Ustal, kto je zatwierdził i czy przeprowadzono due diligence. Opracuj uproszczoną listę kontrolną oceny obejmującą lokalizację danych, model dostępu, rejestrowanie i szyfrowanie.

W celu zapobiegania przejęciu subdomen dodaj do tej listy oceny usług chmurowych domeny niestandardowe, zależności DNS, właściciela wycofania z eksploatacji oraz dowody wyjścia.

Mapowanie NIS2, DORA i GDPR

NIS2 sprawia, że nadzór nad osieroconymi rekordami DNS staje się kwestią na poziomie organu zarządzającego dla wielu podmiotów kluczowych i ważnych. Article 20 wymaga, aby organy zarządzające zatwierdzały środki zarządzania ryzykiem cyberbezpieczeństwa, nadzorowały ich wdrożenie oraz uczestniczyły w szkoleniach z cyberbezpieczeństwa. Article 21 wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych z wykorzystaniem podejścia opartego na wszystkich rodzajach zagrożeń. Minimalne obszary obejmują analizę ryzyka, obsługę incydentów, ciągłość działania, bezpieczeństwo łańcucha dostaw, bezpieczne nabywanie, rozwój i utrzymanie, obsługę podatności, ocenę skuteczności, cyberhigienę, szkolenia, kontrolę dostępu i zarządzanie aktywami.

Program dla osieroconych rekordów DNS mapuje się na te obszary wprost. Article 21(3) wymaga również, aby bezpieczeństwo łańcucha dostaw uwzględniało podatności specyficzne dla każdego bezpośredniego dostawcy lub dostawcy usług. Jeżeli agencja marketingowa, dostawca SaaS, dostawca hostingu zarządzanego albo platforma chmurowa zarządza domenami niestandardowymi, kontrole specyficzne dla dostawcy powinny obejmować własność DNS, wyjście z usługi, wsparcie incydentowe i przekazanie dowodów.

Article 23 ma znaczenie, jeżeli dochodzi do przejęcia albo istnieje możliwość spowodowania poważnego zakłócenia operacyjnego, straty finansowej albo znacznej szkody materialnej lub niematerialnej. NIS2 stosuje etapowe raportowanie: wczesne ostrzeżenie w ciągu 24 godzin od uzyskania wiedzy o znaczącym incydencie, zgłoszenie w ciągu 72 godzin, raporty pośrednie na żądanie oraz raport końcowy w ciągu miesiąca od zgłoszenia incydentu.

Dla podmiotów finansowych DORA jest sektorowym reżimem cyfrowej odporności operacyjnej. Articles 5 i 6 wymagają wewnętrznych ram ładu i kontroli dla zarządzania ryzykiem ICT, z ostateczną odpowiedzialnością organu zarządzającego, jasnymi rolami ICT, politykami dotyczącymi dostępności, autentyczności, integralności i poufności danych, planami audytów, zasobami, polityką usług stron trzecich oraz udokumentowanymi ramami zarządzania ryzykiem ICT.

Articles 8 do 14 tworzą rdzeń operacyjny. Article 8 wymaga identyfikacji, klasyfikacji i dokumentowania funkcji biznesowych wspieranych przez ICT, aktywów informacyjnych, aktywów ICT, zależności, połączeń ze stronami trzecimi ICT, inwentarzy, scenariuszy ryzyka i systemów legacy. Osierocony CNAME jest często przeoczoną zależnością. Article 9 wymaga ochrony i zapobiegania. Article 10 wymaga wykrywania anomalnej aktywności, incydentów związanych z ICT i potencjalnych pojedynczych punktów awarii. Articles 11 i 12 dotyczą ciągłości, odzyskiwania, kopii zapasowych i odtworzenia. Article 13 wymaga uczenia się na podstawie podatności, zagrożeń, incydentów i testów.

Articles 17 do 19 formalizują zarządzanie incydentami, klasyfikację i raportowanie. Articles 28 do 30 czynią ryzyko stron trzecich ICT procesem opartym na cyklu życia. Podmioty finansowe pozostają w pełni odpowiedzialne przy korzystaniu z dostawców usług ICT. Dla gotowości do DORA Clarysec zaleca dodanie czterech pól do każdego rejestru DNS i usług chmurowych: wsparcie funkcji krytycznej lub istotnej, dostawca zewnętrzny ICT, odniesienie do umowy lub rejestru oraz status testu wyjścia.

GDPR ma zastosowanie, gdy problem dotyczy danych osobowych. Przejęcie subdomeny nie jest automatycznie naruszeniem ochrony danych osobowych, ale może się nim stać, jeżeli dotknięta subdomena zbiera dane uwierzytelniające, przechwytuje dane z formularzy, podszywa się pod usługę, ujawnia identyfikatory użytkowników albo umożliwia nieuprawniony dostęp do danych osobowych. GDPR Article 5 wymaga integralności, poufności i rozliczalności. Article 32 wymaga odpowiedniego bezpieczeństwa przetwarzania. Article 33 może wymagać zgłoszenia organowi nadzorczemu, jeżeli naruszenie ochrony danych osobowych prawdopodobnie skutkuje ryzykiem naruszenia praw i wolności osób fizycznych.

PII Incident and Breach Management Policy Clarysec PII Incident and Breach Management Policy, Klasyfikacja i ocena naruszenia, klauzula 4.2.6 wspiera taką wieloreżimową analizę przesłanek zgłoszenia:

[Warunkowo] Osoba odpowiedzialna za prywatność / Menedżer PIMS MUSI ocenić właściwe przesłanki raportowania prawne, sektorowe, dotyczące sektora finansowego, cyberbezpieczeństwa, umowne, klienckie oraz dotyczące odbiorców usług dla każdego incydentu PII o istotnym wpływie oraz zarejestrować wynik stosowalności w REG01, REG08 i REG10.

Taki zapis decyzji jest dokładnie tym, czego potrzeba, gdy przejęcie subdomeny może obejmować GDPR, NIS2, DORA, umowy i powiadomienie klienta.

Jak audytorzy będą testować dowody

Zintegrowany SZBI powinien pozwalać odpowiadać różnym audytorom na podstawie tej samej bazy dowodowej. Brzmienie pytania się zmienia, ale dowód często jest ten sam.

Szersza perspektywa zapewnienia często obejmuje NIST CSF 2.0 i COBIT 2019. NIST CSF 2.0 pomaga wyrazić stan docelowy przez wyniki GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND i RECOVER. Profil bieżący może pokazywać ręczne kwartalne przeglądy DNS i niespójny offboarding SaaS. Profil docelowy może wymagać zautomatyzowanych cotygodniowych kontroli możliwości przejęcia, obowiązkowego przypisania właściciela, dowodów wyjścia dostawcy i integracji z zarządzaniem zmianami.

Audytor działający w podejściu COBIT 2019 albo ISACA zwykle zapyta, kto jest właścicielem procesu, jak ryzyko jest oceniane i kierowane, czy zmiany są kontrolowane, czy dostawcy są zarządzani, czy konfiguracja i aktywa są wiarygodne oraz czy dowody zapewnienia wspierają raportowanie do kierownictwa. Może nie zapytać najpierw o listę rekordów CNAME. Może zapytać, skąd kierownictwo wie, że zewnętrzne usługi cyfrowe są kontrolowane przez cały cykl życia.

Jak wyglądają dobre dowody audytowe

Pakiet dowodów audytowych dotyczący osieroconych rekordów DNS powinien być wystarczająco mały, aby można go było utrzymywać, i wystarczająco kompletny, aby można go było obronić. Clarysec zwykle rekomenduje następujący zestaw dowodów:

• Inwentarz stref DNS ze źródłem, datą, typem rekordu, celem i właścicielem.
• Wyniki skanowania zewnętrznej powierzchni ataku pokazujące kontrole możliwości przejęcia.
• Wpisy w rejestrze aktywów dla domen, subdomen, usług chmurowych, aplikacji SaaS i CDN.
• Rejestr usług pokazujący odpowiedzialność wewnętrzną albo odpowiedzialność dostawcy.
• Zgłoszenia zmian dla tworzenia, modyfikacji i usuwania rekordów DNS.
• Listy kontrolne onboardingu chmury i SaaS obejmujące domenę niestandardową i przegląd DNS.
• Umowy z dostawcami albo klauzule bezpieczeństwa obejmujące DNS, hosting, wsparcie incydentowe i wyjście.
• Zgłoszenia podatności z wagą, właścicielem, datą działań naprawczych i dowodami z retestu.
• Ocena PII, gdy subdomena przetwarza albo wcześniej przetwarzała dane osobowe.
• Zapisy klasyfikacji incydentów dla podejrzewanego albo potwierdzonego przejęcia.
• Wnioski po incydencie i zaktualizowane procedury po ustaleniach.

Metryki również mają znaczenie. Kierownictwo powinno widzieć liczbę zewnętrznych subdomen, odsetek z przypisanymi właścicielami, liczbę ustaleń dotyczących osieroconych rekordów DNS, średni czas działań naprawczych, przeterminowane ustalenia wysokiego ryzyka, subdomeny hostowane przez dostawców bez aktualnego odniesienia do umowy oraz odsetek wyjść z chmury z dowodami usunięcia DNS.

Te metryki przekształcają techniczną higienę w dowody nadzoru organu zarządzającego.

Typowe wzorce nieskuteczności wykrywane przez Clarysec

U klientów z sektorów SaaS, fintech, technologii medycznych, usług zarządzanych i e-commerce powtarzają się te same wzorce.

Po pierwsze, własność DNS jest podzielona między zespoły. Inżynieria odpowiada za chmurę. Marketing odpowiada za kampanie. IT odpowiada za dostęp do dostawcy DNS. Zakupy odpowiadają za zakończenie SaaS. Nikt nie odpowiada za pełny cykl życia.

Po drugie, usunięcie zasobu chmurowego jest traktowane jako koniec usługi. W praktyce DNS, certyfikaty, reguły WAF, monitorowanie, sekrety, dokumentacja i zapisy dostawców mogą pozostać.

Po trzecie, skanery podatności koncentrują się na aktywnych hostach, ale pomijają warunki przejęcia specyficzne dla dostawców. Organizacje potrzebują kontroli zewnętrznej powierzchni ataku, które rozumieją typowe stany błędów SaaS i chmury.

Po czwarte, procedury wyjścia od dostawcy koncentrują się na fakturach i zwrocie danych, a nie na domenach niestandardowych, rekordach DNS i zmianach podwykonawców przetwarzania.

Po piąte, zespoły ds. prywatności są powiadamiane zbyt późno. Jeżeli subdomena przetwarzała PII, IOD albo osoba odpowiedzialna za prywatność powinna uczestniczyć w klasyfikacji, zanim zostaną przyjęte założenia.

Po szóste, dowody istnieją, ale są rozproszone. Eksport DNS jest w jednym narzędziu, zgłoszenia zmian w innym, umowy z dostawcami w zakupach, raporty podatności w skanerach, a analiza prywatności w poczcie elektronicznej. Audytorzy traktują fragmentację jako słabość.

Zestaw narzędzi Clarysec rozwiązuje ten problem przez połączenie polityk, rejestrów, zabezpieczeń i przepływów pracy dowodowej.

30-dniowy plan działania dla nadzoru nad DNS

Jeżeli znalazłeś jeden osierocony rekord DNS, załóż, że jest ich więcej. Jeżeli nie znalazłeś żadnego, upewnij się, że potrafisz wykazać dlaczego.

Zacznij od tego 30-dniowego planu:

1. Wyeksportuj wszystkie autorytatywne strefy DNS.
2. Zidentyfikuj rekordy CNAME, ALIAS, A i AAAA wskazujące na usługi chmurowe, SaaS, CDN oraz usługi zarządzane przez agencje.
3. Przypisz właścicieli i cele biznesowe.
4. Uruchom kontrole możliwości przejęcia i ręcznie zweryfikuj podejrzane rekordy.
5. Utwórz zgłoszenia podatności dla potwierdzonych ryzyk.
6. Usuń albo przejmij eksponowane rekordy w ramach zarządzania zmianami.
7. Zaktualizuj rejestr aktywów, rejestr chmury i rejestr dostawców.
8. Sprawdź, czy jakakolwiek dotknięta subdomena przetwarzała PII.
9. Dodaj kontrole cyklu życia DNS do onboardingu chmury, zakupów SaaS i wyjścia od dostawców.
10. Raportuj metryki kierownictwu.

Techniczna naprawa osieroconych rekordów DNS jest często prosta. Naprawa nadzorcza zapobiega kolejnemu przejęciu.

Clarysec może pomóc w operacjonalizacji tego podejścia z wykorzystaniem Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls oraz naszego zestawu polityk dla zarządzania aktywami, korzystania z chmury, zarządzania podatnościami, nadzoru nad dostawcami, bezpieczeństwa PII, reagowania na incydenty i dowodów audytowych.

Jeżeli chcesz podejścia gotowego do audytu, Clarysec może pomóc zbudować pakiet dowodów dotyczących DNS i ekspozycji chmurowej, zmapować go na ISO/IEC 27001:2022, NIS2, DORA i GDPR oraz przekształcić zapomniane subdomeny w kontrolowane, przypisane właścicielom i monitorowane aktywa. Pobierz odpowiedni zestaw narzędzi Clarysec, poproś o demo albo zaplanuj ocenę nadzoru nad DNS, zanim tester penetracyjny, audytor albo atakujący znajdzie kolejny zapomniany wskaźnik.