Про модели угроз ИБ и сайт www.threat-model.com

 

Недавно запустил сайт www.threat-model.com, посвященный разработке моделей угроз. Написать об этом все не хватало времени. Но сервис заметили коллеги и начали присылать вопросы. А затем и Алексей Лукацкий упомянул его в своей статье об обязательном (!) согласовании моделей угроз ГИС (согласно ПП-555). В общем, тема разработки моделей угроз становится актуальной, поэтому расскажу пару слов о данном сайте.

Для чего это нужно и как это работает

Сервис позволяет достаточно просто и быстро создать модель угроз, удовлетворяющую проекту методики ФСТЭК. Чтобы создать модель нужно перейти на сайт и заполнить небольшую анкету. Регистрация, СМС и тому подобное не требуется. Если формулировки каких-то вопросов не понятны, можно воспользоваться всплывающей подсказкой. После заполнения анкеты, модель угроз можно  будет скачать в виде excel-таблички. 

Используемые методики

Сервис использует Банк угроз безопасности информации ФСТЭК России. В качестве методики расчета используется документ "Методика определения угроз безопасности в информационных системах". Данный документ ориентирован на государственные информационные системы (ГИС), но может использоваться и для других систем. 

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

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

Порядок определения актуальных угроз

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

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

Обратите внимание, что в методике ФСТЭК допускается и альтернативный подход, основанный на определении вероятности реализации угроз. Но формализовать "вероятность" согласно текущему варианту методики довольно сложно, поэтому на сайте она не учитывается.

3) На последнем этапе определяется актуальность угроз. Актуальность угрозы зависит от возможности ее реализации, а также от степени потенциального ущерба.

Почему нет рекомендаций по нейтрализации угроз?

Получил сразу несколько таких вопросов. Предоставить рекомендации по нейтрализации угроз - хорошая идея. Но проблема в том, что большинство угроз можно "закрыть" сразу несколькими способами. Способы нейтрализации угроз - вопрос технического проекта и раздавать такие рекомендации в онлайн-сервисе - большая ответственность. Кроме того, можно ненароком начать holy war с апологетами различных решений и вендоров, что автору совершенно не нужно. Хотя, возможно, когда-нибудь, рекомендации в том или ином виде я добавлю. 

Может ли сайт заменить аудит ИБ?

Конечно, нет.  Чтобы составить полноценную модель угроз нужно проводить обследование системы с привлечением специалистов по ИБ. Но сайт может использоваться как инструмент для ознакомления с методикой моделирования угроз, а также в качестве шаблона для дальнейшей разработки.

Будет ли сервис платным?

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

Планы развития

Во-первых, как уже говорилось, после утверждения методики ФСТЭК, методику на сайте также придется пересмотреть. Во-вторых, в том или ином виде, возможно появится описание способов нейтрализации угроз. Если смотреть шире, то было бы интересно добавить функции моделирования угроз по другим методикам (по методике NIST, например). Но, с учетом того, что проект некоммерческий, все это очень зависит от свободного времени автора.  

На этом, пожалуй, все. Выражаю благодарность коллегам, в частности Алексею Лукацкому и Сергею Сторчаку, за отзывы. Спасибо всем, кто прислал мне рекомендации и замечания по работе сайта. 

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

 

Разработка безопасного программного обеспечения по ГОСТ Р 56939-2016

Пришлось столкнуться с новым стандартом по разработке безопасного - ГОСТ Р 56939-2016. Документ получился интересный, поэтому полезно провести его небольшой анализ.

Стандарт был принят прошедшим летом, но вступит в силу только через год – с 1 июля 2017 года. Разработчиком стандарта является ЗАО «НПО «ЭШЕЛОН». Целевой аудиторией стандарта являются разработчики ПО, а также организации, выполняющие оценку соответствия.

В стандарте можно выделить следующие ключевые моменты:

• Стандарт устанавливает общие требования к содержанию и порядку выполнения работ, связанных с созданием безопасного ПО. Детали соответствующих процессов в стандартом не регламентируются.
• Меры по разработке безопасного ПО применяются в течение всего жизненного цикла ПО. Есть связь с процессами, описанными в ИСО/МЭК 12207-2010.
• Стандартом вводится базовый набор мер по разработке безопасного ПО. При невозможности реализации в среде разработки ПО отдельных мер из базового набора, разработчик имеет право реализовать компенсирующие меры.
• В стандарте предусмотрено целых 6 видов испытаний ПО: статический анализ и экспертиза кода, функциональное тестирование программы, тестирование на проникновение, динамический анализ кода и фаззинг-тестирование.
• Учитывается необходимость защиты инфраструктуры среды разработки ПО.
• Учитывается необходимость обеспечения конфиденциальности информации, получаемой в ходе анализа кода и тестирования ПО

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

"Базовый набор мер" по ГОСТ Р 56939-2016 выглядит следующим образом:

1. Меры по разработке безопасного программного обеспечения, реализуемые при выполнении анализа требований к программному обеспечению:

1.1. При выполнении анализа требований к ПО разработчик ПО должен определить требования по безопасности, предъявляемые к разрабатываемому ПО.

2. Меры по разработке безопасного программного обеспечения, реализуемые при выполнении проектирования архитектуры программы:

2.1. Моделирование угроз безопасности информации.

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

3. Меры по разработке безопасного программного обеспечения, реализуемые при выполнении конструирования и комплексирования программного обеспечения:

3.1. Использование при разработке ПО идентифицированных инструментальных средств.

3.2. Создание программы на основе уточненного проекта архитектуры программы.

3.3. Создание (выбор) и использование при создании программы порядка оформления исходного кода программы.

3.4. Статический анализ исходного кода программы.

3.5. Экспертиза исходного кода программы.

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

4.1. Функциональное тестирование программы.

4.2. Тестирование на проникновение.

4.3. Динамический анализ кода программы.

4.4. Фаззинг-тестирование программы.

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

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

5.2. Поставка пользователю эксплуатационных документов.

6. Меры по разработке безопасного программного обеспечения, реализуемые при решении проблем в программном обеспечении в процессе эксплуатации:

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

6.2.  Систематический поиск уязвимости программы.

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

7.1. Реализация и использование процедуры уникальной маркировки каждой версии ПО.

7.2. Использование системы управления конфигурацией ПО.

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

8.1. Защита от несанкционированного доступа к элементам конфигурации.

8.2. Резервное копирование элементов конфигурации.

8.3. Регистрация событий, связанных с фактами изменения элементов конфигурации.

9. Меры по разработке безопасного программного обеспечения, реализуемые в процессе менеджмента людскими ресурсами

9.1. Периодическое обучение сотрудников.

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

Далее рассмотрим примерный набор документов, которые должны быть в наличии в соответствии со стандартом.

• Политика информационной безопасности в соответствии с ИСО/МЭК 27001.
• Руководство по разработке безопасного ПО.
• Перечень требований по безопасности (могут быть включены в ТЗ).
• Модель угроз безопасности.
• Проект архитектуры программы (логическая структура программы).
• Перечень инструментальных средств разработки ПО.
• Описание проектных решений, обеспечивающих выполнение требований по безопасности;
• Порядок оформления исходного кода программы.
• Регламент и протоколы статического тестирования программы.
• Регламент и протоколы экспертизы исходного кода программы.
• Регламент и протоколы функционального тестирования программы.
• Регламент и протоколы тестирования на проникновение.
• Регламент и протоколы динамического анализа кода программы.
• Регламент и протоколы фаззинг-тестирования программы.
• Эксплуатационная документация.
• Регламент передачи ПО пользователю.
• Регламент отслеживания и исправления обнаруженных ошибок ПО и уязвимостей программы.
• Регламент приема и обработки сообщений от пользователей об ошибках ПО и уязвимостях программы.
• Регламент доведения до пользователей информации об уязвимости программы и рекомендаций по их устранению.
• Журнал ошибок и уязвимостей программы.
• Регламент экстренного выпуска обновлений ПО.
• Регламент, протоколы и журналы поиска уязвимостей программы.
• Регламент доведения до пользователей сведений об уязвимостях программы.
• Регламент маркировки версий ПО.
• Регламент управления конфигурацией ПО.
• Регламент защиты инфраструктуры среды разработки ПО.
• Регламент резервного копирования конфигурации ПО.
• Регламент регистрации событий изменений конфигурации ПО.
• Журнал регистрации изменений конфигурации ПО.
• Программа обучения сотрудников в области разработки безопасного ПО.
• Журнал обучения сотрудников в области разработки безопасного ПО.

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

Подводя итог, хочется отметить достоинства документа: 

• продуманный набор мер, хорошее объяснение по сути каждой меры;
• разрешается использовать компенсирующие меры;
• предусмотрен широкий перечень проверок кода и тестирования ПО;
• связь с ГОСТ Р ИСО/МЭК 15408, ИСО/МЭК 12207-2010.

P.S. Для тех, кто хочет глубже понять стандарт, советую отличную научную статью, практически из первоисточника: ссылка. 
В статье очень подробно объясняется методика разработки стандарта и состав защитных мер.