WDAC (Windows Defender Application Control)

WDAC — Windows Defender Application Control — to mechanizm bezpieczeństwa Windows, który pozwala administratorowi określić jakie aplikacje, pliki wykonywalne, sterowniki i komponenty mogą zostać uruchomione w systemie.

W przeciwieństwie do klasycznego antywirusa WDAC działa przede wszystkim jako polityka kontroli wykonywania kodu.

Najprostszy model:

                    Windows
                       |
                    WDAC Policy
                       |
          +------------+------------+
          |                         |
       Allowed                    Blocked
          |                         |
          v                         v
     Application                  Malware
     Driver                       Unknown EXE
     Script                       Untrusted Code

WDAC vs antywirus

To bardzo ważne rozróżnienie.

Antywirus pyta przede wszystkim:

Czy ten plik wygląda na złośliwy?

WDAC pyta:

Czy ten kod w ogóle ma prawo się uruchomić?

Można więc mieć:

Antivirus
    +
WDAC

i uzyskać dwie różne warstwy ochrony.

Przykładowo malware może nie zostać jeszcze wykryty przez rozwiązanie antywirusowe, ale jeśli WDAC nie pozwala na jego wykonanie, proces może zostać zablokowany.

Application Control

WDAC należy do kategorii application control / allowlisting.

Zamiast próbować stworzyć listę wszystkich możliwych zagrożeń:

Malware A
Malware B
Malware C
Malware D
...

tworzysz model:

Dozwolone:
Windows
Microsoft Office
Chrome
PowerShell
CompanyApp.exe
SignedDriver.sys

a wszystko, co nie spełnia reguł polityki, może zostać zablokowane.

Jak działa WDAC?

Schemat:

User
 |
 v
Uruchamia aplikację
 |
 v
Windows Code Integrity
 |
 v
WDAC Policy
 |
 +---- Allowed ----> Process starts
 |
 +---- Blocked ----> Execution denied

Kluczową rolę odgrywa tutaj Windows Code Integrity.

WDAC nie jest po prostu kolejnym procesem działającym w tle.

Polityka jest powiązana z mechanizmami integralności kodu Windows.

Podpis cyfrowy

Jednym z najważniejszych elementów polityki WDAC może być podpis cyfrowy.

Przykład:

Application.exe
      |
      v
Digital Signature
      |
      v
Trusted Publisher?
      |
   +--+--+
   |     |
  YES    NO
   |     |
 Allow  Block

Możemy powiedzieć:

Zezwalaj na kod podpisany przez określonego wydawcę.

WDAC może być bardziej szczegółowy

Polityka może opierać się na różnych właściwościach pliku, zależnie od konfiguracji.

Między innymi mogą być wykorzystywane:

Publisher
Certificate
File Hash
File Attributes
Path / Location
Signer
Version

W praktyce najbardziej interesujące są często:

Publisher-based rules
Hash-based rules
Signer-based rules

Hash-based allowlisting

Można zezwolić na konkretny plik na podstawie jego hasha.

Przykład:

CompanyApp.exe
SHA-256:
A82F...91D2

Polityka:

IF hash == A82F...91D2
THEN ALLOW

Problem?

Aktualizacja aplikacji zmienia hash:

v1.exe → Hash A
v2.exe → Hash B

Dlatego hash-based rules mogą wymagać większej administracji.

Publisher-based rules

Alternatywnie można zaufać wydawcy.

Microsoft
   |
   +-- Application A
   +-- Application B
   +-- Application C

Polityka może zezwalać na odpowiednio podpisany kod danego wydawcy.

To zwykle jest wygodniejsze niż utrzymywanie ogromnej listy hashy.

Jednocześnie trzeba uważać, jak szeroko definiujemy zaufanie.

Sterowniki

WDAC jest szczególnie istotny dla kernel-mode code.

Schemat:

Application
     |
     v
User Mode
     |
     v
Kernel
     |
   Driver

Złośliwy lub niebezpieczny sterownik jest szczególnie groźny, ponieważ działa na poziomie kernela.

Dlatego kontrola tego, jakie sterowniki mogą zostać załadowane, jest bardzo ważnym elementem bezpieczeństwa Windows.

WDAC i malware

Załóżmy, że atakujący pobiera:

payload.exe

Antywirus jeszcze go nie rozpoznał.

Bez application control:

User
 ↓
payload.exe
 ↓
Execution

Z WDAC:

User
 ↓
payload.exe
 ↓
WDAC
 ↓
Not allowed
 ↓
BLOCK

To pokazuje fundamentalną różnicę:

WDAC może ograniczyć wykonanie kodu niezależnie od tego, czy jego sygnatura malware została już rozpoznana.

Audit Mode

Nie powinno się zwykle zaczynać wdrożenia od agresywnego blokowania wszystkiego.

WDAC może być wdrażany w trybie audytowym.

Schemat:

Application
    |
    v
WDAC
    |
    v
Would this be blocked?
    |
    v
LOG

System zbiera informacje o tym, co polityka zablokowałaby w trybie enforcement.

Dzięki temu administrator może zobaczyć:

Co zostanie zablokowane?

zanim rzeczywiście zacznie blokować.

Enforcement Mode

Po przygotowaniu i przetestowaniu polityki można przejść do egzekwowania.

Audit
  |
  v
Testing
  |
  v
Policy refinement
  |
  v
Enforcement

Wtedy:

Allowed → RUN
Denied  → BLOCK

Największy problem WDAC

Nie jest nim samo stworzenie polityki.

Problemem jest:

utrzymanie jej w środowisku, w którym ciągle coś się zmienia.

Przykład:

Windows Update
Office Update
Driver Update
Application Update
Custom Software

Każda zmiana może potencjalnie wpłynąć na zgodność z polityką.

Dlatego WDAC wymaga dobrego procesu zarządzania.

WDAC a aktualizacje

Wyobraź sobie:

CompanyApp v1
      ↓
Allowed

Developer wypuszcza:

CompanyApp v2

Jeżeli polityka opierała się na konkretnym hashu:

v1 → Hash A
v2 → Hash B

nowa wersja może zostać zablokowana.

Dlatego polityki powinny być projektowane tak, aby aktualizacje zaufanego oprogramowania nie powodowały ciągłego ręcznego zarządzania wyjątkami.

WDAC i Microsoft Defender

Nazwa może być trochę myląca.

Windows Defender Application Control nie jest po prostu funkcją antywirusa Microsoft Defender.

To mechanizm application/code integrity control, który może współpracować z innymi zabezpieczeniami Windows.

Możemy mieć:

                Windows Security
                      |
       +--------------+--------------+
       |              |              |
    Defender         WDAC          Firewall
    Antivirus
       |
    Malware
    Detection

Każdy komponent rozwiązuje inny problem.

WDAC + Defender

Bardzo mocna konfiguracja może wyglądać tak:

                 Endpoint
                    |
        +-----------+-----------+
        |                       |
      WDAC                  Defender
        |                       |
  Can it run?              Is it malicious?
        |                       |
        +-----------+-----------+
                    |
                 Decision

WDAC ogranicza wykonywanie, a Defender dostarcza detekcję i reakcję.

WDAC i Smart App Control

To również warto rozróżnić.

Smart App Control jest rozwiązaniem przeznaczonym przede wszystkim dla użytkowników końcowych i wykorzystuje mechanizmy kontroli aplikacji w Windows.

WDAC jest natomiast bardziej nastawiony na zarządzanie polityką kontroli kodu, szczególnie w środowiskach zarządzanych.

W przedsiębiorstwie administrator może potrzebować znacznie bardziej precyzyjnej kontroli niż typowe ustawienia Smart App Control.

WDAC a AppLocker

To bardzo częste pytanie.

W uproszczeniu:

AppLocker
    ↓
Application Control

natomiast:

WDAC
    ↓
Code Integrity
    ↓
Application + Driver Control

Dlatego WDAC jest zwykle traktowany jako silniejszy mechanizm kontroli kodu.

WDAC i PowerShell

PowerShell jest szczególnie interesujący w kontekście application control.

Atakujący może próbować wykorzystać:

PowerShell
cmd
wscript
mshta
rundll32
regsvr32

czyli legalne komponenty Windows do wykonania złośliwej aktywności.

WDAC może ograniczyć to, jaki kod może być wykonywany w tych środowiskach, choć skuteczność zależy od konkretnej polityki i konfiguracji systemu.

WDAC a LOLBins

LOLBins (Living Off the Land Binaries) są problemem, ponieważ atakujący mogą wykorzystywać legalne komponenty systemu.

Przykład:

Attacker
   |
   v
Trusted Windows Binary
   |
   v
Malicious Activity

Dlatego samo:

„Nie uruchamiaj nieznanych EXE”

nie zawsze wystarcza.

Dobra polityka application control musi uwzględniać również sposób wykonywania kodu przez zaufane komponenty.

WDAC + HVCI

Bardzo ważnym połączeniem jest:

WDAC + HVCI (Hypervisor-Protected Code Integrity).

HVCI wykorzystuje wirtualizację sprzętową do ochrony integralności kodu kernela.

Schemat:

Hardware Virtualization
        |
        v
HVCI
        |
        v
Kernel Code Integrity
        |
        v
WDAC Policy

W odpowiednio skonfigurowanym środowisku daje to bardzo mocną ochronę przed nieautoryzowanym kodem kernel-mode.

WDAC + Secure Boot

Jeszcze mocniejszy model:

Secure Boot
     ↓
Trusted Boot
     ↓
Windows
     ↓
HVCI
     ↓
WDAC
     ↓
Application / Driver Control

Otrzymujemy wtedy kilka warstw ochrony od momentu uruchomienia urządzenia aż do wykonania aplikacji.

WDAC i Zero Trust

WDAC bardzo dobrze wpisuje się w model Zero Trust.

Tradycyjny model:

Inside = Trusted
Outside = Untrusted

Application control:

Every executable
       |
       v
Does policy allow it?
       |
    +--+--+
   YES    NO
    |      |
  RUN    BLOCK

Nie zakładamy automatycznie, że kod jest bezpieczny tylko dlatego, że znajduje się na komputerze firmowym.

Przykład firmowej polityki

Firma ma:

Windows
Microsoft 365
Chrome
ERP
VPN Client
EDR
Custom Application

Administrator może stworzyć model:

                WDAC
                  |
       +----------+----------+
       |                     |
    Trusted               Unknown
       |                     |
       v                     v
Windows binaries           BLOCK
Microsoft
Signed Company Apps
Approved Drivers

Efekt:

Nieznany EXE
      ↓
   BLOCK

nawet jeżeli użytkownik ma uprawnienia do jego uruchomienia.

WDAC a Administrator

To jedna z najważniejszych zalet.

Administrator lokalny może mieć:

Administrator
    |
    v
Uruchomienie aplikacji?
    |
    v
WDAC Policy
    |
    v
BLOCK

Czyli samo posiadanie uprawnień administratora nie oznacza automatycznie możliwości uruchomienia dowolnego kodu.

To znacząco zwiększa odporność endpointów.

Zarządzanie WDAC

W środowisku enterprise polityki mogą być zarządzane centralnie, np. za pomocą:

Microsoft Intune
Microsoft Configuration Manager
Group Policy / enterprise tooling
PowerShell

Dzięki temu można wdrażać politykę na dużej liczbie komputerów:

                 Management
                     |
             WDAC Policy
                     |
       +-------------+-------------+
       |             |             |
     PC 01         PC 02         PC 03

Monitoring

Samo wdrożenie WDAC to dopiero początek.

Trzeba monitorować:

Blocked applications
Blocked drivers
Policy events
Unexpected execution
Application updates

Logi Code Integrity są szczególnie ważne podczas wdrażania i późniejszego troubleshootingu.

Typowy proces wdrożenia

1. Inventory
      ↓
2. Create policy
      ↓
3. Audit Mode
      ↓
4. Collect events
      ↓
5. Fix legitimate blocks
      ↓
6. Test
      ↓
7. Pilot deployment
      ↓
8. Enforcement
      ↓
9. Continuous monitoring

Najgorszym podejściem byłoby:

Create restrictive policy
        ↓
Deploy to 5000 PCs
        ↓
"Zobaczymy co się stanie"

WDAC w architekturze bezpieczeństwa

Można go umieścić w takim modelu:

                  Windows Endpoint
                         |
       +-----------------+-----------------+
       |                 |                 |
    Secure Boot        HVCI           Defender
       |                 |                 |
       +-----------------+-----------------+
                         |
                        WDAC
                         |
                  Code Integrity
                         |
              +----------+----------+
              |                     |
           Allowed                Blocked
              |                     |
            Execute                Stop

Najważniejsze zalety

WDAC daje:

• application allowlisting,
• kontrolę integralności kodu,
• kontrolę sterowników,
• ochronę przed nieautoryzowanym wykonywaniem,
• ograniczenie części ataków malware,
• ochronę nawet w sytuacjach, gdy klasyczna detekcja nie rozpozna jeszcze zagrożenia,
• bardzo dobre dopasowanie do Zero Trust.

Największe wady

Cena za tę ochronę to:

• większa złożoność,
• konieczność przygotowania polityki,
• problemy z nieznanym oprogramowaniem,
• konieczność obsługi aktualizacji,
• potencjalne blokowanie legalnych aplikacji,
• wymagania dotyczące testowania i monitoringu.

Dlatego WDAC jest znacznie bardziej wymagający administracyjnie niż zwykły antywirus.

Najważniejsze do zapamiętania

                  WDAC
                   |
           "Czy ten kod
            może działać?"
                   |
          +--------+--------+
          |                 |
        ALLOW              BLOCK
          |                 |
          v                 v
       Execute          No Execute

A w pełnej architekturze:

Secure Boot
     ↓
Windows
     ↓
HVCI
     ↓
Code Integrity
     ↓
WDAC Policy
     ↓
Application / Driver
     ↓
ALLOW or BLOCK

WDAC nie próbuje wyłącznie wykrywać złośliwego oprogramowania. Jego fundamentalnym zadaniem jest ograniczenie tego, jaki kod system w ogóle może wykonać. Dzięki temu jest jedną z ciekawszych warstw ochrony Windows w środowiskach enterprise i bardzo dobrze uzupełnia Defender, HVCI, Secure Boot oraz architekturę Zero Trust.

Polecane wpisy

Zmiana klucza Windows — jak to zrobić krok po kroku?

Zmiana klucza Windows — jak to zrobić krok po kroku? Klucz produktu Windows to unikalny 25-znakowy kod, który pozwala na Czytaj dalej

Integracja z nowymi technologiami zabezpieczeń sprzętowych w kontekście szyfrowania w Windows 12

🛡️ Integracja z nowymi technologiami zabezpieczeń sprzętowych w kontekście szyfrowania w Windows 12 Współczesne zagrożenia cyfrowe zmusiły twórców systemów operacyjnych Czytaj dalej