Эксперты компании «ГК ИСА» провели анализ состава параметров объектов критической информационной инфраструктуры и возникающих в них событий, контроль которых необходим для выявления инцидентов информационной безопасности.
Одним из наиболее эффективных путей предупреждения нарушения устойчивого функционирования информационных/автоматизированных систем и/или нарушения конфиденциальности, целостности и доступности обрабатываемой в них информации является постоянный контроль (мониторинг) их состояния и поступающих в систему данных с целью своевременного выявления инцидентов информационной безопасности, связанных в том числе с реализацией компьютерах атак, и оперативного реагирования на них.
Реализацию указанных процессов при обеспечении безопасности объектов критической информационной инфраструктуры (ОКИИ) Российской Федерации обеспечивает государственная система обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации (ГосСОПКА). При этом процессы выявления инцидентов информационной безопасности и реагирования на них, включая состав анализируемых параметров системы и возникающих в ней событий, разрабатываются участниками ГосСОПКА самостоятельно с учетом отраслевой специфики, особенностей функционирования конкретных ОКИИ и разработанных национальным координационным центром по компьютерным инцидентам (НКЦКИ) методических рекомендаций.
Анализ требований [1] к составу передаваемой в ГосСОПКА информации о выявленных в ОКИИ инцидентах информационной безопасности и полей разработанного НКЦКИ формата представления информации об инциденте [2] позволяет сделать вывод о том, что в качестве инцидентов рассматриваются последствия:
- преднамеренных атак, проводимых с использованием каналов связи;
- внедрения вредоносного программного обеспечения;
- неосторожных или неквалифицированных действий персонала, ограниченных случаем непреднамеренного отключения ОКИИ.
Исходя из описания перечисленных инцидентов для их выявления необходимо проводить постоянный автоматизированный сбор и анализ событий (на основе правил корреляции), поступающих из средств анализа сетевого трафика, обнаружения (предотвращения) атак, антивирусной защиты и поведенческого анализа программного обеспечения, использующих сигнатурные методы анализа и методы машинного обучения [3].
Недостаток описанного подхода состоит в том, что в качестве инцидентов не рассматриваются последствия сбоев в программных и/или аппаратных компонентах системы, вызванные в том числе воздействием внешних факторов (отказами систем кондиционирования, электропитания и др.). Такие сбои в сочетании с недостатками в архитектуре или настройках системы в целом или отдельных ее компонентов часто приводят к нарушению или существенному снижению эффективности их функционирования. В этом случае события, связанные с развитием инцидента, принципиально не могут быть зарегистрированы по результатам анализа сетевого трафика или анализа поведения программных компонентов антивирусными средствами. В результате инцидент может быть обнаружен не сразу и только по косвенным признакам (например, жалобам пользователей на снижение быстродействия), а его локализация и устранение последствий при отсутствии априорной информации об отказах в некоторых случаях может занять значительное время, что особенно критично для ОКИИ.
С целью устранения указанного недостатка предлагается дополнить категорию событий «Нарушение или замедление работы контролируемого информационного ресурса (availability)» типом события «Отказ аппаратных/программных компонентов ОКИИ (software/hardware fault)», которое по своей сути является инцидентом типа «отказ в обслуживании», не связанным с проведением атак [4]. Для обеспечения возможности выявления данного типа инцидентов информационной безопасности в качестве источников событий для их последующего анализа следует применять автоматизированные системы мониторинга (сбора и анализа событий) инфраструктуры ОКИИ, позволяющие контролировать:
- текущие и усредненные значения параметров производительности (загрузку CPU, RAM, накопителей, операции чтения/записи, скорость передачи данных и др.);
- статус аппаратных компонентов (состояние сетевых интерфейсов, блоков питания, вентиляторов и др.);
- изменения конфигурационных файлов;
- изменения версий программного обеспечения.
Контроль указанных параметров может осуществляться путем взаимодействия с агентами системы мониторинга, устанавливаемыми в совместимых операционных системах, или с использованием протокола SNMP: активного опроса устройств (серверов, телекоммуникационного оборудования, межсетевых экранов и др.) или обработки асинхронных уведомлений (trap), генерируемых устройствами.
Состав конкретных контролируемых параметров и событий должен формироваться на этапе инвентаризации ОКИИ с учетом как технических возможностей применяемых в них программных и аппаратных средств (версий системного и прикладного программного обеспечения, поддерживаемых протоколов и пр.), так и возможностей используемых систем мониторинга. В качестве примера можно привести особенности использования протокола SNMP для мониторинга телекоммуникационного оборудования: состав и коды (OID) передаваемых в сообщениях SNMP событий определяются базами MIB и отличаются на устройствах разных производителей. В этом случае по результатам инвентаризации должны быть подготовлены совместимые с применяемой системой мониторинга описания параметров и событий и их сопоставление с кодами событий (OID), передаваемых в сообщениях SNMP.
Стоит отметить, что при выборе системы мониторинга (сбора событий) должны быть учтены ее возможности по автоматизированной нормализации всех регистрируемых событий: они должны передаваться для дальнейшей регистрации и анализа (например, в SIEM-систему) в заранее определенном формате.
Предложенная модификация известного [3] подхода к разработке процессов выявления инцидентов информационной безопасности и реагирования на них позволит:
- своевременно выявлять сбои в программных и/или аппаратных компонентах системы, приводящие к возникновению инцидентов типа «отказ в обслуживании», не связанных с реализацией атак;
- разрабатывать более точные и надежные правила корреляции за счет увеличения общего числа анализируемых параметров систем и возникающих событий (учета дополнительных признаков атак, таких как аномальное изменение параметров производительности устройств, изменения их конфигурации и др.) и тем самым снизить количество ложных срабатываний;
- увеличить объем данных о состоянии ОКИИ в момент выявления инцидента для их всестороннего анализа и установления причин инцидента на этапе реагирования, в том числе с привлечением экспертов НКЦКИ;
- по результатам проведенной инвентаризации ОКИИ осуществить обоснованный подбор технических решений (систем сбора событий, 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
