Файл: Федеральное государственное бюджетное образовательное учреждение высшего образования санктпетербургский.pdf

VisualLinks предоставляет пользователям развитый инструментарий, с помощью которого они могут самостоятельно, не прибегая к услугам программистов, формировать нужные отчетные документы и аналитические материалы. Основной формой отчета является схема взаимосвязанных объектов. Схемы могут быть различных видов:
– схемы ролевых связей – событие (факт) представляется в виде объекта, с которым на различных ролях связаны другие объекты. Данный способ используется для распознавания следующих схем: точки пересечения, локальные объекты, изолированные кластеры, сильно/слабосвязанные группы, цепочки, общности;
– схемы потоков (почтовых сообщений, финансовых, телефонных звонков и т.п.) - событие (факт) представляется в виде связи, соединяющей два объекта (например, отправителя и получателя, или счета кредита и дебета, или плательщика и получателя). Данный способ используется для распознавания следующих схем: изолированные кластеры, сильно/слабосвязанные группы, цепочки, потоки;
– комплексные схемы – объединяет на одной схеме различные виды представления событий (фактов). Данный способ позволяет избежать
«лавинообразное» увеличение количества объектов на схеме (характерное для представления в виде схем ролевых связей) и получить исчерпывающую картину (что не всегда возможно для представления в виде потоков связей).
5.3.3.5. Сравнительный анализ подходов к интегральному анализу данных мониторинга ИБ зарубежных систем
Сравнительный анализ подходов к интегральному анализу данных мониторинга ИБ зарубежных систем показывает, что:
– рассмотренные системы, реализующие подходы к интегральному анализу данных мониторинга, имеют либо распределенную, либо клиент- серверную архитектуру. Вид архитектуры зависит от источников данных мониторинга: если источниками данных мониторинга являются уже сформированные базы данных, файлы и т. д. (нет необходимости в сборе данных мониторинга), то подход к интегральному анализу реализуется на основе клиент-серверной архитектуры;
– наблюдаемыми объектами для интегрально анализа данных мониторинга, как правило, являются пользователи и элементы наблюдаемых автоматизированных систем. Исключение составляет система VisualLinks, в которой имеется возможность задания типов наблюдаемых объектов в зависимости от области применения данного средства;
– интегральный анализ данных мониторинга выполняется в три этапа: сбор данных мониторинга (включает в себя непосредственный съем информации, ее консолидацию и агрегацию), анализ (сигнатурный и статистический) и формирование отчета;
– методы, используемые при интегральном анализе данных мониторинга, как правило, ориентированы на выявление корреляции, основанной на правилах (сигнатурный анализ). Исключение составляют

системы netForensics и VisualLinks, позволяющие использовать для анализа статистический аппарат и развитую систему визуализации (только
VisualLinks);
– рассмотренные системы, реализующие подходы к интегральному анализу данных мониторинга, имеют развитые подсистемы генерации отчетов, предлагающие до несколько сотен видов отчетов (netForensics и
EnVision). Подсистемы генерации отчетов предлагают также развитый сервис визуализации (только VisualLinks).
Следует учитывать, что характерными недостатками систем являются: отсутствие локализации, отсутствие эксплуатационной документации на русском языке, высокая стоимость и сложность настройки и технической поддержки.
5.3.3.6. Обоснования выбора систем мониторинга отечественного производства [21]
Системы мониторинга ИБ являются одним из компонентов систем контроля защищенности информационных инфраструктур РФ.
Под стандартными продуктами понимается покупное ПО в основном западных фирм-производителей, сравнительно широко растиражированное за рубежом и получившее определенное признание в России. Некоторые из таких продуктов достаточно давно применяются и в России, например, HP
Open View. Универсальный характер ряда стандартных продуктов, в принципе, позволяет использовать их не только по прямому назначению – для целей оптимизации ИТ инфраструктуры, сетей, учета конфигураций, контроля работы сервисов и технологий, и т. п. Из-за наличия ряда хорошо отработанных решений на базе стандартных продуктов для ИТ- инфраструктур идея создать и внедрить аналогичные решения для ИБ порой кажется весьма привлекательной и даже соблазнительной. При этом по умолчанию ошибочно предполагается, что задачи в области ИБ аналогичны таким задачам, как контроль сервисов и технологий в области ИТ–
инфраструктур.
Например, при анализе одного и того же инцидента ИТ-подразделение интересуют условия его возникновения, оценка потребленного ресурса
(информационные потоки на входе и выходе, нагрузка на систему) и соотношение с имеющимися ресурсными возможностями (такими как пропускная способность каналов, производительность системы и другими), а также другие количественные оценки, позволяющие разобраться в возникшей ситуации и устранить последствия. При этом предполагается, что причина инцидента техническая или организационная, во всяком случае, злоумышленная активность не рассматривается или рассматривается в последнюю очередь.
Службу ИБ интересуют ответы хотя бы на три вопроса, связанные с этим же инцидентом:
– Какие свойства безопасности информационных активов были нарушены?

– Какой ущерб нанесен и его величина.
– Не является ли произошедший инцидент следствием злоумышленной активности?
Для ответа на эти вопросы требуется углубленный анализ предшествующих и последующих событий с целью поиска причинно- следственных связей между ними. Обеспечение информационной безопасности на основе методологического базиса агентных технологий рассмотрен, например, в [60-62]. Также необходимы подробные сведения о затронутых активах и операциях с ними, причастном персонале и т. п., т. е. обо всем, что образует контекст события-инцидента.
Ниже рассматриваются причины, препятствующие созданию решений в области ИБ на основе стандартных продуктов, в частности, причины выбора для целей контроля действий администраторов и пользователей решений, на основе разрабатываемых российских специализированных систем в противовес решениям на базе стандартных продуктов ведущих иностранных производителей [РИ]. При этом рассматривается только техническая сторона вопроса, хотя можно предположить, что экономическая сторона вопроса, при попытке решить проблему доработки стандартного импортного продукта, также окажется существенным фактором.
1. Необходимость получения событий мониторинга ИБ от
новых источников или применения новых способов сбора
(доставки) информации о событиях (специализированных
интерфейсов, нетиповых протоколов).
В разрабатываемых российских системах мониторинга ИБ возможность подключения новых источников данных решается в рамках функционального развития этих систем после согласования Заказчиком предлагаемых решений.
Реализовать подобные решения в стандартных импортных продуктах можно силами подрядных организаций за счет создания ПО так называемых
«адаптеров», выполняющих функции конвертирования событий мониторинга
ИБ из журналов ИС (т.е. новых источников) во внутренний формат продукта.
Как правило, стандартные импортные продукты предоставляют возможности написания адаптеров, публикуя для этого API, однако, при создании адаптера для журналов конкретной системы предоставленных возможностей может оказаться недостаточно и возникнет необходимость привлечения производителя продукта. Однако в силу разных причин создать новые адаптеры невозможно.
Проблема получения информации от новых источников в условиях
России, когда используется покупное ПО, разработанное с учетом западных стандартов, весьма актуальна. И особенно это актуально для продуктов, применяемых в области ИБ, поскольку по Российскому законодательству в некоторых областях, например, связанных с криптографией, использовать зарубежные аппаратные средства и ПО просто нельзя. В стандартных продуктах не предусмотрена возможность импорта и анализа регистрационных журналов от российских средств ИБ.

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

импортных продуктов, поскольку приводит к необходимости формирования нужных для контроля событий средствами этого продукта. Здесь единственной возможностью для получения событий мониторинга ИБ является перехват системных вызовов.
Возможность доработки стандартных импортных продуктов в части формирования новых событий, не генерируемых штатными средствами регистрации ОС и приложений, ограничена. Кроме того, в подавляющем большинстве случаев, при необходимости контроля приложений ИС, не формирующих собственных регистрационных журналов, требуется участие разработчиков стандартного продукта.
4. Необходимость в специализированных средствах
анализа и генерации отчетов, потребности их доработки,
переработке и оптимизации.
При использовании специализированных средств разрабатываемых российских систем мониторинга ИБ такая оптимизация или доработки предусматриваются в рамках сопровождения или функционального развития.
Возможности анализа и отчетности в стандартных продуктах также ограничены. Доработка или адаптация видов отчетности по пожеланиям
Заказчика требуют участия разработчиков и вряд ли возможны.
5. Необходимость защиты данных мониторинга от таких
угроз как:
– действия администраторов по отключению процессов, осуществляющих сбор данных о событиях мониторинга ИБ;
– модификация, уничтожение данных о событиях мониторинга ИБ;
– подмена актуальных данных данными, сформированными ранее.
В системах контроля действий администраторов и пользователей отечественной разработки возможна реализация комплекса мер противодействия данным угрозам.
Кроме того, в отечественных разработках систем указанного класса
(например, ПАО «Информзащита» – г. Москва, НПФ «Кристалл» – г. Пенза) проектные решения предусматривают децентрализованный сбор данных мониторинга ИБ, т. е. имеется возможность за счет автономной работы средств сбора осуществлять контроль действий пользователей выделенных объектов или их групп.
5.3.3.7. Единая система мониторинга информационной безопасности
НПФ «Кристалл» (г. Пенза)
Среди российских кампаний, ведущих разработки в данном направлении можно выделить НИЦ «Информзащита» (г. Москва) и НПФ «Кристалл» (г.
Пенза). Рассмотрим подходы к реализации интегрального мониторинга ИБ на примере единой системы мониторинга информационной безопасности для территориальных отделений Банка России (ЕСМИБ ТУ) НПФ «Кристалл»
[44].
ЕСМИБ ТУ предназначена для автоматизации контроля выполнения требований нормативных и иных документов Банка России по