Интеграционные проекты: практические кейсы на основе собственного опыта
Елена Нагорная, 20/05/19
Порой с момента решения о внедрении какой-либо системы или подсистемы защиты информации до ее реального внедрения проходят месяцы, а бывает, что и годы. Это выбор продукта и вендора, проведение пилотных испытаний, обоснование экономической целесообразности, подготовка проектной документации, ее согласование с ИТ-блоком (а равно поиск компромиссов), подготовка технической документации, проведение закупочной процедуры... и так можно продолжать до бесконечности.
Чтобы дойти до самого процесса интеграции, в большинстве случаев специалистам в области информационной безопасности нужно пройти сложный и запутанный квест.
В этой статье я хотела бы поделиться практическими «лайфхаками» как упростить реализацию интеграционного проекта и сохранить нервы себе и своему руководству.
Любой интеграционный проект включает в себя несколько этапов, я не буду останавливаться на этапах, не смежных технической области или напрямую не относящихся к информационной безопасности, и выделю четыре.
Остановимся на каждом этапе подробнее. В данной статье мы рассмотрим все этапы интеграции на примере создания системы мониторинга событий информационной безопасности (СМСИБ).
СМСИБ применяется для:
- оперативного контроля за защищенностью информационных систем;
- обнаружения и сбора событий безопасности из журналов аудита информационных систем;
- корреляции событий безопасности и обнаружения инцидентов ИБ;
- построения отчетов и оповещения об инцидентах ИБ;
- обеспечения хранилища исходных и нормализованных событий безопасности;
- обеспечения инвентаризации и управления конфигурациями информационных активов.
Проведение обследования
В большинстве случаев на данном этапе проводится изучение текущей инфраструктуры. Итоговым документом должен быть отчет о предпроектном обследовании, который содержит:
- имеющиеся нормативно-методические и организационно-распорядительные документы по вопросам обеспечения информационной безопасности;
- порядок взаимодействия подразделений, обеспечивающих и контролирующих информационную безопасность;
- актуальные сведения об архитектуре сети, составе и количестве технических и программных средств информационной системы;
- информацию о наличии требований к сбору и анализу событий информационной безопасности, расследованию инцидентов ИБ, к срокам хранения данных о событиях информационной безопасности и инцидентах ИБ;
- планы по модернизации сети и информационной системы с указанием ориентировочных сроков проведения работ;
- другие особенности информационной системы, влияющие на архитектуру СМСИБ.
Этот этап чаще всего проводится заказчиками в рамках системной интеграции единого проекта, но также может проводиться отдельно как научно-исследовательская работа (НИР).
В случае, если предпроектное обследование проводится в рамках НИР, то помимо аудита текущей инфраструктуры проводится анализ имеющихся продуктов СМСИБ на российском рынке, выбор программного продукта и технико-экономическое обоснование. В таком случае документ «Отчет о предпроектном обследовании» дополнительно включает в себя:
- сравнительный анализ СМСИБ;
- технико-экономическое обоснование выбора СМСИБ с учетом потребностей и архитектуры сети заказчика.
Подготовка технической/проектной
и эксплуатационной документации
Это является важным этапом, т.к. определяет технические решения, проект внедрения СМСИБ, порядок подготовки к вводу СМСИБ в действие, порядок взаимодействия подразделений и мн.др.
Важно, чтобы техническая и эксплуатационная документация была подготовлена в соответствии с требованиями:
- ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания»;
- ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании автоматизированных систем».
Более подробно о составе документов и их содержании останавливаться не буду.
Внедрение
Самый важный этап. В нем как правило задействованы не только специалисты, обеспечивающие ИБ, но и представители блока ИТ. В нашем случае мы еще привлекали разработчиков программного обеспечения, интеграция которого была запланирована с СМСИБ.
Этап внедрения включает в себя следующие мероприятия:
- развертывание аппаратной части (установка серверов в стойки, создание виртуальных машин – это в нашем случае, т.к. вся инфраструктура организации развернута на среде виртуализации);
- инсталляция ОС и компонентов ПО;
- подключение источников событий ИБ;
- настройка сбора сведений об информационных ресурсах;
- настройка правил корреляции событий безопасности для выявления инцидентов ИБ;
- донастройка системы (разграничение прав доступа, создание учетных записей и др.).
Как менеджер проектов, который занимается организацией взаимодействия интеграторов, вендоров и представителей ИТ-блока, согласованием документации и принятием решений по определению архитектуры СМСИБ, я бы определила, что самыми сложными работами являются подключение источников событий и настройка правил корреляции. Именно от их правильного выполнения зависит корректная работа СМСИБ. И на них я остановлюсь поподробней.
Для себя мы решили подключить источники событий, представленные в таблице 1.
Так же, как и источники событий, каждая организация выбирает для себя, какие события либо их совокупность будут являться инцидентами ИБ (от этого и будет зависеть настройка правил корреляции).
В таблице 2 приведу перечень инцидентов ИБ, для выявления которых в СМСИБ настраиваются правила анализа (корреляции) собираемых событий безопасности.
Проблемные моменты
Хотелось бы отметить проблемные моменты, с которыми столкнулись при выполнении работ по подключению источников событий и настройке правил корреляции.
- Выбранная нами СМСИБ «читает» не все события (даже если способ взаимодействия систем соответствует техническим характеристикам), передаваемые от внешних систем. По ряду систем защиты информации приходилось взаимодействовать с разработчиками производителя СМСИБ в целях нормализации полученных событий и приведения их в читаемый вид. А это дополнительное время и трудозатраты.
- СМСИБ и подсистема анализа защищенности одного производителя не взаимодействуют друг с другом. В данном случае также решили проблему путем доработки системы разработчиками производителя.
- В связи с большим потоком событий, СМСИБ не всегда своевременно их обрабатывает, образовываются задержки во времени формирования инцидентов и сбои в работе системы. Данную проблему удалось решить путем исправления ошибок конфигурации сети и постоянной нормализацией работы источников событий (в рамках техподдержки).
- «Коробочные» правила корреляции событий дают очень много ложноположительных срабатываний. Например, когда взаимодействие пакетов внутри сети в рамках одного сервиса являются легитимными. Администратором ИБ осуществляется анализ всех инцидентов и, в случае выявления ложноположительных срабатываний, в рамках технической поддержки осуществляется корректировка правил корреляции путем добавления исключений.
Техническая поддержка
Здесь все просто. Поддерживать систему в работоспособном состоянии непременно необходимо, так как не каждая организация может позволить себе иметь в штате квалифицированного специалиста, обычно заключают договор на оказание технической поддержки первой и второй линии. Данные о правилах оказания технической поддержки прописываются в SLA.
Все эти этапы могут выполнить как разные интеграторы, так и один интегратор (системная интеграция).
При проведении интеграционного проекта я очень рекомендую проводить системную интеграцию (рис. 2), так как такой вид проектной деятельности в будущем поможет избежать ряда проблем, связанных с донастройкой и эксплуатацией систем ИБ.
Преимуществами системной интеграции являются:
- комплексность: именно тот интегратор, который проектировал систему, осуществляет поставку программных или программно-аппаратных средств защиты, их внедрение и последующую техническую поддержку, что позволяет сократить сроки простоя системы при сбоях в работе и качественно доработать ошибки работы системы;
- ответственность: гарантийные обязательства на внедренную систему или подсистему защиты информации осуществляет один интегратор, что исключает «перекладывание» обязанностей в случае, если разные этапы проводились разными интеграторами;
- доработка: в случае, если на этапе внедрения, вы что-то забыли (как мы), эти работы проведет тот же интегратор, который выполнял работы по внедрению, в рамках сертификата технической поддержки.