Журнал "Information Security/ Информационная безопасность" #1, 2019

вителей ИТ-блока, согласованием документации и принятием реше- ний по определению архитектуры СМСИБ, я бы определила, что самыми сложными работами являются подключение источников событий и настройка правил кор- реляции. Именно от их правиль- ного выполнения зависит коррект- ная работа СМСИБ, и на них я остановлюсь поподробней. Для себя мы решили подклю- чить источники событий, пред- ставленные в табл. 1. Так же, как и источники собы- тий, каждая организация выби- рает для себя, какие события либо их совокупность будут являться инцидентами ИБ (от этого и будет зависеть настройка правил корреляции). В табл. 2 приведен перечень инцидентов ИБ, для выявления которых в СМСИБ настраивают- ся правила анализа (корреляции) собираемых событий безопас- ности. Проблемные моменты Хотелось бы отметить проблем- ные моменты, с которыми столк- нулись при выполнении работ по подключению источников событий и настройке правил корреляции. 1. Выбранная нами СМСИБ "читает" не все события (даже если способ взаимодействия систем соответствует техниче- ским характеристикам), переда- ваемые от внешних систем. По ряду систем защиты инфор- мации приходилось взаимодей- ствовать с разработчиками про- изводителя СМСИБ в целях нор- мализации полученных событий и приведения их в читаемый вид. А это дополнительное время и трудозатраты. 2. СМСИБ и подсистема ана- лиза защищенности одного про- изводителя не взаимодействуют друг с другом. В данном случае также решили проблему путем доработки системы разработчи- ками производителя. 3. В связи с большим потоком событий СМСИБ не всегда свое- временно их обрабатывает, обра- зуются задержки во времени фор- мирования инцидентов и сбои в работе системы. Данную про- блему удалось решить путем исправления ошибок конфигура- ции сети и постоянной нормали- зацией работы источников собы- тий (в рамках техподдержки). 4. "Коробочные" правила кор- реляции событий дают очень много ложноположительных сра- батываний, например когда взаи- модействие пакетов внутри сети в рамках одного сервиса являются легитимным. Администратором ИБ осуществляется анализ всех инцидентов и в случае выявления ложноположительных срабатыва- ний в рамках технической под- держки осуществляется коррек- тировка правил корреляции путем добавления исключений. Техническая поддержка Здесь все просто. Поддержи- вать систему в работоспособном состоянии непременно необхо- димо, так как не каждая органи- зация может позволить себе иметь в штате квалифицирован- ного специалиста, обычно заклю- чают договор на оказание техни- ческой поддержки первой и вто- рой линии. Данные о правилах оказания технической поддержки прописываются в SLA. Все эти этапы могут выполнить как разные интеграторы, так и один интегратор (системная интеграция). При проведении интеграцион- ного проекта я очень рекомендую проводить системную интеграцию (рис. 2), так как такой вид про- ектной деятельности в будущем поможет избежать ряда проблем, связанных с донастройкой и экс- плуатацией систем ИБ. Преимуществами системной интеграции являются: l комплексность: именно тот интегратор, который проектиро- вал систему, осуществляет поставку программных или про- граммно-аппаратных средств защиты, их внедрение и после- дующую техническую поддержку, что позволяет сократить сроки простоя системы при сбоях в работе и качественно доработать ошибки работы системы; l ответственность: гарантийные обязательства на внедренную систему или подсистему защиты информации осуществляет один интегратор, что исключает пере- кладывание обязанностей в слу- чае, если разные этапы прово- дились разными интеграторами; l доработка: в случае если на этапе внедрения вы что-то забыли (как мы), эти работы проведет тот же интегратор, который выполнял работы по внедрению, в рамках сертифи- ката технической поддержки. Подводя итог, хотелось бы ска- зать, что внедрять новые систе- мы совсем даже не страшно, а увлекательно, интересно. l • 13 УПРАВЛЕНИЕ www.itsec.ru Ваше мнение и вопросы присылайте по адресу is@groteck.ru Довольно редко говорят о способах организации под- разделений, обеспечивающих защиту информации. Среди наиболее часто встречающих- ся примеров можно указать: делегирование полномочий по эксплуатации в другое под- разделение и выпестовыва- ние контрольных функций, направленных на обеспечение соответствия (аудит, compli- ance). При этом размер орга- низации задает еще несколь- ко параметров: иерархич- ность (учитывает принятый стиль управления), способ взаимодействия (рекоменда- ции, стандартизация, прямое воздействие), зависящий от формы управляемых компа- нией объектов (филиалы, ДЗО и пр.) и собственно количество защищаемых объектов и пользовате- лей. Все эти параметры напрямую влияют на коли- чество ресурсов (бюджет/количество работников), которыми управляет руководитель службы ИБ. А чтобы он не просто руками водил (или разводил), каждым таким руководителем применяются инстру- менты управления проектами и командой. А так как в этой области есть большое количество стан- дартов, грех не обратиться к ним. К примеру, обсуждаемая с подачи многих интег- раторов (или, как сейчас модно говорить, сервис- провайдеров) тема аутсорсинга услуг в области обеспечения ИБ давно признана понятной и эффек- тивной в ИТ-среде. Есть формулы, подходы, поз- воляющие рассчитать предполагаемую выгоду и прогнозируемый эффект. При этом в ITIL есть область, касающаяся управления поставщиками, которая в проекции на наши реалии и законода- тельные ограничения трансформируется в управ- ление сервис-контрактами. Интересна форма управления ИБ, предполагаю- щая сочетание нескольких сервис-провайдеров для полноценного делегирования основных функ- ций обеспечения ИБ. В зависимости от принятой формы по-разному выглядят механизмы управле- ния. 1. Руководитель службы, обеспечивающей все этапы, – классический управленец, нацеленный на многие аспекты обеспечения ИБ. Основной инстру- мент – знания и классические методы управления. 2. Руководитель подразделения с контрольными функциями, в основном обеспечивает контроль и соответствие, делегируя остальные функции. Инструментарий базируется на контролях, описан- ных в документах, принятой методологии проверки таких контролей. 3. Менеджер сервис-контрактов, опирается на SLA, прописанный в договорах. Самый призем- ленный и приближенный к проектной деятельности управленец, ориентируется на качество выполнения заданных договором обязательств. Лев Палей, начальник отдела ИТ-обеспечения защиты информации, АО “СО ЕЭС” Колонка редактора