Возможен ли в наше время, когда уровень автоматизации банковской деятельности становится все более высоким, а злоумышленники и хакеры все более изощренными в своих атаках, следующий подход: сначала вывод на рынок нового банковского продукта, а уже потом принятие мер по его информационной защите? На какой стадии разработки и запуска нового программного обеспечения должны включаться в процесс банковские безопасники? На эти и другие вопросы ответил в интервью NBJ начальник управления экспертизы кибербезопасности Сбербанка России Сергей КРАЙНОВ.

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

С. КРАЙНОВ: На мой взгляд, термин «безопасность программного обеспечения» уже несет в себе уязвимость, ведь при такой постановке вопроса мы смотрим только на программное обеспечение. В Сбербанке мы говорим о безопасности продукта в целом, то есть и о безопасном бизнес-процессе, и о его безопасной реализации в коде ПО, и о его безопасном окружении. Только комплексный подход к оценке защищенности продукта может дать желаемый уровень уверенности в его безопасности. Именно поэтому оценка безопасности продукта в Сбербанке начинается с самой ранней стадии его создания – с этапа концепции или бизнес-идеи «на салфетке». Уже на нем мы анализируем потенциальные риски бизнес-процесса и предлагаем возможные способы митигации, в том числе изменения в бизнес-процессе, а не только внедрение средств защиты. И эта работа продолжается на всех стадиях проектирования, вплоть до программной реализации и приемки работ.

На разных стадиях производственного процесса мы используем различные способы проверки и контроля: статический анализ кода (Static Application Security Testing, SAST), динамический анализ кода и дистрибутива (Dynamic Application Security Testing, DAST), приемка бизнес-функционала перед выводом в эксплуатацию (Business Application Security Testing, BAST), тест на проникновение работающих систем. Если SAST, DAST и пентест известны и понятны, то на термине BAST стоит остановиться подробнее. Он не является общепринятым в индустрии, более того, мы сами его ввели недавно для внутреннего использования и единообразия терминологии. BAST – это приемка бизнес-функционала экспертом кибербезопасности перед вводом его в эксплуатацию. В ходе BAST эксперт кибербезопасности проверяет возможность проведения несанкционированных или нештатных действий в рамках полномочий пользователя в реализованном бизнес-процессе. Здесь делается акцент на логические ошибки в процессе или некорректность его реализации. Культура совместной приемки бизнес-функционала со стороны заказчика и безопасности появилась в Сбербанке практически на заре автоматизации, и сейчас этот этап обязателен для любой доработки.

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

NBJ: Какие можно выделить наиболее острые и актуальные проблемы защищенности и безопасности программных продуктов в настоящее время?

С. КРАЙНОВ: Любой продукт и любое программное обеспечение могут иметь уязвимости, и это нужно принять. У бизнеса есть потребность в снижении time-to-market (время вывода на рынок – Прим. ред.), и скорость вывода доработок в эксплуатацию постоянно увеличивается. Поэтому будет расти и количество уязвимостей из-за логических ошибок при проектировании бизнес-процесса и его реализации в коде. Соответственно, самой острой проблемой становится скорость и полнота проверок кибербезопасности до вывода продукта. Для ее решения требуется целый ряд условий: высокие компетенции специалистов кибербезопасности и их раннее вовлечение, реальная заинтересованность заказчика и разработчиков в безопасности продукта, обучение разработчиков правилам безопасной разработки, эффективные средства автоматизации проверок, комплексность проверок и контроля.

NBJ: Что является источниками проблем информационной безопасности программных продуктов, по вашему мнению?

С. КРАЙНОВ: Их множество: ошибки при проектировании, неправильная архитектура, низкая квалификация разработчиков, ошибки и намеренные закладки в коде, позднее вовлечение специалистов по кибербезопасности, недостаточное тестирование… Этот список можно продолжать практически до бесконечности. Важно помнить, что уровень защищенности системы в целом соответствует уровню защищенности ее наиболее уязвимой части. И, например, аналитик и архитектор 
не сделают ПО безопасным, если код будет писать низкоквалифицированный разработчик без контроля со стороны кибербезопасности.

NBJ: Распространенный способ анализа приложения – исследование его исходного кода. Что происходит на этом этапе исследования защищенности?

С. КРАЙНОВ: Исследование исходного кода на наличие уязвимостей безопасности, или Static Application Security Testing (SAST), осуществляется без компиляции и исполнения кода и обычно включает несколько типов проверок, в том числе поиск известных или подозрительных сигнатур в коде, анализ возможных моделей исполнения кода, построение потенциальных векторов атак.

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

Любой продукт класса SAST при первоначальной инсталляции и «первом проходе» по исходному коду порождает очень большое количество ложных срабатываний: в нашей практике до 95%, включая уязвимости, неприменимые к данному типу системы, и другие ошибочные срабатывания. Все эти инциденты нужно проанализировать и соответствующим образом промаркировать в системе, чтобы они не выявлялись при следующем сканировании. Максимально эффективно эту задачу может выполнить только сам разработчик. И для первого запуска на достаточно больших системах это может стать проблемой, ведь тысячи срабатываний ложатся мертвым грузом на плечи разработчика и практически никогда не разбираются.

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

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

С. КРАЙНОВ: Динамический анализ максимально эффективен в умелых руках, но при этом действительно плохо автоматизируется. Мы сейчас работаем над этой проблемой, так как реализовать потребность в выводе релиза программного обеспечения по требованию в любой момент времени невозможно без средств автоматизации. Скорее всего, мы придем к комплексному решению, которое будет включать как функционал сканеров, так и анализ всего трафика приложения в процессе исполнения. Сейчас наша команда специалистов по анализу безопасности приложений пилотирует такое решение.

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

NBJ: С вашей точки зрения, достаточное ли внимание в настоящее время банки уделяют проблемам обеспечения программной безопасности?

С. КРАЙНОВ: Банки вынуждены уделять внимание проблемам безопасности ПО, так как они являются основной целью для практически любых злоумышленников. Вопрос в том, что считать достаточным вниманием. Кого-то устраивает пентест два раза в год для соответствия стандарту PCI DSS, а другой предпочитает построить эшелонированную систему проверок и контролей кибербезопасности внутри производственного процесса. Все должны определять оценка риска и адекватность защитных мер имеющимся угрозам.