Руководство по разработке безопасного программного обеспечения пример

СОИБ. Анализ. Разработка безопасного ПО

В сегодняшней заметке хотелось бы
поговорить про свежий ГОСТ Р 56939-2016 ЗАЩИТА ИНФОРМАЦИИ. РАЗРАБОТКА
БЕЗОПАСНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ. ОБЩИЕ ТРЕБОВАНИЯ. Разработан ЗАО НПО
Эшелон, недавно отличившимся в пропущенных уязвимостях SN и DL. Введен в действие с 1
июня 2016 г.

Стандарт современный, учитывающий
актуальные практики, но высокоуровневый. Всё-таки это общие требования, которые
потом хорошо бы детализировать. Предназначен для разработчиков ПО и организаций,
проводящих оценку соответствия процесса разработки ПО (аудиторов).  В соответствии с лучшими практиками (как в
австралийском ISM)
требуемые меры вводятся тремя формами: должен (must), следует(should) и может(may). Предусмотрены компенсирующие меры
для неприменимых.

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

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

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

·        

Руководство по разработке безопасного
программного обеспечения (РБПО)

o  

Описание средств разработки ПО

o  

Описание средств управления конфигурацией

o  

Порядок оформления исходного кода

o  

Порядок маркировки версий ПО

o  

Порядок отслеживания уязвимостей

o  

Порядок систематического поиска уязвимостей

·        

Отчеты (о разовых мероприятиях)

o  

Статистического анализа кода

o  

Экспертиза исходного кода

o  

Функционального тестирования

o  

Тестирования на проникновение

o  

Динамического анализа кода

·        

Свидетельства об обучении сотрудников

Популярные сообщения из этого блога

Дмитрий Пономарев, 30/12/22

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

Авторы:
Дмитрий Пономарев, технический директор испытательной лаборатории ООО НТЦ “Фобос-НТ”
Роман Карпов, директор по стратегии и развитию технологий Axiom JDK компании “БЕЛЛСОФТ”, руководитель комитета по ИБ АРПП “Отечественный софт”

Предпосылки

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

В качестве частного примера с далеко идущими последствиями можно привести проработку федеральной службой в сотрудничестве с сообществом экспертов в области ИБ-технологий подхода к декларированию программных компонентов, аналогичного изданному в 2021 г. указу [1] президента США, в числе прочего обязывающему разработчиков декларировать компонентный состав продукта – формировать SBoM (Software Bill of Materials, или реестр компонентных связей).

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

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

Введение автоматизированного механизма в определенном смысле поместит разрабатываемые программные решения «под рентген», снизив возможность сокрытия компонентов из-за недобросовестной работы эксперта.

Не менее важной предпосылкой к внедрению процедур безопасной разработки (SDL, Secure Development Lifecycle) является осознание того, что SDL – не только «про безопасность», это один из доменов практик качественной разработки!

Информация считается защищенной только в случае, если она обладает тремя свойствами одновременно: целостностью, доступностью и конфиденциальностью. Таким образом, любое падение или замедление работы системы, вызванное программной ошибкой, нарушает свойство доступности, а также зачастую ведет к перерасходу ресурсов. Перефразируя известную фразу Стива Балмера, СЕО Microsoft, «Developers! Developers! Developers!», можно сказать: «Тестирование, тестирование, тестирование!»

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

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

Реализация

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

Рассмотрим опыт разработчиков российской среды исполнения Java на базе проекта с открытым исходным кодом OpenJDK. Отечественные инженеры внедрили концепцию жизненного цикла безопасной разработки с момента создания программного продукта Axiom JDK. Команда уже четверть века работает над улучшением Java-технологий, в том числе в центрах разработки Oracle и Sun, и сегодня входит в число лидеров SDL-разработки в России.

На технологиях Java работает подавляющее большинство критически важных государственных, банковских и промышленных систем. Одна из идей, лежащих у истоков российского дистрибутива среды исполнения Java в концепции SDL by Design, – создать надежный продукт, обеспеченный высоким уровнем доверия потребителя, вниманием к процессам тестирования и качеству при каждом обновлении. SDL позволяет воплотить эту идею и сократить расходы на процессы, необходимые для поддержания качества.

Итак, какие этапы необходимо пройти инженерной команде, чтобы внедрить в разработку принципы SDL?

1. Убедить руководство: заручиться поддержкой и бюджетом

Первый (или нулевой) этап предполагает определение бюджета и убеждение руководства в необходимости проведения данных мероприятий. Хорошо, когда инициатива изначально исходит от руководителей компании, но это бывает нечасто. Хорошим аргументом может стать ощутимый размер убытков в случае обнаружения уязвимостей после выпуска изделия в промышленную эксплуатацию. Эксперты из LLVM Project приводят [2] следующую оценку: если стоимость исправления бага на этапе разработки около $25, то после релиза она может быть порядка $16 000, то есть в 640 раз выше.

При проработке плана действий необходимо учесть особенности SDL-процесса в парадигме ФСТЭК России:

• выявление уязвимостей и недекларированных возможностей, статический и динамический анализ в первую очередь в отношении тех компонентов решения, которые находятся на поверхности атаки;
• опора на технологическую и методологическую поддержку ИСП РАН, разработки которого востребованы в России и в мире. В числе его сотрудников – все пять российских ревьюверов gcc-компилятора. Помимо компетенций в технологиях классической продуктовой безопасности ИСП РАН входит в шестерку исследовательских центров в сфере искусственного интеллекта, отобранных в 2021 г. в рамках проекта «Искусственный интеллект» национального проекта «Цифровая экономика». Он сконцентрирован на анализе безопасности технологий искусственного интеллекта;
• активное взаимодействие с сообществом – привлечение участников сообщества к развитию методик и требований разработки и анализа СЗИ, создание информационных ресурсов для обучения компаний.

2. Получить и проработать требования к продукту для сертификации по SDL

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

Например, при подготовке к внедрению SDL и сертификации для Axiom JDK обсуждались и прорабатывались требования и тесты для проверки следующих механизмов:

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

3. Сформировать команду для поддержания SDL-процесса

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

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

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

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

• минимально Junior по SDL/DevSecOps должен обладать следующим набором знаний на базовом уровне: С/C++, работа с Linux, информационная безопасность, а также опционально – базовые знания языка/стека технологий для конкретного изделия/проекта, на котором нужно внедрять SDL;
• специалист уровня Security Champion имеет хорошее понимание C/C++, работы сетевых протоколов, механизмов работы Linux и C runtime, понимание принципов ИБ и их прикладного значения, обладает опытом работы с инструментами тестирования (статические анализаторы, фаззеры, отладчики) и инструментами анализа (статические анализаторы, средства реверс-инжиниринга – дизассемблеры, декомпиляторы, сетевые сканеры, средства пентеста).

4. Выбрать актуальные инструменты

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

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

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

Статический анализатор Svace (ИСП РАН)

Это постоянно развивающийся инновационный продукт для статического анализа, основанный на многолетних исследованиях. Он объединяет ключевые качества иностранных аналогов (Synopsis Coverity Static Analysis, Perforce Klocwork Static Code Analysis, Fortify Static Code Analyzer) с уникальным использованием открытых промышленных компиляторов в целях максимальной поддержки новых стандартов языков программирования. Svace, например, является основным статическим анализатором в компании Samsung, в которой заменил мирового лидера – Coverity.

Инструмент Svace применяется в Axiom JDK для анализа кода C/C++, а также Java-кода с учетом ранних ограничений на анализ исходных кодов, написанных на Java 17. Благодаря передовому движку межмодульного анализа, чувствительному к контексту и путям выполнения, широкому спектру доступных в Svace детекторов и удобству интерфейса разметки срабатываний Svace, команде удалось обнаружить и исправить ряд дефектов в релизах JDK 8, 11 и 17. Работа с этим инструментом подразумевает разметку и разбор предупреждений, выявленных в ходе сертификационных испытаний, и затем написание патчей к выявленным проблемам исходного кода.

Система определения поверхности атаки Natch (ИСП РАН)

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

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

Задачей Natch является выявление структурных элементов кода (функций), значимо взаимодействующих с потоками данных, формируемых потенциальным нарушителем с целью изменения штатной логики работы программы (может быть связано с кодовыми или алгоритмическими ошибками), а также различных неучтенных потоков данных (в самом деле, типовое СЗИ типа межсетевой экран может состоять из ядра Linux и 300–500 пакетов, скомпонованных в единое целое меняющейся командой разработчиков различной квалификации; наличие неучтенных «хвостов» и «точек входа» – это типичное событие при сертификации более-менее крупных программных решений) [3].

Помимо технологий анализа ИСП РАН, в России развиваются и другие команды. В частности, стоит иметь ввиду такие решения, как система SCA-анализа.

Система SCA-анализа и проверки компонент на лицензионную чистоту CodeScoring (Profiscope)

Это уникальное отечественное решение композиционного анализа программных продуктов, решающее задачи инвентаризации компонентной базы продуктов (Bill of Materials), поиска уязвимостей в компонентах Open Source, анализа лицензионного ландшафта и лицензионной чистоты (ближайший аналог – система OWASP Dependency Track). Это пример отечественной команды и разработки со всеми правами на разрабатываемую кодовую базу.

Система комплексного статического и динамического анализа кода AppScreener (Ростелеком-Солар)

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

Инженеры Axiom JDK считают, что для библиотек доверенного репозитория следует иметь в арсенале два анализатора, и в дополнение к Svace рассматривают использование AppScreener для эшелонированного статического анализа.

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

5. Выстроить процесс реализации требований

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

В примере с продуктом Axiom JDK требовалось вовлечение специалистов по Java, С/С++, безопасности и тысячи часов рабочего времени. В результате испытаний были обработаны и разобраны тысячи событий срабатываний санитайзеров, полученные при тестировании, исправлены дефекты и повышено качество продукта. Затем была сформирована дорожная карта по организации, улучшению и расширению процессов SDL.

Эти усилия дали значимые результаты. В частности, для реализации требований ФСТЭК России (фиксировать результаты испытаний) SDL-команда провела серьезную работу по выстраиванию автоматизированной системы порождения различной отчетности, раскатыванию тестовых комплектов на разные процессорные архитектуры и затем – на различные сборки операционных систем. Увеличилось число тестирований в соответствии с рекомендацией ФСТЭК России выполнять их везде, а отчетные материалы стали создаваться автоматически: они верифицированы и принимаются регулятором, можно даже добавить электронную подпись. В результате удалось снизить нагрузку на разработчиков при подготовке отчетности.

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

В работы по SDL-проекту команда Axiom JDK инвестировала 10 человеко-лет, причем самостоятельно, а не под давлением ФСТЭК России. Инженеры верифицировали 3 Гбайт программного кода. Благодаря этому сертифицированный продукт готов к использованию в качестве платформы в критических информационных инфраструктурах и промышленному тиражированию как платформа для Java-приложений и облачных провайдеров, которым требуется сертификация ФСТЭК России.

6. Обмениваться опытом в сообществе SDL

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

Например, сотрудничество ИСП РАН и команды Axiom JDK позволило улучшить как программный продукт, так и инструмент Svace. Специалисты института получили набор рекомендаций по улучшению его работы, связанных как созданием новых типов детекторов, так и с модификацией уровня значимости некоторых типов детекторов, с учетом особенностей, присущих именно Java-коду.

Сила сообщества в единстве непохожих участников и зачастую прямых конкурентов или оппонирующих сторон в процессе сертификационных испытаний (регулятор – лаборатория – разработчик). Они объединяются в вопросах, которые касаются развития безопасной и качественной кодовой базы и нормативно-правовых документов. Технологический центр исследования безопасности ядра Linux [4], работающий под эгидой партнерства ФСТЭК России и ИСП РАН, включает уже более 26 отечественных организаций. Это яркий пример сотрудничества, которое приносит значимые результаты для мирового Open Source-сообщества независимо от международной ситуации. Так, например, за период с февраля по декабрь 2022 г. были обнаружены и поданы в апстрим 64 значимые уязвимости кода и патчи к ним. Координация участников сообщества и обмен опытом осуществляются в телеграм-чате @sdl_community и нескольких других.

Выводы

Внедрение SDL дает разработчикам возможность сократить расходы на сопровождение программного продукта, ускоряет тестирование и выпуск новых релизов, позволяет запустить разработку в промышленное производство. В то же время SDL является базовым требованием при сертификации ПО в дополнение к необходимым функциям безопасности, определяемым документами ФСТЭК России. Разрабатываемые программные средства предназначаются для повышения уровня защищенности объектов критической инфраструктуры, АСУ ТП и информационных систем, обрабатывающих персональные данные. При этом высокое качество, актуальность и востребованность создаваемых продуктов позволяет реализовывать их и для других информационных систем с повышенными требованиями по безопасности, что исключительно важно сегодня, когда число кибератак выросло в 1,5 раза по сравнению с 2021 г., а на КИИ – нефтяную, энергетическую и финансовую отрасли – в 1,7 раз.

Примеры минимизации необязательной кодовой базы

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

Год назад в ходе сертификационных испытаний межсетевого экрана Ideco UTM произошел достаточно поучительный случай. Он особенно важен, поскольку разработчики Ideco весьма ответственно относятся к собственной кодовой базе и занимаются ее минимизацией и анализом самостоятельно, без давления регуляторов. специалисты Ideco решили «на спор» поискать в кодовой базе развернутого межсетевого экрана интерпретируемый код. архитектор утверждал, что ничего, кроме python-кода, в составе дистрибутива нет и быть не может, однако первый же запуск grep/-name «*.pl» нашел некоторое количество perl-кода. после чего выяснилось, что он есть, и даже есть сам интерпретатор perl, хотя при этом он нигде не используется. «раз пошла такая пьянка, режь последний огурец!» – решили поискать заодно и js, что удивительно – нашли! Откуда он там?! Оказалось, что на js (то есть прямо в формате скрипта) присутствует файл конфигурации демона policykit, реализующего систему раздачи прав пользователям и работающего с root-привилегиями. Для чтения файла конфигурации используется mozjs – js-движок из состава firefox, разумеется написанный на C.

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

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

1. https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/ 
2. https://llvm.org/devmtg/2020-09/slides/Using_the_clang_static_ananalyzer_to_find_bugs.pdf 
3. Полный список инструментов и технологий, разрабатываемых ИСП РАН, доступен по ссылке https://www.ispras.ru/downloads/ISP_RAS_Catalogue_of_technologies_2022_ru.pdf
4. https://portal.linuxtesting.ru/ 

Разработка безопасного программного обеспечения по ГОСТ Р 56939-2016

5 сентября, 2016

---

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

---

Проектирование ПО с учетом требований стандартов безопасности

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

Основной материал подготовлен и составлен на основе требований стандарта PCI DSS.  Данные требования также могут быть применены к обработке и хранению персональных данных в части выполнения требований GDPR.

Мой 12 летний опыт подготовки и успешного прохождения аудитов в разных странах мира показывает, что многие компании, которые занимаются разработкой ПО имеют системы и решения собственной разработки, которые обрабатывают карточные (и персональные) данные. А со стороны PCI Council есть даже отдельный стандарт PA DSS, который регламентирует требования к тиражируемому программному обеспечению. Вот только, большинство компаний в моей практике, будь то США, Британия или Китай, которые проходили аудит PCI DSS, не имели планов по тиражированию и продаже ПО. Более того, компании специально вносят ряд изменений в ПО используемое в рамках определенного проекта, чтобы не проходить аудит PA DSS, если это ПО внедряется на заказ. Потому не всегда выполнение требований стандарта и прохождение сертификации желанно и оправдано, а в данной статье приведены именно упомянутые стандарты, а не требования PA DSS.

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

Итак, давайте перейдем к детализации и описанию требований.

Общие разделы стандарта PCI DSS.

 Требования PCI DSS (на основе требований PCI DSS 3.2.1)

1.      Минимизировать места и сроки хранения критичных данных. В контексте данной публикации критичные данные — это данные, безопасность которых регламентируется требованиями PCI DSS + GDPR (карточные и персональные данные). 

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

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

2.    Критичные данные в базах данных, рекомендовано хранить в зашифрованном виде.

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

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

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

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

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

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

5.       Базы данных должны размещаться в отдельной подсети от подсети приложений.

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

6.       Все тестовые параметры при переводе в эксплуатацию должны быть удалены.

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

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

Не все алгоритмы шифрования считаются стойкими.

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

8.       Запрещено хранить пользовательские пароли, только хеш (результат выполнения однонаправленного преобразования над паролем). 

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

9.   Проверка на OWASP TOP 10.

Необходимо проверять решение на основные уязвимости безопасности перед передачей его в эксплуатацию. Сам данный пункт достоин не то что одной, а целой серии статей от процесса проверок внутри Компании до внедрения систем Bug Bounty. Для начала рекомендуется проверять хотя бы на OWASP TOP 10.

10.   Использование персонифицированных учетных записей.

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

11.   Логирование действий с возможностью перенаправления во внешние системы.

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

12.   Система разграничения полномочий с минимально необходимыми правами.

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

13.   Шифрование безопасными ключами.

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

14.   Требования к стойкости пароля.

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

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

Дополнительные требования GDPR

Общие разделы регламента.

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

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

17. Обезличенные данные.

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

18. Должна быть предусмотрена возможность согласия пользователя на сбор и обработку его персональных данных (таких как куки), но не soft opt-in (когда считается, что согласие получается автоматически).

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

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

Данное требование должно быть реализовано как Granular Consent (для каждого конкретного типа отдельно).

20. Проведение Data Mapping.

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

Это последний по списку пункт, но один из самых важных в целом.

Публикация материала носит ознакомительный характер. Все указанные рекомендации являются частным экспертным мнением и могут отличаться от позиции PCI Council или ICO. Для реализации требований рекомендовано опираться на оригинальные версии официальных документов.

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

Более детально с моим опытом можно ознакомиться в рекомендательных письмах на сайте и отзывах в профиле Linkedin.  

 Актуальную и полезную информацию по PCI DSS и GDPR можно найти на сайте.