Ujednolicony model cyberbezpieczeństwa: jeden spójny obraz dla różnych zespołów

Przegląd

W skrócie

W europejskiej firmie informacje dotyczące cyberbezpieczeństwa były rozproszone pomiędzy różnymi zespołami, narzędziami, raportami i arkuszami kalkulacyjnymi.

Dział IT prowadził techniczną ewidencję zasobów. Zespół bezpieczeństwa zajmował się podatnościami, alertami i incydentami. Zespoły zarządzania ryzykiem i zgodnością odpowiadały za ryzyka, zabezpieczenia i ustalenia audytowe. Dział zakupów posiadał informacje o dostawcach, a zespół ciągłości działania dokumentował krytyczne procesy i wymagania dotyczące odtworzenia.

Każdy z tych zespołów posiadał wartościowe informacje. Nie zawsze jednak korzystano z tego samego obrazu sytuacji.

Ten sam system mógł występować pod różnymi nazwami w kilku narzędziach. Podatność mogła być przypisana do serwera, ale nie do usługi biznesowej, którą ten serwer wspierał. Dostawca mógł znajdować się w rejestrze umów bez powiązania z systemami i danymi, do których miał dostęp. Zabezpieczenie mogło być opisane w polityce, ale bez wskazania, gdzie obowiązywało i czy rzeczywiście działało.

Utrudniało to udzielenie odpowiedzi na podstawowe pytania:

?Które zasoby wspierają najważniejsze procesy biznesowe?
?Które podatności stanowią największe ryzyko operacyjne?
?Którzy dostawcy mają dostęp do krytycznych systemów lub informacji wrażliwych?
?Jakie zabezpieczenia odnoszą się do poszczególnych ryzyk?
?Czy zabezpieczenia te działają zgodnie z założeniami?
?Kto odpowiada za poszczególne zasoby, ryzyka, zabezpieczenia i działania?
?Jakie inne obszary mogą ucierpieć w przypadku awarii systemu, problemu z dostawcą lub nieskuteczności zabezpieczenia?

Pomogliśmy klientowi połączyć istniejące informacje i uporządkować je w ramach wspólnego modelu cyberbezpieczeństwa.

Firma mogła zacząć postrzegać swoje środowisko bezpieczeństwa jako sieć powiązanych elementów, a nie zbiór oddzielnych rejestrów. Zespoły mogły zobaczyć, jak procesy biznesowe, dane, aplikacje, infrastruktura, dostawcy, podatności, zabezpieczenia, ryzyka i działania wpływały na siebie nawzajem.

Najważniejszy rezultat

Różne zespoły zaczęły pracować na podstawie jednego, bardziej spójnego obrazu cyberbezpieczeństwa.

Profil klienta

O kliencie

Europejskie przedsiębiorstwo przemysłowe

Klient poufny · Modelowanie danych cyberbezpieczeństwa

Poufne

Branża

Produkcja przemysłowa i inżynieria

Wielkość firmy

Około 5 000 pracowników

Lokalizacje

Zakłady produkcyjne, centra inżynieryjne i biura administracyjne w kilku krajach europejskich

Środowisko IT

Microsoft 365, usługi chmurowe, infrastruktura lokalna, aplikacje biznesowe, urządzenia końcowe, dostęp zdalny oraz zewnętrzni dostawcy

Środowisko bezpieczeństwa

Monitorowanie bezpieczeństwa, skanowanie podatności, ochrona urządzeń końcowych, narzędzia do zarządzania zasobami, rejestry ryzyka, dokumentacja audytowa, oceny dostawców oraz dokumentacja ciągłości działania

Istotne wymagania

ISO/IEC 27001, ochrona danych, wymagania klientów dotyczące bezpieczeństwa, zobowiązania umowne oraz wymagania w zakresie ciągłości działania

Kontekst zaangażowania: Klient jest europejskim przedsiębiorstwem z sektora produkcji przemysłowej i inżynierii, prowadzącym działalność w kilku krajach. Działalność firmy jest wspierana przez systemy produkcyjne, aplikacje inżynieryjne, korporacyjne usługi IT, platformy chmurowe oraz rozwiązania technologiczne dostarczane przez podmioty zewnętrzne. Odpowiedzialność za informacje dotyczące cyberbezpieczeństwa była rozdzielona pomiędzy kilka obszarów organizacji. Dział IT utrzymywał informacje o zasobach technicznych i konfiguracji. Zespół bezpieczeństwa informacji zarządzał podatnościami, alertami i incydentami. Zespoły ds. ryzyka i zgodności prowadziły rejestry ryzyka, środków kontroli, ocen oraz ustaleń audytowych. Dział zakupów zarządzał informacjami o dostawcach i umowach, natomiast specjaliści ds. ciągłości działania dokumentowali procesy krytyczne, wymagania dotyczące odtwarzania oraz zależności operacyjne. Organizacja posiadała już wdrożony system zarządzania bezpieczeństwem informacji oraz ustanowione procesy dotyczące cyberbezpieczeństwa, zarządzania ryzykiem, zgodności, nadzoru nad dostawcami i ciągłości działania. Informacje powstające w ramach tych procesów były jednak przechowywane w różnych narzędziach, rejestrach i arkuszach kalkulacyjnych.

Nazwa klienta, dokładna liczba pracowników, lokalizacje oraz wybrane informacje operacyjne zostały pominięte ze względu na poufność.

Problem

Wyzwanie

Firmie nie brakowało informacji o cyberbezpieczeństwie. Problem polegał na tym, że informacje te były tworzone w różnych celach i utrzymywane przez różne zespoły.

Inwentaryzacje techniczne zawierały dane o serwerach, urządzeniach końcowych i aplikacjach. Narzędzia do skanowania rejestrowały podatności. Rejestr ryzyka obejmował ryzyka biznesowe i ryzyka bezpieczeństwa informacji. Dokumentacja audytowa zawierała ustalenia oraz dowody. Systemy zakupowe przechowywały informacje o dostawcach i umowach.

Źródła te rzadko korzystały z tej samej struktury.

Usługa biznesowa mogła zależeć od aplikacji, kilku serwerów, platformy chmurowej i zewnętrznego dostawcy. Zależności te nie były jednak widoczne w jednym miejscu.

Gdy pojawiała się nowa podatność, zespół bezpieczeństwa musiał kontaktować się z kilkoma osobami, aby zrozumieć jej znaczenie. Gdy audytor prosił o dowody, zespół zgodności musiał zbierać dokumenty od różnych właścicieli. Jeśli dostawca zmieniał zakres swojej usługi, trudno było ustalić, na jakie procesy, systemy i zabezpieczenia mogła wpłynąć ta zmiana.

Raporty przygotowywano zwykle poprzez eksportowanie danych z oddzielnych narzędzi i ich ręczne łączenie. Zanim raport był gotowy, część informacji mogła być już nieaktualna.

Główny problem

Informacje o cyberbezpieczeństwie istniały – ale były rozproszone i niepowiązane.

Wyzwanie nie polegało na braku danych, ale na niemożności zrozumienia, jak różne fragmenty informacji są ze sobą powiązane, aby wspierać skuteczne podejmowanie decyzji.

Rozproszone informacjeInformacje o cyberbezpieczeństwie były rozproszone pomiędzy różnymi zespołami i narzędziami.

Niespójne nazewnictwoTen sam zasób występował pod różnymi nazwami.

Niepołączone zasobyZasoby techniczne nie zawsze były połączone z procesami biznesowymi.

Oddzielne rejestryRyzyka, podatności i zabezpieczenia były prowadzone w oddzielnych rejestrach.

Ukryte zależnościZależności od dostawców nie były odpowiednio widoczne.

Niejasna odpowiedzialnośćInformacje o właścicielach były niepełne lub niespójne.

Brak automatyzacji zmianZmiany w jednym obszarze nie były automatycznie uwzględniane w powiązanych danych.

Ręczne zbieranie dowodówDowody audytowe trzeba było zbierać ręcznie.

Duży nakład pracy na raportyPrzygotowywanie raportów dla kierownictwa wymagało dużego nakładu pracy.

Rozbieżne wersje danychZespoły podejmowały czasem decyzje na podstawie różnych wersji tych samych informacji.

Klient chciał stworzyć wspólny obraz cyberbezpieczeństwa bez konieczności wymiany wszystkich dotychczasowych narzędzi.

Cele

Co klient chciał osiągnąć

Projekt miał siedem głównych celów:

Stworzyć wspólną strukturę dla najważniejszych informacji o cyberbezpieczeństwie.

Połączyć zasoby techniczne z procesami biznesowymi i możliwymi skutkami operacyjnymi.

Pokazać zależności między ryzykami, podatnościami, zabezpieczeniami i działaniami.

Ułatwić zrozumienie zależności od dostawców i innych podmiotów zewnętrznych.

Przypisać właścicieli do najważniejszych informacji i decyzji.

Ograniczyć liczbę powielonych danych i ręczną pracę przy raportowaniu.

Umożliwić aktualizowanie obrazu cyberbezpieczeństwa wraz ze zmianami w działalności i technologii.

Nasze podejście

Co zrobiliśmy

Zaczęliśmy od decyzji, które zespoły musiały podejmować

Celem nie było zebranie wszystkich dostępnych danych. Najpierw ustaliliśmy, na jakie pytania musiały odpowiadać zespoły bezpieczeństwa, IT, zarządzania ryzykiem i zgodnością oraz kierownictwo.

Przeprowadziliśmy warsztaty z przedstawicielami:

✓IT i infrastruktury;
✓bezpieczeństwa informacji;
✓zarządzania ryzykiem i zgodnością;
✓ochrony danych;
✓zakupów i zarządzania dostawcami;
✓ciągłości działania;
✓wybranych działów biznesowych.

Każdy zespół wyjaśnił, jakie informacje utrzymywał, skąd one pochodziły i w jaki sposób były wykorzystywane.

Pozwoliło to odróżnić informacje potrzebne do podejmowania decyzji od danych, które były dostępne, ale nie miały jasno określonego celu. Ujawniło również powielaną pracę oraz zależności od rejestrów prowadzonych przez inne zespoły.

Uzgodniliśmy wspólny model cyberbezpieczeństwa

Stworzyliśmy wspólną strukturę dla najważniejszych informacji o cyberbezpieczeństwie.

Model łączył:

✓procesy biznesowe;
✓usługi biznesowe;
✓działy i lokalizacje;
✓informacje i dane;
✓aplikacje;
✓serwery, urządzenia końcowe i elementy sieci;
✓tożsamości i konta uprzywilejowane;
✓usługi chmurowe;
✓dostawców i usługi zewnętrzne;
✓zagrożenia i podatności;
✓ryzyka cyberbezpieczeństwa;
✓zabezpieczenia;
✓polityki i procedury;
✓incydenty i ustalenia audytowe;
✓działania związane z postępowaniem z ryzykiem i doskonaleniem;
✓odpowiedzialnych właścicieli;
✓dowody i terminy przeglądów.

Model nie ograniczał się do umieszczenia wszystkich informacji w jednym miejscu. Pokazywał również zależności pomiędzy nimi.

Przykład Usługa chmurowa mogła być na przykład połączona ze wspieraną aplikacją, przetwarzanymi danymi, dostawcą, obowiązującymi zabezpieczeniami, znanymi podatnościami, powiązanymi ryzykami i odpowiedzialnym właścicielem. Dzięki temu łatwiej było zrozumieć możliwe skutki problemu lub zmiany.

Uzgodniliśmy nazwy, odpowiedzialność i wiarygodne źródła danych

Jednym z najbardziej praktycznych problemów było używanie różnych nazw dla tego samego zasobu.

Wprowadziliśmy wspólny identyfikator dla ważnych zasobów i zapisaliśmy alternatywne nazwy występujące w narzędziach technicznych, dokumentacji biznesowej i rejestrach dostawców.

Dla każdego ważnego rodzaju informacji ustaliliśmy również:

✓które źródło należy traktować jako główne;
✓który zespół odpowiada za jego utrzymanie;
✓jak często należy przeglądać dane;
✓w jaki sposób rozwiązywać rozbieżności pomiędzy źródłami;
✓które zmiany wymagają zatwierdzenia;
✓co należy zrobić, gdy brakuje wymaganych informacji.

Nie usunęło to wszystkich różnic od razu. Zapewniło jednak zespołom spójny sposób ich rozwiązywania i stopniowego poprawiania jakości danych.

Połączyliśmy ustalenia techniczne z ich wpływem na działalność

Podatności, incydenty i alerty stały się bardziej użyteczne, gdy można było umieścić je w kontekście biznesowym.

Podatność mogła zostać połączona z:

✓dotkniętym zasobem technicznym;
✓aplikacją działającą na tym zasobie;
✓usługą biznesową wspieraną przez aplikację;
✓przetwarzanymi informacjami;
✓odpowiednim dostawcą;
✓istniejącymi zabezpieczeniami;
✓powiązanym ryzykiem;
✓osobą odpowiedzialną za usunięcie problemu.

Zespół bezpieczeństwa mógł zobaczyć, czy problem techniczny mógł wpłynąć na produkcję, obsługę klientów, operacje finansowe, pracowników albo informacje wrażliwe. Właściciele biznesowi mogli natomiast lepiej zrozumieć, dlaczego dany problem wymagał ich uwagi.

Sprawiliśmy, że model mógł reagować na zmiany

Statyczny rejestr szybko traci wartość, gdy zmieniają się systemy, dostawcy i procesy biznesowe.

Zdefiniowaliśmy więc zdarzenia, które powinny uruchamiać przegląd powiązanych informacji:

✓wdrożenie nowej aplikacji lub usługi chmurowej;
✓istotna zmiana systemu;
✓zmiana dostawcy;
✓wykrycie nowej podatności;
✓incydent bezpieczeństwa;
✓nieskuteczność lub awaria zabezpieczenia;
✓zmiana krytycznego procesu biznesowego;
✓nowe wymaganie prawne, umowne lub klienta;
✓zaległe działanie związane z postępowaniem z ryzykiem.

Gdy występowało jedno z tych zdarzeń, można było przeanalizować wszystkie powiązane elementy, zamiast traktować zmianę jako odizolowaną aktualizację. Zmiana dostawcy mogła na przykład spowodować przegląd usługi, dostępu do danych, umów, zabezpieczeń, rozwiązań zapewniających ciągłość działania i powiązanych ryzyk.

Zastosowaliśmy automatyzację tam, gdzie ograniczała powtarzalną pracę

Automatyzację wprowadziliśmy selektywnie. Jej celem było ograniczenie pracy ręcznej bez usuwania odpowiedzialności i nadzoru człowieka.

Automatyzacja mogła obejmować:

✓importowanie aktualnych danych o zasobach technicznych;
✓łączenie ustaleń ze skanerów ze znanymi zasobami;
✓powiadamianie właścicieli o nowych i zaległych działaniach;
✓wskazywanie danych bez przypisanego właściciela;
✓identyfikowanie zabezpieczeń z nieaktualnymi dowodami;
✓oznaczanie wygasłych wyjątków dotyczących ryzyka;
✓przygotowywanie spójnych informacji do regularnych raportów.

Automatyzacja wspierała proces, ale nie podejmowała decyzji dotyczących ryzyka w imieniu firmy. Właściciele biznesowi nadal odpowiadali za ocenę wpływu. Właściciele zabezpieczeń potwierdzali ich skuteczność. Właściciele ryzyka podejmowali decyzje dotyczące jego akceptacji lub dalszego postępowania.

Wyjaśniliśmy odpowiedzialność poszczególnych zespołów

Wspólny model może działać tylko wtedy, gdy wiadomo, kto odpowiada za utrzymanie poszczególnych informacji.

Przypisaliśmy odpowiedzialność za:

✓procesy i usługi biznesowe;
✓aplikacje i infrastrukturę;
✓zasoby informacyjne;
✓dostawców i umowy;
✓ryzyka cyberbezpieczeństwa;
✓zabezpieczenia i dowody ich działania;
✓usuwanie podatności;
✓działania audytowe i doskonalące;
✓przegląd i rozwiązywanie problemów z jakością danych.

Zespoły nie musiały utrzymywać informacji spoza swojego obszaru odpowiedzialności. Musiały jednak rozumieć, w jaki sposób ich dane były wykorzystywane przez innych i o jakich zmianach należało informować.

Usprawniliśmy raportowanie i analizę wpływu

Połączony model pozwolił przygotowywać raporty na podstawie istniejących zależności zamiast ręcznie łączyć informacje z oddzielnych źródeł.

Raportowanie dla kierownictwa koncentrowało się na:

✓krytycznych usługach z nierozwiązanymi ryzykami;
✓ważnych zasobach bez przypisanych właścicieli;
✓podatnościach o wysokim priorytecie, które wpływały na krytyczne działania;
✓brakujących lub nieskutecznych zabezpieczeniach oraz brakach w dowodach;
✓zależnościach od dostawców wpływających na ważne usługi;
✓zaległych działaniach i wygasłych wyjątkach;
✓incydentach wpływających na powiązane systemy i procesy;
✓decyzjach wymaganych od kierownictwa.

Model wspierał także analizę możliwych skutków. Jeśli krytyczny dostawca zgłaszał problem, firma mogła wskazać usługi, systemy, informacje, zabezpieczenia i właścicieli biznesowych, których problem mógł dotyczyć. Zespoły mogły reagować na podstawie wspólnych informacji, zamiast tworzyć nowy arkusz dla każdego przypadku.

Dostarczone elementy

Co przekazaliśmy klientowi

Klient otrzymał:

✓ujednolicony model najważniejszych informacji o cyberbezpieczeństwie;
✓wspólną strukturę danych biznesowych, technicznych i dotyczących bezpieczeństwa;
✓powiązania pomiędzy procesami, danymi, aplikacjami, infrastrukturą i dostawcami;
✓zależności pomiędzy podatnościami, ryzykami, zabezpieczeniami i działaniami;
✓uzgodniony podział odpowiedzialności za utrzymanie informacji;
✓zasady rozwiązywania problemów z powielonymi i niespójnymi danymi;
✓zdarzenia uruchamiające przegląd powiązanych informacji;
✓wybrane automatyczne aktualizacje, powiadomienia i kontrole;
✓szablony raportów dla kierownictwa;
✓praktyczny proces utrzymywania modelu w aktualnym stanie.

Firma nie musiała wymieniać wszystkich istniejących narzędzi. Projekt stworzył strukturę, która pozwalała łatwiej łączyć, rozumieć i wykorzystywać informacje pochodzące z tych systemów.

Wpływ

Rezultaty

W ciągu dziewięciu miesięcy klient osiągnął następujące rezultaty:

krytycznych usług biznesowych powiązano ze wspierającymi je aplikacjami i infrastrukturą

krytycznych zasobów przypisano do właścicieli technicznych i biznesowych

podatności o wysokim priorytecie powiązano z usługami biznesowymi, na które mogły wpływać

istotnych środków kontroli powiązano z aktualnymi dowodami oraz odpowiedzialnymi właścicielami

mniej zduplikowanych lub niespójnych rekordów dotyczących krytycznych zasobów

mniej czasu na przygotowanie regularnych raportów zarządczych dotyczących cyberbezpieczeństwa

mniej zaległych działań związanych z przypisaniem odpowiedzialności i jakością danych

Klient stworzył wspólną strukturę, która umożliwiła zespołom IT, bezpieczeństwa informacji, zarządzania ryzykiem, zgodności, zakupów oraz ciągłości działania korzystanie z bardziej spójnego obrazu środowiska cyberbezpieczeństwa.

Krytyczne usługi biznesowe zostały powiązane z aplikacjami, infrastrukturą, informacjami, dostawcami oraz środkami kontroli bezpieczeństwa, od których zależało ich funkcjonowanie. Dzięki temu ustalenia techniczne mogły zostać ocenione w szerszym kontekście biznesowym. Firma mogła również ustalać priorytety podatności na podstawie ich potencjalnego wpływu operacyjnego, a nie wyłącznie technicznego poziomu krytyczności.

Wprowadzenie wspólnych identyfikatorów oraz uzgodnionych źródeł referencyjnych ograniczyło niespójności pomiędzy inwentaryzacją techniczną, rejestrami ryzyka, dokumentacją dostawców i zapisami audytowymi. Istotne rekordy zostały przypisane do odpowiedzialnych właścicieli, a także uzupełnione o terminy przeglądów i zasady ich utrzymywania.

Zależności od dostawców stały się również bardziej widoczne. W przypadku zgłoszenia przez dostawcę incydentu, zmiany w usłudze lub nieskuteczności zabezpieczenia firma mogła szybciej zidentyfikować potencjalnie dotknięte systemy, informacje, usługi biznesowe, zobowiązania umowne oraz rozwiązania w zakresie ciągłości działania.

Wybrane mechanizmy automatyzacji ograniczyły powtarzalną pracę poprzez importowanie zaktualizowanych informacji o zasobach technicznych, łączenie wyników skanowania podatności ze znanymi zasobami, powiadamianie właścicieli o nowych i zaległych działaniach, identyfikowanie rekordów bez przypisanego właściciela, wskazywanie nieaktualnych dowodów działania zabezpieczeń, oznaczanie wygasłych akceptacji wyjątków od ryzyka oraz przygotowywanie spójnych informacji do raportów zarządczych.

Automatyzacja wspierała realizację procesu, ale nie zastępowała odpowiedzialności człowieka. Właściciele biznesowi nadal odpowiadali za ocenę wpływu operacyjnego, właściciele kontroli potwierdzali skuteczność zabezpieczeń, a właściciele ryzyka podejmowali decyzje dotyczące sposobu postępowania ze zidentyfikowanym ryzykiem.

Najważniejszym rezultatem było ograniczenie potrzeby ręcznego odtwarzania tych samych zależności podczas analizy incydentu, oceny podatności, przeglądu dostawcy lub przygotowywania raportu zarządczego. Ujednolicony model ułatwił zrozumienie, w jaki sposób zmiana lub problem związany z cyberbezpieczeństwem w jednym obszarze mógł wpłynąć na pozostałą część organizacji.

Transformacja

Co zmieniło się dla klienta

Jeden wspólny obraz

Zespoły IT, bezpieczeństwa, zarządzania ryzykiem, zgodności i biznesowe mogły pracować na podstawie tej samej struktury, nadal korzystając ze swoich specjalistycznych narzędzi.

Jaśniejsze zależności

Firma mogła zobaczyć, w jaki sposób procesy biznesowe zależały od danych, aplikacji, infrastruktury, dostawców i zabezpieczeń.

Lepsza analiza wpływu

Gdy pojawiała się podatność, incydent lub problem z dostawcą, zespoły mogły ustalić, jakie inne obszary były zagrożone.

Mniej powtarzalnej pracy

Nie trzeba było odtwarzać tych samych zależności przy każdym raporcie lub nowym problemie.

Jasna odpowiedzialność

Ważne informacje, ryzyka, zabezpieczenia i działania miały przypisanych właścicieli oraz wymagane terminy przeglądów.

Praktyczna automatyzacja

Rutynowe aktualizacje i kontrole zostały zautomatyzowane tam, gdzie było to uzasadnione. Odpowiedzialność za decyzje nadal pozostawała po stronie wyznaczonych osób.

Wnioski

Czego się nauczyliśmy

Należy zacząć od decyzji, a nie od wszystkich dostępnych danych

Przydatny model cyberbezpieczeństwa powinien pomagać ludziom odpowiadać na ważne pytania. Zbieranie danych bez jasno określonego celu prowadzi jedynie do dodatkowej pracy.

Zależności są równie ważne jak pojedyncze informacje

Sama wiedza o istnieniu serwera, dostawcy czy podatności ma ograniczoną wartość. Trzeba również wiedzieć, co jest od nich zależne.

Wspólny model nie wymaga jednego narzędzia do wszystkiego

Istniejące systemy mogą nadal wspierać specjalistyczne działania, jeżeli ich dane są oparte na wspólnej strukturze i mogą być wiarygodnie łączone.

Każda ważna informacja potrzebuje właściciela

Dane szybko stają się nieaktualne, jeżeli nikt nie odpowiada za ich utrzymanie i przegląd.

Automatyzacja powinna wspierać odpowiedzialność

Automatyzacja dobrze sprawdza się przy aktualizacjach, kontrolach i powiadomieniach. Nie powinna ukrywać odpowiedzialności ani samodzielnie podejmować ważnych decyzji dotyczących ryzyka.

Model musi zmieniać się razem z firmą

Nowe systemy, dostawcy, podatności i wymagania biznesowe powinny uruchamiać przegląd powiązanych informacji.

Referencje

Opinia klienta

„Większość potrzebnych informacji już istniała, ale była utrzymywana przez różne zespoły i zapisywana na różne sposoby. Wspólny model pomógł nam zrozumieć, jak nasze systemy, dostawcy, ryzyka i zabezpieczenia były ze sobą powiązane. Zespoły mogą teraz korzystać z tych samych informacji i lepiej oceniać szersze skutki zmiany lub problemu z bezpieczeństwem."

— [Przedstawiciel klienta]

Poniższy cytat można wykorzystać wyłącznie po uzyskaniu zgody klienta. Jeżeli zatwierdzony cytat nie jest dostępny, tę sekcję należy usunąć.

Podsumowanie

Klient nie potrzebował kolejnej niezależnej bazy danych o cyberbezpieczeństwie. Potrzebował lepszego sposobu łączenia i wykorzystywania informacji, które już posiadał.

Oddzielne zespoły prowadziły wartościowe rejestry, ale zależności pomiędzy tymi informacjami były niepełne. Utrudniało to zrozumienie wzajemnych powiązań, ocenę wpływu na działalność i utrzymywanie aktualnych raportów.

Dzięki stworzeniu ujednoliconego modelu firma połączyła procesy biznesowe, dane, aplikacje, infrastrukturę, dostawców, podatności, zabezpieczenia, ryzyka i odpowiedzialnych właścicieli.

Ustalenia techniczne zyskały kontekst biznesowy. Zależności od dostawców stały się bardziej widoczne. Zmiany mogły uruchamiać przegląd powiązanych ryzyk i zabezpieczeń. Rutynowe kontrole i raportowanie wymagały mniej pracy ręcznej.

Co najważniejsze, różne zespoły mogły podejmować decyzje na podstawie tego samego obrazu środowiska cyberbezpieczeństwa.

Rozpocznij

Czy mierzą się Państwo z podobnym problemem?

Informacje o cyberbezpieczeństwie są często rozproszone pomiędzy narzędziami technicznymi, rejestrami ryzyka, dokumentacją dostawców, raportami audytowymi, politykami i arkuszami kalkulacyjnymi.

Cybersecurity Analytics może pomóc Państwa organizacji:

✓połączyć informacje o cyberbezpieczeństwie utrzymywane przez różne zespoły;
✓powiązać zasoby techniczne z procesami i usługami biznesowymi;
✓pokazać zależności pomiędzy ryzykami, podatnościami i zabezpieczeniami;
✓lepiej zrozumieć zależności od dostawców;
✓przypisać odpowiedzialność za ważne informacje i działania;
✓wprowadzić przydatną automatyzację bez rezygnowania z nadzoru człowieka;
✓przygotowywać bardziej przejrzyste raporty dla kierownictwa.

Cybersecurity Analytics

Połącz swoje informacje o cyberbezpieczeństwie, aby podejmować lepsze decyzje.

Skontaktuj się z nami, aby porozmawiać o tym, jak ujednolicony model cyberbezpieczeństwa może wspierać Państwa organizację.

Porozmawiajmy o modelu danych cyberbezpieczeństwa → Poznaj nasze usługi zarządzania cyberryzykiem

Jak możemy pomóc

Ujednolicony model danych
Połącz informacje o cyberbezpieczeństwie utrzymywane przez różne zespoły i narzędzia.

Połączona wizja ryzyka
Powiąż zasoby techniczne z procesami biznesowymi, dostawcami i usługami.

Praktyczna automatyzacja
Wprowadź przydatną automatyzację bez rezygnowania z nadzoru człowieka.

Jasne raportowanie
Przygotowuj bardziej przejrzyste, oparte na zależnościach raporty dla kierownictwa.

Jak różne zespoły stworzyły jeden spójny obraz cyberbezpieczeństwa