SOT

SOT

SOAR
Security Orchestration, Automation and Response

Автоматизация реагирования на инциденты информационной безопасности при помощи динамических плейбуков с применением СЗИ, выстраиванием цепочки атаки и объектно-ориентированным подходом

NG SOAR
Next Generation SOAR

Автоматизация реагирования на инциденты ИБ со встроенной базовой корреляцией, сбором сырых событий непосредственно с СЗИ, динамическими плейбуками, выстраиванием цепочки атаки и объектно-ориентированным подходом

AM
Asset Management

Описание ИТ-ландшафта, обнаружение новых объектов в сети, категорирование активов, инвентаризации и управления жизненным циклом оборудования и ПО на АРМ и серверах организаций

VM
Vulnerability Management

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

Напишите нам на marketing@securituvision.ru или закажите демонстрацию

GRC

GRC

КИИ
Критическая Информационная Инфраструктура

Аудит и исполнение требований ФЗ-187 «О безопасности критической информационной инфраструктуры Российской Федерации» и других нормативных документов

ГосСОПКА
Государственная Система Обнаружения Предупреждения и Ликвидации Последствий Компьютерных Атак

Двустороннее взаимодействие с Национальным координационным центром по компьютерным инцидентам (НКЦКИ), а именно передача информации об инцидентах и получение оперативных уведомлений/бюллетеней от регулятора

FinCERT
Financial Computer Emergency Response Team

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

RM
Risks Management

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

ORM
Operational Risks Management

Учёт и фиксация событий операционных рисков (СОР), мониторинг ключевых индикаторов рисков (КИР) и проведение самооценки /контроля согласно положению №716-П ЦБ РФ

CM
Compliance Management

Аудит соответствия и комплаенса различным методологиям и стандартам (проектный)

BCP
Business Continuity Plan

Автоматизация процесса обеспечения непрерывности и восстановления деятельности (ОНиВД) после наступления чрезвычайных ситуаций

Напишите нам на marketing@securituvision.ru или закажите демонстрацию

Обзор публикации NIST SP 800-190 "Application Container Security Guide"

Обзор публикации NIST SP 800-190 "Application Container Security Guide"
20.06.2022

  |  Слушать на Google Podcasts  |   Слушать на Mave  |   Слушать на Яндекс Музыке  |    


Руслан Рахметов, Security Vision

Друзья, в предыдущей публикации мы обсудили защиту технологий виртуализации в соответствии с рекомендациями специальной публикации 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. Подмена объектов файловой системы хостовой ОС: при некорректной конфигурации контейнеру может быть предоставлено право изменения объектов файловой системы хостовой ОС, что может привести к компрометации самой хостовой ОС и всех контейнеров на ней. В качестве контрмеры следует применять инструменты контроля попыток изменения объектов файловой системы хоста.

Подкасты ИБ NIST

Рекомендуем

SIEM системы (Security Information and Event Management) - что это и зачем нужно?
SIEM системы (Security Information and Event Management) - что это и зачем нужно?
Управление рисками информационной безопасности. Часть  7. Стандарт ISO/IEC 27005:2018 (продолжение). Стандарт IEC 31010:2019
Управление рисками информационной безопасности. Часть 7. Стандарт ISO/IEC 27005:2018 (продолжение). Стандарт IEC 31010:2019
Нормативные документы по ИБ. Часть 14. Обзор российского законодательства в области ИБ финансовых организаций - продолжение
Нормативные документы по ИБ. Часть 14. Обзор российского законодательства в области ИБ финансовых организаций - продолжение
Модуль взаимодействия с НКЦКИ на платформе Security Vision
Модуль взаимодействия с НКЦКИ на платформе Security Vision
Управление рисками информационной безопасности. Часть 2. Стандарт NIST SP 800-39
Управление рисками информационной безопасности. Часть 2. Стандарт NIST SP 800-39
Обзор публикации NIST SP 800-207 "Zero Trust Architecture"
Обзор публикации NIST SP 800-207 "Zero Trust Architecture"
Обзор публикации NIST SP 800-190 "Application Container Security Guide"
Обзор публикации NIST SP 800-190 "Application Container Security Guide"
Краткий обзор специальных публикаций NIST по информационной безопасности. Часть 1
Краткий обзор специальных публикаций NIST по информационной безопасности. Часть 1
Обзор публикации NIST SP 800-161 Rev. 1 (Draft) "Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations"
Обзор публикации NIST SP 800-161 Rev. 1 (Draft) "Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations"
Обзор стандартов Банка России. Безопасность финансовых (банковских) операций
Обзор стандартов Банка России. Безопасность финансовых (банковских) операций
Публикация MITRE «11 стратегий SOC-центра мирового уровня». Стратегия №3 «Выстраивайте структуру SOC в соответствии с потребностями компании». Часть 2
Публикация MITRE «11 стратегий SOC-центра мирового уровня». Стратегия №3 «Выстраивайте структуру SOC в соответствии с потребностями компании». Часть 2
Обзор публикации NIST SP 800-215 "Guide to a Secure Enterprise Network Landscape"
Обзор публикации NIST SP 800-215 "Guide to a Secure Enterprise Network Landscape"

Рекомендуем

SIEM системы (Security Information and Event Management) - что это и зачем нужно?
SIEM системы (Security Information and Event Management) - что это и зачем нужно?
Управление рисками информационной безопасности. Часть 7. Стандарт ISO/IEC 27005:2018 (продолжение). Стандарт IEC 31010:2019
Управление рисками информационной безопасности. Часть  7. Стандарт ISO/IEC 27005:2018 (продолжение). Стандарт IEC 31010:2019
Нормативные документы по ИБ. Часть 14. Обзор российского законодательства в области ИБ финансовых организаций - продолжение
Нормативные документы по ИБ. Часть 14. Обзор российского законодательства в области ИБ финансовых организаций - продолжение
Модуль взаимодействия с НКЦКИ на платформе Security Vision
Модуль взаимодействия с НКЦКИ на платформе Security Vision
Управление рисками информационной безопасности. Часть 2. Стандарт NIST SP 800-39
Управление рисками информационной безопасности. Часть 2. Стандарт NIST SP 800-39
Обзор публикации NIST SP 800-207 "Zero Trust Architecture"
Обзор публикации NIST SP 800-207 "Zero Trust Architecture"
Обзор публикации NIST SP 800-190 "Application Container Security Guide"
Обзор публикации NIST SP 800-190 "Application Container Security Guide"
Краткий обзор специальных публикаций NIST по информационной безопасности. Часть 1
Краткий обзор специальных публикаций NIST по информационной безопасности. Часть 1
Обзор публикации NIST SP 800-161 Rev. 1 (Draft) "Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations"
Обзор публикации NIST SP 800-161 Rev. 1 (Draft) "Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations"
Обзор стандартов Банка России. Безопасность финансовых (банковских) операций
Обзор стандартов Банка России. Безопасность финансовых (банковских) операций
Публикация MITRE «11 стратегий SOC-центра мирового уровня». Стратегия №3 «Выстраивайте структуру SOC в соответствии с потребностями компании». Часть 2
Публикация MITRE «11 стратегий SOC-центра мирового уровня». Стратегия №3 «Выстраивайте структуру SOC в соответствии с потребностями компании». Часть 2
Обзор публикации NIST SP 800-215 "Guide to a Secure Enterprise Network Landscape"
Обзор публикации NIST SP 800-215 "Guide to a Secure Enterprise Network Landscape"

Похожие статьи

Искусственный интеллект в информационной безопасности
Искусственный интеллект в информационной безопасности
Кейлоггер для кибербезопасности и оптимизации
Кейлоггер для кибербезопасности и оптимизации
Нормативные документы по ИБ. Часть 14. Обзор российского законодательства в области ИБ финансовых организаций - продолжение
Нормативные документы по ИБ. Часть 14. Обзор российского законодательства в области ИБ финансовых организаций - продолжение
Управление рисками информационной безопасности. Часть 5. Стандарт NIST SP 800-30 (продолжение). Стандарт NIST SP 800-137
Управление рисками информационной безопасности. Часть 5. Стандарт NIST SP 800-30 (продолжение). Стандарт NIST SP 800-137
Практическая защита персональных данных. Где компания обрабатывает ПДн?
Практическая защита персональных данных. Где компания обрабатывает ПДн?
Практическая защита персональных данных. Как компания должна обрабатывать и защищать персональные данные? Часть 1
Практическая защита персональных данных. Как компания должна обрабатывать и защищать персональные данные? Часть 1
Статический анализ исходного кода
Статический анализ исходного кода
Ситуационная осведомленность в кибербезопасности
Ситуационная осведомленность в кибербезопасности
Обеспечение безопасности значимых объектов критической информационной инфраструктуры в рамках 187-ФЗ. Приказы ФСТЭК России №235 и 239
Обеспечение безопасности значимых объектов критической информационной инфраструктуры в рамках 187-ФЗ. Приказы ФСТЭК России №235 и 239

Похожие статьи

Искусственный интеллект в информационной безопасности
Искусственный интеллект в информационной безопасности
Кейлоггер для кибербезопасности и оптимизации
Кейлоггер для кибербезопасности и оптимизации
Нормативные документы по ИБ. Часть 14. Обзор российского законодательства в области ИБ финансовых организаций - продолжение
Нормативные документы по ИБ. Часть 14. Обзор российского законодательства в области ИБ финансовых организаций - продолжение
Управление рисками информационной безопасности. Часть 5. Стандарт NIST SP 800-30 (продолжение). Стандарт NIST SP 800-137
Управление рисками информационной безопасности. Часть 5. Стандарт NIST SP 800-30 (продолжение). Стандарт NIST SP 800-137
Практическая защита персональных данных. Где компания обрабатывает ПДн?
Практическая защита персональных данных. Где компания обрабатывает ПДн?
Практическая защита персональных данных. Как компания должна обрабатывать и защищать персональные данные? Часть 1
Практическая защита персональных данных. Как компания должна обрабатывать и защищать персональные данные? Часть 1
Статический анализ исходного кода
Статический анализ исходного кода
Ситуационная осведомленность в кибербезопасности
Ситуационная осведомленность в кибербезопасности
Обеспечение безопасности значимых объектов критической информационной инфраструктуры в рамках 187-ФЗ. Приказы ФСТЭК России №235 и 239
Обеспечение безопасности значимых объектов критической информационной инфраструктуры в рамках 187-ФЗ. Приказы ФСТЭК России №235 и 239