Налаштування Windows Defender, які варто змінити сьогодні (не зламано нічого)

Налаштування, які варто змінити (та ті, що залишити в спокої)

1) Увімкніть Tamper Protection (і вважайте це обов’язковим)

Tamper Protection блокує неавторизовані зміни налаштувань Defender. Простіше кажучи: шкідливе ПЗ (і «корисні» скрипти) матимуть складніший час,
щоб вимкнути сигналізацію перед тим, як щось викрасти.

Якщо ви керуєте пристроями централізовано, Tamper Protection має бути ввімкнений і керуватися через політики, а не залишатися на розсуд локальних адміністраторів.
Фіатальна помилка очевидна: ви розслідуєте інцидент і розумієте, що половина флоту мала ключові захисти відключені, бо хтось за старим гайдом «тимчасово відключив захист у реальному часі» і забув про «тимчасово».

2) Використовуйте захист з хмари та автоматичну відправку зразків (з розумною політикою)

Хмарний захист покращує швидкість виявлення нових загроз. Компроміс у тому, що деякі організації мають суворі правила обробки даних
і не хочуть надсилати довільні зразки в Microsoft. Це нормально. Встановіть політику свідомо. Неправильна позиція — «вимкнути, бо може бути питання відповідності».
Після інциденту відділ відповідності поставить більш конкретні питання.

3) Налаштуйте поведінку сканування для передбачуваної продуктивності (не ганяйтеся за мінімумом CPU)

Defender може спричиняти стрибки CPU і диску, особливо на робочих станціях розробників, VDI і агентів збірки з великою кількістю файлів.
Ваша ціль — не нульова витрата ресурсів, а стабільна витрата.

Сфокусуйтеся на:

• Ліміті CPU для сканів (щоб заплановане сканування не тиснуло всіх о 10:00).
• Плануванні сканувань (уникати пікових годин; уникати сюрпризів під час обіду).
• Виключеннях лише там, де їх можна обґрунтувати (шляхи/процеси/розширення з запобіжниками).

4) Розгортайте ASR-правила в режимі аудиту спочатку, потім застосовуйте ті, що з низьким радіусом ураження

Правила Attack Surface Reduction (ASR) — один з найкращих способів підвищити вартість атаки для нападника, не купуючи окремий продукт.
Хитрість — дисципліна розгортання: почніть у режимі Audit, збирайте події, а потім вибірково застосовуйте.

5) Використовуйте Controlled Folder Access обережно: корисно проти рансомвару, але може ламати кастомні додатки

Controlled Folder Access (CFA) дійсно ефективний проти патернів рансомвару — блокує недовірені процеси від запису в захищені папки.
Він має характер: ламає застарілі додатки, які записують куди заманеться.
Впроваджуйте його з процесом додання в allow-list і шляхом ескалації, а не «на око».

Налаштування, які зазвичай НЕ слід змінювати без вагомої причини

• Вимкнення захисту в реальному часі як «виправлення продуктивності». Це — невдала оптимізація, що маскується під безпеку.
• Глобальні виключення шляхів на кшталт виключення C:\ або цілих профілів користувачів. Це не налаштування; це капітуляція.
• Вимкнення моніторингу поведінки щоб уникнути «надокучливих блокувань». Моніторинг поведінки ловить те, що сигнатури пропускають.

Суха істина з операційної практики: надійності не досягають відключенням систем безпеки; надійність досягають, роблячи їх передбачуваними й тестованими.

Цікаві факти та контекст (коротко, конкретно, корисно)

1. Defender починався як окремий продукт. «Microsoft AntiSpyware» існував до того, як перетворився на Windows Defender, а пізніше — Microsoft Defender Antivirus.
2. Двигун змінювався, а не лише маркетинг. Сучасний Defender інтегрує хмарні запити, моделі поведінки та засоби пом’якшення експлойтів, яких не було в інструментах ери Windows 7.
3. ASR-правила народилися з потреб корпоративного загартування. Ідея — блокувати типові техніки вторгнення (дочірні процеси Office, зловживання скриптами) без заміни EDR.
4. Оновлення платформи Defender відрізняються від сигнатур. Сигнатури оновлюються часто; оновлення платформи змінюють ключові компоненти і можуть впливати на продуктивність.
5. Controlled Folder Access побудований навколо патернів рансомвару. Це не «файлові права»; це політично керований довірчий список додатків, що контролює запис у захищені локації.
6. Defender використовує кілька режимів сканування. Є захист у реальному часі (on-access), заплановані та за вимогою — кожен має різні компроміси між продуктивністю й виявленням.
7. Виключення оцінюються в кількох місцях. Є виключення за шляхом, розширенням і процесом — і неправильний вибір може тихо розширити обхід захисту.
8. Windows Security — це UI; Defender — це стек. Люди часто «натиснули щось» і думають, що змінили застосування політик, але реальний стан живе в політиках і налаштуваннях Defender.
9. Журнали подій — джерело істини. UI дружній. Розслідування інцидентів — ні. Операційні журнали Defender — там, де підтверджують, що сталося.

Швидкий план діагностики (знайти вузьке місце швидко)

Коли хтось каже «Defender гальмує», зазвичай мають на увазі: «Щось споживає CPU/диск, і процес Defender видно».
Ваше завдання — довести, де вузьке місце, і вирішити, чи налаштовувати, виключати, перемістити в інший час або ескалувати.

Перше: підтвердіть, що саме зараз виконує роботу

• Перевірте, чи MsMpEng.exe — гарячий процес (CPU), або чи реальним винуватцем є затримка диску.
• Перевірте, чи це заплановане сканування, сканування в реальному часі, викликане збіркою/компіляцією, чи оновлення підписів.
• Перевірте на повторювані цикли виявлень (те саме файли сканується знову і знову через хаос у тимчасових папках).

Друге: класифікуйте навантаження

• Розробник / CI агент: мільйони дрібних файлів, часті записи, розпакування архівів, кеші пакетів.
• VDI / спільний хост: багато профілів користувачів, контейнерів профілю, дублювання сканувань між сесіями.
• Файловий сервер: сканування при записі плюс сканування при читанні з клієнтів.
• Ендпойнт під час інциденту: Defender зайнятий, бо він дійсно щось ловить (або намагається).

Третє: вирішіть мінімальну безпечну зміну

• Якщо проблема в запланованому скануванні: обмежте CPU, змістіть графік, впевніться в поведінці під час простого часу.
• Якщо це churn кешів збірки: розгляньте цілеспрямовані виключення з паперовим слідом, або перемістіть кеші в контрольований шлях.
• Якщо це помилкові спрацьовування: захопіть метадані зразка, оновіть сигнатури/платформу, розгляньте allow-indicators (якщо є EDR), уникайте глобальних виключень.
• Якщо контролі проти рансомвару ламають додатки: перейдіть у режим Audit, збирайте події, потім додайте в allow-list точні бінарники.

Перефразована ідея від Werner Vogels (CTO Amazon): Все ламається, весь час — тому проєктуйте й експлуатуйте системи так, ніби відмови нормальні.

Практичні завдання: реальні перевірки з командами, виводами та рішеннями

Це навмисно операційні. Кожне завдання має: команду, приклад виводу, що означає вивід і яке рішення прийняти.
Команди запускаються з піднятого контексту PowerShell, але я форматую їх як блоки shell, бо так виглядають продакшн-руньбуки.

Завдання 1: Підтвердити, що служба Defender і движок працюють

cr0x@server:~$ powershell -NoProfile -Command "Get-Service WinDefend | Format-List Name,Status,StartType"
Name      : WinDefend
Status    : Running
StartType : Automatic

Значення: Служба Defender Antivirus працює і встановлена на автоматичний запуск.

Рішення: Якщо вона зупинена/відключена несподівано — розглядайте як інцидент безпеки або дрейф політики. Не просто «запустіть» і забудьте — знайдіть, хто змінив.

Завдання 2: Перевірити загальний стан Defender (реальний час, tamper, підпис)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpComputerStatus | Select-Object AMServiceEnabled,AntispywareEnabled,AntivirusEnabled,RealTimeProtectionEnabled,BehaviorMonitorEnabled,OnAccessProtectionEnabled,IoavProtectionEnabled,NISEnabled,TamperProtection,AntivirusSignatureLastUpdated | Format-List"
AMServiceEnabled              : True
AntispywareEnabled            : True
AntivirusEnabled              : True
RealTimeProtectionEnabled     : True
BehaviorMonitorEnabled        : True
OnAccessProtectionEnabled     : True
IoavProtectionEnabled         : True
NISEnabled                    : True
TamperProtection              : True
AntivirusSignatureLastUpdated : 2/5/2026 9:12:41 AM

Значення: Основні захисти ввімкнені; сигнатури оновлені недавно; Tamper Protection увімкнено.

Рішення: Якщо RealTimeProtectionEnabled — false, ви не «налаштовуєте», ви працюєте без гальм. Виправляйте політику перш за все.

Завдання 3: Перевірити поточні налаштування сканування та обмеження

cr0x@server:~$ powershell -NoProfile -Command "Get-MpPreference | Select-Object ScanAvgCPULoadFactor,DisableCpuThrottleOnIdleScans,ScanScheduleDay,ScanScheduleTime,DisableEmailScanning | Format-List"
ScanAvgCPULoadFactor          : 25
DisableCpuThrottleOnIdleScans : False
ScanScheduleDay               : 0
ScanScheduleTime              : 02:00:00
DisableEmailScanning          : False

Значення: Заплановані сканування щодня о 2:00; середній цільовий CPU — 25%.

Рішення: Якщо фактор CPU високий (або розклад збігається з робочими годинами), відкоригуйте, щоб зменшити видимий вплив на користувачів.

Завдання 4: Визначити поточні виключення (шляхи, процеси, розширення)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpPreference | Select-Object ExclusionPath,ExclusionProcess,ExclusionExtension | Format-List"
ExclusionPath      : {C:\BuildCache, D:\Agent\_work\_temp}
ExclusionProcess   : {C:\Program Files\Git\usr\bin\ssh.exe}
ExclusionExtension : {.iso}

Значення: Є поточні виключення. Деякі можуть бути обґрунтованими; деякі — «одноразові хаки, що стали політикою».

Рішення: Аудит виключень щоквартально. Якщо ви не можете пояснити одне реченням — видаліть або обґрунтуйте його даними.

Завдання 5: Перевірити останні загрози та вжиті дії

cr0x@server:~$ powershell -NoProfile -Command "Get-MpThreatDetection | Select-Object ThreatName,Resources,ActionSuccess,InitialDetectionTime | Format-Table -AutoSize"
ThreatName                 Resources                                  ActionSuccess InitialDetectionTime
----------                 ---------                                  ------------- --------------------
Trojan:Win32/Wacatac.B!ml  file:_C:\Users\alex\Downloads\setup.exe    True          2/5/2026 8:04:12 AM

Значення: Defender виявив щось і вжиття заходів було успішним (карантин/видалення).

Рішення: Якщо виявлення часті на робочих кінцях, можлива проблема з навчанням користувачів, прогалина у фільтрації вебу або скомпрометований ланцюжок постачання. Не «виключайте папку Downloads».

Завдання 6: Витягнути останні операційні події Defender (що було заблоковано, що шумить)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' -MaxEvents 10 | Select-Object TimeCreated,Id,LevelDisplayName,Message | Format-Table -Wrap"
TimeCreated           Id LevelDisplayName Message
-----------           -- ---------------- -------
2/5/2026 9:30:02 AM  1116 Warning         Malware detected...
2/5/2026 9:28:10 AM  5007 Information     Configuration has changed...

Значення: Event ID 5007 часто вказує на зміни налаштувань Defender; 1116 — виявлення.

Рішення: Якщо бачите повторювані події 5007, знайдіть джерело (GPO/Intune/локальний адміністратор). Флаппінг налаштувань — сигнал про проблему в операціях.

Завдання 7: Підтвердити стан Tamper Protection через перегляд переваг

cr0x@server:~$ powershell -NoProfile -Command "Get-MpComputerStatus | Select-Object TamperProtection | Format-List"
TamperProtection : True

Значення: Tamper Protection увімкнено.

Рішення: Якщо на керованих пристроях воно false, виправляйте posture керування. Зловмисники люблять кінці, що надто довіряють локальним адміністраторам.

Завдання 8: Виміряти, чи сканування обмежено диском або CPU (швидко і грубо)

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\PhysicalDisk(_Total)\Avg. Disk sec/Read','\PhysicalDisk(_Total)\Avg. Disk sec/Write','\Processor(_Total)\% Processor Time' -SampleInterval 1 -MaxSamples 5"
Timestamp                 CounterSamples
---------                 --------------
2/5/2026 9:41:01 AM       \\...\Avg. Disk sec/Read : 0.045
                          \\...\Avg. Disk sec/Write: 0.062
                          \\...\% Processor Time   : 38.112

Значення: Затримка диску (45–62ms) достатньо висока, щоб усе відчувалося повільним; CPU не завантажений повністю.

Рішення: Якщо латентність висока, виключення не виправлять проблеми зі сховищем. Шукайте, чи антивірус посилює проблеми диску, або чи погане сховище посилює час сканування. Іноді вирішення — «замінити диск» або «перестати використовувати вичавлений VDI-тапір».

Завдання 9: Перевірити часи останніх сканів і чи відбуваються вони, коли ви думаєте

cr0x@server:~$ powershell -NoProfile -Command "Get-MpComputerStatus | Select-Object QuickScanStartTime,QuickScanEndTime,FullScanStartTime,FullScanEndTime | Format-List"
QuickScanStartTime : 2/5/2026 2:00:12 AM
QuickScanEndTime   : 2/5/2026 2:04:58 AM
FullScanStartTime  :
FullScanEndTime    :

Значення: Проводяться quick-скани; full-скан не виконується (можливо, за задумом).

Рішення: Для багатьох кінців часті quick-скани плюс захист у реальному часі достатні; повні скани можна планувати рідше або під час вікон обслуговування.

Завдання 10: Підтвердити версії підписів і движка (і перестати звинувачувати «Defender» абстрактно)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpComputerStatus | Select-Object AMProductVersion,AMEngineVersion,AntivirusSignatureVersion,NISSignatureVersion | Format-List"
AMProductVersion          : 4.18.24090.11
AMEngineVersion           : 1.1.24090.6
AntivirusSignatureVersion : 1.409.1234.0
NISSignatureVersion       : 1.409.1234.0

Значення: Видимі версії продукту/платформи та сигнатур, які можна порівняти по флоту.

Рішення: Якщо підмножина машин має старі версії платформи, очікуйте непослідовної поведінки і виявлень. Виправляйте відповідність оновленням перед хитрим налаштуванням.

Завдання 11: Примусити оновлення підписів (корисно при пошуку помилкових спрацьовувань)

cr0x@server:~$ powershell -NoProfile -Command "Update-MpSignature"

Значення: Defender запитує останні сигнатури з налаштованих джерел.

Рішення: Якщо помилкові спрацьовування зникають після оновлення, ваш «фікс» — покращення частоти оновлень, а не додавання виключень.

Завдання 12: Запустити цілеспрямоване сканування підозрілого файлу або директорії

cr0x@server:~$ powershell -NoProfile -Command "Start-MpScan -ScanType CustomScan -ScanPath 'C:\Users\alex\Downloads'"

Значення: Запускає кастомне сканування; результати потрапляють у журнали подій Defender і в історію загроз.

Рішення: Використовуйте для триажу інцидентів. Якщо сканування постійно долбає одну і ту ж директорію, задумайтеся, чи це не просто churn (temp/build) і чи можна перенаправити її замість виключення.

Завдання 13: Перевірити стан конфігурації ASR (audit vs block)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpPreference | Select-Object AttackSurfaceReductionRules_Actions,AttackSurfaceReductionRules_Ids | Format-List"
AttackSurfaceReductionRules_Actions : {2, 2, 1}
AttackSurfaceReductionRules_Ids     : {D4F940AB-401B-4EFC-AADC-AD5F3C50688A, 3B576869-A4EC-4529-8536-B80A7769E899, BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550}

Значення: Дії відповідають Disabled(0), Block(1), Audit(2), Warn(6) залежно від обробки правил; ви бачите мішанину.

Рішення: Якщо ви не знаєте, який GUID до чого відноситься — то нормально; ваш наступний крок — стандартизувати через політику і моніторити події. Уникайте ручного редагування на кінцях.

Завдання 14: Перевірити стан Controlled Folder Access

cr0x@server:~$ powershell -NoProfile -Command "Get-MpPreference | Select-Object EnableControlledFolderAccess | Format-List"
EnableControlledFolderAccess : 1

Значення: 0=Вимкнено, 1=Увімкнено, 2=Режим аудиту (значення можуть відрізнятися за збіркою/політикою); тут воно ввімкнено.

Рішення: Якщо увімкнено і користувачі скаржаться, що «не можна зберегти файли», дослідіть CFA-події і додайте конкретні додатки в allow-list.

Завдання 15: Прочитати події, пов’язані з CFA (тут живе правда)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' -FilterXPath \"*[System[(EventID=1123 or EventID=1124)]]\" -MaxEvents 5 | Select-Object TimeCreated,Id,Message | Format-Table -Wrap"
TimeCreated           Id   Message
-----------           --   -------
2/5/2026 9:11:20 AM   1123 Controlled Folder Access blocked C:\Program Files\LegacyApp\app.exe from making changes to the folder...

Значення: CFA заблокував застосунок від запису в захищену папку.

Рішення: Якщо додаток легітимний і критичний для бізнесу, додайте в allow-list точний бінарник (за підписом/шляхом). Не вимикайте CFA глобально через одну проблемну програму.

Жарт №1: Вимкнути Defender, щоб «покращити продуктивність», — це як винести датчики диму, щоб переставляти пискати — тихіше, так. Також: палає.

Правила Attack Surface Reduction: загартування, що зазвичай не шкодить

ASR-правила — практичний компроміс між «нічого не робимо» і «впровадили повноцінний EDR з SOC і терапевтом».
Вони націлені на звичні ланцюги атак: макроси Office, що запускають дочірні процеси, виконання скриптів з пошти, крадіжка облікових даних тощо.

Як розгортати ASR, не порушивши бізнес

1. Почніть у режимі Audit принаймні на один бізнес-цикл. Ви хочете побачити, що могло б бути заблоковано.
2. Переглядайте події з власниками додатків: фінансові додатки, доповнення ERP, дивні PDF-інструменти — залучайте власників додатків на старті.
3. Застосовуйте спочатку правила з низьким ризиком (ті, що зупиняють очевидно шкідливу поведінку).
4. Майте процес винятків, що вимагає обґрунтування та строку дії.

На що звертати увагу

• Машини розробників: скриптові та компіляторні ланцюги можуть виглядати як підозріла поведінка, якщо правила надто агресивні.
• Застаріла автоматизація Office: макроси, що створюють процеси або записують файли, можуть викликати правила.
• IT-автоматизація: скрипти управління, що запускаються з мережевих шар, можуть підпасти під дію.

Перевага: ASR зменшує кількість «одного кліку — і ви зламані» шляхів. Вартість: потрібно моніторити, налаштовувати й комунікувати.
Якщо ви впровадите це як сюрпризний податок, користувачі знайдуть обхідні шляхи. Вони завжди знайдуть.

Controlled Folder Access: захист від рансомвару з гострими краями

CFA — одна з небагатьох функцій Windows для кінцевих пристроїв, що безпосередньо перериває поведінку рансомвару: випадкові процеси шифрують документи користувачів.
Вона захищає певні папки за замовчуванням (Documents, Pictures, Desktop) і може бути розширена.

Де CFA виправдовує себе

• Керівники та фінанси: високовартісні цілі, важливі дані.
• Спільні кіоски і VDI: користувачі встановлюють «корисні» утиліти; нападники це люблять.
• Кінці з великою кількістю вкладень: робочі процеси з поштою — поширений вектор.

Де CFA шкодить

• Старі додатки, що записують у захищені локації без сучасних підходів.
• Домашні інструменти, що поставляються як непідписані бінарники і виконуються з профілю користувача.
• Деякі клієнти резервного копіювання/синхронізації, які не розпізнаються як дозволені додатки.

Операційна дисципліна для CFA

Вам потрібний цикл: розгорнути (audit), збирати блокування, дозволяти легітимні додатки, застосувати. Повторювати.
Якщо ви пропустите цикл allow-list, CFA стане «функцією безпеки», яку користувачі відчують як «IT поламало збереження файлів».
І вони будуть праві.

Виключення: робіть менше, робіть точно, документуйте

Виключення — найзловживаніша функція Defender. Водночас іноді вони необхідні.
Різниця між «необхідним» і «ледачим» — чи можете ви пояснити компроміс ризику та виміряти виграш у продуктивності.

Принципи безпечних виключень

• Віддавайте перевагу виключенням процесів над виключеннями шляхів, коли доречно. Виключення шляху може бути зловживане шляхом розміщення шкідливого ПЗ у цьому шляху.
• Уникайте виключення шляхів, доступних для запису користувачами (Downloads, Temp, AppData). Саме там інтернет святкує.
• Виключайте кеші збірки, а не цілі робочі простори — і тримайте кеші на відокремленому шляху.
• Встановлюйте строк дії виключень: додавайте дати перегляду. Те, що мало сенс під час міграції, може стати небезпечним через рік.
• Вимірюйте вплив: не зберігайте виключення, які не дають реального результату.

Звичні кандидати, що умовно безпечні (з застереженнями)

• Каталоги кешів CI збірок на виділених агентах, якщо агент епhemeral і артефакти скануються в іншому місці.
• Великі образи дисків VM у контрольованих директоріях (все ще ризиковано; залежить від джерела і використання).
• Директори даних баз даних для локальних дев СУБД (але краще почати з налаштування БД і відділення дисків).

Якщо ви виключаєте щось через те, що «воно гріє ноутбук», ви, ймовірно, ігноруєте справжню проблему: навантаження, що створює патологічний churn файлів.
Виправте churn (розміщення кешу, налаштування збірки, прибирання тимчасових файлів), і Defender стане менш драматичним.

Планування сканувань і обмеження CPU

У корпоративному житті два найгірші часи для важких сканувань: 9:00 ранку і «коли їм заманеться».
Заплановані сканування мають бути нудними. Передбачуваними. Документованими.

Встановіть розумний кап на CPU для запланованих сканувань

CPU-throttle сканувань Defender не ідеальний, але краще, ніж дозволяти сканам змагатися з дзвінком Teams, збіркою і VPN-клієнтом.
Типова початкова точка для кінців — 15–30. Для серверів залежить від навантаження і вікон обслуговування.

cr0x@server:~$ powershell -NoProfile -Command "Set-MpPreference -ScanAvgCPULoadFactor 20"

Значення: Обмежує середній CPU, який Defender прагне використовувати під час сканів.

Рішення: Якщо користувачі все одно відчувають вплив, спочатку відкоригуйте розклад, потім розгляньте подальше зменшення. Не ставте так низько, щоб сканування ніколи не завершувалось.

Перенесіть заплановані сканування з пікових годин

cr0x@server:~$ powershell -NoProfile -Command "Set-MpPreference -ScanScheduleDay 0 -ScanScheduleTime 03:00:00"

Значення: Щоденне сканування о 3:00 (day=0 часто означає «кожен день»).

Рішення: Якщо пристрої сплять вночі, можливо, краще використовувати поведінку під час простою або щотижневе сканування у передбачуваному вікні, коли пристрої увімкнені (наприклад, понеділок 12:30 у організації з ноутбуками). Оберіть те, що відповідає реальності.

Перевірте, чи заплановані сканування не накладаються на вікна обслуговування

Сканування Defender плюс патчинг плюс індексація плюс резервне копіювання можуть створити прекрасну таємницю «чому все повільно о 2:00».
Розставте важкі завдання по черзі. Ви хочете одного «хулігана» на майданчику.

Оновлення підписів і платформи: нудна, але важлива частина

Оновлення — це те, де Defender тихо виграє або програє.
Прострочені сигнатури викликають помилкові спрацьовування і пропуски.
Прострочені версії платформи викликають дивну продуктивність і неконсистентну поведінку політик.

Практична позиція

• Зробіть видимою відповідність оновленням сигнатур. Якщо ви не можете цього виміряти, ви помітите проблему лише коли щось зламається.
• Розгортайте оновлення платформи з контролем змін. Не тому, що вони страшні — тому що вони можуть змінити поведінку сканування і сумісність.
• Під час усунення несправностей знімайте версії. «Defender зробив це» — не дієвий звіт про інцидент.

Жарт №2: Єдина річ вічніша за застарілий додаток — це нарада про те, чому ми не можемо оновити застарілий додаток.

Три міні-історії з корпоративного світу (усі досить болючі)

Міні-історія 1: Інцидент через хибне припущення

Середня компанія розгорнула політику «загартування робочих станцій розробників». Команда безпеки зробила, як вважала за потрібне:
вони увімкнули Controlled Folder Access і декілька ASR-правил. Тестували на чистому ноутбуці з новою інсталяцією — і все виглядало добре.

Хибне припущення було тонким: вони думали, що розробники в основному використовують сучасні тулчейни під Program Files.
Насправді, половина групи розробників запускала портативні тулчейни з профілей користувачів, включно з неподписаними утилітами збірки та кастомним упаковщиком.
Інструмент зберігав артефакти збірки у захищених папках через звичку «зберегти на Desktop для зручності».

У понеділок збірки почали падати. Не всі. Достатньо, щоб викликати хаос.
Помилки були непослідовні: «доступ відмовлено» тут, «файл не знайдено» там, і багато розробників звинувачували систему збірки, мережу та один одного.
Defender робив саме те, що від нього хотіли: блокував недовірені процеси від запису у захищені локації.

Відновлення навчило оперативної емпатії. Вони переключили CFA в Audit для OU розробників, зібрали події і склали allow-list для реальних інструментів.
Також змінили рекомендації для середовища розробки: виходи збірки йдуть у відокремлений робочий шлях, не на Desktop/Documents.
Безпека повернула свій захист. Розробники отримали передбачувану поведінку. Єдина справжня втрата — віра всіх у «ми протестували це один раз».

Міні-історія 2: Оптимізація, що відпрацювала проти

Інфраструктурна команда керувала флотом Windows CI-агентів, що запускали контейнеризовані збірки з великою кількістю checkout-ів і відновлень пакетів.
Вони помітили, що Defender жере диск, і вирішили «оптимізувати»: додали широкі виключення для всього простору агента і тимчасових директорій.
Збірки стали швидшими. Усі святкували. Тут варто насторожитися.

Через кілька тижнів розробник підчепив скомпрометовану залежність через менеджер пакетів. Шкідливий код опинився в виключеному робочому просторі.
Defender його не просканував — бо йому сказали цього не робити. Після запуску payload під час кроку збірки він вкрав креденшіали з змінних оточення
і використав їх для доступу до внутрішнього репозиторію артефактів.

Інцидентна відповідь була неприємна, але повчальна. Команда зрозуміла, що оптимізували неправильний шар.
Їм не потрібно було виключати весь робочий простір; потрібно було управляти високочастотними кешами точно і робити агенти епhemeral.
Вони перемістили кеші в відокремлені шляхи, виключили лише їх на епhemeral агентах і додали сканування при публікації артефактів.

Висновок: покращення продуктивності шляхом «не дивитись туди» — це не виграш у продуктивності.
Це відтерміновані інциденти з кращим PR, поки не настане день, коли це помітять усі.

Міні-історія 3: Сумна, але правильна практика, що врятувала ситуацію

Велике підприємство керувало змішаними Windows-кінцями і мало суворий контроль змін. Це не було гламурно.
Але у них була одна звичка, яка окупалася: вони централізовано логували зміни конфігурацій Defender і переглядали їх при усуненні проблем.

Одного тижня зросла кількість звернень в хелпдеск: машини «раптом» втратили захист у реальному часі. Дехто бачив попередження; інші просто мали дивну поведінку:
завантаження поводились інакше, скрипти падали, і звіти по позі безпеки показували прогалини.

Команда не гадала. Вони витягли операційні журнали Defender і знайшли повторювані події зміни конфігурації.
Спричувавши їх з логами системи управління кінцями, вони прослідкували за джерелом до пілотної GPO, призначеної для невеликої тестової групи.
Хтось зв’язав її занадто високо в структурі OU. Політика відключила кілька захистів, щоб «зменшити тертя для розробників» для тестової групи.
Вона поширилася широко.

Завдяки нудній, але правильній практиці — централізованому перегляду логів, відстеженню змін і дисципліні корелювати події — вони швидко скасували зв’язок,
перевірили стан захистів і скоротили час експозиції.
Ніхто не писав героїчний постмортем. В цьому і сенс. Надійність часто — це відсутність драми.

Типові помилки: симптом → корінь проблеми → виправлення

1) Симптом: «MsMpEng.exe використовує 30–60% CPU весь день»

Корінь проблеми: Сканування в реальному часі тригериться через високий churn файлів (виходи збірок, кеші пакетів, журнали) або застрягле сканування великого дерева архівів.

Виправлення: Визначте директорії churn, перемістіть кеші в відокремлені шляхи, потім розгляньте цілеспрямовані виключення. Також обмежте CPU запланованих сканів і перенесіть розклад.

2) Симптом: «Диск 100% під час сканів; все зависає»

Корінь проблеми: Система прив’язана до диску (повільний HDD/контендентне VDI-сховище) + сканування великого набору файлів. Defender підсилює вже слабкий I/O.

Виправлення: Виміряйте латентність диску лічильниками; покращіть рівень сховища або зменшіть одночасність сканувань розкладом. Не розглядайте обмеження сховища як проблему конфігурації антивірусу.

3) Симптом: «Конкретний внутрішній інструмент раптом не може зберегти файли в Documents/Desktop»

Корінь проблеми: Controlled Folder Access блокує недовірений/непідписаний бінарник, або патерн запису додатку виглядає як рансомвар-поведінка.

Виправлення: Перевірте CFA-події (1123/1124). Додайте в allow-list точний бінарник, якщо він легітимний; розгляньте підписування коду; або змініть інструмент, щоб писати в дозволені шляхи даних.

4) Симптом: «Скрипти перестали працювати; автоматизація Office зламана»

Корінь проблеми: ASR-правила перейшли з Audit у Block без перевірки бізнес-воркфлоу.

Виправлення: Відкотіть в Audit для уражених груп, перегляньте ASR-події, потім застосовуйте лише ті правила, що не ламають потрібну автоматизацію — або додайте вузьконаправлені винятки.

5) Симптом: «Defender постійно позначає наш інсталяр як шкідливий»

Корінь проблеми: Виявлення на основі репутації/хмарної евристики, спричинене низькопоширеними бінарниками, непідписаними інсталяторами або артефактами пакування.

Виправлення: Переконайтеся, що інсталятор підписано, стабілізуйте вхідні дані pipeline, оновіть сигнатури/платформу. Уникайте постійних виключень для інсталяторів, що розповсюджуються широко.

6) Симптом: «Налаштування Defender постійно змінюються назад»

Корінь проблеми: Керована політика (GPO/MDM), що перевизначає локальні зміни, або Tamper Protection, що блокує локальні перемикання.

Виправлення: Перестаньте змінювати налаштування локально. Визначте джерело політики; оновіть його централізовано; перевірте через журнали і Get-MpPreference.

7) Симптом: «Сканування ніколи не завершується»

Корінь проблеми: Конфлікт розкладу сканування зі сном/гібернацією, або CPU-throttle встановлено так низько, що скан не встигає за відведений час, або цикли шляху на волатильних директоріях.

Виправлення: Перевірте часи початку/закінчення останніх сканів. Відкоригуйте розклад на вікно, коли машини увімкнені; трохи підніміть фактор CPU; зменшіть churn шляхів, перемістивши/сконтролювавши тимчасові директорії.

Чеклісти / покроковий план

План A: Зробити Defender безпечнішим без порушення робочих процесів (сьогодні)

1. Оцініть початковий стан на репрезентативній машині:
   • Запустіть Get-MpComputerStatus і збережіть вивід.
   • Запустіть Get-MpPreference і збережіть вивід.
2. Увімкніть/перевірте Tamper Protection через платформу управління. Підтвердіть за Get-MpComputerStatus.
3. Переконайтесь, що хмарний захист відповідає вашому ризику; не залишайте його невизначеним.
4. Встановіть кап CPU для сканувань на консервативне значення (почніть 20–30 для кінців).
5. Перенесіть розклад сканувань з пікових годин. Підтвердіть через поля часу останнього сканування.
6. Увімкніть ASR в Audit для пілотної групи. Збирайте події протягом 1–2 тижнів.
7. Увімкніть CFA в Audit для пілотної групи, якщо ризик рансомвару суттєвий. Створіть процес обробки запитів на allow-list.
8. Перегляньте існуючі виключення. Видаліть все широке або доступне для запису користувачами, якщо не можете це обґрунтувати.

План B: Стабілізувати скарги на продуктивність (без підриву безпеки)

1. Підтвердіть вузьке місце за допомогою лічильників (CPU vs латентність диску).
2. Знайдіть churn-шляхи запитанням: яка директорія постійно записується? Зборки, клієнти синхронізації, розпакування, кеші браузера.
3. Перемістіть кеші у відокремлений каталог, який можна обґрунтовано виключити за потреби.
4. Віддавайте перевагу виключенням процесів коли перевантаження пов’язане з відомим тулчейном.
5. Міряйте до/після за допомогою лічильників і видимих метрик для користувача (тривалість збірки, час входу, чутливість VDI).

План C: Підготуватися до аудитів і реагування на інциденти (негламурний план надійності)

1. Централізуйте журнали Defender або хоча б стандартизуйтe збір подій на кінцях.
2. Відстежуйте зміни конфігурацій (ID подій як 5007) і корелюйте з розгортаннями політик.
3. Стандартизувати рівні політик: сервери, VDI, робочі станції розробників, стандартні кінці.
4. Щоквартальний перегляд виключень з власниками та датами закінчення терміну дії.

FAQ

1) Чи варто вимикати захист у реальному часі, щоб пришвидшити збірки?

Ні. Якщо збірки повільні, знайдіть директорії з високим churn і виправте розміщення кешів спочатку. Якщо треба, додайте вузькі виключення на епhemeral CI-агентах, а не на ноутбуках розробників.

2) Чи безпечно додавати виключення для моєї папки з кодом?

Зазвичай ні. Деревовидні репозиторії часто доступні для запису інструментами і можуть отримувати контент з зовнішніх репозиторіїв. Якщо мусите, виключайте лише конкретні виходи збірки або каталоги кешу, а не весь репозиторій.

3) Чому Defender постійно знову вмикає налаштування, які я вимкнув?

Бо управління політикою і Tamper Protection виконують свою роботу. Локальні перемикання — не стратегія конфігурації. Знайдіть джерело політики і змініть його там.

4) У чому різниця між сигнатурами і оновленнями платформи?

Сигнатури — це дані виявлення, вони оновлюються часто. Оновлення платформи змінюють движок Defender/компоненти і можуть впливати на продуктивність і поведінку функцій.

5) Чи замінює Controlled Folder Access резервні копії?

Ні. CFA зменшує ймовірність шифрування важливих папок рансомваром. Резервні копії — як ви відновлюєтеся, коли щось все ж піде не так — бо таке трапиться.

6) Якщо я увімкну ASR-правила, чи зламаються макроси Office?

Може трапитись, залежно від набору правил і того, як ви використовуєте макроси. Розгортайте в Audit спочатку, перегляньте події, потім застосовуйте вибірково.

7) Чому Defender сканує мої великі образи VM або ISO-файли?

Бо це файли. Defender не знає, що вони «просто образи», якщо ви явно не вказали виключення — і це ризиковано. Краще зберігати такі артефакти в контрольованих шляхах і сканувати під час ingest/publish.

8) Як довести, що Defender — це вузьке місце, а не підсистема сховища?

Використовуйте лічильники продуктивності. Якщо латентність диску висока під час активності сканування, сховище — вузьке місце. Defender може бути тригером, але платформа — лімітатор.

9) Чи безпечніші виключення процесів, ніж шляхів?

Часто так — бо виключення шляху можна зловживати, помістивши шкідливі файли в ту директорію. Виключення процесів все ще ризиковані, якщо нападник може захопити або підмінити виключений процес.

10) Яка найбезпечніша «швидка перемога» для налаштування?

Увімкніть/перевірте Tamper Protection і переконайтесь, що підпис/платформа оновлені. Потім обмежте CPU сканування і перенесіть сканування з пікових годин.

Висновок: наступні кроки, які ви справді можете зробити сьогодні

Якщо ви не зміните нічого іншого: перевірте Tamper Protection, переконайтесь, що захисти увімкнені, і перестаньте дозволяти сканування захоплювати користувачів зненацька.
Потім рухайтесь вгору по кривій зрілості: ASR в Audit, CFA в Audit, дисципліноване allow-listування і виключення, що вузькі, перевірені і вимірювані.

Практичний список наступних кроків:

1. Запустіть Get-MpComputerStatus і Get-MpPreference на трьох типах машин (стандартний користувач, розробник, VDI/сервер) та порівняйте.
2. Встановіть кап CPU для сканування і передбачуваний розклад.
3. Зробіть інвентар виключень і видаліть усе, що не можете захистити в огляді безпеки.
4. Увімкніть ASR-правила в Audit для пілотної групи і переглядайте події щотижня.
5. Увімкніть CFA в Audit там, де ризик рансомвару реальний, і побудуйте процес allow-list перед застосуванням.

Defender не ідеальний. Але він вже на ваших машинах, глибоко інтегрований в ОС, і ним можна керувати як продакшн-системою: вимірюючи, контролюючи і роблячи нудним.
Нудне — це добре. Нудне дає спокій.