Содержание статьи
Про SDLC, как и про пентесты, не писал разве что ленивый, а так как я не ленивый (врет он. — Прим. совести), то напишу и я. Особенно хочется поговорить про элементы и парадигмы SDLC в рамках гибких методологий разработки, в частности Agile, а также вообще про организацию безопасной разработки в современных софтверных компаниях.
SDLC
SDLC (security development life cycle) — процесс безопасной разработки, штука, которая выглядит полезно и круто. Конечно, кто бы не хотел делать сразу все шикарно и безопасно. К данной категории пациентов относится и корпорация Microsoft, которая и была одним из первопроходцев «внедрения SDLC». Компания устала от того, что, когда заходит речь о безопасности их продуктов, такой диалог заканчивается одинаковым резюме: «решето». И корпорация вложила огромные силы в то, чтобы как-то изменить свои продукты, а для этого менять надо весь процесс. Собственно, таким путем они и пришли к своему классическому SDLC, прочитать про который ты можешь у них на сайте.
Agile
Как многие знают, описанная Microsoft модель была заточена под старомодную, но популярную в то время методологию разработки — Waterflow. Учась в универе, в 2006 году мы все еще проходили данную модель как основную, базовую (хотя у нас были и материалы в курсе про экстремальное программирование, но «Водопад» был основой). Однако в реальности на данный момент мало кто из софтверных компаний ее использует, теперь все любят гибкие методологи семейства Agile. Нет места объяснять, чем там все отличается и как оно все работает, поэтому надеюсь, что читатель знаком со всей этой темой... Но главное, что нам нужно понять, — в чем будет отличие с точки зрения SDLC. Так вот, в «Водопаде» с SDLC наши регламенты, процедуры и прочие работы, связанные с безопасностью, отлично встраиваются в этапы методологии. У нас есть четкое планирование того, что мы хотим сделать и что увидим на выходе, при этом мы говорим в рамках всего разрабатываемого продукта: на этапе архитектуры оцениваем риски, строим модель, планируем защитные механизмы, прорабатываем требования, на этапе разработки используем выбранные фреймворки и подходы безопасного программирования, на выходе тестируем продукт и выпускам. Это если кратко, не внедряясь во все процедуры SDLC. С Agile все несколько иначе, хотя бы потому, что есть приоритеты, циклы разработки с «постоянным выпуском» новых фич, и сегодня мы не очень можем знать, что и как мы будем разрабатывать через месяц (зависит, конечно, от Backlog и пропускной способности команды), и таких вот различий весьма много. В этих условиях довольно сложно взять и прикрепить «безопасность» в виде того SDLC, что описан МС. На самом деле различий гораздо больше, но журнал у нас не резиновый…
Мы (безопасники) привыкли воспринимать безопасность как нечто особое, отдельное от всего, тогда как на самом деле это просто одно из свойств «качества» продукта. По сути, в Agile не надо ничего придумывать и как-то «прилеплять» безопасность или некое SDLC. Достаточно просто расширить понятия качества и тестирования, а также требования к безопасности, добавить в анализ рисков наши риски ИБ. Но именно в этом и есть вся магия и «челлендж» :).
Распределенные команды
Еще проблема — что делать, если у нас много разных команд, да еще и распределенных, которые делают абсолютно разные вещи. Например, у нас в HERE одна команда пишет нативное embended-приложение для автомобиля, другая — мобильное приложение для iPhone, а третья — онлайн-сервис в облаке… Требования, возможности, методологии разработки и прочие практики у всех разные! Не говоря уже о навыках «безопасности». И да, таких команд много, а команда безопасников одна. Тем не менее хотелось бы, чтобы разработка была максимально безопасной, без применения метода «одна команда — один безопасник».
Забить на SDLC?
Как видно, в современных условиях SDLC в том контексте, про который говорит MS, практически нереально применить у себя дома. Поэтому можно прочитать все рекомендации, советы и истории успеха от МS (или других авторов, включая меня) по внедрению SDLC и смело забить на них и не пытаться внедрить «то же самое». Это не будет так работать. Ведь кроме всего прочего, все команды и процессы отличаются в разных компаниях. Что хорошо у одного — плохо и даже вредно у другого! Если тебе действительно нужна безопасная разработка, то придется все делать с нуля — никаких рецептов или алгоритмов: все компании — различные организмы, и процессы у них могут быть разными, даже если на бумаге все одно. Здравый смысл + полноценное использование того, что уже есть, сильно упростят вам жизнь.
(Не)вредные советы
И все же пару-другую мыслей я выскажу. Но это скорее как собственный опыт. Итак, захотев внедрить разработку в вышеописанном «хаосе» и приняв тот факт, что нет никакого универсального пути или алгоритма для решения этой задачи, что мы можем сделать? Все, что у нас есть, — это собственный опыт и знания. И на самом деле это уже немало. Отмечу, что «безопасным» продукт делают не консультанты-безопасники или иные умники вроде меня, а разработчики. Просто многие вещи они (не) делают на автомате, по незнанию неких подводных камней — то есть тупо из-за отсутствия опыта и знаний. Поэтому самое главное — накапливать эти знания в командах. Гибкие методологии для этого еще как годятся, возьмем ту же самую ретроспективу как подобный механизм — и не надо придумывать велосипед. Хотя это все детали. Кроме прочего — секурити-команда в компании может быть отличным тренером (ну и понятно, что можно посылать на внешние конференции, тренинги и прочее). Например, у нас в компании ежегодно проводятся внутренние воркшопы-семинары, где различные команды делятся тем или иным опытом. В том числе и мы, безопасники. Тут же полно места для фантазии: можно сделать мини-HackQuest/CTF в рамках такого внутреннего ивента, с простыми, но эффективными эксплойтами, атаками — поверь, те разработчики, кто поиграет в это, запомнят урок. Но вот не факт, что вспомнят про него во время работы. К сожалению, в Agile эффективность всей методологии зависит от ответственности самой команды, ровно это же относится и к безопасности. Каждая команда сама ответственна за безопасность своего продукта, и это нужно развивать, так как это всего лишь один из критериев качества. Как это приходит: от стейк-холдеров или владельца продукта — неважно. Важно, чтобы это было. Когда владелец продукта заинтересован в этом, сделать это легче, но все же не всегда так. В любом случае наша команда безопасников может и должна генерировать некоторые входные данные — требования безопасности, рекомендации, селфчек-листы, гайды и прочее и прочее. И одно из самых важных — максимум автоматизации! Это все то, на основе чего каждая отдельная команда сможет создавать свои требования и «секурити»-таски (заметь, что секурити у меня не идет историей, это только таски) для конкретного своего проекта, использовать наши тулзы и сервисы (по фаззингу, проверке кода и анализу настроек и среды). Например, задача: пользователь хочет иметь возможность зарегистрироваться на нашем сайте. Проходит первый цикл — мозговой штурм, с анализом рисков и всем прочим + есть наши требования: «Для ситуаций А, Б, … должен быть SSL (ссылка на гайд, что такое правильный ССЛ)», «фильтрация ввода/вывода для пользовательского взаимодействия (ссылки, ну пусть на ОВАСП или материалы про XSS/SQLi и прочие инъекции)» и так далее. В итоге команда сама, без нашего участия, сформирует требования и сделает таски, связанные с ИБ: двухфакторная аутентификация, капча, CSRF, тесты, анализ кода… Но это мечты :). Конечно же, в самом простом случае команда не будет знать, что есть какие-то требования безопасности, селфчек-листы, гайды и какие-то риски. Однако если у нас будут механизмы контроля требований, то можно предъявить претензии командам, в итоге уже на следующей итерации эти знания и опыт останутся с ребятами 🙂 Например, если Agile-разработка интегрирована с гейтами, то именно тут самое место для «экзамена» и валидации. Кроме того, всегда есть финальное ревью, на котором наша команда проверяет документацию, секурити-тесты, результат тулов, типа анализаторов кода и фаззеров/сканеров. Короче, можно придумать множество механизмов влияния. Таким образом, секурити-команда становится неким организующе-проверяющим механизмом, а также командой сопровождения других команд. Мы разрабатываем все эти требования, гайды и тулзы, даем добрые советы и проводим тренинги. И сюда можно накрошить что угодно — все это вопрос архитектурно-организационный, и тут большое поле для творчества. Кроме того, наша RedTeam команда, как независимое лицо (непосредственно не разрабатывавшая код), для выбранных приоритезированных проектов может выполнять пентест или ручной анализ кода 😉 Важно, что мы работаем не с конечным продуктом, проверяя ТОЛЬКО его, мы работаем с командой, проверяя, как у них организована была разработка, какие тесты они делали, как задокументировали вопросы безопасности и как организована работа с ключевыми элементами безопасности, какие риски они увидели. На разных гейтах мы бы прощупали разные слабые места и организовали бы feedback команде.
Еще немного буковок
Можно долго говорить, как можно что-то сделать, или придумывать разные забавные идеи и ходы, это весело и может быть полезно. Но главное, что я хотел сказать, — что нет общего подхода или плана. Есть набор разношерстных практик и процедур, будь то анализ рисков или фаззинг, — и все это давно известно, но вот собрать все это так, чтобы оно работало как машина, — это главная проблема и искусство. Так что можно забить на термин SDLC как на руководство или план — так оно вряд ли заработает, только отдельные моменты. Второе: безопасность продукта — это вопрос разработчиков, их знаний и контроля, а не отдельных команд и людей, поэтому перенос ответственности и проверок на сторону разработчиков может помочь. Третье: безопасность — это критерий качества продукта. И все это взаимосвязано. Безопасной вам разработки!
