Как управлять инцидентами ИБ?

Типовой жизненный цикл управления инцидентами ИБ состоит из трех основных составляющих: Prevention – предотвращение; Detection – выявление инцидентов ИБ; Response – реагирование.

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

Зачем и как решать инциденты ИБ?

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

Как и большинство бизнес задач, задача управления инцидентами ИБ решается с помощью трех составляющих: люди процессы и технологии. Частая ошибка организаций при решении какой-либо задачи – использование одной из трех компонент, например, только технологии. Другими словами, закупается некое программное обеспечение, например SIEM, и существующим сотрудникам, в дополнение к текущим задачам, без дополнительного обучения и затрат на полноценное внедрение и консалтинга по выстраиванию процессов в организации, поручается решить с его помощью поставленную новую задачу.

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

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

SIEM – не панацея

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

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

В зависимости от размера организации и от качества настройки SIEM, подозрений на инциденты ИБ может быть большое количество. По каждому выявленному подозрению на инцидент ИБ так же необходимо определить, в чьей зоне ответственности он находится, кто должен дать вердикт по нему, другими словами, определить маршрут уведомления. Так же при большом количестве подозрений инцидентов ИБ острой становится задача их учета и поддержания в актуальном состоянии ИТ активов, а также возможность их использовать для автоматического обогащения карточек с подозрениями на инциденты ИБ. Для решения этих задач существует отдельный класс программных решений под названием Incident Response Platform (IRP). IRP платформы позволяют вести учет подозрений на инциденты ИБ, их обогащение и правильную маршрутизацию, актуализацию статусов реагирования на них, принятые меры и др. IRP платформы разрабатываются универсальными, что позволяет адаптировать платформу под состав ИТ инфраструктуры организации, структуру организации, запущенные сценарии выявления инцидентов ИБ, и другие особенности. Адаптация платформы осуществляется путем подключения источников данных инвентаризации об ИТ инфраструктуре, создания и поддержания в актуальном состоянии активов, разработке плейбуков под соответствующие сценарии выявления инцидентов ИБ и др. IRP платформы так же, как и SIEM, являются сложным программным комплексом, требующим так же как и SIEM обученных специалистов и консалтинг при внедрении.

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

Итоги

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

Основная задача проведения расследования инцидента ИБ – получить ответы на вопросы: «Что произошло? Как это произошло? Почему это произошло? Кто это сделал?».

Основные цели проведения расследования инцидентов ИБ:

• выявить уязвимые компоненты ИТ инфраструктуры, недостатки систем защиты или процессов и устранить их, чтобы аналогичных инцидентов ИБ более не повторялось;
• подтвердить либо опровергнуть подозрения, что в ИТ инфраструктуре происходит не легитимная активность;
• привлечь к ответственности злоумышленника.

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

Автор: Дмитрий Гаранин