Red Team: де ламається захист у DevSecOps-контурі
Атакуючий рідко ламає те, що закрито навмисно.
Частіше він проходить шляхами, які ніхто не вважав межею захисту: різниця між образом, що пройшов перевірки на збірці, і тим, що реально працює в експлуатації; обліковий запис сервісу з правами адміністратора «щоб не заважав»; панель моніторингу, відкрита у внутрішній мережі без автентифікації.
Окрема категорія — секрети, успадковані всіма гілками й живуть довше за завдання, заради якого їх створювали.
Red Team вправа відрізняється від сканування тим, що перевіряє не наявність засобу захисту, а можливість пройти ланцюжок до цілі.
Інженери діють за узгодженим сценарієм, у заданому вікні та без руйнівних дій: фіксують точки входу, кроки закріплення, зібрані докази й те, які журнали цей шлях не помітили.
Так виявляються уразливості контуру, невидимі для автоматичних сканерів — ті шукають відомі шаблони, а не логіку вашого розгортання.
Практика дає три стійкі типи знахідок. Розбіжність збірки й експлуатації: режими налагодження, ручні правки конфігурації, образи не з того стану репозиторію.
Надлишкові доступи: спільні ключі, ролі без обмеження області дії, облікові записи, які не відкликають після звільнення співробітника. І службові сервіси, залишені доступними «для налагодження».
Цінність вправи — не в списку уразливостей, а в розумінні, де саме контур пропускає атакуючого. Знайдені приховані шляхи атаки перетворюються на правила доступу й перевірки, а команда отримує досвід, який не вичитати з документації.
Що дає регулярна перевірка захисту: вимірювані ефекти
Перевірка захисту має сенс, коли її результат можна порівняти з попереднім прогоном. Тому до вправи ми фіксуємо базові метрики захищеності, а після рахуємо дельту за кожною.
Сценарії будуємо за тактиками з MITRE ATT&CK, щоб перевірки діставалися до облікових записів, довірчих зв'язків і конвеєра збірки, а не обмежувалися скануванням портів.
Що вимірюємо до і після
- Час виявлення атаки — від першої підозрілої дії до алерту. Типова стартова точка — години, після налаштування кореляції подій — хвилини.
- Частка успішних проходів — яка частина сценаріїв доходить до цільового ресурсу. Падає від прогону до прогону, і це вимірюваний показник, а не відчуття.
- Частка хибних спрацювань — скільки алертів черговий закриває без дії. Якщо половина, сповіщення перестають читати.
- Повнота журналів — чи є події на всьому шляху. Прогалина в логах означає, що атаку не відновлять за хронологією.
Які класи відмов закриваються
- Відсутність сегментації: один сервіс бачить бази сусіднього.
- Довгоживучі ключі та надлишкові права сервісних облікових записів.
- Секрети в репозиторії та у змінних збірки, що потрапляють у логи.
- Ручні правки в прод-середовищі без сліду й можливості відкату.
Закриття позиції підтверджується повторним прогоном: якщо сценарій більше не проходить, відмову усунуто, а не замасковано. Такий чек-ліст стає робочим документом — за ним планують наступний цикл і оцінюють, скільки простою контуру вдалося уникнути завдяки ранньому виявленню.
Формати вправ: від разового штурму до постійного циклу
Формати вправ Red Team відрізняються не глибиною, а горизонтом і тим, що саме вимірюють. Разова перевірка захисту дає зріз на дату, навчання із захисною зміною перевіряє реакцію людей і регламенти, постійний цикл перевірок тримає виявлення й реакцію в робочому стані.
Вибір визначається питанням: довести, що захист не тримає, чи вибудувати процес, який тримає його постійно.
| Формат | Коли підходить | Межі вправи |
|---|---|---|
| Разова перевірка захисту | Потрібен незалежний зріз на дату: перед аудитом, після великого релізу, при вході в новий контур | Оцінює лише те, що потрапило в зону; не тренує зміну й не перевіряє виявлення |
| Навчання із захисною зміною | Є моніторинг і чергові: треба зрозуміти, чи помітять атаку і як відпрацюють регламент | Потрібні узгоджене вікно й усі ролі на місці; результат залежить від складу зміни |
| Спільні навчання атаки й захисту | Треба закрити сліпі зони: захисна група розбирає кроки й править правила виявлення | Обмежені глибиною доступу до телеметрії; без правки правил за підсумками ефект розмивається |
| Постійний цикл перевірок | Контур змінюється безперервно: потрібні регулярні хвилі за розкладом і накопичення метрик виявлення | Працює за виділених ролей і часу на розбір, інакше стає формальністю |
Межі вправи фіксують письмово до першого кроку: сегменти й сервіси, вікно робіт, контакт для зупинки, порядок ескалації, якщо навчальна активність збіглася з реальним інцидентом.
Без стоп-умови навчальна атака на живому контурі невідрізненна від справжньої, і чергова зміна починає розбирати не те.
Як проходить вправа: етапи роботи інженерів
Вправа Red Team — не разова атака, а керована послідовність: спочатку фіксуємо межі й точки відмови, потім перевіряємо, чи побачить їх захист. Нижче — етапи, за якими ведемо роботу, щоб результат був відтворюваним, а не залежав від везіння однієї зміни.
- Аудит контуру. Збираємо карту сегментів, точок входу й критичних сервісів, позначаємо, що входить у вправу, а що залишається за її межами. Тут же узгоджуємо правила взаємодії та канал зв'язку на час прогону.
- Підготовка середовища. Розгортаємо ізольований контур — копію робочої схеми на синтетичних даних, без виходу в продуктив. Окремі мережі й облікові записи не дають діям перетнутися з реальним трафіком.
- Схема сценаріїв. Під кожен ризик — свій сценарій: компрометація облікових даних, бокове переміщення, підвищення прав, винесення даних. У сценарії заздалегідь описано ознаку, за якою захист зобов'язаний відреагувати.
- Прогін. Ідемо за сценаріями й фіксуємо телеметрію: що потрапило в журнали, що залишилося непоміченим, скільки часу минуло від першої дії до реакції. Спроби не зриваємо — документуємо.
- Перевірка виявлення. Звіряємо спрацьовані правила з тими, що мали спрацювати, рахуємо частку помічених кроків і затримку до оповіщення.
- Розбір результатів. Зводимо знахідки за критичністю й розділяємо прогалини у видимості, у правилах і в організаційних процесах — кожен має свій спосіб усунення.
- Передача правил виявлення. Нові та скориговані правила йдуть у моніторинг, а спірні сценарії залишаються в наборі для регулярних прогонів.
Матеріали на виході: звіти, правила виявлення, регламенти
Вправа закривається не презентацією, а комплектом артефактів, які залишаються у вашому контурі й працюють після відходу команди. Нижче — мінімальний набір, який ми здаємо за підсумками: без будь-якого з пунктів перевірка вважається незавершеною.
- Карта шляхів атаки. Схема руху Red Team від точки входу до цільового ресурсу: вузли, облікові записи, використані техніки в нотації MITRE ATT&CK. За нею одразу видно, які переходи не залишають слідів у журналах.
- Правила виявлення. Не опис «що детектити», а готові правила під вашу систему: умова спрацювання, поріг, вікно кореляції, прив'язка до техніки. Кожне прогнано на тестовому контурі — хибних спрацювань на фоновому трафіку немає.
- Звіт за вправою. Хронологія з метриками: час до першого сигналу, частка залогованих кроків, кількість спрацьованих і пропущених детектів, точки, де атакуючого зупинили.
- Регламент реагування. Хто ухвалює рішення, кому ескалює, що робить з ізольованою системою і в які строки. Ролі закріплені за конкретними людьми й чергуваннями, а не за відділами.
- Політики доступу. Закриття надлишкових прав, розділення привілейованих облікових записів, коригування сегментації — у вигляді готових змін конфігурації, а не списку побажань.
- План усунення. Слабкі місця з пріоритетом, власником і критерієм закриття. Те, що не можна виправити налаштуванням, отримує компенсувальний захід контролю й строк перегляду.
- Набір сценаріїв для повторного прогону. Кроки вправи у відтворюваному вигляді — щоб перевіряти, що детекти не відвалилися після релізу або зміни інфраструктури.
Кейс: прихований шлях атаки і що змінилося після розбору
Атаку проводили без попередження чергової зміни: вхід із зовнішнього контуру, мета — винести дані з продуктивного середовища.
Стартовою точкою став токен сервісного облікового запису, який залишився в історії збірок; далі сценарій розвивався кроками, які в матриці MITRE ATT&CK описані як легітимний доступ з подальшим розширенням прав.
Прихований шлях атаки виглядав рутинно: запити йшли від справжнього сервісу, з валідними правами й звичною частотою. Перший сигнал з'явився лише на третю добу, коли дані вже копіювалися в проміжне сховище.
З чотирнадцяти кроків сценарію автоматика позначила п'ять — решта розчинялися в загальному потоці, бо події з кластера, сховища секретів і мережі не зв'язувалися в один ланцюжок. Логи були, а картини не було.
Що змінилося після розбору
Розбір дав шість знахідок, і всі закрили правками, а не звітом.
Побудували кореляцію подій за одним обліковим записом і додали правило на аномальні звернення до секретів, строк життя сервісних токенів обмежили й зробили ротацію обов'язковою, вихідні з'єднання від робочих навантажень звузили до відомих напрямків.
На чергову зміну ліг плейбук із готовими кроками: що перевіряти, кого будити, яке навантаження ізолювати.
Повторна вправа через квартал показала зсув у метриках. Час виявлення скоротився з трьох діб до сорока хвилин, сигнал тепер дають тринадцять кроків із чотирнадцяти, а середній час реакції чергового вклався в десять хвилин.
Виявлення перестало залежати від уважності конкретного інженера в конкретну зміну — спрацьовує зв'язка правил, а не везіння.
Чим Red Team відрізняється від разового пентесту
Разовий пентест відповідає на питання «які діри є в периметрі». Фахівці працюють за узгодженим списком, знаходять уразливості й віддають звіт із пріоритетами — далі починається внутрішня робота з виправлення. Цінність скінченна: щойно звіт закрито, знання залишаються в документі, а не в навичках зміни.
Вправа Red Team відповідає на інше питання — «чи встигне захист помітити й відреагувати». Атакуюча група імітує реального противника: обирає ціль, обходить засоби захисту, закріплюється в інфраструктурі й перевіряє реакцію.
Тут важливий не лише факт проникнення, а й скільки часу минуло до виявлення, чи спрацювала ескалація, чи дійшов сигнал до чергового інженера.
Ключова відмінність — в участі захисної зміни. Пентест її не стосується: вона дізнається про знахідки зі звіту. У вправі зміна грає в реальному часі, а розбір іде за її логами й рішеннями, а не лише за діями атакуючих.
| Критерій | Разовий пентест | Вправа Red Team |
|---|---|---|
| Мета | знайти уразливості периметра | перевірити виявлення й реакцію |
| Хто бере участь | лише атакуюча команда | атакуюча група й захисна зміна |
| Результат | звіт зі списком знахідок | метрики виявлення й розбір рішень зміни |
| Вплив | правки за списком | зміни в правилах, регламентах і навчанні |
На виході — не список уразливостей, а зміни в процесах: правила кореляції, пороги оповіщень, порядок ескалації та чек-лісти чергування. Зміна отримує навик, який залишається в команді після вправи.
Що вирішити до старту: межі, ризики, доступи
Межі вправи фіксуємо письмово до першої команди: перелік сегментів, облікових записів і сервісів, які дозволено зачіпати, і окремий список заборонених дій — атаки на промислові системи, шифрування даних, псування резервних копій.
Там же — критерії негайної зупинки й людина, яка має право її віддати. Без цього документа вправа перетворюється на неконтрольований вплив, а її результати неможливо захистити перед власником сервісу.
Доступи інженерів узгоджуємо так само строго, як і межі. Атакуюча група отримує тимчасові облікові записи з обмеженим строком життя, захисна — розширений доступ до журналів і систем виявлення, але без права змінювати продуктивні налаштування.
Усі дії обох груп пишуться в спільний журнал, тому за підсумками видно, на якому кроці спрацював захист, а де спрацював би моніторинг.
Вправа йде по живому контуру — робочі сервіси постраждають?
Роботи ведемо в узгодженому вікні, зазвичай поза піковими годинами, і лише в тих сегментах, які перелічені в межах. Перед початком знімаємо контрольні точки, щоб повернути стан; вплив на сервіс обмежений імітацією дій, а не реальним виведенням вузлів з ладу.
Якщо метрики доступності виходять за обумовлений поріг, вправа зупиняється за заздалегідь прописаним правилом, а не за рішенням у моменті.
Хто бере участь із боку замовника і скільки часу це займе?
Потрібні три ролі: власник сервісу, який підтверджує межі, черговий інженер, який бачить поведінку систем у реальному часі, і відповідальний за зупинку з правом перервати роботу. Інші співробітники не відволікаються. Від замовника потрібно кілька годин на узгодження й присутність чергової зміни в день проведення.
Що як атакуючі знайдуть дещо більше, ніж передбачалося?
Такі знахідки — мета вправи, але обробляємо їх за регламентом: критична уразливість не розробляється далі, фіксується й передається власнику сервісу одразу, у день виявлення.
Звіт розділяємо на дві частини — закриту для команди супроводу й оглядову для керівництва, без готових інструкцій з експлуатації.
Обговоримо вашу задачу і повернемося з планом
Щоб вправа дала результат, а не звіт заради звіту, на старті потрібен контекст вашої інфраструктури. Від вас — п'ять ввідних:
- схема ключових сервісів і те, що вважаєте критичним: де зупинка на годину дорожча за хибне спрацювання;
- джерела журналів і засоби виявлення, які вже збирають події, — перевіряємо реальну видимість, а не будуємо її заново;
- межі допустимих дій: які вузли й дані не чіпаємо, що можна в робочі години, які зміни потребують узгодження;
- вікна для активної фази й контакти чергових, які підтвердять легітимність дій при спрацюванні;
- критерії успіху: час до виявлення, частка зафіксованих кроків, якість розбору.
У відповідь надсилаємо пакет, за яким можна ухвалювати рішення:
- схему вправи: сценарій, етапи, ролі атакуючої та захисної команд, точки контролю;
- склад робіт із розділенням на підготовку, активну фазу й розбір;
- оцінку строків за етапами й вимоги до ресурсів з вашого боку;
- порядок передачі результатів: хронологія подій, вивантаження з журналів, перелік сліпих зон;
- план усунення знайденого з пріоритетами й повторною перевіркою ключових шляхів.
Опишіть задачу — повернемося з оцінкою строків і планом робіт, а не із загальними обіцянками.
