Okresy wsparcia bezpieczeństwa w unijnym CRA a ISO 27001

Jest wtorek, godzina 08:20. Właściciel produktu odpowiedzialny za połączoną bramę B2B otrzymuje wiadomość od klienta z branży regulowanej: „Prosimy o potwierdzenie okresu wsparcia bezpieczeństwa dla wersji firmware’u 4.6, SLA reakcji na podatności oraz informacji, czy urządzenie będzie nadal kwalifikowało się do aktualizacji bezpieczeństwa w trakcie naszej pięcioletniej umowy serwisowej”.

O 09:00 dział zakupów przekazuje kwestionariusz due diligence DORA. O 10:15 dział prawny pyta, czy deklarowany okres wsparcia jest spójny z umowami z klientami. O 11:00 dyrektor ds. bezpieczeństwa informacji zostaje włączony w przegląd ryzyka dostawcy na potrzeby NIS2, ponieważ produkt jest wykorzystywany przez dostawcę usług zarządzanych w UE. Po lunchu zespół ds. prywatności pyta, czy niewspierana biblioteka API w produkcie może wpływać na bezpieczeństwo danych osobowych zgodnie z GDPR.

Niewygodna prawda ujawnia się szybko. Firma ma mapę drogową, proces wdrażania poprawek, kalendarz wydań i portal wsparcia klienta, ale nie ma nadzorowanych dowodów dotyczących okresu wsparcia bezpieczeństwa.

Ta luka ma znaczenie. Zgodnie z unijnym Cyber Resilience Act okres wsparcia bezpieczeństwa nie jest wyłącznie etykietą produktu. Jest zobowiązaniem dotyczącym cyklu życia, które wpływa na obsługę podatności, dostępność aktualizacji, zarządzanie zależnościami od dostawców, komunikację z klientami, deklaracje umowne oraz monitorowanie po wprowadzeniu do obrotu. Dla dostawców SaaS, producentów urządzeń, wydawców oprogramowania, dostawców usług chmurowych i dostawców usług ICT okres wsparcia staje się obiektem zgodności, który będą weryfikować audytorzy oraz nabywcy z branż regulowanych.

Praktycznym rozwiązaniem nie jest kolejny odizolowany arkusz zgodności. Rozwiązaniem jest objęcie okresu wsparcia bezpieczeństwa nadzorem w ramach systemu zarządzania bezpieczeństwem informacji ISO/IEC 27001:2022, a następnie mapowanie tego samego zestawu dowodów na oczekiwania audytowe wynikające z NIS2, DORA, GDPR, NIST CSF 2.0 i podejścia zgodnego z COBIT.

To jest model operacyjny Clarysec: wykorzystać SZBI jako mechanizm gromadzenia i utrzymywania dowodów, stosować egzekwowalne polityki do określenia odpowiedzialności, wykorzystać Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint do budowy identyfikowalności oraz Zenith Controls: The Cross-Compliance Guide Zenith Controls jako punkt odniesienia do mapowania zgodności między ramami.

Dlaczego okres wsparcia bezpieczeństwa jest dziś obiektem audytu

Okres wsparcia bezpieczeństwa odpowiada na proste pytanie: jak długo producent będzie dostarczał aktualizacje bezpieczeństwa, remediację podatności, wytyczne dotyczące mitygacji oraz powiązane wsparcie klienta dla produktu lub wersji produktu?

W praktyce odpowiedź zależy od wielu elementów:

• architektury produktu i jego utrzymywalności,
• wsparcia komponentów zewnętrznych oraz zależności open source,
• zobowiązań dostawców i dostawców usług chmurowych,
• procesów przyjmowania zgłoszeń podatności, triage’u, remediacji i ujawniania,
• możliwości inżynierii wydań i testowania,
• warunków umów z klientami oraz obowiązków regulacyjnych,
• ścieżek reagowania na incydenty i powiadamiania odbiorców usług,
• retencji dowodów i zapisów zatwierdzeń.

Jeżeli producent obiecuje pięć lat wsparcia bezpieczeństwa, ale krytyczna biblioteka kryptograficzna traci wsparcie po trzech latach, okres wsparcia staje się decyzją dotyczącą ryzyka. Jeżeli klient jest podmiotem finansowym objętym DORA, ten sam okres wsparcia staje się częścią zapewnienia dotyczącego zewnętrznych dostawców ICT. Jeżeli produkt przetwarza dane osobowe, niewspierane oprogramowanie może stać się elementem rozliczalności bezpieczeństwa przetwarzania w GDPR. Jeżeli produkt wspiera podmiot kluczowy lub ważny w rozumieniu NIS2, bezpieczeństwo cyklu życia staje się kwestią bezpieczeństwa łańcucha dostaw.

NIS2 ujmuje ten aspekt nadzorczy wprost. Article 20 wymaga, aby organy zarządzające podmiotów kluczowych i ważnych zatwierdzały środki zarządzania ryzykiem cyberbezpieczeństwa, nadzorowały ich wdrożenie i odbywały szkolenia. Article 21 wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych, w tym analizy ryzyka, obsługi incydentów, ciągłości działania, bezpieczeństwa łańcucha dostaw, bezpiecznego pozyskiwania, bezpiecznego rozwoju i utrzymania, obsługi i ujawniania podatności, oceny skuteczności, cyberhigieny, kryptografii, kontroli dostępu, zarządzania aktywami oraz uwierzytelniania. Article 23 dodaje etapowe obowiązki zgłaszania znaczących incydentów.

DORA wywiera podobną presję na podmioty finansowe. Wymaga zarządzania ryzykiem ICT, testowania cyfrowej odporności operacyjnej, zarządzania incydentami oraz nadzoru nad ryzykiem związanym z zewnętrznymi dostawcami ICT. DORA Article 28 obejmuje zasady zarządzania ryzykiem związanym z zewnętrznymi dostawcami ICT, a Article 30 wymaga pisemnych ustaleń umownych z jasnym opisem usług, środkami bezpieczeństwa, wsparciem w przypadku incydentów, prawem do audytu, prawem wypowiedzenia oraz ustaleniami dotyczącymi wyjścia.

GDPR dodaje warstwę prywatności. Jeżeli produkt przetwarza dane osobowe, administratorzy i podmioty przetwarzające potrzebują odpowiednich środków technicznych i organizacyjnych zgodnie z Article 32, jasnych ustaleń umownych zgodnie z Article 28 oraz gotowości do oceny naruszeń i powiadamiania zgodnie z Articles 33 i 34.

Dlatego okresem wsparcia bezpieczeństwa w CRA należy zarządzać jak rodziną zabezpieczeń w SZBI, a nie jak odizolowanym polem w zarządzaniu produktem.

ISO 27001 jako kręgosłup kontroli dla okresów wsparcia bezpieczeństwa w CRA

ISO/IEC 27001:2022 ma wartość, ponieważ jest skalowalne, oparte na ryzyku i zorientowane na system zarządzania. Wymaga, aby organizacja określiła kontekst, strony zainteresowane, zakres i powiązane procesy, a następnie przełożyła wymagania prawne, regulacyjne i umowne na ocenę ryzyka, postępowanie z ryzykiem, kontrole operacyjne oraz dowody ISO/IEC 27001:2022.

Dla nadzoru nad okresem wsparcia bezpieczeństwa oznacza to, że organizacja powinna:

1. Zidentyfikować produkty, wersje, moduły, usługi chmurowe i zależności objęte zakresem.
2. Zidentyfikować strony zainteresowane, w tym klientów, regulatorów, dystrybutorów, importerów, integratorów, administratorów danych, podmioty przetwarzające, podmioty podprzetwarzające, partnerów wspierających reagowanie na incydenty i dostawców.
3. Udokumentować obowiązki prawne, regulacyjne i umowne dotyczące wsparcia.
4. Ocenić ryzyka, które mogłyby uniemożliwić realizację zobowiązań dotyczących wsparcia.
5. Dobrać zabezpieczenia dla zarządzania podatnościami, bezpiecznego rozwoju, zapewnienia w zakresie dostawców, zarządzania incydentami, ciągłości działania, prywatności i udokumentowanej informacji.
6. Utworzyć notatki do Deklaracji stosowania wyjaśniające, dlaczego dane zabezpieczenia mają zastosowanie.
7. Przeglądać okres wsparcia, gdy zmienia się architektura, zależności od dostawców, ekspozycja na zagrożenia lub zobowiązania wobec klientów.

Zenith Controls wskazuje trzy powiązane tematycznie zabezpieczenia ISO/IEC 27002:2022 jako główne punkty odniesienia dla tego problemu nadzorczego: 5.31 Wymagania prawne, ustawowe, regulacyjne i umowne, 8.8 Zarządzanie podatnościami technicznymi oraz 8.25 Bezpieczny cykl życia rozwoju oprogramowania. Nie są to jedyne zaangażowane zabezpieczenia, ale stanowią kręgosłup ładu zarządczego.

Kluczowa jest identyfikowalność. Okres wsparcia produktu powinien być możliwy do prześledzenia od obowiązku do scenariusza ryzyka, od scenariusza ryzyka do dobranych zabezpieczeń, od zabezpieczeń do wymagań polityk oraz od wymagań polityk do dowodów.

Zenith Blueprint, faza Zarządzania ryzykiem, krok 13, opisuje tę dyscyplinę identyfikowalności bezpośrednio:

„Stosuj odwołania krzyżowe do regulacji: jeżeli określone zabezpieczenia są wdrażane specjalnie w celu zapewnienia zgodności z GDPR, NIS2 lub DORA, możesz odnotować to w Rejestrze ryzyk jako część uzasadnienia wpływu ryzyka albo w notatkach do SoA”.

Źródło: Zenith Blueprint: An Auditor’s 30-Step Roadmap, faza Zarządzania ryzykiem, krok 13: Planowanie postępowania z ryzykiem i Deklaracja stosowania Zenith Blueprint

Dla okresu wsparcia bezpieczeństwa w CRA Deklaracja stosowania nie powinna jedynie stwierdzać, że „zarządzanie podatnościami ma zastosowanie”. Powinna wyjaśniać, że zarządzanie podatnościami ma zastosowanie, ponieważ firma ma zobowiązania CRA dotyczące cyklu życia, oczekiwania NIS2 w zakresie bezpiecznego rozwoju i łańcucha dostaw, wymagania due diligence klientów objętych DORA, obowiązki bezpieczeństwa wynikające z GDPR tam, gdzie przetwarzane są dane osobowe, oraz umowne deklaracje wsparcia.

Od obietnicy wsparcia do nadzorowanego cyklu życia

Zdefiniowany przez producenta okres wsparcia bezpieczeństwa powinien przejść sześć testów nadzorczych.

Po pierwsze, musi być zdefiniowany. Organizacja potrzebuje standardowej taksonomii, takiej jak aktywne wsparcie, wsparcie wyłącznie w zakresie bezpieczeństwa, wsparcie rozszerzone, wsparcie ograniczone i brak wsparcia. Każdy status powinien wyjaśniać dostępność aktualizacji, obsługę podatności, komunikację z klientami oraz ścieżki eskalacji.

Po drugie, musi zostać objęty oceną ryzyka. Pięć lat wsparcia dla produktu SaaS zarządzanego w chmurze, z kontrolowanymi kanałami aktualizacji, oznacza coś innego niż pięć lat wsparcia dla urządzenia wbudowanego z ograniczeniami terenowymi, zależnościami od układów zewnętrznych oraz oknami wdrożeniowymi zarządzanymi przez klientów.

Po trzecie, musi zostać zatwierdzony. Zespoły produktu, bezpieczeństwa, prawny, prywatności, wsparcia klienta oraz odpowiedzialne kierownictwo powinny zatwierdzać okres bazowy i odstępstwa.

Po czwarte, musi zostać zakomunikowany. Klienci powinni rozumieć datę rozpoczęcia wsparcia, datę zakończenia, metodę aktualizacji, kanał zgłaszania podatności, oczekiwania dotyczące remediacji, konsekwencje zakończenia wsparcia oraz dostępne opcje przedłużenia.

Po piąte, musi być monitorowany. Zależności się zmieniają. Dostawcy wycofują biblioteki. Pojawiają się podatności. Środowiska klientów ewoluują. Nadzór nad okresem wsparcia musi obejmować monitorowanie cyklu życia komponentów, przegląd dostawców, strumienie informacji o podatnościach, rejestry poprawek, testowanie wydań oraz wnioski z incydentów.

Po szóste, musi być udokumentowany dowodami. Jeżeli audytor, regulator albo klient z branży regulowanej poprosi o dowód, organizacja powinna przedstawić Rejestr zgodności, rejestr wsparcia produktu, ocenę ryzyka, mapowanie SoA, rejestr podatności, zapisy poprawek, przeglądy dostawców, zatwierdzenia wydań i powiadomienia klientów.

Polityki Clarysec czynią to praktycznym. Enterprise Legal and Regulatory Compliance Policy Legal and Regulatory Compliance Policy wymaga:

„Wszystkie obowiązki prawne i regulacyjne muszą zostać zmapowane na konkretne polityki, zabezpieczenia i właścicieli w ramach systemu zarządzania bezpieczeństwem informacji (SZBI)”.

Źródło: Legal and Regulatory Compliance Policy, Wymagania dotyczące wdrożenia polityki, klauzula 6.2.1 Legal and Regulatory Compliance Policy

W przypadku MŚP równoważna dyscyplina zaczyna się od prostszego rejestru. SME Legal and Regulatory Compliance Policy-sme Legal and Regulatory Compliance Policy - SME stanowi:

„Dyrektor generalny musi prowadzić prosty, uporządkowany Rejestr zgodności obejmujący:”.

Źródło: Legal and Regulatory Compliance Policy-sme, Wymagania dotyczące ładu zarządczego, klauzula 5.1.1 Legal and Regulatory Compliance Policy - SME

Zobowiązanie dotyczące okresu wsparcia powinno znajdować się w Rejestrze zgodności, jeżeli wynika z prawa, umowy z klientem, regulacji sektorowej albo oczekiwania nabywcy z branży regulowanej. Nie powinno istnieć wyłącznie w informacjach o wydaniu albo materiałach marketingowych.

Zbuduj rejestr okresów wsparcia bezpieczeństwa CRA podczas jednego warsztatu

Wyobraźmy sobie dostawcę SaaS, który sprzedaje połączone urządzenie analityczne unijnym dostawcom usług logistycznych i klientom z sektora finansowego. Produkt obejmuje agenta wbudowanego, API w chmurze, mobilną aplikację administracyjną i kilka bibliotek open source. Sprzedaż chce obiecać pięć lat wsparcia bezpieczeństwa dla każdej głównej wersji urządzenia.

Dyrektor ds. bezpieczeństwa informacji może przeprowadzić skoncentrowany warsztat z udziałem zespołów produktu, inżynierii, prawnego, prywatności i zarządzania dostawcami.

Krok 1: Utwórz rejestr okresów wsparcia

Utwórz jeden wiersz dla każdej wersji produktu i uwzględnij:

• produkt i wersję,
• datę wydania,
• datę rozpoczęcia wsparcia,
• standardową datę zakończenia wsparcia bezpieczeństwa,
• opcję wsparcia rozszerzonego,
• metodę dostarczania aktualizacji,
• kanał ujawniania podatności,
• docelowy termin wdrożenia krytycznej poprawki,
• rolę w przetwarzaniu danych, taką jak administrator, podmiot przetwarzający albo obie role,
• krytycznych dostawców i komponenty,
• sektory klientów, których dotyczy produkt,
• właściciela ryzyka,
• datę zatwierdzenia,
• lokalizację dowodów.

Ten rejestr staje się udokumentowaną informacją w ramach SZBI. Zenith Blueprint, faza Podstawy SZBI i przywództwo, krok 6, wskazuje oczekiwanie dotyczące kontroli dokumentów:

„Dokumenty powinny mieć właściwą identyfikację, taką jak tytuł, ewentualnie numer dokumentu lub unikalny identyfikator oraz autora, odpowiedni format, a także przegląd i zatwierdzenie adekwatności przed użyciem”.

Źródło: Zenith Blueprint: An Auditor’s 30-Step Roadmap, faza Podstawy SZBI i przywództwo, krok 6: Udokumentowana informacja i budowa biblioteki SZBI Zenith Blueprint

Enterprise PIMS Documented Information Evidence Management Policy Clarysec PIMS Documented Information Evidence Management Policy stosuje podobne zasady dowodowe do dokumentacji prywatności:

„[Wszyscy] Lider ds. prywatności / kierownik PIMS MUSI przypisać identyfikator dokumentu, właściciela, numer wersji, status zatwierdzenia, datę wejścia w życie i datę przeglądu w REG12 przed opublikowaniem udokumentowanej informacji PIMS”.

Źródło: PIMS Documented Information Evidence Management Policy, Tworzenie, zatwierdzanie, wersjonowanie i publikacja, klauzula 4.2.1 PIMS Documented Information Evidence Management Policy

Nawet jeżeli rejestr okresów wsparcia nie jest domyślnie dokumentem dotyczącym prywatności, obowiązuje ta sama dyscyplina: właściciel, wersja, zatwierdzenie, data wejścia w życie i data przeglądu.

Krok 2: Powiąż deklaracje wsparcia z postępowaniem z ryzykiem

Dla każdej wersji produktu utwórz scenariusze ryzyka, takie jak:

• Krytyczna podatność zostaje wykryta w wersji objętej wsparciem, ale dostępność zasobów inżynieryjnych jest niewystarczająca.
• Komponent zewnętrzny traci wsparcie przed końcem zadeklarowanego okresu wsparcia bezpieczeństwa.
• Dostawca zmienia lokalizację hostingu albo podwykonawcę i wpływa na dostarczanie aktualizacji.
• Podatność wpływa na dane osobowe i uruchamia ocenę naruszenia prywatności.
• Regulowany klient finansowy wymaga dowodów odporności zewnętrznego dostawcy ICT.

Klauzule ISO/IEC 27001:2022 6.1.1 do 6.1.3 zapewniają mechanizm planowania: identyfikację ryzyk, ocenę prawdopodobieństwa i konsekwencji, przypisanie właścicieli ryzyka, dobór sposobu postępowania z ryzykiem, porównanie wybranych zabezpieczeń z Załącznikiem A, przygotowanie Deklaracji stosowania oraz uzyskanie zatwierdzenia ryzyka rezydualnego.

Dla ryzyka „niewspierany komponent przed datą zakończenia wsparcia” zapis ryzyka powinien obejmować zabezpieczenia ISO/IEC 27002:2022 5.31, 8.8 i 8.25, a także zabezpieczenia dotyczące dostawców, takie jak 5.19 Bezpieczeństwo informacji w relacjach z dostawcami, 5.20 Uwzględnianie bezpieczeństwa informacji w umowach z dostawcami, 5.21 Zarządzanie bezpieczeństwem informacji w łańcuchu dostaw ICT oraz 5.22 Monitorowanie, przegląd i zarządzanie zmianami usług dostawców.

Krok 3: Ustal reguły dowodowe dla podatności i poprawek

Okres wsparcia jest wiarygodny tylko wtedy, gdy zarządzanie podatnościami działa przez cały ten okres.

SME Vulnerability and Patch Management Policy-sme Vulnerability and Patch Management Policy - SME ustanawia rygorystyczne wymaganie dla pilnej ekspozycji:

„Krytyczne poprawki muszą być wdrażane w ciągu 3 dni od wydania, szczególnie dla systemów dostępnych z Internetu”.

Źródło: Vulnerability and Patch Management Policy-sme, Wymagania dotyczące wdrożenia polityki, klauzula 6.1.1 Vulnerability and Patch Management Policy - SME

Wymaga również zapisów gotowych do audytu:

„Rejestr poprawek musi być prowadzony i przeglądany podczas audytów oraz działań związanych z reagowaniem na incydenty”.

Źródło: Vulnerability and Patch Management Policy-sme, Wymagania dotyczące ładu zarządczego, klauzula 5.4.1 Vulnerability and Patch Management Policy - SME

Dla środowisk enterprise Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy wymaga:

„Scentralizowany Rejestr zarządzania podatnościami musi być prowadzony przez zespół operacji bezpieczeństwa i przeglądany co miesiąc przez dyrektora ds. bezpieczeństwa informacji albo delegowany organ”.

Źródło: Vulnerability and Patch Management Policy, Wymagania dotyczące ładu zarządczego, klauzula 5.1 Vulnerability and Patch Management Policy

Zenith Blueprint, faza Kontrole w działaniu, krok 19, wyjaśnia oczekiwanie operacyjne stojące za zabezpieczeniem ISO/IEC 27002:2022 8.8:

„Bądź na bieżąco z nowymi błędami bezpieczeństwa dla swojego oprogramowania i sprzętu, korzystając m.in. z alertów dostawców i kanałów CVE. Oceń, które z nich są istotne: czy używamy tego oprogramowania, jak krytyczny jest błąd, a następnie niezwłocznie zastosuj poprawki albo mitygacje”.

Źródło: Zenith Blueprint: An Auditor’s 30-Step Roadmap, faza Kontrole w działaniu, krok 19: Zabezpieczenia techniczne I Zenith Blueprint

Każda wspierana wersja produktu potrzebuje ścieżki dowodowej podatności: przyjęcia zgłoszenia, analizy istotności, oceny wagi, wersji objętych wpływem, planu remediacji, wydania poprawki, wytycznych dotyczących mitygacji, komunikacji z klientem i zatwierdzenia zamknięcia.

Krok 4: Połącz bezpieczny rozwój z czasem trwania wsparcia

Wsparcie bezpieczeństwa zaczyna się przed wydaniem. Zależy od praktyk rozwoju, które sprawiają, że produkt jest utrzymywalny.

SME Secure Development Policy-sme Secure Development Policy - SME stanowi:

„Komponenty muszą być regularnie aktualizowane, gdy wydawane są poprawki bezpieczeństwa. Jeżeli zostanie zidentyfikowana krytyczna podatność, komponent musi zostać niezwłocznie zaktualizowany albo zastąpiony”.

Źródło: Secure Development Policy-sme, Wymagania dotyczące wdrożenia polityki, klauzula 6.6.3 Secure Development Policy - SME

SME Application Security Requirements Policy-sme Application Security Requirements Policy - SME wymaga, aby umowy i wymagania:

„określały obowiązki dotyczące ujawniania podatności, czasów reakcji i wdrażania poprawek”.

Źródło: Application Security Requirements Policy-sme, Wymagania dotyczące ładu zarządczego, klauzula 5.3.2 Application Security Requirements Policy - SME

Jeżeli firma obiecuje wsparcie do 2031 r., architektura musi umożliwiać utrzymywalne aktualizacje, zastępowanie zależności, bezpieczne potoki budowania, testy regresji i wydania awaryjne. Zabezpieczenia ISO/IEC 27002:2022 dotyczące bezpiecznego rozwoju, bezpiecznej architektury, bezpiecznego kodowania, testów bezpieczeństwa, rozwoju realizowanego w outsourcingu, separacji środowisk i zarządzania zmianą stają się czynnikami umożliwiającymi realizację okresu wsparcia.

Jeden zestaw dowodów dla CRA, NIS2, DORA i GDPR

Te same dowody dotyczące okresu wsparcia mogą wspierać różne rozmowy regulacyjne, ale każde ramy zadają pytanie inaczej.

Zależność od dostawcy jest często miejscem, w którym zawodzą zobowiązania wsparcia. Enterprise Supplier Dependency Risk Management Policy Supplier Dependency Risk Management Policy wymaga:

„Rejestr zależności od dostawców: biuro zarządzania dostawcami (VMO) powinno prowadzić aktualny rejestr wszystkich krytycznych dostawców, obejmujący szczegóły takie jak świadczone usługi / dostarczane produkty; informację, czy dostawca jest jedynym źródłem; dostępnych alternatywnych dostawców lub możliwość zastąpienia; aktualne warunki umowne; oraz ocenę wpływu w przypadku awarii dostawcy albo naruszenia jego bezpieczeństwa”.

Źródło: Supplier Dependency Risk Management Policy, Wymagania wdrożeniowe, klauzula 6.1 Supplier Dependency Risk Management Policy

Zenith Blueprint, faza Kontrole w działaniu, krok 23, ostrzega, że audytorzy będą sprawdzać umowy z dostawcami oraz dowody monitorowania dostawców:

„Audytorzy będą przeglądać przykładowe umowy lub porozumienia o świadczenie usług. Szukają jednoznacznych klauzul dotyczących bezpieczeństwa informacji, takich jak terminy zgłaszania naruszeń, ograniczenia dostępu, obowiązki przetwarzania danych, wymagania dotyczące szyfrowania albo prawo do audytu”.

Źródło: Zenith Blueprint: An Auditor’s 30-Step Roadmap, faza Kontrole w działaniu, krok 23: Zabezpieczenia organizacyjne Zenith Blueprint

Dla klientów objętych DORA ma to znaczenie krytyczne. Umowy dotyczące usług ICT wspierających funkcje krytyczne lub istotne wymagają jasnych opisów usług, warunków podwykonawstwa, środków bezpieczeństwa, wsparcia w przypadku incydentów, praw do audytu i inspekcji, praw wypowiedzenia oraz ustaleń dotyczących przejścia. Dostawca, który nie może wesprzeć tych zobowiązań, może uniemożliwić producentowi złożenie wiarygodnej deklaracji okresu wsparcia.

Tabela korelacji zabezpieczeń dla gotowego do audytu nadzoru nad okresem wsparcia

Ta tabela korelacji pozwala zespołom bezpieczeństwa, prawnym, produktowym i sprzedażowym mówić jednym językiem. Rejestr okresów wsparcia nie jest wyłącznie dowodem CRA. Jest zapewnieniem w zakresie dostawców dla NIS2, zapewnieniem dotyczącym stron trzecich dla DORA, wsparciem bezpieczeństwa przetwarzania dla GDPR oraz artefaktem ładu zarządczego dla certyfikacji ISO 27001.

Perspektywa prywatności: kiedy brak wsparcia staje się brakiem bezpieczeństwa

Nadzór nad okresem wsparcia bezpieczeństwa nie jest wyłącznie kwestią cyberbezpieczeństwa. Jeżeli produkt przechowuje, przesyła lub przetwarza dane osobowe, niewspierane oprogramowanie może stać się ryzykiem dla prywatności.

GDPR ma zastosowanie do przetwarzania w kontekście jednostki organizacyjnej w UE i może mieć zastosowanie także do organizacji spoza UE oferujących towary lub usługi osobom fizycznym w UE albo monitorujących ich zachowanie. Definiuje dane osobowe szeroko i traktuje naruszenie ochrony danych osobowych jako naruszenie bezpieczeństwa prowadzące do przypadkowego lub niezgodnego z prawem zniszczenia, utraty, zmiany, nieuprawnionego ujawnienia albo dostępu do przetwarzanych danych osobowych.

Dla nadzoru nad okresem wsparcia zespoły ds. prywatności muszą wiedzieć, które wersje produktu przetwarzają PII, które systemy są nadal wspierane oraz czy podatności wpływają na poufność, integralność lub dostępność danych osobowych.

Enterprise PII Security Access Control Policy Clarysec PII Security Access Control Policy wymaga:

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

Źródło: PII Security Access Control Policy, Bezpieczna konfiguracja i zarządzanie podatnościami, klauzula 4.7.4 PII Security Access Control Policy

Enterprise Processor Subprocessor Third Party Privacy Management Policy Processor Subprocessor Third Party Privacy Management Policy dodaje bieżące monitorowanie relacji wysokiego ryzyka dotyczących prywatności:

„[Wszyscy] Właściciel dostawcy / właściciel zakupów MUSI monitorować aktywne relacje wysokiego ryzyka z podmiotami przetwarzającymi i podmiotami podprzetwarzającymi co kwartał, a pozostałe aktywne relacje z podmiotami przetwarzającymi PII i podmiotami podprzetwarzającymi raz w roku, względem warunków due diligence, statusu umowy, statusu zapewnienia, otwartych kwestii i dat przeglądu w REG08”.

Źródło: Processor Subprocessor Third Party Privacy Management Policy, Bieżące monitorowanie, wsparcie, interfejs ujawnień i wyjście, klauzula 4.5.1 Processor Subprocessor Third Party Privacy Management Policy

Gdy podatność staje się incydentem, Enterprise PII Incident Breach Management Policy PII Incident Breach Management Policy wymaga oceny przesłanek zgłoszeniowych w wielu ramach:

„[Warunkowo] Lider ds. prywatności / kierownik PIMS MUSI ocenić mające zastosowanie prawne, sektorowe, finansowe, cyberbezpieczeństwa, umowne oraz dotyczące klienta i odbiorcy usługi przesłanki zgłaszania dla każdego incydentu PII o istotnym wpływie oraz odnotować wynik stosowalności w REG01, REG08 i REG10”.

Źródło: PII Incident Breach Management Policy, Klasyfikacja i ocena naruszenia, klauzula 4.2.6 PII Incident Breach Management Policy

To praktyczne nakładanie się zobowiązań wsparcia CRA, komunikacji incydentowej NIS2, obsługi poważnych incydentów ICT DORA oraz rozliczalności naruszeń w GDPR.

Jak audytorzy testują ten sam proces okresu wsparcia

Silny proces nadzoru nad okresem wsparcia powinien przetrwać różne style audytu. Dowody nie zmieniają się znacząco, ale zmienia się perspektywa audytora.

NIST CSF 2.0 jest użyteczny jako warstwa komunikacyjna, ponieważ jego funkcja GOVERN obejmuje obowiązki prawne, regulacyjne, umowne i dotyczące prywatności, cele zarządzania ryzykiem, apetyt na ryzyko, role, polityki i nadzór. Wyniki dotyczące łańcucha dostaw obejmują strategię dostawców, krytyczność, umowy, due diligence, monitorowanie, koordynację incydentową oraz postanowienia kończące relację.

Audytorzy stosujący COBIT i podejście ISACA często koncentrują się na projekcie ładu zarządczego: kto jest właścicielem decyzji, jaki proces jest zdefiniowany, jakie metryki pokazują wyniki, jak zatwierdzane są wyjątki oraz jak realizowane jest ciągłe doskonalenie.

Enterprise Information Security Policy Clarysec Information Security Policy ujmuje zasadę audytowalności:

„Wszystkie wdrożone zabezpieczenia powinny być możliwe do audytu, wspierane udokumentowanymi procedurami oraz zachowanymi dowodami działania”.

Źródło: Information Security Policy, Wymagania dotyczące wdrożenia polityki, klauzula 6.6.1 Information Security Policy

To wymaganie powinien spełniać każdy okres wsparcia bezpieczeństwa.

Wydłuż, skróć albo zakończ wsparcie bez tworzenia fałszywego zapewnienia

Najtrudniejsze momenty nadzorcze nie występują przy uruchomieniu produktu. Pojawiają się wtedy, gdy zmienia się rzeczywistość.

Może być konieczne wydłużenie wsparcia, ponieważ klienci regulowani zależą od produktu, migracja nie jest możliwa albo klient sektorowy ma umowne potrzeby ciągłości. Może być konieczne skrócenie albo ograniczenie wsparcia, ponieważ dostawca wycofuje utrzymanie bezpieczeństwa, komponent staje się niemożliwy do załatania, platforma osiąga ograniczenia techniczne albo architektura produktu nie może bezpiecznie obsłużyć danej klasy podatności.

Kontrolowana zmiana okresu wsparcia powinna obejmować:

• przesłankę zmiany, taką jak zakończenie cyklu życia u dostawcy, krytyczna podatność, umowa z klientem albo zmiana regulacyjna,
• produkty, wersje, klientów i sektory objęte wpływem,
• analizę wpływu na dane osobowe i usługi krytyczne,
• przegląd wykonalności po stronie dostawców i komponentów,
• ocenę ryzyka i decyzję dotyczącą ryzyka rezydualnego,
• zaktualizowany rejestr okresów wsparcia,
• zaktualizowane powiadomienie klienta i stanowisko umowne,
• zaktualizowane notatki SoA, jeżeli zmieniają się zabezpieczenia lub obowiązki,
• zatwierdzenie przez kierownictwo i datę przeglądu.

Enterprise Coordinated Vulnerability Disclosure Policy Coordinated Vulnerability Disclosure Policy jest przydatna, gdy zmiana wynika z podatności:

„Dla wszystkich potwierdzonych podatności należy opracować plan remediacji albo mitygacji. Wdrożenie poprawki powinno być priorytetyzowane na podstawie wagi. Na przykład podatności krytyczne powinny zostać usunięte albo zmitygowane w ciągu 14 dni, jeżeli jest to wykonalne, lub szybciej, gdy wykryto aktywne wykorzystanie podatności, natomiast kwestie o niższej wadze powinny zostać rozwiązane w rozsądnym terminie”.

Źródło: Coordinated Vulnerability Disclosure Policy, Wymagania wdrożeniowe, klauzula 6.6 Coordinated Vulnerability Disclosure Policy

Jeżeli pełnej poprawki nie da się dostarczyć natychmiast, środki kompensujące, wyłączenie funkcjonalności, zwiększone monitorowanie albo wytyczne konfiguracyjne dla klienta mogą być czasowo akceptowalne, ale decyzja musi być udokumentowana i zakomunikowana.

Praktyczna lista kontrolna Clarysec dla gotowości okresu wsparcia

Użyj tej listy kontrolnej przed opublikowaniem albo odnowieniem jakiegokolwiek zobowiązania dotyczącego okresu wsparcia bezpieczeństwa CRA.

• Czy produkt i wersja są ujęte w rejestrze okresów wsparcia?
• Czy data zakończenia wsparcia została zatwierdzona przez produkt, bezpieczeństwo i odpowiedzialne kierownictwo?
• Czy prawne, regulacyjne i umowne czynniki determinujące zostały zmapowane w Rejestrze zgodności?
• Czy scenariusz ryzyka dotyczący okresu wsparcia jest uwzględniony w Rejestrze ryzyk?
• Czy zabezpieczenia są zmapowane w Deklaracji stosowania, w tym 5.31, 8.8 i 8.25 tam, gdzie mają zastosowanie?
• Czy krytyczni dostawcy i komponenty są zmapowani w rejestrze zależności od dostawców?
• Czy istnieją dowody, że komponenty mogą być łatane albo zastępowane w okresie wsparcia?
• Czy zdefiniowano odpowiedzialności za przyjmowanie zgłoszeń podatności, triage, remediację i ujawnianie?
• Czy SLA dla krytycznych poprawek są zgodne z polityką i umowami z klientami?
• Czy rejestry poprawek, zapisy wydań i decyzje dotyczące podatności są przechowywane?
• Czy systemy przetwarzające dane osobowe są objęte dowodami oceny podatności tam, gdzie przetwarzane jest PII?
• Czy powiadomienia klientów, deklaracje wsparcia i warunki umowne są spójne?
• Czy istnieje proces wydłużania, skracania albo kończenia wsparcia z zatwierdzeniem ryzyka?
• Czy przeglądy zarządzania otrzymują informacje wejściowe dotyczące ryzyka okresu wsparcia, dostawców, podatności i incydentów?
• Czy dowody można przedstawić w ciągu 48 godzin na potrzeby audytu klienta albo zapytania organu regulacyjnego?

Enterprise PIMS Monitoring Audit Improvement Policy PIMS Monitoring Audit Improvement Policy wzmacnia dyscyplinę przeglądu zarządzania dla programów prywatności:

„[Obie role] Najwyższe kierownictwo MUSI przeglądać niezgodności PIMS, działania korygujące, wyniki monitorowania, wyniki audytu, ryzyka dla prywatności, zapewnienie w zakresie dostawców oraz informacje wejściowe o zmianach stron zainteresowanych w REG12 podczas każdego przeglądu zarządzania”.

Źródło: PIMS Monitoring Audit Improvement Policy, Przegląd zarządzania PIMS, klauzula 4.3.5 PIMS Monitoring Audit Improvement Policy

Dla nadzoru nad okresem wsparcia bezpieczeństwa ten sam rytm przeglądów powinien obowiązywać w całym SZBI: podatności, wyniki wdrażania poprawek, zapewnienie w zakresie dostawców, zobowiązania wobec klientów, incydenty, odstępstwa dotyczące wsparcia i działania korygujące powinny zasilać przegląd zarządzania.

Uczyń okres wsparcia bezpieczeństwa możliwym do obrony

Cyber Resilience Act zmienia sposób myślenia o bezpieczeństwie produktu. Skłania producentów i dostawców oprogramowania do myślenia dalej niż dzień wydania. Okres wsparcia bezpieczeństwa staje się obietnicą dotyczącą cyklu życia, którą trzeba zaprojektować, objąć nadzorem, monitorować i udokumentować dowodami.

Dla CISO wniosek jest jasny: nie pozwól, aby okres wsparcia istniał wyłącznie w marketingu produktowym. Dla menedżerów zgodności: nie buduj oddzielnego silosu dowodowego CRA. Dla audytorów: testuj, czy zobowiązania wsparcia są identyfikowalne względem ryzyka, zabezpieczeń, dostawców, incydentów i udokumentowanych zatwierdzeń. Dla właścicieli biznesowych: pamiętaj, że wiarygodny okres wsparcia może stać się przewagą rynkową, szczególnie przy sprzedaży do sektorów regulowanych NIS2, podmiotów finansowych objętych DORA oraz klientów wrażliwych na kwestie prywatności.

Clarysec pomaga organizacjom operacjonalizować ten model poprzez:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint do budowania identyfikowalności SZBI, udokumentowanej informacji, mapowania SoA i gotowości do audytu,
• Zenith Controls: The Cross-Compliance Guide Zenith Controls do mapowania zabezpieczeń ISO/IEC 27002:2022 na NIS2, DORA, GDPR, NIST CSF 2.0 i oczekiwania audytowe,
• pakiety polityk Enterprise i SME dla zarządzania podatnościami, bezpiecznego rozwoju, zgodności prawnej, zależności od dostawców, dowodów w zakresie prywatności i reagowania na incydenty,
• praktyczne rejestry i przepływy pracy dowodowej, które przekształcają deklaracje dotyczące okresu wsparcia w audytowalny ład zarządczy.

Twój następny krok jest prosty: wybierz jedną flagową wersję produktu i zbuduj dla niej pakiet dowodów okresu wsparcia bezpieczeństwa. Zmapuj obowiązek, zatwierdź okres wsparcia, przetestuj proces obsługi podatności, zweryfikuj zależności od dostawców, potwierdź komunikację z klientami i zachowaj zapisy.

Jeżeli potrafisz obronić jeden produkt, możesz skalować model. Jeżeli nie potrafisz obronić jednego produktu, luka nie dotyczy dokumentacji. Dotyczy ładu zarządczego.

Pobierz Zenith Blueprint, użyj Zenith Controls do mapowania dowodów albo zamów ocenę gotowości Clarysec, aby przekształcić okresy wsparcia bezpieczeństwa CRA w gotowy do audytu ład zarządczy ISO 27001.