„Resilience is not optional – resilience is essential”. Microsoft doskonale rozumie i stara się wszystkich przekonać, że w obliczu dzisiejszych zagrożeń bezpieczeństwa, odporność nie może być realizowana ad hoc — musi być fundamentem, rdzeniem systemów IT. Dlatego w ramach inicjatywny Windows Resiliency Initiative (zobacz więcej w PDF), o której szerzej pisaliśmy tutaj, Microsoft zamierza przebudować ochronę Windows 11 i Windows 12 w celu:
- Zapobieżenia incydentom bezpieczeństwa poprzez przedefiniowanie architektury Windows (secure by default, secure by design).
- Reagowania i zarządzania już w momencie wystąpienia problemów.
- Szybkiej odbudowy systemów i usług po awariach lub atakach.
Przypomnę, że we wrześniu 2024 odbyło się spotkanie Windows Endpoint Security Ecosystem Summit, gdzie Microsoft zapowiedział współpracę z producentami zabezpieczeń i instytucjami (m.in. CISA) nad podniesieniem standardów ów odporności. Dodatkowo w ramach projektu Microsoft Virus Initiative, którego AVLab jest członkiem (zobacz szczegóły), dostawcy rozwiązań zabezpieczających muszą stosować się do wytycznych Microsoftu i potwierdzać swoją skuteczność, odporność na błędy, poprzez regularne testy swojego oprogramowania.
Skanowanie anty-malware poza kernelem Windows – kiedy?
Tradycyjnie oprogramowanie antywirusowe w Windows działa bardzo blisko kernela systemu operacyjnego. Wynika to z faktu, że skuteczne wykrywanie złośliwego oprogramowania często wymaga dostępu do niskopoziomowych zasobów systemowych — sterowników, plików systemowych, procesów w pamięci. Ten model ma jednak istotną wadę: mianowicie jeśli coś pójdzie nie tak (np. błąd w module sterownika antywirusa), może spowodować awarię całego systemu. Zdarza się to niezwykle rzadko, ale ma ogromne skutki — wystarczy przypomnieć incydent z lipca 2024, gdy wadliwa aktualizacja sterownika CrowdStrike spowodowała globalne przestoje w firmach.
Nowy model będzie rozwijany na Windows 11 i jego następcę — czyli prawdopodobnie Windows 12 (jeśli tak się będzie nazywał nowy system). Pojawi się specjalne API dla deweloperów rozwiązań bezpieczeństwa (AV, EDR, SIEM itp.), by wynieść skanowanie poza jądro systemu, do trybu użytkownika i jednocześnie uzyskiwać dostęp do niskopoziomowych informacji z kernela. Może to być kluczowy krok, aby zwiększyć przede wszystkim stabilność, zapobiec globalnym awariom, by jeden wadliwy moduł oprogramowania nie wpłynął na bezpieczeństwo tysięcy, milionów urządzeń.
Nowy model skanowania poza jądrem (user-mode) będzie testowany w ramach Private Preview w Windows 11 — czyli najpierw w wersjach Insider lub dedykowanych buildach dla partnerów.
Jak to ma działać w praktyce?
Zamiast instalowania sterownika (np. minifilter driver) bezpośrednio w kernelu, silnik AV będzie działał w izolowanym kontenerze w przestrzeni użytkownika, z minimalnym dostępem do jądra. Komunikacja z systemem plików i procesami będzie realizowana przez udokumentowane API Windows, z dodatkowymi mechanizmami sandboxingu i telemetrii. Dzięki temu hakerom trudniej będzie wywołać eskalację uprawnień poprzez lukę w krytycznym oprogramowaniu, jakim jest antywirus. Co więcej deweloperzy będą mogli szybciej wypuszczać poprawki, bo nie będą musieli przechodzić skomplikowanej walidacji kodu kernelowego. Finalnie system operacyjny będzie bardziej odporny na awarie sterowników firm trzecich.
Czy to wpłynie na szybkość skanowania i wydajność?
Przeniesienie antywirusa (czy innego oprogramowania wymagającego dostępu do jądra) do trybu użytkownika nie oznacza obniżenia skuteczności wykrywania, ponieważ kluczowe funkcje (np. skanowanie w czasie rzeczywistym, heurystyka) będą działać z podobną prędkością, dzięki nowoczesnym mechanizmom w Windows 11 i Windows Server. Przykładowo Microsoft Defender już teraz częściowo działa w user-mode. W nowym modelu ochrony izolowany będzie silnik AV (minifilter driver), ale jednocześnie będzie uzyskiwał dostęp do skanowania plików na etapie otwierania i zapisu — czyli w czasie rzeczywistym. Co więcej kernel systemowy będzie tylko „sygnalizował” AV o zdarzeniu (np. próbie dostępu do pliku), zatem cała analiza ma dziać się poza jądrem.
Poniżej uproszczony przykład fragmentu MiniFiltera, który przechwytuje każde otwarcie pliku i loguje jego nazwę.
#include
PFLT_FILTER gFilterHandle;
// Callback: Pre-operation callback for IRP_MJ_CREATE (open file)
FLT_PREOP_CALLBACK_STATUS
PreCreateOperation(
PFLT_CALLBACK_DATA Data,
PCFLT_RELATED_OBJECTS FltObjects,
PVOID *CompletionContext
)
{
PFLT_FILE_NAME_INFORMATION fileNameInfo;
NTSTATUS status;
// Get file name
status = FltGetFileNameInformation(Data,
FLT_FILE_NAME_NORMALIZED | FLT_FILE_NAME_QUERY_DEFAULT,
&fileNameInfo);
if (NT_SUCCESS(status)) {
FltParseFileNameInformation(fileNameInfo);
DbgPrint("File open intercepted: %wZ\n", &fileNameInfo->Name);
FltReleaseFileNameInformation(fileNameInfo);
}
...
Przykładowo teraz Windows Defender z usługą MsMpEng.sys działa w kernelu i używa tego MiniFiltera. Podobnie większość rozwiązań bezpieczeństwa, ponieważ tak skonstruowany jest Windows. Zasadniczo każde rozwiązanie ma swój MiniFilter lub nawet kilka.
Jak skanowanie działa teraz?
- Silnik antywirusowy instaluje sterownik minifilter w kernel mode.
- Sterownik monitoruje wszystkie operacje I/O (np. otwarcia, zapisy plików).
- Jeśli wykryje podejrzane zachowanie – blokuje operację lub przekazuje dane do silnika AV.
- Sterownik ma wysokie uprawnienia: błąd lub luka w kodzie sterownika = potencjalny BSOD lub wektor eskalacji uprawnień.
Jak to będzie w działać w user mode (przestrzeń użytkownika)?
- Kernel nie załaduje sterownika AV, tylko udostępni API i wywołania do zdarzeń (np. otwarcie pliku, zmiana rejestru).
- Silnik antywirusowy działać ma w procesie użytkownika, odseparowany od jądra.
- Komunikacja odbywać się będzie przez bezpieczny interfejs API (coś w rodzaju sandbox).
- Jeśli AV przestanie działać, ochrona przestanie działać, ale nie spowoduje do uszkodzenia systemu, BSOD
Z perspektywy dewelopera i producenta oprogramowania antywirusowego o dodatkowy komentarz w tej sprawie zapytaliśmy firmę mks_vir sp. z o.o.
Na dzień dzisiejszy trudno jeszcze zająć jednoznaczne stanowisko, ponieważ nie mamy odpowiedzi na wiele pytań dotyczących implementacji ochrony w obszarach, które nie są ujęte w dokumentacji nowego API.
W mojej ocenie nowe otwarcie w podejściu do ochrony ekosystemu Windows niesie ze sobą więcej (przynajmniej potencjalnych) minusów niż plusów. Możemy tutaj odnaleźć analogię do technologicznego przejścia od Windows 9x (a nawet Windows NT) do Windows XP i powstałego wtedy całkowicie nowego i niezbadanego obszaru działań zarówno dla producentów oprogramowania ochronnego jak i twórców szkodliwego oprogramowania. Był to czas prawdziwego wyścigu "cyberzbrojeń" i szybkiego rozwoju mechanizmów zarówno ochronnych jak i ataków. Istnieje znaczące ryzyko, że po wdrożeniu nowego API ponownie rozpocznie się lawinowe odkrywanie luk w procesach systemowych, szybkie ich łatanie zarówno przez Microsoft, jak i przez producentów oprogramowania, co może prowadzić do regresu spójności technologii i w efekcie utratę gwarancji stabilności, która (teoretycznie) leży u podstaw nowego API.
W branży silne reprezentowane jest stanowisko, że przy założeniu, że głównym celem prac nad nowym API jest zagwarantowanie stabilności pracy systemu w zdarzeniach takich, jakie powstało przy "awarii" CrowdStrike (lub wręcz niedopuszczenie do takich awarii), lepszym podejściem byłoby ograniczenie swobody implementacyjnej mechanimzów realizowanych na poziomie sterownika ELAM (Early Launch AntiMalware), którego błędne działanie jest w skrajnych przypadkach faktycznie absolutnie destrukcyjne dla systemu. W przypadku pozostałych sterowników i serwisów awarie nie są już tak dotkliwe i praktycznie w 100% możliwe do niwelacji np. w ramach trybu awaryjnego lub - w skrajnych przypadkach - poprzez konsolę odzyskiwania. Producenci oprogramowania ochronnego już dziś są zobligowani przez Microsoft do udostępniania tzw. procedury "Incident Response Plan", której celem jest odzyskanie stabilności systemu w różnych, krytycznych sytuacjach, które mogą być spodowodowane przez oprogramowanie.
Z punktu widzenia programistycznego w ramach nowego API znacząco upraszcza się proces deweloperski, ponieważ praktycznie wszystkie mechanizmy dotyczące obsługi systemu plików, sieci, rejestru i pozostałych elementów opisanych w ramach powstałej dotychczas dokumentacji będą dostarczone przez Micorosft. Warto tutaj wspomnieć, że samo wyniesienie interfejsów dostępnych dla deweloperów poza jądro wcale nie jest aż tak bardzo rewolucyjnym podejściem, ponieważ większość dotychczasowych implementacji i tak była mocno podobna w różnych rozwiązaniach (np. obsługa systemu plików poprzez FLTMGR), a większość producentów proces szeroko rozumianego skanowania realizuje poza jądrem systemu. Rodzą się tutaj natomiast wątpliwości np. co do wydajności takiego zunifikowanego podejścia, gdyż tutaj faktycznie różni producenci stosują autorskie mechanizmy optymalizacji.
Nie mamy jeszcze odpowiedzi na pytania dotyczące pozostałych obszarów ochrony, takich jak szeroki wachlarz tzw. hook'ów systemowych (często jeszcze bazujących na nieudokumentowanych oficjalnie mechanizmach), które pozwalają na wczesne wykrywanie szkodliwych aktywności w systemie, sterowników pozwalających np. na szyfrowanie ważnych danych i wielu innych, często innowacyjnych mechanizmów, które faktycznie znacząco rozróżniają poszczególne pakiety ochronne. Istnieje uzsadanione ryzyko, że - przynajmniej w pierwszych iteracjach nowego API - tego typu mechanizmy nie będą możliwe do implementacji, co przełoży się na obniżenie skuteczności ochrony. Podsumowując - jako producent i aktywny partner ekosystemu MVI uczestniczymy w procesie tworzenia nowego API i jesteśmy przygotowani do implementacji i wdrożenia odrębnej linii pracującej na nim pakietów. Mamy również świadomość, że wdrożenie nowych mechanizmów będzie stanowiło dla branży ogromne wyzwanie w kontekście zapewnienia dotychczasowego, wysokiego poziomu ochrony, ponieważ ewentualne luki i ułomności powstającego mechanizmu będą bez litości wykorzystane przez cyberprzestępców, a - jak już wspomniałem - nadal nie znamy odpowiedzi na istotne pytania dotyczące bardziej "wyrachowanych" i indywidualnych mechanizmów ochronnych.

Czy ten artykuł był pomocny?
Oceniono: 3 razy