Zbuduj rejestr ryzyk, który zmienia decyzje

Rejestr ryzyk jest wart swojego miejsca, gdy zmienia priorytety, zasoby lub sposób wdrożenia. Powinien pomóc liderowi technicznemu zdecydować, czy opóźnić wydanie, ograniczyć uprawnienie, sfinansować prace nad odtwarzaniem, czy zaakceptować ekspozycję na określony czas. Lista pozycji oznaczonych na czerwono, żółto i zielono to za mało.

Zacznijcie od scenariuszy, które firma potrafi rozpoznać, zamiast od etykiet w rodzaju „ryzyko cybernetyczne”. Następnie powiążcie każdy scenariusz z dotkniętą usługą, dowodami z oceny, zabezpieczeniami, działaniami w ramach postępowania z ryzykiem i odpowiedzialnym decydentem. Rejestr staje się użyteczny, gdy ktoś potrafi prześledzić ten łańcuch i wyjaśnić, dlaczego kolejne działanie ma znaczenie.

Określ decyzje, zanim zaprojektujesz rejestr

Zacznijcie od jednego produktu, procesu biznesowego lub usługi zarządzanej. Zidentyfikujcie jego krytyczne zależności, ważne informacje, dostawców zewnętrznych i ograniczenia operacyjne. Wyraźnie zawężony zakres ułatwia przetestowanie metody przed jej zastosowaniem w całej organizacji.

Zapytajcie osoby, które będą korzystać z rejestru, jakie decyzje muszą podejmować. Lider platformy może musieć wybrać między usprawnieniem odtwarzania a wymianą przestarzałego komponentu. Kierownik wsparcia może musieć zatwierdzić węższy dostęp bez zakłócania obsługi klientów. CTO może musieć zdecydować, czy uruchomienie może nastąpić mimo niedokończonych działań w ramach postępowania z ryzykiem.

Zdefiniujcie metodę oceny i zasady zatwierdzania, zanim zaczniecie zbierać oceny punktowe. Praktycznym zaleceniem jest udokumentowanie:

• Horyzontu oceny, na przykład ekspozycji w ciągu najbliższych dwunastu miesięcy.
• Definicji prawdopodobieństwa i wpływu, w tym sposobu postępowania ze sprzecznymi wymiarami wpływu.
• Apetytu na ryzyko i progów tolerancji operacyjnej.
• Tego, kto może zatwierdzać postępowanie z ryzykiem i akceptować ekspozycję szczątkową.
• Częstotliwości przeglądów i zdarzeń wymagających ponownej oceny.

Apetyt na ryzyko wyraża, jakie rodzaje i poziomy ryzyka organizacja jest gotowa podejmować lub zatrzymać. Tolerancja przekłada to stanowisko na użyteczne granice, takie jak maksymalny akceptowalny czas przestoju czy ograniczenia dotyczące niekontrolowanego eksportu danych klientów.

W przypadku SZBI zgodnego z ISO/IEC 27001 szacowania ryzyka i postępowania z ryzykiem dotyczą punkty 6.1.2 i 6.1.3. Punkt 8.2 wymaga przeprowadzania ocen w zaplanowanych odstępach czasu oraz wtedy, gdy zachodzą lub są proponowane istotne zmiany. Norma nie narzuca jednego uniwersalnego rocznego harmonogramu ani matrycy ocen. Wasza metoda musi działać w rzeczywistym zakresie SZBI.

Nadaj każdej pozycji strukturę wystarczającą do działania

Rejestr można zacząć w arkuszu kalkulacyjnym. Jego użyteczność zależy od powiązań, odpowiedzialności i utrzymania, a nie od formatu pliku. Bardziej zintegrowane narzędzia zyskują na wartości wtedy, gdy ręczne uzgadnianie danych sprawia, że te powiązania przestają być wiarygodne.

Stosujcie stały identyfikator i niewielki zestaw pól, które odpowiadają na praktyczne pytania. Obszerne dowody techniczne przechowujcie w powiązanych zapisach, zamiast kopiować je do każdego wiersza.

Odróżniajcie status ryzyka od statusu zadania. „Postępowanie z ryzykiem w toku” nie oznacza, że ekspozycja się zmniejszyła. „Zaakceptowane” nie oznacza, że scenariusz zniknął. Zamknięcie zarezerwujcie dla sytuacji, takich jak zakończenie danej działalności lub utrata aktualności scenariusza, i zachowajcie uzasadnienie.

Podobnie podatność, niedziałające zabezpieczenie i ryzyko to powiązane, ale różne zapisy. Brakująca poprawka jest słabością. Nieudana kontrola przy wdrożeniu to problem z zabezpieczeniem. Ryzyko opisuje, co może się wydarzyć z powodu tych warunków i dlaczego ma to znaczenie. Powiązujcie szczegółowe ustalenia z takim scenariuszem, zamiast tworzyć odrębne ryzyko korporacyjne dla każdego wyniku skanera.

Odkrywaj scenariusze na podstawie tego, jak działa usługa

Do identyfikacji ryzyk wykorzystujcie dowody architektoniczne i operacyjne. Zaproście do ukierunkowanej dyskusji zespoły inżynierskie, bezpieczeństwa, właścicieli usług, wsparcie i odpowiednie funkcje biznesowe. Same polityki rzadko ujawniają, gdzie uprawnienia są szersze niż zamierzono, gdzie odtwarzanie zależy od jednej osoby lub gdzie dostawca stał się krytyczną zależnością.

Przydatne dane wejściowe to diagramy przepływu danych, przeglądy uprawnień, rejestry incydentów, testy odtwarzania, oceny dostawców, wyniki wykrywania podatności, propozycje zmian i nierozwiązane obserwacje z audytów. Modelowanie zagrożeń może pomóc zespołom przeanalizować granice zaufania i prawdopodobne ścieżki awarii.

Użyteczny scenariusz ma następującą postać: zdarzenie dotyka konkretnej usługi poprzez możliwą do wskazania słabość i wywołuje określone skutki.

Na przykład: przejęte konto wsparcia technicznego umożliwia eksport danych klientów, ponieważ uprawnienia są nadmierne, co prowadzi do nieuprawnionego ujawnienia i konieczności podjęcia działań reagowania. To sformułowanie jest bardziej przydatne do działania niż „przejęcie konta”. Wskazuje zarówno ścieżkę ataku, jak i zabezpieczenia, które mogłyby ją przerwać.

Wyjdźcie poza poufność. Uwzględnijcie przestoje, uszkodzone zapisy, nieudane odtwarzanie, zakłócenia po stronie dostawców, nadużycia administracyjne i brak dostępu do wiedzy eksperckiej. W przypadku funkcji opartych na AI rozważcie działania podjęte na podstawie błędnych wyników, przekazanie wrażliwych informacji do nieodpowiedniej usługi lub działanie agenta wykraczające poza zamierzone uprawnienia.

Starannie usuwajcie duplikaty scenariuszy. Dwie usługi mogą współdzielić dostawcę tożsamości, ale mieć różne skutki i opcje postępowania z ryzykiem. Z kolei kilka ustaleń może składać się na jeden scenariusz eksportu. Agregujcie tam, gdzie decyzja i właściciel są wspólni; rozdzielajcie tam, gdzie różnią się skutki biznesowe lub decyzje dotyczące postępowania z ryzykiem.

Luki w rozpoznaniu dokumentujcie jako zadania. Jeśli nikt nie wie, którzy klienci korzystają z funkcji eksportu, ta niepewność powinna skutkować zadaniem wyjaśniającym, a nie wymyślonym oszacowaniem wpływu.

Oceniaj ekspozycję bez sztucznej precyzji

Ustal wspólny język oceny

Prawdopodobieństwo i wpływ wymagają definicji, które oceniający mogą stosować spójnie. W przypadku prawdopodobieństwa odróżniajcie aktywność zagrożeń od prawdopodobieństwa powodzenia całego scenariusza. Częste próby phishingu nie oznaczają automatycznie częstego masowego ujawniania danych: na ścieżkę ataku wpływają uwierzytelnianie, uprawnienia, zabezpieczenia sesji i ograniczenia eksportu.

Wpływ powinien odzwierciedlać skutek biznesowy. Uwzględnijcie przerwanie usługi, ujawnienie, utratę integralności, koszty reagowania, konsekwencje umowne i, tam gdzie to istotne, szkody dla osób, których to dotyczy. Udokumentujcie regułę agregacji. Jeśli metoda wykorzystuje najwyższy istotny wymiar wpływu, zapiszcie to; w przeciwnym razie średnia może ukryć poważny skutek dla poufności za mniejszymi skutkami operacyjnymi.

Prosta matryca porządkowa może wspierać wstępną kategoryzację. Mnożenie dwóch liczb kategorii daje jednak indeks, a nie zmierzone prawdopodobieństwo czy stratę pieniężną. Nie sumujcie tych ocen dla różnych usług i nie nazywajcie wyniku całkowitą ekspozycją przedsiębiorstwa. Stosujcie ocenę razem z uzasadnieniem, pilnością, niepewnością i zależnościami postępowania z ryzykiem.

Kalibrujcie oceny wspólnie. Niech właściciele niezależnie ocenią kilka reprezentatywnych scenariuszy, porównają swoje rozumowanie i rozstrzygną różnice w odniesieniu do definicji. To bardziej użyteczne niż pozwolenie każdemu działowi na wypracowanie własnej interpretacji słowa „wysokie”.

Oddziel ryzyko nieodłączne, bieżące ryzyko szczątkowe i docelowe ryzyko szczątkowe

Jasno zdefiniujcie punkt odniesienia dla ryzyka nieodłącznego. Może on opisywać scenariusz bez wybranych zabezpieczeń, ale nadal powinien określać zakładaną architekturę usługi i działalność biznesową. W przeciwnym razie oceniający mogą wyobrażać sobie niezgodne ze sobą wersje stanu „bez zabezpieczeń”.

Bieżące ryzyko szczątkowe odzwierciedla zabezpieczenia, które są wdrożone i poparte odpowiednimi dowodami skuteczności. Docelowe ryzyko szczątkowe to oczekiwana ekspozycja po zaplanowanym postępowaniu z ryzykiem. Utrzymujcie oba widoczne: planowane ograniczenie dostępu nie może obniżać dzisiejszej oceny.

Nie każde zabezpieczenie zmienia oba wymiary. Silniejsze uwierzytelnianie może zmniejszyć prawdopodobieństwo. Węższe uprawnienia do eksportu mogą ograniczyć ilość narażonych danych. Przetestowane procedury reagowania mogą ograniczyć skutki po wykryciu zdarzenia. Opisujcie mechanizm działania, zamiast stosować ogólną procentową redukcję tylko dlatego, że zabezpieczenie istnieje.

Zachowaj niepewność i stosuj analizę ilościową wybiórczo

Dokumentujcie założenia, daty dowodów, luki w pokryciu i poziom pewności. „Brak wcześniejszych incydentów” jest słabym dowodem, jeśli logowanie nie jest w stanie wykryć danego zdarzenia. Niska pewność powinna skutkować wyjaśnieniem sprawy; nie powinna automatycznie wymuszać najwyższej oceny.

W przypadku kosztownych decyzji dotyczących postępowania z ryzykiem uzupełnijcie ocenę jakościową analizą finansową opartą na scenariuszach. Stosujcie przedziały częstotliwości zdarzeń i skutków, identyfikujcie główne czynniki kosztowe i sprawdzajcie, jak zmienia się decyzja przy różnych założeniach. Symulacja może pomóc w zbadaniu tych przedziałów, ale nie naprawi niepopartych danych wejściowych.

Jako przykładowe obliczenie załóżmy częstotliwość zdarzeń od 0,05 do 0,2 rocznie i straty od 100 000 € do 400 000 € na zdarzenie. Pomnożenie wartości skrajnych daje przybliżony przedział roczny od 5000 € do 80 000 €. To punkt wyjścia do dyskusji, a nie prognoza ani uzasadnienie dla ignorowania rzadkich, poważnych skutków. Wyjaśnijcie, jakie dodatkowe dowody pozwoliłyby zawęzić ten przedział.

Powiąż zabezpieczenia ze ścieżką awarii

Mapowanie zabezpieczeń powinno wyjaśniać związki przyczynowe. W scenariuszu z kontem wsparcia uwierzytelnianie przeciwdziała przejęciu konta, autoryzacja ogranicza dostępne zapisy, ograniczenia eksportu limitują możliwość wyprowadzenia danych, a monitorowanie wspiera wykrywanie. Polityka określająca obowiązki dotyczące dostępu jest istotna, ale nie dowodzi, że te ograniczenia techniczne działają.

Utrzymujcie relacje wiele-do-wielu: jedno zabezpieczenie tożsamości może wspierać kilka ryzyk, a jedno ryzyko może zależeć od wielu zabezpieczeń. Uwzględniajcie zakres i zależności. Zabezpieczenie uwierzytelniania obejmujące pracowników, ale wyłączające konta dostawców, nie może uzasadniać tego samego wniosku dla obu grup.

Oceniajcie trzy odrębne kwestie:

• Projekt: czy zabezpieczenie przerwałoby lub ograniczyło scenariusz, gdyby działało zgodnie z zamierzeniem?
• Wdrożenie: czy jest wdrożone we wszystkich odpowiednich systemach, tożsamościach i przepływach pracy?
• Działanie: czy aktualne dowody pokazują, że nadal działa?

W przypadku ograniczeń dostępu dowodami mogą być definicje ról, faktyczne przypisania, negatywne testy autoryzacji i zrealizowane usunięcia uprawnień. W przypadku odtwarzania konfiguracja kopii zapasowych dowodzi mniej niż test odtwarzania z kontrolą integralności i zmierzonym wynikiem odtworzenia. W przypadku monitorowania eksportu wykażcie, że zdarzenie jest rejestrowane, alert trafia do osoby reagującej, a ta osoba jest w stanie je zbadać.

Przechowujcie razem z dowodami informacje o ich pochodzeniu: źródło, czas zebrania, zakres, osobę dokonującą przeglądu i ograniczenia. Wiek dowodów należy oceniać w kontekście. Eksport konfiguracji może się zdezaktualizować po wdrożeniu; wynik ćwiczenia może pozostać użyteczny, dopóki nie zmieni się architektura lub podział odpowiedzialności.

Nie obniżajcie ryzyka szczątkowego proporcjonalnie do liczby zakończonych zadań. Trzy zamknięte zgłoszenia z czterech nie oznaczają redukcji o 75%. Brakujące zgłoszenie może dotyczyć jedynego zabezpieczenia, które ogranicza ujawnienie. Po zweryfikowanych zmianach przejrzyjcie scenariusz, a następnie zapiszcie, dlaczego wniosek się zmienił.

Wybierz sposób postępowania z ryzykiem i jawnie przedstaw kompromis

Typowe opcje postępowania z ryzykiem to unikanie, ograniczanie, dzielenie się lub przeniesienie oraz akceptacja ryzyka. Można je łączyć, ale każda wymaga określonego celu.

Unikanie kończy lub zmienia działalność, która tworzy ekspozycję. Niekoniecznie eliminuje każde powiązane ryzyko. Usunięcie funkcji może wprowadzić procesy ręczne, które wymagają własnej oceny.

Ograniczanie powinno uwzględniać zabezpieczenia prewencyjne i środki ograniczające skutki. Porównajcie nakład pracy inżynierskiej, utrudnienia operacyjne, zależności, oczekiwane korzyści i czas do uzyskania efektu. Natychmiastowe ograniczenie może być lepsze niż silniejsza zmiana architektoniczna, której nie da się dostarczyć przez kilka miesięcy; rejestr powinien uwzględniać oba etapy.

Przeniesienie umowne i ubezpieczenie nie usuwają wszystkich skutków operacyjnych. Klauzula odszkodowawcza dostawcy nie przywróci Waszej usługi, a ubezpieczenie nie cofnie ujawnienia danych. Jeśli w grę wchodzi przetwarzanie danych osobowych, outsourcing nie znosi również obowiązków wynikających z roli na gruncie RODO; art. 28 i 32 pozostają istotne dla umów z podmiotami przetwarzającymi i środków bezpieczeństwa.

Akceptacja jest świadomą decyzją, a nie brakiem budżetu czy przeterminowanym zgłoszeniem. Zapiszcie uzasadnienie biznesowe, aktualne dowody, pozostającą ekspozycję, organ zatwierdzający, czas obowiązywania i warunki wymagające przeglądu. Koszt ma znaczenie, ale nie jest jedynym kryterium: obowiązki prawne, zobowiązania wobec klientów i skutki mogą wykluczyć opcję, która poza tym byłaby wygodna.

Każdemu działaniu w ramach postępowania z ryzykiem przypiszcie właściciela wdrożenia, zobowiązanie zasobowe, termin docelowy, zależności i test ukończenia. Właściciel ryzyka pozostaje odpowiedzialny za całość oceny i reakcji; właściciele zadań dostarczają poszczególne zmiany. Upoważniona osoba dokonująca przeglądu zatwierdza decyzję o postępowaniu z ryzykiem i wszelką pozostającą ekspozycję zgodnie z zasadami organizacji.

Określcie zasady eskalacji, zanim prace utkną. Na przykład niedotrzymany kamień milowy wpływający na zbliżające się uruchomienie powinien wywołać decyzję o uruchomieniu, a nie jedynie przesunięcie terminu. Zapisujcie także odrzucone alternatywy, zwłaszcza gdy wyjaśniają, dlaczego wybrano rozwiązanie tymczasowe.

Przykład: ryzyko eksportu z konta wsparcia

Poniższy przykład ma charakter poglądowy. Załóżmy, że usługa programowa ma dwudziestu użytkowników wsparcia, dane klientów dostępne przez konsolę wsparcia oraz funkcję masowego eksportu odziedziczoną po wcześniejszym modelu operacyjnym. Jednokrotne logowanie (SSO) jest wdrożone, ale uprawnienia do masowego eksportu są nadane szeroko. Istniejące logi rejestrują eksporty, choć żaden alert nie został przetestowany.

Scenariusz brzmi: atakujący przejmuje sesję wsparcia i wykorzystuje nadmierne uprawnienia do eksportu danych klientów, co prowadzi do nieuprawnionego ujawnienia i konieczności działań wobec klientów.

Za ryzyko odpowiada właściciel usługi. Lider ds. tożsamości odpowiada za zmiany w uwierzytelnianiu, zespół aplikacyjny za autoryzację, a zespół operacji bezpieczeństwa za testowanie wykrywania.

Zgodnie z pięciostopniową metodą tej hipotetycznej organizacji ryzyko nieodłączne ocenia się na prawdopodobieństwo 4 i wpływ 4. Bieżące ryzyko szczątkowe to prawdopodobieństwo 3 i wpływ 4: istniejące uwierzytelnianie zapewnia pewną ochronę, ale szerokie uprawnienia pozostawiają znaczącą ścieżkę ujawnienia. Pewność oceny jest umiarkowana, ponieważ zabezpieczenia sesji i maksymalny wolumen eksportu nie zostały jeszcze przetestowane. Liczby te są poglądowymi ocenami kategorii, a nie prawdopodobieństwami.

Zespół porównuje trzy opcje: usunięcie masowych eksportów, ograniczenie ich do zatwierdzonych użytkowników albo zachowanie obecnego dostępu przy silniejszym monitorowaniu. Zespół wsparcia wykazuje uzasadnioną potrzebę ograniczonych eksportów. Właściciel wybiera ograniczanie ryzyka poprzez zawężony dostęp, silniejsze uwierzytelnianie dla pozostałych użytkowników uprzywilejowanych i przetestowane alerty dotyczące eksportu.

Załóżmy, że realizacja wymaga dwunastu dni pracy inżynierskiej w ciągu czterech tygodni. Te wartości są założeniami planistycznymi, a nie benchmarkami rynkowymi. Rejestr łączy prace z planem dostaw i dokumentuje tymczasowe ograniczenia na czas, gdy wdrożenie nie jest jeszcze ukończone.

Docelowe ryzyko szczątkowe to prawdopodobieństwo 2 i wpływ 3, pod warunkiem weryfikacji. Pozostaje ono wartością docelową, dopóki testy nie zakończą się powodzeniem. Po wdrożeniu osoba dokonująca przeglądu odkrywa, że starszy endpoint omija nowe ograniczenie wolumenu. Ocena wpływu pozostaje więc na poziomie 4, a obejście staje się blokującym zadaniem w ramach postępowania z ryzykiem.

Po poprawce i ponownym teście właściciel ponownie ocenia całą ścieżkę. Wszelka pozostająca ekspozycja otrzymuje wyraźne zatwierdzenie i termin przeglądu. Nowa integracja eksportu, nieudany przegląd uprawnień lub istotny wzrost liczby dostępnych zapisów wyzwala wcześniejszą ponowną ocenę. Rejestr zmienił teraz wdrożenie, kolejność prac i zatwierdzenia, a nie tylko udokumentował obawy.

Zbuduj pętlę monitorowania, która prowadzi do decyzji

Zaplanowane przeglądy pozostają użyteczne, ale zmiany zachodzące między nimi muszą docierać do właściciela. Powiążcie sygnały operacyjne ze scenariuszami, na które wpływają. Istotne zdarzenia wyzwalające to m.in. nieudane usunięcia dostępu, nowi dostawcy, zmiany architektury, incydenty, niepowodzenia testów zabezpieczeń i nowe informacje o zagrożeniach.

Dla każdego zdarzenia wyzwalającego określcie jego źródło, zakres, którego dotyczy, sposób kierowania, oczekiwany czas reakcji i osobę dokonującą przeglądu. Praktycznym zaleceniem jest odróżnianie pilnej ekspozycji wymagającej natychmiastowych działań operacyjnych od rutynowego odświeżenia dowodów. Nie czekajcie na spotkanie dotyczące ryzyka, by opanować trwający incydent.

Częstotliwość monitorowania powinna odzwierciedlać to, jak szybko zmienia się zabezpieczenie i jak poważne byłyby skutki jego zawiedzenia. Zautomatyzowane kontrole konfiguracji mogą działać często; ćwiczenie odtwarzania czy przegląd dostawcy wymagają innego rytmu. Słowo „ciągłe” powinno opisywać stały proces operacyjny, a nie sugerować, że każde zabezpieczenie jest testowane co sekundę.

Zaprojektujcie obsługę awarii samego monitorowania. Odłączone źródło lub nieaktualna inwentaryzacja powinny pojawiać się jako nieznane pokrycie, a nie jako zabezpieczenie, które przeszło kontrolę. Usuwajcie duplikaty powtarzających się alertów i grupujcie wspólne awarie, tak aby właściciele otrzymywali kontekst umożliwiający działanie, a nie dziesiątki identycznych powiadomień.

Gdy pojawi się sygnał, zapiszcie, co się zmieniło, które scenariusze zostały rozważone, jakie podjęto natychmiastowe działanie i czy ponowna ocena zmieniła decyzję o postępowaniu z ryzykiem. Nieudany przegląd uprawnień może uzasadniać wyjaśnienie sprawy bez automatycznej zmiany każdej powiązanej oceny. I odwrotnie: potwierdzony nadmierny dostęp do wrażliwych zapisów może natychmiast unieważnić dotychczasową ocenę ryzyka szczątkowego.

Ciągłe monitorowanie zabezpieczeń przynosi największą wartość, gdy jego wyniki docierają zarówno do osób obsługujących zabezpieczenia, jak i do właścicieli odpowiedzialnych za powiązaną ekspozycję.

Wykorzystuj AI do przygotowania ocen, a nie do ich zatwierdzania

AI może pomagać w tworzeniu projektów scenariuszy, uzgadnianiu dowodów, podsumowywaniu zmian, identyfikowaniu możliwych mapowań zabezpieczeń i proponowaniu priorytetów. Jej wyniki powinny pozostać projektami podlegającymi przeglądowi.

Zacznijcie od wąskiego przepływu pracy, którego wyniki można sprawdzić. Wymagajcie odwołań do źródeł i odróżniajcie fakty wyodrębnione ze źródeł od wniosków wywnioskowanych. Sprawdzajcie brakujące pokrycie, sprzeczne zapisy, nieaktualne dokumenty i niepoparte założenia. Dopracowane podsumowanie nie jest dowodem, że źródła, na których się opiera, są ze sobą zgodne.

Przy ustalaniu priorytetów podatności wykorzystujcie kontekst biznesowy obok sygnałów zewnętrznych. Krytyczność opisuje potencjalne skutki techniczne; prawdopodobieństwo wykorzystania i potwierdzone wykorzystanie wskazują różne aspekty aktywności zagrożeń. Żadne z nich nie mówi, czy dotknięty komponent jest wdrożony, osiągalny, uprzywilejowany lub stanowi część krytycznej usługi. AI może pomagać w korelacji, ale kontrole inwentaryzacji i ekspozycji pozostają niezbędne.

Informacje o dostawcach wymagają podobnej dyscypliny: odróżniajcie fakty dotyczące zakontraktowanego dostawcy i jego usługi od spekulacji na temat powiązanej spółki. Analityka behawioralna również wymaga ostrożności, ponieważ nietypowa aktywność nie jest automatycznie złośliwa, a monitorowanie pracowników może rodzić kwestie z zakresu ochrony prywatności i prawa pracy.

Zarządzajcie także samym przepływem pracy AI. Stosujcie zasadę najmniejszych uprawnień, ograniczajcie wrażliwe dane wejściowe, przechowujcie historię wyników podlegającą przeglądowi i określcie, kiedy zmiana modelu lub promptu wymaga ponownych testów. Historyczne dane o incydentach mogą utrwalać martwe pola: słabo monitorowane usługi mogą wydawać się bezpieczniejsze tylko dlatego, że zarejestrowano w nich mniej zdarzeń.

Wyniki predykcyjne powinny być hipotezami z przypisanymi właścicielami i zadaniami walidacyjnymi. Wygenerowana ocena powinna pozostać propozycją, dopóki nie zostanie sprawdzona względem uzgodnionej metody. Ocenę i postępowanie z ryzykiem zatwierdza odpowiedzialny właściciel.

Wykorzystywanie AI do prac nad ryzykiem nie czyni automatycznie systemu systemem wysokiego ryzyka w rozumieniu unijnego aktu w sprawie sztucznej inteligencji. Klasyfikacja zależy od przypadku użycia i roli; wymagania art. 9 dotyczące zarządzania ryzykiem odnoszą się do systemów wysokiego ryzyka. Informacje o zakresie stosowania i terminach znajdziecie w aktualnym omówieniu Komisji. NIST AI RMF zawiera dobrowolne wytyczne dotyczące ładu, a nie gwarancję zgodności.

Raportuj ścieżkę decyzji i sprawdzaj, czy rejestr działa

Zespoły inżynierskie potrzebują informacji o dotkniętych systemach, blokujących zależnościach, kryteriach weryfikacji i nadchodzących decyzjach. Kierownictwo potrzebuje informacji o istotnej ekspozycji, opcjach postępowania z ryzykiem, zapotrzebowaniu na zasoby i zmianach od poprzedniego przeglądu. Oba widoki powinny wynikać z tej samej oceny bazowej.

Zachowujcie historię ocen zamiast ją nadpisywać. Przechowujcie poprzedni wniosek, nowe dowody, zmienione założenia, osobę dokonującą przeglądu, zatwierdzenie i datę. Utrzymujcie widoczność zaakceptowanych ryzyk, w tym zbliżających się terminów wygaśnięcia i warunków, które przestały obowiązywać.

Użyteczne mierniki operacyjne to wiek ryzyk oczekujących na decyzję, zaległe kamienie milowe postępowania z ryzykiem, czas od istotnej zmiany do ponownej oceny oraz odsetek istotnych scenariuszy popartych aktualnymi dowodami dotyczącymi zabezpieczeń. Porównujcie mierniki z własnym punktem odniesienia. Liczba pozycji czy wygenerowanych rekomendacji opisuje głównie aktywność, a nie lepsze decyzje. Mierniki SZBI powinny pomagać ujawniać zablokowaną odpowiedzialność i niepoparte wnioski.

Secani łączy ryzyka, wymagania, zabezpieczenia i dowody w przestrzeni roboczej SZBI. Dla pierwszego, wąskiego zakresu zamodelujcie wspierające systemy i dostawców, powiążcie istniejące dowody z zabezpieczeniami lub decyzjami, które wspierają, i przekształćcie luki w zadania z przypisanymi właścicielami. Weryfikujcie sugestie wspierane przez AI względem ich źródeł oraz zachowujcie zatwierdzenia ludzi, komentarze i znaczniki czasu. Dokumentacja opisuje ten przepływ pracy skoncentrowany na dowodach.

Zacznijcie od pięciu istotnych scenariuszy. Dla każdego potwierdźcie właściciela, aktualne uzasadnienie oceny, decyzję o postępowaniu z ryzykiem, dowody weryfikacji i kolejne zdarzenie wyzwalające przegląd. Następnie weźcie jeden z nich na prawdziwe spotkanie planistyczne i zapytajcie, co powinno się zmienić. Jeśli odpowiedzią jest granica uprawnień, kolejność dostaw, sfinansowane zadanie lub wyraźna decyzja o akceptacji, rejestr wykonuje użyteczną pracę.