Статистика атак на информационные системы в последние годы однозначно указывает на тенденцию увеличения количества взломов на прикладном уровне. Конечно, средства защиты активно эволюционируют, помогая предотвращать такие атаки за счет самообучения и анализа аномалий, но чем дальше, тем более понятно, что только внешними средствами защиты проблему не решить – необходимо менять подход разработчиков прикладных систем к обеспечению информационной безопасности уже на этапе разработки.
Системы контроля защищенности приложений зародились практически одновременно с самим программированием и широко известны. Методики исследований не являются секретом, а набор инструментов – от простых бесплатных до дорогих профессиональных – можно найти на любой вкус и бюджет.
Методики и инструменты
Любой мало-мальски знакомый с исследованием защищенности приложений вспомнит основные инструменты таких проверок – статический анализ, динамический анализ, автоматизированные и ручные тесты на проникновение, экспертный анализ. Последний часто называют ручным анализом, но этот прижившийся термин не точно отражает суть исследования: во-первых, эксперт изучает код не руками, а глазами, во-вторых, если этот термин используется как антоним «автоматизированного анализа», то следует знать, что эксперт при анализе запускает множество различных сканеров.
Рассмотрим каждый из методов более подробно и оценим их плюсы и минусы.
Статический анализ
Статический анализ имеет дело с исходным кодом приложения, исследуя программные конструкции, исполнение которых может быть небезопасным. Обычно используется поиск образцов (называемых также сигнатурами, паттернами, шаблонами или даже проверками) небезопасных конструкций из базы знаний в исходном коде приложения. Поисковый механизм сканера может искать лексические конструкции (регулярные выражения), семантические конструкции языка программирования либо образцы графов потоков данных. Иногда сравнивают качество статических сканеров по количеству сигнатур в базе («больше сигнатур – лучше сканер»), но это не совсем корректно: ключевое качество статического анализа кода – алгоритмы сравнения программных структур и образцов из базы знаний. Одному сканеру на каждый поисковый запрос нужен свой шаблон, а другой по одной сигнатуре умеет строить много поисковых запросов.
Поскольку исходный код не сообщает исследователям контекста исполнение приложения – настройки, права учетной записи, из-под которой запускается приложение, то не всегда совпадение программной конструкции с образцом опасного программирования указывает на наличие уязвимости. Возможно, что в конкретном контексте найденную конструкцию эксплуатировать нельзя – настройки приложения, ограниченные права учетной записи или внешние средства безопасности не позволят это сделать. Потому при исследовании защищенности приложения методами статического анализа совпадения программных конструкций с образцами опасного программирования часто называют «гипотезами» или «некорректным кодом», а не уязвимостями. Заметим, что это не означает, что некорректные программные конструкции не надо исправлять – настройки и права учетной записи конкретного приложения со временем могут измениться. Кроме того, этот код может быть использован программистами в другом приложении без повторной проверки – они могут посчитать, что данный код уже проверялся и признан безопасным.
Статический анализ – единственный из всех методов, который можно использовать на этапе кодирования – для раннего обнаружения проблем, когда их максимально легко исправить. Для анализа исходного кода не требуется законченный код, за исключением технологий анализа потоков данных. Лексические и семантические методы могут указывать на опасность использования конкретных программных конструкций буквально в момент их сохранения в программном проекте. Однако для этого необходима определенная зрелость процессов разработки, и в России подобная практика используется пока достаточно редко.
Справедливости ради стоит сказать, что статическим анализом можно исследовать не только исходный, но и исполняемый код – этот метод часто применяют разработчики антивирусов для детектирования вредоносного кода, внедренного в обычные приложения. Однако в процессе безопасной разработки такие методы практически не используются.
При сборке также необходимо удостовериться, что приложение собирается именно из того кода, который был исследован и признан безопасным.
Динамический анализ
Динамический анализ применяется на этапе полной готовности приложения и требует запуска приложения в той среде, в которой планируется его эксплуатировать, и с теми же настройками.
При исследовании приложений на недекларированные возможности (закладки) иногда используется специальный вид динамического анализа: в исследуемый код внедряют маркеры, показывающие, что код применялся в процессе исполнения программы. Если после прогона приложения во всех описанных в документации режимах некоторые маркеры оказались неактивированными, вполне возможно, что не задействованный во время штатного исполнения фрагмент кода реализует функционал, о котором программисты не сочли нужным сообщить заказчику.
Автоматизированный и ручной тесты на проникновение используются уже на этапе тестирования, при полной готовности приложения. Программа или эксперт (а чаще оба) пытаются использовать известные им атаки и уязвимости для того, чтобы нарушить безопасность данных и процессов, реализованных в приложении. При этом предполагается, что тестеры не понимают архитектуры приложения и атакуют его, как черный ящик. Динамический анализ часто называют blackbox-анализом в противовес whitebox-анализу (по аналогии со статическим анализом). Иногда полезно интегрировать статический и динамический анализы – гипотезы об уязвимостях, найденные при статическом анализе, передаются на проверку системе автоматизированного пен-теста. Если не удалось черным ящиком подтвердить гипотезу о некорректном коде, полученную белым ящиком, то критичность такой уязвимости в отчете существенно понижается: для конкретного приложения в данных настройках она не опасна, угрозу представляет лишь смена настроек или использование этого кода в другом приложении или с другими настройками.
Экспертный анализ
Экспертный анализ сочетает в себе все известные технологии, используемые квалифицированными экспертами, которые проверяют все гипотезы статического анализа, пересобирают код, пишут работающие эксплойты и журналируют поведение приложения в различных режимах эксплуатации. Поскольку все автоматические инструменты ищут только те некорректности кода и модели атак на них, которые в них заложены, то они не способны найти новые, ранее неизвестные уязвимости. Кроме того, некоторые уязвимости являются таковыми исключительно в контексте исполнения программ и с точки зрения автоматизированных средств анализа к уязвимостям не относятся. Например, выполнение перевода денег без авторизации в системе дистанционного банковского обслуживания является уязвимостью, но для автоматизированных средств анализа кода такая конструкция вполне корректна. Поэтому лишь квалифицированный эксперт-исследователь, понимающий контекст выполнения программы и имеющий подробное описание ее функционала, способен найти новый тип уязвимости или специфическую для приложения уязвимость и затем уже добавить его в автоматизированные средства анализа защищенности приложения.
Процесс, а не проект
Требования безопасной разработки включают в себя организацию с помощью различных инструментов процесса контроля над наличием уязвимостей на всех этапах создания кода – от планирования архитектуры до кодирования, тестирования и приемки. Организация такого процесса подразумевает не только появление инструментов контроля, но и изменение самих процессов разработки, возникновение дополнительных точек контроля и возможностей возвращать код на доработку из любой такой точки. Без этого использование инструментов будет неэффективным.
Отдельно стоит сказать о результате работы любого инструмента анализа защищенности приложений. Это отчет, указывающий на наличие уязвимости, описывающий место нахождения проблемы (при статическом анализе можно указать даже файл и строку начала программной конструкции), возможность ее эксплуатации (описание и пример, в некоторых инструментах – готовый эксплойт) и рекомендации по исправлению такой конструкции. Таким образом, все инструменты исследования приложения являются пассивными, перекладывающими ответственность за собственно защищенность приложения на того, кто этим отчетом пользуется. Если в компании не организован процесс, обязывающий разработчиков исправлять уязвимости по мере их обнаружения, то исправления могут не происходить годами.
Практика применения
Исследования говорят, что один доллар, вложенный в обеспечение защищенности на этапе разработки, экономит до 30 долл. на этапе эксплуатации. Почему же столь впечатляющая эффективность не вдохновляет разработчиков немедленно приступить к внедрению процессов безопасной разработки? Специалисты по анализу защищенности кода работают в специальных лабораториях и не спешат переходить к производителям программного обеспечения. Что же мешает компаниям организовать у себя эффективный процесс безопасного программирования?
Очевидно, что безопасный процесс разработки дороже – требуются дополнительные вложения в программное обеспечение, обучение и экспертизу. Какими методиками рассчитывать экономический эффект? Это зависит от типа разработки: либо это продукт для продажи большому количеству клиентов, либо заказное решение для одного заказчика, либо разработка внутренняя, собственными силами автоматизирующая конкретный процесс внутри компании.
Тиражная разработка
Первыми процессы безопасного программирования стали внедрять производители тиражного программного обеспечения, т. е. те компании, для которых производство ПО – основной бизнес. Чем крупнее компания и чем больше у нее клиентов, тем выше риски того, что от уязвимости пострадают ее клиенты и повысится нагрузка на службы поддержки. Для публичных компаний вполне возможно и падение курса акций. Поэтому такие компании, как Microsoft и Cisco не просто внедряют процессы, а всячески рекламируют и пропагандируют их применение. Технологии безопасной разработки также активно внедряют компании, разрабатывающие программное обеспечение не на продажу, а оказывающие с помощью своих разработок сервисы клиентам: Google, Yandex, Yahoo, Salesforce.com и т. п.
Менее крупные компании – производители программного обеспечения, в том числе российские, тоже начинают внедрять элементы процесса безопасной разработки, но пока находятся в самом начале пути. Статистика не подтверждает эффективность таких методов: исследователи постоянно находят уязвимости в готовых продуктах Cisco и Microsoft. Значит, темпы внедрения подобных процессов не будут высокими.
Заказная разработка
Следующие кандидаты на внедрение практик безопасной разработки – контрактные разработчики заказных систем, так называемые аутсорсеры. Разработка для одного заказчика значительно упрощает процессы разработки, в том числе контроль версий: когда заказчик один, то вместо выпуска патча зачастую правится код. В этом бизнесе наличие процесса безопасной разработки является скорее конкурентным преимуществом при демонстрации возможностей клиенту. Поэтому такие процессы внедряются до уровня, достаточного для демонстрации потенциальному клиенту, и используются формально.
В компаниях-аутсорсерах, работающих на западные рынки, где конкуренция высока и аргументом для размещения заказа являются не только цена, но и сроки внедрения, безопасная разработка имеет важное следствие. Начиная тестировать код на ранних этапах, компании уже к моменту тестовой сборки выпускают продукт без критичных уязвимостей в отличие от конкурентов, начинающих заниматься безопасностью только после первой сборки.
Внутренняя разработка
При собственной внутренней разработке мотивация на безопасную разработку низкая – все-таки это не основной бизнес компаний, зарабатывающих деньги добычей нефти, финансовыми операциями, производством электроэнергии и другими, далекими от информационных технологий способами. Поэтому на разработке сильно экономят, а если и вкладываются в тестирование приложений, то прежде всего в функциональное и нагрузочное.
Аутсорсинг услуг по исследованию защищенности приложений
Аутсорсинг услуг по исследованию защищенности приложений – неплохой вариант для компаний избежать необходимости держать у себя экспертизу и инструменты, однако он тоже не всегда приемлем. Разработка сегодня настолько быстрый процесс, что исследовательские лаборатории за ним просто не успевают. Бизнес-приложения меняются еженедельно или даже ежедневно, а срок исследования приложения в лаборатории – от одного месяца. Таким образом, отчеты лаборатории будут описывать уже неактуальные версии приложений.
Заключение
Описанные проблемы и пути их решения понятны, вопрос лишь во времени достижения зрелости процессов разработки и в последовательной позиции регуляторов. Например, инициатива Банка России по обеспечению безопасности на всех этапах жизненного цикла финансовых приложений пока не является обязательной, а значит, при всех полезных методиках пользы не приносит, поскольку не создает мотивации для применения. Действовать силой в таких случаях недопустимо, а воспитательный эффект от подобных рекомендаций невозможно переоценить – новые проекты уже запускаются с учетом этих требований, а значит, со временем все приложения будут готовы к внедрению процессов безопасной разработки.
Сегодня российские разработчики находятся в самом начале пути постановки процессов безопасной разработки. Объединяя усилия регуляторов, разработчиков и исследователей, мы будем настойчиво продвигаться к безопасным ведомственным и бизнес-приложениям.
