MTTR

MTTR (mean time to respond) to uśredniony czas od wykrycia incydentu do jego opanowania lub zamknięcia. Mierzy sprawność zespołu, który zajmuje się reagowaniem na incydenty. NIST wymienia wśród miar czas od odkrycia incydentu do kolejnych etapów obsługi, takich jak opanowanie i przywrócenie, oraz czas, w jakim zespół zareagował na pierwsze zgłoszenie ^[1]. MTTR jest średnią z takich wartości dla wielu incydentów.

Jak działa

Pomiar zaczyna się tam, gdzie kończy się MTTD: w chwili wykrycia. Koniec pomiaru trzeba zdefiniować, bo „reakcja” może oznaczać pierwsze działanie analityka, opanowanie incydentu albo formalne zamknięcie sprawy. Każda z tych definicji daje inną liczbę, więc raport z MTTR powinien mówić, którą przyjęto.

RYS. 1Odcinki mierzone po wykryciu

W Microsoft Sentinel tabela SecurityIncident przechowuje czas utworzenia incydentu, czas pierwszej zmiany i czas zamknięcia ^[2]. Czas do triażu (triage) to różnica między pierwszą zmianą a utworzeniem, a czas do zamknięcia to różnica między zamknięciem a utworzeniem ^[2]. Gotowy skoroszyt „Security operations efficiency” pokazuje średni czas do triażu i średni czas do zamknięcia, także w percentylach ^[2]. Każda zmiana incydentu tworzy w tej tabeli nowy wpis, więc przed liczeniem średniej trzeba wybrać ostatni rekord każdego incydentu ^[2].

NIST proponuje obok czasu także inne miary związane z reakcją: łączną liczbę godzin pracy poświęconych incydentowi oraz czas, jaki zajęło powiadomienie kierownictwa i, gdy to konieczne, podmiotów zewnętrznych ^[1]. Pierwsza miara pokazuje koszt, druga sprawność komunikacji. Dopiero razem z MTTR dają pełniejszy obraz: krótki czas reakcji osiągnięty wysiłkiem całego zespołu przez noc to inny wynik niż ten sam czas osiągnięty przez jedną osobę według gotowej procedury.

Znaczenia skrótu

Skrót MTTR nie ma jednego rozwinięcia. W bezpieczeństwie oznacza zwykle mean time to respond, ale w utrzymaniu systemów bywa rozwijany jako czas naprawy lub przywrócenia. Program badawczy DORA (DevOps Research and Assessment, bez związku z unijnym rozporządzeniem o tej samej nazwie), mierzący wydajność dostarczania oprogramowania, wcześniej używał MTTR, a następnie zastąpił go miarą failed deployment recovery time, czyli czasem przywrócenia działania po nieudanym wdrożeniu ^[3]. Przy porównywaniu dwóch raportów warto więc sprawdzić, co w nich znaczy MTTR.

MTTR różni się też od RTO. RTO to cel, czyli dopuszczalny czas niedostępności ustalony z góry w planie ciągłości działania. MTTR to wynik pomiaru z przeszłych incydentów. Porównanie obu wartości pokazuje, czy plan jest realistyczny.

W WordPressie

Na stronie WordPress większość czasu reakcji zajmuje sprzątanie po włamaniu. CERT Polska zaleca po wykryciu infekcji odcięcie serwera HTTP od sieci i zabezpieczenie logów, zanim nadpisze je rotacja ^[5]. Jeżeli wektor i czas ataku są jasne, stronę można odtworzyć z czystej kopii sprzed incydentu; jeżeli nie, CERT Polska zaleca odbudowę od zera ze świeżej instalacji ^[5]. Ten wybór najmocniej wpływa na MTTR: odtworzenie z kopii trwa krócej niż przebudowa.

Dlatego czas reakcji zależy od przygotowania, a nie od szybkości w dniu ataku:

• Kopie. Dokumentacja WordPressa zaleca trzymać co najmniej 3–5 ostatnich kopii w różnych miejscach, na przykład na serwerze, w chmurze i na komputerze lokalnym ^[6]. Dla stron o dużej aktywności zaleca kopie codzienne ^[6]. Bez sprawdzonej kopii zapasowej (backup) przywrócenie działania znacznie się wydłuża.
• Unieważnienie dostępu. WordPress.org zaleca wymusić zmianę haseł wszystkich użytkowników i wymienić klucze w wp-config.php, co wylogowuje wszystkie sesje ^[7]. Gotowa procedura skraca ten krok do minut; zob. klucze bezpieczeństwa i sole.
• Ponowna instalacja rdzenia. Katalogi /wp-admin i /wp-includes można bezpiecznie zastąpić plikami tej samej wersji, a pliki w wp-content trzeba sprawdzać staranniej ^[7].
• Procedura na piśmie. Gotowy playbook zwalnia z podejmowania decyzji pod presją.

Ograniczenia miary

• Szybko nie znaczy dobrze. Pospieszne przywrócenie bez usunięcia zagrożenia zostawia tylną furtkę (backdoor), a napastnik wraca. Niski MTTR i powtórne włamanie to gorszy wynik niż wyższy MTTR i czysta strona.
• Średnia ukrywa skrajności. Microsoft pokazuje czasy obsługi w percentylach ^[2]; długie incydenty są zwykle ciekawsze od średniej.
• Różne definicje incydentu. NIST zaznacza, że organizacje definiują incydent różnie, więc proste miary nie nadają się do porównań między nimi ^[1].
• Dane do działania. NIST zaleca zbierać dane, które pozwalają coś zmienić, a nie wszystko, co jest dostępne ^[1].

Dobre praktyki

• Ustalenie na piśmie, gdzie zaczyna się i kończy pomiar, oraz stałe znaczniki czasu w systemie zgłoszeń albo SIEM.
• Automatyzacja powtarzalnych kroków, na przykład przez SOAR: blokada adresu, wyłączenie konta, powiadomienie.
• Ćwiczenia typu tabletop, które ujawniają braki w procedurach przed prawdziwym incydentem.
• Analiza każdego dłuższego incydentu w ramach post-incident review. Google wymienia przekroczenie ustalonego czasu rozwiązania jako jeden z typowych powodów zwołania takiego przeglądu ^[4].