Что не относится к разработке безопасного по

Как правильно организовать процесс безопасной разработки ПО (SDL): 6 шагов

Как правильно организовать процесс безопасной разработки ПО (SDL): 6 шагов 19.01.2023 09:00

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

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

Предпосылки

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

В качестве частного примера с далеко идущими последствиями можно привести проработку федеральной службой в сотрудничестве с сообществом экспертов в области ИБ-технологий подхода к декларированию программных компонентов, аналогичного изданному в 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. Итого: сократили несколько десятков Мбайт бинарного кода и два интерпретатора, что особенно важно при прохождении сертификационных испытаний, упростили сборочный процесс.

Разработка безопасного ПО для цифровых экосистем и платформ отечественной цифровой экономики

Современные цифровые платформы, особенно созданные на базе так называемых сквозных информационных технологий искусственного интеллекта (AI), больших данных (Big Data), квантовых вычислений (Q), дополненной реальности (VR/AR), облачных и пограничных вычислений (Сloud and Edge), промышленного интернета вещей (IoT/IIoT), не обладают требуемой кибербезопасностью для целевого функционирования в условиях разнородно-массовых кибератак из-за высокой структурной и функциональной сложности названных систем, потенциальной опасности имеющихся уязвимостей и «спящих» аппаратно-программных закладок — так называемых «цифровых бомб». Кроме того, еще недостаточно эффективны известные средства обеспечения безопасности, в том числе средства антивирусной защиты, сканеры уязвимостей, а также системы обнаружения, предупреждения и нейтрализации компьютерных атак и пр. Поэтому достаточно важно обеспечивать требуемую безопасность на каждом этапе жизненного цикла разработки соответствующей цифровой платформы: анализ требований, проектирование (Secure By Design), программирование отдельных компонентов и подсистем, сопряжение подсистем в систему в целом, тестирование и эксплуатация и сопровождение (при модернизации и выводе из эксплуатации).

Практика Agile

В настоящее время широкую известность получила методология гибкой разработки программного обеспечения Agile («живой, подвижный» или «гибкий»). Актуальность этой методологии объясняется несовершенством (недостаточностью) известных «тяжелых» и «неповоротливых» практик разработки программного обеспечения на основе традиционной «водопадной» модели программотехники.

Основными причинами повышенного интереса разработчиков приложений к методологии гибкой разработки программного обеспечения Agile стали:

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

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

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

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

Методология Agile позволяет оперативно вносить изменения и наращивать функциональность решения.

Улучшение коммуникационных возможностей. Agile-подход акцентируется на непосредственном общении постановщиков задачи и разработчиков лицом к лицу. Большинство Agile-команд располагаются в одном офисе, иногда называемом bullpen. В состав команды включается «заказчик» (product owner) или его полномочный представитель, который определяет требования к результату разработки; эту роль может также выполнять менеджер проекта, бизнес-аналитик или клиент. Также в состав команды включают дизайнеров интерфейса, тестировщиков, технических писателей и других специалистов.

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

С какими трудностями приходится сталкиваться разработчикам при использовании методологии Agile?

Коллектив разработчиков должен трансформироваться в полноценный так называемый трайб со своими кластерами и функциональными командами (скводами и чаптерами). В качестве инструмента автоматизации деятельности трайба можно выбрать, например, решение Atlassian JIRA, которое способно поддерживать сотни и тысячи активных задач. Нужно научиться работать в спринтах и производить расчет задач по story point’ам, которые можно учитывать, в том числе, и в системе мотивации разработчиков. Наконец, необходимо наладить полноценное управление изменениями, Change с использованием Agile-практик, а также решение оперативных задач по разработке цифровых платформ.

От Agile к SecAgile

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

Необходимость учета требований безопасности

Сегодня к лучшей практике безопасной разработки программного обеспечения относятся требования и рекомендации: SDL PCI DSS, SDL Microsoft, SDL Cisco, 7.3.5 СТО БР ИББС-1.4-2018 и др.

Практика SDL Microsoft

Так, например SDL Microsoft в состав мер безопасной разработки ПО включает следующий типовой набор мер: обучение, задание требований безопасности, проектирование, риск-анализ архитектуры ПО (моделирование угроз безопасности информации), статический и динамический анализа исходного кода программ, тестирование безопасности, выпуск и поддержка.

Однако упомянутая практика не содержит рекомендаций для независимой оценки полноты и достоверности реализованных мер безопасности. Отметим, что требования так называемых «Общих критериев» (ISO/IEC 15408), широко используемых для оценивания программного обеспечения по требованиям безопасности информации, также функционально ограничены. Например, применяются только для программного обеспечения с функциями безопасности, а номенклатура мер не содержит требования статического и динамического анализа, обучения и пр.

Основные этапы методики обоснования мер

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

• ГОСТ Р 56939 «Защита информации. Разработка безопасного программного обеспечения. Общие требования». Содержит ряд общих требований к реализации мер по разработке безопасного ПО;

• ГОСТ Р «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Определяет номенклатуру типовых угроз безопасности информации;
• ГОСТ Р «Защита информации. Разработка безопасного программного обеспечения. Руководство по разработке программного обеспечения». Включает свод практических рекомендаций по реализации мер разработки безопасного ПО согласно ГОСТ Р 56939;
• ГОСТ Р «Защита информации. Разработка безопасного программного обеспечения. Методика оценки соответствия». Описывает ряд типовых процедур по проверке соответствия организаций — разработчиков ПО требованиям ГОСТ Р 56939.

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

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

Отметим, что для формирования мер и средств контроля и управления безопасностью ПО можно также использовать рекомендации ГОСТ Р ИСО/МЭК а для конкретизации и расширения компонентов доверия — рекомендации ГОСТ Р ИСО/МЭК

Заключение

На практике использование адаптированной методологии SecAgile позволяет:

• определить характеристики среды разработки безопасных цифровых платформ;
• осуществить обоснованный выбор процессов, задач и работ из номенклатуры ГОСТ Р ИСО/МЭК 12207 с учетом характеристик среды разработки, а также требований к соответствующим цифровым платформам;
• уточнить перечень задач и работ с учетом предлагаемой номенклатуры мер по разработке безопасных цифровых платформ из ГОСТ Р 56939;
• документировать решения по внедрению выбранных процессов, задач и работ, а также соответствующих обоснований выбранных решений.

Существенно, что это позволяет реализовать следующие два основных сценария:

• декларация соответствия: в этом случае разработчиком цифровой платформы должны быть реализованы все меры, предложенные в стандарте ГОСТ Р 56939, и созданы соответствующие свидетельства;
• использование стандарта ГОСТ Р 56939 в качестве рекомендаций с целью повышения уровня защищенности цифровой платформы: в этом случае разработчиком ПО может быть выбрано подмножество мер, подлежащих реализации.

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

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

Что не относится к разработке безопасного по

Практический курс «Основы безопасной разработки программного обеспечения»

Код курса: S-123

О чем курс

Участники курса «Основы безопасной разработки программного обеспечения» изучат эталонную модель построения продуктовой безопасности в компании и на практике познакомятся с лучшими практиками и методиками обеспечения безопасности программных продуктов.

20 ак. часов
5 живых занятий

Что узнаете на курсе

Безопасная разработка

Научитесь выстраивать процессы поддержания продуктовой безопасности и разработки

Защищенные приложения

Узнаете особенности использования ролей, участвующих в процессе построения защищенных приложений

Продуктовая безопасность

Изучите способы поддержания продуктовой безопасности в компании

Защищенные приложения

Узнаете особенности использования ролей, участвующих в процессе построения защищенных приложений

Чему вы научитесь на курсе

Продуктовая безопасность

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

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

Изучите SDL, SDLc, DevOps, DevSecOps

Тестирование

Познакомитесь с методами, типами тестирования и рекомендациями по безопасному написанию кода

Кому будет
полезен курс

Специалисты по безопасности приложений с опытом работы до 1 года

Будущие руководители отдела безопасности приложений

DevOps инженеры

Компании, где работают наши выпускники

2 специальности в 1:
Разработчик и ИБ-эксперт

Ваше резюме после прохождения курса

Специалист по безопасной разработке

Средняя зарплата

200 000 ₽

Мои компетенции

Разработка и внедрение концепции SSDLc
Разработка pipeline на базе GitaLab
Ручной и автоматизированный анализ безопасности кода приложений
Построение модели ИБ угроз
Проведение тестирования на проникновение
Составление политик безопасности приложения

Инструменты, которыми владею

Получите консультацию
по выбору курса

Как проходит обучение в CyberEd

Иммерсивное обучение

Участник полностью погружается в профессиональную среду

80% практики

Практическое обучение в виртуальных лабораториях собственной разработки

Метод гарантированной ошибки

Через собственный опыт получаете представление о вашем уровне и точках роста. Преподаватель выступает в роли наставника

Проектное обучение

Микропроекты, где вы тренируете конкретные навыки

Программа курса

Занятие 1. Введение в информационную безопасность и концепты безопасности

• Определение информационной безопасности
• Концепции безопасности
• Риск-ориентированный подход. Управление рисками
• Вычисление рисков
• Оценка рисков
• Обработка рисков
• Оценка критичности уязвимостей — CVSS
• Модель угроз
• Нормативная база

Занятие 2. Принципы дизайна для безопасной разработки и требования для безопасной разработки

• Software Development Lifeсycle (SDLc)
• Security Development Lifecycle (SDL)
• DevOps
• DevSecOps

Занятие 3. Основные практики и принципы безопасной разработки

• Основные практики Security Development Lifecycle (SDL)
• Методики оценки зрелости ИБ процессов
• Принципы дизайна

Занятие 4. Тестирование и ПСИ для безопасного ПО

• Материалы тестирования (например: стратегии, планы, кейсы)
• Типы тестирования программного обеспечения QA
• Методы тестирования безопасности
• Рекомендации по безопасному написанию кода (Secure Coding Guidelines)
• Статический анализ безопасности приложений (SAST)
• Динамический анализ безопасности приложений

Занятие 5. Роли и метрики процесса по обеспечению безопасности программного обеспечения. Цепочки поставок и угрозы ПО цепочек поставок

• Роли процесса по обеспечению безопасности программного обеспечения (ОБПО)
• Другие роли
• Цепочки поставок и угрозы ПО
• Угрозы программному обеспечению цепочки поставок
• Метрики

Требования

Иметь опыт работы в ИТ-сфере (Разработчик, Администратор, Тестировщик, Инженер-поддержки, Архитектор, Product-owner и пр.)

Понимать как ведется разработка программных продуктов

Обладать навыками администрирования своей домашней ОС (Уметь установить и настроить ПО виртуализации VMWare, VirtualBox, Parallels и пр.)

Иметь опыт работы с Unix подобными ОС;

Иметь базовые знания о компьютерных сетях, протоколы DNS, TCP;

Иметь базовые умения программирования на любом языке.

Уметь читать специализированную документацию и техническую литературу на английском языке;

Уметь читать логи программ и способность самостоятельно гуглить ошибки для решения простейших проблем

Сертификат по итогам прохождения курса

Диплом профессиональной переподготовки
Преподаватели
Стать преподавателем

Игорь Кривонос

Эксперт в области Android/iOS

Константин Костеневский

Руководитель отдела аудита информационной безопасности

Павел Сорокин

Ведущий инженер по ИБ, Ozon

Андрей Муллин

Пресейл-архитектор в ИБ компании

Олег Безик

Преподаватель в МГТУ им. Баумана

Ильназ Гатауллин

Заместитель директора IZ:SOC

Александр Колесников

Malware Analyst в ИБ-интеграторе

Владислав Бурцев

Эксперт SOC и администрировании Windows

Ярослав Шмелев

Эксперт в вирусной аналитике и тестировании на проникновение

Юрий Тихоглаз

Эксперт в разработке ПО и криминалистике

Вадим Егоров

Эксперт в тестировании на проникновение

Сергей Сидорин

Эксперт SOC

Алексей Поляков

Эксперт в компьютерной криминалистике

Алексей Мещеряков

Эксперт в безопасной разработке

Артем Комарский

Эксперт в тестировании на проникновение

Нияз Кашапов

Эксперт по анализу защищенности мобильных и веб-приложений

Егор Зайцев

Эксперт в тестировании на проникновение

Петр Зузанов

Эксперт SOC

Иван Дьячков

Эксперт в threat hunting и SOC

Гайк Инанц

Эксперт в веб-разработке и data engineering

Егор Богомолов

Эксперт в наступательной кибербезопасности

Cпециалист по тестированию на проникновение Android/iOS & Android-разработчик (java/kotlin)

• Android-разработчик (java/kotlin)
• специалист по тестированию на проникновение Android/iOS
• инженер по безопасности
• Python-разработчик
• преподаватель по мобильной безопасности, разработке под Android и Python

Эксперт в области проведения внутреннего тестирования на проникновение и создания инфрастуктуры для проведение тестирования на проникновение

Успешно выполнил 200+ разнообразных проектов:

• по аудиту информационных систем и процессов
• комплексному аудиту
• расследованию инцидентов и случаев мошенничества
• управлению рисками и внутреннему контролю

Сертификаты:

• Certified Ethical Hacker (CEH)
• Burp Suite Certified Practitioner
• Certified Fraud Examiner (CFE)
• Certified Internal Auditor (CIA)

Работал пентестером в «Информзащите» и BI.ZONE, после этого перешел в Application Security, а затем в «Яндекс» и Ozon

Более 6 лет преподавательской деятельности

Павел регулярно выступает на отраслевых конференциях по кибербезопасности. Публичные доклады:

• GraphQL applications security testing automatization (ZeroNights 2019)
• PDO и проблемы, которые может вызвать 0 byte (ZeroNights 2021)
• OPA с Docker executor ( БЕКОН 2023)

Ключевые компетенции:

• Защита веб-приложений
• Безопасная разработка приложений
• Тестирование на проникновение
• Аудит защищенности

Сертификаты:

• Offensive Security Web Expert (OSWE)
• Offensive Security Certified Professional (OSCP-2020)

Преподаватель в 1 образовательной программе

Пресейл-архитектор в ИБ компании
10+ лет работает в сфере информационной безопасности

Опыт работы в компаниях:
Positive Technologies
CTI, Руководитель группы решений информационной безопасности

Обладает сертификатами Cisco Devnet Associate, Fortinet NSE7, Fortinet NSE5, Huawei HCIE R&S, Cisco CCIE Security Written, PT-MP-CP, PT-AF-CP, PT-SIEM-CP, Cisco CCNP R&S, Cisco CCNP Security, CCSE

Ключевые компетенции:

• Практическая кибербезопасность
• Построение систем мониторинга
• Разработка документации
• Аудит ИБ
• Проектирование архитектуры системы ИБ

Преподаватель в 3 образовательных программах

Преподаватель в МГТУ им. Баумана

Более 8 лет работает в сфере ИБ, более 5 лет преподает дисциплины по кибербезопасности

Сертификаты
2021 – CEDS
2019 – CHFI
2018 — ISACA CISM

Также работал в компаниях:
KPMG, старший менеджер
PwC, менеджер
CSI Group, Руководитель департамента Forensic Technology Solutions

Ключевые компетенции:

• Комплаенс-менеджмент
• Компьютерная криминалистика

Заместитель директора IZ:SOC
Более 7 лет работает в сфере информационной безопасности

Ильназ принимает участие в турнирах Standoff. В 2020 г. занял 1 место на стороне команды защиты

Опыт работы в компаниях
Информзащита, заместитель директора SOC
РТ-Информ, аналитик по ИБ
Таттелеком, инженер по ИБ

Ключевые компетенции:

• SOC
• Windows Server
• Threat Hunting
• Расследование инцидентов ИБ
• Цифровая криминалистика

Преподаватель в 1 образовательной программе

10+ лет работает в сфере информационной безопасности.

Александр регулярно выступает спикером на отраслевых конференциях, security -митапах и принимает участие в соревнованиях конференции PHDays на стороне атакующих. Обладает сертификатом CEH .

• внешнее тестирование на проникновение
• анализ защищенности мобильных и веб-приложений
• реверс инжиниринг Code Review

Преподаватель в 4 образовательных программах

Senior Threat Intelligence analyst at Kaspersky. Также работал в компаниях:

• Информзащита, Аналитик SOC, технический эксперт
• Ростелеком, ИТ Аналитик

Экспертиза в области информационной безопасности – 3 года.

Владислав регулярно выступает на отраслевых конференциях по информационной безопасности.

• Администрирование Windows инфраструктуры;
• Написание детектирующих правил SIEM;
• Системное программирование;
• Реверс инжиниринг

Преподаватель в 1 образовательной программе

Вирусный аналитик в KASPERSKY LAB. В сфере информационной безопасности работает 7 лет.

Закончил МПиТК, кафедра ИБ в НИУ МИЭТ

Ярослав регулярно принимает участие в профильных соревнованиях:

• The Standoff 2022 – III место
• The Standoff 365 (beta-запуск) 2021 – I место
• Всероссийская студенческая олимпиада по информационной безопасности 2018 – I место

Ключевые компетенции:

• Исследование угроз;
• Вирусная аналитика;
• Тестирование на проникновение;
• Компьютерная криминалистика;
• Администрирование Linux

Преподаватель в 3 образовательных программах

HEAD OF COMPUTER INFORMATION SECURITY – CHIRPWIRELESS.IO
CO-FOUNER – ZERO E-DISCOVERY

Также работал в компаниях:

• Chirpwireless.io, Head of computer information security
• CSI Group, Старший Менеджер (Forensic Technology Solutions)
• PwC Russia, Менеджер (Forensic Technology Solutions)
• TNS Gallup Ad-Fact, Ведущий разработчик систем распознавания
• Вымпелком, Ведущий Инженер Службы поддержки и мониторинга критической инфраструктуры

Опыт работы в информационной безопасности более 15 лет.

Закончил Факультет Электронного Машиностроения в МИЭМ.

2021 — Управление инновациями и потоком стартапов в корпорации

2021 — ZyLab Certified Administrator

2021 — ZyLab Cerdified Analyst

2020 — Brainspace Certified Administrator

2020 — Brainspace Certified Analyst

2019 — Relativity Infrastructure

2019 — Relativity Admin Essentials

2017 — Core Consulting Skills (PwC)

Юрий регулярно выступает на отраслевых мероприятиях по информационной безопасности.

Ключевые компетенции:

• Разработка программного обеспечения;
• Криминалистический анализ данных;
• Разработка алгоритмов машинного обучения;
• Технологическое сопровождение независимых финансовых расследований;
• Реагирование на инциденты информационной безопасности.

iOS developer в APP ANALYSIS – DATA THEOREM.

Также работал в компаниях:

— AdGuard, Principal Security Researcher

— Avangard Motors LLC, Full Stack Engineer

— ACP MikBiLL, Back End Engineer

Опыт работы в сфере информационной безопасности – 6 лет.

Закончил Прикладное программирование в сфере предпринимательства в СПб ГУАП.

2021 — Moscow Institute of Physics and Technology, Cryptography

2021 — Cisco Certified Network Associate

2020 — Mail.ru, Compiler intricacies and deep C/C++ knowledge

Ключевые компетенции:

• Внешнее тестирование на проникновение;
• Анализ исходного кода web-приложений;
• Анализ защищенности мобильных приложений;
• Тестирование на проникновение
• Реверс инжиниринг мобильных приложений;
• Реверс инжиниринг десктопного ПО

Аналитик третьей линии SOC в ИНФОРМЗАЩИТЕ.

Также работал в компаниях:

— ФГБУ ФБ МСЭ Минтруда России, специалист по защите информации

— Московская Биржа, специалист в группе по мониторингу и реагированию на инциденты информационной безопасности, аналитик 3 линии SOC

Закончил Московский авиационный институт (национальный исследовательский университет) по специальностям Информационная безопасность телекоммуникационных систем и Кибербезопасность

2022 — School Codeby – SQL Injection Master

2021 — School Codeby — WAPT (Web Application Penetration Testing)

2020 — HackerU School – Информационная безопасность

Ключевые компетенции:

• Осуществление мониторинга и реагирования на инциденты информационной безопасности;
• Осуществление настройки аудита, СЗИ, иных источников для мониторинга;
• Написание правил корреляции и работа в различных SIEM-системах;
• Администрирование Windows;
• Администрирование сетей;
• Тестирование на проникновение веб-приложений (давно не имел практики. Проходил специальные курсы, самообразовывался)

Преподаватель в 8 образовательных программах

Ведущий эксперт по компьютерной криминалистике в BI.ZONE.

Опыт работы в сфере информационной безопасности более 10 лет.

Закончил Факультет Информационной безопасности НИЯУ МИФИ, кафедра Криптология и дискретная математика

2019 — GIAC Reverse Engineering Malware (GREM)

2019 — GIAC Certified Forensic Analyst (GCFA)

Ключевые компетенции:

• Incident Response;
• Digital Forensic;
• Malware Analysis

Преподаватель в 1 образовательной программе

Security engineer в KLARNA. Также работал в компаниях:

• Yandex, Information Security Engineer
• Sberbank-Technology, Application Security Engineer

Опыт по преподаваемым темам – 13 лет.

Закончил ​Институт Интеллектуальных Кибернетических Систем НИЯУ МИФИ и факультет информационных технологий АлтГТУ им. И.И.Ползунова.

2022 — Offensive Security Certified Professional (OSCP)

Алексей регулярно выступает на отраслевых мероприятиях по информационной безопасности.

Ключевые компетенции:

• Web & Mobile security
• Автоматизация процессов ИБ​
• Безопасность приложений​
• Построение процессов разработки безопасных приложений

Преподаватель в 1 образовательной программе

Старший специалист по тестированию в Singleton Security

Опыт работы в сфере информационной безопасности – 8 лет.

Артем регулярно принимает участие в отраслевых соревнованиях. На Standoff 2023 в составе команды True0xA3 занял 2 место

Работал в таких компаниях, как:

Центральная станция связи — Филиал ОАО РЖД , Ведущий технолог (специалист по информационной безопасности)
ООО «УК Деметра-Холдинг» , Ведущий специалист по информационной безопасности
Имеет опыт руководства подразделением информационных технологий в вооруженных силах РФ.

Закончил Пермский военный институт внутренних войск МВД РФ по специальности Автоматизированные системы управления , Программное обеспечение вычислительной техники и автоматизированных систем

Ключевые компетенции:

• Внутреннее тестирование на проникновение
• Внешнее тестирование на проникновение
• Применение социальной инженерии

Преподаватель в 1 образовательной программе

Application Security BP в Сбермаркет. Также работал в компаниях:

• Ak Bars Digital, Application Security
• Tinkoff, Application Security BP

Опыт по преподаваемым темам – 5 лет.

Закончил Институт Компьютерных Технологий и Защиты Информации КНИТУ-КАИ и Факультет компьютерных и инженерных наук в ​ИНСТИТУТЕ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ И КИБЕРФИЗИЧЕСКИХ СИСТЕМ университета Иннополис

Нияз регулярно выступает на отраслевых конференциях по информационной безопасности.

Ключевые компетенции:

• ​​Анализ защищенности web-приложений;​
• Анализ защищенности мобильных приложений;​
• ​​Безопасная архитектура​
• Организация процессов безопасной разработки (SSDLC)​
• Автоматизация тестирования безопасности приложений​

Преподаватель в 1 образовательной программе

Ведущий специалист в Информзащите. Также работал в компаниях:

• NLMK (Администратор баз данных)
• NLMK SOC (1-3 линия)
• Фриланс (Full-Stack Web Application Developer)
• Академия Шаг (Ведущий ментор)
• Информзащита (Ведущий специалист)

Опыт по преподаваемым дисциплинам – 3 года

Закончил Липецкий Государственный Технический Университет, АСУ

Егор регулярно принимает участие в отраслевых соревнованиях:

• Cuptur the flag Победитель соревнований по кибербезопасности по теме «Уязвимости веб-приложений» в 2021 году
• Laboratory Kaspersky KL 009.12: Kaspersky Security Centre. Systems management 2021

Ключевые компетенции:

• Внутреннее тестирование на проникновение;
• Физическое проникновение во внутренний контур;
• Анализ защищенности web-приложений;
• Социальная инжинерия;
• Программирование: Python, JS, VBA
• Написание сценариев: bash, PowerShell
• Написание запросов: PL/SQL
• Анализ инцидентов: ArcSight, KSC

Преподаватель в 7 образовательных программах

SecOps Manager в RingCentral. Также работал в компании Сбербанк. Опыт по преподаваемым темам – 15 лет.

Окончил факультет информационных технологий Санкт-Петербургского Государственного Университета Телекоммуникаций им. проф. Бонч-Бруевича

2020 — OFFENSIVE SECURITY – OSCP Exam

2016 — CISCO SYSTEMS — CCNP Security

Петр регулярно участвует в профильных соревнованиях:

• The Standoff – SPbCTF (RedTeam) в ноябре 2021 – III место
• The Standoff – SPbCTF (RedTeam) в мае 2021 – IV место
• Cyber Polygon – DINS (BlueTeam) 2021 – III место
• The Standoff – SPbCTF (RedTeam) 2020 – V место
• Internal Sberbank Pentest Lab 2018 – I место

Ключевые компетенции:

• Создание эффективного SOC
• Проектирование защиты высоконагруженных систем
• Построение сетевой защиты от внешних и внутренних угроз
• Построение процессов управления уязвимостями
• Тестирование на проникновение корпоративных сетей

Руководитель группы реагирования в RAIFFEISENBANK RUSSIA.

Также работал в компаниях:

• Positive Technologies, Старший специалист SOC
• АО Центральная Пригородно Пассажирская Компания, Ведущий специалист отдела информационной безопасности
• GANT/Barbour, Системный администратор

Суммарный опыт по преподаваемым темам – 6 лет.

Иван закончил факультет кибернетики МИРЭА по направлению Специалист по защите информации.

Сертификат SANS SEC511: Continuous Monitoring and Security Operations (2021)

• Threat Hunting
• Win/linux аудит (auditd, Sysmon, wineventlog) + администрирование
• Расследования инцидентов (SOC)
• Network Traffic analysis (PT NAD)

Преподаватель в 1 образовательной программе

Преподаватель МФТИ. Также работал в компаниях Glowbyte Consulting и Muon в роли data engineer.

Экспертиза в области информационной безопасности – 7 лет.

Закончил Факультет Защиты Информации в РГГУ.

Ключевые компетенции:

• ​​Веб разработка
• Data engineering

Преподаватель в 1 образовательной программе

Управляющий директор CyberEd, основатель компании Singleton Security.

Также работал в компаниях:

• HackerU, Head of Security
• Wallarm, Lead Pentester
• BI.ZONE, Pentester
• ЗАО НИП «Информзащита», Pentester
• Positive Technologies, Signature Analyst
• Direct-Credit, Full-stack Developer

Суммарный опыт по преподаваемым темам – 7 лет.

Закончил бакалавриат по направлению «Комплексная защита объектов информатизации» РГГУ, Институт информационных наук и технологий безопасности, факультет информационных систем и безопасности и магистратуру по направлению «Программная защита информации» МТУСИ, факультет «Информационные технологии.

Регулярно принимает участие в профильных соревнованиях:

• The Standoff 2022 – II место
• The Standoff 2021 – II место
• The Standoff 2021 – I место
• IDS Bypass 2019 – III место
• Wallarm & Qiwi HackQuest 2018 – III место
• Competitive Intelligence 2018 – III место
• DefHack 2018 – I место

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

2021 — Burp Suite Certified Practitioner (PortSwigger WebSecurity Academy)

2021 — CEH | Certified Ethical Hacker (EC-Council)

2019 — OSCP | Offensive Security Certified Professional (Offensive Security)

Ключевые компетенции:

• Внешнее тестирование на проникновение
• Анализ защищенности web-приложений
• Анализ защищенности мобильных приложений

Преподаватель в 3 образовательных программах

Мы обучили 3000 сотрудников
крупнейших компаний на рынке

/отзывы

Николай Колеганов

Профессиональный трек «Специалист по безопасной разработке приложений S-410»

Отличный трек подготовки «специалиста по безопасной разработке»! Профессионализм и практичность подачи учебного материала Дениса и Якова помогали лучше понять сложные и местами нудные моменты и нюансы разработки, более глубже понять необходимость тех или иных шагов при построении pipeline и их запуску! На учебных стендах всегда можно было отработать задания и попрактиковаться, а в случае сложностей обратиться к преподавателям! Очень много практических кейсов и реальной практики по внедрению и совершенствованию процессов!

Особенно понравилось, что было мало «сухой» теории, а больше «реальной» практики по объяснению материала! Сдача итоговых заданий очень интересные и всегда имеют практический опыт.

Полученные знания уже пригодились на рабочем месте и активно внедряю полученные навыки в рабочие процессы разработки!

Спасибо большое Денису и Якову за практическую помощь в систематизации и актуализации информации по безопасной разработке!

Читать далее

Ясмин Кадырова

Я пришла в школу CyberEd будучи студенткой, желая получить практические знания в сфере пентеста.

Главным критерием выбора курса для меня было соотношение потраченного времени на обучение и результата. Спустя 4 месяца я смогла успешно пройти интервью и попасть на стажировку в интересную компанию. Сейчас я работаю на постоянной позиции инженера по безопасности.

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

Очень рада, что однажды доверилась профессионалам из CyberEd! Рекомендую данный курс каждому, кто хочет познакомиться с этой черно-белой профессией!

Читать далее

Надир Мустафин

Всем рекомендую данную школу. Мое погружение в ИБ и в ИТ началось именно тут.

До данных курсов я мог только вкл/выкл комп, установить ПО. Сейчас работаю специалистом ИБ в одной из крупных ИТ-компаний РФ в области ИБ.

Хочу отметить таких преподавателей как Ильдар, Иван, Павел, Александр, Ярослав — это большие профессионалы. А главное они по-человечески относятся к обучающимся разных уровней и всегда помогают. Раскрывают тему максимально подробно и дают материалы для дальнейшего изучения.

Благодаря им и школе спустя половину курса (на 6-ой месяц из 12), я уже устроился на работу.

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

Нравится максимальная открытость и поддержка.

Для тех, кто только начинает свой путь, могу сказать, что это отличное место для старта, НО только если готовы уделить 90% своего свободного времени. Без собственных усилий ничего не получится.

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

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

В качестве огромного бонуса — это контакты таких же единомышленников!

До сих пор с ребятами и преподавателями дружим)

Читать далее

Мартун Минасян

Обучение в CyberEd было одним из лучших в моей жизни. Я был совсем новичок в области ИБ, без бэка в IT. Но как говорится, усердие и труд все перетрут)

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

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

Жизнь заиграла новыми красками. И самое главное после обучения — я понимаю, как устроены различные системы, какие уязвимости могут быть, как гуглить и подходить к решению сложных задач с разных сторон.

Очень рад, что когда-то принял решение обучаться в этой школе.

Читать далее

Елена Скалозубова

Курс «BlueTeam»

Это обучение вытянуло меня на новый уровень.

Будучи в декрете, решила пройти курс BlueTeam. Учеба началась в июне. Через несколько месяцев, в октябре, я решила составить резюме на hh.ru и походить на собеседования, чтобы понять, в каких моментах проседают мои знания. За 10 дней у меня было 4 собеседования (три на должность Инженера по информационной безопасности и одна в команду Red Team). И все 4 компании выставили мне офферы. Самый минимальный оклад был 150 тысяч и выше. И теперь я Ведущий инженер по системам информационной безопасности в крупной компании, да и еще на удалёнке!

Обучение нелёгкое. Не ждите, что вы просто будете смотреть видосики, а потом отдыхать. Если хотите стать высокооплачиваемым специалистом и кардинально поменять свою жизнь за год, то придётся попотеть. Домашние задания, лабораторные, лекции и дискуссии с преподавателями. Мне было очень интересно и не сказать, что легко, но это того стоило!

Читать далее

Владимир Иванов

Курс «Специалист по информационной безопасности»

Данный курс выбрал для с целью кардинально поменять профессию и сменить работу. Начинал еще с «основ информационной безопасности», так как в этом вопросе чистый 0.

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

Данное обучение требует 150% погружения. За себя могу сказать, что, как человек не из смежной специальности, чтобы что-то освоить на это требуется на 200% больше времени чем остальным. Да, и не забывайте делать домашку!

«Отвал башки» — это моё личное впечатление о курсе и о всем времени обучении.

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

О мерах по безопасной разработке ПО для значимых объектов КИИ

В 2017 году был опубликован Федеральный закон от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации», который регулирует отношения в области обеспечения безопасности критической информационной инфраструктуры Российской Федерации (далее – КИИ). Позже ФСТЭК России выпустила приказ от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации» (далее – Приказ № 239), в котором определены технические и организационные меры по обеспечению безопасности значимых объектов КИИ. В 2020 году приказом ФСТЭК России от 20.02.2020 № 35 в Приказ № 239 внесен, в частности, пункт 29.3, который предъявляет требования к прикладному ПО, обеспечивающему выполнение функций значимых объектов КИИ по их назначению, то есть ПО, которое используется для автоматизации критических процессов в значимых объектах КИИ. Например, это может быть следующее ПО, если оно установлено на значимых объектах КИИ:

• SCADA-системы в АСУ ТП (InTouch, Citect, SIMATIC WinCC, TRACE MODE и иные);
• программные продукты для автоматизированных банковских систем (ЦФТ-Банк, RS-Bank, Diasoft FA и прочие);
• биллинговые системы (FORIS BSS/OSS, Comverse One и прочие);
• BPM-системы (ELMA, Creatio, Directum и прочие)
• ERP-системы (BAS, 1С, SAP и иные).

Требования к прикладному ПО вступают в силу с 1 января 2023 года.

В этой статье будут разобраны требования к прикладному ПО значимых объектов КИИ. Также вы можете посмотреть другие статьи и вебинары по теме защиты КИИ на нашем портале 187.ussc.ru.

Распределение обязанностей

Поскольку требования п. 29.3 Приказа №239 относятся к процессу разработки ПО, то выполнять требования должен разработчик, в том числе, и документально подтвердить их выполнение. Однако не редки случаи, когда субъект КИИ использует ПО, для которого закончилась поддержка разработчика и субъект КИИ осуществляет поддержку ПО самостоятельно или, когда субъектом КИИ используется свободно распространяемое ПО. В таком случае обязанность выполнения требований лежит на субъекте КИИ.

В стандартной ситуации, субъект КИИ должен выставить требования разработчику ПО. В свою очередь, разработчик должен внедрить необходимые процедуры безопасности и документально подтвердить их внедрение. Тем не менее, ответственность за невыполнение требований несет субъект КИИ как владелец значимых объектов КИИ.

Оценку выполнения требований осуществляют лица, выполняющие работы по созданию, модернизации, реконструкции, ремонту и обеспечению безопасности значимых объектов КИИ. Это могут быть:

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

Результаты оценки выполнения требований к прикладному ПО включаются в проектную документацию на значимый объект КИИ и предоставляются субъекту КИИ, который несет ответственность за выполнение требований.

Государственный контроль выполнения требований по обеспечению безопасности значимых объектов КИИ (в т.ч. требований по безопасности разработки ПО) проводит ФСТЭК России.

Разделение обязанностей представлено на схеме:

Содержание требований

Требования по безопасности прикладного ПО включают:

1. требования по безопасной разработке. Для выполнения указанных требований необходимо:
   • определить меры обеспечения безопасной разработки ПО, внедрить их и документировать в руководстве по безопасной разработке ПО;
   • назначить ответственных лиц;
   • провести анализ угроз безопасности информации ПО (модель угроз);
   • описать структуру ПО на уровне подсистем и провести сопоставление функций ПО и интерфейсов, описанных в функциональной спецификации с его подсистемами;
2. требования к испытаниям по выявлению уязвимостей в ПО. Для выполнения указанных требований необходимо провести соответствующие испытания:
   • статический анализ исходного кода ПО;
   • фаззинг-тестирование ПО;
   • динамический анализ кода ПО (для ПО, применяемого на объектах КИИ первой категории значимости).
3. требования к поддержке безопасности ПО. Для выполнения указанных требований на ПО должны быть внедрены следующие процедуры:
   • отслеживание и исправление обнаруженных ошибок и уязвимостей;
   • информирование пользователей об уязвимостях ПО, компенсирующих мерах по защите информации или ограничениях по применению ПО, способах получения пользователями обновлений ПО и порядке проверки их целостности и подлинности;
   • информирование пользователей об окончании производства и (или) поддержки ПО (для ПО, применяемого на объектах КИИ 1 категории значимости).

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

Процесс безопасной разработки представлен на рисунке 1.

Рисунок 1 – Схема процесса безопасной разработки ПО

1. Руководство по безопасной разработке

На этапе планирования, когда определяются требования к разрабатываемому ПО, необходимо создать руководство по безопасной разработке ПО, где для каждого этапа разработки должны быть указаны меры по обеспечению безопасности ПО и процесса разработки в целом. В качестве методического документа можно использовать ГОСТ Р 56939-2016.

Схема подпроцессов безопасности разработки представлена на рисунке 2.

Рисунок 2 – Схема подпроцессов безопасности разработки

Рекомендуем регламентировать следующие процессы разработки ПО:

Процесс анализа требований к ПО

На данном этапе разработки должны быть определены требования по безопасности ПО. В качестве источника требований можно использовать, например, Приказ № 239, отраслевые стандарты и профили защиты ФСТЭК России.

На данном этапе должны быть проведены следующие работы:

• анализ угроз безопасности и разработка модели угроз безопасности информации;
• оформление проекта архитектуры ПО;
• оценка рисков в отношении процесса разработки.

Подробнее о содержании модели угроз и проекте архитектуры разберем в разделах 2 и 3.

На данном этапе должны быть определены и утверждены:

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

Также рекомендуется после проведения статического анализа кода с помощью автоматических средств провести экспертизу кода «вручную».

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

На данном этапе должны быть определены и утверждены:

• порядок приема ПО перед передачей пользователям;
• порядок передачи ПО пользователям;
• состав и содержание эксплуатационных документов на ПО, передаваемых пользователям.

На данном этапе должны быть определены:

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

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

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

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

2. Анализ угроз безопасности

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

Для анализа рекомендуется выполнить следующие шаги:

Построить схему информационных потоков (потоков данных) в ПО

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

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

В качестве источников информации об угрозах можно использовать:

• банк данных угроз безопасности информации ФСТЭК России (bdu.fstec.ru);
• публикации проекта Open Web Application Security Project (OWASP);
• MITRE Matrix;
• CWE top 25.

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

Еще одной методикой моделирования угроз является STRIDE, согласно которой для каждого компонента из схемы информационных потоков необходимо определить актуальность одной или нескольких угроз:

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

Для автоматизации процесса моделирования угроз по STRIDE существует инструмент, разработанный Microsoft, – Microsoft Threat Modeling Tool.

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

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

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

3. Проект архитектуры ПО

Проект архитектуры ПО должен содержать:

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

4. Статический анализ кода

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

5. Динамический анализ кода

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

6. Фаззинг-тестирование

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

7. Отслеживание и исправление обнаруженных ошибок и уязвимостей

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

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

Государственный контроль

Государственный контроль по выполнению требований в отношении субъектов КИИ осуществляет ФСТЭК России на основе анализа материалов и документов на ПО. Поэтому все реализованные требования должны быть документированы. Контрольные мероприятия проводятся ФСТЭК России в рамках плановых и внеплановых проверок в соответствии с Постановлением Правительства РФ от 17.02.2018 №162 «Об утверждении Правил осуществления государственного контроля в области обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Плановые проверки проводятся не реже, чем раз в три года после:

• внесения сведений о значимом объекте КИИ в реестр значимых объектов КИИ;
• окончания последней плановой проверки.

Внеплановые проверки проводятся после:

• истечения срока выполнения субъектом КИИ предписания об устранении выявленных нарушений;
• возникновения компьютерного инцидента на значимом объекте КИИ, повлекшего негативные последствия;
• приказа органов государственного контроля.

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

Компания УЦСБ помогает разработчикам ПО подготовить необходимые документы и провести тестирование ПО, а субъектам КИИ – провести оценку выполнения мер по безопасной разработке для ПО, применяемого на значимых объектах КИИ.