Заражений ноутбук у VPN: ізолюйте сеанс, а не маршрут
Розділений тунель змінює те, яку адресу бачить призначення, а не зараження. Три умови визначають порядок ізоляції, доказів і допуску.
Повідомлення про зловживання кінцевою точкою зазвичай надходять із готовим коротким шляхом: перевести ноутбук на розділений тунель, щоб змінилася адреса, яку бачить призначення. Це змінює спостереження, а не зараження. Пристрій зберігає весь внутрішній доступ, який уже має його сеанс, а шкідлива програма продовжує працювати на обладнанні, яке ніхто не оглядав. Порядок роботи мають задавати три умови: до чого ще сягають облікові дані пристрою, чи використовується цей доступ просто зараз і які докази знищить швидке очищення.
Перша умова: до чого ще сягають облікові дані
Відкликаний або вимкнений обліковий запис — це лише половина відповіді, бо клієнт може зберігати сертифікат, кешований токен, збережений заздалегідь спільний ключ або облікові дані машини, які переживуть зміну пароля. Перед вибором дії складіть карту всіх засобів автентифікації, які використовує профіль. Потім перевірте, чи продукт завершує сеанси під час відкликання або лише відмовляє новим.
Там, де шлюз це підтримує, завершіть сеанс явно й підтвердьте за таблицею обліку або сеансів, що він зник. Зміна, яка впливає лише на наступний вхід, залишає поточний потік працювати.
Друга умова: чи використовується доступ зараз
Зіставте вікно оповіщення з фактичним сеансом, призначеною адресою тунелю та ідентичністю пристрою. Спільний корпоративний вихід представляє всіх, хто за ним, тому спостережувана публічна адреса не дає змоги визначити, яка кінцева точка створила потік. Саме це зіставлення люди пропускають, коли оповіщення здається очевидним.
Використовуйте записи, які розгорнутий сервіс справді збирає, наприклад події початку й зупинки обліку, що прив'язують сеанс до ідентичності та адреси. Якщо ці записи неповні, скажіть про це у звіті, а не заповнюйте прогалину поглядом міжмережевого екрана. Звіт, який відокремлює докази від висновків, краще витримує перевірку, ніж той, який цього не робить.
Третя умова: що має пережити відповідь
Ізоляція, що знищує єдину копію доказів, — це другий інцидент. Збережіть відповідні журнали, записи сеансів і артефакти кінцевої точки через процес, який відповідає за зберігання та доступ. Не вставляйте експорт у заявку, яку може прочитати вся команда підтримки.
Далі разом із власником інциденту вирішіть, яку частину кінцевої точки перезібрати. Карантин обмежує шкоду, поки встановлюється обсяг, і він також обмежує те, що реагувальники ще можуть спостерігати, тож ці дві цілі треба свідомо врівноважувати.
Як ізоляція виглядає насправді
Ефективна ізоляція багатошарова: мережевий карантин на рівні доступу, відкликання всіх засобів автентифікації, які використовує профіль, явне завершення сеансу та обмеження внутрішніх прав, які мав обліковий запис. Будь-яке з них окремо залишає відкритий шлях.
| Condition | Act first | Defer |
|---|---|---|
| Credentials reach internal systems | Revoke and terminate the session | Endpoint rebuild |
| Access visibly in use | Quarantine, then scope the reach | Rotation of unrelated accounts |
| Evidence still on the device | Preserve artefacts, restrict read access | Reimage |
У першу годину порядок важливіший за повноту. Відкликання до очищення дає шанс спостерігати реакцію клієнта, а завершення сеансу до відкликання показує, чи шлюз узагалі це поважає. Запишіть, який засіб дав який ефект.
Маршрутизація — рішення сервісу, а не інструмент ізоляції
Розділений тунель зменшує те, що несе офісний вихід, а повний тунель спрямовує більше трафіку обраним шляхом перевірки. Жоден режим не засвідчує кінцеву точку, і жоден не відкликає облікові дані.
Проєкт повного тунелю варто мати, коли шлях перевірки оснащений для виявлення та дій, а це вже інший проєкт, ніж інцидент перед вами. Зміна режиму посеред інциденту здебільшого створює плутанину щодо того, які журнали належать якій поведінці. Режим вирішуйте потім, разом із власником сервісу та командою моніторингу.
Умови повторного допуску
Запишіть умови повторного допуску до повернення пристрою: стан виправлення, який треба перевірити, статус кожного розкритого облікового запису, засоби контролю кінцевої точки, які мають звітувати, і мінімальні права, потрібні обліковому запису, а не ті, що в нього випадково були. Розділіть їх на обов'язкові та бажані. Початковий набір прав не є вимогою.
Чисте сканування — лише один вхід, а успішний вхід доводить тільки те, що процес автентифікації виконався. Відновлюйте доступ поетапно, стежачи за сеансом і використанням ресурсів за затвердженим планом. Назвіть власника будь-якого залишкового обмеження. Якщо зловживання дійшло до партнера через офісний вихід, повідомте його каналом, якого вимагає договір, замість того щоб чекати, поки він помітить.