Что нужно знать об оценочном уровне доверия (ОУД4) и ГОСТах (719-П, 757-П, 683-П)

За последние несколько лет появилось много нормативных правил, которые обязаны соблюдать компании для контроля ИБ, однако до сих пор не все ясно представляют себе, что значит то или иное Положение и как выполнять его требования. В таких указаниях, как 719-П, 757-П, 683-П содержится требование по проведению ОУД4 в соответствии с ГОСТ Р ИСО/МЭК 15408-3-2013. Как разобраться в том, что такое ОУД, и не пропустить важное? Разберемся в этой статье.

Что такое ОУД4 и как он связан с 382-П и ГОСТ Р ИСО/МЭК 15408-3-2013?

В начале становления отрасли ИБ в США в 1970-80-х годах, силовые ведомства и государственные структуры осознали необходимость гарантировать надежность систем, используемых для обеспечения защиты информационных активов. Это привело к разработке различных стандартов и методологий оценки безопасности.

Однако эти стандарты существовали параллельно и в разных юрисдикциях. Затем они были объединены в единый фреймворк под названием «Общие Критерии» (Common Criteria) под эгидой международных организаций ISO/IEC. Этот фреймворк стал общепризнанным и используется во многих странах для оценки безопасности информационных систем.

В России также начали анализировать и адаптировать ОУД, чтобы издать его официально на русском языке от Стандартинформа с 2012 года. Вместе с тем ГОСТы, в которых упоминается ОУД, не являются обязательными для соблюдения сами по себе, как и любой ГОСТ на территории России согласно ст. 27 Федерального закона № 162-ФЗ «О стандартизации». Однако ЦБ в Положениях ссылается на ГОСТы, что и делает их обязательными для исполнения.

«Стандартинформ» начал выпускать стандарты, связанные с оценкой безопасности информационных систем. В это время Банк России начал ужесточать правила безопасности в финансовой сфере. Основная цель заключалась в обеспечении надежности и стабильности финансовой системы страны. Это вмещало борьбу с мошенничеством и незаконными операциями, связанными с денежными средствами. Летом 2012 года было принято положение 382-П, которое стало основным регулирующим документом по безопасности информации для организаций, занимающихся финансовыми операциями в России. Этот документ содержал обязательные стандарты и правила для сохранения конфиденциальности в финансовой сфере. Кроме того, существовали и другие стандарты, такие как PCI DSS, который также касался безопасности информации и применялся в определенных сферах деятельности.

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

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

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

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

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

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

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

Оценка соответствия по ОУД4 и для кого она обязательна

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

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

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

Как проводится оценка соответствия по ОУД4

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

Уязвимости в системе безопасности не ограничиваются исключительно этапами разработки и проектирования; они могут проявляться во время настройки и эксплуатации. Поэтому понимание операционной среды и конфигурации среды/объекта оценки имеет первостепенное значение.

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

Два базовых сценария подтверждения соответствия:

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

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

• Поиск данных: все начинается с получения необходимых исходных данных от клиентов. Эти данные содержат сертификаты оценки, охватывающие проектную и тестовую документацию, а также саму основу программного обеспечения – его исходный код.
• Если какие-либо важные документы отсутствуют, то необходимо привести документацию в порядок, то есть восполнить в ней пробелы. Эти документы важны для того, чтобы провести грамотную оценку.
• Схема обеспечения безопасности: в основе оценки соответствия лежит задание по обеспечению безопасности. Этот документ соединяет само назначение безопасности, цели безопасности, заявления о соответствии требованиям, расширенные определения компонентов, производные требования безопасности и множество других важных параметров.
• Необходимо тщательное изучение документации проекта. Это включает в себя изучение описаний функций безопасности в спецификации, изучение проекта программного обеспечения и вникание в его реализацию в исходном коде.
• Руководства пользователя разделяются на две отдельные категории: те, которые управляют приемкой и установкой программного обеспечения, и те, которые управляют процессом эксплуатации и администрирования. Оценка этих руководств определяет их адекватность и соответствие требованиям безопасности в области взаимодействия с программным обеспечением.
• Нужно внимательное изучение методологии разработчика, модели жизненного цикла, управления конфигурацией, мер безопасности во время разработки и других скрытых аспектов.
• Тестовая документация. Она необходима для понимания внутреннего режима работы программного обеспечения и характеристик его функций безопасности. В нем раскрывается подход разработчика к задаче тестирования безопасности.
• Следующая область — пентест. Здесь необходимо принять роль потенциальных злоумышленников, чтобы выявить уязвимости ПО. Это дает ценную информацию и возможные варианты укрепления защиты.
• Для завершения процесса составляются отчеты. Они содержат перечень выявленных уязвимостей, рекомендации по их устранению.
• Техническая сторона процесса: подготовка отчета о технической оценке. В нем изложена суть результатов оценки, содержащая выводы относительно соответствия требованиям безопасности.

Как часто нужно проводить оценку соответствия по ОУД4?

Когда дело доходит до оценки соответствия ПО (программного обеспечения), важно определить, как часто это следует делать. В законах и правилах, устанавливаемых Банком России, нет конкретного указания о том, как часто это должно происходить. Однако мы можем опираться на аналогии с ГОСТ 57580.1–2017 и использовать риск-ориентированный подход.

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

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

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