Анастасия Худоярова, Awillix: Специалист по безопасной разработке должен уметь находить баланс между защищенностью и эффективностью

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

Ведущий специалист по безопасной разработке в Awillix Анастасия Худоярова рассказала порталу CyberMedia о сложностях, которые возникают на пути интеграции SSDLC-подхода в работу над программными продуктами.

Cyber Media: ИТ-рынок растет огромными темпами. Вместе с этим формируются и ценовые сегменты. С позиции безопасной разработки, есть ли разница между молодой и опытной, титулованной компанией разработчиков?

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

Разница наверняка есть: опытные разработчики с большей вероятностью предусмотрят защиту инфраструктуры от простых DDoS-атак или автоподбора паролей. Но, до тех пор пока в разработке не участвует ИБ-специалист, ее уровень безопасности – околонулевой.

Это обусловлено двумя факторами:

1. Разница в подходах. Разработчик думает о том, как сделать систему эффективной. Безопасник – о том, как ее можно поэксплуатировать. Взломать, нарушить работоспособность или извлечь данные.
2. Разница в задачах. Задача разработчика – это в рамках отведенных сроков создать программный продукт или его часть, отвечающую задачам заказчика. Задача ИБ-специалиста – предусмотреть как можно больше возможных сценариев атаки, приоритезировать их и предложить модель защиты, процедурные, а также технические решения.

В большей степени важна квалификация ИБ-специалистов, участвующих в разработке.

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

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

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

Тот тренд, который мы пытаемся побороть – это бездействие. В 4 случаях из 10 заказчик успокаивается после получения отчета. Критических проблем выявлено не было, а с остальными можно жить дальше. В таком случае мы прикладываем все усилия, чтобы донести простую мысль: чем дольше проблема живет в архитектуре, тем выше вероятность, что она будет использована для атаки на компанию.

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

Cyber Media: Клиенты, которые приходят к вам за экспертизой впервые: имеются ли у них какие-либо мифы или стереотипы о работе специалиста по безопасности разработки?

Анастасия Худоярова: Процесс безопасной разработки – относительно новая услуга на российском рынке. Зачастую, заказчики не до конца понимают что это такое. Они уже знакомы с каким-то набором различных средств защиты, понимают для чего они нужны, но SSDLC для них – темный лес.

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

Искаженное восприятие ведет к пренебрежительному отношению к безопасности. Действительно, на первый взгляд гораздо проще интегрировать в работу сканер уязвимостей и отладить его, чем внедрить в работу компании культуру безопасной разработки. Чтобы перебороть это убеждение, нужно проводить разъяснительную работу с заказчиками.

Можно привести следующий пример. Оперативные методы защиты и «закрытия» уязвимостей – это строительство каменного забора вокруг старого дома с прогнившими досками. Это повышает защищенность конструкции. SSDLC и DevSecOps – это монтажные работы по замене износившихся досок в доме на новые. Таким образом дом становится не только защищеннее, но и надежнее. Без использования сторонних средств.

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

Cyber Media: SSDLC-подход, если мы не берем технические аспекты – это SDLC «с оглядкой» на безопасность. Может возникнуть ощущение, что знание теории позволит команде разработчиков создать безопасный продукт без специалиста по ИБ.

Анастасия Худоярова: Здесь вновь уместно упомянуть о том, что отличает безопасника от разработчика. Программист думает о том, как сделать так, чтобы все работало. Это правильно, эффективно и быстро.

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

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

Второй аспект заключается в том, что безопасность – это комплексный процесс. Даже самая безопасная разработка не спасет компанию от взлома, если ее сотрудники используют свои ФИО в качестве паролей от внутренних сервисов.

Безопасная разработка – это залог обеспечения безопасности «по умолчанию». SSDLC позволяет минимизировать количество изъянов, которые будут требовать дополнительных мер защиты в дальнейшем. Но это не отменяет необходимость создания и соблюдения политик безопасности в целом в масштабах компании, использования ИБ-инструментов и сканеров.

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

Анастасия Худоярова: Главная сложность – соблюсти баланс интересов между эффективностью и защищенностью. С позиции бизнеса приоритет всегда будет у первого фактора.

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

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

Немного другая ситуация при работе с госсектором. Ввиду специфики, там нередко идут на урезание функционала, снижение эффективности и, тем более, удобства, в пользу безопасности и защищенности.

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

Cyber Media: Можно ли выделить систематические ошибки и уязвимости, избежать которых можно с помощью методов безопасной разработки?

Анастасия Худоярова: Немало слабых мест годами существуют в инфраструктуре компании. Их могло бы вовсе не быть, если бы разработка этих программных продуктов велась на базе SSDLC-подхода.

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

Другая проблема, которую SSDLC решает еще в зародыше – это контроль выполнения санитизации входящих данных. Многие компании никак не обрабатывают приходящие от клиентов запросы, либо делают это номинально. А между тем, они могут быть заражены: содержать фишинговые ссылки и вредоносные скрипты.

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