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

Поднимаем бокал за коллег и начинаем рассказ… Среди проектов нашей компании ярко сияют системы, разработанные на базе СИГМА:Алькор — ядре, используемом при создании продуктов для оперативного управления работами предприятий топливно-энергетического комплекса. Одним из таких продуктов является решение для актуализации сведений о приборах учета, фиксации показаний и нарушений и иных важных параметров. И в прошлом году наш отдел стал работать с командой продукта департамента заказной разработки. Вместе мы исправили критические уязвимости продукта и выстроили процесс безопасной разработки так, чтобы не напоминать коллегам о разборе новых срабатываний анализаторов. Взаимодействие оказалось таким легким и кайфовым, что мы решили все зафиксировать, а затем повторить с другими командами.

Пройдемся по нашим шагам?

1 шаг. Легкий старт

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

2 шаг. Обучение

Для всей команды и особенно для ответственных Security Champion’ов команды продукта мы провели курсы и индивидуальные консультации по использованию AppSec-инструментов, требованиям и документам по информационной безопасности, на которых строится работа в нашем контуре и у заказчиков. А еще прошлись по актуальным уязвимостям и выдали материалы для самопроверки (основные темы: OWASP TOP 10, OWASP Proactive Controls, уязвимости web и mobile платформ).

Лирическое отступление

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

3 шаг. Архитектурный контроль

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

• команде продукта,

• проектной документации,

• отчетности,

• протоколах совещаний,

• тестовой документации и результатах тестирования,

• релизной политике,

• архитектурных схемах,

• и многому другому в доступной, понятной и полной форме.

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

Теперь вернемся к архитектурному контролю. У нас есть шаблон отчета, в котором расписаны функциональные требования по безопасности из внутренних методик по информационной безопасности компании. Если по-простому — там все, что требуется от разработчиков. Что сделала команда продукта: перевела основную таблицу из нашего документа в вики-систему и постепенно наполняла ее вопросами и результатами как самостоятельно, так и в ходе наших совместных встреч (их было около 5 штук, что редкость! Причем большинство встреч инициировала сама разработка).

В итоге у продуктовой команды было полное понимание:

• всех пунктов требований по БР (что из себя представляют, зачем нужны, кто ответственный);

• пунктов, которые точно выполняет решение (что уже реализовано и дополнительных действий по разработке не требуется);

• пунктов, по которым необходимо завести задачи в разработку или эксплуатацию.

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

4 шаг. Встраивание инструментальных проверок

Параллельно архитектурному контролю мы встраивали инструментальные проверки в CI/CD команды разработки. Здесь получилось добиться плотного взаимодействия между инженерами ОБР и DevOps команды продукта. Потратили много сил, но результат того стоил! Мы встроили автоматические security-проверки в CI/CD, которые функционируют до сих пор. Теперь при изменениях кода, а также по заданному расписанию происходят сканирования исходных текстов (SAST), используемых компонентов (SCA) и контейнеров (CA). В любой момент времени все участники видят актуальный статус по уязвимостям. А что с этой ситуацией делать, читаем в шаге №6.

5 шаг. Динамические проверки

Динамический анализ веб-приложения (DAST) и динамический анализ мобильного приложения (mDAST) у нас в СИГМЕ осуществляется в автоматизированном режиме инженерами ОБР. Почему же данные проверки мы не встроили как предыдущие три? Ответ прост — автоматизированный режим (с участием специалиста) по сравнению с автоматическим дает возможность расширить поверхность атаки и покрыть максимальное количество функционала приложений. К тому же в некоторых случаях существуют ограничения, при которых невозможно реализовать полную автоматизацию. Результат этого пункта также найдется в следующем шаге.

6 шаг. Обработка результатов (уязвимостей)

Этот шаг заслуживает особого внимания. Итак, обработка уязвимостей по всем практикам (SAST, SCA, CA, DAST, mDAST) происходила по единому принципу:

1. Сканер обнаружил потенциальную уязвимость.

2. AppSec-аналитик протриажил (обработал) или обозначил срабатывание как ложноположительное (с обоснованием), либо отправил на проверку Security Champion’у.

3. Security Champion проверил актуальность срабатывания и либо обозначил его ложноположительным (с обоснованием), либо отправил на исправление разработчикам.

4. Разработчик исправил подтвержденную уязвимость.

5. Сканер при повторном сканировании не обнаружил данное срабатывание.
   

По итогам множества итераций проверки/перепроверки команда создала специальные правила обработки ложноположительных срабатываний, а еще исправила ВСЕ реальные уязвимости. Это действительно удивительный случай, ведь ребята обработали даже самые некритичные срабатывания (уровня medium, low).

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

7 шаг. Контроль реализации требований ИБ

На обработке уязвимостей процесс не завершается. Команда продукта выполнила все поставленные по итогам архитектурного контроля задачи. Была подготовлена программа методика испытаний (ПМИ), согласованная с ОБР, и по ней, совместно с заказчиками, проведены приемо-сдаточные испытания (ПСИ).

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

8 шаг. Анализ защищенности

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

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

Закрыли этот вопрос совместными встречами, мастер-классами от спеца ОБР для команды продукта, на которых демонстрировался способ поиска подобных уязвимостей.

9 шаг. Выдача результатов

По итогам всего перечня проверок и активностей ОБР подготовил положительное заключение. В нем же разработанный на базе СИГМА:Алькор продукт был рекомендован в промышленную эксплуатацию.

Успех!

Резюмируем

Итак, проверки пройдены и все хорошее — формальные отношения между командой разработки продукта и отделом безопасной разработки — когда-то заканчивается. Но у всего нашего взаимодействия остались важные эффекты: разработка подключена к AppSec-инструментам, Security Champion самостоятельно контролируют состояние продукта. А если смотреть глобально, то благодаря такому положительному опыту мы шагнули в сторону повышения уровня безопасности разрабатываемого ПО и повышения уровня доверия к продуктам СИГМЫ. А это, согласитесь, уже совсем другой уровень?.

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

Давайте еще раз зафиксируем перечень проверок:

• архитектурный контроль;

• статический анализ исходного кода продукта (SAST);

• анализ используемых opensource-компонент (SCA);

• анализ контейнерных приложений (CA);

• динамический анализ программного обеспечения (DAST), включая фаззинг-тестирование;

• динамический анализ мобильных приложений (mDAST);

• контроль реализации требований информационной безопасности;

• анализ защищенности (АЗ).

Что дальше?

В этом проекте все сложилось идеально благодаря взаимопониманию с коллегами, но и тут есть куда расти. Впереди:

• развитие направления Security Champion в СИГМЕ — проведение курсов, повышение осведомленности и т.д.;

• автоматизация проверок DAST, mDAST;

• встраивание Quality Gates (автоматические проверки качества, которые устанавливают пороговые значения для продвижения продукта по конвейеру разработки);

• контроль целостности ПО на этапе развертывания;

• введение новых практик проверки.

Мы решили поделиться этой историей, потому что на собственном примере убедились — мэтч ИТ и ИБ случается. А за этим следует более безопасная разработка и рост доверия к ИТ-продуктам. Обязательно продолжим делиться этой темой и будем рады вашей поддержке. Всем хороших выходных!

Автор: Денис Павлов