SOT

Security Orchestration Tools

SIEM
Security Information and Event Management

Мониторинг событий ИБ

EDR
Endpoint Detection and Response

Защита конечных точек

SOAR
Security Orchestration, Automation and Response

Автоматизация реагирования на инциденты ИБ

NG SOAR
Next Generation SOAR

Автоматизация реагирования на инциденты ИБ со встроенной базовой корреляцией, сбором сырых событий непосредственно с СЗИ, динамическими плейбуками, выстраиванием цепочки атаки и объектно-ориентированным подходом

AM
Asset Management

Инвентаризация и управление ИТ-активами

VM
Vulnerability Management

Устранение уязвимостей с автопатчингом

VS
Vulnerability Scanner

Поиск технических уязвимостей на активах

SPC
Security Profile Compliance

Управление конфигурациями безопасности активов

ГосСОПКА
Государственная Система Обнаружения Предупреждения и Ликвидации Последствий Компьютерных Атак

Двустороннее взаимодействие с НКЦКИ

FinCERT
Financial Computer Emergency Response Team

Двустороннее взаимодействие с ЦБ

Напишите нам на sales@securityvision.ru или закажите демонстрацию

План реагирования на киберинциденты

План реагирования на киберинциденты

Руслан Рахметов, Security Vision


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

 

Как мы отмечали в предыдущей статье, киберинцидент – это выявленное изменение состояния элементов ИТ-инфраструктуры, свидетельствующее об успешной реализации угрозы ИБ и нарушении состояния защищенности информации. Очевидно, что киберинцидент логичнее не допустить – применение предупредительных, директивных, превентивных мер защиты не должно позволить угрозе реализоваться. Но что делать, если злоумышленники обошли защитные меры, нашли уязвимости (технические или организационные), атаковали цепочку поставок, применили методы социальной инженерии или вообще внедрили инсайдера? Признаки киберинцидента необходимо обнаружить как можно быстрее, выявить атакованные активы, проанализировать характеристики инцидента и приоритизировать меры реагирования – и затем выполнить локализацию и устранение инцидента, а также восстановить инфраструктуру и запустить остановленные бизнес-процессы. Для того, чтобы систематизировать и упорядочить действия по реагированию, следует провести подготовительную работу, начать которую рационально с анализа применимых методик, фреймворков и стандартов.

 

В России действует ряд стандартов, посвященных реагированию на киберинциденты и мониторингу кибербезопасности:

  •  ГОСТ Р 59709-2022 «Защита информации. Управление компьютерными инцидентами. Термины и определения»;

  •  ГОСТ Р 59710-2022 «Защита информации. Управление компьютерными инцидентами. Общие положения»;

  •  ГОСТ Р 59711-2022 «Защита информации. Управление компьютерными инцидентами. Организация деятельности по управлению компьютерными инцидентами»;

  •  ГОСТ Р 59712-2022 «Защита информации. Управление компьютерными инцидентами. Руководство по реагированию на компьютерные инциденты»;

  •  ГОСТ Р 59547-2021 «Защита информации. Мониторинг информационной безопасности. Общие положения»;

  •  ГОСТ Р 59548-2022 «Защита информации. Регистрация событий безопасности. Требования к регистрируемой информации».

 

Стандарты ГОСТ Р 59709-59712 предназначены для использования субъектами ГосСОПКА (т.е. субъектами КИИ, участниками информационного обмена с ГосСОПКА, Центрами ГосСОПКА и самим НКЦКИ), но могут применяться и иными организациями в качестве методических документов и лучших практик. В стандарте ГОСТ Р 59709-2022 даётся ряд определений: в частности, инцидент ИБ определён как непредвиденное или нежелательное событие (группа событий) ИБ, которое привело или может привести к нарушению функционирования информационного ресурса, возникновению угроз безопасности информации, нарушению требований по защите информации. При этом составители стандарта разделяют понятия «инцидент ИБ», «компьютерный инцидент» и «компьютерная атака»:

  •  компьютерные инциденты являются подмножеством инцидентов ИБ, для которых уже подтверждён факт вредоносного воздействия или прекращение (нарушение) функционирования защищаемых информационных ресурсов;

  •  компьютерная атака представляет собой целенаправленное вредоносное воздействие;

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

 

В стандарте ГОСТ Р 59710-2022 указано, что управление компьютерными инцидентами включает в себя четыре стадии:

     - организация деятельности по управлению компьютерными инцидентами;

     - обнаружение и регистрация компьютерных инцидентов;

     - реагирование на компьютерные инциденты (включая фиксацию материалов, связанных с возникновением компьютерных инцидентов и установление причин и условий возникновения компьютерных инцидентов);

     - анализ результатов деятельности по управлению компьютерными инцидентами.

 

Первая стадия описана в стандарте ГОСТ Р 59711-2022, а последующие три стадии – в ГОСТ Р 59712-2022.

 

Обратимся к стандарту ГОСТ Р 59711-2022, в котором говорится, что для организации процесса управления компьютерными инцидентами требуется выполнить следующие шаги:

     - разработать политику управления компьютерными инцидентами;

     - разработать план реагирования на компьютерные инциденты;

     - определить подразделение, ответственное за управление компьютерными инцидентами;

     - организовать взаимодействие с подразделениями внутри компании и с внешними организациями;

     - обеспечить ресурсами (техника, люди, бюджет) ответственное за управление инцидентами подразделение;

     - организовать обучение и информирование ответственных лиц и работников организации в части управления компьютерными инцидентам (включая проведение инструктажей на регулярной основе);

     - организовать проведение на регулярной основе тренировок по отработке мероприятий плана реагирования на компьютерные инциденты, при этом тренировки могут проводиться в форме обсуждения, командных тренингов (командно-штабных киберучений), практических занятий.

 

В стандарте ГОСТ Р 59711-2022 указано, что политика управления компьютерными инцидентами является высокоуровневым документом и должна содержать:

     - цели ведения деятельности по управлению компьютерными инцидентами;

     - информация о ресурсах, в отношении которых будет вестись деятельность по управлению компьютерными инцидентами (зона ответственности);

     - общие сведения о том, что для организации является компьютерным инцидентом (эти сведения используются для разработки правил выявления инцидентов и их подтверждения);

     - высокоуровневый обзор или визуализация процесса управления компьютерными инцидентами в части стадий «обнаружение и регистрация компьютерных инцидентов» и «реагирование на компьютерные инциденты»;

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

 

В соответствии с положениями ГОСТ Р 59711-2022, план реагирования на компьютерные инциденты должен содержать подробные пошаговые инструкции к действиям, выполняемым на стадиях «обнаружение и регистрация компьютерных инцидентов» и «реагирование на компьютерные инциденты» с учётом особенностей компании и её инфраструктуры, а также типов, приоритетов и уровней влияния инцидентов. В частности, план реагирования на компьютерные инциденты должен включать:


1. Общие сведения, необходимые для обнаружения и регистрации компьютерных инцидентов и реагирования на них:

1.1. технические характеристики и состав контролируемых информационных ресурсов компании;

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

1.3. порядок формирования состава рабочих групп реагирования на компьютерные инциденты;

1.4. перечень лиц, привлекаемых к реагированию, их функции и обязанности;

1.5. порядок доступа к данным мониторинга и к информации о ходе реагирования;

1.6. установленные сроки выполнения этапов реагирования;

1.7. порядок регистрации действий, выполняемых на стадии «реагирование на компьютерные инциденты» (т.е. протоколирование выполняемых действий при реагировании);


Опционально:

1.8. порядок принятия решения о необходимости привлечения к реагированию специалистов НКЦКИ;

1.9. порядок проведения мероприятий по реагированию на компьютерные инциденты совместно с НКЦКИ.

 

2. Порядок обнаружения и регистрации компьютерных инцидентов:

2.1. перечень и описание правил регистрации признаков возможного возникновения компьютерных инцидентов (перечень событий ИБ, данных мониторинга, условий и правил корреляции);

2.2. порядок приема сведений о признаках возможных инцидентов от работников организации;

2.3. порядок проверки фактов возникновения компьютерных инцидентов;

2.4. формы карточек компьютерных инцидентов;

2.5. перечень и формы отчетов, формируемых на стадиях «обнаружение и регистрация компьютерных инцидентов» и «реагирование на компьютерные инциденты».

 

3. Порядок реагирования на компьютерные инциденты:

3.1. порядок определения вовлеченных в компьютерный инцидент элементов информационной инфраструктуры;

3.2. порядок локализации компьютерных инцидентов;

3.3. ситуации, при которых требуется прекратить действия по реагированию на компьютерный инцидент;

3.4. порядок контроля процесса реагирования со стороны ответственных и руководителей;

3.5. порядок действий в процессе выявления и ликвидации последствий компьютерных инцидентов;

3.6. порядок закрытия компьютерных инцидентов;

3.7. порядок фиксации материалов, связанных с возникновением компьютерных инцидентов (артефактов инцидента, цифровых свидетельств, данных компьютерной криминалистики), порядок установления причин и условий возникновения компьютерных инцидентов.

 

Кроме того, в приложениях А и Б к стандарту ГОСТ Р 59711-2022 приведены принципы определения уровней влияния компьютерных инцидентов (используются показатели критериев значимости объектов КИИ в соответствии с ПП-127), порядок определения приоритета инцидентов (зависит от значимости затронутых инцидентов элементов инфраструктуры и масштаба инцидента), порядок определения очередности реагирования на инциденты (зависит от уровня влияния и приоритета инцидента).

 

Наконец, стандарт ГОСТ Р 59712-2022 определяет содержание трех стадий управления компьютерными инцидентами:

1. Обнаружение и регистрация компьютерных инцидентов:

1.1. регистрация признаков возможного возникновения компьютерных инцидентов;

1.2. подтверждение компьютерных инцидентов.

 

2. Реагирование на компьютерные инциденты:

2.1. определение вовлеченных в компьютерный инцидент элементов информационной инфраструктуры;

2.2. локализация компьютерного инцидента;

2.3. выявление последствий компьютерного инцидента;

2.4. ликвидация последствий компьютерного инцидента;

2.5. закрытие компьютерного инцидента;

2.6. фиксация материалов, связанных с возникновением компьютерного инцидента;

2.7. установление причин и условий возникновения компьютерного инцидента.

 

3. Анализ результатов деятельности по управлению компьютерными инцидентами:

3.1. приобретение и накопление опыта по результатам управления компьютерными инцидентами;

3.2. разработка рекомендаций по устранению в информационных ресурсах причин и условий возникновения компьютерных инцидентов;

3.3. оценка результатов и эффективности реагирования на компьютерные инциденты. 

Заказать демонстрацию Security Vision

Отметим также, что для владельцев значимых объектов КИИ актуальным является Приказ ФСБ России от 25 декабря 2025 г. № 547 «Об утверждении Порядка информирования ФСБ России о компьютерных атаках и компьютерных инцидентах, реагирования на них, принятия мер по ликвидации последствий компьютерных атак...». В данном документе указано, что для значимого объекта КИИ должен быть разработан план реагирования на компьютерные инциденты и принятия мер по ликвидации последствий компьютерных атак. Данный план реагирования должен включать:

     - технические характеристики и состав значимых объектов критической информационной инфраструктуры;

     - события (условия), при наступлении которых начинается реализация предусмотренных планом реагирования мероприятий;

     - мероприятия, проводимые в ходе реагирования на компьютерные инциденты и принятия мер по ликвидации последствий компьютерных атак, а также время, отводимое на их реализацию;

     - описание состава подразделений и должностных лиц субъекта критической информационной инфраструктуры, ответственных за проведение мероприятий по реагированию на компьютерные инциденты и принятию мер по ликвидации последствий компьютерных атак;


Опционально:

     - условия привлечения подразделений и должностных лиц ФСБ России к проведению мероприятий по реагированию на компьютерные инциденты и принятию мер по ликвидации последствий компьютерных атак;

     - порядок проведения владельцем значимого объекта КИИ мероприятий по реагированию и ликвидации последствий совместно с привлекаемыми подразделениями и должностными лицами ФСБ России.

 

Кроме того, в Приказе №547 указано, что владельцы значимых объектов КИИ при реагировании на инциденты и ликвидации последствий выполняют следующие действия:

     - анализ компьютерных инцидентов (включая определение очередности реагирования на них), установление их связи с компьютерными атаками;

     - проведение мероприятий в соответствии с планом реагирования;

     - определение в соответствии с планом реагирования необходимости привлечения к реагированию на компьютерные инциденты и принятию мер по ликвидации последствий компьютерных атак подразделений и должностных лиц ФСБ России и Банка России.

 

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


1) Методология PICERL от американской организации профессиональной ИБ-сертификации SANS Institute разработана на базе публикации по управлению инцидентами («Incident Handler's Handbook»). PICERL – это аббревиатура от перечисленных в документе этапов управления инцидентами: Preparation (подготовка), Identification (выявление), Containment (сдерживание), Eradication (устранение), Recovery (восстановление), Lessons Learned (выученные уроки).


2) Рекомендации по реагированию на киберинциденты приводит также американский институт NIST в специальной публикации NIST SP 800-61 Rev.3 «Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile» («Рекомендации и соображения по реагированию на инциденты в рамках управления рисками кибербезопасности»). В отличие от предыдущей версии данного документа (Rev.2), которая с 2012 года активно использовалась ИБ-специалистами, новая версии публикации ориентирована на соответствие фреймворку NIST CFS 2.0 и сфокусирована на встраивании процессов реагирования в общую корпоративную систему управления ИБ, а модель жизненного цикла реагирования состоит из фаз подготовки (связана с функциями выявления и управления киберрисками, реализацией защитных мер), реагирования на инцидент (выявление и анализ атак и компрометаций, выполнение действий по реагированию, восстановление затронутых инцидентом активов и операций), анализа выученных уроков (улучшение процессов).


3) Группа стандартов ISO/IEC 27035 посвящена управлению инцидентами информационной безопасности и включает в себя документы ISO/IEC 27035-1:2023 («Принципы и процессы»), ISO/IEC 27035-2:2023 («Руководства по планированию и подготовке к реагированию на инциденты»), ISO/IEC 27035-3:2020 («Руководства по операциям реагирования на инциденты в сфере информационных и компьютерных технологий»), ISO/IEC 27035-4:2024 («Координация»).

 

Рассмотрим подробнее стандарт ISO/IEC 27035-3:2020, который описывает следующие процессы в рамках реагирования на киберинциденты:


I. Процесс обнаружения и регистрации киберинцидентов.


1. Сбор информации о событиях ИБ и иных данных мониторинга ИБ из различных источников: данные СЗИ, ИТ-систем, а также сообщения от работников, контрагентов, поставщиков, подрядчиков, клиентов.

2. Регистрация инцидентов ИБ: вручную ответственным или автоматически в СЗИ.

3. Первичный анализ: определение достаточности информации, сбор дополнительной информации, обогащение, контекстуализация данных об инциденте.

4. Приоритизация (оценка критичности), категорирование (триаж) инцидента ИБ, заполнение карточки инцидента ИБ.

5. Отправка уведомлений сотрудникам, входящим в группу реагирования.

 

II. Процесс реагирования на компьютерные инциденты.


1. Локализация компьютерного инцидента:

Цели:

  • Предотвратить нарушение конфиденциальности, целостности, доступности информации;

  • Предотвратить дальнейшие несанкционированные действия атакующих;

  • Предотвратить горизонтальное перемещение и распространение угрозы на другие элементы ИТ-инфраструктуры.

Способы:

  • Блокирование IP-адресов, доменов, URL атакующих на сетевых СЗИ (межсетевые экраны, прокси-серверы);

  • Сетевая изоляция атакованного хоста (на сетевом оборудовании или средствами хостовых СЗИ);

  • Отключение скомпрометированных учетных записей;

  • Отключение процессов, служб;

  • Выключение устройства (может затруднить дальнейшее расследование и форензику).

 

2. Выявление последствий компьютерного инцидента:

Цели:

  • Выявить признаки негативного воздействия инцидента ИБ на инфраструктуру (например, подозрительная сетевая активность и процессы, изменение состава ПО, изменение файлов, нештатное поведение устройства);

  • Оценить уровень негативного влияния инцидента ИБ на инфраструктуру (трудозатраты, время простоя инфраструктуры, оценка вреда и финансового ущерба).

Способы:

  • Обработка данных от хостовых и сетевых СЗИ по скомпрометированному устройству;

  • Ручные экспертные действия с применением доступных источников информации.

 

3. Ликвидация последствий компьютерного инцидента:

Цели:

  • Устранение последствий компьютерного инцидента;

  • Восстановление скомпрометированных объектов в состояние «до атаки».

Способы:

  • Перенастройка ПО / ОС для соответствия политикам ИБ;

  • Восстановление данных и ПО / ОС из резервных копий;

  • Переустановка ПО / ОС из доверенного источника, установка актуальной версии и всех обновлений безопасности;

  • Подключение резервных ресурсов (каналы связи, серверное оборудование, виртуальные машины, запасные комплектующие);

  • Внесение изменений в архитектуру ИТ-инфраструктуры;

  • Миграция виртуальных машин в резервные инфраструктуры.

 

4. Закрытие компьютерного инцидента:

Выполняется после реализации всех предыдущих действий при условии достаточности принятых мер и оценки полноты реализованных мероприятий руководителем подразделения по управлению инцидентами ИБ. Если принятые меры оценены как недостаточные, то производится возврат на предыдущие этапы и повторение соответствующих действий.

 

III. Установление причин компьютерных инцидентов.


Цель:

  • Определение факторов, обусловивших или способствовавших возникновению инцидента ИБ.

Способы:
  • Анализ действий пользователей, соблюдение ими политик ИБ;

  • Анализ журналов событий безопасности ОС, ПО, СЗИ, сетевого оборудования;

  • Анализ копии сетевого трафика и информации о соединениях скомпрометированного устройства и источника атаки;

  • Анализ данных о состоянии устройства (запущенные процессы, сетевые соединения, активные сессии пользователей, состояние реестра, состояние файловой системы);

  • Анализ конфигурации ОС, ПО, СЗИ, сетевого оборудования, аппаратного обеспечения;

  • Анализ результатов оценки защищенности, наличия уязвимостей, результатов тестов на проникновение;

  • Реверс-инжиниринг подозрительных объектов, изучение их в «песочнице».

 

IV. Анализ результатов деятельности по управлению инцидентами ИБ («пост-анализ»).


Цели:

  • Приобретение и накопление опыта по результатам управления инцидентами ИБ

  • Оценка результатов и эффективности реагирования на инциденты ИБ

  • Актуализация системы управления ИБ

  • Актуализация политики управления инцидентами ИБ и плана реагирования на инциденты ИБ

Заказать демонстрацию Security Vision

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

  • политика реагирования – это высокоуровневый документ, описывающий принципы и подходы к управлению инцидентами в компании;

  • план и регламенты реагирования (или плейбуки/сценарии реагирования) разрабатываются для каждого из актуальных типов инцидентов и содержат практические шаги и инструкции при наступлении определенных типов инцидентов (например, DDoS, фишинг, вредоносная активность, несанкционированный доступ и т.д.);

  • инструкции для ответственных – детальное описание технических операций при выполнении определенных действий в рамках реагирования (например, команды для получения свойств атакованной учетной записи, описание создания блокирующего сетевого правила на межсетевом экране, описание перемещения устройства в группу сетевого карантина, сбор артефактов на атакованном устройстве и т.д.);

  • матрица эскалации – документ, описывающий условия, при которых повышается уровень ответственности при реагировании на инцидент (например, сотрудник на L1 может эскалировать инцидент на сотрудника L2, сотрудник L2 – на уровень L3, а с L3 инцидент можно эскалировать еще выше – киберкриминалисту, реверс-инженеру, в специализированные организации);

  • матрица коммуникации при инциденте – документ, описывающий, с кем и как следует взаимодействовать при инциденте (ответственный за актив/процесс, владелец актива/процесса, руководство компании, департамент ИТ, СБ, юристы, PR, GR и т.д.).

 

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


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

https://gitlab.com/syntax-ir/playbooks

https://github.com/certsocietegenerale/IRM/tree/main/EN

https://learn.microsoft.com/en-us/security/operations/incident-response-playbooks

https://github.com/Azure/Azure-Sentinel/tree/master/Playbooks

https://github.com/luduslibrum/awesome-playbooks


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


3. Следует связать процессы реагирования с другими процессами кибербезопасности – например, без качественного управления активами и уязвимостями невозможно выстроить реагирование, а без связи с процессом обеспечения непрерывности и восстановления работоспособности не получится своевременно запустить инфраструктуру после инцидента.


4. Необходимо понимать современные тактики, техники, инструменты злоумышленников – сценарии реагирования требуют непрерывной актуализации не только по результатам обработки инцидентов, но и при появлении новых методов кибератак.


5. Современные кибернападения происходят с крайне высокой скоростью – атаки производятся автоматизировано, используются целые рои ИИ-агентов, атакующие активно кооперируются друг с другом для повышения эффективности взломов. Без средств автоматизации защитники не смогут дать адекватный ответ и будут всегда на шаг позади злоумышленников. Именно поэтому мы в Security Vision разрабатываем решения для автоматизации реагирования на киберинциденты и роботизации процессов кибербезопасности, применяем ИИ для усиления экспертизы аналитиков и снижения рутинной нагрузки, используем адаптирующиеся под контекст конкретного инцидента динамические сценарии реагирования, формируем единую ресурсно-сервисную модель инфраструктуры, даём возможность максимально гибко настраивать рабочие процессы с помощью удобного конструктора Low-Code/No-Code. Для автоматизации реагирования на киберинциденты наши Заказчики могут использовать такие продукты Security Vision, как:

  • Security Vision SOAR и NG SOAR

  • Security Vision SIEM

  • Security Vision TIP

  • Security Vision UEBA

  • Security Vision CMDB

  • Security Vision VM

  • Security Vision VS

 


Управление инцидентами Стандарты, ГОСТы и документы ИБ Организационные меры в ИБ КИИ Практика ИБ

Похожие статьи

Управление активам в режиме Blackbox
Управление активам в режиме Blackbox
Red Teaming: Симуляция реальной киберугрозы
Red Teaming: Симуляция реальной киберугрозы
Анализ защищенности и пентесты
Анализ защищенности и пентесты
CMDB: что это такое и почему база управления конфигурациями является фундаментом ИБ
CMDB: что это такое и почему база управления конфигурациями является фундаментом ИБ
Как ИИ меняет кибербезопасность
Как ИИ меняет кибербезопасность
CyBOK. Глава 3. Законы и регуляторные нормы. Часть 7
CyBOK. Глава 3. Законы и регуляторные нормы. Часть 7
Конфиденциальность, целостность и доступность информации
Конфиденциальность, целостность и доступность информации
Что такое дипфейк, как его распознать и защититься
Что такое дипфейк, как его распознать и защититься
Что такое Trusted Platform Module (TPM-модуль) и как он используется для обеспечения кибербезопасности конечных точек
Что такое Trusted Platform Module (TPM-модуль) и как он используется для обеспечения кибербезопасности конечных точек
Когда база данных становится открытой книгой
Когда база данных становится открытой книгой
XSS, Межсайтовый скриптинг (Cross-Site Scripting)
XSS, Межсайтовый скриптинг (Cross-Site Scripting)

Похожие статьи

Управление активам в режиме Blackbox
Управление активам в режиме Blackbox
Red Teaming: Симуляция реальной киберугрозы
Red Teaming: Симуляция реальной киберугрозы
Анализ защищенности и пентесты
Анализ защищенности и пентесты
CMDB: что это такое и почему база управления конфигурациями является фундаментом ИБ
CMDB: что это такое и почему база управления конфигурациями является фундаментом ИБ
Как ИИ меняет кибербезопасность
Как ИИ меняет кибербезопасность
CyBOK. Глава 3. Законы и регуляторные нормы. Часть 7
CyBOK. Глава 3. Законы и регуляторные нормы. Часть 7
Конфиденциальность, целостность и доступность информации
Конфиденциальность, целостность и доступность информации
Что такое дипфейк, как его распознать и защититься
Что такое дипфейк, как его распознать и защититься
Что такое Trusted Platform Module (TPM-модуль) и как он используется для обеспечения кибербезопасности конечных точек
Что такое Trusted Platform Module (TPM-модуль) и как он используется для обеспечения кибербезопасности конечных точек
Когда база данных становится открытой книгой
Когда база данных становится открытой книгой
XSS, Межсайтовый скриптинг (Cross-Site Scripting)
XSS, Межсайтовый скриптинг (Cross-Site Scripting)