угроза эксплуатации цифровой подписи программного кода
Обзор требований ФСТЭК России к анализу программного кода средствами защиты информации
Главный редактор Anti-Malware.ru Александр Панасенко подготовил обзор одного из наиболее интересных ИБ-проектов последнего года — приказ №131 ФСТЭК России о требованиях к безопасности информации.
Введение
В июле 2018 года Федеральная служба по техническому и экспортному контролю (далее — ФСТЭК России) представила приказ №131 об утверждении «Требований по безопасности информации, устанавливающих уровни доверия (далее — УД) к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий». В соответствии с новым перечнем требований для средств защиты информации (далее — СЗИ) устанавливаются УД, характеризующие безопасность их применения для обработки и защиты информации, содержащей государственную тайну, конфиденциальные сведения или данные ограниченного доступа. По новым правилам в отношении СЗИ всех уровней доверия должны проводиться исследования по выявлению уязвимостей и недекларированных возможностей (далее — НДВ) в соответствии с методикой, разработанной в дополнение к приказу №131 и утвержденной ФСТЭК России в феврале 2019 года.
Рекомендации по применению приказа №131 касаются только тех разработчиков, кто специализируется на программных решениях для защиты инфраструктур и систем, содержащих информацию, доступ к которой должен быть ограничен или защищен. Однако любое программное обеспечение (далее — ПО), разрабатываемое и используемое в системах, где хранятся и обрабатываются данные, имеет встроенные программные алгоритмы для защиты информации (например, проверки полномочий доступа к данным или к системе в целом), которые также могут нуждаться в проверке на безопасность.
Основной причиной инцидентов в области ИБ чаще всего становятся ошибки кодирования, приводящие к уязвимостям программ и систем. В связи с этим для предотвращения нарастающих угроз в информационной сфере всем разработчикам программных продуктов рекомендуется принимать меры по выпуску защищенного ПО и придерживаться требований ГОСТ и приказов ФСТЭК России, касающихся безопасной разработки кода.
Анализ программного кода на уязвимости и НДВ в процессах жизненного цикла ПО
В соответствии с ГОСТ Р 56939-2016 «Защита информации. Разработка безопасного ПО. Общие требования» можно обеспечить реализацию и проведение мер по разработке безопасного программного обеспечения непосредственно в процессах его жизненного цикла. Целесообразно проводить исследования по выявлению уязвимостей и НДВ:
Одним из способов упростить и автоматизировать проведение таких исследований является применение СЗИ для анализа кода. Необходимо отметить важность проверки программного кода, содержащегося в транспортных запросах, при переносе данных по ландшафту системы от этапа к этапу. В таком варианте исследований применение СЗИ позволит снизить процент небезопасных конструкций в коде к моменту эксплуатации программного обеспечения, провести работы по выявлению уязвимостей и НДВ без выгрузки и передачи исходного кода на исследования третьей стороне. При этом средства защиты информации могут быть интегрированы в систему разработки.
Схема использования СЗИ для анализа кода в процессах жизненного цикла ПО представлена на рисунке 1.
Изображение Anti-Malware.ru: Рисунок 1. Схема использования СЗИ для анализа кода в процессах жизненного цикла ПО
Анализ программного кода на уязвимости и НДВ после завершения разработки ПО
В соответствии с требованиями методики ФСТЭК России, разработанной в дополнение к приказу №131, можно осуществить проверку кода уже готового к эксплуатации ПО с привлечением испытательных лабораторий (или СЗИ).
При данном варианте исследований существуют риски ввода в эксплуатацию небезопасного программного обеспечения. Для того чтобы выполнить анализ, необходимо будет предоставить испытательным лабораториям исходный код программных решений или воспользоваться интегрируемыми СЗИ, установив их на испытательный стенд. В последнем случае выгрузка исходного кода не потребуется, если стенд будет развернут на рабочей станции разработчика программного обеспечения.
Схема использования СЗИ для анализа кода после завершения разработки ПО приведена на рисунке 2.
Изображение Anti-Malware.ru: Рисунок 2. Схема использования СЗИ для анализа кода после завершения разработки ПО
Выявление уязвимостей и НДВ, согласно методике, необходимо выполнять посредством проведения статического анализа исходного кода программы, а также путем реализации процедуры, позволяющей выполнять отслеживание и исправление всех обнаруженных дефектов безопасности и уязвимостей исследуемой программы.
Исследования по выявлению уязвимостей и НДВ состоят из следующих этапов:
Рекомендуемый набор требований, предъявляемых к инструменту статического анализа в СЗИ:
На данный момент наиболее актуальным инструментом для хранения и обработки информации являются системы на платформе SAP NetWeaver. В качестве СЗИ для проведения исследований по выявлению уязвимостей и недекларированных возможностей в программном ABAP-коде данных систем рассмотрим программный модуль (далее — ПМ) SafeERP Code Security (в составе СЗИ SafeERP), разработанный ООО «Газинформсервис». Этот модуль использует статический метод анализа кода.
Для проведения исследований на проверяемые системы устанавливается программный компонент клиентской части SafeERP Code Security, отвечающий за сбор и передачу данных (для последующего анализа) на сервер управления. Приведем пример использования модуля в процессах жизненного цикла ПО на описанных выше этапах.
1. Разработка. ПМ включается в список инструментов для проверки среды разработки (ABAP-редактора) как основное средство анализа кода. Проверка на наличие небезопасных конструкций может проводиться непосредственно в момент разработки ПО через вызов модуля из основного меню ABAP-редактора.
2. Тестирование. Проверка на наличие небезопасных конструкций проводится посредством анализа выбранных программных пакетов тестируемого ПО непосредственно на тестовой системе.
3. Эксплуатация. Проверка на наличие небезопасных конструкций проводится посредством анализа выбранных программных пакетов вновь разработанного или эксплуатируемого ПО непосредственно на системе эксплуатации.
4. Перенос транспортных запросов. ПМ включается в организатор переносов как основной инструмент для анализа кода. При деблокировании запросов (при переносе программного кода) автоматически выводятся предупреждения о наличии небезопасных конструкций в случае их обнаружения (запрос не деблокируется).
Модуль SafeERP Code Security реализует все требования, предъявляемые к инструменту анализа программного кода:
Для анализа программного кода рекомендуется выбирать СЗИ с уровнем доверия, который соответствует категориям сведений, содержащихся в проверяемой инфраструктуре или системе (дифференциация требований к УД в зависимости от класса (категории/уровня) защищенности объекта приведена в следующем разделе). Согласно требованиям приказа ФСТЭК России №131 SafeERP будет проходить сертификацию как СЗИ 5-го уровня доверия.
На данный момент СЗИ SafeERP применяется в ПАО «Газпром» (с 2010 г.) и ПАО «Норникель» (с 2017 г.). Ознакомиться с возможностями СЗИ SafeERP и установкой его программного модуля на системы для проведения исследований программного ABAP-кода можно на сайте ООО «Газинформсервис».
Дифференциация требований к УД СЗИ в зависимости от класса (категории/уровня) защищенности объекта
Согласно документам ФСТЭК России, к СЗИ относятся: межсетевые экраны, средства обнаружения вторжений, антивирусные программы, средства доверенной загрузки и контроля съемных носителей, другие решения в области информационной безопасности. В таблице 1 приведена дифференциация требований к УД СЗИ в зависимости от класса (категории/уровня) объекта защиты.
Таблица Anti-Malware.ru: Дифференциация требований к уровням доверия СЗИ
СЗИ, соответствующие 6-му УД, подлежат применению в значимых объектах критической информационной инфраструктуры (далее — КИИ) 3 категории, в государственных информационных системах (далее — ГИС) 3 класса защищенности, в автоматизированных системах управления производственными и технологическими процессами (далее — АСУ ТП) 3 класса защищенности, в информационных системах персональных данных (далее — ИСПДн) при необходимости обеспечения 3 и 4 уровня защищенности персональных данных.
СЗИ, соответствующие 5-му УД, подлежат применению в значимых объектах КИИ 2 категории, в ГИС 2 класса защищенности, в АСУ ТП 2 класса защищенности, в ИСПДн при необходимости обеспечения 2 уровня защищенности персональных данных.
СЗИ, соответствующие 4-му УД, подлежат применению в значимых объектах КИИ 1 категории, в ГИС 1 класса защищенности, АСУ ТП 1 класса защищенности, в ИСПДн при необходимости обеспечения 1 уровня защищенности персональных данных, в информационных системах общего пользования II класса.
СЗИ, соответствующие 1-му, 2-му и 3-му УД, применяются в информационных (автоматизированных) системах, в которых обрабатываются сведения, составляющие государственную тайну.
Выводы
Мы разобрали наиболее важные аспекты работ, проводимых в соответствии с требованиями методик приказа №131 ФСТЭК России, а также основные причины инцидентов информационной безопасности и особенности проверки ПО на безопасность. Оптимизировать процесс перехода на новые требования регуляторов, защитить системы и разработки поможет программный комплекс SafeERP, разработанный ООО «Газинформсервис».
Читайте также:
В России утверждены два первых ГОСТа по искусственному интеллекту
Федеральное агентство по техническому регулированию и метрологии (Росстандарт) приняло первые национальные стандарты в области искусственного интеллекта (ИИ).
ФАС разъясняет механизм поддержки товаров из России и стран ЕАЭС на закупках госкомпаний
Приоритет на закупках предоставляется в равной степени товарам/работам/услугам из России и стран ЕАЭС.
Статья Угон сертификата подписи Microsoft
Сценарий заимствует подпись существующего приложения и модифицирует два ключа реестра, чтобы сделать его исполняемый файл с подписью Microsoft.
Возьмите подпись из двоичного файла и добавьте ее в другой двоичный файл
Сохраните подпись на диск для последующего использования
Используйте вырванную подпись
Сократить (удалить) подпись
Проверьте, есть ли подпись
Inputfile is signed!
3) Запустите следующую команду
4) Ослабьте цель, изменив следующие ключи реестра (32 бита)
HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllVerifyIndirectData\
HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllVerifyIndirectData\
5) Ослабьте цель, изменив следующие ключи реестра (64 бит)
HKLM\SOFTWARE\WOW6432Node\Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllVerifyIndirectData\
HKLM\SOFTWARE\WOW6432Node\Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllVerifyIndirectData\
6) Проверьте, действительна ли эта подпись с PowerShel
7) Начните новый процесс, чтобы угон вступил в силу:
Примечание: это может быть любой процесс
8) Microsoft подписал mimikatz
Сценарий SubvertTrust Powershell
Успешно протестировано в Win7_x86 и Win10_x64.
Угроза эксплуатации цифровой подписи программного кода
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
РАЗРАБОТКА БЕЗОПАСНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Угрозы безопасности информации при разработке программного обеспечения
Information protection. Secure software development. Software development life cycle threats
Дата введения 2019-11-01
Предисловие
1 РАЗРАБОТАН Федеральной службой по техническому и экспортному контролю (ФСТЭК России), Акционерным обществом «Научно-производственное объединение «Эшелон» (АО «НПО «Эшелон»)
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 362 «Защита информации»
Введение
Настоящий стандарт входит в комплекс стандартов, направленных на достижение целей, связанных с предотвращением появления и/или устранением уязвимостей программ, и содержит систематизированный перечень угроз безопасности информации, которые могут возникать при разработке программного обеспечения.
Информация, представленная в настоящем стандарте, может быть использована разработчиком программного обеспечения при выборе (определении) и реализации мер по разработке безопасного программного обеспечения, установленных ГОСТ Р 56939.
1 Область применения
Настоящий стандарт устанавливает перечень и содержит описание угроз безопасности информации, которые могут возникать при разработке программного обеспечения. Настоящий стандарт предназначен для разработчиков и производителей программного обеспечения и применяется совместно с ГОСТ Р 56939. Информация о мерах по разработке безопасного (защищенного) программного обеспечения, установленных ГОСТ Р 56939, реализация которых способствует нейтрализации угроз безопасности информации при разработке программного обеспечения, приведена в приложении А.
Перечень и описание угроз безопасности информации, представленные в настоящем стандарте, могут использоваться для определения угроз безопасности, актуальных для среды разработки программного обеспечения и разрабатываемого программного обеспечения. В некоторых случаях, например, в процессе разработки программ для ЭВМ с открытым кодом или при использовании программ для ЭВМ с открытым кодом в составе разрабатываемого ПО разработчик может принять осознанное решение об отсутствии необходимости сохранения конфиденциальности определенных компонентов ПО, что соответствующим образом может отразиться на результатах идентификации и оценки угроз безопасности информации: угрозы нарушения конфиденциальности информации, содержащейся в указанных компонентах ПО будут являться неактуальными.
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие стандарты:
ГОСТ 19781 Обеспечение систем обработки информации программное. Термины и определения
ГОСТ Р 50922 Защита информации. Основные термины и определения
ГОСТ Р 51275 Защита информации. Объект информатизации. Факторы, воздействующие на информацию. Общие положения
ГОСТ Р 54593 Информационные технологии. Свободное программное обеспечение. Общие положения
ГОСТ Р 56939 Защита информации. Разработка безопасного программного обеспечения. Общие требования
ГОСТ Р ИСО 10007 Менеджмент организации. Руководящие указания по управлению конфигурацией
ГОСТ Р ИСО/МЭК 12207 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств
ГОСТ Р ИСО/МЭК 27000 Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Общий обзор и терминология
ГОСТ Р ИСО/МЭК 27001-2006 Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования
3 Термины и определения
В настоящем стандарте применены термины по ГОСТ Р ИСО/МЭК 27000, ГОСТ Р ИСО 10007, ГОСТ 19781, ГОСТ Р 50922, ГОСТ Р 51275, ГОСТ Р 54593, ГОСТ Р 56939, а также следующие термины с соответствующими определениями:
3.1 инструментальное средство: Программа, используемая как средство разработки, тестирования, анализа, производства или модификации других программ или документов на них.
3.2 исходный код программы: Программа в текстовом виде на каком-либо языке программирования.
3.3 среда разработки программного обеспечения: Среда, в которой осуществляется разработка программного обеспечения.
4 Общие положения
4.1 При реализации требований ГОСТ Р 56939 разработчиком безопасного программного обеспечения (ПО) должен быть определен перечень мер, подлежащих реализации при его разработке в целях предотвращения появления и устранения уязвимостей программ в процессах их жизненного цикла. Выбор и уточнение мер по разработке безопасного ПО должен основываться на результатах проводимого разработчиком ПО анализа угроз безопасности информации, в результате которого должны быть определены актуальные для среды разработки ПО угрозы безопасности информации. Угрозы безопасности информации при разработке ПО, представленные в настоящем стандарте, могут являться основой для проведения анализа угроз безопасности информации конкретной среды разработки ПО.
4.2 Перечень угроз безопасности информации, приведенный в настоящем стандарте, является специфичным для процессов жизненного цикла ПО, в ходе которых в ПО могут быть внедрены уязвимости программы или нарушена конфиденциальность информации, потенциально способствующей выявлению недостатков ПО и уязвимостей программы. Угрозы безопасности информации, приведенные в настоящем стандарте, являются антропогенными. В настоящем стандарте не рассматриваются угрозы безопасности информации, связанные со стихийными бедствиями, природными явлениями и утечкой информации по техническим каналам.
4.3 Перечень угроз безопасности информации не является исчерпывающим и может быть дополнен и (или) уточнен в процессе идентификации угроз безопасности информации для конкретной среды разработки ПО.
4.4 В качестве источников угроз безопасности информации при разработке ПО могут выступать:
— лица (нарушители), осуществляющие преднамеренные или непреднамеренные действия, направленные на внедрение в ПО уязвимостей программы или нарушение конфиденциальности информации, потенциально способствующей выявлению недостатков ПО и уязвимостей программы;
— инструментальные средства, применяемые при разработке ПО, алгоритм работы которых может стать причиной внедрения в ПО уязвимостей программы.
Непреднамеренные угрозы безопасности информации при разработке ПО возникают из-за неосторожности или неквалифицированных действий работников разработчика ПО и связаны с недостаточной осведомленностью работников в области защиты информации и разработки безопасного ПО.
4.5 С учетом возможностей по доступу к среде разработки ПО нарушителей в настоящем стандарте подразделяют на два типа:
Внутренние нарушители могут реализовывать угрозы безопасности информации при разработке ПО путем:
— влияния на процессы жизненного цикла ПО;
— осуществления преднамеренных или непреднамеренных действий в отношении отдельных объектов среды разработки ПО, в том числе элементов конфигурации, выполняя санкционированный доступ;
— осуществления преднамеренных действий в отношении отдельных объектов среды разработки ПО, в том числе элементов конфигурации, выполняя несанкционированный доступ.
Внешние нарушители могут реализовывать угрозы безопасности информации при разработке ПО путем удаленного доступа (из внешних сетей связи общего пользования) к объектам среды разработки ПО, в том числе элементам конфигурации, выполняя несанкционированный доступ. Внешние нарушители для повышения своих возможностей по доступу к объектам среды разработки ПО могут вступать в сговор с внутренними нарушителями.
5 Угрозы безопасности информации при разработке программного обеспечения
Номенклатура угроз безопасности информации при разработке ПО, представленная в данном разделе, приведена применительно к процессам жизненного цикла ПО, установленных ГОСТ Р ИСО/МЭК 12207.
5.1 Угрозы безопасности информации при выполнении анализа требований к программному обеспечению
5.1.1 Угроза появления уязвимостей программы вследствие ошибок, допущенных при задании требований по безопасности, предъявляемых к создаваемому программному обеспечению
Данная угроза заключается в преднамеренном или непреднамеренном задании требований по безопасности к создаваемому ПО, содержащих ошибки, которые при условии их необнаружения или неисправления могут стать причиной появления уязвимостей программы. Реализация угрозы может быть связана:
— с преднамеренными действиями нарушителя;
— с принятием разработчиком ПО осознанного решения о неисправлении обнаруженных в требованиях по безопасности ошибок в силу различных причин, например, для сокращения времени разработки программы;
— некачественной или неполной проработкой перечня требований;
— неисправлением обнаруженных ошибок вследствие неосторожных или неквалифицированных действий, неточностями, допущенными в формулировках требований;
— неучетом при формировании требований к разрабатываемому ПО всех применимых источников, например: законов, нормативных правовых актов, отраслевых стандартов, требований пользователя, сценариев применения ПО, актуальных угроз безопасности информации.
Уязвимости программы, появившиеся из-за ошибок в требованиях по безопасности, в дальнейшем могут быть использованы с целью выполнения компьютерных атак на информационные системы пользователей, применяющих ПО.
Реализация данной угрозы внутренним нарушителем может быть осуществлена путем влияния на формирование требований по безопасности в процессе их задания или внесения изменений в любые объекты среды разработки ПО, в том числе в элементы конфигурации, создаваемые или используемые при определении этих требований. Изменения могут вноситься путем санкционированного или несанкционированного доступа к объектам среды разработки ПО.
Внешний нарушитель может реализовывать данную угрозу путем удаленного доступа (из внешних сетей связи общего пользования и (или) сетей международного информационного обмена) к объектам среды разработки ПО, создаваемым или используемым при определении требований по безопасности. Реализация данной угрозы внешним нарушителем возможна при условии подключения среды разработки ПО к внешним сетям связи общего пользования и (или) сетям международного информационного обмена.
Угроза обусловлена недостатками в реализованных разработчиком ПО мерах контроля доступа и контроля целостности, применяемых к объектам среды разработки ПО, и мерах по разработке безопасного ПО, в частности: отсутствием мер, связанных с определением требований по безопасности, неполной или некачественной оценкой сформулированных требований по безопасности, недостатками в мерах, связанных с управлением конфигурацией ПО и обучением работников разработчика ПО в области разработки безопасного ПО.
5.1.2 Угроза выявления уязвимостей программы вследствие раскрытия информации о требованиях по безопасности, предъявляемых к создаваемому программному обеспечению
Данная угроза заключается в преднамеренном или непреднамеренном (из-за неосторожности или неквалифицированных действий работников разработчика ПО) раскрытии информации о требованиях по безопасности, предъявляемых к создаваемому ПО. Нарушение конфиденциальности данной информации может способствовать выявлению недостатков ПО и уязвимостей программы, которые в дальнейшем могут быть использованы с целью выполнения компьютерных атак на информационные системы пользователей, применяющих ПО.
Реализация данной угрозы внутренним нарушителем может быть осуществлена путем раскрытия информации, содержащейся в объектах среды разработки ПО, в том числе в элементах конфигурации, создаваемых или используемых разработчиком ПО при определении требований по безопасности, вследствие санкционированного или несанкционированного доступа к указанным объектам.
Внешний нарушитель может реализовывать данную угрозу путем удаленного доступа (из внешних сетей связи общего пользования и (или) сетей международного информационного обмена) к объектам среды разработки ПО, создаваемым или используемым при определении требований по безопасности. Реализация данной угрозы внешним нарушителем возможна при условии подключения среды разработки ПО к внешним сетям связи общего пользования и (или) сетям международного информационного обмена.
— недостатками в реализованных разработчиком ПО мерах контроля доступа, применяемых к объектам среды разработки ПО и направленных на ограничение круга лиц, имеющих доступ к критичной информации, и операций, которые могут быть выполнены с объектами среды разработки (например, вывод информации с использованием носителей информации или каналов передачи данных);