Экстенсивное развитие микроэлектронной промышленности и сетей передачи данных, а также разработка и внедрение новых специализированных и энергоэффективных сетевых технологий и протоколов, таких как 5G, Bluetooth Low Energy, LoRa, Zigbee и Z-Wave, в течение последних 10 лет привели к формированию целого класса недорогих и высокопроизводительных устройств - так называемых устройств «Интернета Вещей» (англ. IoT, Internet of Things).

Применение IoT-концепции и сопутствующих технологий «Промышленный Интернет Вещей» (англ. IIoT, Industrial Internet of Things) и «Интернет Всего» (англ. IoE, Internet of Everything), в том числе и в промышленности, в медицине, на транспорте, в инфраструктурах крупных компаний от ритейла и логистики до шеринговых сервисов и коммунальных услуг, предоставляет фантастические бизнес-возможности и создает новые вызовы, в том числе в области рисков информационной безопасности. Кибербезопасности IoT-устройств посвящены публикации NIST SP 800-213 "IoT Device Cybersecurity Guidance for the Federal Government: Establishing IoT Device Cybersecurity Requirements" («Руководство по кибербезопасности IoT-устройств для федерального правительства: Разработка требований по кибербезопасности IoT-устройств») и NIST SP 800-213A "IoT Device Cybersecurity Guidance for the Federal Government: IoT Device Cybersecurity Requirement Catalog" («Руководство по кибербезопасности IoT-устройств для федерального правительства: Каталог требований по кибербезопасности IoT-устройств»).

Итак, в публикации NIST SP 800-213 поддерживается логическая связь с фреймворком управления киберрисками NIST (NIST RMF, т.е. Risk Management Framework), и прежде всего с публикациями NIST SP 800-39, 800-37, 800-30. При этом публикация NIST SP 800-213A содержит каталог требований ИБ к возможностям защиты информации IoT-устройств и их производителей, логически связанный с положениями стандарта NIST SP 800-53, описывающего требования к мерам обеспечения безопасности и конфиденциальности. В соответствии с фреймворком RMF, IoT-устройства являются элементами информационных систем, которые могут быть частью как IT-, так и OT-сетей (англ. Operations Technology). В OT-сетях применяются разнообразные устройства: датчики, преобразователи, актюаторы (исполнительные устройства), которые посредством IoT-устройств связаны с IT-инфраструктурой для обработки поступающей информации. Примером IoT-устройства может быть LPWAN-модем, который передает информацию с датчика давления из труднодоступного участка газопровода в диспетчерский пункт, где на основании данной телеметрии ведется аналитика эффективности прокачки газа и выполнения контрактных обязательств.

Одной из особенностей IoT-устройств является их внедрение в зачастую уже функционирующую IT/OT-инфраструктуру, из которой потребовалось получать больше телеметрии, представляющей бизнес-ценность (аналитика, прогнозирование, контроль). Можно привести банальный пример: руководитель службы безопасности принимает решение об установке «умных» камер видеонаблюдения на территории компании, с подключением их к Интернет для возможности удаленного контроля; при этом уже после закупки выясняется, что в устройствах отсутствует функционал ограничения сетевых подключений и защиты от брутфорс-атак, а производитель данного оборудования не предоставляет инструкцию по настройке прав доступа пользователей и обновленную версию прошивки. Для подобных ситуаций публикация NIST SP 800-213 предлагает подход, заключающийся в предъявлении требований к функциональным возможностям IoT-устройств с точки зрения кибербезопасности с одновременным анализом способности вендора/поставщика решить организационные и технические ИБ-вопросы, что в свою очередь должно помочь сохранить уровень киберрисков на заранее оговоренном приемлемом уровне после внедрения IoT-устройств.

Выявление и предъявление требований информационной безопасности к IoT-устройствам в соответствии с NIST SP 800-213 состоит из 3 этапов:

1. Выявление сценариев использования IoT-устройств и характеристики свойств защиты информации в них:

1.1. Сценарии использования (use cases) и преимущества, которые дают бизнесу IoT-устройства, с применением cost-benefit анализа и с учетом того, что IoT-устройства могут стать брешью в защите компании и послужить входной точкой в ИТ-инфраструктуру для атакующих.

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

1.3. Взаимодействие с другими компонентами информационных систем в компании, с учетом влияния IoT-устройств на физическую среду функционирования и на другие IT/OT-элементы: например, могут ли повлиять IoT-устройства на конфиденциальность персональных данных сотрудников при использовании систем видеонаблюдения или на безопасность самих сотрудников, если речь идет о датчиках дыма или носимой электронике. Кроме того, нужно учитывать архитектурные особенности работы IoT-устройств, такие как приоритет надежности функционирования над кибербезопасностью, невозможность переопределить свойства микропрограммы устройства, использование проприетарных протоколов и форматов данных. Следует также учитывать наличие уязвимостей, которые нужно либо пропатчить (изменением настроек или перепрошивкой), либо применить компенсирующие меры для смягчения данного риска.

1.4. Методы обеспечения ИБ со стороны производителей IoT-устройств: руководствуется ли вендор фреймворком безопасной разработки ПО (SSDF, Secure Software Development Framework), следует ли рекомендациям по управлению рисками цепочек поставок (в соответствии с NIST SP 800-161), каким образом вендор устраняет уязвимости и раскрывает информацию о них, каким образом производитель предоставляет обновления прошивок для устранения уязвимостей в своих IoT-устройствах.

2. Выявление влияния IoT-устройств на оценку уровня киберрисков компании:

2.1. Влияние IoT-устройств как источников новых киберугроз и причину новых инцидентов ИБ.

2.2. Влияние уязвимостей IoT-устройств на состояние защищенности компании и её инфраструктуры (например, установленный по умолчанию и неизменяемый пароль суперпользователя может стать точкой входа атакующих в компанию или, как минимум, сделать IoT-устройство частью бот-сети для осуществления DDoS-атак по команде хакера).

2.3. Влияние вероятности реализации угроз ИБ устройствами IoT: например, наличие в IoT-устройстве постоянного интернет-подключения к сотовой сети может означать повышение вероятности эксплуатации атакующим сетевых уязвимостей устройства. При этом следует учитывать специфику работы IoT-устройств и их взаимодействие с защищаемыми активами: например, IoT-устройства (за исключением обработки по модели Edge Computing), как правило, не хранят у себя данные, что снимает необходимость обеспечивать защиту "data at rest", однако при передаче ими информации следует применять меры защиты "data in transit".

2.4. Оценка ущерба/влияния при реализации угроз ИБ устройствами IoT: например, сбой критически важного инфраструктурного IoT-устройства или медицинского IoT-оборудования может привести к значительному увеличению потенциального ущерба для компании.

3. Выявление требуемых характеристик ИБ, предъявляемых к IoT-устройствам:

3.1. Выбор применимых требований ИБ и свойств защиты информации устройств IoT для сохранения приемлемого уровня киберрисков.

3.2. Выбор применимых мер обеспечения ИБ из авторитетных источников (каталог защитных мер их публикации NIST SP 800-213A, контроли ИБ из NIST SP 800-53, применимые нормы NIST Cybersecurity Framework).

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

Далее вкратце опишем публикацию NIST SP 800-213A "IoT Device Cybersecurity Guidance for the Federal Government: IoT Device Cybersecurity Requirement Catalog" ( «Руководство по кибербезопасности IoT-устройств для федерального правительства: Каталог требований по кибербезопасности IoT-устройств»). Данный документ содержит перечень требований информационной безопасности, которые можно предъявлять к IoT-устройствам как с технической точки зрения (функционал программной и аппаратной части устройства), так и с организационной (документация, работа вендора с уязвимостями, обучение потребителей представителями вендора или поставщика).

Технические требования представлены следующими группами:

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

2. Конфигурирование устройств: логическое разграничение доступа к настройкам устройства, настройка интерфейсов и отображаемой на экране устройства информации.

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

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

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

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

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

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

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

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

3. Распространение производителем информации о кибербезопасности IoT-устсройства.

4. Обучение покупателей по вопросам кибербезопасности IoT-устройства.

Наконец, в приложении "B" приведена таблица соответствия требований публикации NIST SP 800-213A с требованиями публикации NIST SP 800-53 Rev. 5 "Security and Privacy Controls for Information Systems and Organizations" («Меры обеспечения безопасности и конфиденциальности для информационных систем и организаций»).

Как мы знаем, уязвимость - это некий недостаток создания/конфигурирования/использования программно-технического средства или информационной системы, который может негативно повлиять на обеспечение кибербезопасности ИТ-актива, при этом атакующие используют (эксплуатируют) уязвимости в самом активе или в его защите для осуществления вредоносных действий. Список уязвимостей непрерывно пополняется, так, например, в реестре CVE (Common Vulnerabilities and Exposures) организации MITRE на конец января 2022 года задокументировано почти 170 тысяч уязвимостей, среди которых встречаются по-настоящему разрушительные, эксплуатация которых может привести к захвату всей ИТ-инфраструктуры.

Основным способом защиты от эксплуатации известных уязвимостей является выстраивание процесса патч-менеджмента, который описан в документе NIST SP 800-40 Rev. 4 "Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology" («Руководство по планированию корпоративного управления обновлениями безопасности: Профилактическое обслуживание для ИТ»).

Итак, в 4-ой ревизии документа NIST SP 800-40 дается определение процессу установки обновлений (патчингу) как действию по применению изменений к установленному ПО (приложениям, операционным системам, микропрограммам), которые исправляют проблемы с безопасностью/функционалом или привносят новые функциональные возможности. Корпоративное управление обновлениями определяется как процесс идентификации, приоритизации, получения, установки и проверки корректности установки обновлений безопасности, апдейтов или апгрейдов в рамках всей организации. В рамках документа NIST SP 800-40 рассматриваются такие информационные активы, как IT/OT-системы, IoT-устройства, мобильные устройства, а также облачные, виртуализированные и контейнеризированные инфраструктуры. В целях повышения и операционной эффективности процесса управления обновлениями ИТ и ИБ-руководителям совместно с руководством компании и владельцами бизнес-систем следует разработать корпоративную стратегию проактивного патч-менеджмента, контролируемо устраняющего потенциальную проблему (эксплуатация уязвимости), несмотря на устоявшиеся предубеждения (подход «работает - не трогай») и риски простоя бизнес-процессов (для установки обновления, перезагрузки ОС после установки обновления или в случае, если обновление нарушило функционал решения). При этом в документе признается факт того, что не все обновления действительно устраняют уязвимости или расширяют необходимый защитный функционал (достаточно вспомнить выпуск некорректных обновлений для Windows, нарушающих базовый функционал ОС, с последующим экстренным выпуском «патча для патча»), а также упоминаются случаи, когда обновление может само содержать новые уязвимости, допущенные случайно или заложенные намеренно (например, в рамках проведения атаки "supply chain", т.е. атаки на цепочку поставок).

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

1. Принятие: осознанное понимание наличия незакрытых уязвимостей, использование наложенных средств защиты, ожидаемый ущерб от эксплуатации уязвимости достаточно низок для непринятия дополнительных мер ИБ.

2. Минимизация: снижение киберриска путем устранения уязвимости (например, установка обновления безопасности ПО, отключение уязвимого компонента, обновление ПО до актуальной версии без уязвимостей) и/или применение дополнительных мер защиты для снижения вероятности эксплуатации уязвимости (например, применение «виртуального патчинга» на Web Application Firewall или в IPS-системе, сетевое ограничение доступа от/к уязвимому активу для сокращения поверхности потенциальной атаки). При этом следует учесть ограничения: уязвимость и эксплойт для неё появились раньше, чем вышел патч (например, в атаках “0-day” или при отсутствии должной реакции вендора); производитель больше не поддерживает устаревшее ПО/решение или истек срок лицензии на получение обновлений; бизнес-процессы не допускают простоя из-за установки обновления, требуется протестировать работу бизнес-приложений после установки ПО или обучить сотрудников работе с обновленной версией; установка патчей откладывается из-за наличия более высокоприоритетных обновлений; производитель выпускает обновление ПО/решения с задержкой, обусловленной расширенным тестированием или испытаниями; необходимость использования только сертифицированного ПО/решения, обновление для которого пока не прошло необходимые процедуры, установленные законодательством.

3. Передача: использование услуг киберстрахования или решений класса SaaS (Software-as-a-Service, программное обеспечение как услуга).

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

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

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

2. Планирование реагирования на киберриск эксплуатации уязвимости: выбор одного или нескольких способов обработки киберриска эксплуатации уязвимости (принятие, минимизация, передача, избегание).

3. Реагирование на киберриск эксплуатации уязвимости:

3.1. Подготовка к установке обновлений: приоритизация патча (в зависимости от уровня критичности уязвимости, которую он закрывает), планирование установки патча (в рамках корпоративной процедуры change management, т.е. управления внесением изменений), получение патча (скачивание, доставка на носителе, разработка своими силами), проверка патча (контроль целостности и отсутствия внесенных несанкционированных изменений), тестирование (для выявления проблем при/после установки патча до широкомасштабного развертывания).

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

3.3. Проверка установленного обновления: оценка успешности установки; проверка устранения связанной уязвимости.

3.4. Мониторинг установленных обновлений: контроль того, что обновление не было отменено/деинсталлировано пользователем или злоумышленником; контроль того, что старая уязвимая версия ПО не была восстановлена из бэкапа автоматически; анализ поведения обновленного ПО/решения для выявления признаков реализации атаки на цепочку поставок.

В документе NIST SP 800-40 также содержатся практические рекомендации по разработке корпоративного плана управления уязвимостями:

1. Снижение количества инсталляций потенциально уязвимого ПО.

Снижение количества инсталляций потенциально уязвимого ПО и, как следствие, минимизация необходимости установки обновлений может заключаться в следующем:

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

1.2. Использование ПО/решений, которые с меньшей вероятностью будут содержать уязвимости.

1.3. Взаимодействие с опытными вендорами, которые с меньшей вероятностью допустят появление уязвимостей в своих продуктах.

1.4. Использование, по возможности, предоставляемых сервисов вместо традиционного ПО.

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

2. Инвентаризация ИТ-активов.

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

· тип платформы (IT/OT/IoT/облако/контейнер/виртуальная машина);

· администрирующее лицо (IT-администратор, вендор, конечный бизнес-пользователь);

· механизм управления актива (гипервизор, менеджер контейнеров, endpoint-система управления);

· данные о сетевой связности актива (доступ в интернет, использующиеся порты и протоколы);

· применяемые СЗИ;

· основной пользователь актива или взаимосвязанные сервисы (с указанием привилегий);

· роль и критичность актива для компании (выполняемая бизнес-задача);

· нормативные требования к устранению уязвимости на этом активе;

· ограничения при установке обновлений (например, установить патч может только вендор);

· бизнес-требования к доступности актива (например, перезагрузка возможна раз в квартал в заранее согласованный временной интервал).

3. Определение сценариев реагирования на киберриск эксплуатации уязвимости.

Сценарии реагирования на киберриск эксплуатации уязвимости могут включать в себя:

3.1. Плановое обновление: установка обновлений в соответствии с планом обновлений, при отсутствии данных об эксплуатации уязвимостей атакующими.

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

3.3. Экстренный «обходной путь» (англ. workaround): выполнение срочных действий (изменение настроек ОС, правки реестра, перенастройка конфигурации ПО) для минимизации риска эксплуатации уязвимости до момента доступности патча или до возможности провести процедуру его установки.

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

4. Объединение активов в группы обслуживания.

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

5. Разработка планов обслуживания для каждой группы обслуживания.

5.1. План обслуживания для сценария «Плановое обновление»: следует определить небольшую группу активов, на которую будет установлено обновления в первую очередь, для тестирования и получения обратной связи, с выборкой пользователей и сервисов из различных бизнес-подразделений; после успешного теста можно применить обновление на оставшиеся активы. При этом в больших инфраструктурах тестовых групп может быть несколько, например, с распределением в пропорции 5%/20%/75%. При этом затягивать процесс установки плановых обновлений тоже не следует: можно установить дедлайн по установке, после которого обновление будет принудительно применено к устройству, либо временно блокировать сетевой доступ необновленному устройству.

5.2. План обслуживания для сценария «Экстренное обновление»: в случае необходимости применить экстренное обновление следует также выделить группу тестовых активов, в максимально сжатые сроки установить и протестировать на них обновление, а затем распространить его уже на все активы.

5.3. План обслуживания для сценария «Экстренный workaround»: следует заранее продумать способ применения экстренного workaround, например, централизованно отключая уязвимые компоненты, изолируя активы, автоматически изменяя настройки ОС, внося правки реестра, переконфигурируя ПО. При этом следует продумать процедуру отката внесенных экстренных изменений после выхода официального патча для его успешного применения.

5.4. План обслуживания для сценария «Необновляемые ИТ-активы»: следует продумать способы защиты необновляемых активов, такие как применение сетевой микросегментации, включения в виртуальные VLAN с ограниченным сетевым доступом, ограничение функционала, максимальный hardening. Следует также непрерывно анализировать применяемые меры для оценки их эффективности, а также проводить cost/benefit-анализ для соотнесения затрат на защиту необновляемых активов и их бизнес-пользы.

6. Выбор метрик эффективности процесса управления обновлениями.

Документ NIST SP 800-40 предлагает использовать инвентаризационные данные (включая информацию о критичности ИТ-активов) и данные систем оценки опасности уязвимостей (например, CVSS) для разработки метрик, отражающих важность каждой уязвимости и патча для инфраструктуры организации. В качестве примера составления метрики можно использовать взаимосвязь критичности актива (3 градации) и опасности уязвимости (4 градации).

7. Оценка технической поддержки ПО/решений при закупках.

При закупках ПО/решений следует оценивать уровень технической поддержки вендора при помощи опросника, который включает в себя вопросы о планах по выпуску обновлений для ПО/решения, регулярности предоставления патчей, периоде планируемого предоставления обновлений безопасности, способе обработки данных об обнаруженных уязвимостях, предоставлении экстренных патчей/workaround'ов, сведений о влиянии установки вендорский обновлений на ИТ-актив в целом.

Ряд резонансных киберинцидентов, произошедших в последнее время (такие как атаки на ИТ-гигантов SolarWinds и Kaseya), поставили мировое сообщество перед фактом: невозможно однозначно доверять даже самым проверенным и изученным информационным системам. Причина заключается в возможности проведения атак на цепочки поставок (англ. "supply chain attacks") путем несанкционированного внедрения атакующими вредоносного кода и/или недекларированных возможностей в программное и/или аппаратное обеспечение, которое поставляется третьим лицом (ИТ-вендором, производителем, сторонними разработчиками).

Не секрет, что современные приложения, информационные системы и высокотехнологичное оборудование настолько сложны и так часто обновляются, что компания-заказчик, как правило, не может самостоятельно проверить отсутствие уязвимостей, вредоносного функционала, бэкдоров (программной или аппаратной закладки) в используемом оборудовании, операционных системах, прикладном ПО и даже в средствах защиты. Вопросы обработки рисков цепочек поставок освещены в документе NIST SP 800-161 Rev. 1 (Draft) "Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations" («Практики управления киберрисками цепочки поставок для систем и организаций»).

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

Например, киберрисками цепочки поставок будут:

• компрометация репозитория исходного кода проприетарного программного продукта и включение в него бэкдора;

• выявление уязвимости в распространенном ПО и проведение дальнейших атак на пользователей данного ПО;

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

В документе NIST SP 800-161 признается, что повторное использование программных компонент, включая компоненты с открытым исходным кодом (англ. open source) является экономически эффективным и популярным способом разработки и улучшения ПО, при этом зачастую конечный потребитель не имеет представления о версиях программных модулей, используемых в конечном ПО, которое он использует. Аналогичные киберугрозы актуальны и для внутренней (in-house) разработки ПО, поскольку штатные разработчики могут использовать сторонние библиотеки и модули, которые могут содержать уязвимости. Приведем пример: недавняя опасная уязвимость Log4Shell, обнаруженная в популярной OpenSource-библиотеке логирования операций веб-приложений Apache Log4j, активно эксплуатируется в кибератаках именно по причине её широкого применения в коммерческих платформах по всему миру. Другой пример: при разработке программного продукта для внутренних нужд используется библиотека с открытым исходным кодом, хранящимся в GitHub-репозиторий; данный репозиторий может быть скомпрометирован атакующими (например, путем похищения учетных данных администратора), чтобы в дальнейшем "раздавать" видоизмененный код проекта, содержащий легко эксплуатируемую извне уязвимость, а за этим последуют и атаки на все компании, использовавшие данный GitHub-репозиторий. В результате, NIST SP 800-161 вводит понятие C-SCRM (Cybersecurity Supply Chain Risk Management, управление киберрисками цепочки поставок), обозначающее систематический процесс управления киберрисками цепочки поставок, являющийся частью корпоративной системы управления рисками и включающий в себя практики и меры защиты цепочек поставок для IT и OT-инфраструктур, а также для IoT-устройств. Внедрение процессов C-SCRM может помочь организациям выявить наиболее зависимые от цепочек поставок информационные системы и компоненты ИТ-инфраструктуры, уменьшить вероятность компрометации инфраструктуры за счет эффективного выявления, реагирования и восстановления после инцидентов в цепочках поставок, повысить уверенность в качестве, подлинности, надежности, киберустойчивости и безопасности приобретаемых продуктов, а также в надежности поставщиков и сервис-провайдеров.

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

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

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

• Периодические перепроверки выполнения поставщиками требований кибербезопасности;

• Установленные процессы и протоколы обмена информацией об уязвимостях, киберинцидентах и иных нарушениях бизнес-процессов, а также критерии категорирования инцидентов;

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

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

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

• Функционал и возможности;

• Доступ к данным и информации, включая привилегии доступа;

• Среда установки и функционирования;

• Безопасность, подлинность и целостность продукта и сервиса и соответствующей цепочки поставки и компиляции;

• Возможности источника поставок предоставить ожидаемый продукт или сервис требуемого качества;

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

• Рыночные альтернативы источнику поставок;

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

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

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

• Данные оповещений средств защиты, отчеты с данными киберразведки;

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

• Уязвимости информационных систем;

• Уровень угроз и уязвимостей по результатам их оценки;

• Потенциальное негативное влияние или ущерб, причиненный возможной компрометацией продукта или сервиса бизнес-процессам компании, а также вероятность такого негативного влияния или ущерба, с учетом возможности эксплуатации уязвимостей;

• Возможности компании по смягчению выявленных киберрисков цепочки поставок.

В документе NIST SP 800-161 приводятся рекомендации по эффективному обеспечению кибербезопасности цепочек поставок, которые разделены на основные (foundational), дополнительные (sustaining) и развивающие (enhancing).

Основные рекомендации включают в себя следующие пункты:

• Создание выделенного подразделения или группы для управления киберрисками цепочки поставок;

• Внедрение процессов и иерархии риск-менеджмента в соответствии с рекомендациями NIST SP 800-39 и NIST SP 800-30;

• Внедрение структуры корпоративного управления для интеграции требований управления киберрисками цепочки поставок в корпоративные политики и процедуры;

• Разработка процесса определения и оценки критичности корпоративных поставщиков, продуктов и сервисов;

• Повышение осведомленности ответственных работников в вопросах управления киберрисками цепочки поставок;

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

• Внедрение логически связанного, повторяемого, задокументированного процесса определения уровней негативного воздействия при реализации киберрисков цепочки поставок;

• Внедрение процессов оценки рисков поставщиков, включая анализ критичности, угроз и уязвимостей;

• Внедрение программы оценки качества и надежности с методами их контроля и проверки;

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

• Обеспечение контролируемого доступа к конфиденциальной информации по управлению киберрисками цепочки поставок;

• Внедрение применимых защитных мер в соответствии с документом NIST SP 800-53;

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

• Внедрение внутренних процессов для проверки того, что поставщики и сервис-провайдеры активно ищут и оповещают об уязвимостях в своих продуктах;

• Внедрение корпоративной функции управления и мониторинга каталога компонент программного обеспечения (англ. SBOM, Software Bill Of Materials) для выявления уязвимостей в используемом ПО.

Дополнительные рекомендации включают в себя следующие пункты:

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

• Использование механизмов построения доверия, включая опросники для оценки третьих лиц, визиты на площадки производителей, формальные сертификации (например, по ISO 27001) для оценки возможностей и практик критичных поставщиков;

• Внедрение формальных процессов мониторинга и переоценки существующих поставщиков для выявления возможных изменений их риск-профилей;

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

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

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

• Включение тренингов по вопросам управления киберрисками цепочки поставок в корпоративный процесс внутреннего обучения;

• Внедрение аспектов управления киберрисками цепочки поставок в жизненный цикл продуктов и систем, а также внедрение соответствующих логически связанных, повторяемых, задокументированных процессов в создание систем, практики обеспечения кибербезопасности, процедуры приобретения ИТ-продуктов и услуг;

• Внедрение внутрикорпоративных требований по управлению киберрисками цепочки поставок в контрактные требования для поставщиков, разработчиков, системных интеграторов, сервис-провайдеров;

• Включение критически важных поставщиков в планы и тестирования по реагированию на киберинциденты, обеспечению непрерывности и восстановлению работоспособности;

• Взаимодействие с поставщиками, разработчиками, системными интеграторами, сервис-провайдерами для повышения их практик обеспечения кибербезопасности;

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

Развивающие рекомендации включают в себя следующие пункты:

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

• Применение количественных методов оценки анализа рисков для повышения точности оценки рисков цепочки поставок, повышения возможностей руководства компании для определения оптимальных способов реагирования на киберриски, а также количественного измерения эффективности реагирования на киберриски цепочки поставок;

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

Новости об обнаружении опасных уязвимостей в популярных приложениях и операционных системах публикуются на профильных ресурсах практически ежедневно, при этом наиболее громкие уязвимости получают даже имена собственные - так было, например, с HeartBleed (CVE-2014-0160), EternalBlue (CVE-2017-0144), Log4Shell (CVE-2021-44228). Обнаружение подобного рода уязвимостей, ошибок конфигурирования или реализации протоколов становится значимым событием, поскольку вслед за публикацией исследователем или вендором технической информации злоумышленники начинают разрабатывать эксплойты в надежде атаковать пока что непропатченные системы.

Документ NIST SP 800-218 "Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities" («Фреймворк создания безопасного программного обеспечения: Рекомендации по снижению рисков программных уязвимостей») содержит рекомендации по использованию фреймворка создания безопасного программного обеспечения - набора высокоуровневых практик безопасной разработки ПО. Следование ему поможет сократить количество уязвимостей в коде, снизить потенциальный ущерб от их эксплуатации, устранить корневые причины возникновения уязвимостей.

В документе NIST SP 800-218 вводится термин Secure Software Development Framework (SSDF), т.е. фреймворк создания безопасного программного обеспечения, который является набором базовых целесообразных практик для разработки ПО. Внедрение фреймворка SSDF позволит организации выполнить следующие рекомендации по безопасной разработке ПО:

1. Подготовка людей, процессов и технологий к осуществлению циклов безопасной разработки;

2. Защита всех программных компонентов от несанкционированного доступа и вредоносного вмешательства;

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

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

В документе дается определение SDLC (software development life cycle, жизненный цикл разработки программного обеспечения) как формальной или неформальной методологии по проектированию, созданию, поддержке программного обеспечения, включая микропрограммы («прошивки») аппаратных устройств. Несмотря на большое количество методологий разработки ПО (каскадная модель, спиральная модель, agile, DevOps и другие), применение в любой из них фреймворка SSDF и практик безопасной разработки поможет снизить количество уязвимостей в релизах, снизить потенциальный ущерб от эксплуатации оставшихся уязвимостей, а также выявить и устранить корневую причину возникающих уязвимостей для предотвращения их появления в дальнейшем. В NIST SP 800-218 подчеркивается важность фундаментального правила безопасной разработки софта: стратегия "Shifting Left", т.е. буквально «сдвиг влево», подразумевает максимально ранее включение вопросов безопасности кода в жизненный цикл разработки продуктов. Решение вопросов безопасности разрабатываемого продукта на самом раннем этапе проектирования и написания технического задания, с дальнейшим контролем на этапах непосредственной разработки, выпуска, внедрения, обновления, поддержки поможет снизить будущие затраты на устранение уязвимостей и последствий от их эксплуатации. В документе NIST SP 800-218 подчеркивается, что указанные во фреймворке рекомендации являются гибкими и высокоуровневыми, что позволяет применять их вне зависимости от специфики разработки, сектора экономики, IT/OT/IoT-инфраструктуры, методологии разработки, применяемого стека технологий или языка программирования. В случае же использования сервисной модели (SaaS, PaaS, CaaS и т.д.), будет разумно применять принцип разделения ответственности между провайдерами, разработчиками, тенантами.

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

1. Подготовка организации:

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

1.1.1. Выявление, документирование и периодическая актуализация требований безопасности к инфраструктуре и процессам разработки ПО;

1.1.2. Выявление, документирование и периодическая актуализация требований к разрабатываемому компанией ПО;

1.1.3. Доведение требований безопасности всем третьим лицам, поставляющим программные компоненты организации для повторного их использования при создании ПО.

1.2. Распределение ролей и ответственных:

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

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

1.2.3. Получение поддержки руководства компании и доведение позиции топ-менеджмента до всех ответственных и заинтересованных лиц.

1.3. Внедрение средств автоматизации безопасной разработки:

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

1.3.2. Следование рекомендациям при внедрении, использовании, поддержке инструментов автоматизации процессов безопасной разработки;

1.3.3. Настройка инструментов автоматизации процессов безопасной разработки для создания цифровых артефактов их применения при разработке ПО.

1.4. Разработка и применение критериев оценки безопасности разработки ПО:

1.4.1. Определение критериев оценки и их контроль в рамках цикла безопасной разработки ПО;

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

1.5. Внедрение и поддержка безопасной среды разработки ПО:

1.5.1. Разделение и защита всех инфраструктурных сегментов, применяемых при разработке ПО (например, сегменты разработки, сборки, тестирования, распространения и т.д.);

1.5.2. Обеспечение кибербезопасности и защищенная настройка конечных точек разработчиков, архитекторов, тестировщиков и т.д.

2. Защита программного обеспечения:

2.1. Защита всех видов программного кода от неавторизованного доступа и изменения:

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

2.2. Предоставление механизма для проверки целостности и аутентичности программного продукта:

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

2.3. Архивация и защита всех версий продукта в целях поиска и устранения уязвимостей, обнаруженных после релиза:

2.3.1. Безопасная архивация файлов и сопутствующей информации для каждого релиза продукта;

2.3.2. Сбор, защита, актуализация и передача заинтересованным лицам данных о всех программных компонентах каждого релиза ПО, например, через каталог компонент программного обеспечения (англ. SBOM, Software Bill Of Materials).

3. Создание безопасного программного продукта:

3.1. Разработка ПО для соответствия требованиям безопасности и смягчения рисков:

3.1.1. Использование вариантов моделирования киберрисков (например, моделирование угроз, моделирование кибератак, анализ поверхности атак) для оценки рисков использования программного обеспечения;

3.1.2. Отслеживание и поддержка требований безопасности ПО, рисков, принятых архитектурных решений;

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

3.2. Пересмотр архитектуры ПО для проверки соответствия требованиям безопасности и результатов анализа киберрисков:

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

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

3.3.1. Приобретение/получение и поддержка хорошо защищенных и отлаженных программных компонент (библиотек, модулей, фреймворков) из коммерческих, open source и иных источников;

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

3.3.3. Проверка соответствия приобретенных/полученных программных компонент требованиям безопасности компании, с перепроверками в течение их жизненного цикла.

3.4. Создание исходного кода в соответствии с практиками написания безопасного кода:

3.4.1. Следование всем практиками безопасного программирования, применяемым в соответствующем языке программирования и среде разработки.

3.5. Настройка процессов компиляции, интерпретации и сборки для повышения безопасности исполняемых модулей:

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

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

3.6. Проведение изучения и/или анализа человекочитаемого кода для выявления уязвимостей и проверки соответствия требованиям безопасности:

3.6.1. Выбор способов изучения кода (вручную квалифицированным сотрудником) или анализа кода (с привлечением средств автоматизации) в соответствии с требованиями организации;

3.6.2. Проведение изучения и/или анализа кода на соответствие корпоративным стандартам безопасной разработки ПО, с документированием и анализом всех выявленных проблем, а также с выдачей рекомендаций.

3.7. Проведение тестирования исполняемого кода для выявления уязвимостей и проверки соответствия требованиям безопасности:

3.7.1. Выявление необходимости тестирования исполняемого кода для поиска уязвимостей, не обнаруженных на предыдущих этапах;

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

3.8. Настройка ПО для использования наиболее безопасных настроек по умолчанию:

3.8.1. Создание baseline минимальных требований безопасности путем выявления всех настроек, которые могут повлиять на безопасность, с выработкой настроек по умолчанию, которые не будут снижать защищенность ПО, среды установки, сервисов;

3.8.2. Внедрение настроек по умолчанию и их документирование для администраторов ПО.

4. Реагирование на уязвимости:

4.1. Выявление и подтверждение уязвимостей на постоянной основе:

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

4.1.2. Проведение изучения, анализа и/или тестирования кода ПО для выявления или подтверждения наличия ранее не выявленных уязвимостей;

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

4.2. Оценка, приоритизация, устранение уязвимостей:

4.2.1. Проведение анализа каждой уязвимости для сбора достаточной информации о риске её эксплуатации для планирования устранения данной уязвимости или выполнения иных мер по реагированию на киберриск;

4.2.2. Планирование и внедрение мер по реагированию на обнаруженные уязвимости.

4.3. Анализ уязвимостей для выявления корневой причины их возникновения:

4.3.1. Проведение анализа обнаруженных уязвимостей для выявления корневой причины их возникновения;

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

4.3.3. Изучение программных продуктов для нахождения однотипных уязвимостей и проактивного устранения этого класса уязвимостей;

4.3.4. Пересмотр процессов безопасной разработки ПО и их обновление для предотвращения или снижения вероятности повторения корневых причин уязвимостей в обновлениях и новом ПО.

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

Документ NIST SP 800-47 Rev. 1 "Managing the Security of Information Exchanges" («Управление безопасностью информационных обменов») содержит рекомендации по выстраиванию процессов обмена информацией без привязки к конкретным технологиям и форматам передачи данных, фокусируясь на согласовании процессов обмена информацией и обеспечении её защиты, а также на выполнении соглашений между участниками обмена. Целями защищенного обмена являются управление соответствующими киберрисками и обеспечение защищенности информации на уровне не меньшем, чем в организации-источнике информации, что достигается применением мер ИБ и подписанием юридически значимых договоренностей.

В рамках публикации NIST SP 800-47 рассматривается защищенный доступ и обмен данными между информационными системами, которые управляются различными организациями/подразделениями или которые пересекают границы авторизации систем (термин из публикации по управлению киберрисками NIST SP 800-37, означающий формальную зону ответственности за ИТ-системы). Для управления и обеспечения защиты информационного обмена в документе NIST SP 800-47 предлагается использовать структурированный подход, состоящий из 4 фаз:

• Планирование информационного обмена (выработка соглашений, согласование методов, оценка систем и ИТ-инфраструктуры);

• Установление защищенного обмена (внедрение и конфигурирование СЗИ, подписание соглашений);

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

• Завершение информационного обмена (плановое, с сохранением работоспособности не участвовавших в обмене систем, или внеплановое, например, в результате инцидента ИБ).

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

Следуя положениями NIST SP 800-47, защищенный обмен информации следует выстраивать в соответствии со следующими этапами:

1. Планирование информационного обмена:

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

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

1.3. Применение к используемым при информационном обмене системам положений фреймворка управления рисками NIST SP 800-37 ”Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy” («Фреймворк управления рисками для информационных систем и организаций: жизненный цикл систем для обеспечения безопасности и конфиденциальности»).

1.4. Определение требований по защите информации при обмене, учитывая следующие факторы:

1.4.1. Применимые законодательные нормы, стандарты, политики, рекомендации.

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

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

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

1.4.5. Способ информационного обмена (например, обмен файлами по электронной почте, общий доступ к облачному хранилищу, настройка VPN-туннеля между сетями компаний-участников обмена).

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

1.4.7. Зависимость ИТ-систем, участвующих в информационном обмене, от поступающей по каналам обмена информации или от самого канала обмена, с возможной выработкой планов на случай чрезвычайных ситуаций, резервированием каналов обмена, обеспечением избыточности ИТ-систем.

1.4.8. Детальные требования к аппаратному обеспечению с оценкой достаточности текущих ресурсов и с учетом вопросов совместимости оборудования.

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

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

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

1.4.12. Определение ролей и ответственных за создание, поддержку и управление информационным обменом, с учетом профессиональных компетенций сотрудников.

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

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

1.4.15. Наименование элементов в базах данных для использования единообразного совместимого формата.

1.4.16. Назначение владельцев информации и ответственных при информационном обмене: становится ли организация, принявшая информацию, владельцем этой информации, или она становится лишь ответственным (англ. custodian), а владельцем остается организация-источник.

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

1.5. Подписание соглашений об информационном обмене, уровень и значимость которых зависят от важности информации (т.е. потенциального ущерба от нарушения её защищенности) и от способа обмена информацией. В соглашениях должны быть прописаны порядок и способы использования информации и системы обмена, роли и ответственные, обязательные к выполнению условия совместной работы. В документе NIST SP 800-47 приводятся возможные типы соглашений: соглашение об обеспечении безопасности соединения (Interconnection Security Agreement,ISA), меморандум о взаимопонимании (Memoranda of Understanding, MOU), меморандум о договоренности (Memoranda of Agreement, MOA), соглашение об обмене информацией (Information Exchange Agreement, IEA), соглашение об уровне обслуживания (Service-Level Agreement, SLA), пользовательское соглашение (User Agreement), соглашение о доступе (Access Agreement), соглашение о приемлемом использовании (Acceptable Use Agreement), соглашение о неразглашении (Non-Disclosure Agreement, NDA), внутрикорпоративные форматы соглашений, а также системы контроля и учета, включая SGRC-системы.

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

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

2. Установление защищенного обмена:

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

2.2. Выполнение плана внедрения (после его согласования):

2.2.1. Установка и/или настройка программного и аппаратного обеспечения.

2.2.2. Внедрение и/или настройка средств защиты информации.

2.2.3. Интеграция приложений/служб для обмена информацией.

2.2.4. Проведение операционного и security-тестирования для оценки корректности работы системы обмена информацией и выполнения в ней всех требований по информационной безопасности.

2.2.5. Проведение обучения для сотрудников, участвующих в информационном обмене.

2.2.6. Актуализация планов обеспечения безопасности информационного обмена для соответствия изменениям в ИТ-инфраструктуре и бизнес-процессах.

2.2.7. Проведение аудитов уровня кибербезопасности и согласование изменений в ИТ-системах, участвующих в информационном обмене.

2.3. Запуск информационного обмена с мониторингом и документированием корректности выполнения процессов обмена, обращений пользователей системы обмена, событий безопасности в задействованных ИТ-системах.

3. Поддержка информационного обмена:

3.1. Поддержка четкого порядка коммуникаций между организациями-участниками для оперативного решения вопросов информационного обмена.

3.2. Поддержка систем и их компонент, использующихся для информационного обмена.

3.3. Управление учетными записями пользователей системы обмена информацией.

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

3.5. Анализ журналов безопасности для выявления подозрительных или необычных действий.

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

3.7. Координация планов на случай чрезвычайных ситуаций организаций-участников информационного обмена.

3.8. Управление внесением изменений с оценкой влияния вносимых изменений на обмен информацией и своевременным уведомлением организаций-участников.

3.9. Пересмотр и актуализация соглашений (между организациями-участниками) и планов обеспечения кибербезопасности системы обмена информацией.

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

4. Завершение информационного обмена:

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

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

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

Процессы цифровизации в последние годы затронули множество секторов экономики, и, в частности, современное производство, добычу полезных ископаемых, энергетику, транспорт, медицину уже невозможно представить без автоматизированных систем управления технологическими процессами (АСУТП, англ. Industrial Control Systems, ICS), SCADA-систем, программируемых логических контроллеров (ПЛК), распределенных систем управления. Данные средства являются составными частями OT-инфраструктуры (от Operational Technology), которые могут взаимодействовать с классической IT-инфраструктурой и являться объектами кибератак.

Зачастую компоненты OT-сетей выполняют критически важные задачи, прерывание или компрометация которых может привести к серьезным последствиям. Документ NIST SP 800-82 Rev. 2 "Guide to Industrial Control Systems (ICS) Security" («Руководство по обеспечению безопасности автоматизированных систем управления») содержит рекомендации по обеспечению безопасности OT-сетей и компонент АСУП с учетом специфических киберрисков и требований по кибербезопасности и надежности.

Итак, документ NIST SP 800-82 сфокусирован на обзоре технологий современных OT-сетей и компонент АСУП, описании специфичных для них угроз и уязвимостей, предоставлении рекомендаций по обработке связанных киберрисков. Подчеркивается, что современные АСУТП становятся всё более IP-ориентированными, а также возрастает связность OT-сегмента с IT-инфраструктурой компании, что, в свою очередь, увеличивает вероятность эксплуатации уязвимостей и возникновения киберинцидентов. В OT-сетях применяются разнообразные устройства: датчики, преобразователи, актюаторы (исполнительные устройства), которые посредством IoT-устройств связаны с IT-инфраструктурой для обработки поступающей информации. При этом специфика АСУТП такова, что приоритет отдаётся бесперебойности функционирования, доступности и целостности над конфиденциальностью, а для обеспечения защиты информации должны применяться средства, спроектированные с учетом нюансов OT-сетей.

Основными особенностями АСУТП являются:

1. Повышенные требования к своевременности и производительности выполняемых операций: работа OT-компонент в режиме, близком к реальному времени, а также зависимость/влияние на физические характеристики среды функционирования.

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

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

4. Физические эффекты: непосредственное воздействие АСУТП на физические процессы.

5. Управление системами: компоненты АСУТП требуют иных навыков и опыта, нежели ИТ-системы, и управлять АСУТП должны специально обученные квалифицированные инженеры.

6. Ресурсные ограничения: компоненты АСУТП отличаются от ИТ-систем своими аппаратными и программными характеристиками, а также могут не обладать функционалом, необходимым для реализации требований информационной безопасности.

7. Взаимодействие: протоколы передачи данных и среда передачи данных могут быть проприетарными и нетиповыми.

8. Управление изменениями: патч-менеджмент, столь важный для кибербезопасности, в АСУТП должен проводиться лишь после тщательного тестирования вендором и на площадке (в тестовом контуре), с заранее составленным планом обновления, с учетом возможного применения устаревших программных компонент в АСУТП.

9. Управление технической поддержкой: производители АСУТП, как правило, оказывают выделенную поддержку закупленного оборудования, что осложняет получение технической поддержки от другой компании.

10. Жизненный цикл компонентов: АСУТП рассчитаны на работу в течение 10-15 лет, что усложняет быструю замену устаревших компонент.

11. Расположение: географическая распределенность и, зачастую, труднодоступность компонент АСУТП и OT-сетей усложняет их администрирование.

Для обеспечения информационной безопасности OT-сетей и компонентов АСУТП в документе NIST SP 800-82 предложено реализовать следующие принципы:

1. Разграничение логического и сетевого доступа к OT-сети и компонентам АСУТП с использованием шлюзов доступа, DMZ-подсетей, межсетевых экранов, VLAN-сетей, различных учетных записей и методов аутентификации для IT-сети и OT-сети.

2. Разграничение физического доступа к компонентам АСУТП.

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

4. Предотвращение несанкционированного изменения данных (как минимум при передаче и хранении).

5. Обработка событий и киберинцидентов путем мониторинга состояния OT-сетей и компонентов АСУТП.

6. Обеспечение отказоустойчивости с помощью избыточности программных и аппаратных компонент, безопасного аварийного завершения работы одного компонента без нарушения работы других компонентов АСУТП, планового переключения из автоматического в полуавтоматический, а затем в ручной режим в случае аварии или вредоносного воздействия.

7. Восстановление после киберинцидентов.

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

1. Разработка политик, процедур, программ обучения специально для OT-сетей и компонентов АСУТП.

2. Обеспечение кибербезопасности на протяжении всего жизненного цикла OT-сетей и компонентов АСУТП.

3. Применение сетевой топологии с размещением критичных компонент OT-сетей и компонентов АСУТП в самом защищенном сегменте.

4. Сетевое разграничение IT-сетей и OT-сетей с применением межсетевых экранов, DMZ-подсетей, односторонних шлюзов, диодов данных.

5. Обеспечение избыточности критичных компонент и обслуживающих их сетей.

6. Применение принципов отказоустойчивости при проектировании и внедрении OT-сетей и компонентов АСУТП.

7. Использование современных технологий обеспечения безопасности (при возможности).

8. Применение криптографических средств для защиты передающихся и хранящихся данных.

9. Установка обновлений после тщательного планирования и тестирования.

10. Мониторинг и анализ событий аудита информационной безопасности OT-сетей и компонентов АСУТП.

11. Применение надежных и безопасных сетевых протоколов и служб (при возможности).

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

Неуправляемое и не принадлежащее компании устройство может быть случайно или намеренно заражено вредоносным ПО, не получать своевременные обновления для системного и прикладного софта, также личным устройством могут не поддерживаться корректные настройки безопасности (длина пароля для разблокировки, шифрование данных, подключение к открытым беспроводным сетям, настройки конфиденциальности и т.д.). Одним из решений данных сложностей является концепция BYOD (Bring Your Own Device, принеси свое собственное устройство), представляющая собой структурированный систематический подход к выбору, настройке, предоставлению защищенного доступа личным устройствам сотрудников к корпоративным ресурсам. Рекомендациям по внедрению BYOD-концепции для смартфонов под управлением ОС Android и Apple iOS посвящен документ NIST SP 1800-22 (Draft) "Mobile Device Security: Bring Your Own Device (BYOD)" («Безопасность мобильных устройств: принеси свое собственное устройство»).

Итак, документ NIST SP 1800-22 предлагает рекомендации по использованию BYOD-концепции для обеспечения:

• защиты конфиденциальных корпоративных данных от несанкционированного доступа при утере или краже устройств (смартфонов под управлением ОС Android и Apple iOS);

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

• повышения кибербезопасности мобильных устройств и приложений путем применения специализированных технологий;

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

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

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

В документе также отмечаются возможные сложности при внедрении BYOD, такие как:

• разнообразие версий ОС и «оболочек» для них (актуально в основном для устройств на базе ОС Android);

• разнообразие моделей Android-смартфонов от различных производителей;

• разнообразие функциональных (программных и аппаратных) возможностей портативных устройств, требующих анализа и защиты;

• сложности в применении классических СЗИ для мобильных устройств и, как следствие, необходимость выбора, закупки, эксплуатации, поддержки специализированных защитных решений;

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

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

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

Внедрение BYOD рассмотрено в документе NIST SP 1800-22 на примере типовой организации, целями которой при использовании концепции использования личного устройства для служебных нужд могут быть:

• отделение личной информации от рабочей путем разграничения информационных потоков между рабочими и личными приложениями;

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

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

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

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

• контроль и ограничение сбора информации об устройстве и его использовании сотрудником со стороны BYOD-системы.

Реализовать данные цели предлагается путем применения следующих технологий и подходов:

1. Среда доверенного выполнения (Trusted Execution Environment, TEE)

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

2. Система корпоративного управления мобильными устройствами (Enterprise Mobility Management, EMM)

EMM-решения позволяют управлять некоторыми функциями смартфонов, прошедших процедуру регистрации (англ. enrollment) в корпоративной BYOD-системе. Такие решения, как правило, содержат серверную часть с политиками и настройками, применяющимися к различным группам устройств и пользователей, а также клиентскую часть в виде агента, устанавливаемого как приложение на смартфон и взаимодействующего с EMM-сервером. EMM-решение выполняет функции управления мобильными устройствами (Mobile Device Management, MDM), включающие в себя установку на устройства конфигурационных профилей, настройку политик безопасности, контроль соответствия настроек устройства примененным политикам. Агентская часть оповещает пользователя о проблемах с безопасностью и о несоответствии устройства корпоративным политикам и настойкам, а также разделяет личные и рабочие данные (с помощью технологии контейнеризации и шифрования) и автоматически исправляет некоторые ошибки и несоответствия. На основании данных о состоянии устройства серверной частью принимается решение о допуске устройства к корпоративным сервисам и данным.

3. VPN-туннелирование

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

4. Служба проверки приложений (Mobile Application Vetting Service)

Установленные пользователем приложения могут быть как целенаправленно вредоносными, так и безобидными, но содержащими уязвимости или избыточный функционал. Для контроля приложений используется клиент службы проверки приложений, который по набору статических, динамических и поведенческих показателей может сделать вывод о безопасности того или иного установленного приложения. В результате анализа устройству присваивается определенный уровень киберриска, по значению которого устройство допускается до корпоративных сервисов и данных. Например, устройство с видоизмененной прошивкой, «рутованное» или с измененным загрузчиком (bootloader), скорее всего, будет иметь очень высокий риск-балл и не сможет получить доступ к рабочим данным или установить VPN-соединение с корпоративным VPN-шлюзом.

5. Защита от мобильных угроз (Mobile Threat Defense, MTD)

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

6. Встроенные в мобильные ОС механизмы обеспечения кибербезопасности

6.1. Secure Boot (защищенная загрузка): процесс последовательной загрузки компонент ОС с проверкой целостности и подлинности загружаемого кода, начиная с загрузчика (bootloader);

6.2. Device Attestation (проверка устройства): проверка целостности и подлинности всех компонент ОС и запускаемого ПО;

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

6.4. iOS App Transport Security (безопасность iOS-приложений на транспортном уровне): принудительное использование протокола TLS для защиты передаваемых приложениями данных через интернет (включено по умолчанию для iOS 9.0 и старше);

6.5. Android Network Security Configuration (конфигурация сетевой безопасности Android): запрет по умолчанию на передачу трафика в незащищенном виде (cleartext), с возможностью выбора доверенных центров сертификации и выпуском соответствующих цифровых сертификатов.

В современном цифровом мире киберугрозы эволюционируют настолько быстро и приобретают такие масштабы, что специалисты и методологи информационной безопасности вынуждены регулярно пересматривать концепции и парадигмы защиты информации. Периодически, раз в 2-3 года, на рынке средств защиты информации появляется новый класс продуктов, обещающий защиту от новейших киберугроз: так было с Next Generation Firewall (межсетевые экраны нового поколения), с системами DLP (решения для предотвращения утечек данных), с SIEM-системами и далее с решениями по защите облачных платформ, системами выявления аномалий, платформами для работы с данными киберразведки.

Сейчас же речь пойдет об относительно новой концепции "Zero Trust Architecture" («Архитектура нулевого доверия»), подразумевающей доскональную непрерывную проверку всех субъектов доступа (пользователи, сущности, устройства) вне зависимости от их местоположения (корпоративная сеть, интернет, удаленная работа через VPN). Данный подход описан в документе NIST SP 800-207 "Zero Trust Architecture" («Архитектура нулевого доверия»), который содержит описание концепции создания сетевой архитектуры по принципу нулевого доверия и примеры её использования для повышения информационной безопасности предприятия.

Итак, концепция непрерывной проверки и аутентификации всех субъектов сетевого доступа родилась уже достаточно давно - компания Cisco говорила и правильности такого подхода еще в начале 2000-х годов. Со временем многие СЗИ реализовали свои варианты данного подхода, например, в виде «условного доступа» (англ. conditional access), когда для аутентификации и получения доступа к корпоративным ресурсам сотруднику недостаточно ввести корректные логин и пароль: устройство пользователя должно отвечать определенным критериями (версия ОС, установленные обновления безопасности, работающий антивирус), подключаться из определенного географического региона (например, из стран, в которых у компании есть офисы), а также не иметь незакрытых инцидентов информационной безопасности (на данном устройстве или у данного пользователя). Кроме того, может учитываться время подключения (рабочее или неурочное время), история устройства (как давно оно успешно подключалось к корпоративной сети), наличие корректного второго фактора аутентификации (например, цифрового сертификата устройства), данные из систем киберразведки (анализ внешнего IP-адреса и хэшей запущенных исполняемых файлов подключающегося устройства).

В документе NIST SP 800-207 указано, что в архитектуре нулевого доверия (сокращенно ZTA, Zero Trust Architecture) аутентификация и авторизация субъектов доступа выполняется до установления сетевого соединения с корпоративными ресурсами, а применять ZTA можно для эффективного обеспечения кибербезопасности ИТ-активов (данных, сервисов, учетных записей, бизнес-процессов) при удаленной работе, использовании BYOD-концепции и при работе с облачными платформами. Концепция соответствует трендам современного состояния киберпространства, в котором больше нет сетевых периметров, а пользователи получают доступ к рабочим ресурсам с разных устройств и из разных географических точек. При этом субъектам доступа должны быть предоставлены гранулированные, минимально необходимые права доступа, а вся корпоративная сеть может считаться изначально недоверенной, т.е. вероятно ранее скомпрометированной - это допущение помогает выстроить логическую модель угроз в ZTA-концепции. Иначе говоря, для каждого субъекта доступа (пользователи, сущности, устройства) непрерывно выполняются проверки их аутентичности и прав доступа, только после этого устанавливается контролируемое сетевое соединение по определенному порту, протоколу и к определенному IP-адресу назначения внутри корпоративной сети.

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

1. Все источники данных и вычислительные сервисы считаются ИТ-ресурсами (объектами доступа), включая личные устройства сотрудников, которые подключаются к корпоративной сети.

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

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

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

5. Производится контроль и мониторинг состояния кибербезопасности всех ИТ-активов, отсутствует доверие «по умолчанию».

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

7. Организация собирает максимум информации об актуальном состоянии активов, сетевой инфраструктуре, сетевом взаимодействии и использует эти данные для повышения уровня киберзащищенности.

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

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

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

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

4. Видимость сети: при передаче шифрованного трафика компания не сможет адекватно анализировать передающиеся данные и предотвращать киберугрозы; для повышения качества анализа такого трафика можно применять методы машинного обучения или механизмы SSL/TLS-инспекции.

5. Хранение сетевой и системной информации: компоненты ZTA-архитектуры содержат в себе множество ценной информации, которая может стать целью хакеров.

6. Зависимость от конкретных вендоров и решений: при выходе из строя оборудования для ZTA или при смене вендора компания может столкнуться с серьезными сетевыми сбоями и простоями.

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

Для внедрения ZTA-архитектуры документ NIST SP 800-207 рекомендует выполнить следующие действия:

1. Определить всех субъектов доступа (пользователи, сущности, устройства), которым надо будет предоставлять доступ к ИТ-активам с помощью модели ZTA.

2. Определить ИТ-активы компании (провести инвентаризацию).

3. Определить ключевые бизнес-процессы и оценить их киберриски для поэтапного внедрения ZTA от менее критичных процессов к более критичным.

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

5. Выбрать подходящее техническое решение для реализации ZTA-подхода.

6. Провести пилотное внедрение и осуществлять мониторинг работы ZTA-решения для выбранных бизнес-процессов; возможно, провести пилотирование в режиме аудита (без блокировок).

7. Расширить границы проекта внедрения ZTA на другие бизнес-процессы.

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

Выход был найден: крупные компании стали постепенно внедрять облачные системы вычислений, что вкупе с применением технологий виртуализации и контейнеризации давало возможность уйти от привязки к физическому «железу», перейдя на новый вид абстракции при работе ИТ-систем. Затем такие облачные решения стали отдельным и достаточно прибыльным бизнесом: крупные ИТ-гиганты стали сдавать в аренду свои вычислительные мощности компаниям-арендаторам («тенантам»), которые стремились снизить свои капитальные затраты на оборудование (CAPEX) и перейти на более гибкую и прогнозируемую модель операционных расходов (OPEX) с возможностью переложить часть задач по обслуживанию инфраструктуры на специалистов Cloud-провайдеров. Публикация NIST SP 800-210 "General Access Control Guidance for Cloud Systems" («Общие рекомендации по контролю доступа к облачным системам») описывает принципы контроля доступа к облачным инфраструктурам с указанием специфики для каждой из сервисных моделей предоставления вычислительных услуг.

Итак, облачные инфраструктуры можно разделить по принципу работы на следующие типы:

1. Public cloud (публичные облака) - провайдер облачных услуг предоставляет заказчику свою инфраструктуру и сервисы на коммерческой основе, как правило, по подписке.

2. Private cloud (частные облака) - организация размещает часть своей инфраструктуры в некотором своем или арендуемом ЦОД (центре обработки данных) и полностью контролирует все аппаратные и программные компоненты.

3. Hybrid cloud (гибридные облака) - организация совмещает работу с публичным и частным облаком, размещая свои приложения и данные в зависимости от удобства и потребностей в той или иной инфраструктуре.

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

Для работы с облачными инфраструктурами, как правило, предоставляются следующие варианты:

1. IaaS (infrastructure as a service) - предоставление услуги по модели «инфраструктура как сервис», когда облачный провайдер предоставляет только своё аппаратное обеспечение, сетевой доступ и гипервизор системы виртуализации, а заказчикам дается возможность установить свои операционные системы, прикладное и системное ПО, бизнес-приложения.

2. PaaS (platform as a service) - предоставление услуги по модели «платформа как сервис», когда облачный провайдер предоставляет установленную операционную систему (как правило, давая на выбор несколько вариантов ОС на базе Winows и Linux), а заказчики уже устанавливают только свое программное обеспечение.

3. SaaS (software as a service) - предоставление услуги по модели «программное обеспечение как сервис», когда облачный провайдер предоставляет конечному заказчику предварительно установленное бизнес-приложение с некоторыми возможностями по его настройке и модификации.

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

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

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

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

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

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

В публикации NIST SP 800-210 приводятся рекомендации по обеспечению контроля доступа для каждой из сервисных моделей (IaaS, PaaS, SaaS).

1. Рекомендации по обеспечению контроля доступа для IaaS-модели.

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

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

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

1.4. Защита доступа по API: облачные платформы могут предоставлять своим клиентам доступ к API для управления гостевыми виртуальными машинами, что требует контроля доступа к таким API.

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

2. Рекомендации по обеспечению контроля доступа для PaaS-модели.

2.1. Защита данных: данные, разделяемые между PaaS-приложениями, следует защищать от несанкционированного доступа с помощью встроенных функций безопасности гостевых ОС (например, с помощью PaaS-контейнеризации), а также путем контроля доступа к памяти на уровне гипервизора.

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

2.3. Контроль доступа к данным в PaaS: защита памяти PaaS-сервисов может реализовываться путем очистки кэша данных процессора при переключении контекстов, а также путем применения централизованной системы контроля доступа на основе политик, которые применяются ко всем применяемым клиентом PaaS-сервисам.

3. Рекомендации по обеспечению контроля доступа для SaaS-модели.

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

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

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

3.4. Управление реплицированными данными: множественные копии данных (реплики) должны управляться синхронизируемой политикой контроля доступа.

3.5. Управление мульти-арендностью (multi-tenancy): обработка данных разных пользователей в одном SaaS-приложении требует применения строгих правил контроля доступа на основе моделей ABAC (атрибутная модель), RBAC (ролевая модель), CBAC (контекстная модель). Кроме того, следует учитывать киберриски эксплуатации уязвимостей самого SaaS-приложения в целях получения несанкционированного доступа.

3.6. Управление атрибутами и ролями: выбор типов атрибутов доступа и ролей на этапе проектирования SaaS-систем определяет надежность контроля доступа. Малое количество атрибутов может привести к недостаточной гибкости политик контроля доступа, а большое - к чрезмерной сложности модели доступа.

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

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

3.9. Контроль доступа к данным в SaaS: системы авторизации в мульти-арендной среде могут быть централизованными (одна база авторизаций для всех клиентов), децентрализованными или гибридными (каждый тенант отвечает за своих клиентов в выделенных базах авторизации). Для эффективного использования политик контроля доступа можно использовать службу федерации авторизации (англ. authorization federation), которая представляет собой брокер авторизации между SaaS-провайдером и клиентом.

Использование мобильных устройств (смартфонов, планшетов) в корпоративной среде стало обыденностью уже 5-10 лет назад, но с момента начала пандемии применение таких устройств стало всеобъемлющим. До этого момента лишь продвинутые в техническом плане компании давали возможность использования корпоративных или личных устройств для решения бизнес-задач и обработки конфиденциальной служебной информации. Использование смартфонов и планшетов не только повышает эффективность работы сотрудников, но и привносит специфические киберриски, уровень которых существенно возрос в последнее время (уязвимости в мобильных ОС и приложениях, в аппаратном обеспечении, в сетях и протоколах передачи данных, а также вредоносное и шпионское ПО для мобильных устройств). Предварительная версия (драфт) документа NIST SP 800-124 Rev. 2 (Draft) "Guidelines for Managing the Security of Mobile Devices in the Enterprise" («Рекомендации по управлению безопасностью мобильных устройств на предприятии») предлагает рекомендации по обеспечению безопасности мобильных устройств с описанием возможных стратегий и технологий защиты на протяжении всего жизненного цикла их использования.

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

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

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

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

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

1.3. Доступ к информационным ресурсам компании с небезопасно настроенного устройства или с применением непроверенных приложений, установленных пользователем намеренно, случайно или в результате хакерской атаки.

1.4. Кража учетных данных в рамках фишинговой атаки (ввод логина и пароля на контролируемом злоумышленником веб-ресурсе, ссылку на который присылают через текстовое сообщение, мессенджер или через email).

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

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

1.7. Перехват данных, передающихся по беспроводным каналам между устройством и информационными системами компании (атаки вида Man-in-the-Middle, MitM).

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

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

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

1.11. Утечка данных в результате синхронизации данных корпоративного мобильного устройства со сторонним облачным сервисом (например, Apple iCloud, Google Drive, Яндекс-Диск и т.д.) или с недоверенным физическим устройством (например, личным ноутбуком).

1.12. Риски «теневого ИТ»: самостоятельное использование сотрудниками информационных систем или сервисов, предварительно не согласованных Департаментами ИТ/ИБ, как следствие невозможности согласовать использование необходимых систем или как следствие большего субъективного удобства сторонних решений.

2. Киберугрозы системам корпоративного управления мобильными устройствами (решения класса EMM - Enterprise Mobility Management):

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

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

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

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

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

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

2. Внедрение технологий обеспечения кибербезопасности мобильных технологий, таких как Mobile Device Management (MDM), Enterprise Mobility Management (EMM), Mobile Threat Defense (MTD), Mobile Application Vetting (MAV), Data Loss Prevention (DLP). Системы MDM и EMM предназначены для управления мобильными устройствами (корпоративными и личными, использующимися для выполнения служебных задач), для настройки конфигураций безопасности таких устройств, контроля и предоставления доступа к корпоративным данным на основании сведений о состоянии безопасности устройства, мониторинга состояния ИБ устройства (вредоносная активность, необновленная ОС, «рутирование» устройства, безопасность подключенной беспроводной сети). Системы класса MTD позволяют зарегистрировать вредоносную активность на уровне ОС или приложений, выявить уязвимости софта или конфигураций устройства, сообщать о подключении к вредоносным веб-сервисам или небезопасным сетям. Решения класса MAV позволяют проводить аудит безопасности используемых в организации приложений и программных библиотек для выявления уязвимостей, небезопасных конфигураций, устаревших компонент с дальнейшим устранением выявленных недостатков (оповещение разработчиков, запрет на публикацию уязвимого приложения в корпоративном «магазине», удаленное отключение или деинсталляция приложения на устройствах). Системы DLP предназначены для защиты от утечки данных в том числе и с мобильных устройств, поэтому DLP-компоненты для Android и iOS являются важной составляющей корпоративной системы обеспечения кибербезопасности.

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

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

5. Защита всех новых мобильных устройств перед выдачей пользователю и предоставлением доступа к корпоративным данным. Перед передачей устройства сотруднику оно должно пройти процедуру «выпуска» (enrollment), во время которой на устройстве применяется профиль защиты (набор настроек безопасности), базовые настройки которого обычно предлагаются вендорами EMM/MDM-решений, но тонкие настройки, отвечающие специфическим ИБ-требованиям компании, следует выполнить самостоятельно. По результатам проведения оценки киберрисков мобильных устройств может быть принято решение об установке дополнительных защитных решений (MTD, MAV, DLP) на них.

6. Обновление мобильных ОС, прошивок и приложений на устройствах следует проводить проактивно, учитывая скорость разработки и применения эксплойтов для новых опасных уязвимостей (особенно классов 0-day и 0-click). Решения класса EMM/MDM позволяют проводить инвентаризацию ОС, прошивок и приложений для обеспечения процессов патч-менеджмента.

7. Поддержка состояния защищенности мобильных устройств путем проведения регулярных оценок состояния соответствия устройств применимым политикам, процессам и процедурам кибербезопасности. Оценку можно проводить пассивно (путем анализа журналов аудита EMM/MDM-систем и самих устройств) и активно (путем проведения сканирований на наличие уязвимостей и пен-тестов мобильной инфраструктуры компании). Операционные процессы включают в себя проверку и установку патчей и апгрейдов; синхронизацию времени на устройствах и в ИТ-инфраструктуре; получение, централизованный сбор и аудит логов с мобильных устройств; перенастройку систем контроля логического доступа при необходимости; выявление и логирование аномалий в работе устройств и EMM/MDM-инфраструктуры, включая несанкционированное изменение политик безопасности или конфигураций. Кроме того, важно вести инвентаризационный учет устройств и приложений, отзыв или удаление опасных приложений, удаление конфиденциальной информации при утере, краже, передаче устройства другому пользователю.

Не секрет, что в современном киберпространстве одной из причин разрушительных инцидентов являются уязвимости, которые исследуются, выявляются и затем эксплуатируются злоумышленниками. Выше мы рассмотрели документ NIST SP 800-40, посвященный патч-менеджменту (англ. Patch Management), т.е. управлению процессами обновления программного обеспечения для устранения уязвимостей. Однако процесс установки обновлений также является и составным элементом более общего процесса внесения изменений в конфигурацию информационных систем - так называемый Configuration Management (далее - CM), т.е. управление изменениями конфигураций систем. Также нужно уесть, что уязвимости программных или аппаратных компонент могут иметь различную природу - в частности, ошибки конфигурирования или несогласованное изменение состояния информационных систем могут привести к успешной кибератаке. Документ NIST SP 800-128 "Guide for Security-Focused Configuration Management of Information Systems" («Руководство по безопасному управлению конфигурацией информационных систем») предлагает структурированный подход к управлению конфигурацией ИТ-систем с фокусом на безопасность и мониторинг для снижения киберрисков и обеспечения требуемого уровня функциональности сервисов.

Публикация NIST SP 800-128 сфокусирована на безопасности CM-процессов и использует термин Security-focused Configuration Management (SecCM, безопасно-ориентированное управление конфигурациями), под которым понимается управление и контроль конфигурациями информационных систем для обеспечения кибербезопасности и менеджмента киберрисков. Применение методологии SecCM позволяет получить глубокий контроль над ИТ-активами, что повышает качество управления ИТ/ИБ-процессами, улучшает реагирование на киберинциденты, помогает в разработке и внедрении ПО, позволяет автоматизировать ИТ/ИБ-процессы, обеспечивает прозрачность проведения комплаенс-процедур. Классическое управление конфигурациями (Configuration Management, CM) состоит из набора действий, сфокусированных на внедрении и поддержке процесса проверки целостности и функциональности продуктов и систем путем контроля процессов инициализации, изменения и мониторинга их конфигураций. Конфигурационная единица (Configuration Item, CI) - это определенная часть системы (например, единица программного или аппаратного обеспечения, документация, микропрограмма), являющаяся целью процесса контроля конфигурации. Базовая конфигурация (Baseline Configuration) - это набор спецификаций систем или их конфигурационных единиц (CI), которые были проверены и утверждены на определенную дату; изменения в данную базовую конфигурацию могут быть внесены только через прохождение процедуры контроля внесения изменений в конфигурацию, а сама базовая конфигурация используется в качестве базы для последующих билдов, релизов и/или изменений.

В документе NIST SP 800-128 также используется понятие плана управления конфигурациями (Configuration Management Plan, CM Plan), который содержит подробное описание ролей, ответственных, политик и процедур, применяемых при управлении конфигурациями продуктов и систем. План управления конфигурациями включает в себя следующие элементы:

1. Группа по контролю за конфигурациями (Configuration Control Board, CCB) - утвержденная и наделенная полномочиями группы квалифицированных сотрудников, отвечающих за процесс контроля и согласования изменений на протяжении жизненных циклов продуктов и систем.

2. Идентификация конфигурационных единиц - методология выбора и определения конфигурационных единиц, используемых в процессе управления конфигурациями.

3. Контроль изменений конфигурации - процесс управления обновлениями базовой конфигурации для конфигурационных единиц.

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

Управление конфигурациями в соответствии с подходом SecCM включает в себя такие процессы, как:

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

2. Учет киберрисков при согласовании конфигураций.

3. Анализ последствий для кибербезопасности при внесении изменений в конфигурацию систем.

4. Документирование согласованных и произведенных изменений.

Внедрение методологии SecCM можно разбить на следующие фазы:

1. Планирование.

1.1. Планирование на организационном уровне:

1.1.1. Разработка и внедрение SecCM-программы в масштабах компании, с назначением руководителя SecCM-программы (из числа старшего менеджмента компании).

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

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

1.1.4. Разработка стратегии мониторинга SecCM для проверки текущей эффективности SecCM-процессов для поддержки состояния защищенности организации, соответствия базовым конфигурациям, соответствия политике SecCM; проверка может выполняться по заранее согласованному расписанию и включать в себя предоставление отчетов по результатам проверки.

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

1.1.6. Разработка обучающих тренингов по SecCM-процедурам для ответственных сотрудников.

1.1.7. Определение списка согласованных ИТ-продуктов (программного и аппаратного обеспечения), которые можно закупать и использовать без дополнительных согласований.

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

1.1.9. Создание тестовой среды для проверки новых продуктов и планируемых изменений.

1.2. Планирование на уровне информационных систем:

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

1.2.2. Создание или обновление инвентаризационного списка системных компонент, который состоит из множества дискретных идентифицируемых ИТ-активов. При использовании инструментов для инвентаризации ИТ-активов рекомендуется использовать решения, поддерживающие протокол SCAP (Security Content Automation Protocol, протокол автоматизации обмена данными о безопасности) и нотацию CPE (Common Platform Enumeration, общий метод перечисления программных компонент).

1.2.3. Определение конфигурационных единиц, из которых состоит информационная система.

1.2.4. Взаимосвязь между информационной системой и её конфигурационными единицами и программными компонентами.

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

2. Определение и внедрение конфигураций.

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

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

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

2.2.2. Тестирование конфигураций в выделенной среде для выявления взаимного влияния настроек безопасности на функционирование целевой системы.

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

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

2.2.5. Внедрение базовой конфигурации - централизованно, по возможности с применением средств автоматизации.

3. Контроль изменений конфигураций.

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

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

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

3.4. Документирование внесенных изменений, обновление соответствующей документации, архивирование старых версий документов.

4. Мониторинг SecCM.

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

4.2. Внедрение и управления инструментами для мониторинга процедур SecCM; при невозможности применения автоматизированных инструментов следует задокументировать такие системы/компоненты и разработать процесс проведения неавтоматизированной проверки.