Мошак_Птицына_ Учебное пособие. Федеральное государственное бюджетное образовательное учреждение высшего образования санктпетербургский
 Скачать 3.09 Mb.
|
|
ИСТОЧНИКИ ДАННЫХ ИЗВЛЕЧЕНИЕ, ПРЕОБРАЗОВАН ИЕ, ЗАГРУЗКА ДАННЫХ ХРАНИЛИЩЕ ДАННЫХ АНАЛИТИЧЕСКИЕ ТЕХНОЛОГИИ АНАЛИТИКИ МНОГОМЕРНЫЙ АНАЛИЗ (OLAP) ПОИСК ЗАКОНОМЕРНОСТЕЙ (DATA MINING) АРМ АНАЛИТИКА АРМ АНАЛИТИКА ВИЗУАЛЬНЫЙ АНАЛИЗ АНАЛИЗ НЕСТРУКТУРИРОВАННОЙ ИНФОРМАЦИИ Рис.5.2. Подход к интегральному анализу данных системы VisualLinks По мнению организации, традиционные методы Data Mining эффективно работают на этапе первичного отбора информации, содержащей признаки правонарушений (преступлений и административных правонарушений). Технологии OLAP обеспечивают аналитикам возможность исследовать большие объемы взаимосвязанных данных при помощи быстрого интерактивного их отображения на разных уровнях детализации с различных точек зрения в соответствии с представлениями конечного пользователя. Наряду с Data Mining, технологии OLAP позволяют определить направление детального исследования информации с помощью инструментов визуального анализа данных. 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]. ЕСМИБ ТУ предназначена для автоматизации контроля выполнения требований нормативных и иных документов Банка России по информационной безопасности (ИБ) на объекте автоматизации пользователями автоматизированных систем (АС), в том числе в рамках проведения процедур внутреннего контроля уровня территориального учреждения Банка России (ТУ Банка России). ЕСМИБ ТУ является трех уровневой системой и состоит из следующих подсистем (рис.5.3.): а) Первый уровень мониторинга ИБ – уровень сбора первичных событий мониторинга и контроля отчуждения информации: – подсистема сбора первичных событий мониторинга (далее по тексту – подсистема сбора данных); – подсистема контроля отчуждения информации (далее по тексту – подсистема контроля отчуждения); б) Второй уровень мониторинга ИБ – уровень формирования сообщений о событиях ИБ: – подсистема анализа и формирования сообщений о событиях ИБ (далее по тексту – подсистема анализа); – подсистема хранения событий ИБ; – подсистема информирования о событиях ИБ (далее по тексту – подсистема информирования); – подсистема расследования событий ИБ (далее по тексту – подсистема расследования); в) Третий уровень мониторинга ИБ – уровень формирования и обработки КСИБ: – подсистема идентификации КСИБ; – подсистема импорта исходных данных; – подсистема обработки КСИБ; – подсистема хранения и резервирования КСИБ; – подсистема подготовки отчетов по КСИБ; – подсистема централизованного обновления базы требований документов Банка России по ИБ. Подсистема сбора данных предназначена для автоматизированного сбора первичных событий мониторинга из журналов ШПРС подконтрольных объектов, а также их регистрации. Подсистема анализа предназначена для автоматизированного анализа первичных событий мониторинга (входных данных) из журналов ШПРС подконтрольных объектов и формирования сообщений о событиях ИБ по заданным правилам с целью оценки степени их влияния на ИБ объекта автоматизации. Подсистема контроля отчуждения предназначена для фиксации первичных событий мониторинга о работе персонала объекта автоматизации со съемными периферийными устройствами на подконтрольных объектах, работающих под управлением ОС Microsoft Windows. ЕСМИБ ТУ Второй уровень мониторинга ИБ Уровень формирования сообщений о событиях ИБ Третий уровень мониторинга ИБ Уровень формирования и обработки КСИБ Первый уровень мониторинга ИБ Уровень сбора первичных событий мониторинга и контроля отчуждения информации Подсистема контроля отчуждения информации Подсистема сбора первичных событий мониторинга Подсистема хранения событий ИБ Подсистема информирования о событиях ИБ Подсистема анализа и формирования сообщений о событиях ИБ Подсистема расследования событий ИБ Подсистема идентификации КСИБ Подсистема обработки КСИБ Подсистема подготовки отчетов по КСИБ Подсистема хранения и резервирования КСИБ Подсистема импорта исходных данных Подсистема централизованного обновления базы требований документов Банка России по ИБ Рис. 5. 3. Конфигурация ЕСМИБ ТУ Подсистема информирования предназначена для оперативного (в режиме, максимально возможно приближенном к режиму реального времени) графического представления персоналу ЕСМИБ ТУ результатов работы подсистемы анализа – информации о событиях ИБ. Подсистема расследования предназначена для автоматизации деятельности персонала в части проведения отложенного анализа и генерации отчетов о событиях ИБ, содержащихся в подсистеме хранения событий ИБ. Подсистема хранения событий ИБ предназначена для хранения результатов работы подсистемы анализа в БД событий ИБ ЕСМИБ ТУ. Подсистема идентификации КСИБ предназначена для выявления КСИБ на основе правил анализа событий ИБ от разнотипных источников данных мониторинга объекта автоматизации с указанием нарушений требований нормативных и иных актов Банка России по ИБ, а также передачи КСИБ в подсистему обработки. Подсистема идентификации КСИБ включает в свой состав средства для создания, редактирования, проверки и графического представления правил анализа событий ИБ (сценариев). Подсистема импорта исходных данных предназначена для переноса информации из БД подсистемы хранения событий ИБ и получения данных о пользователях (сотрудниках ТУ) от АС ВХД для последующего использования в целях мониторинга ИБ. Подсистема обработки КСИБ предназначена для регистрации, информирования, классификации по заданным критериям и фиксирования мер по устранению последствий КСИБ в соответствии с ролевыми функциями персонала ЕСМИБ ТУ. Подсистема хранения и резервирования КСИБ предназначена для ведения оперативного архива и долговременного архива КСИБ, загрузки данных из долговременных архивов. Подсистема подготовки отчетов по КСИБ предназначена для автоматизированной подготовки отчетов по КСИБ с учетом задаваемых параметров (временной интервал, оценка коррелированного события ИБ, его тип и т. п.), вывода на печать и экспорта в файл отчетов, а также просмотра отчетов и контроля настроек ЕСМИБ ТУ. Подсистема централизованного обновления базы требований документов Банка России по ИБ. Основной задачей первого уровня мониторинга ИБ в ЕСМИБ (рис.5.4) является сбор от подконтрольных объектов мониторинга и представление в унифицированном внутреннем формате информации о событиях мониторинга ИС. Подконтрольный объект - совокупность технических средств, системного и прикладного программного обеспечения, а также их персонала, получение информации о состоянии и действиях которых является необходимым условием обеспечения процесса мониторинга ИБ. Состав подконтрольных объектов мониторинга определяется руководством исходя из значимости данных мониторинга ИБ для ИС организации. Главный компонент первого уровня – подсистема сбора первичных событий мониторинга предназначена для автоматизированного сбора первичных событий мониторинга из журналов подконтрольных объектов ИС. В основу работы этой подсистемы положены следующие принципы: – входными данными ЕСМИБ являются события мониторинга от разных источников, доставляемые собственными программными агентами; – собственные программные агенты формируют события мониторинга, связанные с контролем устройств и съемных машинных носителей, а также ряд других событий, необходимых для анализа; – на подконтрольные объекты не оказывается блокирующих воздействий; – собственные программные агенты работают как непосредственно в среде подконтрольных объектов (т. е. локально), так и получают события мониторинга удаленно, в зависимости от типа источника; – результатом работы первого уровня мониторинга является набор событий мониторинга в унифицированном формате представления, не зависящем от типа источника. Подсистема контроля отчуждения информации предназначена для фиксации первичных событий мониторинга о работе персонала ИС со съемными периферийными устройствами на подконтрольных объектах, работающих под управлением ОС Windows. - Подсистема регистрации событий РАБИС-НП - Автоматизированная система эмиссионных и кассовых работ - ОС Microsoft Windows - СУБД Microsoft SQL Server - СУБД Oracle - Symantec pcAnyWhere - Symantec Antivirus - Антивирус Касперского - Антивирус DrWeb - Аккорд NT/2000 - Secret Net - АПКШ «Континент» |