Контакты
Подписка 2025

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

Елена Нагорная, 20/05/19

 

 

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

 

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

nagornaya_ris1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внедрение

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

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

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

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

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

nagornaya_tab1

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

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

nagornaya_tab2

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

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

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

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

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

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

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

nagornaya_ris2

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

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

 

 

Темы:Елена НагорнаяТехснабэкспортУправление

Программа мероприятий
по информационной безопасности
на ТБ Форуме 2025
Крокус Экспо | 11-13 февраля 2025

Посетить
Обзоры. Спец.проекты. Исследования
Кибербезопасность. Защита АСУ ТП. Безопасность КИИ. Москва | 11 февраля 2025
Получите комментарии экспертов на ТБ Форуме 2025
Статьи по той же темеСтатьи по той же теме

  • Стратегия аудита информационной безопасности в пяти шагах
    Константин Саматов, Член Правления Ассоциации руководителей службы информационной безопасности
    В условиях стремительного развития технологий и увеличения числа угроз регулярный аудит становится необходимым инструментом для обеспечения надежной защиты данных, предотвращения утечек информации и обеспечения непрерывного функционирования информационных ресурсов.
  • Кризисный менеджмент в информационной безопасности
    Константин Саматов, Член Правления Ассоциации руководителей службы информационной безопасности
    В данной статье рассмотрим, что такое кризисный менеджмент и как его принципы соотносятся с классическим циклом PDCA, обеспечивая системный подход к управлению информационной безопасностью.
  • Ключевые индикаторы риска: как ими правильно пользоваться
    Кирилл Чекудаев, ведущий консультант по информационной безопасности RTM Group
    Ключевые индикаторы риска (КИР) необходимо корректно определить, и на этом этапе, как показывает практика, у многих организаций финансового сектора возникают проблемы.
  • Секьюритизация сотрудников: практики и инструменты в интересах безопасности организации
    Кирилл Шалеников, руководитель проектов в интеграторе Angara Security
    Security Awareness – неотъемлемая часть стратегии информационной безопасности для любой организации. Обученные сотрудники способствуют созданию более защищенной среды и снижают риски для потери данных и репутации компании. Инвестиции в обучение и повышение осведомленности сотрудников могут оказаться одной из наиболее эффективных мер по обеспечению безопасности информации.
  • Ключевые показатели эффективности для подразделений информационной безопасности
    Константин Саматов, Член Правления Ассоциации руководителей службы информационной безопасности
    В практической деятельности у руководителей cлужб информационной безопасности часто возникают проблемы, связанные с оценкой эффективности возглавляемого ими подразделения.
  • Что такое Compromise Assessment и зачем он нужен бизнесу
    Семен Рогачев, руководитель отдела реагирования на инциденты системного интегратора “Бастион”
    Если СЗИ молчат, то это не значит, что систему безопасности организации не взломали. Некоторые хакеры могут годами прятаться в ИТ-инфраструктуре и шпионить, прежде чем решат нанести удар. Вовремя выявить такую опасность или убедиться в ее отсутствии помогает практика Compromise Assessment.

Хотите участвовать?

Выберите вариант!

КАЛЕНДАРЬ МЕРОПРИЯТИЙ 2024
ПОСЕТИТЬ МЕРОПРИЯТИЯ
ВЫСТУПИТЬ НА КОНФЕРЕНЦИЯХ
СТАТЬ АВТОРОМ
Linux
13 февраля | Подходы и инструменты управления процессом РБПО
Узнайте на ТБ Форуме 2025!

More...
ТБ Форум 2025
13 февраля. Отечественные ИТ-системы и российское ПО
Жми, чтобы участвовать

More...