среда, 21 сентября 2016 г.

О расшифровке трафика


Похоже на то, что «Великий российский фаервол» получит поддержку HTTPS inspection. И в этой связи, появляется несколько вопросов.  

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

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

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

В-третьих, как уже говорилось в исходной статье, как заставить браузер доверять УЦ, выпустившему сертификат для «великого фаервола»? Яндекс.Браузер используют не все.

В-четвертых, как будет обеспечиваться соответствие всей системы требованиям самих регуляторов?
Расшифровка трафика, конечно, подразумевает его шифрование на каком-то своем ключе (т.к. предполагается, что это не «великий российский SSLstrip»).
В трафике пользователя могут передаваться, например, ПДн или другая конфиденциальная информация. Для шифрования этой информации сами регуляторы требуют использовать только сертифицированные средства.
Соответственно, «великий российский DPI с поддержкой HTTPS inspection», по-хорошему, должен быть сертифицирован в качестве СКЗИ и… использовать ГОСТовый сертификат. А это потребует установки сертифицированных СКЗИ заодно и на компьютеры всех граждан.

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

P.S. Вот последовали мнения, что государство имеет право и возможности расшифровать интернет-трафик

понедельник, 5 сентября 2016 г.

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