Pomiar wpływu automatyzacji

Automatyzacja to inwestycja. Tworzenie i utrzymywanie playbooków wymaga czasu inżynierów. Aby uzasadnić te nakłady i wiedzieć, co należy poprawić, trzeba mierzyć wpływ każdego zautomatyzowanego procesu.

Bez metryk nie można odróżnić playbooka, który oszczędza wiele godzin tygodniowo, od takiego, który po cichu szybciej podejmuje błędne decyzje. Pomiar przekształca automatyzację z działania opartego na przeczuciu w dyscyplinę inżynierską.

Najbardziej intuicyjną metryką jest czas pracy analityka zaoszczędzony. Dla każdego zautomatyzowanego zadania należy oszacować czas bazowy wykonania ręcznego, a następnie pomnożyć go przez liczbę uruchomień.

Jeśli ręczne przeprowadzenie wstępnej analizy phishingu trwało 30 minut i odbywa się 200 razy w miesiącu:

Dwie metryki cyklu życia opisują wydajność SOC:

• MTTD (średni czas wykrycia, Mean Time To Detect) — czas od przejęcia do wykrycia. SOAR ma na niego mniejszy wpływ; jest to przede wszystkim metryka inżynierii wykrywania.
• MTTR (średni czas reakcji, Mean Time To Respond) — czas od wykrycia do powstrzymania zagrożenia. To obszar, w którym SOAR sprawdza się najlepiej.

Należy śledzić MTTR przed wdrożeniem playbooka i po nim. Skrócenie czasu z godzin do minut jest najbardziej oczywistym dowodem skuteczności automatyzacji.

Wskaźnik automatyzacji to udział zdarzeń obsłużonych w pełni lub częściowo przez playbooki w porównaniu ze zdarzeniami wymagającymi pracy ręcznej.

Należy podzielić go na następujące kategorie:

• W pełni zautomatyzowane — zamknięte bez udziału człowieka.
• Wspomagane przez analityka — playbook przeprowadził wzbogacanie danych, a analityk podjął decyzję.
• W pełni ręczne — nie zastosowano żadnego playbooka.

Wzrost udziału spraw w pełni zautomatyzowanych i wspomaganych przez analityka pokazuje zwiększający się zakres objęcia automatyzacją; stagnacja tego wskaźnika sygnalizuje playbooki wymagające rozszerzenia.

Szybkość nie ma znaczenia, jeśli decyzje są błędne. Metryki wydajności należy łączyć z metrykami jakości:

• Wskaźnik fałszywie pozytywnych wyników automatycznych zamknięć (czy playbook zamknął sprawę dotyczącą rzeczywistego zagrożenia?).
• Wskaźnik ponownego otwarcia — spraw zamkniętych przez playbook, które analityk musiał ponownie otworzyć.
• Wskaźnik odrzuceń — częstotliwość, z jaką analitycy odrzucają rekomendowane przez playbook działanie.

Szybki playbook z wysokim wskaźnikiem odrzuceń nie oszczędza czasu; podważa zaufanie do automatyzacji.

Niektóre liczby wyglądają imponująco, ale wprowadzają w błąd. Liczba wykonań playbooka jest metryką próżności, jeśli te wykonania obsługują trywialne lub zduplikowane zdarzenia.

Playbook uruchamiany 10 000 razy w miesiącu może sprawiać wrażenie produktywnego, ale jeśli 9 000 z tych uruchomień dotyczy zduplikowanych alertów, które powinien był stłumić, prawdziwym problemem jest szum u źródła, a nie wartość automatyzacji. Należy zawsze odnosić liczbę aktywności do wyników i zaoszczędzonego czasu.

Można mierzyć tylko to, co jest rejestrowane. Należy uwzględnić telemetrię w każdym playbooku: na początku i na końcu rejestrować ustrukturyzowany wpis zawierający decyzję, czas trwania i zdarzenie źródłowe.

Wpływ jest wartością porównawczą, dlatego potrzebna jest wartość początkowa. Przed wdrożeniem automatyzacji należy zarejestrować bieżący MTTR, czas obsługi ręcznej oraz liczbę godzin pracy analityków dla każdego typu alertu.

Zespoły, które pomijają wartość początkową, nigdy nie mogą udowodnić wartości automatyzacji; mają tylko wartość po automatyzacji, bez punktu odniesienia. Należy zapisać wartość początkową, nawet w nieformalny sposób, a następnie ponownie wykonać pomiar po uruchomieniu każdego playbooka.

Kadra kierownicza interesuje się ryzykiem i kosztami, a nie szczegółami działania playbooków. Należy przełożyć metryki na jej język:

• Zaoszczędzone godziny wyrażone jako odzyskana przepustowość w przeliczeniu na pełne etaty (FTE).
• Redukcję MTTR należy przedstawiać jako skrócenie czasu obecności atakującego w środowisku i zmniejszenie ryzyka naruszenia bezpieczeństwa.
• Spójność i zakres audytów należy przedstawiać jako gotowość do spełnienia wymagań zgodności.

Pojedynczy dashboard łączący automatyzację z czasem, ryzykiem i kosztami pomaga zapewnić finansowanie programu.

Metryki zasilają pętlę informacji zwrotnej. Należy przeglądać je w ustalonych odstępach, aby decydować, co tworzyć, naprawiać lub wycofywać.

• Wysoki odsetek nadpisań -> logika decyzyjna jest błędna; należy ją dopracować.
• Niski odsetek automatyzacji w przypadku alertu generującego dużo szumu -> kandydat do nowego playbooka.
• Playbook uruchamiany rzadko -> warto rozważyć jego wycofanie, aby ograniczyć koszty utrzymania.

Automatyzacja nigdy nie jest ukończona; pomiary wskazują, gdzie należy inwestować w następnej kolejności.

Dane o zaoszczędzonym czasie pokazują tylko połowę obrazu. Każdy playbook wiąże się z bieżącym kosztem utrzymania: integracje się psują, interfejsy API się zmieniają, a logika decyzyjna wymaga dostrajania.

Uczciwą miarą wartości jest wartość netto:

Odróżnij miarodajną metrykę od metryki wprowadzającej w błąd.

Mierzenie wpływu automatyzacji:

• Należy mierzyć, aby uzasadniać inwestycje i znajdować obszary do poprawy; przed wdrożeniem playbooków trzeba ustalić wartości bazowe.
• Należy śledzić czas zaoszczędzony podczas każdego uruchomienia, redukcję MTTR oraz odsetek automatyzacji (w pełni zautomatyzowane, wspomagane przez człowieka i manualne).
• Szybkość należy zestawiać z jakością: zamknięcia fałszywie pozytywnych alertów, odsetek ponownych otwarć i odsetek nadpisań.
• Należy unikać metryk próżności, takich jak sama liczba wykonań; aktywność zawsze trzeba wiązać z rezultatami.
• Playbooki należy wyposażyć w telemetrię, wpływ przedstawiać w kategoriach istotnych dla kadry kierowniczej (zaoszczędzone FTE, ryzyko związane z czasem obecności atakującego) oraz stosować pętlę ciągłego doskonalenia.