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

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

Банк России на протяжении последних лет планомерно усиливал свои требования к подотчетным организациям в направлении обеспечения безопасности ПО. Безусловно, никто не мог предугадать масштабы грядущих событий, но наличие грамотных подходов к организации безопасности ПО наряду с другими мерами ИБ обеспечивает необходимую устойчивость организаций перед лицом возникающих угроз. Эти меры и подходы можно «прочитать» в текстах требований, выставляемых Банком России к обеспечению безопасности ПО.

Что читаем?

Банк России сформулировал требования к обеспечению информационной безопасности ПО в ряде нормативно-правовых актов:

• Положение Банка России от 17 апреля 2019 года № 683-П «Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента» (с изменениями от 18 февраля 2022 года);
• Положение Банка России от 4 июня 2020 года № 719-П «О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств»;
• Положение Банка России от 20.04.2021 № 757-П «Об установлении обязательных для некредитных финансовых организаций требований к обеспечению защиты информации при осуществлении деятельности в сфере финансовых рынков в целях противодействия осуществлению незаконных финансовых операций».

Документы выставляют требования, согласно которым для ряда важнейших процессов необходимо обеспечить использование программ, «сертифицированных в системе сертификации ФСТЭК на соответствие требованиям по безопасности информации, или в отношении которых проведен анализ уязвимостей по требованиям к оценочному уровню доверия (ОУД) не ниже чем ОУД 4 в соответствии с требованиями национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 15408-3-2013 “Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности”». Этот стандарт утвержден приказом Федерального агентства по техническому регулированию и метрологии № 1340-ст «Об утверждении национального стандарта» от 8 ноября 2013 года.

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

Оценка соответствия по ОУД 4 vs сертификация по требованиям ФСТЭК России

Система сертификации ФСТЭК России выстроена в рамках выполнения оценки соответствия, согласно приказу ФСТЭК России от 2 июня 2020 года № 76 «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий». Также для удовлетворения всем требованиям по оценке соответствия необходимо выполнить перечень мероприятий, описанных в Методике выявления уязвимостей и недекларированных возможностей в программном обеспечении. В этих документах содержатся как классификация программного обеспечения, так и требования к критериям соответствия и инструментальным контролям (типам выполняемых проверок) для каждого класса программ.

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

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

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

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

Основные понятия ГОСТ 15408

ГОСТ серии 15408 вводит следующие базовые понятия:

• ОО (объект оценки) — проверяемое ПО;
• ЗБ (задание безопасности) — документ, описывающий архитектуру безопасности проверяемого ПО;
• ФТБ (функциональные требования безопасности) — составные части архитектуры безопасности проверяемого ПО.

Согласно 683П, 719П и 757П, объектом оценки являются приложения, обрабатывающие платежную информацию клиентов, АБС, ДБО, а также те, что имеют связи со средой интернет, из числа организаций, напрямую отчитывающихся перед Банком России.

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

Во-вторых, к ним относятся разнообразные некредитные организации:

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

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

Реализация ОУД 4

Согласно ГОСТ 15408-3-2013, п. 7.6, «ОУД 4 позволяет разработчику достичь максимального доверия путем применения надлежащего проектирования безопасности, основанного на хороших коммерческих практиках разработки, которые, даже будучи строгими, не требуют глубоких профессиональных знаний, навыков и других ресурсов. ОУД 4 — самый высокий уровень, на который, вероятно, экономически целесообразно ориентироваться при оценке уже существующих продуктов». Поэтому подход ОУД 4 применим, когда разработчикам или пользователям требуется независимо подтвержденный уровень доверия (от умеренного до высокого в ОО общего назначения) и имеется готовность нести дополнительные производственные затраты, связанные с обеспечением безопасности.

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

Оценочный уровень доверия 4. Компоненты доверия

Анализ поддержан:

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

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

Таким образом, ОУД 4 обусловливает значимое увеличение доверия по сравнению с ОУД 3, требуя более детального описания проекта, представления реализации для всех ФБО и улучшенные механизмов и/или процедур. Все это дает уверенность в том, что в ОО не будут внесены искажения во время разработки.

Отметим, что каждый из компонентов доверия, приведенных в таблице, имеет расширенное описание. Например, «AVA_VAN.3 Сосредоточенный анализ уязвимостей» имеет следующее расширенное описание:

15.2.5 AVA_VAN.3 Фокусированный анализ уязвимостей

Достижение целей оценки

Согласно 15.2.5.1 Цели (ГОСТ 15408-3-2013), оценщик проводит анализ с целью установить наличие потенциальных уязвимостей. Он осуществляет тестирование проникновения, чтобы удостовериться в невозможности использования потенциальных уязвимостей в среде функционирования объекта оценки. Тестирование проникновения проводится исходя из потенциала нападения уровня «Усиленный базовый».

В документе также приводятся элементы действий разработчика ПО:

15.2.5.2 Элементы действий разработчика

15.2.5.2.1 AVA_VAN.3.1D

Разработчик должен представить ОО для тестирования.

15.2.5.1* Элементы содержания и представления свидетельств.

15.2.5.1.1* AVA_VAN.3.1C

ОО должен быть пригоден для тестирования.

15.2.5.2* Элементы действий оценщика.

15.2.5.2.1 AVA_VAN.3.1E

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

15.2.5.2.2 AVA_VAN.3.2E

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

15.2.5.2.3 AVA_VAN.3.3E

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

15.2.5.2.4 AVA_VAN.3.4E

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

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

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

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

Что касается требований к анализу уязвимостей, то они практически ничем не отличаются от стандартной процедуры анализа уязвимостей, широко применяемой экспертами ИБ. Решение класса SAST (статический анализ кода) может использоваться в качестве одного из инструментов для выполнения анализа. Отметим, что среди решений SAST встречаются и такие, которые обеспечивают отчетность в формате ОУД 4. Тогда данный отчет можно использовать в составе материалов при проведении оценки соответствия ОУД 4. В числе таких инструментов — ПО Solar appScreener, известное также широким перечнем поддерживаемых языков программирования.

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