Rama Audytora: Myślenie Jak Audytor IS

Audytor IS nie jest zatrudniany, żeby znaleźć każdy bug lub błędną konfigurację w systemie. Zadanie jest węższe i, szczerze mówiąc, trudniejsze: ustalić, czy istniejące kontroli dają rozsądną pewność, że ryzyka dla biznesu są zarządzane. Ta różnica zmienia podejście do niemal każdego zadania, od czytania zestawu reguł zapory do przeprowadzania rozmów z właścicielem systemu.

Ryzyko najpierw, technologia drugie

Tester penetracyjny pyta "czy mogę to złamać?" Audytor pyta "czy to ma znaczenie i co się stanie z biznesem, jeśli to zawiedzie?" Zanim audytor dotknie jakiekolwiek kontrole, stara się zrozumieć, co robi system, jakie dane dotyka i co pójdzie źle, jeśli będzie zagrożona poufność, integralność lub dostępność. To dlatego programy audytu zwykle rozpoczynają się od oceny ryzyka lub przeglądu, a nie od skanowania luk.

Konkretnie: jeśli audytujesz kontrole dostępu w systemie płac, pierwsze pytanie nie brzmi "czy MFA jest włączone?" Brzmi "jaki jest wpływ, jeśli nieupoważniona osoba może zmienić dane pensji lub przeglądać PII?" Kiedy znasz wpływ, możesz ocenić, czy istniejące kontrole (MFA, przepływy zatwierdzeń, segregacja obowiązków) są proporcjonalne.

Dowody, nie twierdzenia

Właściciele systemów powiedzą ci, że rzeczy działają. Zadaniem audytora jest weryfikacja, nie zaufanie. To oznacza proszenie o artefakty: zrzut ekranu ekranu konfiguracyjnego, eksport praw dostępu użytkowników, bilet zmiany ze znacznikami czasowymi zatwierdzeń, wpisy dziennika pokazujące, że kontrola faktycznie zadziałała. Jeśli ktoś mówi "przeglądamy dostęp co kwartał", audytor prosi zobaczyć ostatnie trzy rekordy przeglądów, nie tylko politykę, która to nakazuje.

Ta nawyk oparty na dowodach to to, co odróżnia wniosek audytowy od rozmowy na korytarzu. Wniosek musi przetrwać kontrolę: co było testowane, jaka populacja została pobrana, jakie kryteria były używane i co faktycznie zaobserwowano. Niejasne stwierdzenia takie jak "kontrole wydają się odpowiednie" nie wytrzymają w raporcie, który czytać będą kierownictwo i organy regulacyjne.

Projektowanie kontra efektywność operacyjna

Jednym z najbardziej użytecznych podziałów mentalnych w tej dziedzinie jest rozdzielenie projektowania kontroli od operacyjności kontroli. Polityka haseł wymagająca 14 znaków i MFA jest dobrze zaprojektowana na papierze. Ale jeśli ostatni przegląd dostępu był 11 miesięcy temu, lub jeśli konta usług są wyłączone bez dokumentacji, kontrola nie działa zgodnie z zamierzeniem. Audytorzy testują oba: czy kontrola istnieje tak jak opisana, i czy faktycznie jest następowana na co dzień?

Dlatego próbkowanie ma znaczenie. Przetestowanie dostępu jednego użytkownika nie mówi wiele. Pobranie próbki 25 pracowników zwolnionych i sprawdzenie, czy ich konta zostały wyłączone w obrębie SLA (powiedzmy, 24 lub 48 godzin) daje ci obronną podstawę do wniosku.

Segregacja obowiązków jako powtarzający się temat

Duża część ustaleń audytu sięga segregacji obowiązków (SoD): ta sama osoba, która żąda zmiany, ją zatwierdza, lub developer ma bezpośredni dostęp do bazy danych w produkcji wraz z prawami wdrażania. Audytorzy szukają tych nakładów stale, ponieważ awarie SoD to jak oszustwa i niezamierzone błędy przechodzą bez drugiego spojrzenia, które by je złapało.

Podczas przeglądania środowiska, zapytaj: kto może zainicjować działanie, kto je zatwierdza, i kto je wykonuje? Jeśli jedna osoba pełni dwie lub więcej z tych ról bez kontroli kompensacyjnej (takiej jak szczegółowe logowanie przeglądane przez kogoś innego), to jest luka warta udokumentowania.

Pisanie ustaleń, które się naprawiają

Ustalenie technicznie poprawne, na które nikt nie działa, to zmarnowany audyt. Dobre ustalenia stwierdzają warunek (co zaobserwowano), kryteria (polityka lub standard, które narusza), przyczynę (dlaczego to się stało) i efekt (jakie ryzyko to tworzy) — klasyczna struktura 4C, którą używa wiele sklepów audytu. Niejasne ustalenia takie jak "kontrole dostępu wymagają poprawy" są ignorowane. Konkretne takie jak "14 z 25 próbkowanych pracowników zwolnionych zachowało dostęp VPN przez więcej niż 5 dni po dacie zwolnienia, naruszając SLA deprovisioning 24-godzinny w polityce SEC-014" są naprawiane, ponieważ właściciel wie dokładnie co naprawić.

Budowanie nawyku

Rozwijasz tę ramę ćwicząc ją na zwykłych systemach, nie tylko na formalnych angażowaniach. Wybierz aplikację, którą używasz każodnia i zapytaj: jakie ryzyko, jeśli zawiedzie, jakie kontrole istnieją, i jak bym to udowodnił? Rób to wystarczająco wiele razy i instynkt audytora — sceptycyzm połączony z wymaganiem dowodów — staje się automatyczny.

Jeśli ten rodzaj myślenia o kontroli i ryzyku ciebie interesuje, sprawdź segmenty Korra Studio dotyczące modeli kontroli dostępu i ramach zarządzania bezpieczeństwem, aby uzyskać głębsze ugruntowanie techniczne.