SOT

SOT

SOAR
Security Orchestration, Automation and Response

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

NG SOAR
Next Generation SOAR

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

AM
Asset Management

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

VM
Vulnerability Management

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

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

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

FinCERT
Financial Computer Emergency Response Team

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

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

GRC

GRC

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

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

RM
Risk Management

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

ORM
Operational Risk Management

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

CM
Compliance Management

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

BCP
Business Continuity Plan

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

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

Обзор публикации 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) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities"
15.02.2022

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


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


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

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

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

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

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


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


Подкасты ИБ Практика ИБ ГОСТы и документы ИБ NIST Стандарты ИБ

Рекомендуем

SOC (Security Operation Center): что это такое и зачем используется? Центры мониторинга информационной безопасности
SOC (Security Operation Center): что это такое и зачем используется? Центры мониторинга информационной безопасности
КИИ - что это? Безопасность объектов критической информационной инфраструктуры
КИИ - что это? Безопасность объектов критической информационной инфраструктуры
Кейлоггер для кибербезопасности и оптимизации
Кейлоггер для кибербезопасности и оптимизации
Информационная  безопасность (ИБ) - что это такое. Виды защиты информации.
Информационная безопасность (ИБ) - что это такое. Виды защиты информации.
Что такое IRP, где используется и как внедряется
Что такое IRP, где используется и как внедряется
SIEM системы (Security Information and Event Management) - что это и зачем нужно?
SIEM системы (Security Information and Event Management) - что это и зачем нужно?
Управление рисками информационной безопасности. Часть 1. Основные понятия и методология оценки рисков
Управление рисками информационной безопасности. Часть 1. Основные понятия и методология оценки рисков
Управление рисками информационной безопасности (конспект лекции)
Управление рисками информационной безопасности (конспект лекции)
Федеральный закон № 161-ФЗ «О национальной платежной системе»
Федеральный закон № 161-ФЗ «О национальной платежной системе»
Категорирование объектов критической информационной инфраструктуры в рамках 187-ФЗ. Постановление Правительства РФ № 127
Категорирование объектов критической информационной инфраструктуры в рамках 187-ФЗ. Постановление Правительства РФ № 127
Практика ИБ. Централизованный сбор логов с Windows-устройств
Практика ИБ. Централизованный сбор логов с Windows-устройств
Обеспечение безопасности значимых объектов критической информационной инфраструктуры в рамках 187-ФЗ. Приказы ФСТЭК России №235 и 239
Обеспечение безопасности значимых объектов критической информационной инфраструктуры в рамках 187-ФЗ. Приказы ФСТЭК России №235 и 239

Рекомендуем

SOC (Security Operation Center): что это такое и зачем используется? Центры мониторинга информационной безопасности
SOC (Security Operation Center): что это такое и зачем используется? Центры мониторинга информационной безопасности
КИИ - что это? Безопасность объектов критической информационной инфраструктуры
КИИ - что это? Безопасность объектов критической информационной инфраструктуры
Кейлоггер для кибербезопасности и оптимизации
Кейлоггер для кибербезопасности и оптимизации
Информационная безопасность (ИБ) - что это такое. Виды защиты информации.
Информационная  безопасность (ИБ) - что это такое. Виды защиты информации.
Что такое IRP, где используется и как внедряется
Что такое IRP, где используется и как внедряется
SIEM системы (Security Information and Event Management) - что это и зачем нужно?
SIEM системы (Security Information and Event Management) - что это и зачем нужно?
Управление рисками информационной безопасности. Часть 1. Основные понятия и методология оценки рисков
Управление рисками информационной безопасности. Часть 1. Основные понятия и методология оценки рисков
Управление рисками информационной безопасности (конспект лекции)
Управление рисками информационной безопасности (конспект лекции)
Федеральный закон № 161-ФЗ «О национальной платежной системе»
Федеральный закон № 161-ФЗ «О национальной платежной системе»
Категорирование объектов критической информационной инфраструктуры в рамках 187-ФЗ. Постановление Правительства РФ № 127
Категорирование объектов критической информационной инфраструктуры в рамках 187-ФЗ. Постановление Правительства РФ № 127
Практика ИБ. Централизованный сбор логов с Windows-устройств
Практика ИБ. Централизованный сбор логов с Windows-устройств
Обеспечение безопасности значимых объектов критической информационной инфраструктуры в рамках 187-ФЗ. Приказы ФСТЭК России №235 и 239
Обеспечение безопасности значимых объектов критической информационной инфраструктуры в рамках 187-ФЗ. Приказы ФСТЭК России №235 и 239

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

Технология SOAR и ее место в SOC
Технология SOAR и ее место в SOC
Живее всех живых: непрерывность бизнеса
Живее всех живых: непрерывность бизнеса
Что такое системы анализа трафика (Network Traffic Analysis, NTA), их отличие от NDR и IDS
Что такое системы анализа трафика (Network Traffic Analysis, NTA), их отличие от NDR и IDS
Анатомия визуализации. Часть первая: от задачи к исполнению
Анатомия визуализации. Часть первая: от задачи к исполнению
Что такое аутентификация Kerberos (Керберос), что такое NTLM и как они работают
Что такое аутентификация Kerberos (Керберос), что такое NTLM и как они работают
Open software supply chain attack reference (OSC&R)
Open software supply chain attack reference (OSC&R)
Применение утилиты Sysmon для повышения уровня кибербезопасности
Применение утилиты Sysmon для повышения уровня кибербезопасности
Фантастический TI и где он обитает
Фантастический TI и где он обитает
Что такое шлюзы безопасности и какие функции они выполняют
Что такое шлюзы безопасности и какие функции они выполняют

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

Технология SOAR и ее место в SOC
Технология SOAR и ее место в SOC
Живее всех живых: непрерывность бизнеса
Живее всех живых: непрерывность бизнеса
Что такое системы анализа трафика (Network Traffic Analysis, NTA), их отличие от NDR и IDS
Что такое системы анализа трафика (Network Traffic Analysis, NTA), их отличие от NDR и IDS
Анатомия визуализации. Часть первая: от задачи к исполнению
Анатомия визуализации. Часть первая: от задачи к исполнению
Что такое аутентификация Kerberos (Керберос), что такое NTLM и как они работают
Что такое аутентификация Kerberos (Керберос), что такое NTLM и как они работают
Open software supply chain attack reference (OSC&R)
Open software supply chain attack reference (OSC&R)
Применение утилиты Sysmon для повышения уровня кибербезопасности
Применение утилиты Sysmon для повышения уровня кибербезопасности
Фантастический TI и где он обитает
Фантастический TI и где он обитает
Что такое шлюзы безопасности и какие функции они выполняют
Что такое шлюзы безопасности и какие функции они выполняют