Рустэм Хайретдинов, CEO компании Appercut Security: «Заботиться о безопасности приложений надо, начиная с исходного кода»

–  Насколько остро сегодня стоит проблема уязвимостей в заказных приложениях по сравнению с приложениями тиражируемыми?

Я абсолютно уверен, что сегодня эта проблема – одна из острейших в сфере ИБ. И начну я, пожалуй, с тиражируемых приложений, ведь они зачастую воспринимаются как эталон правильного подхода к разработке, обеспечивающего высокую безопасность ПО и технологичность внедрения. Действительно, здесь есть объективные преимущества. Рассчитывая на большой рынок, разработчики применяют платформенный подход, тщательно проектируют и кодируют программы, используют разнообразные инструменты  для выявления уязвимостей и контроля качества. Много сил уходит и на тестирование. И вот, наконец, это ПО появляется на конкретном предприятии. И тут же становится понятно, что никакой тиражируемый софт не может использоваться в корпоративной среде без глубоких настроек, доработок, изменений… Собственно, многие годы сама парадигма потребления ИТ в крупном бизнесе предполагала серьезную «кастомизацию», приспосабливающую универсальный программный продукт к нуждам конкретной компании и особенностям ее информационной среды.

Естественно, что разработчики изначально закладывают в свои продукты полный набор инструментов «кастомизации», включая интерфейсы прикладного программирования (API), информацию о внутренней структуре баз данных и даже целые языки программирования, специфические для каждой платформы. Эти средства открывают практически неограниченные возможности доступа к данным и модификации алгоритмов работы основного приложения.

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

Получается, что грань между тиражируемым и заказным ПО стирается: первое, по сути, приобретает свойства второго. Иными словами, в чистом виде тиражируемое ПО в корпоративной среде не встречается.

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

- Насколько разработчики и заказчики заказных приложений обеспокоены безопасностью полученного продукта?

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

- И какова же эта позиция?

Насколько мне известно, масштабных исследований на эту тему пока не проводилось, поэтому наиболее точными, пожалуй, остаются результаты опроса 1200 предприятий, работающих в России, который мы провели еще в 2010 году. Выяснилось, что 88 % из них осознают риски, связанные с использованием заказного ПО. Казалось бы, это хорошо. Но нет, подавляющее большинство компаний эти риски принимает, но совершенно не собирается с ними бороться. Такие предприятия заявляют, что эта проблема сейчас неразрешима, хотя, полагаю, сами не очень-то в это верят. И за прошедшие годы – а я постоянно встречаюсь с руководителями компаний разного масштаба – это состояние кардинально не изменилось. А вот проблема стала еще острее: получив веб-интерфейс, заказные приложение стали гораздо более открыты для внешнего мира. И теперь уязвимостями пользуются уже не только инсайдеры, но и хорошо организованные киберпреступные сообщества. Все чаще возникают резонансные дела, которые подталкивают рынок к тому, чтобы с проблемой бороться. Словом, времени на ожидание больше нет.

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

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

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

 - Так стоит ли специально заниматься безопасностью внутренних приложений?

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

- А как сканнер Appercut может изменить работу с заказными и внутренними приложениями?

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

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

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

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

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

Наконец, сканер Appercut никак не влияет на процесс разработки, не вносит изменений в исходный код и не требует знания архитектуры системы и того, какие именно применялись методики и инструментальные средства.

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

- На какие компании ориентировано ваше решение?

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

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

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

Наконец, третий сценарий предназначен для заказчиков, которые не хотят, чтобы исходный код покидал периметр организации. Для них наш сканер реализован в виде программно-аппаратного комплекса, который работает без обращений к интернет-сервисам и ко внешним источникам данных.

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

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