Zero-day i patch management —
plan na 24 godziny

Kiedy w 2025 roku Microsoft wydał patch dla krytycznego zero-day w Windows (CVSS 9.8), część polskich firm zareagowała w godziny, a część czekała miesiące. Ta różnica to nie szczęście — to przygotowanie. W tym artykule rozkładam **zero-day vs known CVE**, wyjaśniam **CVSS scoring**, pokazuję **5-krokowy plan działania w 24 godziny** i opisuję, jak ManageEngine Endpoint Central automatyzuje to całe zamieszanie.

Zero-day vs known CVE — jaka jest różnica?

Termin zero-day pochodzi z czasów, gdy liczono dni od odkrycia podatności do pojawienia się exploita — na „zero" dni producent miał na opracowanie patcha. Dzisiaj zero-day oznacza podatność, którą producent nie zna albo zna, ale nie ma jeszcze publicznego patcha.

Known CVE to podatność katalogowana w bazie NIST, z przypisanym CVE ID (np. CVE-2025-1234), CVSS scorem i dostępnym patchem. Większość znanych CVE istnieje w bazie przez kilka dni do kilka tygodni zanim pojawi się exploit.

To kluczowe rozróżnienie:

• Zero-day: brak patcha, brak wiedzy producenta, atakujący ma 100% przewagę, obrona = mitygacja (izolacja sieci, WAF, segmentacja)
• Known CVE: patch dostępny, wiedza publiczna, atakujący będzie próbować przed patchowaniem, obrona = szybkie patching + skanowanie

CVSS scoring — jak interpretować ostrość podatności

CVSS (Common Vulnerability Scoring System) to standardowa międzynarodowa skala 0–10 zdefiniowana przez NIST. Każda podatność w bazie CVE ma przypisany CVSS, który określa jej względną ostrość.

Jak interpretować CVSS:

• 0.0–3.9 (Low): minimalne ryzyko, zwykle wymaga fizycznego dostępu lub social engineering, patch w bieżącym cyklu (monthly)
• 4.0–6.9 (Medium): umiarkowane ryzyko, wymaga uwierzytelnienia lub specjalnych warunków, patch co 2 tygodnie
• 7.0–8.9 (High): wysokie ryzyko, zdalny dostęp lub remote execution, patch w 7 dni
• 9.0–10.0 (Critical): krytyczne ryzyko, remote unauthenticated access, full system compromise, patch w 24–72 godziny (obowiązkowe w NIS2)

Przykłady rzeczywiste z 2025 roku:

• CVE-2025-21224 (Windows RCE) — CVSS 9.8 — patch wydany w piątek, wdrożony w poniedziałek (lub szybciej)
• CVE-2024-38063 (Windows LPE) — CVSS 8.2 — patch w ciągu 7 dni
• CVE-2024-1234 (aplikacja niestandardowa) — CVSS 5.5 — monthly patch

Plan działania w 24 godziny (5 kroków)

Gdy pojawi się podatność z CVSS 9+, procedura musi ruszyć natychmiast:

• Krok 1: Identyfikacja (H+0h – H+2h)

  Monitor (NIST NVD, vendora advisory) dostaje alert o podatności. Sprawdzaj: czy dotyczy nas (OS/aplikacja)? Jaki CVSS? Czy jest patch? Trigger: CVSS 9+ = activation full team.

• Krok 2: Ocena wpływu (H+2h – H+4h)

  Ile systemów/maszyn dotyczy podatności? Sprawdzenie inwentarza (CMDB w ManageEngine) — wersje OS, aplikacji, vulnerability scan. Priorytetyzacja: krytyczne (produkcja) vs non-critical.

• Krok 3: Plan działania (H+4h – H+8h)

  Czy patch dostępny? Czy wymaga restartu? Czy są znane problemy compatibility? Estabelish okno patching (night/weekend lepiej, ale dla CVSS 9+ można działać na żywo). Plan rollback (snapshot VM, backup, fallback patch).

• Krok 4: Pilotaż (H+8h – H+20h)

  Patch na TEST environment (2–3 maszyny, reprezentatywne konfiguracje). Test funkcjonalności, aplikacji, sieci. Brak regression = approval dla rollout.

• Krok 5: Full deployment (H+20h – H+24h)

  Staged rollout: 10% → 50% → 100% maszyn. Monitoring (CPU, memory, network, error logs). Być gotowym do rollback na każdym etapie.

Tabela CVSS i okna patching — ile czasu na reaction?

Automatyzacja patch management w ManageEngine Endpoint Central

Manual patch management w skali 50–500 maszyn to chaos. ManageEngine Endpoint Central automatyzuje to całe:

• Automatic vulnerability scanning: co 24 godziny scan wszystkich maszyn pod kątem missing patches i known exploits
• CVSS-based prioritization: system automatycznie priorytetyzuje patches na bazie CVSS i wpływu biznesowego
• Staged deployment: wdrażanie patch'u w falach (10% → 50% → 100%) z monitoringiem na każdym etapie
• Fallback policy: jeśli X% maszyn się zawali po patchu, automatycznie wycofaj patch na pozostałych
• Compliance reporting: raport pokazujący które maszyny są patched, które brakuje patcha i kiedy patch jest wymagany (dla audytu NIS2/ISO 27001)

Typowy workflow w ManageEngine:

1. Pojawia się CVE-2025-99999 (CVSS 9.5) dla Windows 10
2. ManageEngine pobiera patch z WSUS/Windows Update — CVSS 9.5 = alert CRITICAL
3. System sprawdza inwentarz — 120 maszyn Win10 → podatne
4. Tworzy Change ticket (automatycznie przypisany do Security Manager)
5. Wdrażanie: pilotaż (5 maszyn) → monit 2 godziny → staging (60 maszyn) → monitoring 4 godziny → full deployment (55 maszyn)
6. Compliance report: 120/120 patched ✓ Time to patch: 12 godzin

Best practices — staged deployment i rollback

Nigdy nie patchuj wszystko jednocześnie. Nawet jeśli patch pochodzi od Microsoftu i testowałeś 3 dni, zawsze istnieje ryzyko negatywnej interakcji z lokalno-spersonalizowanym systemem.

Staged deployment pattern:

• Wave 1 (5–10% maszyn, T+2h po patchu): reprezentatywne maszyny (mix konfiguracji), krytyczne aplikacje wyłączone na czas testowania
• Monitoring Wave 1 (2–4 godziny): error logs, CPU/memory, network, user reports
• Wave 2 (50% maszyn, T+6h): jeśli Wave 1 OK, rozszerz na 50%
• Monitoring Wave 2 (4 godziny): escalation path gotowy
• Wave 3 (100% maszyn, T+12h): finalny rollout

Rollback procedure (wymagany zawsze):

• Snapshot VM przed patchem (On-Premise) lub image backup (Cloud)
• Znana dobra konfiguracja w repozytorium (u nas = SDP artifact repository)
• Plan komunikacji: kto wyłącza maszynę, kto czeka na rollback, jakie systemy są touched
• Test rollback'u raz na kwartał (nie czekaj na emergency, żeby testować procedurę)

Najczęstsze pytania (FAQ)