За последние два года я участвовал в разборе четырнадцати инцидентов с подтверждённым инсайдером. В восьми из них организация потеряла контроль над доказательной базой. Причина банальная: IR-команда действовала по стандартному playbook для внешних атак - изолировала хост, заблокировала учётку и спугнула инсайдера раньше, чем юристы успели зафиксировать улики. По данным Ponemon Institute (Global Cost of Insider Threats Report 2022), средний годовой ущерб от халатности сотрудников - 6.6 миллиона долларов, а на локализацию инцидента уходит в среднем 85 дней. Восемьдесят пять. Почти три месяца.
Этот playbook - конкретная последовательность шагов, которая учитывает специфику инсайдерского кейса: юридические ограничения, тихий containment, chain of custody и коммуникацию, при которой подозреваемый не узнает о расследовании раньше времени.
Бизнес-логика инсайдерской атаки: kill chain инсайдера по MITRE ATT&CK
Прежде чем открывать playbook, стоит разобраться, как выглядит типичная цепочка действий инсайдера - не внешнего APT, а человека с легитимным доступом. Без этого не выстроить ни триаж алерта, ни containment.Инсайдер уже внутри периметра. Ему не нужен initial access через фишинг или эксплуатацию уязвимости - он использует Valid Accounts (T1078, Initial Access / Persistence / Privilege Escalation). Вот ключевое отличие от внешней угрозы: первый индикатор - не "вход с подозрительного IP", а аномалия в паттерне использования легитимных привилегий. Он приходит на работу каждый день, пьёт кофе с коллегами и параллельно тянет данные.
Типичная kill chain:
- Злоупотребление доступом (T1078, Initial Access / Defense Evasion; T1083, Discovery - File and Directory Discovery) - сотрудник обращается к ресурсам за пределами должностной функции. Финансовый аналитик лезет в инженерные репозитории, HR-менеджер скачивает клиентские базы. Никакой lateral movement - просто открыл другую папку.
- Сбор данных (T1005, Collection - Data from Local System; T1213, Collection - Data from Information Repositories) - инсайдер копирует файлы с рабочей станции, выгружает документы из SharePoint, Confluence, внутренней wiki.
- Промежуточное хранение (T1074.001, Collection - Local Data Staging) - перед выводом данные складываются в одну директорию, архивируются, иногда шифруются. Это один из наиболее детектируемых моментов: создание крупных архивов в нетипичных каталогах. Если у вас настроен мониторинг - тут его и ловить.
- Эксфильтрация (T1052.001, Exfiltration - Exfiltration over USB) - флешка, внешний диск, иногда облачный upload на личный аккаунт. USB остаётся классическим вектором для инсайдеров: не требует сетевой активности и не порождает аномального исходящего трафика.
- Заметание следов (T1685.005, Defense Evasion - Clear Windows Event Logs) - продвинутые инсайдеры чистят логи, отключают аудит. Иногда срабатывает Disable or Modify Tools (T1685, Defense Evasion) - отключение DLP-агента на рабочей станции. Видел кейс, когда сотрудник просто остановил сервис Symantec DLP через
services.msc- у него были права локального админа. - Деструктивные действия (T1531, Impact - Account Access Removal) - саботаж при увольнении: удаление учётных записей коллег, вайп данных, отзыв доступов.
Алерт инсайдерская активность в SIEM: триаж и первичный анализ
Типовые триггеры в Splunk и Microsoft Sentinel
Расследование инсайдерской угрозы начинается с алерта. Вопрос - какие алерты сигнализируют именно об инсайдерской активности, а не о внешней компрометации.Microsoft Sentinel - правила из UEBA-модуля при включённом User and Entity Behavior Analytics:
AnomalousDataAccess- пользователь обращается к ресурсу, к которому не обращался 60+ днейMassDownload- загрузка аномально большого объёма файлов из SharePoint или OneDrive за одну сессиюFirstTimeAccessToResource- первый доступ к конфиденциальному ресурсу, особенно критичен после подачи заявления об увольнении
Код:
index=windows sourcetype=WinEventLog:Security EventCode=4663
| stats count by Account_Name, Object_Name
| where count > 100
| sort -countVaronis строит поведенческий baseline по каждому пользователю автоматически и сигнализирует при отклонении. Типичный алерт: "User accessed 500+ files in a folder they haven't touched in 90 days". Securonix генерирует risk score на основе поведенческих моделей: превышение порога (обычно 80+ из 100) - повод для ручного анализа. Согласно NIST CSF v2.0 (RS.AN-01), каждое уведомление от систем обнаружения подлежит расследованию.
Decision tree: инсайдер или скомпрометированная учётка
Получив алерт, первый вопрос: это действительно инсайдер или его учётку угнал внешний атакующий? Разница определяет весь дальнейший план реагирования на инцидент с инсайдером.| Признак | Инсайдер | Скомпрометированная учётка |
|---|---|---|
| Источник входа | Корпоративная сеть, VPN с привычного устройства | Новый IP, нетипичная геолокация, незнакомое устройство |
| Время активности | Рабочие часы или чуть за пределами | Нерабочее время, ночи, выходные |
| Паттерн доступа | Постепенная эскалация, знание внутренней структуры | Хаотичный перебор, массовый доступ сразу |
| Lateral movement | Минимален или отсутствует | Активный - попытки расширить плацдарм |
| MFA-события | Штатное прохождение | Множественные сбои, попытки сброса MFA |
Если признаки указывают на инсайдера - дальше по этому playbook. Если на компрометацию - стандартный IR с блокировкой учётки и анализом вектора проникновения.
Критический нюанс при реагировании на инсайдерскую атаку: при подозрении на инсайдера нельзя сразу блокировать учётку. Это предупредит сотрудника и уничтожит возможность собрать полную доказательную базу. Стандартный IR playbook здесь не работает. Я это повторю ещё раз ниже, потому что половина инцидентов, которые я видел, были запороты именно на этом шаге.
Containment инсайдера: два сценария реагирования
Containment инсайдера - самая сложная фаза, потому что здесь сталкиваются два требования: минимизировать ущерб прямо сейчас и сохранить цифровые доказательства для юридических действий. Решение зависит от одного вопроса: сотрудник ещё в штате или уже нет.Сценарий А: сотрудник ещё в штате - тихий containment
Таймлайн: от 0 до 72 часов после подтверждения алерта.Цель - ограничить вред без информирования подозреваемого.
Час 0-4: тихие меры.
Уведомить юридический отдел и HR-директора. Без их санкции - никаких действий с учёткой. NIST SP 800-53 (IR-1) требует координации между организационными подразделениями при реагировании на инцидент. Связаться с непосредственным руководителем подозреваемого - только для верификации бизнес-обоснованности доступа, не для информирования о расследовании. Убедиться, что аудит включён на всех ресурсах, к которым обращается подозреваемый: если аудит был отключён - включить максимально незаметно через GPO.
Час 4-24: усиление мониторинга.
На рабочей станции подозреваемого включить расширенное логирование через EDR-политику. Для CrowdStrike Falcon - переключить хост в политику с maximum visibility (Response Policy -> Enhanced visibility). Для Microsoft Defender for Endpoint - включить Advanced Hunting с расширенным набором событий DeviceFileEvents, DeviceLogonEvents, DeviceNetworkEvents.
DLP: в Forcepoint или Symantec DLP переключить политику на monitor-only, если ранее стояла block. Задача - видеть, что именно инсайдер пытается вынести, а не просто блокировать. Блокировка покажет ему, что его засекли. Это контринтуитивно для большинства IR-инженеров (рефлекс - "заблочить немедленно"), но в инсайдерском кейсе monitor-only - единственный правильный режим.
Сетевой мониторинг: добавить IP рабочей станции в watch list на NGFW для зеркалирования трафика. Записывать DNS-запросы и HTTP/HTTPS метаданные.
Час 24-72: ограничение без детекции.
Если подтверждается активная эксфильтрация - мягко ограничить доступ: убрать из групп AD, к которым сотрудник не обращался последние 30 дней. Это не вызовет подозрений - он не использовал эти ресурсы.
USB-порты: через endpoint management (Microsoft Intune, SCCM) отключить USB mass storage для конкретного хоста. Обосновать как "обновление политики безопасности для отдела" - не для одного сотрудника.
Снять forensic-образ рабочей станции при первой возможности. Планово - под предлогом "замены оборудования" или "обновления диска". Подробнее - в разделе про форензику ниже.
Решение о жёстком containment принимается совместно IR-лидом, юристом и HR. Если эксфильтрация подтверждена и продолжается - блокировка учётки и конфискация оборудования с немедленным уведомлением сотрудника. Если эксфильтрация прекратилась - расследование продолжается в тихом режиме до сбора полной доказательной базы.
Сценарий Б: сотрудник уволен или уходит - жёсткая изоляция скомпрометированного пользователя
Этот сценарий проще технически, но требует чёткой координации с HR по таймингу. Все действия по изоляции скомпрометированного пользователя выполняются одновременно, в момент объявления сотруднику об увольнении.До дня увольнения (T-7 дней):
Снять полный forensic-образ рабочей станции, пока сотрудник не начал чистить данные. Экспортировать логи его активности из SIEM за последние 90 дней - сохранить отдельно с хешем и таймстемпом. Проверить, нет ли у сотрудника service accounts, API-ключей, SSH-ключей, клиентских сертификатов - всего, что переживёт отключение основной учётки AD. Этот пункт пропускают чаще всего. А потом удивляются, откуда через два месяца приходят запросы к API с отозванного (как думали) аккаунта.
В момент увольнения (день T) - все действия одновременно:
Код:
# Disable AD account and move to quarantine OU
Disable-ADAccount -Identity "username"
Move-ADObject -Identity "CN=username,OU=Employees,DC=corp,DC=local" `
-TargetPath "OU=Terminated,DC=corp,DC=local"
# Remove from all groups except Domain Users
Get-ADUser "username" -Properties MemberOf |
Select-Object -ExpandProperty MemberOf |
Where-Object { $_ -notmatch 'CN=Domain Users' } |
ForEach-Object { Remove-ADGroupMember $_ -Members "username" -Confirm:$false }Revoke-MgUserSignInSession -UserId username@corp.local через Microsoft Graph PowerShell; модуль AzureAD deprecated). Отключить учётки в SaaS-сервисах - Slack, Jira, Confluence, корпоративная почта. Забрать оборудование и пропуска физического доступа. Проверить Account Access Removal (T1531, Impact) - убедиться, что сотрудник не удалил и не модифицировал учётки коллег перед уходом.Разрыв между уведомлением об увольнении и блокировкой доступа - окно для деструктивных действий. В одном из кейсов сотрудник за 12 минут между звонком HR и отключением учётки успел удалить три репозитория в GitLab и отозвать доступ у двух коллег. Двенадцать минут. Три репозитория. Два коллеги без доступа. Разрыв должен быть ноль.
Юридическая фиксация инцидента: форензика инсайдерской атаки
Юридическая фиксация инцидента кибербезопасности - то, что отделяет профессиональный IR от "потушили пожар и забыли". Без корректного сбора доказательств суд не примет электронные артефакты, и организация проиграет трудовой спор.Снятие образов и сбор цифровых доказательств
Требования к окружению для forensic-сбора:- ОС: Windows 10/11 или GNU/Linux (Ubuntu 22.04+)
- RAM: минимум 16 ГБ на рабочей станции аналитика
- Инструменты: FTK Imager (бесплатный, актуальную версию проверять на сайте Exterro) или
ddна GNU/Linux - Внешний носитель: объём больше диска целевой машины, физический write-blocker для офлайн-снятия
- Подключить write-blocker к диску целевой машины при офлайн-снятии или использовать forensic-агент на живой системе.
- Снять полный bit-for-bit образ. Через FTK Imager - формат E01 с верификацией MD5 и SHA1. Через
dc3dd(форкddс встроенным хешированием):dc3dd if=/dev/sda hof=/mnt/evidence/image.dd hash=sha256 log=/mnt/evidence/image.log. Если доступен толькоdd:dd if=/dev/sda of=/mnt/evidence/image.dd bs=1M conv=noerror,sync, после снятия - рассчитать хеш источника и образа:sha256sum /dev/sda,sha256sum /mnt/evidence/image.ddи сравнить. - Записать хеш в бумажный протокол с подписью аналитика, датой и временем. Бумажный. С подписью. Не в Notion, не в Confluence - на бумаге.
- Снять RAM-дамп, если машина включена: через WinPmem или Belkasoft RAM Capturer. Это критично для обнаружения данных в открытом виде и активных процессов.
- Сделать скриншоты рабочего стола - перед выключением машины.
Оформление chain of custody для суда и трудовых разбирательств
Chain of custody в кибербезопасности - непрерывная цепочка документирования: кто имел доступ к цифровым доказательствам, когда и что с ними делал.Документ chain of custody содержит:
- Уникальный номер вещественного доказательства
- Описание объекта (серийный номер диска, MAC-адрес, модель ноутбука)
- Дату и время изъятия
- Кто изъял (ФИО, должность, подпись)
- Хеши образов (SHA-256)
- Каждую передачу: от кого, кому, дата, время, подписи обеих сторон
- Условия хранения (номер сейфа, номер помещения)
Дополнительные артефакты для расследования инсайдерской угрозы:
- Логи DLP (Forcepoint / Symantec DLP): какие файлы копировались, куда, в каком объёме
- Логи SIEM: полная хронология действий за период подозрительной активности
- Логи AD: изменения членства в группах, попытки доступа, выданные Kerberos-тикеты
- Логи VPN и прокси: внешние подключения, URL-адреса облачных хранилищ
- Записи физического доступа (СКУД): когда сотрудник находился в офисе
Коммуникация при инциденте безопасности с инсайдером
Коммуникация при инциденте безопасности с инсайдером радикально отличается от коммуникации при внешней атаке. Главное ограничение: круг посвящённых минимален до завершения сбора доказательств.
Внутренняя коммуникация: кого уведомлять и когда
Немедленно (час 0): CISO или руководитель ИБ, старший юрист с опытом трудовых споров, HR-директор (не линейный HR-менеджер - именно директор).После подтверждения инцидента (час 4-24): генеральный или операционный директор при значительном масштабе ущерба, непосредственный руководитель подозреваемого - только для верификации бизнес-контекста.
После containment (час 72+): IT-отдел для технических мер по ликвидации последствий, остальные заинтересованные стороны по решению CISO.
Кого не уведомлять до завершения расследования: коллег подозреваемого (риск утечки информации), линейных менеджеров других подразделений, службу поддержки (helpdesk). Helpdesk - отдельная боль. Стоит кому-то из IR-команды создать тикет "проверить активность пользователя X", и через час об этом знает пол-офиса.
Каналы: только личные встречи или звонки. Не email, не мессенджеры - инсайдер может иметь к ним доступ. Если необходим электронный обмен - использовать out-of-band communications: отдельный канал, к которому подозреваемый гарантированно не имеет доступа. По данным Sygnia (11 Incident Response Best Practices), планирование безопасных внеполосных коммуникаций - обязательный элемент IR на случай компрометации внутренних каналов.
Внешняя коммуникация: регуляторы и правоохранители
Уведомление регуляторов определяется типом скомпрометированных данных:- Персональные данные (152-ФЗ): уведомление Роскомнадзора в течение 24 часов при подтверждённой утечке, план устранения последствий - в течение 72 часов
- Банковская тайна: уведомление ЦБ РФ по установленным формам и срокам
- Объекты КИИ: уведомление НКЦКИ через систему ГосСОПКА
Чеклист: план реагирования на инцидент с инсайдером
Готовый чеклист для передачи IR-команде или включения в отчёт:Этот чеклист - отправная точка. В каждой организации он адаптируется под специфику: количество и тип SIEM, наличие UEBA, зрелость offboarding-процессов, юрисдикция.
Часть IR-команд, с которыми я сталкивался, работают по единому playbook на все типы инцидентов. Ransomware, внешний APT, инсайдер - одна последовательность: "изолировать хост, заблокировать учётку, снять образ". Для внешней атаки это работает. Но инсайдер - не техническая проблема, а проблема на стыке ИБ, HR и юриспруденции. Момент блокировки учётки определяет не IR-лид, а юрист, потому что если сотрудник подаст в суд за незаконное увольнение, а chain of custody собран с нарушениями - компания проиграет. Я видел кейсы, в которых организация теряла данные, затем проигрывала трудовой спор и выплачивала компенсацию тому же человеку, который эти данные вынес.
Через год-два UEBA-платформы, вероятно, начнут генерировать юридически значимые отчёты из коробки - с хешами артефактов, таймстемпами и форматированием под российскую судебную практику. Пока этого нет, IR-команда должна уметь оформлять доказательную базу руками. И главный навык здесь не технический, а координационный: свести четыре подразделения - ИБ, IT, HR, юристов - в условиях, где каждое из них тянет процесс в свою сторону. Цена ошибки - месяцы разбирательств и потеря доказательств. Попробуйте прогнать свой текущий offboarding-процесс по этому чеклисту. Если между "HR звонит сотруднику" и "учётка заблокирована" проходит больше нуля минут - у вас та же проблема.
Последнее редактирование модератором:
