Меня зовут Александр Вознесенский, я AppSec Teamlead в VK. Не так давно мне в очередной раз задали вопрос: «Чем занимается AppSec?». И обычно, отвечая на этот вопрос в двух словах, я чувствую, что должен дать больше информации. Поэтому решил подготовить эту статью.
Начну с того, что универсального ответа на этот вопрос нет. Многие компании, предоставляющие услуги по консалтингу в сфере ИБ, производители и интеграторы различных инструментов приводят собственное определение Application Security. Некоторые говорят о том, что Application Security это комплекс мер, включающий и стандарты, и процессы проектирования, и формирование требований к цифровым продуктам до написания кода. Другие в своих материалах больше сосредоточены на автоматизированных инструментах, которые помогают искать уязвимости в разработанном решении.
На просторах отечественного рынка труда представлено множество вакансий в области Application Security, и нет единого набора обязанностей специалиста AppSec.
Многое зависит от компании, зрелости IT-процессов и производственного процесса, технологического стека, даже от состава и потребностей команды в определённый момент времени. Также сильно на круг задач влияет тип бизнеса компании. Компании-разработчики программных продуктов больше сосредоточены на отсутствии уязвимостей в своём приложении, его интерфейсах и кодовой базе. Крупные корпорации, которые занимаются внутренней разработкой для автоматизации своих собственных процессов, в профиль AppSec-инженера вкладывают не только безопасность кода и приложений, но и безопасность бизнес-процессов и IT-ландшафта компании.
Несмотря на различия, можно сформировать примерный перечень компетенций AppSec. Погуглив вакансии, я сформировал такой список задач:
Развитие SSDLC.
Архитектурные проверки.
Автоматизация DevSecOps.
ИБ-тестирование.
Поддержка Bug Bounty.
Обучение сотрудников.
Работа с инцидентами в ИБ (AppSec).
Давайте чуть подробнее поговорим о каждом из этих пунктов.
Развитие SSDLC
На мой взгляд, это ключевой пункт. Остальные задачи AppSec из этой статьи можно так или иначе уложить в применение практик SSDLC. Смысл в том, чтобы находить или предотвращать появление уязвимостей на всех этапах жизненного цикла разработки ПО (SDLC).
Для повышения безопасности разработки ПО существует множество способов и практик. Каждая из этих практик может быть наиболее уместна на определённом этапе жизненного цикла разработки. Например, уязвимости в архитектуре лучше всего отслеживать ещё на этапе проектирования, потому что на более поздних этапах, когда сервис уже написан, будет гораздо сложнее их исправить.
Чтобы структурировать безопасную разработку, создаются фреймворки. Яркими примерами являются BSIMM и OWASP SAMM. Фреймворки не содержат в себе практических рецептов, они предназначены для структурирования и оценки зрелости безопасной разработки. Развитие в компании таких практик — это ваше поле для исследования и импровизации.
Автоматизация (DevSecOps)
Автоматизация проверок безопасности — тренд последних лет. У кого-то уже есть свои «звездолёты», кто-то только начинает свой путь к автоматизации, но в целом это действительно фокусная цель. Очень редко ресурсов отдела ИБ хватает на весь спектр задач SSDLC. Разработчиков сотни, а AppSec-инженеров единицы. Это абсолютно нормально, все живут с этой действительностью. В условиях нехватки ресурсов приходится выкручиваться, приоритизировать и автоматизировать. Один из вариантов — встроить проверки безопасности в линию сборки сервисов (CI/CD). Конечно, тут мы сильно зависим от возможностей применяемых инструментов, но такой подход имеет место быть. Благодаря автоматизации мы можем обеспечивать очень широкое покрытие сервисов самыми необходимыми тестами безопасности.
На текущий момент никакая, даже самая дорогая автоматика не сравнится с человеком. Любые автоматические средства действуют лишь в соответствии с заложенными в них правилами и не способны от них отступать. Также автоматика сама по себе не способна копать глубоко. Но зато с её помощью можно охватить относительно простыми и рутинными проверками сразу большие объёмы кода. Например, мы автоматизировали проверки в тысячах наших проектов и таким образом быстро находим в этом огромном массиве какие-то типовые уязвимости.
Что касается инструментов автоматизации, я считаю, что главное — это не инструмент, а принятые в компании процессы. Какая разница, чем сканировать код, если после этого никто не разобрал получившийся бэклог? У нас, к примеру, действует трёхуровневая система разбора: начинающие коллеги разбирают самые простые и очевидные находки, а всё, что посложнее, передают на второй уровень, более опытным сотрудникам. На третьем уровне к разбору срабатываний подключаются эксперты — люди, чьё время наиболее ценно.
ИБ-тестирование
Это основная рутина AppSec-инженера, а также ключевой навык, который будут оценивать на собеседовании. Это классический Offensive белым ящиком. На внутреннем тестировании нужно меньше fuzzy'ить чёрным ящиком, а больше смотреть в код и разговаривать с разработчиками. Это требует немного другого образа мышления. Тестирование продукта на безопасность тянет за собой обсуждение предлагаемых исправлений и контроль устранения найденных уязвимостей в установленные сроки.
Результаты тестирования создают бэклог для команды автоматизации, если найденные баги достаточно просты, чтобы искать их автоматизированными средствами.
Тестировать можно целиком весь сервис или часть функциональности. Например, если реализована новая или значительно изменена существующая функциональность, это повод провести тестирование безопасности. Хорошей практикой является интеграция тестирования продукта с тестированием на безопасность. Так достигается оценка готовности продукта к запуску не только со стороны функциональности, масштабируемости под нагрузкой, но и со стороны безопасности. В реальной жизни ресурсов ИБ может не хватить в моменте для тестирования навалившейся кучи релизов, и тогда часть изменений может быть исследована позже. В таком случае лучше выделить менее критичные изменения, которые инженер AppSec будет проверять уже в промышленной среде.
Как видите, в AppSec даже ИБ-тестирование это не только про навыки взлома, но и в значительной степени про процессы.
Архитектурные проверки
Практика архитектурных проверок помогает предупредить появление уязвимости ещё до момента написания кода. Например, продакт-менеджер готовит новую фичу и придумал хитрую схему с шифрованием данных на FrontEnd. Чем раньше к процессу разработки этой фичи подключится безопасность, тем быстрее мы скорректируем архитектуру решения и тем меньше придётся переделывать на более поздних этапах. На финальных этапах тестирования исправить архитектурные дефекты слишком затратно. Для проведения архитектурной проверки в некоторых случаях достаточно будет 15-минутной встречи и абстрактного устного описания фичи или сервиса. А где-то без подробной архитектурной схемы и утверждения ИБ невозможно приступить к следующим этапам. В архитектурной проверке многое зависит от опыта AppSec-инженера и умения обращать внимание на вещи, которые могут приводить к уязвимостям.
Поддержка Bug Bounty
Программа Bug Bounty позволяет привлекать к поиску уязвимостей в наших сервисах широкое сообщество специалистов, которые способны очень пристально их изучить и найти то, что мы могли упустить. Каждая уязвимость для компании — это повод поработать над ошибками. Скажем, если кто-то из участников программы принесёт нам уязвимость с открытым SSH с паролем по умолчанию, то мы понимаем, что у нас что-то идёт не так с сетевыми настройками или мы недостаточно покрываем наши активы (shadow IT).
И если компания поддерживает свою программу Bug Bounty, то вам, как инженеру AppSec, придётся проверять и фильтровать множество отчётов, разбираясь, какие из них отправить в мусорку, а какие действительно принесли нам крутые уязвимости. Попутно нужно организовывать исправление найденных багов и уязвимостей в соответствии с SLA.
Обучение сотрудников
Одно из основных ожиданий работодателей. Смысл понятен: если разработчик будет знать, как сделать безопасно, то вряд ли он сделает небезопасно. Вы не можете проверять защищённость каждой выкладки в мастер-ветке во всей зоне вашей ответственности, но вы можете пойти другим путём. Просто покажите разработчикам последствия их «допущений», и они будут более осмотрительны в дальнейшем (в моём идеальном мире). Скажем, для предотвращения IDOR-уязвимостей нужно донести разработчикам важность проверки отношения субъекта и доступа к объекту. Проще говоря, почему важно проверять права пользователя прежде чем выводить приватную информацию (например, историю покупок или личных сообщений). В обучении помогут регулярные post mortem’ы, курсы адаптации новичков и прочие практики повышения осведомлённости сотрудников. И поверьте, обучение — это гораздо больше, чем подготовка материала.
Работа с инцидентами ИБ
Продукты, которые разрабатывают компании, рано или поздно добираются до промышленной эксплуатации. Уязвимости, пропущенные в ходе разработки или тестирования, может находить эксплуатация продукта. В случае возникновения инцидентов ИБ в промышленной среде, классифицированных как дефект приложения, инженер AppSec является полноценным участником разбора и исправления багов наряду с командами разработки.
Напоследок
В AppSec чрезвычайно важны технические навыки самого специалиста, но большую роль играют и личностные качества, организованность. По работе придётся поддерживать кучу внутренних процессов и практик безопасной разработки. Мы не пишем продуктовый код и не администрируем продуктивные серверы. Но нам приходится много взаимодействовать с людьми, чтобы обеспечить безопасность, и мы должны разбираться в этих областях. Мне кажется, AppSec-инженер — это менеджер проекта с навыками в Offensive, разработке и архитектурном проектировании. AppSec-инженер может сочетать в себе эти роли в разных пропорциях, в зависимости от проекта, навыков и должности.