Контакты
Подписка 2022
МЕНЮ
Контакты
Подписка

Автоматическое реагирование на инциденты. Круглый стол

Редакция журнала "Информационная безопасность", 09/12/21

С ростом ИТ- и ИБ-инфраструктуры предприятия естественным образом возникает потребность в мониторинге ее защищенности, управлении инцидентами с помощью специализированных систем класса IRP/SOAR, а также развертывании на их базе полноценного SOC. Как понять, что настал момент для системного управления инцидентами? Как сократить расходы на комплексный мониторинг ИБ? Как проактивно защитить всю организацию и снизить вероятности ошибок первого и второго рода? Об этом в рамках круглого стола рассказали эксперты журнала “Информационная безопасность".

Эксперты:
Валерий Горбачев, руководитель направления внедрения средств защиты информации, “ДиалогНаука”
Алексей Горелкин, генеральный директор Phishman
Александр Ковалев, заместитель генерального директора Zecurion
Александр Носарев, руководитель отдела систем мониторинга и реагирования ГК Angara
Илья Петров, директор департамента продвижения собственных продуктов по безопасности ГК Innostage
Дмитрий Поливанов, старший специалист отдела технических решений, “ДиалогНаука”
Руслан Рахметов, CEO Security Vision
Михаил Савин, директор по продукту Eplat4m Orchestra, ООО “КИТ.Р”
Всеслав Соленик, директор Центра экспертизы R-Vision

Когда пора внедрять IRP/SOAR? Каковы минимальные требования для начала внедрения?

Михаил Савин, КИТ.Р:
В упрощенном виде IRP есть в любой организации, например в виде ITSM и Service Desk. А предпосылками внедрения специализированной платформы является необходимость автоматизации ручного труда (обогащения, быстрая реакция), появление команды аналитиков и наличие SLA.

Алексей Горелкин, Phishman:
IRP/SOAR пора внедрять, как только появляются процессы обработки киберинцидентов. Но многое зависит от специфики бизнеса. Одной организации с 50 сотрудниками может быть крайне необходима автоматизированная работа с инцидентами, а другой компании с 5 тыс. сотрудников вполне хватает и ручной обработки. Поэтому, хотя вопрос и кажется простым, ответ зависит от конкретной ситуации.

Руслан Рахметов, Security Vision:
Минимальным требованием начала внедрения IRP/SOAR является только уровень зрелости ИТи ИБ-подразделений. При классическом подходе предпосылками для использования IRP/SOAR являются желание автоматизировать рутинные операции в сценарии, нехватка персонала, потребность в скорости реагирования на инциденты. В последнее время стал популярным подход Security by Design, когда IRP/SOAR включается уже на этапе проектирования.

Дмитрий Поливанов, ДиалогНаука:
Наступает момент, когда ИБ-специалисты начинают захлебываться в ручном разборе потока событий и реагировании, возрастает вероятность ошибок. В этой ситуации на помощь и должны прийти решения IRP/SOAR. Для применения решений данного класса заказчик должен иметь подразделение, отвечающее за развитие, реализацию и поддержание процессов и систем ИБ как на бумаге, так и в инфраструктуре, а также базовый набор средств защиты информации.
Желательно также наличие SIEM, которая возьмет на себя обработку и подготовку событий, направляемых в IRP/SOAR.

Александр Носарев, Angara:
Основываясь только на экономической эффективности, можно выделить шесть критериев:
1. Определены перечень анализируемых источников, событий, механизмы и возможность сбора.
2. Инфраструктура приведена в соответствие с действующими политиками и регламентами.
3. Определены критичные инциденты, и для них созданы ранбуки, исполняемые вручную.
4. Внедрена SIEM.
5. Создано подразделение, осуществляющее мониторинг в режиме 24 х 7.
6. Есть необходимость автоматизации действий или журналирования расследования.

Илья Петров, Innostage:
IRP-/SOAR-систему рекомендуется внедрять в крупных компаниях с определенным уровнем зрелости. Для этого должен быть реализован базовый набор средств защиты информации, внедрена SIEM-система и укомплектован штат специалистов, которые будут выстраивать процесс работы с инцидентами на базе IRP/SOAR.

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

Александр Ковалев, Zecurion:
Известны кейсы, когда системы IRP внедрялись на энтузиазме для единственного активного специалиста по ИБ, но больше для упорядочивания своих процессов. Действительно полезным инструментом IRP становится уже для двух-трех занимающихся расследованиями специалистов. С SOAR ситуация интереснее: требуется определенная зрелость компании, заметное количество защищаемых систем и задач для замены их плейбуками с автоматическим реагированием. Обычно к этому приходят с уже большим штатом и ресурсами для поддержки плейбуков.

Как можно снизить затраты на интеграцию IRP/SOAR в уже развернутую масштабную мультиспецифическую ИТи ИБ-инфраструктуру?

Дмитрий Поливанов, ДиалогНаука:
Во-первых, снизить затраты можно благодаря разумной минимизации количества систем, с которыми будет интегрироваться IRP/SOAR. Понять, что будет полезно автоматизировать, поможет графический или текстовый план действий, выполняемый сотрудниками при наступлении различного рода инцидентов до внедрения IRP/SOAR. Второй фактор экономии – наличие у ИБ-специалистов базовых навыков программирования, что снизит зависимость от платных сервисов интеграции, оказываемых сторонними организациями. Многие вендоры предоставляют готовые интеграции, но и их зачастую необходимо приспосабливать под свои цели.

Руслан Рахметов, Security Vision:
Система IRP/SOAR работает практически со всеми ИТи ИБ-системами компании. Интеграции IRP/SOAR с другими системами образуют транспортную сеть ИБ компании, на которую далее наслаиваются ИТи ИБ-сервисы, от рутинных сценариев до работы с BigData. От качества транспортной сети зависит дальнейшее качество работы ИБ в целом. Промышленные IRP/SOAR имеют коннекторы ко всем системам, а к новым системам позволяют подключаться с помощью универсальных коннекторов, тем самым снижая затраты на интеграцию.

Александр Носарев, Angara:
1. Система IRP/SOAR должна соответствовать имеющейся инфраструктуре (готовые интеграции) и процессам (возможности плейбуков), важно смотреть на это в некоторой временной перспективе. Например, локальные производители обычно поддерживают продукты других локальных производителей.
2. Должна быть простота разработки пользовательского контента, а интеграция с редкими или самописными системами не должна становиться проблемой.
3. Важна экосистема, и производители обычно предлагают дополнить решение модулем SGRC, модулем взаимодействия с ГосСОПКА и т.д.

Илья Петров, Innostage:
Для снижения затрат на внедрение IRP/SOAR необходимо детально проработать архитектуру внедряемой системы, которая в первую очередь должна учитывать организационную структуру компании, ландшафт и особенности ее ИТ-инфраструктуры. Сама IRP-/SOAR-система должна обладать вариативностью внедрения, гибкой настройкой функционала и набором коннекторов – готовых инструментов для интеграции с внешними системами.

Всеслав Соленик, R-Vision:
Нужно выбрать подходящий продукт уровня Enterprise с большим количеством готовых интеграций, а также партнера или вендора с опытом проектов в аналогичных компаниях. Окончательный выбор возможен только по итогам пилотирования решений в вашей инфраструктуре. Проектировать процессы и архитектуру следует с учетом выбранных продуктов, а внедрять – в несколько этапов. Дополнительный функционал IRP можно тестировать на пробных лицензиях и закупать, только если он оказался действительно полезен.

Александр Ковалев, Zecurion:
Самый простой способ – проводить постепенное внедрение, правильно сформировать техзадание, отказаться от объективно лишних требований, где это возможно. И стоит помнить, что поддержка любых интеграций в дальнейшем требует их содержания и на масштабных инфраструктурах это стоит дороже условных DLP или NGFW.

Михаил Савин, КИТ.Р:
Самая сложная часть внедрения – заставить купленную "коробку" работать. Это зависит от того, можете ли вы описать сценарии автоматизации на бумаге с тем, чтобы переложить их на язык плейбуков. В большой организации можно запустить систему только в одном подразделении, а если требуются сквозные процессы и интеграции, то важным аспектом станут возможности адаптации. Так как процессы реагирования на инциденты ИБ меняются и совершенствуются, важна возможность адаптации системы без участия вендора.

Что необходимо для совершенствования сценариев анализа инцидентов в решениях класса IRP/SOAR?

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

Всеслав Соленик, R-Vision:
Для начала нужно хорошо проработать процесс реагирования на инциденты: источники данных, рубрикатор, карточки и поля, сценарии, рабочие группы, интеграции, метрики и пр. Полезно использовать лучшие практики – ISO, NIST, MITRE и др. Далее важно начать пользоваться системой и несколькими сценариями в боевом режиме. Постепенно найдутся точки совершенствования сценариев, и можно будет развивать их покрытие, глубину обогащения и автоматизации, удобство, гибкость и отказоустойчивость.

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

Михаил Савин, КИТ.Р:
Нужна система поддержки принятия решений – экспертная система, предоставляющая аналитикам знания о том, что они могут сделать на очередном шаге проведения расследования. Например, к каким внешним источникам данных обратиться, проследить связи определенного события с другими сущностями, проверить гипотезу о применении конкретной техники атаки. Результат работы такой системы – готовый плейбук, автоматизированно разработанный аналитиком для решения конкретной задачи обнаружения и реагирования.

Александр Носарев, Angara:
Есть три основные составляющие:
1. Совершенствование самих процессов. Если при расследовании нужен внешний ресурс (система, специалист), которого сейчас нет или к которому нет полномочий обратиться, – это проблема.
2. Автоматизация. Не всегда ограничения носят технический характер, иногда бизнес не готов на действия без ручного подтверждения. Нужно договариваться и искать обходные пути.
3. Измерение эффективности процесса. Многие решения для этого имеют встроенные средства.

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

Александр Ковалев, Zecurion:
При наличии ресурсов желательно изначально проводить правильное внедрение, чтобы потом меньше тестировать SOAR в боевых условиях. Для совершенствования процесса необходимо накопить достаточный опыт и компетенции для анализа и оптимизации срабатывания сценариев, и это должно стать постоянным процессом.

Руслан Рахметов, Security Vision:
Для начала необходимо в IRP/SOAR формализовать сценарии as-is и начать с ними работать. Команда сразу увидит, что необходимо улучшать в процессе анализа инцидентов. Дело в том, что процесс обработки сценариев существует в головах, на листочках, в файлах. И когда формализованный процесс начинает работать как система, слабые места обнаруживаются и улучшаются автоматически.
Кроме того, современные IRP/SOAR имеют базы знаний, справочники, механизмы выбора лучших решений и подсказок, в том числе с использованием ИИ.

Как организации "куют" кадры для работы и анализа данных в IRP/SOAR – ищут, готовят, переманивают?

Дмитрий Поливанов, ДиалогНаука:
Нанятый на рынке специалист не будет сразу готов к выполнению задач в рамках работы с IRP/SOAR. Как бы ни был высок класс, ему в любом случае предстоит процесс погружения в специфику инфраструктуры организации и применяемых средств защиты. Зато уже работающий в организации сотрудник обладает необходимой осведомленностью об инфраструктуре и, хотя не имеет навыков работы в новой системе, может получить базовое понимание на этапе внедрения, а более специфичные навыки – по мере использования IRP/SOAR.

Руслан Рахметов, Security Vision:
Подход должен отвечать кадровой политике компании в целом: у одних для этого используется стажировка, у других применяется классическая модель хантинга кадров. Может также применяться переподготовка, она вполне оправданна, если сотрудник работал с различными СЗИ, понимает сетевой и прикладной уровни безопасности, необходимые при обеспечении безопасных интеграций. С тематикой IRP/SOAR отлично справляются специалисты, владеющие направлениями DLP и SIEM.

Александр Ковалев, Zecurion:
Это напрямую зависит от бюджета, так как специалистов мало и они достаточно дороги. Поэтому универсальным ответом будет учить своих сотрудников и мотивировать их остаться в организации в первую очередь интересными задачами.

Илья Петров, Innostage:
Оптимальным вариантом является использование смешанного подхода, включающего в себя задействование в работе собственных специалистов, знающих ИТ-инфраструктуру компании, а также привлечение сторонней экспертизы со стороны SOC. Данное взаимодействие повысит навыки специалистов компании и позволит на практике перенять опыт и навыки для возможности самостоятельного мониторинга и анализа инцидентов ИБ в IRP/SOAR.

Всеслав Соленик, R-Vision:
Поиск готовых специалистов на рынке не покрывает потребностей в кадрах современных SOC, поэтому все же придется растить собственные кадры. Как правило, всегда есть подходящие базовые задачи для молодых специалистов, а выстроенная система обучения и наставничества позволит быстро готовить из них профессионалов. Хорошее партнерское или вендорское обучение также является важным подспорьем, хотя внедрение IRP на практике и анализ реальных инцидентов ничем не заменить.

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

Поэтому сама ситуация может диктовать различные варианты. Оптимальным может быть получение системы как сервиса с возможным постепенным переходом к модели in-house.

Михаил Савин, КИТ.Р:
Нужно идти в университеты, открывать свои лаборатории, организовывать совместные магистерские программы. Например, я сейчас прохожу обучение по магистерской программе, разработанной совместно с ИРИТ-РТФ УрФУ и компанией УЦСБ. Помимо непосредственно процесса обучения, это также отличная возможность для хантинга перспективных специалистов. Бакалаврам же можно предлагать оплачиваемые стажировки в SOC.

Как понять, что организация созрела для использования SOC?

Алексей Горелкин, Phishman:
В целом SOC – это набор процессов, и если организация созрела для внедрения IRP/SOAR, главного инструмента для специалистов центра реагирования, то появление SOC становится лишь вопросом времени.

Михаил Савин, КИТ.Р:
SOC – это знания, люди, процессы и инструменты. Неважно, используете вы термин SOC или нет, если у вас есть эти компоненты, значит, вы уже строите SOC.

Александр Носарев, Angara:
Потребность в SOC возникает при достижении компанией и ее ИБ-службой определенного уровня развития. Его использование в виде услуги не предполагает, в частности, формирования подразделения, внедрения систем. Но при этом к моменту принятия решения о SOC уже должны быть внедрены блокирующие средства (AV, HIPS/NIPS, FW и др.), имеющие приоритет над детектирующими. Далее следует провести расчет: если стоимость реализации рисков, которые может закрыть SOC, выше стоимости его услуг – надо брать.

Илья Петров, Innostage:
Если в компании реализован базовый уровень ИБ, установлена SIEM, а также возникают задачи контроля общего состояния ИБ на системной основе, предотвращения инцидентов и компьютерных атак, это является индикатором достаточной зрелости для использования SOC. Остается выбрать для себя подход: создание собственно SOC, передача этих задач на сервис либо применение гибридного подхода.

Всеслав Соленик, R-Vision:
SOC – понятие относительное как по размеру, так и по зрелости. Это и ситуационный центр на сотню аналитиков, и внутренний отдел из пяти человек; главное – построить эффективные процессы выявления и реагирования на инциденты, а также применять качественный инструментарий. Если есть потребность реагировать на инциденты ИБ, есть желание и ресурсы снижать риски информационной безопасности, значит, организация созрела и нужно начинать пробовать строить свой или использовать внешний SOC.

Александр Ковалев, Zecurion:
Очень многим организациям помогла созреть нормативно-правовая база, поэтому в первую очередь стоит убедиться в наличии или отсутствии регуляторных требований. Понимание необходимости SOС приходит примерно так же, как и в случае с управленческой отчетностью: в какой-то момент становится понятно, что данных стало слишком много и пора менять угол зрения (дашборды, отчеты, показатели). Второй критерий: наступление момента, когда хочется выделить реагирование в постоянную и развивающуюся функциональность.

Руслан Рахметов, Security Vision:
Когда формализовался процесс управления инцидентами кибербезопасности, можно считать, что компания созрела для SOC и для выхода на управляемый сервис. Множественность ручных операций, связанных с ИБ, является безусловной предпосылкой к построению SOC. Готовность к использованию SOC – это прежде всего зрелость отдела ИБ, его стремление к автоматизации рутины, к повышению скорости реагирования и к безопасности компании в целом.

Что лучше, свой SOC или внешний?

Илья Петров, Innostage:
Для принятия правильного решения необходимо определиться, какие функции обеспечения ИБ компания хочет и может реализовать внутри, а в каких случаях будут привлекаться внешние ресурсы. Это сильно зависит от ИТ-инфраструктуры и количества специалистов по ИБ. Зачастую выгоднее использовать гибридную модель, сочетая навыки собственной команды с сервисами кибербезопасности, дополняющими внутренний SOC экспертизой, которую нецелесообразно содержать внутри компании.

Михаил Савин, КИТ.Р:
Идеально, если вы можете позволить себе оба варианта. То есть внутренний SOC решает задачи первой-второй линии, а сложные случаи вы отдаете во внешний SOC с экспертизой, и он же проводит перформанс-ревью внутреннего SOC. Либо, например, внешний SOC занимается определенным типом событий/инцидентов, например из сегмента АСУ ТП.

Валерий Горбачев, ДиалогНаука:
Выбор напрямую зависит от возможности поддерживать необходимую инфраструктуру – круглосуточную первую линию, высококвалифицированных админов СЗИ и т.д. По мере развития зрелости ИБ хорошим ориентиром будет следующий путь развития:
1. Полностью внешний SOC с экспертизой вендоров и провайдера в части контента, выявления инцидентов, подключения источников.
2. Перенос части функций к компании по мере готовности.
3. Внутренний SOC, использующий, возможно, внешнюю первую линию.

Александр Носарев, Angara:
Каждый вариант имеет свои преимущества. Свой SOC – это полная согласованность с инфраструктурой, бизнес-процессами и высокая скорость реагирования на их изменения. Минусы решения in-house заключаются в том, что для обеспечения квалифицированного мониторинга 24 х 7 необходимы такие вложения (CAPEX и OPEX) во внедрение систем, поиск, развитие и удержание персонала, что направление может оказаться нецелесообразным. Есть и третий, гибридный, вариант с признаками каждого из первых двух.

Руслан Рахметов, Security Vision:
Вопрос имеет заметный управленческий оттенок, и ответ зависит от выбора модели бизнеса компании, от того, как компания работает с рисками. В случае своего SOC все понятно: своя инфраструктура, свои СЗИ, свой персонал и свои риски. В случае внешнего SOC компания должна довериться и фактически переложить риски ИБ на внешний SOC. Каждый делает выбор, исходя из целей бизнеса и бюджета. Свой SOC – это больше CAPEX, внешний SOC – это больше OPEX

Всеслав Соленик, R-Vision:
Выбор внешнего или внутреннего SOC сводится к потребностям, опыту и контексту того, кто отвечает на этот вопрос. На практике внутренний SOC требует компетенций, времени и ресурсов. Если чего-то из этого нет, можно начать с внешнего сервиса и со временем перейти к гибридной модели либо построить свой. Гибридность может подразумевать получение извне части сервисов, компетенций, систем или персонала.

Алексей Горелкин, Phishman:
Выбор зависит от специфики бизнеса. Тут нет "лучше" или "хуже", все зависит от того, какие задачи решаются. Если важен вопрос соотношения цены и качества, то внешний SOC выглядит более привлекательным. Если в бизнесе много специфических особенностей, а также нет сложностей с бюджетом, то собственный SOC будет более качественно и оперативно обрабатывать события. Промежуточный вариант – импланты для SOC внутри организации.

Александр Ковалев, Zecurion:
Если речь о полноценном SOC, то для небольших и средних организаций оптимальным видится сторонний SOС – это в общем случае дешевле, проще и эффективнее. Для крупных организаций эффективны как собственные, так и гибридные модели по аналогии с большинством других бизнес-функций: ключевая компетенция сохраняется внутри, но регулярно привлекаются внешние "мозги" и "руки".

Реальна ли возможность внедрения технологий искусственного интеллекта в управление инцидентами ИБ?

Валерий Горбачев, ДиалогНаука:
Нужно реалистично подходить к оценке возможностей ИИ. Как и в любой другой сфере, в ИБ действует принцип приемлемой точности. То есть ИИ никогда не сможет обработать все инциденты самостоятельно, и в любом случае часть действий придется выполнять человеку, включая работу с неочевидными False Positive, доработку правил корреляции и т.д. Практика показывает, что планка приемлемой точности неизменно сдвигается в сторону увеличения трудозатрат персонала.

Михаил Савин, КИТ.Р:
Технологии ИИ – уже реальность, и они шире, чем просто машинное обучение. Например, мы разработали технологию автоматизированного (в перспективе – полностью автоматического) расследования атак для ряда популярных техник из матрицы MITRE ATT&CK на основе компьютерной онтологии MITRE D3FEND, связывающей техники защиты и нападения.

Алексей Горелкин, Phishman:
Все, что имеет закономерности (даже если человек с первого раза их не видит), может быть автоматизировано на базе машинного обучения. Сначала, конечно, это будут рекомендации для оператора, который сам станет выбирать, как поступить, но впоследствии многие повторяющиеся действия будут автоматизированы.
Единственная проблема, которую я вижу, – это составление датасета для обучения.

Руслан Рахметов, Security Vision:
Система реагирования на основе ИИ Security Vision IRP/SOAR используется в банках из топ-10 и структурах государственной власти. Модуль анализа содержит модели машинного обучения с возможностью автоматического определения и выполнения команд реагирования на инциденты кибербезопасности. Сервис используется в качестве инструмента обогащения данных при получении инцидентов ИБ от других источников с целью выстраивания полной информации об атаке или нарушениях ИБ, предложения лучших решений и выявления аномалий с использованием ИИ.

Александр Носарев, Angara:
Многие производители уже сейчас пытаются добавить своим потребителям ценность за счет использования ИИ. Но правда заключается в том, что только незначительный процент организаций достиг того уровня, когда исчерпаны более простые методы выявления, расследования и реагирования на инциденты ИБ.

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

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

Александр Ковалев, Zecurion:
В широком понимании ИИ в управлении инцидентами навряд ли скоро заменит человека в части расследований, но в плане автоматизации постоянно делаются большие шаги, одной из точек приложения которых является SOAR.

 

securityvision-jpg

 

Темы:SOCIRPЖурнал "Информационная безопасность" №5, 2021SOAR

Хотите участвовать?

Выберите вариант!

КАЛЕНДАРЬ МЕРОПРИЯТИЙ 2021
ПОСЕТИТЬ МЕРОПРИЯТИЯ
ВЫСТУПИТЬ НА КОНФЕРЕНЦИЯХ
СТАТЬ АВТОРОМ

More...