Как правило, первой задачей является автоматизация процесса выявления инцидентов информационной безопасности. На текущий момент на рынке существует большое количество различных SIEM-решений (Security Information and Event Management), которые прекрасно справляются с ней. Но каждое из них требует серьезных стартовых вложений – необходимы закупка оборудования и ПО, привлечение интегратора для обследования инфраструктуры и кастомизации SIEM под конкретные требования бизнеса и службы безопасности. Поскольку суммарная стоимость решения измеряется сотнями тысяч долларов, даже в крупных компаниях зачастую встает вопрос о возможности выделения таких бюджетов.
Но даже если задача создания SIEM-системы решается успешно, на этом построение процесса управления инцидентами ИБ только начинается. Вторым важным аспектом является обеспечение мониторинга и реагирования на возникающие инциденты. Причем в случае, если к SIEM подключены критичные бизнес-приложения или онлайн-сервисы компании, мониторинг и реагирование должны осуществляться в круглосуточном режиме с очень высокой скоростью реакции на возникновение инцидента. Решение по выделению специальной дежурной смены, особенно для работы 24*7, редко проходит проверку финансовой целесообразностью. Каким же образом решается эта проблема?
Самый популярный вариант – использование существующих ресурсов подразделения информационной безопасности. Но сотрудники отдела ИБ имеют большое количество других профильных задач и обычно не могут полноценно обеспечивать требуемую реакцию на инциденты. Совещание/выход на обед/глубокое погружение в разработку организационных мер выдергивают сотрудника из процесса полноценного мониторинга. О режиме 24*7 и говорить не приходится – отделы ИБ, как правило, не имеют круглосуточной дежурной смены. А по странным жизненным законам самый критичный инцидент обязательно произойдет в пятницу поздно вечером, когда сотрудники разошлись по домам, или во время обеденного перерыва. Безусловно, при дальнейшем «разборе полетов» будет найден ответственный, которого накажут по всей строгости. Но инцидент уже произошел, и самое горячее время, когда его последствия можно было минимизировать, упущено.
Вторым вариантом, как правило, становится передача части функций по управлению инцидентами (например, мониторинг и первичное реагирование) в ИТ-подразделение компании, которое зачастую работают в режиме 24*7. Но и здесь не обходится без «подводных камней». Сотрудники ИТ-службы нередко очень далеки от задач ИБ и могут допустить ошибку в определении важности инцидента. Кроме того, им вряд ли по силам полноценно выполнить задачи по определению его источника, причин и провести расследование. При этом ИТ-подразделение само по себе является одной из основных точек контроля в процессе обеспечения информационной безопасности из-за своих повышенных знаний об инфраструктуре и привилегий по работе с ключевыми системами. Поэтому использование их ресурсов для мониторинга ИБ не всегда дает объективные результаты.
Но даже когда, казалось бы, все проблемы решены и процесс управления инцидентами ИБ запущен, остается немаловажный вопрос развития системы. Профили внешних и внутренних угроз ИБ меняются регулярно, а процесс управления инцидентами должен идти в ногу со временем. Сотрудникам ИБ, работающим в рамках конкретной компании, очень сложно выполнять эту задачу: при эксплуатации процессов обеспечения глаза замыливаются, и работа в рамках одной инфраструктуры и компании редко дает пространство для изысканий и исследований в области ИБ.
Pro без contra
В связи с этим российские компании начинают задумываться о передаче процесса управления инцидентами на аутсорсинг или получении этого сервиса на облачной основе. Подобные программы достаточно давно существуют и успешно функционируют в Европе и Америке. В числе клиентов MSSP (Managed Security Service Provider) – несколько тысяч компаний, причем эти услуги имеют спрос не только в SMB-секторе, но и у таких гигантов, как Vodafone и T-Mobile. Давайте разберемся, какие из описанных выше проблем можно решить подобным образом.
Во-первых, использование облачного сервиса может избавить от необходимости стартовых капитальных вложений, например в том случае, когда оборудование и ПО предоставляются аутсорсинговой компанией в аренду. Высокая стартовая цена SIEM-решения преобразуется в существенно меньшие ежемесячные платежи. Помимо этого, сервис-провайдер берет на себя обязанности по размещению основного оборудования и гарантирует его доступность и работоспособность в рамках SLA. Он обеспечивает высокую доступность предоставляемой системы, своевременное и корректное проведение всех работ по ее администрированию и сопровождению, квалифицированное и быстрое предоставление информации из нее. Таким образом, со службы ИБ снимается нагрузка, позволяя ей заниматься другими, не менее приоритетными, задачами по обеспечению безопасности компании. При этом величина регулярных платежей, представляющаяся достаточно высокой при первом рассмотрении, становится более понятной и обоснованной, если учесть косвенные расходы, начиная с уплотнения серверного помещения и обеспечения электропитания до налоговых и премиальных выплат, работы руководителей и кадровых служб, которые получат дополнительную нагрузку (мы не говорим о затратах на закупку оборудования, лицензий и расширение зарплатного фонда).
Во-вторых, внешний сервис-провайдер готов оказывать услуги по мониторингу и реагированию на инциденты в выбранном компанией режиме с теми метриками и набором услуг, которые ей необходимы. В случае, если целевой задачей является мониторинг состояния и защищенности критичного онлайн-сервиса (угрозы несанкционированного доступа, изменения конфигураций, атак на приложение), то контроль, безусловно, должен осуществляться в круглосуточном режиме, а время выявления и оповещения о возникшем инциденте ИБ – измеряться минутами. Но при этом сам процесс расследования инцидента требует крайне ограниченного объема информации, а задачи по реагированию и противодействию могут быть целиком решены сотрудниками, обслуживающими сервис.
Если же речь идет о выявлении и устранении сетевых аномалий инфраструктуры, контроле непрофильного использования технологических систем и учетных записей или анализе интернет-активности пользователей, то критичность такого рода инцидентов чаще всего ниже. Это снижает требования компании к временным показателям услуги, но существенно влияет на объем проводимого анализа и периодически требует активного участия сервис-провайдера в противодействии инциденту и устранении его последствий. Поэтому формирование SLA важно для получения нужного набора услуг с необходимыми метриками обслуживания.
В-третьих, опытный сервис-провайдер, помимо консалтинговой составляющей, обладает экспертизой в интеграции облачного сервиса с банковскими системами, оборудованием связи телеком-операторов, системами управления технологическими процессами, а также CRM- и ERP-приложениями. Это позволяет построить процесс управления инцидентами ИБ, максимально приближенный к задачам обеспечения безопасности бизнес-систем, а не только общей инфраструктуры.
Накопление и использование опыта других компаний, получающих аналогичные услуги, позволяет более глубоко и системно подходить к сценариям определения инцидентов. Последние тенденции отрасли и изменение профилей угроз – новые банковские стандарты безопасности, контроль выполнения требований регуляторов по защите персональных данных или активная борьба с веб-угрозами и DDoS-атаками в публичных сегментах инфраструктуры – также находят отражение в предоставляемой сервис-провайдером базе инцидентов.
При подключении компаний к облачным сервисам проводится адаптация разработанных процедур и уточняется формат оказания услуги по следующим направлениям:
- обследование инфраструктуры и выявление состава подключаемых источников;
- формирование перечня журналируемых событий;
- кастомизация общей базы контролируемых инцидентов под задачи и потребности компании, их приоретизация;
- определение ролей сотрудников, участвующих в расследовании инцидентов;
- согласование порядка и способов взаимодействия при расследовании инцидентов в зависимости от их типа и критичности;
- подготовка и планирование проактивных мер ИБ, предотвращающих повторное возникновение инцидента.
Причем процесс формирования перечня событий, не имеющий высокой степени критичности при построении внутреннего SOC, приобретает совсем другое значение в облачном варианте. Даже при соответствующих соглашениях конфиденциальности компания чаще всего не готова транслировать во внешнюю систему не подлежащие разглашению данные. Но на деле для корректного функционирования и выявления инцидентов SIEM достаточно обрабатывать события аудита и общую информацию активности пользователей: фиксируется факт доступа к критичному файлу или таблице базы данных, а не сам файл или информация из БД. Поэтому степень критичности транслируемой информации мало отличается от характера данных, получаемых интегратором при обследовании системы или ее технической поддержке.
Использование процессного подхода, описанного выше, делает реагирование и разрешение инцидентов ИБ более оперативным и позволяет использовать как аккумулированный провайдером, так и собственный опыт компаний по расследованию инцидентов, специфичных для их бизнеса или особенностей инфраструктуры.
В случае, если компания готова вступить в аутсорсинговые отношения в области управления инцидентами ИБ, следующим ее шагом становится выбор сервис-провайдера, которому она готова доверить этот непростой и важный процесс. В данном случае взаимное терпение в преодолении сложностей на старте, как правило, оказывается более важным, чем скрупулезное согласование состава услуг и метрик обслуживания, и является одним из ключевых факторов успешного взаимодействия.