В нашей недавней серии статей про SIEM системы упоминалась, среди прочего, встроенная в некоторые продукты возможность управления инцидентами (incident management). Сегодня мы расскажем о некоторых аспектах этого процесса.
Автор: Олеся Шелестова, исследовательский центр Positive Research.
Сотрудники служб ИБ и технические специалисты занимаются решением самых разных задач. При этом не всегда их инициатором является руководство: в случае обнаружения симптомов угрозы, инцидента безопасности или ошибки конфигурации сотрудник вполне может и сам проявить инициативу. Если задачу ставит руководитель, то он, как правило, устанавливает сроки и контролирует ход решения задачи. Однако далеко не во всех компаниях используется специализированное ПО для контроля и учета задач наподобие Microsoft Project. Зачастую применяются «самописные» или адаптированные системы Service Desk. Задачи оформляются в подобном ПО, и далеко не всегда это делается должным образом.
Если сотрудник самостоятельно находит инцидент и сам же занимается его решением, то позиция руководителя здесь: «лишь бы все работало». Редко бывает, что процесс решения задач регламентирован, задокументирован, что выстроена схема согласования. И чем больше компания, тем ситуация хуже.
Вот лишь некоторые недостатки этих двух схем:
Все вышеперечисленное существенно влияет на оперативность решения задач и инцидентов (mean time to remediate, MTTR), на риски их возникновения, простои и даже на размер штата подразделения. При этом невозможно утверждать (и подтвердить это), что в информационных системах компании нет уязвимостей, а те, что есть, своевременно обнаруживаются и устраняются.
Зачастую ретивые менеджеры просто-напросто заставляют сотрудников оформлять инциденты и «заводить» решаемые задачи вручную, полагая, что так порядка будет больше. Очевидно, что построить адекватный процесс управления инцидентами в таких условиях невозможно по двум причинам:
В то же время автоматизация управления инцидентами, построенная на шаблонах регистрации и проведения инцидента с расстановкой задач и контролем сроков их выполнения, — значительно упрощает внедрение, адаптацию и ведение процесса управления инцидентами.
Зачем это нужно?
Для чего нужна автоматизация и переход к управлению инцидентами? Конечно, вы можете выявлять инциденты самостоятельно и по электронной почте или по телефону назначать задачи по их устранению конкретным сотрудникам. Однако всегда есть риск не дозвониться, а письмо может попасть в спам. Специфика ИБ заключается в том, что за это время вирус на рабочей станции способен перерасти в настоящую эпидемию, злоумышленник может провести эксплуатацию уязвимости, похитить конфиденциальные данные, нанести ущерб системе. Во избежание подобных последствий как раз и требуется снижение показателя MTTR.
Представим себе ситуацию, когда инцидент не был своевременно выявлен. Причин тому может быть множество: сотрудник заболел, отвлекся, был загружен другими задачами, банально забыл или ему не хватило опыта. Если процесс управления инцидентами в компании отлажен хорошо, то ситуация «забыл зарегистрировать инцидент» не произойдет в принципе. Инцидент будет зарегистрирован, зафиксирован, а к решению проблемы будет привлечен компетентный сотрудник. Именно для автоматического выявления и регистрации инцидентов нужны механизмы корреляции SIEM-систем. Кстати сказать, подобные системы обычно оснащены и встроенным функционалом управления инцидентами.
Без особых затрат автоматизировать процесс регистрации инцидента можно с помощью автоматически создаваемого электронного письма, содержащего сценарий необходимых действий в зависимости от условий инцидента, запуск процедуры SQL для поиска симптомов инцидента, взаимодействие посредством API. Большинство программных продуктов, предназначенных для обеспечения информационной безопасности, имеют встроенную возможность работы с системами регистрации инцидентов или минимально необходимые инструменты для взаимодействия посредством электронной почты, SNMP, API.
Понятие и организация процесса управления инцидентами для IТ-департаментов наиболее полно и четко описаны в ITIL и ITSM. Для ИБ же, по большому счету, опираться можно только на стандарт NIST 800-61, хотя на практике можно успешно пользоваться и ITIL.
Процесс управления инцидентами включает в себя следующие понятия:
Процесс управления инцидентами может и должен включать в себя часть процессов управления изменениями и управления проблемами (change management и problem management).
Чтобы определить понятия, используемые в процессе управления инцидентами, рассмотрим простые жизненные примеры.
Для правильной организации управления инцидентами необходимо обеспечить по крайней мере три линии поддержки.
Связь пользователь — эксперт — это не лучшая практика: тратить время высокооплачиваемого специалиста на решение простых задач невыгодно. К сожалению, на практике в некоторых случаях это необходимо, к примеру, когда у двух первых двух линий поддержки не хватает компетенции или необходимо как можно быстрее разобраться с причинами инцидентами, позвонив пользователю напрямую, а не играть в «испорченный телефон».
Введем еще один термин. Заголовок — это некое подобие задачи, которая представляет инцидент, запрос на изменение или проблему. Для того чтобы описать шаблонную автоматическую регистрацию инцидента и его назначение в качестве задачи сотруднику, каждый заголовок (инцидент, RFC, проблема) должен включать:
Присвоение приоритета позволяет в первую очередь уделить больше внимания решению действительно значимых инцидентов. В простейшем случае важность той или иной задачи определяется с помощью таблицы:
Однако в случае наличия в инфраструктуре компании систем риск-менеджмента (GRC) или SIEM-систем с возможностью указывать значения ценности актива, все немного сложнее. В общем случае каждая задача (заголовок) должна назначаться конкретному сотруднику или определенной группе специалистов. Уведомление о назначении должно подтверждаться по электронной почте. Перечислим рекомендуемые статусы заголовков для отслеживания процесса решения задач.
На решение любой задачи можно потратить сколько угодно времени или вообще отложить выполнение под грузом других дел, ответственный сотрудник может уволиться/заболеть. Однако если инцидент не будет устранен своевременно, это может негативно сказаться на бизнесе. Именно поэтому, каждая задача и каждый заголовок должны иметь заданный срок решения. Он определяется на основе набора различных параметров (класс, тип подразделения, объект, приоритет, линия поддержки), а для задачи — указывается вручную сотрудником, который ее ставит.
За соблюдением сроков выполнения своих задач обязаны следить все самостоятельно. Для того чтобы облегчить сотрудникам эту задачу, существуют автоматические уведомления о просрочке, рассылаемые по электронной почте или в виде новых задач в рамках заголовков. За соблюдением сроков выполнения заголовков обязаны следить первая линия поддержки и руководители. Если складывается ситуация, когда сроки выполнения заголовка не будут соблюдены, первая линия обязана выяснить причины и предпринять действия к недопущению просрочки (напомнить, оповестить, выяснить причины). Руководители должны получать оповещения о фактической просрочке заголовка (например, выше 25% отведенного на решение времени).
В процессе управления инцидентами учитывается и план реагирования, однако в терминологии SIEM подобный план — это сценарии, которые лишь выполняют регистрацию инцидента и первоначальную постановку задач. Системы Service Desk позволяют «вести» инцидент от момента открытия до подтверждения решения, а также подключать шаблонные планы реагирования — заранее заготовленные инструкции, содержащие описание шагов по устранению типового инцидента.
Функциональные возможности управления инцидентами, реализованные в различных SIEM, перечислены в таблице:
Управление инцидентами полезно и при составлении и обосновании плана минимизации рисков. С его помощью на основании возникающих инцидентов и критичности активов можно оценить слабые места в инфраструктуре. Кроме того, управление инцидентами с автоматическим формированием задач — важно для контроля конфигураций и соответствия стандартам. При ручной обработке формируемых отчетов довольно трудно обнаружить несоответствие какого-либо актива политике безопасности компании. Поэтому возникает проблема оперативного устранения несоответствий. При использовании управления инцидентами задачи на устранение несоответствия будут расставлены автоматически (например, ИТ специалисту, ответственному за этот актив, будет поставлена задача на установку обновления или исправление конфигурации в соответствии с политикой), а экспертам будет предоставлена контрольная информационная задача (чтобы уведомить о найденном несоответствии и предоставить возможность контроля устранения).
При совместном использовании различных систем обработки данных возникает важная проблема разграничения доступа и обеспечения целостности доказательной базы. Как правило, информацию об инциденте и этапах его решения должны иметь далеко не все сотрудники даже внутри одного отдела. Часто именно по этой причине служба ИБ не использует общую с IТ-департаментом систему HelpDesk. Доказательства по инциденту также должны храниться централизовано, а не где-то на файловом сервере.
Итак, все это может вам пригодиться при организации процесса управления инцидентами в ИБ. Вы сможет выстроить необходимые ИБ-процессы компании, упростить предоставление аудиторам статистики при проверках. Кроме того, вам будет легче отчитаться о проделанной работе перед руководством, проще управлять отделом ИБ и распределять нагрузку. Ну и, разумеется, самое главное: управление инцидентами позволит вам минимизировать риски безопасности.