Microsoft risk cohorts: priorytety październikowych poprawek

13 października MSRC przedstawiło koncepcję risk cohorts: grup CVE wymagających podobnych pytań o wdrożenie, ekspozycję i granice uprawnień. Grupy mają charakter wstępny; nie zmieniają wytycznych aktualizacji ani potrzeby oceny poszczególnych CVE. Źródło: komunikat Microsoftu o risk cohorts.

Wniosek Breachroad: zespół IT może wykorzystać ten pomysł do uporządkowania wiedzy o swoim środowisku, ale decyzja o poprawce powinna nadal wskazywać konkretną podatność, urządzenia i wymagane działanie. Poniższy sposób organizacji pracy jest naszą rekomendacją dla administratorów, właścicieli usług i zespołów bezpieczeństwa.

Zacznij od odpowiedzi, którą da się sprawdzić

Proponujemy przygotować krótkie opisy najważniejszych usług i grup urządzeń. Każdy opis powinien mieć właściciela, datę potwierdzenia i dowód dotyczący rzeczywistej konfiguracji. „Nie używamy tej funkcji” jest użyteczne dopiero wtedy, gdy wiadomo, czego dotyczyło sprawdzenie i jakie systemy obejmowało.

Rozróżnij stan deklarowany, stan potwierdzony oraz brak danych. W naszej ocenie warto zachować te trzy wartości w rejestrze, zamiast wymuszać odpowiedź tak lub nie przy niepełnym inwentarzu. Brak informacji powinien otrzymać osobę odpowiedzialną i termin uzupełnienia.

Przykład: wspólna aplikacja, odmienne stanowiska

Wyobraźmy sobie firmę z zespołem zakupów, projektantami i komputerem zapasowym. Wszystkie grupy mają tę samą aplikację biurową, ale różnią się sposobem pracy i zarządzania aktualizacjami. To hipotetyczny przykład szkoleniowy, nie dane z raportu Microsoftu.

Zespół zakupów obsługuje dokumenty od zewnętrznych kontrahentów. Projektanci mają dodatkowe rozszerzenia. Komputer zapasowy rzadko łączy się z firmowym systemem zarządzania. Ogólna odpowiedź dotycząca aplikacji nie opisuje jeszcze tych różnic.

Nasza rekomendacja: zapisz wspólną informację o wdrożeniu, a następnie wskaż wyjątki wymagające osobnego potwierdzenia. Właściciel aplikacji powinien znać zakres danych wejściowych, a administrator stan wersji i aktualizacji. Obie odpowiedzi powinny być widoczne przy decyzji o działaniach.

Z opisu środowiska do zadania o aktualizacji

Proponujemy przypisać do zadania cztery konkretne ustalenia:

1. Zakres. Wskaż podatności, urządzenia i składniki, których dotyczy decyzja. Nazwa grupy ryzyka nie wystarcza jako identyfikator zadania.
2. Podstawa priorytetu. Zapisz informacje dostawcy o wykorzystaniu podatności oraz warunki istotne dla własnego wdrożenia. Oddziel potwierdzone dane od przyjętych założeń.
3. Właściciel i termin. Ustal, kto przeprowadza zmianę, kto zatwierdza wyjątek i kiedy nastąpi kolejna ocena. Brak dostępności użytkownika lub aplikacji powinien mieć widoczną ścieżkę rozwiązania.
4. Dowód wyniku. Określ, jak potwierdzisz działającą wersję, zakończenie wymaganych etapów i dostępność potrzebnych funkcji.

To nasza propozycja zapisu decyzji. Pozwala sprawdzić, dlaczego dwa systemy otrzymały różne terminy, bez odtwarzania uzasadnienia z rozmów na komunikatorze.

Zachowaj widoczność wyjątków

MSRC zaznacza, że wspólna grupa nie oznacza jednej poprawki lub mitygacji usuwającej wszystkie jej CVE. Koncepcja pozostaje eksperymentalna, a Security Update Guide nie prezentuje obecnie tych powiązań. To ograniczenia opisane w powyższym źródle.

W naszym planie każda odrębna decyzja zachowuje swoje uzasadnienie i odniesienie do aktualnych informacji dostawcy. Jeśli pojawi się nowe potwierdzenie ataków, zmiana ekspozycji albo poprawiona ocena, wróć do odpowiednich zadań. Samo wcześniejsze zaklasyfikowanie urządzeń nie zamyka tego przeglądu.

Sprawdź, czy nowy sposób pracy pomaga

Zalecamy ocenić mały, jasno określony zakres przed zastosowaniem metody do całego rejestru. Sprawdź, czy opis środowiska rzeczywiście skraca zbieranie danych oraz czy osoby podejmujące decyzje nadal widzą istotne różnice między zadaniami.

Przy przeglądzie zapytaj o brakujące dowody, opóźnione wyjątki i nieaktualne opisy konfiguracji. Taka ocena dotyczy jakości decyzji, a nie tylko liczby rekordów zamkniętych po wysłaniu pakietu aktualizacji.

Na szkoleniu uczestnicy mogą porównać fikcyjne stanowiska i wyjaśnić, co potwierdzili wspólnie, a co wymaga dodatkowych ustaleń. Ćwiczenie nie potrzebuje prawdziwych podatnych systemów ani wykonywania testów ofensywnych.

Więcej o organizacji tego procesu znajdziesz w przewodniku po zarządzaniu podatnościami. Zespoły IT i właściciele usług mogą przećwiczyć podobne decyzje podczas szkoleń z cyberbezpieczeństwa dla organizacji.