SOT

Security Orchestration Tools

Напишите нам на sales@securityvision.ru или закажите демонстрацию

SSDL: Dev vs Sec

SSDL: Dev vs Sec
  |  Слушать на Google Podcasts  |   Слушать на Mave  |   Слушать на Яндекс Музыке  |  


Ева Беляева, Security Vision


Когда-то народы разработчиков и безопасников жили в мире, но все изменилось, когда регулятор решил прорегулировать и их процессы тоже.

1. Общий язык

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


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


Существуют различные способы мотивировать и разработчика, и безопасника. У них есть что-то общее – как, например, мотивация обрести долгожданный сертификат; но такой мотивацией занимается как правило компания. Что же до мотивации более мягкой – зачастую таким двигателем прогресса становится очень замотивированный человек «со взором горящим», готовый крушить и ломать код перед собой (иногда это расстраивает тимлидов), но в любом случае, работа эта довольно творческая.


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


В частности, некоторые проблемы начинаются с подозрений: не внедрит ли разработчик вредоносный коммит, насколько хорошо лиды разбираются в безопасности коммитов и мерджей, как много библиотек используется при разработке open source? Одним прекрасным днем может оказаться, что привычные инструменты скомпрометированы, что явно подсвечивает необходимость анализа кода.

 

2. POC и как его готовить

Вторым камнем преткновения является предоставление доказательств как последнего оплота убеждения несогласного коллеги.


Зачастую недостаточно аргумента «вот есть цель, на пути у цели баг – баг нужно убрать». Такая логическая последовательность, хоть и достоверна, может таить в себе множество нюансов. У команды разработки на все эти случаи припасено внушительное множество контраргументов: и никогда звезды не сойдутся в нужной последовательности так, чтобы атака произошла; и никому не придет в голову таким заниматься; и даже физически злоумышленник никогда-никогда, правда-правда не доберется до исходного кода/возможности подменить файл/подставить нужное. И вообще, это легаси, а что мы сделаем?


Именно поэтому за каждым багом должен прочно обосноваться POC, если этого недостаточно – POC с примерами воспроизведения, а если и этого недостаточно – POC, полученный в ходе пентеста, повлекшего за собой неработоспособность ПО. Но если и этот аргумент не убедит разработчика, в ход идет последнее средство – искусство перевода с русского на русский – от безопасности к разработке. Если повезет, этим таинственным кунг-фу будет заниматься специально обученный человек (об этом позже), но будем честны: очень часто – не везет. Без этой магии никогда, увы, не решить проблему.


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


3. Анализ кода

Раз уж мы хоть и косвенно затронули зоны ответственности (и компетенции), можно поговорить о самом наболевшем: кто же все-таки должен встраивать процесс анализа кода в процесс разработки продукта? Кто будет отвечать непосредственно за реализацию? Статический анализ хорош тем, что может существовать обособленно, выдавая множество достоверных и не очень замечаний вкупе со статистикой покрытия кодовой базы. Динамический же анализ не так прост – для таких проверок требуется оставлять в самом коде «врезки», а также возможность выполнить сборку продукта именно с целю тестирования – это может быть патч, условия запуска, какой-либо другой вариант, удобный безопаснику, но практически никогда не устраивающий разработку. Почему так?


Проблем, косвенно или напрямую относящихся к этой (без иронии) непростой задаче, может быть много. Высокая загрузка или недостаток компетенций – самые распространенные из них. Однако, стоит заметить, что множество аргументов, сводящихся к «а давайте вы как-нибудь сами», рано или поздно все же приведут к тому пути, при котором методом многих или не очень проб и ошибок разработчик поймет: этот подход полезен (и удобен), в первую очередь, ему самому.


4. А что сплачивает?

Очевидно, что-то общее. Общий друг или общий враг. Что по части врага – нередки случаи выстаивания чудесных и долговечных дружеских отношений с коллегами после совместных чтений требований от регулятора. Иногда получается устроить и целый стендап, и ролевые игры – когда одна команда засчитывает требования, а вторая – пытается угадать, какой во всем этом был смысл.


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


Увидеть первые результаты работы в целом бесценно – на словах не всегда очевидно, к чему может привести новый формат. И даже более того, в какой-то момент приходит возможность влиять на эти самые нормативные документы и на ключевые значения и настройки анализа кода – кто же упустит шанс повлиять на ФСТЭК и приблизить регулятора к реальности.

 


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


В процессе взаимодействия стираются многие острые углы, потому и говорят, что для успеха application security становится полноценной частью команды, постоянно на связи и по уши в коде, готовый рваться через тернии к заветному Secure by design.


Во-вторых, если спуститься с небес на землю и представить более реальную картину, грамотно наладить взаимодействие поможет один чудесный покемон специалист – security champion. Но об этом как-нибудь в другой раз.

Практика ИБ ФСТЭК России (приказы, БДУ) Подкасты ИБ

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

Между печеньем и морковкой: удержание команды в условиях неопределенности
Между печеньем и морковкой: удержание команды в условиях неопределенности
Что такое Single Sign-On (SSO)
Что такое Single Sign-On (SSO)
EDR для Windows. Основы, архитектура, принципы работы
EDR для Windows. Основы, архитектура, принципы работы
Авторизация
Авторизация
Методы тестирования в ИБ — технологии «черный», «серый», «белый» ящик
Методы тестирования в ИБ — технологии «черный», «серый», «белый» ящик
Что такое брутфорс и как от него защититься?
Что такое брутфорс и как от него защититься?
Как устроены вредоносные программы
Как устроены вредоносные программы
API на передовой: методы противостояния кибератакам
API на передовой: методы противостояния кибератакам
Сценарии нетиповых атак UEBA
Сценарии нетиповых атак UEBA
Темные стороны контейнеров: риски и меры безопасности
Темные стороны контейнеров: риски и меры безопасности
Что такое социальная инженерия и как от нее защититься
Что такое социальная инженерия и как от нее защититься

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

Между печеньем и морковкой: удержание команды в условиях неопределенности
Между печеньем и морковкой: удержание команды в условиях неопределенности
Что такое Single Sign-On (SSO)
Что такое Single Sign-On (SSO)
EDR для Windows. Основы, архитектура, принципы работы
EDR для Windows. Основы, архитектура, принципы работы
Авторизация
Авторизация
Методы тестирования в ИБ — технологии «черный», «серый», «белый» ящик
Методы тестирования в ИБ — технологии «черный», «серый», «белый» ящик
Что такое брутфорс и как от него защититься?
Что такое брутфорс и как от него защититься?
Как устроены вредоносные программы
Как устроены вредоносные программы
API на передовой: методы противостояния кибератакам
API на передовой: методы противостояния кибератакам
Сценарии нетиповых атак UEBA
Сценарии нетиповых атак UEBA
Темные стороны контейнеров: риски и меры безопасности
Темные стороны контейнеров: риски и меры безопасности
Что такое социальная инженерия и как от нее защититься
Что такое социальная инженерия и как от нее защититься