Большинство успешных атак организации реализуется через уязвимости и закладки в софте. К счастью, сканер уязвимостей ПО уже рассматривается компаниями не как что-то экзотическое, а как необходимый элемент инфраструктуры защиты. Если при небольших объемах разработки можно использовать сканер as is, то когда объемы большие, приходится автоматизировать процесс. Но кто должен им управлять? Решать, как часто проверять релизы? Заниматься верификацией уязвимостей? Принимать решение, наложить ли вето на релиз и отправить код на устранение уязвимостей? И отвечать на многие другие вопросы. Вот тут на авансцену выходит Application Security Manager — менеджер по безопасной разработке ПО.
Но где сыскать такую редкую птицу или как вырастить самим? Артем Бычков, менеджер по безопасности приложений АО «Райффайзенбанк», и Даниил Чернов, руководитель направления Solar appScreener компании «Ростелеком-Солар», рассказывают, какие требования к Application Security Manager диктует практика разработки в российских компаниях.
Кто такой Аппликейшн Секьюрити Менеджер
Организации рано или поздно приходят к осознанию необходимости найма такого человека в команду. В частности, потому что никто из имеющихся в компании специалистов на эту роль напрямую не подходит. Разработчики? Их опыт работы связан именно с разработкой софта – транслировать найденные уязвимости в риски ИБ, а тем более риски для бизнеса для них весьма затруднительно. Безопасники? Для них проблематично погружение в тонкости разработки: для верификации уязвимостей необходимо умение разбираться в программных кодах на разных языках, что требует наличия серьезного опыта разработки.
Давайте рассмотрим, какие задачи возникают в ходе реализации процесса безопасной разработки, которые предстоит решать Аппликейшн Секьюрити Менеджеру (АСМ).
У читателя может сложиться мнение, что работа АСМ связана исключительно с проведением проверок программных разработок на предмет соответствия требованиям безопасности. Но вопросы безопасности возникают на различных этапах жизненного цикла системы, начиная от проектирования и заканчивая развертыванием на продуктив. Существуют различные модели построения цикла безопасной разработки (Software Security Touchpoints, SDLC и другие) и разные методики встраивания этих практик в процесс (в зависимости от применяемого подхода – waterfall, agile). Но все они сходятся в ключевых моментах: о безопасности нужно думать на всех этапах жизненного цикла системы.
Очевидно, что в рамках более-менее крупного проекта один человек вряд ли сможет выполнить работы на всех этапах. Редко кто в одиночку способен разработать требования к безопасности приложения, выполнить ревью его архитектуры и проверить результат работы аналитиков, провести аудит безопасности кода, убедиться, что во время тестирования были проведены необходимые тесты защищенности приложения и что система была безопасно развернута и правильно сконфигурирована. Более того, часто эти активности выполняются представителями разных команд и подразделений. Чтобы весь механизм работал, как нужно, движущей силой процесса должен стать АСМ. Задача АСМ – обеспечить выполнение практик безопасной разработки, либо своими силами, либо делегируя определенные задачи профильным специалистам. Однако, исходя из нашей практики, просто раздать задачи ответственным и почивать на лаврах у АСМ не получится.
Какие требования предъявляются к АСМ
Во-первых, от него требуется понимание проекта, который он сопровождает. Это особенно важно в agile-разработке, когда, в отличие от ватерфольной модели, у тебя нет 2-х месяцев на то, чтобы провести ревью перед релизом. От АСМ зависит, например, как сформированные на этапе проектирования требования будут интерпретированы командой, как лягут на архитектуру, являются ли они вообще реализуемыми и не создадут ли серьезных технических проблем в будущем. Чаще всего АСМ является основным потребителем, интерпретатором и оценщиком отчетов автоматизированных инструментов и аудитов, сделанных третьими сторонами. Именно АСМ отфильтровывает нерелевантные и ошибочные результаты, оценивает риски, участвует в процессах управления исключениями и выработки компенсирующих мер.
Приведем пример из жизни: аудит или сканер исходного кода выявил в проекте использование небезопасной хеш-функции (MD5). Политика компании формально настаивает на том, что использовать ее нельзя, и вендор согласен заменить функцию на более безопасную за 3 месяца и крупную сумму. Нюанс состоял в том, что в данном случае неустойчивость хеш-функции к коллизиям никак не влияла на безопасность системы, так как функция не использовалась для защиты целостности. Формальный подход в данном случае и замена одной функции другой привел к необоснованному затягиванию сроков вывода проекта в продуктив и значительным затратам, дав нулевой выигрыш в безопасности.
Во-вторых, в дополнение к первому, АСМ должен обладать знаниями из различных областей: нужно понимать процессы разработки и принципы информационной безопасности. Важны в том числе и «хард-скилы», ведь очень тяжело критически оценивать результаты работы профильных специалистов и автоматизированных инструментов, если не можешь прочитать код, не понимаешь возможных путей эксплуатации уязвимостей. Наверняка многие сталкивались с ситуацией, когда в отчете по анализу кода или пентесту фигурирует критическая уязвимость, но разработчики не согласны с этим (при этом они, как правило, тоже хотят создать безопасную систему) и указывают на то, что аудиторы не смогли провести эксплуатацию данной уязвимости. Как оценить, кто прав в подобной ситуации? Без технических навыков объективно разрешить спор будет сложно. Если процесс разработки безопасного ПО строится руками внешней организации и/или по сервисной модели – кто и как будет оценивать работоспособность «технических» практик?
Еще один жизненный пример: внедряется новый инструмент разработки, его работоспособность проверяется на референсном проекте, после чего он передается в промышленную эксплуатацию. К нему постепенно подключаются проекты, отрисовывается красивый зеленый дашборд… и тут происходит ИБ-инцидент. Как выясняется, использованная «дыра» должна была быть обнаружена еще на этапе динамического анализа. Но этого не произошло, потому что… никто не посмотрел, а как работает этот топовый сканер уязвимостей, обычно выдающий прекрасные результаты, с SPA-приложениями на новом JavaScript-фреймворке. Оказалось, что он не может «увидеть» динамически генерируемую форму аутентификации и сделать нужные проверки. И никто не обращал на это внимание, поскольку все работало. У разработчиков не было потребности вникать в специфику функционирования сканеров, чтобы обратить на это внимание, а безопасники не видели критических отличий между разными подходами к веб-разработке.
Где взять такого специалиста
Кто изучал рынок, тот наверняка столкнулся с острым дефицитом специалистов по безопасности приложений. Как правило сценарий выглядит следующим образом: внутренние заказчики составляют требования к кандидату и передают их в кадры. Если требования жёсткие, то по результатам свободного поиска на выходе компания получает ноль кандидатов, так как готовые специалисты крайне редко вывешивают резюме в открытый доступ. Если они и меняют работу, то это чаще всего происходит легко и непринужденно через имеющиеся контакты. Как быть?
Можно попытаться переманить профессионала из других компаний, но этот путь по разным причинам не всегда приемлем. Все чаще на рынке появляются конкурсы на аутстаффинг АСМ, что вполне успешно позволяет закрыть вопрос за счет аренды экспертов у сервис-провайдера.
Но есть и другой вариант. Можно попытаться вырастить своего профессионала. В качестве кандидатов на подобную роль могут подойти представители двух направлений:
- выходцы из разработки, увлекающиеся или желающие развиваться в сфере безопасности;
- безопасники-технари, знакомые с разработкой и безопасностью ПО и желающие глубже погрузиться в эту тематику.
И тем, и другим кандидатам понадобится овладеть недостающим пакетом знаний. При этом желающие «перековаться» выходцы из разработки будут обладать лучшим пониманием сложившейся культуры и процессов в знакомых им командах. У них может уйти довольно много времени на освоение областей знаний, связанных с информационной безопасностью. Однако опыт показывает, что среди разработчиков, тестировщиков, аналитиков и архитекторов можно найти интересующихся безопасностью людей, уже обладающих определенным набором знаний в сфере безопасности приложений. Они могут стать идеальными кандидатами на вакансию АСМ.
Профессиональным же безопасникам придется акклиматизироваться, меняя сложившиеся привычные подходы к организации работы и перенимая культуру в командах, занимающихся разработкой. Однако, если специалист по безопасности пишет код и знаком с процессами разработки, то в команду он вольется быстро и просто.
Итого
Контроль безопасности разработки – это в первую очередь бизнес-процесс, для успешного функционирования которого необходимо слаженное взаимодействие всех участников команды. «Сердцем» этого процесса является квалифицированный АСМ – он и вдохновитель, и двигатель направления, и исполнитель многих задач, и контролирующий менеджер, и много кто еще. В общем, и чтец, и жнец, и на дуде игрец. Найти или вырастить такого специалиста непросто, но если все же удастся, то будет всем счастье.
Автор: SolarSecurity
