W lipcu 2024 roku globalna awaria wywołana błędną aktualizacją sterownika CrowdStrike ujawniła zbyt głęboką ingerencję systemu bezpieczeństwa w jądro Windows. Wielu ekspertów powtarzało wówczas, iż było to spowodowane zbyt dużym zaufaniem do zewnętrznego systemu bezpieczeństwa, ale nie tylko. W przypadku Linux i macOS integracja nie występuje aż na tak wysokim poziomie. Microsoft zareagował dosyć szybko. Powołano inicjatywę Windows Resiliency Initiative oraz program MVI – rozpoczęto dyskusję nad przebudowaniem modelu ochrony Windows z naciskiem na „secure by design” i ograniczenie wpływu komponentów firm trzecich na kernel systemu.
Microsoft zaostrza bezpieczeństwo Windows - wyjaśnienia:
1.
2.
Kluczowym elementem tej zmiany jest nowe podejście do skanowania i monitorowania – przeniesienie mechanizmów AV/EDR poza kernel, do trybu użytkownika, przy jednoczesnym zachowaniu dostępu do niskopoziomowych danych przez kontrolowane API. Zmiana architektury ma przebiegać płynnie i zamiast sterowników działających w jądrze, silniki bezpieczeństwa mają funkcjonować w izolowanych komponentach w trybie użytkownika i komunikować się ze systemem poprzez oficjalne API.
Na pierwszy rzut oka celem takiego podejścia jest zwiększenie stabilności i ograniczenie ryzyka podobnych globalnych incydentów. Z drugiej strony Microsoft brakiem wcześniejszych reakcji przyzwyczaił producentów systemu ochronnego do niemal dowolnego stosowania mechanizmów bezpieczeństwa. A teraz to Microsoft zaczyna przejmować kontrolę nad tym, jak AV/EDR będzie działać w Windows.
Koniec z nieoficjalnymi hookami
Techniki takie jak hooking, process injection czy sterowniki kernel-mode były przez lata standardem zarówno w malware, jak i w rozwiązaniach bezpieczeństwa, ponieważ umożliwiały przechwytywanie i modyfikację działania systemu na poziomie niedostępnym dla oficjalnych interfejsów. Dodatkowo przez lata producenci AV/EDR budowali swoje możliwości detekcji i reakcji w oparciu o techniki, które formalnie nie były zabronione, ale też nie były oficjalnie wspierane. Obejmowały one głównie ingerencję w newralgiczne elementy systemu operacyjnego.
Najczęściej wykorzystywane podejścia obejmowały:
- hookowanie procesów systemowych (np. winlogon, lsass, explorer) w celu przechwytywania zdarzeń i manipulowania przepływem wykonania
- instalację sterowników w kernel-mode umożliwiających obserwację i modyfikację operacji na poziomie jądra
- wstrzykiwanie kodu (DLL injection, APC, inline hooks) do procesów o wysokich uprawnieniach
- obchodzenie ograniczeń systemowych w celu uzyskania pełniejszej telemetrii niż ta dostępna przez oficjalne API
Takie techniki dawały bardzo wysoką widoczność, często wyprzedzającą możliwości samego systemu Windows, ale jednocześnie wprowadzały ryzyko wspomnianej destabilizacji systemu (niebieskie ekrany śmierci, konflikty sterowników), podatności wynikających z błędów w kodzie vendorów oraz trudności w utrzymaniu kompatybilności między wersjami Windows. Nowe podejście Microsoftu zakłada systemowe ograniczenie tych możliwości.
Po pierwsze, dostęp do kluczowych informacji i zdarzeń w ramach telemetrii ma być realizowany wyłącznie przez oficjalne API, takie jak rozwijany WESP (Windows Endpoint Security Platform). Oznacza to, iż vendor nie może już samodzielnie rozszerzać zakresu telemetrii poprzez własne mechanizmy w kernelu.
Po drugie, rośnie znaczenie podpisywania kodu i zaufania do komponentów. System Windows będzie wymagał uruchamiania wyłącznie podpisanych sterowników, czyli np. nie da się uruchomić komponentów, które nie spełniają wymagań dla Secure Boot.
Po trzecie, ograniczana jest możliwość wstrzykiwania kodu do procesów systemowych. Przykładem jest planowane uszczelnienie procesu winlogon.exe, gdzie tylko kod podpisany przez Microsoft będzie mógł być ładowany. To eliminuje całą klasę technik wykorzystywanych dotychczas przez rozwiązania bezpieczeństwa i na przykład istniejące rozwiązania do monitoringu logowania mogą przestać działać w obecnej formie.
WESP – terminy i nowa platforma bezpieczeństwa Windows
Windows Endpoint Security Platform (WESP) to centralny element przebudowy modelu bezpieczeństwa Windows. Microsoft wprowadza to jako warstwę pośrednią pomiędzy systemem operacyjnym a rozwiązaniami AV/EDR, której celem jest standaryzacja dostępu do telemetrii i mechanizmów ochrony.
Dotychczas vendorzy budowali własne mechanizmy zbierania danych:
- sterowniki kernel-mode do monitorowania operacji systemowych
- własne hooki i techniki interceptowania zdarzeń
- bezpośrednią ingerencję w procesy i pamięć
WESP ma to zastąpić jednym, kontrolowanym modelem. Założeniem platformy jest przeniesienie większości logiki bezpieczeństwa do trybu użytkownika, przy jednoczesnym zachowaniu dostępu do krytycznych informacji systemowych.
Docelowo Microsoft dostarcza:
- oficjalne API do monitorowania zdarzeń (procesy, pliki, pamięć, boot)
- kontrolowany kanał dostępu do danych wcześniej dostępnych tylko z poziomu kernela
- model uprawnień i podpisów powiązany z poziomem zaufania aplikacji
Kluczowa zmiana polega na tym, iż dostawca sterowników nie implementuje już własnego agenta w kernelu, tylko korzysta z mechanizmów dostarczonych przez system.
Wszystko będzie podzielone na etapy podczas uruchamiania Windows:
- Pierwszym elementem jest monitorowanie wczesnego etapu uruchamiania systemu. Historycznie był to obszar wymagający sterowników ELAM, które działały bardzo wcześnie w procesie startu. WESP umożliwi widoczność procesów podczas ładowania Windows, dostawca systemu poprzez API otrzyma te dane bez konieczności ładowania własnego kodu w tym etapie – co z założenia miało wyeliminować ryzyko BSOD lub inne błędy.
- Drugim elementem jest nowy model podpisywania i autoryzacji agentów w WESP. Dostęp do funkcji platformy będzie zależny od:
- poziomu podpisu aplikacji
- zgodności z wymaganiami MVI
- nadanych uprawnień w modelu platformy
Nie każdy komponent będzie miał taki sam dostęp – Microsoft wprowadza granularną kontrolę nad tym, kto i w jakim zakresie może korzystać z telemetrii systemowej. Przewiduje się, iż pierwsze wersje PREVIEW będą udostępnione partnerom w czerwcu 2026 roku a we wrześniu odpowiednie buildy mają być dostępne dla wszystkich.
Podsumowując tę sekcję, wprowadzenie WESP oznacza koniec dla producentów systemu bezpieczeństwa (oraz dla autorów malware) korzystania z alternatywnych metod zbierania danych ze systemu, poprzez własne sterowniki nie będzie już można omijać ograniczeń Windows, to Microsoft ma mieć kontrolę jakie dane i mechanizmy udostępni producentom. Z czasem lista tych funkcji może ulec wydłużeniu.
MVI 3.0 – nowe regulacje dla vendorów
Microsoft Virus Initiative 3.0 – zestaw wymagań technicznych dla partnerów Microsoft
Dostęp do kluczowych funkcji systemu w tym podpisywania sterowników, integracji z Windows Security Center czy możliwości zastąpienia Microsoft Defender jest uzależniony od spełnienia formalnych wymagań. najważniejsze znaczenie ma zgodność z programem MVI 3.0, czyli poprawne podpisywanie wszystkich komponentów oraz wykorzystanie chronionych procesów (AM-PPL). Brak zgodności może skutkować:
- odrzuceniem sterowników (np. ELAM)
- brakiem integracji z Windows Security Center (brak powiadomień)
- działaniem równoległym do Microsoft Defender zamiast jego zastąpienia
AM-PPL – wymuszenie ochrony procesów AV
Antimalware Protected Process Light (AM-PPL) staje się obowiązkowym elementem integracji z Windows Security Center. Jest to mechanizm, który chroni procesy AV przed manipulacją ze strony innych aplikacji, w tym złośliwego oprogramowania. Vendorzy muszą ograniczyć możliwości debugowania, wstrzykiwania kodu i interakcji z procesami, aby przez cały czas korzystać z Windows Security Center i nie być tylko przystawką do Microsoft Defender.
Smart App Control (SAC) – agresywniejsze egzekwowanie reputacji
Smart App Control to mechanizm kontroli uruchamiania aplikacji w Windows, który działa niezależnie od klasycznych rozwiązań AV. Jego decyzje nie opierają się na sygnaturach czy heurystyce, ale na kombinacji reputacji pliku, podpisu cyfrowego oraz danych chmurowych Microsoft. Smart App Control wykorzystuje podpisy cyfrowe oraz chmurowe usługi reputacyjne Microsoft, aby dopuścić do uruchomienia wyłącznie kod uznany za bezpieczny, blokując aplikacje niepodpisane lub bez historii reputacyjnej.
SAC analizuje, czy dany plik:
- jest podpisany i przez kogo
- posiada historię reputacyjną
- nie wykazuje cech charakterystycznych dla malware lub nieznanego oprogramowania
Jeśli aplikacja nie spełnia tych kryteriów, może zostać zablokowana jeszcze przed uruchomieniem – niezależnie od tego, czy AV uzna ją za bezpieczną.
Zmiany wprowadzone przez Microsoft znacząco zwiększają wpływ SAC na bezpieczeństwo. Okres ewaluacji został skrócony z 30 do 7 dni, co oznacza szybsze przejście systemu do trybu egzekwowania decyzji. W praktyce producent systemu musi zadbać o podpisywanie wszystkich komponentów (nie tylko EXE, ale także DLL i modułów pomocniczych) oraz budowanie reputacji w ekosystemie Microsoft, ponieważ aplikacje bez historii mogą być blokowane.
Istotne jest również to, iż SAC działa przed uruchomieniem AV. Oznacza to, iż decyzja o blokadzie może zapaść zanim silnik AV wykona analizę, a vendor nie ma możliwości obejścia tej decyzji własnymi mechanizmami.
Zmiany w podpisywaniu sterowników
Microsoft stopniowo porządkuje model podpisywania sterowników, który dotychczas dopuszczał różne poziomy zaufania i scenariusze wdrożeniowe: test signing, preproduction, attestation oraz WHQL. Każdy z nich zapewniał inny poziom weryfikacji i dopuszczenia do działania w systemie. Sterownik nie tylko musi być podpisany, ale musi być podpisany na odpowiednim poziomie, zgodnym z wymaganiami Microsoft i powiązanym z reputacją vendora.
Kluczowa zmiana polega na tym, iż zgodność certyfikacyjna będzie czymś w rodzaju continuous compliance pod kątem jakości i zgodności z aktualnymi wymaganiami a nie jednorazową certyfikacją. Brak spełnienia wymagań będzie skutkować blokadą możliwości podpisywania sterowników, w konsekwencji odrzuceniem komponentów przez system i utratą statusu partnera MVI.
Podsumowanie
Microsoft kończy erę stosowania nieoficjalnych technik ingerencji w jądro Windows i przechodzi do modelu ściśle kontrolowanej integracji z systemem. Wprowadzane zmiany mają ograniczyć nieautoryzowane metody działania oprogramowania, co bezpośrednio przekłada się na większą stabilność i bezpieczeństwo platformy.
Dostawcy rozwiązań będą objęci bardziej rygorystycznymi wymaganiami, zarówno technicznymi, jak i operacyjnymi, co oznacza konieczność ciągłego dbania o jakość kodu, zgodność z wymaganiami Microsoft oraz utrzymanie statusu compliance.
Z drugiej strony skuteczność nowych mechanizmów będzie weryfikowana dopiero w praktyce – przez twórców złośliwego systemu oraz zaawansowane grupy atakujące. To oni najszybciej pokażą, czy nowy model rzeczywiście ogranicza możliwości obejścia zabezpieczeń, czy jedynie zmienia ich charakter.
