Реализация процессов управления инцидентами и уязвимостями информационной безопасности
в финансовых организациях

Задачи контроля и отчетности перед ЦБ по инцидентам ИБ стоят перед банками достаточно давно. Требования по предоставлению такой отчетности впервые появились в «Указании от 9 июня 2012 г. N 2831-У» ЦБ РФ. Однако в этом документе не содержатся в явном виде ни требования полноты отчета по инцидентам, ни требования к технологиям сбора данных и анализа инцидентов. Банковский сектор давно отстроил все необходимые процессы и предоставляет ЦБ необходимую формальную отчетность. И судя по всему, всем участникам этого процесса очевидна его формальность, поэтому в последних нормативных документах, выпущенных регулятором, достаточно четко просматривается тенденция к переходу от номинальной отчетности к реальному мониторингу событий ИБ и реагированию на них.

И действительно, возьмем к рассмотрению ГОСТ 57580.1, как наиболее свежий стандарт ИБ, соответствовать которому с недавних пор обязана большая часть финансовых организаций. В нем ясно устанавливается требуемый объем и полнота выявления и анализа инцидентов ИБ.
Положения Банка России N 683-П, N 719-П и N 747-П тоже не обходят стороной и требуют содержательного информирования ЦБ (и общественности!) не только об инцидентах, но и о мерах по их предотвращению.

Что касается уязвимостей, то на эту тему тот же ГОСТ 57580.1, содержит набор требований, отраженных в разделе «Процесс 3 «Контроль целостности и защищенности информационной инфраструктуры». Помимо требований к технической реализации процесса по контролю отсутствия и устранению уязвимостей, которых в данном разделе более 10, важным моментом является то, что ГОСТ 57580.1 устанавливает требование по непрерывности процесса управления уязвимостями, что не позволяет реализовать данное требование в формате разовых ежегодных сканирований, а требует реализовать полноценный процесс, который выливается в постоянную цикличную работу от момента выявления до проверки устранения выявленных уязвимостей.

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

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

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

Если говорить об управлении инцидентами, то здесь ситуация обстоит сложнее. Помимо обеспечения централизованного сбора событий ИБ с информационных ресурсов и оборудования, необходимо обеспечивать корреляции для выявления инцидентов. В этом случае также не обойтись организационными мерами, ГОСТ 57580.1 однозначно, требует применение именно технических средств сбора и обработки информации о событиях ИБ.

Посмотрим на характер и полноту данных, собираемых в рамках процесса «Управление инцидентами защиты информации» (табл. 33 из п 7.7):
требуется сбор и регистрация данных о событиях защиты информации, формируемых:

• техническими мерами, входящими в состав системы защиты информации;
• сетевым оборудованием, в том числе активным сетевым оборудованием, маршрутизаторами, коммутаторами;
• сетевыми приложениями и сервисами;
• системным ПО, операционными системами СУБД и т. д.

Хранить и обрабатывать подобный объем информации можно только с использованием технических средств (см. меру МАС.17).

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

В итоге ресурсы, необходимые для реализации процессов управления инцидентами и уязвимостями, можно разделить на две части:

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

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

• приобрести и развертывать решения самостоятельно;
• покупать функционал как сервис у сторонних специалистов.

Рассмотрим оба этих варианта в части процессов управления инцидентами, так и в части управления уязвимостями подробнее.

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

Разделим процедуру реализации процессов управления инцидентами и уязвимостями на два этапа:

1. Развертывание системы мониторинга, включающее:

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

2. Реализация операционного процесса управления инцидентами и уязвимостями, включая:

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

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

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

После выбора и приобретения SIEM-системы и сканеров безопасности необходимо осуществить их настройку.

Настройка сканеров безопасности не требует большого количества ресурсов и квалификации, осуществляется достаточно оперативно.

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

В части технической реализации необходимо провести комплекс работ, включающий:

• разворачивание инструментария (SIEM-системы);
• проведение инвентаризации информационной инфраструктуры;
• настройка источников событий безопасности (необходимо обеспечить регистрацию и направление в SIEM-систему перечня событий безопасности, признанных необходимыми для расследования сформированного перечня инцидентов. Сюда в соответствии с требованиями относятся АРМ пользователей, серверная инфраструктура, коммутационное оборудование, прикладное банковское ПО, СЗИ).
• разработка и настройка правил корреляции событий безопасности в SIEM-системе с целью выявления инцидентов.

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

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

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

• SIEM-система;
• сканеры безопасности.

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

Стоимость продления технической поддержки ежегодно составляет 25−30% от стоимости решения.

Стоимость сканеров безопасности в свою очередь начинается от ~90 000,00 рублей в год для небольшой инфраструктуры.

Итого стоимость приобретения и продления в течение двух лет инструментария для осуществления процессов управления инцидентами и уязвимостями информационной безопасности составляет в минимальном объеме ~2,5 млн. рублей за три года.

После внедрения информационной инфраструктуры комплексная система поступает в эксплуатацию. Для полноценной реализации функций управления инцидентами и уязвимостями необходимо иметь в штате кадровые ресурсы в объеме 2 сотрудников, роли которых прямо зафиксированы в ГОСТ 57580.1 и в общем случае обозначаются как группа реагирования на инциденты защиты информации (ГРИЗИ):

Кроме того, руководитель информационной безопасности (или иное лицо) должен курировать и координировать процесс функционирования подразделения, заниматься постановкой и распределением задач, формированием регламентов выявления и реагирования, форм отчетности (в соответствии с требованиями ГОСТ 57580.1 руководитель и секретарь ГРИЗИ).

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

В сухом остатке для реализации процессов управления инцидентами и уязвимостями в организации потребуется 2 человека и некоторое время руководителя подразделения информационной безопасности.

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

Команда осуществляет:

• внедрение требуемого инструментария самостоятельно;

В части управления инцидентами:

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

В части управления уязвимостями:

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

Кроме того, могут предоставляться дополнительные опции, например, в Акрибии это:

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

Все затраты, связанные как с инструментарием, так и с оплатой труда специалистов, заложены в стоимость услуги.

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

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

2. Критичность для компании предоставления подрядчику постоянного доступа к информационной инфраструктуре
Здесь компании необходимо ответить на вопрос есть ли готовность предоставить удаленный доступ сторонней организации ко всей инфраструктуре или нет.

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

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

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

Сравнение прямых затрат на решение при разных сценариях дан ниже. Рассматриваемый временной промежуток реализации процессов равен 3 годам, количество анализируемых EPS (Event Per Second) равным 500. Стоимость сервиса приобретаемой услуги рассчитана исходя из тарифов SOC Акрибии и может отличаться от других компаний на рынке Серверная инфраструктура вынесена за границы расчета по причине того, что потребуется для обоих вариантов реализации.

Расходы при самостоятельной реализации:

* уровень заработной платы получен из данных Росстата о средней заработной плате инженера по информационной безопасности и данных портала Head Hunter.