Интеграционные проекты: практические кейсы на основе собственного опыта

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

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

Остановимся на каждом этапе подробнее. В данной статье мы рассмотрим все этапы интеграции на примере создания системы мониторинга событий информационной безопасности (СМСИБ).

СМСИБ применяется для:

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

Проведение обследования

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

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

Этот этап чаще всего проводится заказчиками в рамках системной интеграции единого проекта, но также может проводиться отдельно как научно-исследовательская работа (НИР).

В случае, если предпроектное обследование проводится в рамках НИР, то помимо аудита текущей инфраструктуры проводится анализ имеющихся продуктов СМСИБ на российском рынке, выбор программного продукта и технико-экономическое обоснование. В таком случае документ «Отчет о предпроектном обследовании» дополнительно включает в себя:

• сравнительный анализ СМСИБ;
• технико-экономическое обоснование выбора СМСИБ с учетом потребностей и архитектуры сети заказчика.

Подготовка технической/проектной
и эксплуатационной документации

Это является важным этапом, т.к. определяет технические решения, проект внедрения СМСИБ, порядок подготовки к вводу СМСИБ в действие, порядок взаимодействия подразделений и мн.др.

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

• ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания»;
• ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании автоматизированных систем».

Более подробно о составе документов и их содержании останавливаться не буду.

Внедрение

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

Этап внедрения включает в себя следующие мероприятия:

• развертывание аппаратной части (установка серверов в стойки, создание виртуальных машин – это в нашем случае, т.к. вся инфраструктура организации развернута на среде виртуализации);
• инсталляция ОС и компонентов ПО;
• подключение источников событий ИБ;
• настройка сбора сведений об информационных ресурсах;
• настройка правил корреляции событий безопасности для выявления инцидентов ИБ;
• донастройка системы (разграничение прав доступа, создание учетных записей и др.).

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

Для себя мы решили подключить источники событий, представленные в таблице 1.

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

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

Проблемные моменты

Хотелось бы отметить проблемные моменты, с которыми столкнулись при выполнении работ по подключению источников событий и настройке правил корреляции.

1. Выбранная нами СМСИБ «читает» не все события (даже если способ взаимодействия систем соответствует техническим характеристикам), передаваемые от внешних систем. По ряду систем защиты информации приходилось взаимодействовать с разработчиками производителя СМСИБ в целях нормализации полученных событий и приведения их в читаемый вид. А это дополнительное время и трудозатраты.
2. СМСИБ и подсистема анализа защищенности одного производителя не взаимодействуют друг с другом. В данном случае также решили проблему путем доработки системы разработчиками производителя.
3. В связи с большим потоком событий, СМСИБ не всегда своевременно их обрабатывает, образовываются задержки во времени формирования инцидентов и сбои в работе системы. Данную проблему удалось решить путем исправления ошибок конфигурации сети и постоянной нормализацией работы источников событий (в рамках техподдержки).
4. «Коробочные» правила корреляции событий дают очень много ложноположительных срабатываний. Например, когда взаимодействие пакетов внутри сети в рамках одного сервиса являются легитимными. Администратором ИБ осуществляется анализ всех инцидентов и, в случае выявления ложноположительных срабатываний, в рамках технической поддержки осуществляется корректировка правил корреляции путем добавления исключений.

Техническая поддержка

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

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

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

Преимуществами системной интеграции являются:

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