О мониторинге информационной безопасности объектов критической информационной инфраструктуры

Эксперты компании «Информационные системы и аутсорсинг» провели анализ состава параметров объектов критической информационной инфраструктуры и возникающих в них событий, контроль которых необходим для выявления инцидентов информационной безопасности.

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

Реализацию указанных процессов при обеспечении безопасности объектов критической информационной инфраструктуры (ОКИИ) Российской Федерации обеспечивает государственная система обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации (ГосСОПКА). При этом процессы выявления инцидентов информационной безопасности и реагирования на них, включая состав анализируемых параметров системы и возникающих в ней событий, разрабатываются участниками ГосСОПКА самостоятельно с учетом отраслевой специфики, особенностей функционирования конкретных ОКИИ и разработанных национальным координационным центром по компьютерным инцидентам (НКЦКИ) методических рекомендаций.

Анализ требований [1] к составу передаваемой в ГосСОПКА информации о выявленных в ОКИИ инцидентах информационной безопасности и полей разработанного НКЦКИ формата представления информации об инциденте [2] позволяет сделать вывод о том, что в качестве инцидентов рассматриваются последствия:

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

Исходя из описания перечисленных инцидентов для их выявления необходимо проводить постоянный автоматизированный сбор и анализ событий (на основе правил корреляции), поступающих из средств анализа сетевого трафика, обнаружения (предотвращения) атак, антивирусной защиты и поведенческого анализа программного обеспечения, использующих сигнатурные методы анализа и методы машинного обучения [3].

Недостаток описанного подхода состоит в том, что в качестве инцидентов не рассматриваются последствия сбоев в программных и/или аппаратных компонентах системы, вызванные в том числе воздействием внешних факторов (отказами систем кондиционирования, электропитания и др.). Такие сбои в сочетании с недостатками в архитектуре или настройках системы в целом или отдельных ее компонентов часто приводят к нарушению или существенному снижению эффективности их функционирования. В этом случае события, связанные с развитием инцидента, принципиально не могут быть зарегистрированы по результатам анализа сетевого трафика или анализа поведения программных компонентов антивирусными средствами. В результате инцидент может быть обнаружен не сразу и только по косвенным признакам (например, жалобам пользователей на снижение быстродействия), а его локализация и устранение последствий при отсутствии априорной информации об отказах в некоторых случаях может занять значительное время, что особенно критично для ОКИИ.

С целью устранения указанного недостатка предлагается дополнить категорию событий «Нарушение или замедление работы контролируемого информационного ресурса (availability)» типом события «Отказ аппаратных/программных компонентов ОКИИ (software/hardware fault)», которое по своей сути является инцидентом типа «отказ в обслуживании», не связанным с проведением атак [4]. Для обеспечения возможности выявления данного типа инцидентов информационной безопасности в качестве источников событий для их последующего анализа следует применять автоматизированные системы мониторинга (сбора и анализа событий) инфраструктуры ОКИИ, позволяющие контролировать:

  • текущие и усредненные значения параметров производительности (загрузку CPU, RAM, накопителей, операции чтения/записи, скорость передачи данных и др.);
  • статус аппаратных компонентов (состояние сетевых интерфейсов, блоков питания, вентиляторов и др.);
  • изменения конфигурационных файлов;
  • изменения версий программного обеспечения.

Контроль указанных параметров может осуществляться путем взаимодействия с агентами системы мониторинга, устанавливаемыми в совместимых операционных системах, или с использованием протокола SNMP: активного опроса устройств (серверов, телекоммуникационного оборудования, межсетевых экранов и др.) или обработки асинхронных уведомлений (trap), генерируемых устройствами.

Состав конкретных контролируемых параметров и событий должен формироваться на этапе инвентаризации ОКИИ с учетом как технических возможностей применяемых в них программных и аппаратных средств (версий системного и прикладного программного обеспечения, поддерживаемых протоколов и пр.), так и возможностей используемых систем мониторинга. В качестве примера можно привести особенности использования протокола SNMP для мониторинга телекоммуникационного оборудования: состав и коды (OID) передаваемых в сообщениях SNMP событий определяются базами MIB и отличаются на устройствах разных производителей. В этом случае по результатам инвентаризации должны быть подготовлены совместимые с применяемой системой мониторинга описания параметров и событий и их сопоставление с кодами событий (OID), передаваемых в сообщениях SNMP.

Стоит отметить, что при выборе системы мониторинга (сбора событий) должны быть учтены ее возможности по автоматизированной нормализации всех регистрируемых событий: они должны передаваться для дальнейшей регистрации и анализа (например, в SIEM-систему) в заранее определенном формате.

Предложенная модификация известного [3] подхода к разработке процессов выявления инцидентов информационной безопасности и реагирования на них позволит:

  1. своевременно выявлять сбои в программных и/или аппаратных компонентах системы, приводящие к возникновению инцидентов типа «отказ в обслуживании», не связанных с реализацией атак;
  2. разрабатывать более точные и надежные правила корреляции за счет увеличения общего числа анализируемых параметров систем и возникающих событий (учета дополнительных признаков атак, таких как аномальное изменение параметров производительности устройств, изменения их конфигурации и др.) и тем самым снизить количество ложных срабатываний;
  3. увеличить объем данных о состоянии ОКИИ в момент выявления инцидента для их всестороннего анализа и установления причин инцидента на этапе реагирования, в том числе с привлечением экспертов НКЦКИ;
  4. по результатам проведенной инвентаризации ОКИИ осуществить обоснованный подбор технических решений (систем сбора событий, SIEM-систем и др.), соответствующих всем требованиям, предъявляемым к выявлению инцидентов, и учитывающих специфику функционирования конкретных ОКИИ.

Однако стоит учесть, что в случае привлечения экспертов НКЦКИ или иных организаций к анализу инцидента передаваемая в ГосСОПКА дополнительная информация, которая может включать конфиденциальные сведения об ОКИИ, должна в обязательном порядке иметь ограничительный маркер TLP [2, 5]. Для этого указанный маркер, который по умолчанию имеет значение «TLP:WHITE» («Распространение сведений не ограничено»), в случае необходимости может быть заранее присвоен определенным параметрам или событиям, регистрируемым системой мониторинга. Его наличие или отсутствие должно учитываться автоматизированной системой регистрации инцидентов при формировании карточки инцидента и ее отправке в ГосСОПКА: если карточка содержит дополнительные данные с маркером TLP, то значение маркера карточки должно соответствовать максимальному значению маркера приложенных данных.

Таким образом, для своевременного выявления инцидентов информационной безопасности в ОКИИ и оперативного реагирования на них в состав контролируемых параметров и событий должны входить:

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

Для их сбора, предварительного анализа и нормализации в состав системы мониторинга помимо автоматизированных средств анализа информации (средств обнаружения атак, SIEM-систем и др.) и регистрации инцидентов должны входить автоматизированные средства контроля параметров программных и аппаратных компонентов инфраструктуры ОКИИ и связанных с их функционированием событий.

 

Список источников

[1] Приказ ФСБ России от 24.07.2018 № 367 «Об утверждении Перечня информации, представляемой в государственную систему обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации и Порядка представления информации в государственную систему обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации».

[2] Состав технических параметров компьютерного инцидента, указываемых при представлении информации в ГосСОПКА, и форматы представления информации о компьютерных инцидентах – https://safe-surf.ru/specialists/article/5252/638030/

[3] Дрюков В. Управление инцидентами и событиями информационной безопасности – https://safe-surf.ru/specialists/article/5236/611719/

[4] ГОСТ Р ИСО/МЭК ТО 18044-2007 «Информационная технология. Методы и средства обеспечения безопасности. Менеджмент инцидентов информационной безопасности».

[5] Traffic Light Protocol (TLP). FIRST Standards Definitions and Usage Guidance — Version 1.0 – https://www.first.org/tlp/docs/tlp-v1.pdf






Заказать обратный звонок

Вы можете заказать обратный звонок или позвонить
по телефону 8-800-200-7932






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

Я согласен на предоставление мне информации посредством электронной почты, телефонных обращений, sms-сообщений, направления почтовой корреспонденции.

Согласие предоставляется с момента оформления настоящего обращения и действует в течение 5 (пяти) лет. Согласие может быть отозвано путем подачи в isoit.ru заявления об отзыве согласия.






Заказать обратный звонок

Вы можете заказать обратный звонок или позвонить
по телефону 8-800-200-7932