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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внедрение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подводя итог, хотелось бы сказать, что внедрять новые системы совсем даже не страшно, а увлекательно, интересно.