Анализ кода и технологии защиты

Рустэм Хайретдинов
CEO компании Appercut Security

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

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

Методы обеспечения защищенности заказного приложения не отличаются от таких же мер для тиражируемого программного обеспечения, однако способы их применения разнятся. Рассмотрим их подробнее.

Статический анализ исходного кода

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

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

Динамический анализ приложения

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

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

Тестирование на проникновение

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

Экспертный анализ приложения

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

Что выбрать и выбирать ли вообще?

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

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

С чего начать?

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

Содержать у себя квалифицированную экспертизу скорее всего не получится. Дело даже не в заоблачной стоимости таких специалистов, а в возможности загрузить их интересными задачами. Эксперты такого уровня не будут заниматься рутиной ни за какие деньги. Поэтому наиболее простые способы начать контролировать защищенность своего приложения – это автоматизированные способы анализа с помощью быстрых инструментов. Автоматизации хорошо поддается статический анализ и тестирование на проникновение некоторыми, наиболее распространенными моделями атак. Начав с автоматизированного анализа, вы сможете получить информацию о наиболее распространенных уязви-мостях как общих для любых приложений, так и специфических конкретно для этого приложения (так называемые application specific vulnerabilities). Конечно, специфические решения вы не сможете получить "из коробки", но интеграторы смогут обучить решение на такие проверки.

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

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