Защита в DevOps

Как сделать продукт безопасным для пользователя? Какими ресурсами этого достичь и можно ли автоматизировать проверку безопасности? На эти и другие вопросы журнала отвечает Николай Турович, начальник Технологического отдела Управления экспертизы кибербезопасности Сбербанка

Меняется ли топ главных проблем безопасности ПО, по вашим наблюдениям? Если да, то как?

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

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

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

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

В испанском банке BBVA разработана технология Security Feedback as a Service, в которой фокус делается на формирование условий и механизмов предоставления обратной связи по безопасности кода и продуктов конкретных команд. Как вы оцениваете перспективы подобного подхода?

Да, нам известна эта технология, но еще до знакомства с ней внедрили ее элементы в собственном процессе статического анализа кода на безопасность (SAST). В конце лета прошлого года мы предоставили командам разработки сервис доступа к результатам SAST. Команды имеют возможность, не дожидаясь результатов прохождения, соответствующего Quality Gate, получить информацию о качестве своего кода с позиции кибербезопасности.

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

С этого года бизнес-партнеры по информационной безопасности предоставляют агрегированную информацию руководителям бизнес-блоков банка.

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

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

Как вы отслеживаете безопасность производственного процесса ПО?

Обеспечение безопасности производственного процесса у нас ничем не отличается от обеспечения безопасности любого другого продукта в Сбербанке – оно строится на основе комплексного подхода. Для этого задействуются существенные усилия и ресурсы.

С начала генерации идей по автоматизации производственного процесса эксперты по кибербезопасности работают совместно с командами, соответственно, в мельчайших деталях представляют процесс, а значит, и его слабые места. Акцент в разработках делается на внедрение эффективных средств автоматизации проверок, таких как DevOps и релизных Quality Gates, поскольку ручные проверки никогда не смогут обеспечить непрерывности и комплексности контроля. Немаловажным фактором стало создание заинтересованности заказчика и разработчиков в безопасности продукта, в том числе им предоставлены средства мониторинга процесса производства продукта и возможность сравнения показателей эффективности с соседними командами. В части «трубы» DevOps был разработан собственный инструмент: DevOps Pipeline Management, который, обеспечивая команде возможность увидеть состояние любого релиза, дистрибутива, этапа DevOps-конвейера, предоставляет аналогичную возможность и специалистам кибербезопасности. А независимость этого инструмента от команд делает контроль объективным.

Deloitte Consulting в своем отчете Tech Trends 2019: Beyond the Digital Frontier определила шесть тенденций развития технологий, одна из которых — усиление модели DevSecOps в противовес модели DevOps. Видите ли вы смысл в противопоставлении этих терминов?

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

При этом сейчас следует скорее переходить к модели BizDevSecOps, так как в текущее время невозможно быть конкурентоспособным на рынке без синергии всех этих направлений. Разработка программных продуктов без постоянно корректирующихся бизнес-потребностей или без реализации требований кибербезопасности приведет к «дефолту» продукта уже в первые два-три месяца эксплуатации. Но и качественный с точки зрения бизнеса и безопасности продукт ничтожен при отсутствии надлежащего сопровождения. Причем под сопровождением я также понимаю и своевременное замыкание обратной связи на разработку. Иначе, без оперативного устранения дефектов, выявляемых в процессе эксплуатации, продукт быстро теряет свои качественные свойства. В целом все это не что иное, как agile-трансформация организации.

Если пытаться заглядывать в будущее, то, по моему мнению, уже в скором времени кросс-функциональные команды, работающие над продуктом, будут на постоянной основе расширены экспертами в области права и риск-менеджмента. И какая приставка, Risk или Jur, в новой аббревиатуре появится первой, зависит только от того, какие проблемы «выстрелят» первыми. Уже сейчас наши команды регулярно привлекают как первых, так и вторых экспертов не только при анализе собственно бизнес-задач, но и при решении задач кибербезопасности и сугубо ИТ-проблем. Security Feedback, о котором мы говорили, — это ни что иное, как один их первых шагов в области риск-ориентированного подхода к обеспечению кибербезопасности продуктов.

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

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

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

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

Сталкиваетесь ли вы с дефицитом квалифицированных специалистов, умеющих работать в культуре DevOps? Если да, как решаете проблему?

Действительно, DevOps – это в первую очередь культура, а уже потом – инструменты и инженерные практики. Как и любую другую культуру, DevOps невозможно навязать – ее можно только прививать.

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

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

Как вы оцениваете свой уровень зрелости в части кибербезопасности ПО?

Мы одна из немногих компаний в нашей стране, которая занимаемся обеспечением кибербезопасности и не только ПО и инфраструктуры, но и в первую очередь – бизнес-процессов. В авиации говорят, что хорошо летать будет только красивый самолет. Так и в нашей сфере – безопасным может быть только тот продукт, качество в который закладывалось с самого начала производства. Это подтверждается и оценками консультантов «большой четверки», позиционирующих Сбербанк в домене «Безопасность разработки» на уровне компаний Fortune 500.       

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