Всем привет! Меня зовут Евгений Иляхин, я работаю архитектором процессов безопасной разработки в Positive Technologies, вместе с командой консалтинга в области безопасной разработки мы специализируемся на внедрении AppSec в различных компаниях и всячески продвигаем этот подход в массы.

В отрасли ИБ существует множество методологий, фреймворков, моделей безопасной разработки, которые помогают встроить AppSec в цикл создания ПО: BSIMM, OWASP SAMM, BSA SSF, Microsoft SDL и другие. Каждый из них имеет свои особенности, преимущества и, скажем так, способ использования и адаптации к собственным процессам. В ходе нашей работы мы познакомились со многими из них и пришли к выводу, что российским разработчикам нужен собственный инструмент. Зачем? Что из этого получилось? Расскажу в этой статье.

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

Необходимость безопасной разработки понимают все, кто так или иначе связан с IT, — на нее есть спрос. Существует огромное количество информации, связанной с ее внедрением: подходы, меры, стандарты, лучшие практики. Несмотря на все это, проблемы с внедрением AppSec остаются актуальными. В чем же дело? Отвечаю: в отсутствии четкой системы и правильного подхода к внедрению AppSec.

Я вижу следующие проблемы:

• Слабая интеграция в процессы разработки: безопасность рассматривается отдельно, в отрыве от разработки, вместо того чтобы быть ее неотъемлемой частью.

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

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

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

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

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

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

Эволюция безопасной разработки, или Как появились фреймворки

А началось все с того, что однажды ребята из компании Microsoft пришли к следующему выводу: развитие технологий и увеличение масштабов производства ведут к тому, что становится кратно сложнее обеспечить безопасность разрабатываемого ПО традиционными методами ИБ. Решением стала концепция Security Development Lifecycle (SDL), которая описывала обязательные меры безопасности на всех этапах жизненного цикла приложений (см. рис. 1).

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

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

Самыми популярными фреймворками, пожалуй, можно назвать BSIMM (Building Security In Maturity Model) и OWASP SAMM (Software Assurance Maturity Model). Это уже были модели оценки зрелости, которые предоставляли более структурированное описание SSDL с опорой на опыт экспертного сообщества и других компаний. Они помогали компаниям проанализировать свои процессы безопасной разработки, позволяли оценить инициативы по обеспечению безопасности, найти слабые места и определить зоны развития.

Кстати, подробнее про BSIMM рассказывал мой коллега Артем Кармазин в своей статье.

Опыт Positive Technologies

Некоторое время в нашей работе при планировании стратегии развития безопасной разработки у клиентов мы использовали как раз модели оценки зрелости, дополняя их требованиями отраслевых стандартов. За основу брали, как правило, самый популярный BSIMM, который позволял:

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

2. Познакомиться с лучшими практиками и учесть их в работе.

3. Составить дорожную карту внедрения процессов безопасной разработки.

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

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

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

3. Отсюда вытекает и сложность в составлении дорожной карты. Инициативы нужно декомпозировать, анализировать на предмет противоречий, переводить в формат задач.

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

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

Постепенно мы поняли, что нам не хватает более четкой структуры и процесса внедрения AppSec. Мы активно включали в свою работу декомпозицию задач на отдельные этапы, чтобы структурировать процесс и контролировать его результаты. Сами задачи обрастали новыми рекомендациями и характеристиками: сложностью реализации, необходимыми организационно-распорядительными документами по результатам действий. Используемые инструменты (например, для тестирования безопасности — SAST, DAST) также требовали особого подхода к настройке и включению в процесс. Все это приводило к появлению новых уникальных инициатив и практик в рамках AppSec.

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

«А давайте», — ответили остальные.

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

Что легло в основу методологии AppSec Table Top

Результатом стала методология AppSec Table Top, которая включает в себя все необходимые меры и поможет внедрить принципы безопасной разработки. Наша цель — не просто предоставить увлекательное чтиво с перечнем необходимых мер, а дать читателям инструмент, который можно использовать в работе.

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

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

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

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

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

Структура и практическое применение методологии AppSec Table Top

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

1. Стадии разработки.

Стадии разделяют жизненный цикл на несколько глобальных этапов:

• PreStageSDL — подготовка, включающая планирование, проектирование архитектуры, настройку инфраструктуры и другие подготовительные этапы, предшествующие разработке.

• MainStageSDL — сердце разработки, охватывающее написание кода, тестирование, сборку и развертывание.

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

2. Процессы.

Стадии делятся на десять процессов. Каждый процесс соответствует какому-то более-менее принятому в обществе этапу жизненного цикла разработки ПО:

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

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

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

• Разработка — написание безопасного кода и проведение предварительных проверок кода.

• Сборка — меры безопасности, применяемые в процессе преобразования исходного кода в готовое приложение.

• Тестирование — инженерные и инструментальные практики тестирования приложения.

• Релиз и развертывание — меры по обеспечению безопасности при подготовке приложения и его вводе в эксплуатацию.

• Эксплуатация — мониторинг и обеспечение защиты приложения в продуктивной среде, а также сбор обратной связи и работа с инцидентами.

• Периодический анализ и тестирование — проведение внешних и внутренних исследований защищенности приложения.

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

3. Практики.

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

4. Инициативы.

Инициативы — это уже конечные меры и задачи, необходимые для реализации практик. Сейчас их 96.

Наглядно структура методологии отображена на таблице внизу.

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

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

• По статусу: «выполняется», «запланировано» или «неактуально».

• Этапу: первый, второй, третий год реализации.

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

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

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

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

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

Дальнейшее развитие

Текущая версия методологии — лишь первая. Мы не собираемся останавливаться на достигнутом и уже поместили 100500 задач в бэклог планируем дополнять наше детище свежими материалами и приложениями, а также раз в год обновлять методологию с учетом изменений в требованиях регуляторов, трендов безопасной разработки и обратной связи от экспертного сообщества. Несколько компаний уже используют AppSec Table Top в качестве стандарта, а несколько учебных центров добавили в программу обучения ее обзор. Методология доступна всем заинтересованным лицам, а мы открыты для предложений. Любая критика, рекомендации, свежий взгляд и личный опыт будут полезны для всего комьюнити. Делитесь обратной связью в комментариях и в нашем телеграм-чате.

Евгений Иляхин

Архитектор процессов безопасной разработки, Positive Technologies