Хабрахабр

Application Security Manager. Разработчик или безопасник?

Большинство успешных атак организации реализуется через уязвимости и закладки в софте. К счастью, сканер уязвимостей ПО уже рассматривается компаниями не как что-то экзотическое, а как необходимый элемент инфраструктуры защиты. Если при небольших объемах разработки можно использовать сканер as is, то когда объемы большие, приходится автоматизировать процесс. Но кто должен им управлять? Решать, как часто проверять релизы? Заниматься верификацией уязвимостей? Принимать решение, наложить ли вето на релиз и отправить код на устранение уязвимостей? И отвечать на многие другие вопросы. Вот тут на авансцену выходит Application Security Manager — менеджер по безопасной разработке ПО.

image

Артем Бычков, менеджер по безопасности приложений АО «Райффайзенбанк», и Даниил Чернов, руководитель направления Solar appScreener компании «Ростелеком-Солар», рассказывают, какие требования к Application Security Manager диктует практика разработки в российских компаниях.
Но где сыскать такую редкую птицу или как вырастить самим?

Кто такой Аппликейшн Секьюрити Менеджер

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

Давайте рассмотрим, какие задачи возникают в ходе реализации процесса безопасной разработки, которые предстоит решать Аппликейшн Секьюрити Менеджеру (АСМ).

Но вопросы безопасности возникают на различных этапах жизненного цикла системы, начиная от проектирования и заканчивая развертыванием на продуктив. У читателя может сложиться мнение, что работа АСМ связана исключительно с проведением проверок программных разработок на предмет соответствия требованиям безопасности. Но все они сходятся в ключевых моментах: о безопасности нужно думать на всех этапах жизненного цикла системы. Существуют различные модели построения цикла безопасной разработки (Software Security Touchpoints, SDLC и другие) и разные методики встраивания этих практик в процесс (в зависимости от применяемого подхода – waterfall, agile).

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

Какие требования предъявляются к АСМ

Во-первых, от него требуется понимание проекта, который он сопровождает. Это особенно важно в agile-разработке, когда, в отличие от ватерфольной модели, у тебя нет 2-х месяцев на то, чтобы провести ревью перед релизом. От АСМ зависит, например, как сформированные на этапе проектирования требования будут интерпретированы командой, как лягут на архитектуру, являются ли они вообще реализуемыми и не создадут ли серьезных технических проблем в будущем. Чаще всего АСМ является основным потребителем, интерпретатором и оценщиком отчетов автоматизированных инструментов и аудитов, сделанных третьими сторонами. Именно АСМ отфильтровывает нерелевантные и ошибочные результаты, оценивает риски, участвует в процессах управления исключениями и выработки компенсирующих мер.

image

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

Важны в том числе и «хард-скилы», ведь очень тяжело критически оценивать результаты работы профильных специалистов и автоматизированных инструментов, если не можешь прочитать код, не понимаешь возможных путей эксплуатации уязвимостей. Во-вторых, в дополнение к первому, АСМ должен обладать знаниями из различных областей: нужно понимать процессы разработки и принципы информационной безопасности. Как оценить, кто прав в подобной ситуации? Наверняка многие сталкивались с ситуацией, когда в отчете по анализу кода или пентесту фигурирует критическая уязвимость, но разработчики не согласны с этим (при этом они, как правило, тоже хотят создать безопасную систему) и указывают на то, что аудиторы не смогли провести эксплуатацию данной уязвимости. Если процесс разработки безопасного ПО строится руками внешней организации и/или по сервисной модели – кто и как будет оценивать работоспособность «технических» практик? Без технических навыков объективно разрешить спор будет сложно.

К нему постепенно подключаются проекты, отрисовывается красивый зеленый дашборд… и тут происходит ИБ-инцидент. Еще один жизненный пример: внедряется новый инструмент разработки, его работоспособность проверяется на референсном проекте, после чего он передается в промышленную эксплуатацию. Но этого не произошло, потому что… никто не посмотрел, а как работает этот топовый сканер уязвимостей, обычно выдающий прекрасные результаты, с SPA-приложениями на новом JavaScript-фреймворке. Как выясняется, использованная «дыра» должна была быть обнаружена еще на этапе динамического анализа. И никто не обращал на это внимание, поскольку все работало. Оказалось, что он не может «увидеть» динамически генерируемую форму аутентификации и сделать нужные проверки. У разработчиков не было потребности вникать в специфику функционирования сканеров, чтобы обратить на это внимание, а безопасники не видели критических отличий между разными подходами к веб-разработке.

Где взять такого специалиста

image

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

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

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

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

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

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

Итого

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть