Обзор специальных публикаций NIST по информационной безопасности. Часть 2

С развитием цифровых технологий и проникновением ИТ во все сферы бизнеса также увеличивается соответствующее количество информационных ресурсов и вычислительных устройств, а руководство и киберспециалисты неминуемо сталкиваются со сложностями при управлении и обслуживании большого разрозненного парка ИТ-систем. Сложности и пробелы при управлении ИТ-системами являются также ощутимым киберриском: логически связанную систему киберзащиты невозможно выстроить без четкого видения и понимания, какие именно элементы ИТ-инфраструктуры предстоит защищать, а разнообразие операционных систем, бизнес-приложений, типов данных и систем защиты лишь усугубляет остроту вопроса обеспечения киберустойчивости. Для оценки и приоритизации уязвимостей, оперативного выявления актуальных киберугроз, для своевременного и качественного реагирования на киберинциденты необходимо выстроить целостную систему управления информационными активами. Данной задаче посвящена специальная публикация NIST SP 1800-5 "IT Asset Management" («Управление ИТ-активами»), которая приводит характеристики эффективного программного решения для управления активами (ITAM, IT Asset Management), а также перечисляет киберриски при отсутствующем или неполном процессе инвентаризации активов.

Итак, для решения задачи централизованного управления активами, авторы документа NIST SP 1800-5 предлагают ряд практических шагов и инструментов для построения системы управления ИТ-активами, а также приводится результат оценки киберрисков некорректного процесса инвентаризации информационных активов и отсутствующий или неполной централизованной системы управления ИТ-активами.

Стратегическими киберрисками некорректно выстроенного процесса управления ИТ-активами являются:

1. Негативное влияние на предоставление услуг ввиду возможного отсутствия доступа сотрудников к ИТ-активам;

2. Стоимость внедрения системы централизованного управления ИТ-активами, стремление к использованию единой системы во всей компании и всех системах для снижения накладных расходов;

3. Расходование бюджета применительно к инвестициям в технологии кибербезопасности;

4. Прогнозируемое сокращение затрат и операционная эффективность как результат новых инвестиций в кибербезопасность;

5. Соответствие законодательным нормам в части тщательного и оперативного контроля ИТ-активов;

6. Репутационные и имиджевые риски;

7. Риски бездействия или неверных шагов.

Тактическими киберрисками некорректно выстроенного процесса управления ИТ-активами являются:

1. Отсутствие конвергентного (объединенного) видения ИТ-активов и централизованной отчетности по ним;

2. Недостаток знаний о местоположении ИТ-активов;

3. Недостаток конфигурационных контролей для ИТ-активов;

4. Неэффективный патч-менеджмент;

5. Отсутствие управления программными уязвимостями;

6. Отсутствие общей картины работы корпоративных активов;

7. Отсутствие конвергентного репозитория ИТ-активов.

Для централизованного управления информационными активами в документе NIST SP 1800-5 рекомендуют применять системы класса ITAM (IT Asset Management, управление ИТ-активами), которые представляют собой эволюцию CMDB-систем (Configuration Management Database, база данных управления конфигурацией) для решения следующих задач:

1. Первоначальное наполнение репозитория информацией об ИТ-активах;

2. Автоматизированное обогащение и поддержание сведений об ИТ-активах в актуальном состоянии;

3. Интеграция с системами, содержащими актуальные сведения об ИТ-активах;

4. Интеграция с СЗИ для помощи в реагировании на инциденты ИБ.

Данные действия выполняются в течение всего жизненного цикла ИТ-актива, который состоит из следующих этапов:

1. Разработка стратегии жизненного цикла ИТ-актива;

2. Планирование использования ИТ-актива;

3. Разработка архитектуры и модели использования;

4. Закупка, внедрение;

5. Эксплуатация;

6. Поддержка;

7. Внесение изменений;

8. Вывод из эксплуатации.

Напомним также, что системы CMDB предназначены для хранения, обработки, поддержания в актуальном состоянии информации об активах и их взаимосвязях. Программные (например, ОС, ПО, файлы) и аппаратные (например, серверы, ПК, сетевые устройства) активы в терминологии CMDB называются CI (Configuration Items, конфигурационные единицы) и могут содержать следующую информацию:

• бизнес-владелец (business owner) актива;

• риск-владелец (risk owner) актива;

• ответственный за актив со стороны ИТ (IT custodian);

• ответственный за актив со стороны ИБ (IT Security custodian);

• пользователь актива;

• выполняемая активом бизнес-роль/функция;

• выполняемая активом техническая роль/функция;

• зависимый от актива бизнес-процесс;

• критичность, стоимость, ценность актива;

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

• местоположение (адрес, помещение, номер стойки и т.д.);

• конфигурация (FQDN-имя, версия ОС, установленное ПО, VLAN, IP-адрес, MAC-адрес, объем ОЗУ и т.д.).

Главные задачи, которые приходится решать при ведении процесса управления активами, включают в себя первоначальное наполнение информацией, обогащение и поддержание сведений в актуальном состоянии, автоматизацию процесса, интеграцию с разнообразными системами, содержащими ценную информацию об ИТ-активах. При этом некоторые решения по управлению активами дополнительно поддерживают получение актуальных данных о новых активах в сети компании, а также взаимодействуют с СЗИ в целях реагирования на несанкционированное появление нового устройства в сети (результатом реагирования может быть как проведение сканирования нового устройства, так и его временная изоляция).

С точки зрения кибербезопасности, применение ITAM-систем приносит следующие преимущества:

1. Корректный выбор и применение базовых мер защиты;

2. Непрерывный мониторинг и ведение отчетности о состоянии ИТ-актива с сохранением в едином хранилище;

3. Применение механизмов выявления аномалий (например, отклонение в сетевом трафике или от установленных параметров базовой конфигурации);

4. Снабжение контекстом и обогащение данными для выявления аномалий и событий ИБ с помощью механизмов аналитики и отчетности.

В документе NIST SP 1800-5 приводятся три функциональных уровня типовой ITAM-системы, от низшего третьего уровня (Tier 3) до высшего первого уровня (Tier 1):

1. Уровень Tier 3 включает в себя все контролируемые корпоративные активы (ПК, серверы, портативные устройства, сетевое оборудование).

2. Уровень Tier 2 содержит данные об местоположении активов, установленном на них программном и аппаратном обеспечении. На данном уровне выполняется задача сбора данных - выявление и документирование ПО и конфигураций систем каждого ИТ-актива и передача данной информации на следующий уровень для хранения.

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

В публикации NIST SP 1800-5 приводятся характеристики эффективного программного решения для управления активами (ITAM, IT Asset Management):

• дополнение существующих в компании систем учета активов, СЗИ, сетевых решений;

• API-интеграция с СЗИ (межсетевые экраны, системы обнаружения вторжений, системы управления доступом и учетными данными);

• предоставление информации и контроль подключенных к сети компании физических и виртуальных активов;

• автоматическое определение и оповещение о попытках неавторизованных устройств получить доступ к сети;

• предоставление возможности определять и контролировать аппаратное и программное обеспечение, которое авторизовано для подключения к сети компании;

• применение политик ограниченного использования ПО;

• аудит и мониторинг изменений состояния активов;

• интеграция с системами хранения и анализа журналов аудита;

• запись и отслеживание атрибутов ИТ-активов.

Наконец, в документе NIST SP 1800-5 приведено детальное описание по настройке лабораторного стенда для реализации ITAM-системы, в котором на Tier 1 работает Splunk; на Tier 2 задействованы IDS (Bro, Snort), сканер OpenVAS, WSUS-сервер, CMDB-системы AssetCentral и BelManage, система контроля конфигураций Puppet Enterprise; на Tier 3 функционируют серверы Active Directory и Email, VPN-сервер, PKI-центр сертификации.

Технологии виртуализации нашли широкое применение в последние 15 лет, однако сам принцип виртуализации был разработан 50 лет назад компанией IBM, а принципы, заложенные еще тогда, до сих пор лежат в основе современных систем виртуализации. На сегодняшний день практически все ИТ/ИБ-специалисты активно работают с теми или иными средствами виртуализации, и причина этого понятна: виртуализация позволяет использовать аппаратные вычислительные ресурсы более рационально, размещая на одном физическом сервере сразу несколько виртуальных машин, работающих зачастую с разными типами операционных систем, а добавление нового уровня абстракции при виртуализации позволяет  «развязать» аппаратную и программную платформы, что привносит дополнительную стабильность работы и упрощение администрирования. Однако, применение дополнительных технологий зачастую сопряжено с определенными угрозами информационной безопасности, что требует актуализации организационных и технических мер защиты для минимизации соответствующих киберрисков. Документ NIST SP 800-125 "Guide to Security for Full Virtualization Technologies" («Руководство по безопасности технологий виртуализации») содержит рекомендации по повышению кибербезопасности виртуальных инфраструктур, включая обеспечение защиты всех компонентов платформы виртуализации, управление административным доступом, защиту гипервизора, планирование обеспечения безопасности всех виртуальных компонент перед развертыванием. В дополнение к данной публикации, в NIST был разработан документ NIST SP 800-125A "Security Recommendations for Server-based Hypervisor Platforms" («Рекомендации по безопасности для серверных гипервизорных платформ»), в котором описаны базовые функции безопасности гипервизоров без привязки к конкретным архитектурам и платформам, и документ NIST SP 800-125B "Secure Virtual Network Configuration for Virtual Machine (VM) Protection" («Безопасная сетевая конфигурация для защиты виртуальных машин»), в котором описаны техники сетевой сегментации, обеспечения сетевой избыточности, контроль трафика с применением межсетевых экранов, мониторинг виртуальной сети для обеспечения кибербезопасности виртуальной инфраструктуры. О них мы поговорим в текущей публикации.

Итак, в публикации NIST SP 800-125 акцент делается на защите технологии полной виртуализации, full virtualization, что отличается от виртуализации приложений, application virtualization (например, виртуализация с помощью виртуальной машины Java Virtual Machine или запуск определенных приложений в «песочнице») или виртуализации операционной системы, operating system virtualization (например, при использовании технологий контейнеризации). При полной виртуализации применяется гипервизор (или монитор виртуальных машин, virtual machine monitor), который осуществляет управление гостевыми ОС (guest OS). При этом гипервизор может быть установлен непосредственно на аппаратной платформе (так называемая bare metal virtualization, например, виртуализация через VMware ESXi) или на хостовой ОС, host OS (например, виртуализация с помощью Microsoft Hyper-V). Вариант виртуализации bare metal можно считать более предпочтительным с точки зрения ИБ, т.к. применение варианта с хостовой ОС добавляет новый промежуточный уровень и новый объект для нападения - при кибератаке на хостовую ОС злоумышленники могут воспользоваться уязвимостями более широкого спектра, т.к. хостовая ОС во многих случаях представляет собой типовую ОС с дополнительными функциями и характерными уязвимостями, а специализированные ОС для bare metal-виртуализации дают атакующим меньшую поверхность атак в силу отсутствия избыточного функционала.

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

В документе NIST SP 800-125 содержатся рекомендации по повышению кибербезопасности виртуальных сред, включая следующие рекомендации по обеспечению безопасности гипервизоров:

1. Своевременная установка вендорских обновлений для гипервизоров;

2. Ограничение административного доступа к управляющим интерфейсам гипервизора с защитой каналов передачи данных в выделенном сетевом сегменте с применением криптографических средств;

3. Синхронизация времени в виртуальной инфраструктуре с доверенным источником;

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

5. Отключение сервисов буфера обмена и функции копирования файлов между гостевыми системами и хостовой ОС;

6. Использование средств мониторинга состояния безопасности гостевых ОС на уровне гипервизора для повышения надежности получаемых данных;

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

8. Мониторинг безопасности самого гипервизора с применением средств контроля целостности и анализа логов.

Для обеспечения безопасности гостевых ОС в документе NIST SP 800-125 предлагается выполнение следующих мер:

1. Применение мер защиты, рекомендованных для обычных физических систем (управление доступом, аудит, контроль подключений и т.д.);

2. Своевременная установка обновлений для гостевых ОС;

3. Обеспечение резервного копирования виртуальных дисков в соответствии с регламентом бэкапов для физических систем;

4. Отключение неиспользуемых виртуальных устройств от хостовых систем, включая накопители и сетевые адаптеры;

5. Использование отдельных учетных записей для каждой гостевой ОС;

6. Контроль соответствия виртуальных устройств гостевых ОС физическим устройствам на уровне хостовой системы.

При настройке и обеспечении кибербезопасности виртуальной инфраструктуры авторы NIST SP 800-125 рекомендуют придерживаться следующих этапов:

1. Инициализация: определение потребности в виртуализации имеющейся инфраструктуры, описание модели будущей виртуальной среды, создание высокоуровневой стратегии для внедрения систем виртуализации, разработка политики по применению средств виртуализации, определение целевых платформ и приложений для перехода на виртуализацию, описание функциональных и бизнес-требований к решению для виртуализации.

2. Планирование и разработка: определение технических требований и характеристик решения для виртуализации и сопутствующих компонент, включая методы аутентификации и криптографической защиты информации, а также последующая закупка решения.

3. Внедрение: конфигурирование оборудования для соответствия операционным и ИБ-требованиям, установка и тестирование прототипа, перевод в продуктивное использование. Также на данном этапе выполняется перенастройка средств защиты информации и подключение новых ИБ-систем для контроля создаваемой виртуальной инфраструктуры.

4. Эксплуатация и поддержка: выполнение задач кибербезопасности в виртуальной инфраструктуре, включая аудит логов, выявление кибератак, реагирование на киберинциденты.

5. Вывод из эксплуатации: при отказе от системы виртуализации и выводе ее из эксплуатации следует озаботиться сохранением информации из системы, очисткой накопителей, корректной утилизацией оборудования и систем.

В дополнение к публикации NIST SP 800-125 был выпущен документ NIST SP 800-125A "Security Recommendations for Server-based Hypervisor Platforms" («Рекомендации по безопасности для серверных гипервизорных платформ»), в котором описаны базовые функции безопасности гипервизоров:

1. Изоляция процессов виртуальных машин с использованием аппаратных функций гипервизоров, ограничением и контролем прямого доступа виртуальных машин к аппаратным компонентам;

2. Управление доступом к аппаратным устройствам с применением эмуляции, паравиртуализации, проброса устройств или с помощью виртуализируемых аппаратных компонентов;

3. Выполнение некоторых команд (называемых гипервызовами, hypercalls) от гостевых ОС непосредственно самим гипервизором (применимо только для гипервизоров с паравиртуализацией);

4. Управление жизненным циклом виртуальных машин, включая создание и управление образами виртуальных машин, контроль состояния виртуальных машин (запуск, пауза, остановка), миграция и мониторинг виртуальных машин, управление доступом администраторов, применение политик ИБ;

5. Управление платформой гипервизора: конфигурирование самого гипервизора и программного обеспечения виртуализации, включая установку виртуальных машин на гипервизоре, создание и поддержку кластеров гипервизоров, управление виртуальной сетью на гипервизоре.

В дополнение к публикации NIST SP 800-125, был также выпущен документ NIST SP 800-125B "Secure Virtual Network Configuration for Virtual Machine (VM) Protection" («Безопасная сетевая конфигурация для защиты виртуальных машин»), в котором описаны следующие способы обеспечения сетевой безопасности применительно к виртуальным инфраструктурам:

1. Сетевая сегментация: изоляция виртуальных хостов, применение виртуальных коммутаторов и межсетевых экранов, использование VLAN (виртуальных сетей), применение оверлейных виртуальных сетей для повышения масштабируемости и гибкости;

2. Обеспечение сетевой избыточности путем создания группы сетевых адаптеров на виртуализированном хосте;

3. Контроль трафика с применением межсетевых экранов: применение физических межсетевых экранов, виртуальных файрволлов на уровне подсетей, виртуальных файрволлов на уровне ядра гипервизора;

4. Мониторинг виртуальной сети для обеспечения кибербезопасности виртуальной инфраструктуры, с применением виртуальных сетевых адаптеров с зеркалированием траффика или виртуальных коммутаторов для отправки трафика на выделенный порт для мониторинга.

Выше мы обсудили защиту технологий виртуализации в соответствии с рекомендациями специальной публикации NIST SP 800-125. При этом мы отмечали, что применение технологий виртуализации широко распространено в современных ОС, что позволяет предоставить безопасный, гибкий, автоматизируемый способ развертывания и запуска новых приложений, которые работают независимо и изолированно друг от друга благодаря технологии контейнеризации приложений. Текущей же темой является специальная публикация NIST SP 800-190 "Application Container Security Guide" («Руководство по безопасности контейнеризованных приложений»), в которой описаны угрозы информационной безопасности при использовании технологий контейнеризации приложений и приводятся рекомендации по способам их нейтрализации.

В отличие от технологии полной виртуализации, при которой гипервизор управляет набором виртуализированных операционных систем, технология контейнеризации подразумевает создание для приложений виртуальной среды, в которой доступны только выделенные ресурсы ОС и данные самого приложения, при этом данные других приложений, которые работают на той же ОС, недоступны. В технологиях контейнеризации приложений также используется микросервисный подход, при котором создается набор контейнеров, содержащих несколько компонентов (сервисов) для функционирования одного приложения. Такое дробление обеспечивает гибкость и масштабируемость разработки и развертывания приложений, поскольку позволяет распределить и при необходимости реплицировать сервисы между разными приложениями, а независимость сервисов дает возможность использовать разные языки программирования и фреймворки при их создании. В отличие от виртуализации, где каждая виртуальная машина имеет свой жизненный цикл (т.е. может быть изменена или переконфигурирована), контейнеры существуют в неизменном состоянии, а при необходимости произвести модификацию контейнер удаляется и создается новый с требуемыми характеристиками; при этом все необходимые файлы для запуска контейнеризованных приложений хранятся в образах контейнеров (англ. container images). Аналогичный подход применяется и при работе контейнеров с данными: контейнеры не содержат необходимых данных внутри себя, вместо этого они обращаются к независимым хранилищам информации, которые не меняются при замене контейнера. При работе с контейнерами к хостовым ОС предъявляются некоторые требования, обеспечивающие работу контейнеризации, такие как изоляция пространства имен (недоступность файловой системы, сетевых интерфейсов, процессов одного контейнера для обращения из другого контейнера), выделение ресурсов (возможность задать определенные аппаратные характеристики для каждого контейнера), виртуализация файловой системы (дедупликация исполняемых контейнерами файлов, сохранение изменений с доступом к новым данным только для контейнера-инициатора).

Архитектура технологий контейнеризации состоит из пяти уровней:

1. Системы разработки, использующиеся для создания образов контейнеров и отправки их на тестирование и аккредитацию;

2. Системы тестирования и аккредитации, проверяющие и подписывающие содержимое образов контейнеров, с дальнейшей отправкой в реестр образов;

3. Реестры образов контейнеров, хранящие и передающие данные образы по запросу оркестратора;

4. Оркестраторы, конвертирующие образы в контейнеры и разворачивающие контейнеры на хостах;

5. Хосты, запускающие и останавливающие контейнеры по команде оркестратора.

Фазы жизненного цикла контейнера состоят из 3 этапов:

1. Создание, тестирование, аккредитация образа: компоненты контейнеризируемого приложения собираются и размещаются в образе контейнера. Создание образов выполняется с помощью инструментов автоматизации и управления созданием (например, Jenkins, TeamCity). Тестирование выполняется для проверки функциональности полученного образа, а аккредитация осуществляется силами команды кибербезопасности после проверки образа.

2. Хранение и получение образа: образы хранятся в централизованных репозиториях - реестрах образов, выполняющих также версионный контроль, тэгирование, каталогизацию. Реестры могут быть внутренними и внешними (например, Docker Hub, Google Container Registry).

3. Развертывание и управление контейнерами: данный этап выполняется оркестраторами (например, Kubernets, Docker Swarm) - программными инструментами для получения образов контейнеров из реестров, развертывания в контейнерах, управления запущенными контейнерами. При развертывании образа в контейнере сам образ остается неизменным, а его копия размещается внутри контейнера и запускается. Оркестратор отвечает за управление контейнерами - контроль состояния, перезапуск в случае ошибки, управление сетевым взаимодействием контейнеров. При обновлении приложения, свежая версия попадает в реестр образов, а оркестратор получает новый образ контейнера и замещает им предыдущий. При этом в небольших инфраструктурах оркестратора может не существовать, а хост будет сам запрашивать образ контейнера из реестра и управлять им.

В документе NIST SP 800-190 также приведен список указанных ниже киберрисков для различных аспектов технологии контейнеризации с указанием контрмер для их минимизации.

1. Киберриски образов контейнеров

1.1. Уязвимости в образах: при наличии уязвимости в образе, данная уязвимость «перекочует» в развернутый контейнер; при этом при первоначальном развертывании ПО в образе может не иметь известных уязвимостей, однако со временем уязвимости с высокой долей вероятности будут найдены и проэксплуатированы атакующими. Контрмерами будут интеграция процессов и инструментов контроля отсутствия уязвимостей на всех этапах жизненного цикла образов, обработка уязвимостей на всех уровнях образа (включая фреймворки и прикладное ПО), применение политик соответствия публикуемых приложений внутренним правилам контроля отсутствия уязвимостей.

1.2. Недостатки конфигурации: при использовании недостаточно безопасных настроек в образе, соответствующий контейнер будет уязвим перед атакующими, использующими данные слабости в конфигурации. Контрмерами могут стать проверка конфигураций на соответствие рекомендациям вендоров и лучших практик, непрерывный процесс контроля соответствия образов внутренним требованиям, запрет на запуск несоответствующих требованиям образов, использование только доверенных базовых компонент для создания образов.

1.3. Встроенное вредоносное ПО: при использовании недостаточно проверенных компонент в образе, вредоносный код может скомпрометировать контейнер или хостовую ОС. Контрмеры включают в себя сигнатурное и поведенческое выявление признаков наличия вредоносного ПО.

1.4. Встроенные секреты/пароли, хранящиеся в открытом виде: при создании образа разработчики могут включить в него пароли в открытом виде, закрытые ключи шифрования, строки подключения, API-ключи и т.д., что позволит любому, имеющему доступ к образу, получить эти сведения. Для минимизации данного риска современные оркестраторы предлагают защищенные хранилища секретов, также можно использовать решения сторонних производителей для защищенного хранения аутентификационной информации.

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

2. Киберриски реестров

2.1. Небезопасное подключение к реестрам: при использовании незащищенных каналов связи риску подвергаются как сами передающиеся образы, так и учетные данные администраторов и разработчиков, используемые для подключения к реестрам. Для минимизации этого риска следует применять защищенные каналы связи, обеспечивающие защиту данных при передаче, а также аутентификацию конечных точек при установке связи.

2.2. Устаревшие образы в реестрах: при хранении в реестрах устаревших образов с известными уязвимостями повышается вероятность того, что они будут развернуты в контейнерах. Контрмерами будут очистка реестров от старых образов и использование указания версии при именовании образов.

2.3. Недостаточные ограничения аутентификации и авторизации: при недостаточных требованиях к аутентификации и авторизации (слабые пароли или их отсутствие) риску подвергается как информация внутри образов, так и сами образы, которые могут быть подменены на вредоносные. Для защиты следует применять аутентификацию всех субъектов доступа, а также принцип разграничения полномочий и минимизации привилегий, с логированием и аудитом всех событий записи в реестры.

3. Киберриски оркестраторов

3.1. Неограниченный административный доступ: есть права администрирования предоставлены недостаточно гранулированно, то администраторы оркестраторов могут случайно или намеренно внести изменения в сторонние контейнеры. В качестве контрмеры можно применять модель разграничения доступа, предоставляемую оркестратором.

3.2. Неавторизованный доступ: оркестраторы зачастую используют встроенные механизмы аутентификации, что может привести к применению более простой парольной политики или появлению устаревших учетных записей. Контрмерами будет использование мультифакторной аутентификации администраторов, применение концепции единого входа (англ. single sign-on), а также шифрования данных в контейнерах.

3.3. Недостаточное разграничение сетевого межконтейнерного трафика: в системах контейнеризации трафик между контейнерами маршрутизируется через оверлейные виртуальные сети, управляемые оркестратором, что приводит к отсутствию контроля со стороны корпоративных сетевых средств защиты (например, IPS/IDS), а также чревато реализацией сетевых атак со стороны скомпрометированного контейнера в отношении соседних контейнеров, использующих ту же сеть. Для минимизации данного риска можно выделять специальные сети для передачи информации разного уровня конфиденциальности и разного назначения.

3.4. Смешение уровней конфиденциальности контейнеров: по умолчанию, оркестраторы распределяют контейнеры в зависимости от нагрузки и могут разместить на одном хосте несколько контейнеров с данными разной степени конфиденциальности, что может привести к компрометации более контейнера с более чувствительными данными после атаки на менее защищенный контейнер. Контрмерами могут стать сегментация контейнеров по цели применения, уровню чувствительности информации, модели угроз, а также ручное распределение контейнеров по разным хостам.

3.5. Доверие к ноде оркестрации: при недостаточно защищенной конфигурации оркестратора под угрозу может быть поставлен сам оркестратор и другие компоненты технологии контейнеризации, включая доверие между хостами, компрометацию всего кластера из-за одного хоста, отключение шифрования и аутентификации при передаче данных между администраторами и хостами. Контрмерами названы применение оркестраторов, устойчивых к компрометации одной ноды без риска для всего кластера, способных обеспечить изоляцию скомпрометированного объекта.

4. Киберриски контейнеров

4.1. Уязвимости в ПО контейнера: при уязвимостях, позволяющих атакующим выполнить «побег из контейнера» (англ. container escape), безопасность всего хоста и всех контейнеров на нем будет поставлена под угрозу. В качестве контрмеры следует применять процедуры процесса управления уязвимостями ко всем приложениям и компонентам контейнеров.

4.2. Неограниченный сетевой доступ из контейнеров: при компрометации контейнера и отсутствии должных мер ограничения сетевого контейнерного трафика, атакующие могут производить сетевые атаки, направленные на соседние контейнеры и сам хост. Для минимизации данного риска следует применять инструменты контроля сетевого доступа, оптимизированные для работы с контейнерами, которые позволяют идентифицировать контекст сетевого подключения и выявить аномалии в трафике.

4.3. Небезопасные конфигурации контейнеров: при отсутствии разграничения на выполнение высокопривилегированных команд из контейнеров, хостовая ОС и соседние контейнеры могут быть скомпрометированы. Контрмерами будут применение вендорских рекомендаций по конфигурированию контейнеров, применение встроенных в ОС инструментов управления доступом, примените Linux-профилей seccomp для ограничения возможностей контейнеров повлиять на ОС.

4.4. Уязвимости в контейнеризованных приложениях: при обнаружении уязвимости в приложении, которое было размещено в контейнере, последствия от ее эксплуатации могут включать в себя компрометацию хостовой ОС и других контейнеров. Для минимизации данного риска можно применять специализированные инструменты, позволяющие выстроить поведенческие профили для контейнеризованных приложений, с возможностью выявлять и реагировать на аномалии.

4.5. Избыточные контейнеры: при несанкционированном или незапланированном размещении контейнера к нему могут не применяться строгие конфигурационные ограничения и проверки на отсутствие уязвимостей. Данный риск купируется организационными мерами, регламентирующими использование различных сред для разработки, тестирования, эксплуатации.

5. Киберриски хостовых ОС

5.1. Широкая поверхность атаки: при доступности контейнеров из интернет актуальна угроза компрометации хостовой ОС или контейнеров в ней. Контрмерой будет применение специализированных минималистичных ОС, оптимизированных для размещения контейнеров.

5.2. Разделяемое ядро ОС: при работе контейнеров они получают доступ к некоторым компонентам ядра хостовой ОС, что может привести к ее компрометации. Для исключения данного сценария не следует контейнеризованные и неконтейнеризованные приложения на одном хосте.

5.3. Уязвимости компонент хостовой ОС: при эксплуатации уязвимостей компонент хостовой ОС, могут быть скомпрометированы контейнеры и приложения, запущенные на ней. Применение процесса управления уязвимостями к хостовой ОС, с размещением в контейнере обновленных компонент ОС со всеми разрешенными зависимостями, послужит контрмерой.

5.4. Некорректно настроенные права доступа: при предоставлении пользователю возможности вручную управлять контейнерами минуя уровень оркестратора, под угрозу может быть поставлена работоспособность других контейнеров на хостовой ОС. В ответ следует контролировать все попытки аутентификации, выявлять аномалии при входе пользователей, проверять попытки повышения привилегий.

5.5. Подмена объектов файловой системы хостовой ОС: при некорректной конфигурации контейнеру может быть предоставлено право изменения объектов файловой системы хостовой ОС, что может привести к компрометации самой хостовой ОС и всех контейнеров на ней. В качестве контрмеры следует применять инструменты контроля попыток изменения объектов файловой системы хоста.

С ростом количества кибератак в середине 2010-х годов киберсообщество пришло к логичному выводу: невозможно предотвратить все киберинциденты, поскольку арсенал и возможности атакующих непрерывно совершенствуются, а защитные меры зачастую не успевают адаптироваться под постоянно меняющийся ландшафт киберугроз. За этим последовал неутешительный вывод: стратегии защиты, обнаружения и предотвращения киберугроз были к тому моменту описаны и изучены уже достаточно подробно, чего нельзя было утверждать про планы по восстановлению после киберинцидентов, которые были разрознены и фрагментарно сформулированы в различных документах и рекомендациях. Как итог, институт NIST в конце 2016 года разработал документ NIST SP 800-184 "Guide for Cybersecurity Event Recovery" («Руководство по восстановлению после киберинцидентов»), в которым были описаны рекомендации по обеспечению непрерывности бизнеса и восстановлению работоспособности после киберинцидентов, включая разработку планов, инструкций, плейбуков реагирования и восстановления, а также перечислены метрики оценки эффективности процесса восстановления после кибератаки. С этим документом мы и ознакомимся в настоящей публикации.

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

Фаза планирования восстановления после киберинцидента играет ключевую роль в обеспечении киберустойчивости компании. Процесс планирования восстановления должен быть включен в общую систему управления ИБ и интегрироваться с другими процессами обеспечения кибербезопасности. Так, планирование восстановления позволяет выстроить взаимосвязи активов и бизнес-процессов, определить ключевые роли сотрудников, заранее договориться об альтернативных способах связи, предоставляемых сервисах и помещениях, провести what if-анализ для моделирования киберинцидентов и создания соответствующих сценариев реагирования (playbooks). В документе NIST SP 800-184 также подчеркивается, что план восстановления после киберинцидента должен быть встроен в корпоративную программу обеспечения непрерывности деятельности и восстановления работоспособности (Business Continuity, Disaster Recovery), а взаимосвязи между системами, активами и бизнес-процессами должны быть отражены в документах анализа влияния инцидентов на бизнес (Business Impact Analysis), соглашениях об уровнях оказываемых услуг или операций (Service Level Agreements/Operational Level Agreements), картах взаимозависимостей систем. Указывается также на важность инвентаризации и категоризации активов для приоритизации действий по восстановлению, на необходимость учитывать применимые технические, операционные, юридические, законодательные требования при восстановлении, а также на важность понимания границ информационных систем, отношений доверия между ними, прав доступа субъектов в инфраструктуре.

План восстановления является частью плана реагирования на киберинциденты с фокусом на восстановление после инцидента ИБ и включает в себя такие основные положения, как:

1. Соглашения об уровне оказываемых услуг (SLA) с сервис-провайдерами, оказывающими услуги по реагированию на киберинциденты (MDR, Managed Detection and Response), или MSSP-провайдерами (Managed Security Service Provider), оказывающими услуги по аутсорсингу части функций ИБ;

2. Документ с указанием контактных данных руководителей компании, которые имеют полномочия на задействование плана восстановления;

3. Документ с указанием контактных данных ответственных работников компании, которые должны выполнять действия по плану восстановления;

4. Документ с описанием детальных процедур по восстановлению информационных систем с указанием всех технических подробностей, диаграмм связности, методов активации альтернативных (запасных) способов обеспечения работоспособности зависимых бизнес-процессов;

4. Запасные способы связи и каналы коммуникации, которые могут быть использованы членами команды при выполнении действий по восстановлению, с допущением того, что основные способы связи и каналы коммуникации контролируются или подменяются атакующими;

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

6. Документ с указанием места хранения и описанием способа развёртывания резервных копий критичных данных;

7. Документ с описанием альтернативных действий при невозможности восстановить данные штатным порядком за регламентированное время;

8. Документ для оповещения сотрудников с указанием адресов резервных офисов и дата-центров при выходе из строя основных;

9. Данные об инфраструктуре, аппаратном и программном обеспечении, которые используются во время восстановления основных систем и сервисов.

В рамках описания этапа планирования восстановления после киберинцидента в документе NIST SP 800-184 приведены также следующие рекомендации:

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

2. Разработать детальные планы восстановления с приоритизацией целей восстановления и использовать данные планы для разработки процессов и процедур восстановления для своевременного восстановления элементов инфраструктуры. Планы должны содержать описание технических и организационных действий с вовлечением людей, процессов, технологий. При этом рекомендуется автоматизировать как можно большее количество процедур восстановления для ускорения и снижения количества человеческих ошибок, а достичь этого можно, например, путем использования IRP/SOAR-систем;

3. Разработать, внедрить и испытать планы с описанием процессов восстановления на основе корпоративных требований для обеспечения оперативного взаимодействия и восстановления сервисов, затронутых киберинцидентом;

4. Разработать и задокументировать условия запуска плана восстановления и перечень лиц, имеющих право на запуск плана восстановления, а также способ оповещения ответственных сотрудников, которые непосредственно будут выполнять действия по восстановлению;

5. Определить контрольные точки, в которых проверяется выполнение целей восстановления и прекращаются дальнейшие действия при достижении результата;

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

7. Разработать план коммуникации при восстановлении после киберинцидента, использовать положения данного плана в политиках и процедурах восстановления;

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

Для непрерывного улучшения процесса восстановления после киберинцидентов в документе NIST SP 800-184 рекомендуется выполнение следующих действий:

1. Выполнять сбор обратной связи о планах и процедурах восстановления от участвующих в процессе восстановления ответственных сотрудников;

2. Регулярно выполнять тренировки и тестирование процедур восстановления, документируя результаты для улучшения процесса восстановления;

3. Проводить глубокий пост-тренировочный анализ для выявления ошибок, корректировки планов и процедур восстановления, повышения уровня подготовленности сотрудников;

4. Непрерывно корректировать и улучшать политики, планы и процедуры восстановления на основе данных пост-инцидентного анализа;

5. Выявлять недостатки и слабости защиты в технологиях, процессах и сотрудниках при анализе результатов выполненных действий по восстановлению;

6. Регулярно проверять возможности процедур восстановления на основе данных от ответственных сотрудников и по результатам тренировок и тестов;

7. Тщательно документировать все сложности при восстановлении для последующего возврата к ним.

Для измерения эффективности процессов восстановления после киберинцидентов авторы публикации NIST SP 800-184 рекомендуют использовать следующие метрики:

1. Финансовый ущерб от снижения конкурентоспособности при разглашении конфиденциальной информации;

2. Штрафные санкции, судебные издержки;

3. Затраты программного и аппаратного обеспечения и стоимость человеческих ресурсов для выполнения действий по восстановлению;

4. Финансовый ущерб из-за простоя бизнес-процессов, снижения эффективности работы, незаключённых договоров;

5. Репутационный ущерб, уменьшение клиентской базы;

6. Частота и границы тестирования и обучения процедурам восстановления;

7. Количество значимых киберинцидентов, которые не были учтены при проведении оценки киберрисков;

8. Количество неучтенных активов, связей между активами;

9. Количество недостатков, выявленных при тестировании и обучении процедурам восстановления, которые можно учитывать для улучшения процессов ИБ в компании;

10. Число фактов нарушения бизнес-процессов, произошедших из-за сбоев ИТ-инфраструктуры;

11. Процент руководителей компании, удовлетворенных соблюдением показателей SLA при восстановлении;

12. Процент ИТ-сервисов, соответствующих показателям доступности (uptime);

13. Процент успешных и своевременных фактов восстановления из резервных копий;

14. Количество фактов восстановления, достигших временных и целевых показателей восстановления.

Экстенсивная цифровизация бизнес-процессов, выход множества сервисов в онлайн, непрерывно усложняющийся и эволюционирующий киберландшафт приводят и к сопутствующему росту киберугроз и повышению мотивации атакующих. Если еще 15-20 лет назад большинство хакеров осуществляло взломы ради удовлетворения собственного любопытства или тщеславия, а о материальной выгоде от атаки задумывались единицы, то в наше время подавляющее большинство атакующих являются финансово мотивированными. Продвинутые киберпреступники объединяются в преступные синдикаты со строгой иерархией, четким разделением обязанностей и инвестициями в поиск новых эксплойтов, методов атаки и в обеспечение собственной анонимности и безопасности, а киберармии отдельных государств представляют реальную угрозу целым секторам экономики различных государств. В сложившейся ситуации принципиально важным является взаимодействие защищающихся сторон - государств, компаний, ИБ-вендоров, научных и исследовательских сообществ. Взаимодействие подразумевает не только синхронизацию нормативно-правовой базы для эффективного юридического преследования киберпреступников, но и обмен информацией о способах проведения кибератак и «почерке» хакерских кибергруппировок для повышения эффективности выявления признаков компрометации инфраструктуры, выполнения релевантных оперативных действий по реагированию на киберинциденты, обеспечения корректного пост-инцидентного анализа. Документ NIST SP 800-150 "Guide to Cyber Threat Information Sharing" («Руководство по обмену данными о киберугрозах») предоставляет рекомендации по обмену данными об индикаторах компрометации, о тактиках, техниках и процедурах атакующих и о результатах анализа обработанных киберинцидентов, что помогает определить надежные источники получения таких данных, согласовать правила обмена информацией, эффективно использовать данные киберразведки для повышения уровня кибербезопасности.

Итак, данные о киберугрозах - это любая информация, которая может помочь организации выявить, оценить, отследить и отреагировать на киберугрозы. Примерами данных о киберугрозах будут индикаторы компрометации (IP-адрес, URL, хэш-сумма, адрес отправителя фишингового email), индикаторы атак (последовательность событий ИБ, которые могут свидетельствовать о кибератаке), индикаторы поведения атакующих (сканирование портов, подбор паролей, попытки эксплуатации уязвимостей), артефакты (признаки произошедшей компрометации в виде специфических файлов, метаданных, сетевой активности), тактики, техники и процедуры атакующих, оповещения об угрозах (например, данные об уязвимостях и эксплойтах), отчеты киберкриминалистов и исследователей киберугроз, а также рекомендуемые настройки средств защиты для эффективного сбора, обмена, обработки и анализа данных о киберугрозах. Указанные сведения как правило уже собираются и обрабатываются внутри организаций, но публикация NIST SP 800-150 сфокусирована на внешнем обмене такими данными, что позволяет повысить общий уровень защищенности компаний путем обмена сведениями о совершающихся или недавно произошедших киберинцидентах, особенно если обмен ведется данными, специфичными для определенного сектора экономики. Такой подход даст возможность работать во взаимовыгодной парадигме «то, что выявила одна организация в результате произошедшего инцидента, может использовать другая организация для недопущения аналогичного инцидента», что дает возможность обогащать данные о киберугрозах информацией от всех участников обмена, повышать ситуационную осведомленность и знания об актуальном ландшафте киберугроз, применять релевантные меры и способы защиты для минимизации киберрисков. При этом не следует забывать и о рекомендациях и лучших практиках при обмене информацией, а также о возможных негативных последствиях и мерах предосторожности при информационном обмене: необходимо установить доверительные отношения с участниками обмена, автоматизировать передачу данных и применять стандартизованные решения, обеспечить защиту конфиденциальной информации и минимизировать риск ее  разглашения при информационном обмене данными о киберугрозах, обеспечить ресурсную поддержку при обмене информацией (инфраструктура, инструменты, сотрудники), а также оценить качество входящей информации и обеспечить ее конвертацию в применяемый внутри компании формат, соответствие применимым законодательным нормам, сокрытие конфиденциальных подробностей при отправке данных о кибератаке за пределы компании.

При внедрении процесса обмена данными о киберугрозах можно руководствоваться следующими этапами, приведенными в публикации NIST SP 800-150:

1. Определить цели и задачи процесса обмена данными о киберугрозах, приоритизировать действия и шаги.

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

3. Определить объем и границы информационного обмена: согласовать типы доступной для обмена информации, условия обмена информацией, получателей информации. Также следует приоритизировать типы требующейся информации в зависимости от целей и задач процесса обмена, а также, основываясь на ресурсных возможностях организации, отдавать предпочтение автоматизированным способам обработки информации о киберугрозах.

4. Установить правила обмена информацией и утвердить их в виде политики: определить перечень типов информации, которой можно делиться, определить условия и обстоятельства, при которых обмен возможен, согласовать перечень получателей информации, установить правила санитизации или редактирования информации для удаления конфиденциальных сведений, определить требования к получателям информации по обеспечению защиты полученной информации. Также следует озаботиться соблюдением ограничений на передачу конфиденциальной информации (персональные данные, коммерческая тайна, банковская тайна и т.д.) и разработкой правил санитизации этих сведений в рамках информационного обмена. В документе NIST SP 800-150 приводится пример использования TLP-нотации (Traffic Light Protocol, «светофорный индикатор конфиденциальности»), который можно применять при обмене чувствительной информацией для маркирования её соответствующим образом в зависимости от степени конфиденциальности.

5. Присоединиться к сообществу обмена информацией о киберугрозах: при оценке сообществ обмена информацией и поставщиков данных киберразведки следует оценить потенциальную пользу от предоставляемых ими сведений, оценить полноту закрытия их данными пробелов в ситуационной осведомленности компании. Рекомендуется поддерживать членство в нескольких сообществах по обмену информацией и отдавать предпочтение наиболее релевантным (т.е. тем, которые объединяют компании одного сектора, одного региона, со сходными инфраструктурами и риск-профилями).

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

Участие в обмене информацией о киберугрозах, по мнению авторов публикации NIST SP 800-150, должно включать в себя следующие процессы:

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

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

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

4. Организация хранения информации о киберугрозах, включая данные об источнике индикатора, использующие данный индикатор правила на СЗИ, дату и время получения данных, срок жизни индикатора, релевантные идентификаторы CVE/CPE/CWE/CCE, ассоциированные с индикатором киберпреступные группы и их техники, тактики, процедуры и атакуемые системы и компании. Не следует забывать и о защите информации о киберугрозах, которая сама может являться одной из целью атакующих для сокрытия кибератаки и увеличения времени обнаружения вторжения.

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

При выстраивании эффективных процессов управления информационной безопасностью одной из главных задач является т.н.  «харденинг», т.е. защищенная настройка операционных систем и приложений с задействованием встроенных функций безопасности. Такой подход оправдан, например, при невозможности приобретения наложенных средств защиты информации при наличии бюджетных, законодательных и прочих ограничений, а также при нежелательности применения дополнительного ПО в критичных системах. Например, при защите значимых объектов КИИ согласно Приказу ФСТЭК №239 приоритет следует отдавать штатному защитному функционалу. При выстраивании системы технических защитных мер штатными средствами для минимизации киберрисков одним из важных и действенных методов является создание разрешительных списков (англ. allow list / white list). При полноценном применении данной концепции создается защищенная программная среда, функционирующая по принципу «запрещено все, что явно не разрешено» (англ. Default Deny, «запрет по умолчанию»). Данный принцип позволяет отсечь существенное количество потенциальных угроз, оставляя атакующим достаточно узкую поверхность атаки и вынуждая их прибегать к продвинутым методам атак (например, с использованием системных утилит "Living-off-the-Land Binaries" или с помощью покупки/кражи цифрового сертификата для подписи кода), что в свою очередь повышает стоимость атаки и, следовательно, снижает привлекательность цели для злоумышленников. Ниже мы рассмотрим документ NIST SP 800-167 "Guide to Application Whitelisting" («Руководство по составлению белого списка приложений»), который содержит предложения по созданию разрешительных списков исполняемых файлов, библиотек, файлов конфигураций путем применения встроенных в ОС технологий и использования разнообразных критериев оценки (цифровая подпись, хэш, расположение файла).

Итак, публикация NIST SP 800-167 дает определение следующим понятиям:

1. Whitelist (белый/разрешительный список) - перечень отдельных сущностей (например, хосты, IP-адреса, email-адреса, имена процессов и приложений), которые могут присутствовать или быть активными в системе в соответствии с заранее определенными правилами;

2. Blacklist (черный/запретительный список) - перечень сущностей, которые были ранее определены как связанные с вредоносной активностью, и их активность на системе должна быть исключена;

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

Разрешительный список приложений ("application whitelist") - это перечень приложений и их компонент (библиотеки, модули, конфигурационные файлы), которые могут присутствовать или быть активными в системе в соответствии с заранее определенными правилами ("baseline"). Данные ограничения реализуются программами контроля приложений (application control programs) или технологиями создания разрешительных списков (application whitelisting technologies).

Технология разрешительных списков призвана защищать от вредоносного ПО, в том числе от образцов, пока неизвестных антивирусным лабораториям. При этом, в отличие от тех же антивирусов, они действуют более строго, разрешая запуск только заранее определенного ПО и блокируя всё остальное. Эта технология также призвана защитить инфраструктуру компании от несанкционированной установки пользователями программного обеспечения, которое может содержать критичные уязвимости, не поддерживаться вендором и нести юридические риски для компании в случае отсутствия лицензии - указанные риски, известные как «Теневое ИТ» ("Shadow IT"), могут принести много головной боли крупным компаниям с разветвленной структурой. При этом следует учесть, что поддержка технологии разрешительных списков в распределенных гетерогенных инфраструктурах также потребует дополнительных накладных расходов на администрирование и оперативную актуализацию разрешений по заявкам пользователей.

В публикации NIST SP 800-167 приведены следующие типы разрешительных списков приложений:

1. Атрибуты файлов и каталогов:

1.1. Путь к файлу. Распространенный, но не самый надежный вариант, поскольку вредоносное ПО с правом записи в каталоги из «разрешительного списка» сможет быть запущено. При этом применение данного атрибута может быть оправдано при использовании строгих правил контроля доступа к каталогам (ACL, access control lists).

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

1.3. Размер файла. Также ненадежный вариант, который может быть использован лишь в сочетании с другими атрибутами.

1.4. Цифровая подпись или издатель. Использование цифровых сертификатов для подписи кода (code signing certificates) позволяют подписать хэш-сумму от определенного исполняемого файла или библиотеки с помощью закрытого ключа издателя - компании-разработчика или организации, которая санкционировала исполнение данного файла на своих устройствах. Разрешительный список по имени издателя может избавить от дополнительных трудозатрат на проверку и подпись каждого файла в отдельности, но позволит пользователям запускать любое ПО, созданное данным издателем, включая устаревшее или не рекомендованное к использованию в компании. Единственным минусом данного типа атрибутов, помимо трудозатрат на администрирование списка издателей, является тот факт, что и по сей день не все разработчики ПО подписывают своё ПО цифровыми подписями - отчасти это связано с необходимостью приобретения сертификатов у коммерческих центров сертификации.

1.5. Значение хэш-суммы. Достаточно надежный способ атрибутирования, при этом следует учесть трудозатраты на регулярное обновление списка хэшей при выходе обновлений ПО и на удаление из "белого списка" хэшей старых версий ПО, содержащих уязвимости.

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

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

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

Режимы работы технологий для создания разрешительных списков приложений, в соответствии с документом NIST SP 800-167, могу быть следующими:

1. Режим аудита: запуск всех приложений без ограничений и сбор информации об их атрибутах для дальнейшего анализа;

2. Режим блокирования:

2.1. Запуск только разрешенных приложений с блокированием иного ПО;

2.2. Запрос пользователя (администратора) при попытке запуска приложения не из «белого» / «черного» списка;

2.3. Блокирование приложений только из списка запрещенных и разрешение всех иных приложений.

Кроме непосредственного разрешения или запрещения определенных программ, технологии контроля приложений могут предоставлять следующие возможности:

1. Инвентаризация ПО: контроль версий, издателей, соблюдения лицензионных требований и внутренних нормативных документов по использованию ПО;

2. Мониторинг целостности файлов: мониторинг целостности файлов или предотвращение несанкционированного изменения файлов;

3. Реагирование на киберинциденты: сбор данных о файлах на скомпрометированном хосте, выявление аналогичных подозрительных файлов на других устройствах в сети компании;

4. Дополнительные опции, включающие в себя контроль загруженных в память приложений, репутационный анализ неизвестных файлов, проверка файлов из «серого» списка через онлайн-сканеры вредоносного ПО (например, VirusTotal).

При внедрении решения для контроля приложений авторы документа NIST SP 800-167 рекомендуют придерживаться следующих этапов:

1. Выявление текущих и возможных будущих потребностей и функционала решения для контроля приложений, описание требований к безопасности и производительности, разработка соответствующих внутренних нормативных документов;

2. Разработка архитектуры решения, включая управление разрешительными и запретительными списками, выбор алгоритмов хэширования и цифровой подписи для файлов, а также алгоритмов шифрования канала связи между клиентом и сервером управления, на котором хранятся политики и «белые»/ «черные» списки;

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

4. Развертывание решения последовательно на различных группах устройств с выявлением и устранением проблем;

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

Экстенсивный рост объема данных в электронном виде в результате ускоренных процессов автоматизации и цифровизации привел к необходимости грамотного управления всеми этапами жизненного цикла конфиденциальной информации и физических накопителей, её содержащих. Эволюция технологий хранения данных также привела к появлению в компаниях множества устаревших накопителей, которые содержат корпоративную информацию, но при этом выводятся из эксплуатации. Примерами могут стать жесткие диски на магнитных накопителях (HDD), ленточные накопители предыдущих поколений (LTO-7 и предыдущие), компакт-диски (CD/DVD), а также дискеты и старые флешки. При устаревании указанных накопителей в момент вывода из эксплуатации перед утилизации крайне важно обеспечить очистку накопителей от конфиденциальной информации. Аналогичный подход следует использовать и при передаче устройств и накопителей третьим лицам - например, при ремонте вне офиса, при продаже сотрудникам или при передаче на благотворительные цели. Документ NIST SP 800-88 Rev. 1 "Guidelines for Media Sanitization" («Рекомендации по очистке носителей данных») содержит рекомендации по удалению конфиденциальной информации с носителей различных типов в зависимости от критичности данных, с указанием ролей и ответственных за процесс очистки. Ниже мы подробно рассмотрим положения данного документа.

В соответствии с категоризацией документа NIST SP 800-88, для санитизации (очистки) накопителей можно применять следующие способы:

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

2. Удаление (Purge) - применение логических и физических методов удаления информации, после воздействия которых невозможно восстановить данные даже в специализированных лабораториях.

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

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

С развитием технологий хранения данных меняются и способы их гарантированного уничтожения. Так, методы, которые применяли для накопителей с магнитными дисками, такие как размагничивание в устройствах-дегауссерах, не применимы к накопителям, использующим другие физические принципы, например, к твердотельным накопителям (SSD/NVMe). Электронные накопители небольшого размера, такие как USB-флешки и карты памяти (SD/microSD), представляют сложность для устройств-измельчителей (особые шредеры), поскольку требуется, чтобы минимальная единица измельчения была меньше, чем физические габариты уничтожаемого накопителя: например, могут возникнуть трудности с миниатюрными microSD-картами, емкость которых доходит до 1 Тб. Кроме того, некоторые модели накопителей содержат встроенную в микропрограмму функцию гарантированного удаления информации, при этом доверие реализованной вендором функции может быть под вопросом до проведения независимого исследования. Еще одним вызовом в современном киберпространстве будет потребность в гарантированном уничтожении данных в мобильных устройствах и в облачных инфраструктурах. В обоих случаях можно воспользоваться методом криптографического стирания (Cryptographic erase), при котором удаляется не сама зашифрованная информация, а ключ шифрования. Однако, доверие к данному способу также зависит от вендоров-производителей мобильных устройств и от облачных провайдеров: в первом случае важна корректность реализации как самого шифрования всей чувствительной информации, так и надежность удаления ключа шифрования (и отсутствие где-либо его копии), а во втором случае требуется убедиться, что провайдер не сохраняется копию незашифрованной информации или ключа шифрования в незащищенной области (например, в оперативной памяти или в резервных копиях / репликах данных).

В документе NIST SP 800-88 рекомендуется использовать криптографическое стирание в следующих случаях:

1. Когда конфиденциальная информация была зашифрована до того, как была записана на носитель (включая и сами данные, и копии данных).

2. Когда известно место хранения накопителя с ключом шифрования и когда можно очистить данные накопители.

3. Когда известны все места хранения ключей шифрования и можно их очистить.

4. Когда ключи шифрования сами зашифрованы ключом доступа и можно гарантированно удалить эти ключи доступа.

5. Когда есть уверенность в том, что пользователь сможет осознанно применять необходимые функции шифрования.

Криптографическое стирание не рекомендуется применять в следующих случаях:

1. Когда шифрование накопителя было включено после того, как туда была записана конфиденциальная информация.

2. Когда неизвестно, была ли записана конфиденциальная информация на накопитель до включения шифрования.

При выборе метода очистки данных организациям следует руководствоваться следующими характеристиками:

1. Какой тип и объем накопителя следует очистить?

2. Каковы требования конфиденциальности к данным, хранящимся на накопителе?

3. Будет ли накопитель работать в пределах контролируемой зоны?

4. Будет ли очистка проводиться силами самой организации или силами подрядчика?

5. Какое количество накопителей потребуется очистить?

6. Какова доступность инструментов и оборудования для проведения санитизации?

7. Каков уровень подготовленности сотрудников для работы с инструментами и оборудованием для проведения санитизации?

8. Как долго будет проводится санитизация?

9. Какова стоимость санитизации с учетом инструментов, подготовки, проверки выполненных действий?

Распределение ответственных и ролей за процесс очистки носителей данных согласно документу NIST SP 800-88 может быть следующим:

1. Руководитель организации отвечает за выделение адекватных ресурсов для обеспечения успешности процессов выявления мест хранения накопителей и корректной санитизации.

2. Руководитель ИТ отвечает за соблюдение требований политики по ИБ и за соответствие процессов санитизации ее положениям.

3. Владелец информационной системы должен убедиться в наличии методов обеспечения конфиденциальности информации и накопителей в соответствии с уровнем её критичности.

4. Владелец информации отвечает за понимание уровня критичности информации в его зоне ответственности и за понимание пользователями информации правил очистки данных.

5. Руководитель ИБ отвечает за создание и применение политики ИБ в части удаления информации и очистки накопителей с применением принципов релевантности и оперативности, а также имеет доступ к ресурсам и инструментарию для выполнения процедур санитизации.

6. Пользователи отвечают за знание и понимание уровня конфиденциальности обрабатываемой ими информации и за корректность ее использования.

Современный киберландшафт претерпел значительные изменения за последнее время: развитие облачных инфраструктур, размытие периметра, переход на микросервисные архитектуры, а также существенно расширившаяся поверхность атаки и усложнившиеся кибернападения, которые стали чрезвычайно разрушительными, оказывают влияние на выбор релевантных мер защиты информации, включая сетевые СЗИ. В драфте публикации NIST SP 800-215 "Guide to a Secure Enterprise Network Landscape" («Руководство по созданию безопасного корпоративного сетевого ландшафта»), который по состоянию на сентябрь 2022 проходит процедуры публичного обсуждения и готовится к утверждению, приводится перечень основных традиционных сетевых классов решений с указанием присущих им ограничений и приводится список современных решений и подходов для обеспечения сетевой безопасности.

Итак, современная ИТ-среда состоит из подписок на множественные облачные сервисы (включая IaaS, PaaS, SaaS), корпоративных бизнес-приложений, распределенных по множеству офисов и дата-центров и размещенных на гетерогенных платформах, а также, зачастую, из IoT-устройств. Такая инфраструктура предполагает множество взаимосвязей между ИТ-системами и ресурсами, включая данные, облачные сервисы и пользователей, подключающихся удаленно. Соответственно, разнообразие площадок с данными и приложениями, разнородность сред, скорость разработки ПО вынуждает фокусировать внимание не на внутренних или внешних сетях, а на пользователях и устройствах: сегодня невозможно проверить подлинность сущности только на основании однократно предъявленного идентификатора или локации (сетевого сегмента). Следует непрерывно валидировать все запросы на доступ, не ограничиваясь только началом сетевой сессии или запуском веб-приложения, а также принимать решение на основании контекстно-ориентированного подхода.

В публикации NIST SP 800-215 дается описание функционала некоторых современных сетевых СЗИ:

1. CASB (Cloud Access Security Broker, брокер безопасности облачного доступа) реализует политики безопасности доступа к облачным данным и приложениям путем анализа мест хранения документов, контроля доступа к ним, выявления аномалий в поведении пользователей и сущностей, выявления недостатков конфигураций облачных инфраструктур. CASB-решения ставятся между пользователями облачных сервисов (cloud service customers, CSC) и провайдерами облачных сервисов (cloud service providers, CSP). Изначально CASB-решения применялись для выявления облачных ресурсов и SaaS-приложений (software-as-a-service , программное обеспечение как услуга), в том числе для решения вопроса «теневого ИТ», которое означает несанкционированное использование пользователями ИТ-решений и ПО, таких как файлообменники, системы ВКС, инструменты совместной работы, которые не прошли процедуру согласования. Затем CASB-решения эволюционировали в системы для обеспечения выполнения политик ИБ в облачных инфраструктурах, включая защиту корпоративных данных в решениях SaaS и IaaS (infrastructure-as-a-service, инфраструктура как услуга). анализ аномалий поведения и выявление вредоносных действий пользователей и сущностей, выявление облачных конфигураций, не соответствующих требованиям ИБ компании и лучшим практикам по кибербезопасности.

2. WAF (Web Application Firewall, межсетевой экран уровня приложения) позволяет предотвратить реализацию веб-атак путем мониторинга попыток эксплуатации веб-уязвимостей (таких как SQL-инъекции, XSS, внедрение команд уровня ОС и т.д.), а также путем реализации функций виртуального патчинга (блокирование попыток эксплуатации уязвимостей непропатченных веб-компонент).

3. Межсетевые экраны также не потеряли своей актуальности. Они прошли следующий примерный эволюционный путь расширения функционала:

- пакетная фильтрация и трансляция сетевых адресов (NAT-трансляция) для мониторинга и контроля сетевых пакетов, применения сетевых правил безопасности, сокрытия внутренних адресов от «внешнего мира»;

- сетевая инспекция с контролем состояния (stateful inspection), также известная как динамическая фильтрация пакетов, обеспечивает контроль состояния сетевых соединений и принимает решения на основании информации о текущем состоянии каждого сетевого соединения;

- выявление и реагирование на киберугрозы, такие как ВПО, эксплойты, некорректно сформированные пакеты, с передачей сообщений в SIEM-системы и корреляции с другими ИТ/ИБ-решениями в инфраструктуре;

- возможности по расширенному логированию и аудиту сетевых соединений, контроль разнообразных типов сетевых соединений и точек обмена трафиком, применение Open API для интеграции с другими сетевыми СЗИ;

- UTM-решения (Unified threat management, унифицированное управление киберугрозами), сочетающие несколько функций безопасности: межсетевое экранирование, IPS/IDS-функционал для предотвращения/выявления сетевых вторжений, VPN-шлюз, антивирус, контентную фильтрацию, балансировку нагрузки;

- NGFW (Next-generation firewall, межсетевые экраны нового поколения), обеспечивающие гранулированный контроль сетевой активности на уровне приложений (L7), внутреннюю сегментацию, интеграцию с «песочницами» для проверки подозрительных объектов, проверку зашифрованного трафика (т.н. SSL/TLS-инспекция), а также реализующие функции программно-определяемых сетей (SD-WAN, Software-defined wide area networks);

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

4. Более современными решениями для обеспечения сетевой безопасности можно назвать следующие типы продуктов:

- решения WAAP (Web Application and API Protection, защита веб-приложений и API), которые представляют собой расширение функционала WAF для защиты WebAPI интерфейсов и противодействия ботнетам и DDoS-атакам;

- решения SWG (Secure Web Gateway, защищенные шлюзы доступа в интернет), которые защищают корпоративных пользователей, подключающихся из разнообразных локаций, при работе с интернет от веб-угроз путем анализа HTTP/HTTPS-трафика.

В публикации NIST SP 800-215 также уделено внимание стратегии микросегментации сети для сдерживания распространения угроз по сети и снижения последствий атак. Концепция микросегментации подразумевает разделение ЛВС организации на множество небольших сетевых сегментов, обмен трафика между которыми логируется и контролируется, а сетевые правила позволяют открыть только явно разрешенные сетевые соединения, настроенные с помощью политик сетевой безопасности.

Для практической реализации микросегментации сначала потребуется:

1. Создать идентификаторы приложений: в современном мире идентификация лишь на основании связки «IP-адрес + порт» уже не может быть достаточной, поскольку подавляющее большинство современных веб-приложений работают на одном и том же порту TCP:443. Таким образом, для каждого сетевого приложения необходимо построить его уникальный отпечаток, который будет характеризовать только его.

2. Созданный идентификатор следует подписать цифровой подписью доверенного центра сертификации для того, чтобы злоумышленники не смогли несанкционированно изменить идентификатор приложения или создать собственный идентификатор вредоносного приложения.

3. Следует выявить все ресурсы, которые использует то или иное веб-приложение, включая сервисы, приложения и т.д., для учета данных взаимосвязей при профилировании поведения приложения.

4. Рекомендуется сгруппировать сходные и одинаковые по уровню доверия приложения для снижения нагрузки на аппаратные ресурсы и упрощения администрирования.

5. Затем потребуется сделать привязку созданных групп приложений к конкретным физическим или виртуальным инфраструктурным элементам, с учетом топологии сети.

При внедрении миросегментации можно руководствоваться следующими подходами:

1. Подход на основе сегментации: приложения и ресурсы со сходными требованиями по безопасности группируются в отдельные сегменты, а правила межсетевого экранирования применяются к данным сегментами. Сетевые шлюзы, установленные на границах сегментов, контролируют и логируют трафик между сегментами, выявляют и предотвращают распространение сетевых угроз.

2. Сегментация на основе виртуализации: гипервизор контролирует трафик, проходящий между виртуальными гостевыми машинами.

3. Хостовая микросегментация: на устройства устанавливается агент, который использует встроенные функции хостового межсетевого экрана для применения гранулированных сетевых политик, устанавливаемых централизованно.

4. Микросегментация на основе идентификаторов: все сетевые приложения обмениваются подписанными идентификаторами, взаимно аутентифицируют и авторизуют друг друга, а далее определяют, могут ли подключиться друг к другу при каждой установке соединения. При таком подходе нет привязки к IP-адресации или подсетям, поэтому соединения не зависят от конкретных подсетей, независимы от инфраструктуры, могут быть внедрены как политики в процессах CI/CD (непрерывная интеграция, CI / непрерывная доставка, CD) для ускорения разработки и обновления ПО, а также позволяют создать максимально точные и гранулированные политики сетевого взаимодействия.