Где проверить входы SSH на Linux-сервере?

Проверяйте текущие и прошлые сеансы через who, w и last, а также журналы аутентификации. В зависимости от дистрибутива записи могут быть в journald, /var/log/auth.log или /var/log/secure. Сопоставляйте успешные входы, адреса источников и последующие привилегированные действия; необычный вход сам по себе ещё не доказывает компрометацию.

Нужно ли сразу удалять майнер с сервера?

Нет, если майнер не создаёт немедленный ущерб. До удаления зафиксируйте процессы, сетевые соединения, сеансы, механизмы автозапуска, журналы и сведения о файлах. Удаление процесса или файла не доказывает, что атакующий потерял доступ: на сервере могут остаться другой способ закрепления, учётная запись или исходный вектор проникновения.

Как распознать ransomware на сервере?

Признаками ransomware могут быть массовая смена расширений файлов, недоступность данных и появление записок с требованием выкупа. Если шифрование продолжается, приоритетом становится остановка ущерба: по утверждённому плану полностью отключите сетевые связи или ограничьте их через инфраструктурную точку управления. Зафиксируйте время, принятое решение и наблюдаемый эффект.

Можно ли оставить SSH или RDP при изоляции сервера?

Нет, если это обычный административный доступ, который потенциально доступен и атакующему. Оставлять можно только заранее подготовленный, отдельно контролируемый канал управления или расследования, например через bastion host либо внеполосный доступ. Если такой канал гарантировать нельзя, а ущерб продолжается, сервер следует полностью отключить от сети по плану реагирования.

Является ли обычная резервная копия доказательством взлома?

Нет. Обычная резервная копия не считается криминалистической копией и не заменяет сохранение артефактов расследования. Для проверки инцидента отдельно фиксируют внешние события, процессы, сетевые соединения, сеансы, конфигурации служб и журналы, указывая время, исполнителя, применённые команды и место хранения результатов.

Доказывает ли одна тревога EDR, что сервер взломан?

Нет. Одиночный индикатор, тревога защитного средства, необычный процесс или ошибка входа могут оказаться легитимным действием администратора, ошибкой конфигурации либо ложным срабатыванием. Такой сигнал требует триажа: сохраните контекст и сопоставьте его с журналами входов, сетевой активностью, учётными записями, процессами и внешними событиями.

Сервер взломали: изоляция, артефакты и первые действия

Если инцидент происходит сейчас, не удаляйте найденный файл, не перезагружайте и не выключайте сервер автоматически. Ограничьте его связи по утверждённому плану, сохранив только заранее доверенный и отдельно контролируемый канал управления или расследования, если это не мешает остановить непосредственный ущерб; зафиксируйте время, симптомы и передайте событие ответственным. При активном шифровании, эксфильтрации данных или ином немедленном ущербе приоритетом может стать полное отключение сетевых связей.

Последовательность не универсальна

Эти действия не гарантируют сохранение всех доказательств и не останавливают любую атаку. Решение зависит от критичности сервиса, угрозы людям и данным, требований регулятора, договора с провайдером, доступного аварийного канала и наличия команды расследования. Событие следует зарегистрировать как инцидент информационной безопасности, если есть обоснованное подозрение на нарушение конфиденциальности, целостности или доступности.

Что считать потенциальным инцидентом

Высокая загрузка CPU, неизвестный процесс, новая учётная запись, тревога EDR, необычный исходящий трафик, web shell, признаки криптомайнера или ransomware — это повод для триажа инцидента, а не самостоятельное доказательство причины и масштаба атаки. Аналогично, один IOC может оказаться легитимным административным действием, ошибкой конфигурации или ложным срабатыванием.

Немедленный приоритет: файлы массово меняют расширения или становятся недоступны, появляются записки с выкупом, идёт передача данных наружу, атакующий выполняет команды, создаёт учётные записи или меняет права.
Высокий приоритет: неизвестный процесс с устойчивой нагрузкой CPU или сетью, несанкционированная задача автозапуска, вход привилегированной учётной записью с необычного адреса, обнаружение web shell в каталоге приложения.
Требует проверки: единичная тревога защитного средства, необычная служба, ошибка входа, неожиданное обновление пакета или файла. Не удаляйте объект до фиксации контекста.

Приоритеты первых часов

Цель	Что сделать	Что не считать результатом
Сдержать	Ограничить связи сервера и возможное боковое перемещение.	Остановка одного процесса не доказывает, что доступ атакующего прекращён.
Сохранить	Параллельно собирать внешние события и доступные данные хоста; при работе одного специалиста учитывать волатильность, сроки хранения и риск дальнейшего ущерба. Записывать время и исполнителя.	Обычная резервная копия не является криминалистической копией.
Проверить	Установить вероятный вектор атаки, закрепление, учётные записи и затронутые системы.	Удаление web shell или майнера не устраняет причину проникновения.
Отозвать	Инвентаризировать и поэтапно заменить доступные хосту секреты.	Смена одного пароля не закрывает токены, ключи и сертификаты.
Восстановить	Развернуть сервис из доверенного состояния после исправления вектора атаки.	Восстановление поверх подозрительной ОС не возвращает доверие к ней.

Первые действия: сдержать ущерб и не уничтожить следы

Порядок реакции в первые часы

Назначьте ответственного за технические действия и отдельного человека для журнала решений. Если есть команда реагирования или договорной порядок эскалации, используйте его.

1
Зафиксируйте исходное наблюдение
Запишите время с часовым поясом, имя и роль сервера, кто обнаружил событие, симптомы, затронутые сервисы, пользовательские жалобы, уже известные IP-адреса, имена файлов, хеши и идентификаторы тревог. Сохраните скриншот или экспорт карточки тревоги из внешней системы, если это предусмотрено её политикой. Не задерживайте сдерживание ради вычисления дополнительных хешей или подробного локального сбора. Ожидаемый результат — первичная запись, по которой другой специалист сможет восстановить начало хронологии.
2
Оцените непосредственный ущерб
Проверьте, продолжается ли шифрование, удаление данных, активная передача наружу, распространение на сетевые ресурсы или выполнение команд атакующим. При подтверждённом немедленном ущербе сдерживание важнее полноты сбора: отключите все сетевые связи по плану реагирования или через инфраструктурную точку управления. Не тратьте время на локальный сбор, если он позволяет ущербу продолжаться.
3
Изолируйте сервер
Ограничьте доступ к серверу извне и из других сегментов, включая административные и прикладные соединения, кроме заранее подготовленного и отдельно контролируемого маршрута расследования. Внеполосный доступ через гипервизор или BMC может не зависеть от гостевой ОС. Отдельная сеть управления или bastion host контролируют маршрут и круг допущенных сотрудников, но не делают скомпрометированную ОС доверенной: команды и результаты работы внутри неё всё равно фиксируйте как изменяющие состояние. Из независимой точки проверьте, что обычные клиентские и межсерверные подключения прекращены.
4
Организуйте параллельный сбор
По возможности один специалист фиксирует волатильное состояние хоста, а другой экспортирует события из SIEM, EDR, системы идентификации, межсетевого экрана, балансировщика, VPN, DNS, почтового шлюза, гипервизора, облачной панели и журналов провайдера. Для внешних выгрузок запишите диапазон времени, фильтры, автора и место хранения. Если сбор выполняет один человек, определите очерёдность по скорости исчезновения данных, срокам хранения и риску дальнейшего ущерба; не откладывайте фиксацию процессов, соединений и сеансов ради полной выгрузки всех внешних источников.
5
Соберите доступный контекст на хосте
До удаления файлов и остановки процессов зафиксируйте процессы, сетевые соединения, активные сеансы, учётные записи, службы, задания автозапуска и доступные журналы. Сам сбор на хосте меняет его состояние: в журнале действий укажите команды или средство, точное время, учётную запись исполнителя и место сохранения результата.
6
Эскалируйте и сохраните решения
Передайте ответственным краткую сводку: что произошло, когда началось, какие системы затронуты, какая изоляция введена, что продолжает работать, какие артефакты сохранены и какие решения нужны. Если сервер обслуживается провайдером, действуйте также по его процедуре реагирования и сохранения данных.

Как изолировать сервер без потери управления

Способ изоляции зависит от ОС, firewall-стека, виртуальной или физической инфраструктуры, топологии VLAN, средств удалённого управления и корпоративной политики. Это может быть правило на сетевом экране или коммутаторе, отключение виртуального сетевого адаптера, изоляция средствами защитной платформы либо физическое отключение линии. Не существует безопасной универсальной команды «отключить сеть»: она может оборвать расследование, изменить следы или не затронуть другие интерфейсы. Постоянные правила и аварийный доступ проектируют заранее: Firewall сервера: default deny, порядок правил и политика доступа, Сегментация серверной сети: VPN, bastion host и защищённый административный доступ, Защита BMC: безопасная настройка iDRAC, iLO и отдельной сети управления.

Если доверенного канала нет

Не оставляйте обычный SSH, RDP, веб-интерфейс или BMC доступным только потому, что он нужен администратору: он может быть доступен и атакующему. Если нельзя гарантировать отдельный контролируемый канал, а риск активного ущерба высок, полностью отключите сетевые связи по плану реагирования. Отключение питания допустимо как крайняя мера для защиты людей, данных или инфраструктуры, но оно обычно уничтожает данные из памяти и часть текущего сетевого контекста.

Чего не делать без решения ответственного за расследование

Не удалять майнер, web shell, подозрительную учётную запись, задачу, службу или файл.
Не останавливать подозрительный процесс и не помещать объект в карантин, если непосредственный ущерб не требует этого немедленно.
Не перезагружать, не выключать и не обновлять сервер без оценки последствий.
Не запускать сканеры, обновления, средства очистки, дефрагментацию, ротацию журналов и очистку временных каталогов.
Не восстанавливать резервную копию поверх исходной системы и не подключать подозрительные диски к рабочей среде.
Не менять пароли хаотично: несогласованный отзыв может остановить приложения, а пропущенный секрет оставит атакующему путь возврата.
Не публиковать индикаторы и детали инцидента в незащищённых чатах, тикетах с широким доступом или общих таблицах.

Исключение — действия, необходимые для остановки шифрования, утечки, распространения на другие системы либо угрозы безопасности людей. Даже тогда фиксируйте: кто принял решение, что именно было сделано, почему, в какое время и какой эффект наблюдался.

Какие артефакты сохранить в первую очередь

Как можно раньше запросите данные у внешних систем параллельно с фиксацией волатильного состояния хоста: внешние записи часто уже находятся вне контроля подозрительного сервера. Если сбор выполняет один человек, определяйте очерёдность по скорости исчезновения данных, срокам хранения и риску продолжающегося ущерба. Проверьте права на изменение, синхронизацию времени и возможность получить исходную запись, а не только сводку. Централизованное журналирование полезно именно потому, что позволяет сопоставить события нескольких систем, но не делает записи автоматически неизменяемыми.

Источники для первичного сбора

Источник	Что сохранить	Что это помогает проверить
SIEM, EDR, антивирус, IDS/IPS	Исходные события, временной диапазон, затронутый хост, процесс, пользователь, сеть, статус реакции.	Первую тревогу, цепочку процессов, известные индикаторы и соседние хосты.
Firewall, VPN, DNS, балансировщик, proxy	Разрешённые и заблокированные соединения, запросы, NAT, DNS-ответы, учётные записи VPN.	Внешний доступ, командные серверы, эксфильтрацию, связи с другими сегментами.
Система идентификации	Успешные и неудачные входы, MFA-события, изменения групп и учётных записей.	Использование украденных реквизитов и повышение доступа.
Гипервизор, облако, BMC	Консольные действия, снимки, изменения сети, питания, образов и ролей.	Действия вне гостевой ОС и возможность более безопасного сбора.
Сам сервер	Процессы, соединения, сеансы, конфигурация служб, задания, журналы, сведения об объектах.	Текущую активность и механизмы закрепления.

Ориентиры для Linux

В типичной Linux-системе сведения о процессах и соединениях дают ps, ss и systemd; о текущих и прошлых сеансах — who, w, last; о службах и таймерах — systemd. Журналы аутентификации часто находятся в journald и, в зависимости от семейства дистрибутива и настройки, в файлах вроде /var/log/auth.log или /var/log/secure. Журнал аутентификации, systemd journal и Linux Audit дополняют друг друга.

Сохраните список процессов с полными доступными аргументами в файл на подготовленном носителе или по разрешённому каналу. Ожидаемый результат — снимок PID, родительского процесса, пользователя и командной строки; необычные процессы затем сопоставляют с сетевыми соединениями и механизмами запуска.

ps -efww

Покажите доступные TCP/UDP-сокеты, включая слушающие и установленные соединения, а также связанные процессы, если прав достаточно. Неожиданный слушающий порт или исходящее соединение — повод сохранить вывод и сопоставить PID с процессом, а не немедленно завершать его.

ss -tupna

Зафиксируйте состояние служб. Для подозрительной службы дополнительно сохраняют её unit-файл, параметры запуска, время изменения и связанные журналы; не отключайте службу до решения о сдерживании.

systemctl list-units --type=service --all

Пример выгрузки systemd journal за заданный период. Подставьте фактическую дату и сохраняйте часовой пояс в журнале действий. Если журнал непостоянный или уже ротирован, запросите копии из централизованного хранилища.

journalctl --since '2026-10-10 00:00:00' --no-pager

Также проверьте задания cron и systemd timers, конфигурации служб, каталоги автозапуска, изменения в веб-каталогах, authorized_keys, sudo-правила и локальных пользователей. Пути, названия пакетов, доступность journalctl, auditd и формат журналов зависят от дистрибутива, версии и конфигурации. Для используемого выпуска сверяйтесь с Debian Reference, документацией Ubuntu Server по журналированию и руководством RHEL по аудиту системы. Подробный разбор входов, включая журнал входов SSH Linux, — в статье Аудит безопасности Linux: auditd, входы и контроль действий.

Ориентиры для Windows Server

Журнал безопасности Windows содержит события, создаваемые включёнными политиками аудита входов, доступа и изменений. В расследовании также важны журналы Microsoft Defender, PowerShell, System, Application, Task Scheduler, служб и, если они были заранее настроены, Sysmon или пересылка событий. Назначение аудита и зависимость записей от политики описаны в документации Microsoft по аудиту входов и аудиту создания процессов. Отдельно документированы события Microsoft Defender Antivirus и журналирование PowerShell в Windows. Доступность и состав конкретных событий зависят от выпуска Windows Server, заранее включённой политики аудита и конфигурации журналирования.

События успешного и неудачного входа анализируйте вместе с типом входа, учётной записью, источником, статусом и временем; один идентификатор события не доказывает атаку.
Событие создания процесса может быть полезно, но без заранее включённого аудита командной строки часто недостаточно для понимания действия.
Журналы PowerShell дают разную детализацию в зависимости от включённых Script Block Logging, Module Logging и Transcription; они могут содержать чувствительные аргументы.
События Microsoft Defender помогают установить обнаружение и реакцию средства, но не заменяют журналы ОС, сети и идентификации.

В PowerShell получите последние доступные записи Security Event Log и сохраните экспорт по принятой процедуре. Если доступ запрещён, не меняйте аудит ради сбора: зафиксируйте ограничение и запросите события у администратора или из центрального хранилища.

Get-WinEvent -LogName Security -MaxEvents 100

Зафиксируйте текущие TCP-соединения. Сопоставьте `OwningProcess` с процессом через штатные средства Windows и сохраните результаты; отсутствие соединения в момент проверки не исключает предыдущую сетевую активность.

Get-NetTCPConnection

Полный порядок экспорта Event Log, проверки эффективной политики аудита и интерпретации событий — в Аудит Windows Server: Security Event Log, Advanced Audit Policy и PowerShell logging. Названия каналов, пунктов интерфейса, параметры команд и состав записей могут отличаться между версиями Windows Server и корпоративными политиками; сверяйтесь с официальной документацией Microsoft для используемого выпуска.

Первичная проверка входа, закрепления и бокового перемещения

Постройте проверяемые гипотезы

1
Определите вероятную точку входа
Сопоставьте начало аномалии с публикацией веб-приложения, RDP, SSH, VPN, почтой, агентом управления, обновлением, учётной записью и известными уязвимостями. Проверьте логи reverse proxy и веб-сервера на необычные запросы, загрузку файлов и запуск обработчиков; для SSH — успешные входы, источники и последующие привилегированные действия; для Windows — входы и удалённые сессии. Результат — список гипотез с подтверждающими и опровергающими событиями.
2
Проверьте закрепление
На Linux проверьте systemd services и timers, cron, пользовательские автозапуски, конфигурации веб-сервера, ключи SSH и изменения sudo. На Windows проверьте службы, Scheduled Tasks, автозагрузку, WMI-подписки, изменения реестра и учётные записи. Сохраняйте конфигурации и метаданные до отключения объекта.
3
Проверьте учётные записи и привилегии
Сравните локальных и доменных пользователей, группы администраторов, сервисные учётные записи и недавние изменения с утверждённым инвентарём. Отдельно оцените привилегированные учётные записи: их использование с подозрительного хоста повышает приоритет проверки остальных систем.
4
Ищите признаки перемещения
По внешним журналам проверьте подключения сервера к другим хостам, обращения к общим ресурсам, удалённое выполнение, необычные DNS-запросы, аутентификацию одной учётной записи на нескольких системах и изменения в системах управления. Расширяйте изоляцию и сбор на другие активы только по подтверждённым связям или обоснованному риску.

Удаление находки не означает устранение компрометации

Если атакующий получил административные или иные высокие привилегии, сервер нельзя автоматически считать доверенным после удаления одного вредоносного файла. Майнер может быть только заметным последствием доступа, web shell — одним из нескольких входов, а ransomware — финальной стадией атаки. Нужно установить вероятный вектор, проверить закрепление, оценить доступ к другим системам и решить, возможно ли вернуть доверие к ОС.

Какие секреты считать раскрытыми и как их отзывать

Считайте потенциально раскрытым любой секрет, который был доступен процессу, пользователю или файловой системе скомпрометированного сервера: пароли, SSH-ключи, API-токены, облачные реквизиты, ключи сервисных учётных записей, закрытые ключи TLS и клиентской аутентификации, ключи резервных копий, значения в конфигурациях, переменных окружения, CI/CD и секретных хранилищах. Если мог быть раскрыт закрытый ключ, соответствующий сертификат может потребовать отзыва и перевыпуска. Если хост мог читать секрет, нельзя исходить из того, что атакующий его не получил.

Составьте инвентарь: секрет, владелец, где хранится, какие сервисы используют, какие права даёт, когда применялся последний раз и как отзывается.
Расставьте приоритеты по радиусу поражения и признакам использования: первыми обрабатывайте облачные и доменные административные реквизиты, VPN, секреты хранилищ, ключи автоматизации и доступа к другим серверам.
Если секрет уже используется атакующим или даёт возможность продолжить непосредственный ущерб, немедленно отзовите либо ограничьте его по решению ответственного, учитывая возможную остановку зависимых сервисов.
Если немедленный отзыв не требуется, выпустите новое значение, переведите на него прикладные сервисы, базы данных, очереди, интеграции, резервное копирование и мониторинг, подтвердите их работу и затем отзовите старый секрет.
Удалите неуправляемые копии и проверьте журналы использования. Если секрет временно нельзя отозвать, ограничьте его права и допустимые источники, назначьте владельца и срок окончательного отзыва.

Ротация ключей при инциденте требует координации: немедленный отзыв может остановить приложение, но активный старый ключ даёт атакующему возможность вернуться. Управляемый процесс инвентаризации и замены описан в статье Управление секретами сервера: хранение, выдача, ротация и отзыв доступов.

Когда восстанавливать сервер из доверенного состояния

Если подтверждена или обоснованно подозревается компрометация с привилегиями, безопаснее считать исходную ОС недоверенной. Возврат сервиса строят на доверенном образе, проверенной резервной копии данных или контролируемой переустановке — после устранения вектора атаки и замены затронутых секретов. Способ зависит от критичности сервиса и плана DR; восстановление резервной копии — операционная процедура, а не способ криминалистического сохранения доказательств.

До запуска восстановленного сервиса подтвердите, что закрыта или ограничена исходная точка входа: уязвимый компонент исправлен, лишний доступ отключён, конфигурация пересмотрена.
Разверните сервис в изолированной или контролируемой среде, если это допускает план восстановления, и проверьте необходимые функции, журналы и сетевые ограничения.
Подключайте зависимости и внешний доступ поэтапно, наблюдая за входами, исходящими соединениями и ошибками.
После возврата к работе усилите контроль и разберите причины; постоянный hardening выполняйте отдельным изменением: Hardening Linux-сервера: чек-лист для Ubuntu, Debian и RHEL или Hardening Windows Server 2019, 2022 и 2025: базовая защита.

Передача инцидента: минимальный чек-лист

Идентификатор инцидента, время обнаружения и часовой пояс; кто обнаружил и кто ведёт реакцию.
Имя, роль, владелец, ОС, адреса и критичность затронутого сервера.
Наблюдаемые симптомы: процесс, файл, web shell, шифрование, тревога, IP-адреса, учётные записи, затронутые данные.
Статус сдерживания: какие связи прекращены, какой доверенный канал сохранён либо почему выполнено полное отключение.
Список сохранённых артефактов, источников, диапазонов времени, контрольных сумм при наличии и мест хранения.
Все действия на хосте с временем, исполнителем и причиной; это часть цепочки хранения доказательств.
Гипотезы о векторе атаки, закреплении, затронутых учётных записях, секретах и связанных системах.
Решения, которые ещё требуются: отзыв секретов, уведомление владельцев данных, восстановление, обращение к провайдеру или юридическая оценка.

Образы диска и дампы памяти

Сбор образа диска или дампа памяти относится к компьютерной криминалистике и должен выполняться подходящим для среды средством и специалистом. Для доказательной ценности нужны метаданные времени, сведения о носителе и средстве, контрольные суммы, ограничение доступа и документированная цепочка хранения. Требования и поддерживаемые параметры зависят от выбранного средства, ОС и версии; сверяйтесь с его официальным руководством и корпоративной процедурой. Не подменяйте такой сбор обычным бэкапом.

Термины в статье

IOC: IOC — наблюдаемый технический признак возможной или подтверждённой компрометации: хеш файла, IP-адрес, домен, путь, ключ реестра или иной артефакт.
Ransomware: Ransomware — вредоносная программа, которая блокирует доступ к данным или системам и требует выкуп; обычно применяет шифрование, но не сводится к нему.
Web shell: Web shell — серверный веб-скрипт или приложение, принимающее команды через HTTP(S) и выполняющее их с правами процесса, обрабатывающего запрос.
Боковое перемещение: Боковое перемещение — этап атаки, при котором нарушитель использует уже полученный доступ для проникновения на другие системы и расширения контроля внутри инфраструктуры.
Вектор атаки: Вектор атаки — путь или способ, которым атакующий получает первоначальный доступ, доставляет вредоносный код либо воздействует на целевую систему.
Журнал аудита: Журнал аудита — защищаемая совокупность записей о значимых действиях и изменениях с указанием времени, субъекта, объекта, результата и контекста для расследования и контроля.
Журнал аутентификации: Журнал аутентификации — набор записей о попытках подтверждения личности, их результатах и данных, необходимых для расследования и контроля доступа.
Журнал безопасности Windows: Журнал безопасности Windows — системный журнал событий, фиксирующий результаты аудита входов, доступа к объектам, изменений политик и привилегий в Windows.
Инцидент информационной безопасности: Инцидент информационной безопасности — выявленное или обоснованно подозреваемое событие, нарушающее политику защиты либо создающее угрозу конфиденциальности, целостности или доступности.
Карантин: Карантин — режим изоляции подозрительного или вредоносного объекта защитным средством, при котором его обычный запуск и доступ к нему ограничиваются.
Компрометация: Компрометация — нарушение защищённости актива, при котором произошли несанкционированный доступ или воздействие на его конфиденциальность, целостность либо доступность.
Компьютерная криминалистика: Компьютерная криминалистика — дисциплина сбора, сохранения, исследования и документирования цифровых доказательств с обеспечением их целостности и проверяемости.
Криптомайнер: Криптомайнер — программа, выполняющая вычисления для добычи криптовалюты; её использование без разрешения владельца вычислительных ресурсов является криптоджекингом.
Механизм закрепления: Механизм закрепления — конфигурация, код или системный объект, позволяющий сохранять присутствие либо повторно получать доступ после выхода из сеанса, остановки процесса или перезагрузки.
Привилегированная учётная запись: Привилегированная учётная запись — учётная запись с правами управления системами, данными или политиками доступа, превышающими полномочия обычного пользователя.
Ротация ключей: Ротация ключей — управляемая замена криптографических ключей по сроку, событию или политике с переводом систем на новые ключи и выводом прежних из активного применения.
Сдерживание инцидента: Сдерживание инцидента — этап реагирования, ограничивающий распространение атаки и доступ нарушителя до устранения причины, с сохранением данных для расследования.
Триаж инцидента: Триаж инцидента — первичная оценка события безопасности для подтверждения инцидента, определения его приоритета, масштаба, потенциального ущерба и необходимых действий реагирования.
Централизованное журналирование: Централизованное журналирование — сбор и хранение журналов разных систем в общем сервисе для унифицированного поиска, контроля целостности и анализа.
Цепочка хранения доказательств: Цепочка хранения доказательств — документированная история получения, передачи, хранения и анализа цифровых доказательств, позволяющая проследить их происхождение и оценить целостность.