Kontrole mitygujące – czy to lek na „całe zło” w nadmiarowych uprawnieniach w SAP? Część #3/5 – Jak budować repozytorium kontroli mitygujących?
Budowa repozytorium kontroli mitygujących wymaga dobrego zrozumienia ryzyka dostępu, systemu, a przede wszystkim kontekstu, czyli procesów biznesowych (i nie tylko) w których te kontrole osadzamy. Jeśli posiadasz już tą wiedzę, to zapraszamy do lektury artykułu, z którego dowiesz się jak w praktyce utworzyć repozytorium kontroli mitygujących i co tak naprawdę to oznacza.
Jeśli wciąż zastanawiasz się czy potrzebujesz kontroli mitygujących, polecam poprzedni wpis w tej serii (Kontroli mitygujące – czy to lek na „całe zło”?), z którego dowiesz się, kiedy warto je stosować, a kiedy polegać na innych mechanizmach.
Ryzyka, a kontrole mitygujące
Postępowanie z ryzykiem w przypadku dostępu użytkowników do systemów, podlega podobnym regułom jakie stosujemy w przypadku każdego innego rodzaju ryzyka.
Na początek odrobina teorii – kluczowe strategie odpowiedzi na ryzyko obejmują:
- minimalizację (redukcję) ryzyka – działania mające zmniejszyć negatywne efekty zagrożeń,
- transfer (przeniesienie) ryzyka – ubezpieczenie, outsourcing,
- unikanie ryzyka – eliminacja zagrożeń, zmiana zakresu projektu,
- akceptację ryzyka – zazwyczaj przez właściciela ryzyka, procesu, czy kadrę zarządzającą.
Mówiąc teoretycznie o kontrolach mitygujących (czy kompensujących) ryzyko zazwyczaj odnosi się do pierwszej z wymienionych strategii. Jednak w podejściu projektowym jest to pewne uproszczenie, bo tak naprawdę kontrolą mitygującą nazywamy działania w ramach każdej z tych 4 strategii (zdaję sobie w tym miejscu sprawę z tego, jak może to razić purystów teorii zarządzania ryzykiem). Oczywiście jest to pewne uproszczenie, ale bardzo przydatne i ułatwiające późniejszą implementację kontroli mitygujących w rozwiązaniach klasy GRC (o czy w następnym odcinku).
Repozytorium – najtrudniej zacząć…
Tworząc repozytorium kontroli mitygujących warto najpierw zastanowić się co już mamy, a następnie jak możemy to wykorzystać i zoptymalizować. Poniżej przedstawiamy kilka praktycznych podejść, z którymi spotkaliśmy się w naszej praktyce projektowej. Zacznijmy od początku, czyli podejścia, które, na szczęście coraz rzadziej spotykamy na projektach:
Tabula rasa….
Załóżmy, że zidentyfikowaliśmy ryzyka związane z dostępem do systemów, czy konflikty rozdziału (separacji) obowiązków tzw. SoDy i próbujemy je rozwiązać i …. trafiamy na ścianę, tzn. spotykamy się z biznesem, czy innymi udziałowcami projektu i dowiadujemy się, że:
– TAK – oczywiście, że wszystkie ryzyka i konflikty SoD powinny zostać zaadresowane, ale
– NIE – nie zgadzamy się na zmiany, w tym ograniczenie dostępu (albo zgadamy tylko w kilku przypadkach) oraz
– NIE – nie mamy żadnych kontroli mitygujących, które moglibyście wykorzystać do zaadresowania ryzyka
Roboczo nazwijmy to stanowisko biznesu Trójkątem Bermudzkim, w którym znikają wszystkie ryzyka dostępowe, czy konflikty rozdziału obowiązków…. Przynajmniej do czasu audytu lub popełnienia nadużycia, kiedy to w magiczny sposób powrócą w czasie. Wtedy konieczne jest nurkowanie wewnątrz Trójkąta, aby wydobyć na powierzchnię wszystkie słabości, które były głęboko ukrywane.
Poniżej przedstawię krótko podejście, które pozwoli nam tej pułapki uniknąć i zaadresować kwestię ryzyka w usystematyzowany sposób.
Krok Pierwszy – Rozpoznanie
Jeśli pracujesz w organizacji, w której wdrożono system kontroli wewnętrznej w oparciu o COSO, ICFR, podlegasz SOX, J-SOX, czy innej regulacji w zakresie ICS, to zapraszam od razu do Drugiego Kroku.
Dla tych, którzy pracują w organizacjach, gdzie te praktyki nie zostały jeszcze wdrożone, dedykowane są działania, które od lat dobrze sprawdzają się w realizowanych przez nas projektach.
Co może wydawać się na początek zaskakujące, z naszej praktyki wynika, że najlepszym mechanizmem identyfikacji kontroli, który wykorzystujemy na projektach jest rozmowa. Zanim przystąpisz do implementowania tzw. najlepszych praktyk w zakresie kontroli czy przyniesiesz do biznesu benchmarki i standardy do powielania, zacznij od rozmowy z właścicielami i kluczowymi użytkownikami procesów biznesowych
Podstawowe informacje, które chcemy zdobyć w trakcie takiej rozmowy, to przede wszystkim: dobre zrozumienie kontekstu biznesowego w którym ryzyko występuje, jaki to element procesu, kto go wykonuje, jakie działania są realizowane (w systemie i poza systemem), jakie inne elementy procesu są realizowane (raportowanie, zatwierdzanie itd..). Jeśli w trakcie tych rozmów (przejścia przez procesy natrafisz na działania zbliżone do elementów kontrolnych), to warto je szczegółowo opisać (najlepiej zgodnie z zasadą 5W – często stosowaną systematyką opisu kontroli).
Efekty takich spotkań zaskakują, zazwyczaj ponad połowa kontroli, które następnie wykorzystujemy do mitygacji jest już realizowana przez biznes i nie ma potrzeby żadnych dodatkowych działań, aby zaadresować nimi ryzyko czy konflikt SoD.
Krok Drugi – Selekcja
Mając zdefiniowaną listę kontroli wewnętrznych, niezależnie od metody pozyskania – czy poprzez rozpoznanie opisane powyżej, czy na podstawie dostępnej dokumentacji, możemy przystąpić do filtrowania, które z tych kontroli możemy wykorzystać do mitygacji konfliktów SoD.
Przede wszystkim ustalmy kryteria, które będziemy stosować przy wyborze kontroli mitygujących.
Zazwyczaj uwzględnia się co najmniej te aspekty, które są kluczowe dla tworzenia repozytorium:
- proces, w którym kontrola występuje (czy w zakresie analizy SoD),
- zakres organizacyjny – które jednostki są objęte kontrolą, czy to są jednostki w zakresie SoD,
- stopień pokrycia transakcji – czy całość istotnych danych transakcyjnych jest pokryta kontrolą, czy nie pomijamy istotnej części, np. rozpatrywaliśmy tylko wybrany typ zatrudnienia, specyficzne zamówienia itd.,
- wyłączenia – metoda obsługi wyłączenia, kontrole komplementarne,
- aktorzy – osoby wykonujące kontrole vs. osoby realizujące transakcje, czy to te same, czy różne osoby,
- dokumentacja – opis przebiegu kontroli, czy dostępny, czy jesteśmy w stanie uzyskać,
- skuteczność kontroli – jak upewnimy się, czy dana kontrola faktycznie jest wykonywana i skutecznie ogranicza ryzyka.
Mając tak zdefiniowane aspekty analizy, kryteria selekcji nasuwają się same – wybieramy tylko te kontrole, które są adekwatne do zidentyfikowanych ryzyk dostępowych, czy konfliktów SoD.
Bazując na tej wstępnej selekcji będziemy w stanie określić, czy adresujemy potrzeby wszystkich obszarów biznesowych czy też potrzebujemy dodać nowe kontrole, które pozwolą na mitygację w obszarach „białych plam”. To na tym etapie możemy posiłkować się źródłami zewnętrznymi, czyli tzw. najlepszymi praktykami.
Krok Drugi’ (Prim) – Źródła zewnętrzne
Podstawowe źródła zewnętrzne dla kontroli, to oczywiście wszelkiego typu standardy, obejmujące m.in. COSO, CoCo, ICFR, IFC, ICS, CobIT itp. Jeśli poszukujemy informacji, które jest już przetworzona dla potrzeb systemu SAP, to zachęcam do zapoznania się z repozytorium procesów, które SAP udostępnia dla S/4 – jest to kopalnia pomysłów dla kontroli i specyficznych ustawień procesowych.
Dla systemów SAP dostępne są również predefiniowane kontrole automatyczne dostępne np. w rozwiązaniu SAP Process Control szerzej opisane np. tutaj (https://grcadvisory.com/aktualnosci/sap-pc-10-1-12-0-reguly-do-monitorowania-procesow-biznesowych-cz-1/).
W najbliższym czasie planujemy publikację serii artykułów dotyczących kontroli automatycznych w poszczególnych procesach biznesowych, które możemy wykorzystać do mitygacji ryzyk. Udostępnimy link do materiałów zaraz po ich aktualizacji.
Krok Trzeci – Repozytorium
Po zebraniu informacji i wstępnej selekcji możemy przystąpić do budowy repozytorium kontroli.
W zależności od zapotrzebowania i złożoności naszego środowiska przyjmowane są różne kryteria dla potrzeb opisu danych podstawowych, nasze doświadczenia praktyczne wskazują, że w repozytorium kontroli warto ująć co najmniej następujące informacje:
Dane podstawowe
- ID kontroli
- Opis (najlepiej w oparciu o 5W)
- Typ: prewencyjna, detekcyjna, korekcyjna
- Określenie czy kontrola jest zdarzeniowa (opis zdarzeń) czy okresowa (zdefiniowany przedział czasu)
- Automatyzacja wykonania kontroli i testowania (automatyczna, częściowo zautomatyzowana, ręczna)
Kontekst biznesowy
- Proces / podproces / obszar biznesowy
- Jednostka organizacyjna (lub zakres jednostek)
- Właściciel kontroli w danej jednostce, osoby wykonujące kontrole
Kontekst ryzyka
- Powiązane ryzyka (tzn. które ryzyka, konflikty SoD możemy mitygować z wykorzystaniem tej kontroli)
Efektywność mitygacji:
- Wyniki testowania efektywności kontroli (okres / zakres / wynik)
Przypisania do użytkowników:
Niezależnie od powyżej przedstawionych kryteriów, konieczne jest również przechowywanie danych dotyczących przypisania kontroli mitygujących do działań poszczególnych użytkowników. W tym przypadku konieczne jest przechowywanie informacji o:
- konfliktach SoD, ryzykach dostępu zidentyfikowanych na użytkownikach
- sposobie mitygacji (ID kontroli mitygującej)
- zakresie organizacyjnym (identyfikator jednostki, dla której przypisano kontrolę)
- czasu ważności przypisania (maksymalny okres, po którym należy zweryfikować, czy przypisanie wciąż jest aktualne i wymagane)
Dane dotyczące przypisania kontroli do użytkowników jako dane transakcyjne, powinny zostać umieszczone w osobnym repozytorium (powiązanym z repozytorium kontroli).
Krok Czwarty – Utrzymanie aktualności
Utworzenie i zarzadzanie repozytorium wymagają wsparcia w postaci zaplecza narzędziowego. Zależnie od możliwości, którymi nasza firma dysponuje może to być wersja minimum, czyli wykorzystanie arkuszy Excel i udostępnienie ich jednostkom zainteresowanym, a następnie ręczne przypisywanie do ryzyk dostępowych, konfliktów SoD, a w konsekwencji do osób dla których te ryzyka występują (nawet pisząc o tym mam przed oczami koszmar osób, które później będą musiały tym repozytorium zarządzać i ręcznie śledzić wszystkie przypisania, ich wygasanie…).
Istnieje oczywiście szereg dedykowanych produktów automatyzujących pracę, przeznaczonych dla SAP – np. SAP Access Control, czy SmartGRC. Więcej o nich opowiem w kolejnym artykule z serii „. …”
Podsumowując, budowa repozytorium kontroli mitygujących wymaga:
- Znajomości kontekstu biznesowego,
- Identyfikacji działań kontrolnych i właściwej selekcji dla potrzeb mitygacji,
- Dokumentacji w oparciu o ustalone kryteria,
- Wsparcia narzędziowego do zarządzania danymi podstawowymi i przypisaniem do użytkowników.
W kolejnej, czwartej części artykułu przenalizujemy temat automatyzacji i implementacji kontroli w systemach klasy GRC. Omówimy kluczowe funkcjonalności, które powinny być zaimplementowane, aby efektywnie wspierać analizę ryzyka SoD i zarządzanie kontrolami mitygującymi. Zapraszamy do lektury!
