Сейчас направление Application Security (AppSec) переживает бурный рост. Всё больше компаний выделяют AppSec в отдельное подразделение или начинают строить его с нуля. В крупных корпорациях появляются AppSec бизнес-партнеры, в стартапах лиды разработки всё чаще берут на себя задачи по обеспечению безопасности продуктов. Но с чего начать, если вы — первый AppSec-инженер или руководитель такого направления? Какие задачи поставить в первые полгода, чтобы заложить прочный фундамент?
Меня зовут Алексей Волков, я эксперт в области продуктовой безопасности. Здесь я поделюсь опытом построения AppSec-процессов с нуля в первые полгода: как разобраться в ИТ-ландшафте, настроить процессы и расставить приоритеты, чтобы сразу дать бизнесу ощутимую пользу. Чеклист и советы основаны на моём опыте — без абстракций и нереалистичных ожиданий. При этом важно оговориться, что ваша работа может затянуться — в каждой компании свой ландшафт и у всех проблем бывают разные сроки решения.
План работ рассчитан на одного специалиста. Но если у вас будет команда, вы сможете пройти эти этапы быстрее. Статья будет полезна новым AppSec-руководителям, Security бизнес-партнерам и лидерам разработки, которым важно не только понять, с чего начать, но и избежать распространенных ошибок.
Всего я выделил 8 этапов работ:
KYB (Know Your Business): Сбор информации о ключевых активах и бизнес-процессах компании, их приоритизация. Знакомство с коллегами.
Внедрение в процессы принятия решений: Участие в обсуждении чувствительных продуктовых и ИТ-изменений, определение своей зоны ответственности.
Проверка защищенности критичных приложений: Security-ревью, проверка политики безопасности, поиск быстро решаемых проблем.
Анализ результатов и обучение: Презентация итогов проверок, обучение коллег исправлению ошибок.
Детальное погружение в ИТ-процессы: Погружение в структуру разработки, анализ доступов и CI/CD процессов, изучение инфраструктуры.
Проверка защищенности приложений средней критичности: Проведение аналогичных третьему этапу проверок для менее приоритетных систем.
Повторный анализ и обучение: Выработка рекомендаций, обучение коллег, доработка процессов.
Формирование базы знаний и запуск AppSec-процессов: Создание инструкций, чеклистов, новых процессов для согласований и ревью.
На этом основные этапы заканчиваются, но работа в AppSec продолжается бесконечно. Далее вас ждёт Этап N — развитие таких направлений, как:
Vulnerability Management;
SSDLC;
Shift Left Security;
Пентесты и аудиты;
Bug Bounty и киберучения;
Харденинг процессов и инфраструктуры.
Каждый из этапов подробно разберу ниже.
Этап 1. Know your business
Поздравляю, вы приняли оффер! Первый рабочий день — отличный момент, чтобы начать погружение в новый мир. Что делать сначала? Нетворкинг и изучение корпоративных баз знаний — ваши лучшие друзья на этом этапе.
Ваша задача — понять, чем живёт компания: какие продукты она создаёт, какие бизнес-процессы для неё ключевые. Поговорите с руководителями подразделений, узнайте, какие активы и процессы для них самые важные. Это поможет сосредоточить усилия на том, что действительно имеет значение.
Затем выберите самые критичные активы и процессы с точки зрения безопасности. Не углубляйтесь в детали — позже всё можно уточнить.
Знакомство с бизнесом — это ваш стартовый капитал. Чем лучше вы разберётесь в том, как всё устроено, тем легче будет двигаться дальше.
Этап 2. Внедрение в процессы принятия ключевых решений
Чем быстрее вы начнёте следить за важными изменениями, тем лучше. Ваша задача — сделать так, чтобы команда знала: вы — тот человек, к которому нужно обращаться за экспертизой. Это касается любых чувствительных интеграций, архитектуры ключевых продуктов или других критичных вопросов.
Начните с изучения планов компании на ближайшие кварталы. Понять, куда движется бизнес, — половина успеха. Вторая половина — дать коллегам чёткое понимание ваших зон ответственности и знаний. Они должны знать, что в определённых вопросах за вами закреплено право голоса.
Почему важно заняться этим сразу? Чтобы успевать за ростом компании и сделать фундамент для дальнейшего внедрения практик shift-left security (если такая инициатива стоит перед командой).
Этап 3. Проверка текущего состояния безопасности критичных приложений
Когда вы уже уверены, что участвуете во всех важных обсуждениях и связи налажены, пора приступать к проверке защищенности приложений. Возвращайтесь к приоритизированным ранее активам и выберите, с чего начать. Формат проверки — будь то whitebox тестирование, пентест части инфраструктуры или аудит мобильного приложения — зависит от специфики приложения и ваших навыков.
Особое внимание уделите политике безопасности веб-сервера и внешней инфраструктуре. Такие уязвимости, как Security Misconfiguration, встречаются часто, но их настройка, как правило, не требует много времени.
На что обратить внимание в первую очередь? Сосредоточьтесь на недопустимых событиях — утечках, мошенничестве и байпассах с биллингом, потере данных или доступа к УЗ. Это позволит вам говорить с бизнесом на понятном языке и демонстрировать, почему ваши усилия важны. Кроме того, такие приоритеты облегчат получение согласия на исправления — тема следующего этапа.
Этап 4. Анализируем результаты и обучаем коллег
Теперь выявленные проблемы нужно донести до команды в понятной форме. Помните: вы первый, кто проводит такую работу в компании. Непонимание или слабая вовлечённость — нормальная реакция, через которую нужно пройти.
Оптимальный формат представления результатов:
Разбивка по критичности уязвимостей.
Векторы атак и их влияние на систему.
Примеры эксплуатации уязвимостей.
Рекомендации по исправлению.
Эти данные помогут коллегам понять суть проблем и осознать, почему их надо исправить. Вам пригодятся коммуникативные навыки: задача — договориться о точных сроках устранения проблем и согласовать их так, чтобы всё сделали с первого раза.
Ваши усилия на этом этапе обеспечат бесперебойную работу в будущем и укрепят доверие к вашей роли в команде.
Этап 5. Детальное погружение в ИТ-процессы
Пока выявленные уязвимости исправляются командами, потратьте время на более глубокое понимание работы ИТ-процессов компании. Это поможет вам лучше понять состояние текущей инфраструктуры и наметить дальнейшие шаги для повышения её безопасности.
Начните с процессов вокруг кода
Хранилища кода: где и как хранится код? Часто компании используют несколько Git-хранилищ. Разберитесь в их структуре, доступах и логике организации репозиториев.
Архитектура приложений: микросервисная или монолитная? Как организован основной поток трафика, включая балансировку, фильтрацию и отказоустойчивость?
Инфраструктура: на каком «железе» исполняются приложения? Важно найти и изучить «забытые» машины, а также понять, как они патчатся. Если в вашей команде есть коллеги из инфраструктурной безопасности, то поздравляю, ваша задача стала легче и вы можете обратиться за данными к коллегам.
CI/CD процессы: какие воркеры и джобы существуют? Кто имеет к ним доступ? Какие шаги проходит код от пулл реквеста до продакшна?
Обратите внимание на доступы и секреты
Изучите роли разработчиков. Уберите избыточные доступы и внедрите единые правила.
Проверьте технические учётные записи. Если в компании нет хранилища секретов (например, HashiCorp Vault), сейчас самое время инициировать его внедрение.
Работа с данными
Разберитесь, где хранятся данные компании и кто к ним имеет доступ.
Проверьте используемые базы данных и брокеры (включая NoSQL-продукты) на предмет безопасного хранения чувствительных данных. Пароли, персональные данные, платежная информация и тд должны храниться согласно закону и лучшим практикам на рынке.
Убедитесь, что процесс бэкапа настроен корректно — покрыты все необходимые источники данных, периодичность бекапирования соответствует вашим стандартам. Также советую убедиться, что процесс восстановления из бекапа работает без ошибок и потери данных.
Остальные процессы
Изучите, как запускаются новые продукты, админки и сторонние интеграции.
Поймите зоны ответственности команд, процесс инцидент-менеджмента и роль инфраструктурных команд.
Подумайте об улучшениях бизнес-процессов: прозрачен ли процесс согласований, насколько трудно найти историю принятых ранее решений, есть ли дублирование в процессах?
И, наконец, legacy-компоненты. Скорее всего, вам предстоит иметь дело с устаревшими системами. Соберите список таких компонентов и сразу подумайте, как можно минимизировать их риски — пусть даже с помощью временных решений. Как правило, безопасность таких решений отстает от часто обновляемых компонентов.
По итогам работы вы получите совместный с ИТ-подразделением план доработок, который поможет повысить безопасность и согласованность работы всех команд.
Желаю вам терпения — этот этап сложный, но очень важный для дальнейшей работы.
Этапы 6–7. Проверка защищенности приложений средней критичности, анализ результатов, обучение коллег
Эти этапы во многом повторяют то, что вы уже сделали с критичными приложениями:
Проверка защищенности приложений средней критичности. Проведите ревью безопасности исходя из приоритетов и специфики каждого приложения.
Анализ результатов. Составьте понятный отчёт для коллег: выделите проблемы, объясните их влияние на бизнес и дайте рекомендации по их исправлению.
Обучение коллег. Как и ранее, убедитесь, что результаты понятны и закреплены в работе команд. Постарайтесь вовлечь разработчиков в процесс исправления, чтобы они не просто устранили уязвимости, но и поняли, как избежать подобных ошибок в будущем.
Этапы 6–7 — это естественное продолжение вашей работы. Их цель — охватить больше приложений, закрепить процессы анализа и исправления, а также усилить вовлечённость команд в вопросы безопасности.
Этап 8. Формирование базы знаний и запуск AppSec-процессов
Теперь, когда у вас есть чёткое представление о проблемах компании, собранные данные можно превратить в полезные инструменты. Вот что стоит сделать на этом этапе:
Создайте инструкции и чеклисты. Сформулируйте понятные гайды для типовых задач: как безопасно запускать новый продукт, внедрять интеграции, проверять изменения в коде. Это поможет стандартизировать подходы к безопасности.
Соберите внутреннюю базу знаний. Храните информацию об аудитах, найденных уязвимостях и их исправлениях. Такая база станет отправной точкой для будущих членов вашей команды.
Запустите процессы AppSec. Продумайте и внедрите регулярные security-review, процессы согласования архитектурных изменений и интеграций. Это можно делать через таск-трекеры, чтобы не терять информацию и сделать процесс прозрачным. Сделайте публичные каналы связи, обычно за это отвечают чаты в корпоративном мессенджере или почтовый ящик. Если позволит время, попробуйте настроить важные алерты и дашборды.
Этот этап укрепит основу: сделает процессы безопасными, а знания доступными. Чем понятнее ваши рекомендации, тем легче коллегам учитывать их в работе.
Этап N. Continuous Security
Вот и подошли к концу ваши первые полгода в роли лидера направления AppSec. Что дальше? Работы меньше не станет, но ваш вклад в безопасность компании уже ощутим.
На этом этапе вы переходите к непрерывному улучшению и масштабированию процесса. Вот что может стать вашим следующим фокусом:
Vulnerability management: регулярное управление уязвимостями и их устранение.
SSDLC: интеграция безопасных практик в жизненный цикл разработки программного обеспечения.
Пентесты и внешние аудиты: проверка безопасности с привлечением сторонних специалистов.
Shift left security: внедрение безопасности на ранних этапах разработки.
Киберучения: обучение команды действиям в случае кибератак.
Bug bounty: программы поощрения за нахождение уязвимостей.
Работа с security-чемпионами и повышение осведомленности об AppSec-процессах в компании: привлечение команд к решению вопросов безопасности.
Харденинг: укрепление защиты процессов и систем.
Алертинг: в связке с коллегами из SOC выстройте мониторинг событий и правила для алертов.
Моделирование угроз и рисков: создание карты MITRE ATT&CK, перечня недопустимых событий и других инструментов.
Погружение в трудные и узкоспециализированные компоненты компании: в ИБ дьявол кроется в деталях
Путь безопасника тернист и долог. Непрерывная безопасность — это путь, в котором всегда найдётся что улучшить и оптимизировать. Удачи!
Эпилог
Может возникнуть закономерный вопрос: почему статья посвящена работе первого AppSec-инженера, если в классическом понимании AppSec строится вокруг SSDLC, а его здесь нет? Или кто-то из экспертов заметит, что перечень задач больше напоминает обязанности смежной должности.
И это нормально. В каждой компании задачи AppSec могут и должны адаптироваться под её специфику, оргструктуру, бизнес-модель и существующий ландшафт. Главное, чтобы ваши предложения совпадали с ожиданиями руководства. Именно поэтому на старте важно обсудить и зафиксировать, что вы делаете, зачем и в каком формате.
Почему SSDLC не попал в план на первые полгода? Всё просто: одному человеку в столь сжатые сроки не справиться со всем сразу. Да, можно запустить разовое сканирование репозиториев, разобрать отчёты, но полноценная работа с разработчиками, поиск безопасных решений и контроль их внедрения займут значительно больше времени и ресурсов. SSDLC — это масштабное направление, к которому стоит подходить отдельно, причём в идеале с усилением команды.
Уверен, среди читателей найдутся эксперты, готовые поставить под сомнение предлагаемый подход. Это хорошо, ведь моя цель — поделиться личным опытом, который был полезен в реальной жизни. Если у вас есть идеи, дополнения или критика, буду рад обсуждению в комментариях.
P.S. Кстати, прошлой весной я присоединился к команде AppSec в Циан. Здесь базовые процессы уже выстроены. Фокус внимания направлен на улучшение процессов, сохраняя удобство для команд, баланс и высокий уровень безопасности. Наравне с техническими изменениями, мы работаем над культурой безопасности в командах. Внедряем практики security-чемпионов и обучения разработчиков. В будущем поделимся с вами самыми интересными из них в блоге Циан.
