Привет, уважаемые любители защищенных приложений! В нашем блоге мы привычно освещаем практические кейсы разработки безопасного ПО (РБПО), но заметили, что вас также интересует мир регуляторики. Понимаем, не осуждаем и поэтому сегодня открываем серию статей с обзором актуальных нормативных требований, которые касаются практик безопасной разработки или реализуются с помощью внедрения практик DevSecOps. Выясним, на какие отрасли распространяется регуляторика и какую юридическую ответственность она влечет за собой, а также рассмотрим тренды и прогнозы на ближайшее будущее.
Немного вступления
Меня зовут Альбина Аскерова, я работаю в команде Swordfish Security руководителем направления по взаимодействию с регуляторами, и искренне верю - как красота в глазах смотрящего, так и в российской регуляторике много полезного, нужно только перевести с эльфийского нормативной лексики на понятный обывателю язык.
В нашей практике консалтинга по разработке безопасного программного обеспечения (РБПО) мы часто получаем от клиентов запрос на создание стратегии процессов РБПО, подбор и внедрение нужных инструментов с обязательным учетом всех действующих требований законодательства. Один нюанс – клиенты сами не всегда знают конечный список обязательных требований, но всегда очень переживают, если в рамках проверок выявляются нарушения.
На просторах интернета мы не нашли полного описания действующей регуляторики, в которой прямо или косвенно указаны требования к практикам безопасной разработки, и сделали такой обзор сами. Провели целое исследование (выжали более 30 документов) и с радостью готовы поделиться им с вами. Материала набралось много, поэтому мы поделим наш путь на 5 частей и опубликуем их в виде цикла статей:
Часть 1. РБПО: общие требования - ГОСТы, Указы Президента, Федеральные законы, Приказы (сейчас вы ее читаете);
Часть 2. РБПО: требования в финансовой отрасли;
Часть 3. РБПО: требования к КИИ;
Часть 4. РБПО: требования к ГИС, ИСПДн, отраслевые требования;
Часть 5. РБПО: ответственность, взгляд в будущее, инфографика всего обзора.
Важно! Еще раз подсветим, что мы будем говорить только про регулирование РБПО. Другие направления информационной безопасности тоже важны, но им мы посвятим отдельные материалы.
Важно № 2! РБПО в современном понимании это давно уже не только классический DevSecOps в виде разного вида анализов безопасности приложений. Сейчас наша классическая восьмерка разрастается и становится как бы ядром всех практик безопасности, которые влияют на безопасность приложения. Теперь это и инфраструктура (защищенность контейнерных сред, секретов), и цепочка поставок ПО, и вообще Secure by Design с подходом к безопасности еще на этапе появления первой мысли о создании приложения и многое другое.
Или еще такой вариант неких «кругов по воде» при замысле разработки продукта:
Разминка
Так как элементов творчества и креатива в регуляторике мало, попробуем на протяжении пяти частей помочь вам держать фокус внимания небольшими, но понятными обзорами, добавим немного юмора и разыграем мерч.
Начнем с синхронизации. Если это регуляторное бинго вызовет у вас улыбку сквозь слезы, то знайте – вы не один.
Перечитывал одно и то же 3 раза и каждый раз понимал по-разному | Только выполнил требование, а регулятор внес изменения | Добрый день! Завтра проверка, вот чек-лист на 100+ требований | Прочитал три дня назад, но понял только сейчас | Искренне веришь, что "инновации в регуляторике" — это не оксюморон |
Читал и думал - кто это написал? | Прочитал и понял нормативный документ с первого раза, не отвлекаясь на слёзы | Пришел за консультацией к юристам, но тебе пояснили, что они не безопасники | Провел вечер, изучая новый закон, и теперь можешь цитировать его наизусть (но никто не хочет тебя слушать) | Участвовал во встрече, где все согласны с тем, что правила — это хорошо, но соблюдение их — это уже перебор |
Понял, что самый сложный документ — это тот, который ты написал сам | Пытался объяснить коллеге, что "проверка соответствия" — это не то же самое, что "проверка на совместимость" | Участвовал в обсуждении новых правил и вспомнил о старых добрых временах, когда все было проще | Получил звонок от проверяющего и на мгновение поймал паническую атаку | Убедил начальство, что новые требования — это не конец света, а просто новое утро |
Получил от начальства задание "сделать так, чтобы нас не оштрафовали", и задумался о карьере в магии | Пытался объяснить, почему важна документация, и чувствовал себя проповедником | Прочитал новую регуляторику и почувствовал себя в научной фантастике | Составлял отчет и думал, что это похоже на написание романа | Пытался найти баланс между инновациями и соблюдением норм |
Слышал, как кто-то говорит: "Мы всегда соблюдаем правила", и не смог сдержать улыбку | Чувствовал себя Шерлоком, расследуя несоответствия в документации | Проводил встречу с коллегами, чтобы обсудить изменения в требованиях, и все пришли с разными мнениями, и все похожи на правду | Получил положительный отзыв от регулятора и почувствовал гордость за свою работу | Пытался объяснить родителям, чем ты занимаешься на работе, и они все равно не поняли |
Погнали!
Какие есть регуляторы и что они регулируют в РБПО?
Регуляторов у нас в стране много, и, по сути, все они говорят об одном и том же, только каждый со своей стороны. Также много отраслей экономики, среди которых можно выделить укрупненные виды требований. И типов документов тоже много, но глобально – обязательные и рекомендательные. В этих трех плоскостях будем двигаться.
Итак, чем дальше в Консультант, тем удивительней мир.
Источники нормативного регулирования РБПО
Президент;
Регуляторы – ФСТЭК России, Минцифры России, Банк России, Минэнерго России (сами не ожидали);
Росстандарт.
(Если кого-то упустила, обязательно напишите об этом в комментариях).
Для кого требования
Для себя мы выделяем глобально 5 типов систем/приложений по их целевому назначению:
Финансовая отрасль;
КИИ (если вы КИИ в финтех, то смотрите и требования к финансовой отрасли);
Системы обработки персональных данных (если обработка ПДн в финтех и/или КИИ, то смотрите еще и требования к ним);
Государственные системы, созданные для выполнения гос.полномочий, а также в иных установленных федеральными законами целях (если ГИС в финтех и/или КИИ, и/или обрабатываете ПДн, то смотрите еще и требования к ним);
Иное (тут общие требования типа ГОСТов, законов, указов, требования при сертификации ПО в системе ФСТЭК и сертификации процесса РБПО, тут Минэнерго с требованиями к энергетике. Предчувствуем, что список будет расширяться).
Про типы документов уже писала выше:
Обязательные к исполнению (Указы Президента, Федеральные законы, нормативные правовые акты регуляторов – приказы, положения);
Рекомендательные (ГОСТы, методические рекомендации). Важно, что они такие до тех пор, пока в обязательном документе не укажут, что рекомендательные являются обязательными 😊. Иными словами – дело добровольное, пока законодательство не скажет обратное.
Определились с классификацией (если у вас другая систематизация – поделитесь в комментариях) и начнем обзор с общих требований, которые распространяются на всех, вне зависимости от целевого назначения объекта защиты.
Общие обязательные:
Федеральный закон от 27.07.2006 № 149-ФЗ Об информации, информационных технологиях и о защите информации.
Среди прочих положений он также регулирует отношения, связанные с защитой информации. Этот закон действует для всех компаний, работающих в области информационных технологий.
Что тут из практик безопасной разработки ПО? Требования из статьи 16 «Защита информации»:
П.4. Обладатель информации, оператор информационной системы в случаях, установленных законодательством Российской Федерации, обязаны обеспечить:
1) предотвращение несанкционированного доступа к информации и (или) передачи ее лицам, не имеющим права на доступ к информации;
2) своевременное обнаружение фактов несанкционированного доступа к информации;
3) предупреждение возможности неблагоприятных последствий нарушения порядка доступа к информации;
4) недопущение воздействия на технические средства обработки информации, в результате которого нарушается их функционирование;
5) возможность незамедлительного восстановления информации, модифицированной или уничтоженной вследствие несанкционированного доступа к ней;
6) постоянный контроль за обеспечением уровня защищенности информации.
Общие рекомендательные:
ГОСТ Р 56939-2016 Защита информации. Разработка безопасного программного обеспечения. Общие требования.
Стандарт устанавливает условия к содержанию и порядку выполнения работ по созданию безопасного ПО и формированию среды обеспечения оперативного устранения выявленных пользователями ошибок и уязвимостей программы.
Раздел 5 ГОСТ содержит описание мер по разработке безопасного ПО, реализуемые:
5.1. при выполнении анализа требований к программному обеспечению;
5.2. при выполнении проектирования архитектуры программы;
5.3. при выполнении конструирования и комплексирования программного обеспечения;
5.4. при выполнении квалификационного тестирования программного обеспечения;
5.5. при выполнении инсталляции программы и поддержки приемки программного обеспечения;
5.6. при решении проблем в программном обеспечении в процессе эксплуатации;
5.7. в процессе менеджмента документацией и конфигурацией программы;
5.8. в процессе менеджмента инфраструктурой среды разработки программного обеспечения;
5.9. в процессе менеджмента людскими ресурсами.
Компании применяют ГОСТ на добровольной основе или в обязательном порядке, если это указано в нормативном документе. Кстати, скоро он выйдет в новой редакции, но об этом расскажем в следующей статье.
ГОСТ Р 15408-3-2013 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности.
Эта часть ИСО/МЭК 15408 определяет требования доверия ИСО/МЭК 15408. В ней описаны:
- Оценочные уровни доверия (ОУД), которые помогают измерять уровень доверия к объектам оценки (ОО);
- Составные пакеты доверия (СоПД), показывающие уровень доверия для составных ОО;
- Отдельные компоненты доверия, из которых складываются уровни и пакеты доверия;
- Критерии для оценки профилей защиты (ПЗ) и заданий по безопасности (ЗБ).
ГОСТ используется добровольно или обязательно, если он указан в каком-либо нормативном документе. Весь документ содержит описание методов и средств обеспечения безопасности информационных технологий при их разработке.
Более предметно про анализ уязвимостей описано в 15 разделе «AVA: оценка уязвимостей»:
- AVA_VAN.1 Обзор уязвимостей;
- AVA_VAN.2 Анализ уязвимостей;
- AVA_VAN.3 Фокусированный анализ уязвимостей;
- AVA_VAN.4 Методический анализ уязвимостей;
- AVA_VAN.5 Усиленный методический анализ.
Дополнительно установлены требования к композиционному анализу в разделе 16 «ACO: Композиция»:
- ACO_COR.1 Обоснование композиции;
- ACO_DEV.1 Функциональное описание;
- ACO_REL.1 Базовая информация о зависимостях;
- ACO_CTT.1 Тестирование интерфейсов;
- ACO_VUL.1 Краткий анализ уязвимостей композиции.
ГОСТ Р 58412-2019 Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения.
Стандарт описывает угрозы безопасности информации, которые могут появиться при разработке программного обеспечения. Его также могут использовать все организации добровольно или обязательно, если он упомянут в каком-либо нормативном документе.
Описанные в ГОСТ 58412-2019 угрозы безопасности информации при разработке ПО сопоставлены с мерами по разработке безопасного ПО из ГОСТ Р 56939-2016. Подробно тут рассматривать не будем, вся информация представлена в Приложении А ГОСТ 58412-2019.
ГОСТ Р 71207-2024 Защита информации. Разработка безопасного программного обеспечения. Статический анализ исходных текстов. Общие требования.
Весь ГОСТ в целом посвящен практике статического анализа ПО. Он определяет:
1. Требования к внедрению и порядку выполнения статического анализа;
2. Классификацию обнаруженных критических ошибок;
3. Требования к методам проверки, реализованным в статическом анализаторе;
4. Требования к инструментам SAST;
5. Требования к специалистам, которые проводят анализ;
6. Методику проверки требований к анализатору.
Здесь тоже отметим, что ГОСТ применяется добровольно или обязательно при упоминании в нормативном документе.
Общие опциональные
Приказ ФСТЭК России от 03.04.2018 № 55 Об утверждении Положения о системе сертификации средств защиты информации.
Этот документ устанавливает порядок сертификации средств защиты информации во ФСТЭК России. Он касается всех компаний, которые разрабатывают такие средства и хотят сертифицировать свою продукцию.
Практики РБПО затрагивают следующие пункты:
П.47 говорит о том, что при проверке компаний, которые разрабатывают программы и средства защиты информации, оценивается, насколько они внедрили процедуры РБПО в соответствии с требованиями безопасности, по которым проходят сертификационные испытания.
П.71.1. разрешает Заявителю, имеющему сертифицированный конвейер РБПО, самостоятельно тестировать свои средства защиты информации, если он вносил в них изменения.
Приказ ФСТЭК России от 02.06.2020 № 76 Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий.
Документ определяет уровни безопасности применения инструментов обработки и защиты информации. Устанавливается 6 уровней доверия для различия требований.
Приказ касается всех компаний, которые разрабатывают продукты и собираются сертифицировать их в системе ФСТЭК. Из практик РБПО в нём есть:
П.6. Требования к уровням доверия с правилами по безопасной разработке (обязательны для 6, 5, 4 ОУД):
1. Требования к разработке и производству средства:
1.8. требования к разработке документации по безопасной разработке средства.
2. Требования к проведению испытаний средства:
2.1. требования к тестированию средства;
2.2. требования к испытаниям по выявлению уязвимостей и недекларированных возможностей средства.
3. Требования к поддержке безопасности средства:
3.1. требования к устранению недостатков средства;
3.2. требования к обновлению средства;
3.3. требования к документированию процедур устранения недостатков и обновления средства;
3.4. требования к информированию об окончании производства и (или) поддержки безопасности средства.
П.7. При разработке средства разработчик должен выполнить действия по:
7) управлению конфигурацией средства (для 4 уровня доверия – управление изменениями средства, в том числе изменениями исходных текстов программного обеспечения и аппаратной платформы средства; применение автоматизированных мер контроля, обеспечивающих внесение в элементы конфигурации только санкционированных изменений; организацию процедур приемки модифицированных или вновь созданных элементов конфигурации);
8) разработке документации по безопасной разработке средства.
П.15. Требования к документации по безопасной разработке средства:
15.1. Для средства с 6-м уровнем доверия должна быть создана документация по безопасной разработке средства, включающая:
а) описание всех физических, процедурных, организационных и других мер безопасности, применяемых в среде разработки средства для защиты конфиденциальности и целостности проектной документации и реализации средства;
б) применяемые меры безопасности, направленные на снижение вероятности возникновения в средстве уязвимостей и иных недостатков, и их обоснование.
15.2. Требования к разработке документации по безопасной разработке средства, соответствующего 5 уровню доверия, соответствуют требованиям к разработке документации по безопасной разработке средства, соответствующего 6 уровню доверия.
15.3. Разработка документации по безопасной разработке средства, соответствующего 4 уровню доверия, наряду с требованиями, установленными пунктом 15.1, должна предусматривать разработку документации по безопасной разработке аппаратной платформы средства, которая должна включать описание организационных и технических мер безопасности, применяемых в среде разработки аппаратной платформы средства для защиты целостности проектной документации и аппаратной платформы средства.
П.21. Средство должно иметь поддержку безопасности, которая включает в себя:
1) устранение недостатков и дефектов, в том числе уязвимостей и недекларированных возможностей средства;
2) информирование пользователей об обновлении ПО и оповещение об обновлениях и изменениях в эксплуатационной документации;
3) документирование процедур устранения недостатков и обновления средства;
4) информирование об окончании производства и (или) поддержки безопасности средства.
Приказ ФСТЭК России от 01.12.2023 № 240 Об утверждении Порядка проведения сертификации процессов безопасной разработки программного обеспечения средств защиты информации.
Сертификация процессов разработки ПО средств защиты информации проходит по требованиям ГОСТ Р 56939-2016 "Защита информации. Разработка безопасного программного обеспечения. Общие требования". Этот приказ могут использовать компании, которые разрабатывают средства защиты и хотят сертифицировать свои процессы безопасной разработки. Другими словами, если вы создаете средство защиты и внедрили практики РБПО согласно ГОСТ 56939, то сможете сертифицировать свой процесс разработки и затем выпускать новые версии сертифицированного ПО без повторной сертификации ПО во ФСТЭК.
Из интересного:
Указом Президента от 18.06.2024 № 529 установлены приоритетные направления научно-технологического развития и список важных наукоемких технологий. Он определяет ключевые национальные цели и сроки их реализации, включая объем финансирования и план мероприятий.
Среди утвержденных приоритетных целей:
Безопасность получения, хранения, передачи и обработки информации (Раздел «Приоритетные направления научно-технологического развития»).
Технологии создания доверенного и защищенного ПО, в том числе для управления социальными и экономически значимыми системами (раздел «Перечень важнейших наукоемких технологий»).
Итак, мы завершили наше вводное знакомство с общими требованиями к РБПО. В следующей статье погружаемся в финансовую сферу — Банк России не поскупился на правила, так что будет интересно. До встречи через неделю 😊
Если что-то из общих требований не попало в обзор, делитесь знаниями в комментариях!
