Zarządzanie rozszerzeniami przeglądarek na potrzeby NIS2, DORA i GDPR

Maria, CISO szybko rosnącej firmy fintech, uważała, że wstępna ocena zgodności z DORA przebiega dobrze. Jej zespół przygotował rejestr stron trzecich ICT, umowy dotyczące krytycznych usług SaaS, zapisy due diligence dostawców, decyzje o akceptacji ryzyka oraz pakiet raportowy dla organu zarządzającego.

Wtedy audytor zadał pytanie, którego nikt nie przewidział.

„Czy mogą Państwo pokazać nam proces zarządzania rozszerzeniami przeglądarek?”

Pytanie wynikało z przeglądu punktu końcowego przeprowadzanego z analitykiem finansowym. Podczas udostępniania ekranu audytor zauważył w przeglądarce analityka rozszerzenie zwiększające produktywność, dostarczane przez stronę trzecią. Wyglądało niegroźnie, ale szybka weryfikacja wykazała, że jego twórca trzy miesiące wcześniej padł ofiarą naruszenia łańcucha dostaw. Skompromitowane rozszerzenie wykorzystano do wyprowadzania tokenów sesji dla głównych platform SaaS.

Fintech miał solidne polityki zakazujące nieautoryzowanego oprogramowania. Korzystał z EDR, MFA, CASB, logów SaaS oraz SZBI dostosowanego do ISO/IEC 27001. Nikt jednak nie potraktował przeglądarki jako zarządzanej platformy oprogramowania. Nikt nie zinwentaryzował rozszerzeń. Nikt nie zatwierdził ich uprawnień. Nikt nie sprawdził, czy twórcy rozszerzeń są dostawcami. Nikt nie powiązał aktywności rozszerzeń z materiałem dowodowym dla DORA, NIS2 lub GDPR.

Pojedynczy dodatek do przeglądarki zmienił pozornie zgodny punkt końcowy w potencjalną furtkę do systemów finansowych, danych klientów i regulowanych procesów.

Na tym polega problem zarządzania rozszerzeniami przeglądarek w 2026 r. Przeglądarka nie jest już tylko oknem na Internet. To miejsce, w którym pracownicy się uwierzytelniają, zatwierdzają płatności, uzyskują dostęp do rejestrów CRM, przetwarzają dane osobowe, zarządzają infrastrukturą chmurową i korzystają z krytycznych platform SaaS. Rozszerzenia nie są już kosmetycznymi dodatkami. Są kodem stron trzecich uruchamianym w najbardziej wrażliwej warstwie współczesnego środowiska pracy.

Dla CISO, menedżerów ds. zgodności, IOD oraz właścicieli ryzyka ICT niezarządzane rozszerzenia znajdują się na styku bezpieczeństwa punktów końcowych, shadow IT, ryzyka związanego z dostawcami, zarządzania zmianą, zarządzania podatnościami i rozliczalności w zakresie prywatności. ISO/IEC 27001:2022 daje organizacjom strukturę do zarządzania tym ryzykiem. NIS2, DORA i GDPR tworzą presję regulacyjną, aby móc to wykazać.

Rozszerzenia przeglądarek są oprogramowaniem, dostawcami i podmiotami przetwarzającymi dane

Większość organizacji nauczyła się już zarządzać laptopami, urządzeniami mobilnymi, serwerami, aplikacjami SaaS, infrastrukturą chmurową i kontami uprzywilejowanymi. Rozszerzenia przeglądarek często wypadają poza te programy.

Zespoły bezpieczeństwa traktują je jak ustawienie przeglądarki. Zakupy ich nie widzą, ponieważ nie podpisano umowy. Dział prawny ich nie widzi, ponieważ nie uruchomiono procesu onboardingu dostawcy. Zespoły ds. prywatności ich nie widzą, ponieważ rozszerzenie zainstalował użytkownik, a nie wdrożono go jako oficjalnej aplikacji. Tymczasem rozszerzenie może żądać uprawnień do odczytu i zmiany danych na wszystkich stronach internetowych, dostępu do zawartości schowka, przechwytywania metadanych strony, zarządzania pobieraniem, wstrzykiwania skryptów lub komunikacji z zewnętrznym backendem.

Oznacza to, że rozszerzenie przeglądarki może być jednocześnie każdym z poniższych elementów:

[ZB] Zenith Blueprint: An Auditor’s 30-Step Roadmap ujmuje sedno problemu w wytycznych ISO/IEC 27002:2022 dla środka kontrolnego 8.19. Ostrzega, że „nawet działający w dobrej wierze pracownicy mogą instalować narzędzia, aby ‘szybciej wykonać pracę’ — rozszerzenie przeglądarki, bibliotekę kodu, aplikację do transferu plików — nie zdając sobie sprawy, że właśnie wprowadzili furtkę, niezałataną zależność albo wektor eksfiltracji danych”.

To zdanie należy traktować jako deklarację ryzyka na poziomie zarządu. Pracownicy instalujący ryzykowne rozszerzenia zwykle nie próbują omijać zabezpieczeń. Próbują zwiększyć produktywność. Nieskuteczność zarządzania pojawia się wtedy, gdy organizacja nie zapewnia bezpiecznego procesu wnioskowania, zatwierdzania, wdrażania i monitorowania.

Dlaczego NIS2, DORA i GDPR czynią tę ślepą plamę pilną

Ryzyko związane z rozszerzeniami przeglądarek istnieje od lat, ale kontekst regulacyjny się zmienił. W 2026 r. od organizacji oczekuje się wykazania nie tylko tego, że środki kontrolne istnieją, lecz także tego, że są oparte na ryzyku, zintegrowane, monitorowane i udokumentowane dowodowo.

NIS2 podnosi oczekiwania dotyczące cyberhigieny i bezpieczeństwa łańcucha dostaw. DORA wymaga od podmiotów finansowych zarządzania ryzykiem ICT w odniesieniu do zależności wewnętrznych i zależności od stron trzecich. GDPR wymaga od administratorów i podmiotów przetwarzających wykazania bezpieczeństwa przetwarzania, rozliczalności oraz privacy by design. Niezarządzane rozszerzenia mogą podważyć wszystkie trzy obszary.

Wniosek jest prosty. Rozszerzenie przeglądarki nie jest zbyt małe, aby miało znaczenie. Jeżeli może mieć kontakt z danymi regulowanymi, uwierzytelnionymi sesjami, procesami finansowymi lub krytycznymi usługami SaaS, musi podlegać zarządzaniu.

Wykorzystaj ISO/IEC 27001:2022 jako model operacyjny

ISO/IEC 27001:2022 dobrze sprawdza się w zarządzaniu rozszerzeniami przeglądarek, ponieważ nie wymaga tworzenia osobnego silosu zgodności. Pozwala organizacjom rozszerzyć istniejące procesy SZBI na warstwę przeglądarki.

Praktyczny model kontroli opiera się na ośmiu środkach kontrolnych z Załącznika A ISO/IEC 27001:2022:

[ZC] Zenith Controls: The Cross-Compliance Guide jest szczególnie przydatny, ponieważ wyjaśnia, jak audytowane są środki kontrolne ISO/IEC 27001 i jak wspierają one dowody wykorzystywane w różnych ramach zgodności. W przypadku środka kontrolnego 8.19 Zenith Controls: The Cross-Compliance Guide wskazuje, że audytorzy będą „śledzić przepływ pracy: od wniosku, przez test, po zatwierdzenie i wdrożenie”. Dokładnie tak należy zaprojektować zarządzanie rozszerzeniami.

Jeżeli audytor znajdzie rozszerzenie, którego nie ma na liście zatwierdzonych, które nie jest udokumentowane w zapisach zmian i nie zostało objęte oceną ryzyka, problem przestaje być tylko ustawieniem przeglądarki. Staje się dowodem słabej kontroli instalowania oprogramowania, słabego zarządzania punktami końcowymi i potencjalnej nieskuteczności zarządzania ryzykiem dostawców.

Krok 1: wykryj środowisko rozszerzeń

Pierwszą nieskutecznością kontroli w fintechu Marii był brak widoczności. Jej zespół nie wiedział, które rozszerzenia są zainstalowane, kto je zainstalował, jakich uprawnień żądają ani czy łączą się z usługami zewnętrznymi.

Wykrywanie powinno obejmować wszystkie zarządzane przeglądarki, profile, użytkowników, urządzenia i systemy operacyjne. Powinno identyfikować nazwę rozszerzenia, unikalny identyfikator, wersję, wydawcę, źródło instalacji, zestaw uprawnień, datę instalacji, status aktualizacji, liczbę użytkowników, właściciela biznesowego oraz informację, czy rozszerzenie jest instalowane wymuszenie, instalowane przez użytkownika, side-loaded czy zablokowane.

Punktem odniesienia jest środek kontrolny 8.1, Urządzenia końcowe użytkowników. Wytyczne Zenith Blueprint: An Auditor’s 30-Step Roadmap dla środka kontrolnego 8.1 stwierdzają, że urządzenia końcowe użytkowników „muszą być wzmacniane, monitorowane i kontrolowane”. To wymaganie naturalnie obejmuje przeglądarkę, ponieważ przeglądarka jest obecnie podstawowym interfejsem użytkownika dla pracy w SaaS i chmurze.

Środek kontrolny 5.23 również ma zastosowanie, gdy rozszerzenia łączą się z usługami w chmurze. Zenith Blueprint: An Auditor’s 30-Step Roadmap przedstawia ten środek kontrolny jako odpowiedź na shadow IT, w ramach którego użytkownicy przyjmują niezatwierdzone usługi bez zarządzania. Rozszerzenie przeglądarki wysyłające treść do nieznanego hostowanego backendu jest zdarzeniem przyjęcia usługi chmurowej, nawet jeżeli nikt w dziale zakupów go nie zatwierdził.

Dojrzały wynik wykrywania powinien klasyfikować każde rozszerzenie do jednego z pięciu stanów:

Wykrywanie nie powinno być jednorazowym projektem. Rozszerzenia często się aktualizują, wydawcy zmieniają właściciela, uprawnienia się rozszerzają, a sklepy usuwają złośliwe pakiety dopiero po tym, jak użytkownicy już je zainstalowali. Inwentarz musi stać się ciągły albo co najmniej na tyle cykliczny, aby wspierać zarządzanie podatnościami i dowody audytowe.

Krok 2: jasno określ dopuszczalne użytkowanie

Gdy rozszerzenia są widoczne, oczekiwania wobec użytkowników muszą być jednoznaczne. Wiele organizacji ma już zapisy polityk, które mogą wspierać zarządzanie rozszerzeniami, ale trzeba je wyraźnie zastosować do przeglądarki.

[P-EPM] Ochrona punktów końcowych - Polityka ochrony przed złośliwym oprogramowaniem - MŚP stanowi, że użytkownicy „nie mogą instalować nieautoryzowanego oprogramowania ani wtyczek, które mogą wprowadzać ryzyko”. To jedno zdanie daje zespołom bezpieczeństwa mocną podstawę polityki, aby traktować rozszerzenia przeglądarek jako kontrolowane oprogramowanie.

[P03-AUP] P03 Polityka dopuszczalnego użytkowania, określana również jako organizacyjna Polityka dopuszczalnego użytkowania, zakazuje „Niezatwierdzonych narzędzi: instalowania lub używania nieautoryzowanego oprogramowania, sprzętu, usług chmurowych lub urządzeń”. To fundament po stronie użytkowników. Przekształca zarządzanie rozszerzeniami przeglądarek z preferencji technicznej w egzekwowalne wymaganie behawioralne i zgodnościowe.

Silna polityka rozszerzeń przeglądarek powinna odpowiadać na sześć praktycznych pytań:

Nie chodzi o zakazanie każdego użytecznego rozszerzenia. Chodzi o przejście od zaufania domyślnego do jawnego zatwierdzenia. Niektóre rozszerzenia mogą być bezpieczne, potrzebne i zwiększające produktywność. Inne mogą być zbędne, nadmiernie uprzywilejowane, porzucone albo wrogie. Program zarządzania musi je rozróżniać.

Krok 3: egzekwuj zasadę domyślnej odmowy z listą dozwolonych jako wyjątkiem

Środek kontrolny 8.19, Instalowanie oprogramowania w systemach operacyjnych, przekształca politykę w działanie operacyjne. Rozszerzenia przeglądarek nie powinny być traktowane inaczej niż inne oprogramowanie tylko dlatego, że użytkownicy instalują je ze sklepu przeglądarki.

Zenith Blueprint: An Auditor’s 30-Step Roadmap formułuje to wprost: „żadne oprogramowanie nie jest instalowane, dopóki nie zostanie uzasadnione, autoryzowane i zabezpieczone”. W przypadku rozszerzeń przeglądarek oznacza to użycie narzędzi do zarządzania przeglądarkami w przedsiębiorstwie, zarządzania punktami końcowymi lub konfiguracji urządzeń w celu egzekwowania reguł instalacji.

Najbardziej defensywnym modelem jest zasada domyślnej odmowy z listą dozwolonych jako wyjątkiem:

1. Blokować wszystkie rozszerzenia domyślnie w zarządzanych przeglądarkach.
2. Wymuszać instalację wyłącznie niezbędnych, zatwierdzonych rozszerzeń korporacyjnych.
3. Utrzymywać listę dozwolonych rozszerzeń według grupy użytkowników, działu lub roli.
4. Blokować rozszerzenia side-loaded oraz niezaufane źródła instalacji.
5. Zapobiegać obchodzeniu polityk przez zmianę profili lub używanie niezarządzanych przeglądarek.
6. Usuwać już zainstalowane rozszerzenia, które nie zostały zatwierdzone.
7. Przeglądać uprawnienia rozszerzeń i ryzyko wydawcy przed zatwierdzeniem.
8. Rejestrować rozszerzenia dozwolone, zablokowane, usunięte i zmienione.

Niektóre organizacje zaczynają od łagodniejszego modelu ze względu na złożoność operacyjną. Mogą najpierw przeprowadzić inwentaryzację, zablokować znane złośliwe rozszerzenia, a następnie etapowo wprowadzać listy dozwolonych dla grup wysokiego ryzyka, takich jak finanse, inżynieria, administratorzy uprzywilejowani, dział prawny, HR i obsługa klienta. Jest to dopuszczalne, jeżeli istnieje udokumentowana mapa drogowa. Nie jest natomiast możliwe do obrony trwałe tolerowanie nieznanego ryzyka rozszerzeń.

Krok 4: oceniaj ryzyko rozszerzeń jak ryzyko dostawców i oprogramowania

Przegląd ryzyka rozszerzenia przeglądarki powinien być na tyle lekki, aby biznes go akceptował, i na tyle solidny, aby wytrzymał audyt. Przegląd powinien łączyć ryzyko oprogramowania, ryzyko dostawcy, ryzyko chmury, ochronę danych i zarządzanie podatnościami.

[P-TP] Polityka bezpieczeństwa dostawców i stron trzecich nakazuje, aby „wszyscy nowi dostawcy przeszli udokumentowaną ocenę bezpieczeństwa przed zawarciem umowy”. Nie każdy twórca rozszerzenia będzie wymagał pełnego procesu onboardingu dostawcy w przedsiębiorstwie, ale zasada ryzyka dostawcy nadal ma zastosowanie. Jeżeli twórca może wypychać aktualizacje kodu do przeglądarek pracowników albo przetwarzać dane organizacji przez usługę backendową, organizacja ma zależność od strony trzeciej.

[P-ASR] Polityka wymagań bezpieczeństwa aplikacji - MŚP wzmacnia ten sam wymóg z perspektywy oprogramowania: „każde narzędzie strony trzeciej, wtyczka lub zewnętrzna biblioteka kodu używana w aplikacji musi być zarejestrowana i corocznie przeglądana pod kątem wpływu na bezpieczeństwo oraz statusu poprawek”.

Użyj poniższego modelu ryzyka, aby ustandaryzować decyzje:

Rozszerzenie wysokiego ryzyka nie powinno zostać zatwierdzone, chyba że istnieje krytyczna potrzeba biznesowa, udokumentowane środki kompensujące i akceptacja ryzyka przez kierownictwo wyższego szczebla. Przykłady środków kompensujących obejmują ograniczenie użycia do utwardzonego profilu przeglądarki, ograniczenie do konkretnych adresów URL, blokowanie wprowadzania danych do aplikacji wrażliwych, gdy rozszerzenie jest aktywne, stosowanie monitorowania DLP albo wymaganie umowy z dostawcą i aneksu dotyczącego prywatności.

Krok 5: zintegruj przegląd prywatności i GDPR

Zarządzanie rozszerzeniami przeglądarek często zawodzi, ponieważ przegląd prywatności jest odłączony od narzędzi punktów końcowych. Tymczasem wiele rozszerzeń może widzieć dane osobowe wyświetlane w aplikacjach SaaS, systemach HR, zgłoszeniach wsparcia, rejestrach CRM, poczcie elektronicznej, platformach analitycznych i narzędziach współpracy.

Zgodnie z GDPR Article 5(2) organizacja musi wykazać rozliczalność. Zgodnie z Article 25 musi wdrożyć ochronę danych w fazie projektowania i domyślną ochronę danych. Zgodnie z Article 32 musi stosować odpowiednie środki techniczne i organizacyjne dla bezpieczeństwa przetwarzania. Jeżeli rozszerzenie eksfiltruje dane osobowe, zdarzenie może stać się naruszeniem ochrony danych osobowych w rozumieniu Article 4(12), uruchamiając ocenę i potencjalnie obowiązki zgłoszeniowe wynikające z Article 33.

Przegląd rozszerzenia uwzględniający prywatność powinien obejmować następujące pytania:

Nie każde rozszerzenie wymaga pełnej DPIA. Jednak rozszerzenia z szerokim dostępem do stron, przetwarzaniem AI, przechwytywaniem ekranu, dostępem do poczty elektronicznej, dostępem do CRM, dostępem do danych HR, danymi obsługi klienta lub regulowanymi danymi finansowymi powinny uruchamiać ustrukturyzowaną ocenę prywatności.

Krok 6: rejestruj i monitoruj na potrzeby audytu i reagowania na incydenty

Program zarządzania rozszerzeniami bez logów nie jest możliwy do prześledzenia audytowo. Osłabia również reagowanie na incydenty, ponieważ organizacja nie może ustalić, kiedy rozszerzenie zostało zainstalowane, kto go używał, która wersja była obecna, kiedy zmieniły się uprawnienia ani czy wystąpiła zablokowana próba instalacji.

[P-LM] Polityka logowania i monitorowania - MŚP wskazuje logi dotyczące „instalacji oprogramowania” jako kluczowy wymóg zarządzania. Instalacja rozszerzenia przeglądarki jest zdarzeniem instalacji oprogramowania i powinna być odpowiednio rejestrowana.

Co najmniej logi powinny obejmować:

Te logi powinny zasilać procesy monitorowania zgodnie ze środkami kontrolnymi 8.15 i 8.16. W zależności od ryzyka mogą również trafiać do SIEM, platformy punktów końcowych lub repozytorium materiału dowodowego zgodności. Alerty należy skonfigurować dla zablokowanych rozszerzeń wysokiego ryzyka, nagłych wzrostów liczby wniosków o rozszerzenia, zmian uprawnień zatwierdzonych rozszerzeń, prób instalacji z nieoficjalnych źródeł oraz prób instalacji przez użytkowników uprzywilejowanych.

Monitorowanie jest również przewagą w kontekście NIS2 i DORA. Zgłaszanie incydentów zgodnie z NIS2 Article 23 zależy od wczesnego wykrycia i oceny wpływu. DORA wymaga solidnej obsługi incydentów ICT i dowodów odporności. Ocena naruszenia w GDPR zależy od wiedzy, co się wydarzyło, kiedy i jakie dane mogły zostać objęte skutkami.

Co chce zobaczyć audytor

Audytor rzadko zadowala się stwierdzeniem typu „blokujemy ryzykowne rozszerzenia”. Oczekuje dowodów zarządzania. Materiał dowodowy musi łączyć politykę, ocenę ryzyka, techniczne egzekwowanie, monitorowanie i odpowiedzialność kierownictwa.

Właśnie tutaj Zenith Controls: The Cross-Compliance Guide staje się wartościowy. Pomaga organizacjom pokazać, w jaki sposób jedno działanie kontrolne wspiera wiele oczekiwań zgodności. Pojedynczy przepływ zatwierdzania rozszerzenia przeglądarki może wspierać środek kontrolny ISO/IEC 27001 8.19, cyberhigienę NIS2, zarządzanie ryzykiem ICT w DORA oraz rozliczalność GDPR, jeżeli materiał dowodowy jest zachowywany i jasno zmapowany.

Powiązanie ISO/IEC 27001:2022 z NIS2, DORA i GDPR

Praktyczna mapa powiązań pomaga CISO wyjaśnić, dlaczego zarządzanie rozszerzeniami przeglądarek nie jest niszową kontrolą techniczną. To środek kontroli zgodności o szerokiej wartości regulacyjnej.

Mapowanie DORA zasługuje na szczególną uwagę. Niektórzy audytorzy i asesorzy będą używać języka COBIT przy przeglądzie zarządzania zmianami ICT. COBIT BAI06 jest powszechnie rozumiany jako Managed IT Changes. Jeżeli rozszerzenia przeglądarek są oprogramowaniem, a ich instalacja zmienia środowisko obliczeniowe użytkownika, instalacja rozszerzeń należy do tej samej logiki zarządzanej zmiany. Zenith Controls: The Cross-Compliance Guide wspiera tę perspektywę audytową, pokazując, jak dowody środków kontrolnych ISO/IEC 27001 można ponownie wykorzystać w różnych oczekiwaniach zgodności.

90-dniowy plan wdrożenia zarządzania rozszerzeniami przeglądarek

Organizacje nie muszą rozwiązywać wszystkiego w jeden tydzień. Praktyczny program można zbudować etapami, zwłaszcza gdy trzeba ostrożnie zarządzać zakłóceniami biznesowymi.

W przypadku organizacji wysokiego ryzyka, zwłaszcza podmiotów finansowych objętych DORA lub podmiotów kluczowych i ważnych objętych NIS2, pierwszy etap egzekwowania powinien priorytetowo obejmować użytkowników z dostępem do systemów krytycznych, danych regulowanych, uprzywilejowanych konsol administracyjnych, platform finansowych, narzędzi obsługi klienta i środowisk programistycznych.

Przekaz na poziomie zarządu

Zarządzania rozszerzeniami przeglądarek nie należy przedstawiać kierownictwu jako projektu utwardzania przeglądarki. Należy je przedstawić jako kontrolę niezweryfikowanego kodu stron trzecich w regulowanych procesach.

Rada i organ zarządzający muszą zrozumieć cztery kwestie:

1. Przeglądarka jest obecnie podstawową platformą biznesową.
2. Rozszerzenia mogą uzyskiwać dostęp do wrażliwych danych SaaS i uwierzytelnionych sesji.
3. Niezarządzane rozszerzenia tworzą ryzyko dostawcy, prywatności, incydentu i odporności.
4. ISO/IEC 27001:2022 zapewnia obronny model kontroli wspierający dowody dla NIS2, DORA i GDPR.

Takie ujęcie przenosi dyskusję z preferencji technicznej na odporność operacyjną. Wspiera również finansowanie zarządzania przeglądarkami w przedsiębiorstwie, integracji z punktami końcowymi, monitorowania, przeglądów prywatności, triage dostawców oraz automatyzacji dowodów audytowych.

Od ślepej plamy do kontroli strategicznej

Problem audytowy Marii nie został spowodowany tym, że jeden analityk zainstalował jedno narzędzie produktywności. Spowodowała go niezarządzana klasa ryzyka. Organizacja zbudowała silny program zgodności wokół widocznych aktywów, widocznych dostawców, widocznych platform SaaS i widocznych punktów końcowych, ale warstwa rozszerzeń przeglądarek pozostała niewidoczna.

Ta luka jest obecnie zbyt istotna, aby ją ignorować.

Rozwiązanie nie jest skomplikowane, ale musi być świadome i konsekwentne. Traktuj przeglądarkę jako część punktu końcowego. Traktuj rozszerzenia jako oprogramowanie. Traktuj twórców rozszerzeń i backendy jako dostawców tam, gdzie jest to właściwe. Traktuj uprawnienia jako dostęp do danych. Traktuj instalację jako zmianę. Traktuj logi jako dowody zgodności.

Obronny program zaczyna się od czterech działań:

1. Wykryj każde rozszerzenie we wszystkich zarządzanych przeglądarkach i punktach końcowych.
2. Zdefiniuj dopuszczalne użytkowanie i zasady domyślnej odmowy, korzystając z Ochrona punktów końcowych - Polityka ochrony przed złośliwym oprogramowaniem - MŚP, P03 Polityka dopuszczalnego użytkowania oraz organizacyjnej Polityki dopuszczalnego użytkowania.
3. Oceniaj wnioski o rozszerzenia według kryteriów dostawcy, chmury, podatności i prywatności wynikających z Polityka bezpieczeństwa dostawców i stron trzecich oraz Polityka wymagań bezpieczeństwa aplikacji - MŚP.
4. Egzekwuj i monitoruj aktywność instalacji przy użyciu zarządzania przeglądarkami, rejestrowania i praktyk dowodowych dostosowanych do Polityka logowania i monitorowania - MŚP.

Dla CISO przygotowujących się do audytów NIS2, DORA, GDPR lub ISO/IEC 27001:2022 zarządzanie rozszerzeniami przeglądarek jest usprawnieniem kontroli o wysokiej wartości, ponieważ zamyka realną ścieżkę ataku, a jednocześnie tworzy dowody możliwe do ponownego użycia w różnych ramach.

Aby przyspieszyć prace, pobierz Zenith Blueprint: An Auditor’s 30-Step Roadmap i zmapuj swoje dowody z Zenith Controls: The Cross-Compliance Guide. Jeśli chcesz przekształcić chaos związany z rozszerzeniami przeglądarek w program zarządzania gotowy do audytu, umów ocenę lub demo Clarysec i zacznij od praktycznego inwentarza, mapy ryzyka oraz 90-dniowego planu kontroli.