Функциональность Web-приложений и их пользовательская база развиваются одновременно с ростом угроз, и хотя специальное оборудование (например, сетевые экраны) играет важную роль в деле защиты приложений, для обеспечения их полной безопасности одного оборудования недостаточно.
Все эти устройства обеспечивают защиту хостов и средств связи, но почти бессильны перед атаками на сами программные модули или дизайн (интерфейсные экраны) приложения, поэтому предприятия должны сосредоточиться на усилении защиты Web-приложений. Однако здесь сразу появляется ряд вопросов. Какие проблемы могут возникнуть у моих программ? Насколько установленные приложения уязвимы перед лицом наиболее общих угроз? Какие изменения в цикле разработки программного обеспечения могут повлиять на защиту этих уязвимых мест?
В проекте Open Web Application Security Project (OWASP, www.owasp.org) выделено десять ключевых характеристик защиты Web-приложений, а также приведены метрики, которые могут помочь количественно оценить влияние на безопасность программного продукта изменений, сделанных на той или иной стадии его жизненного цикла, — разработка, развертывание и выполнение. Расстановка метрик по жизненному циклу и типу в версии OWASP наряду с ранжированием по полученным количественным результатам может помочь выявить негативные процессы и выработать стратегии улучшения защиты.
Метрики и жизненный цикл приложений
Руководители проектов разработки программного обеспечения используют шкалу времени для принятия решений по управлению рисками на каждом из этапов жизненного цикла проекта. И менеджеры, и разработчики должны получать оценки по времени разработки на основе статического анализа исходного кода, из данных аудита и прикидочных данных. Кроме этого, они получают данные из других метрик. Метрики времени разработки помогают идентифицировать и описывать слабые места приложения на ранних стадиях его жизненного цикла, когда еще невелика стоимость исправления ошибок.
Метрики времени развертывания продукта характеризуют процесс изменения системы и ее конфигурации с течением времени. Согласно общему мнению, изменение — враг безопасности, а метрики времени развертывания позволяют получить картину реальных изменений в динамике, что помогает установить базовые принципы выявления аномалий. В сочетании со временем выполнения, время развертывания позволяет понять такие характеристики скорости изменений и ключевые метрики соглашения об уровне обслуживания, как доступность, временной интервал между сбоями и время восстановления системы после сбоя.
Метрики времени выполнения позволяют следить за поведением Web-приложения по ходу работы и обнаружить нарушения защиты после развертывания. Обнаружение уязвимых мест в процессе работы приложения обходится дороже, чем на ранних стадиях разработки, поскольку связано со снижением производительности приложения и потерями для покупателей. Если оценки времени, собранные на ранних стадиях жизненного цикла приложения, показывают улучшение благодаря изменениям в его дизайне и процессе развертывания, то можно ожидать, что в ходе эксплуатации метрики времени выполнения также покажут улучшение.
Данные по времени разработки, времени развертывания и времени выполнения тем более наглядны, что они применяются для разделения цикла разработки программного обеспечения на фазы. Параметры времени выполнения могут быть определены, например, на стадии контроля качества продукта.
Десять важных элементов безопасности
Для иллюстрации применения некоторых внешних метрик рассмотрим каждый элемент из первой десятки OWASP и соответствующий ему пример использования метрики времени разработки, развертывания и выполнения.
Запрещенный ввод
Первый элемент десятки OWASP — запрещенный ввод. Речь идет о данных, получаемых в ответ на Web-запросы, которые не были проверены на корректность перед их отправкой Web-приложению. Злоумышленники могут использовать эти слабости для компрометации конечных компонентов через данное Web-приложение.
Наиболее часто используемая метрика времени разработки — PercentValidatedInput. Чтобы ее вычислить, положим T равным значению счетчика количества вводных форм или интерфейсов, показанных приложением (число команд POST, GET и т.п., выполненных в данной HTML-форме), а V — числу тех же интерфейсов, использующих механизмы подтверждения. Отношение V/T определяет строгое условие устойчивости Web-приложения к попыткам взлома с использованием некорректных входных данных — чем ближе к единице, тем лучше. Если предприятие видит, что все его Web-приложения имеют низкий показатель PercentValidatedInput, то оно может потребовать обязательного использования стандартных механизмов подтверждения ввода, что может привести к постепенному улучшению текущих и будущих приложений.
Нарушение контроля доступа
Нарушение контроля доступа означает, что приложение не может установить и применить адекватные ограничения действия авторизованных пользователей. Взломщики могут воспользоваться этой слабостью для доступа к учетным записям других сотрудников компании, для просмотра важных файлов или вызова неавторизованных функций.
Пример соответствующей метрики времени выполнения — параметр AnomalousSessionCount, вычисляемый за два шага. Первый шаг — определение параметра SessionTableAccessProfile путем сопоставления имеющихся в журнале записей о входе пользователей в систему с таблицами базы данных, к которым был получен доступ; полученное значение SessionTableAccessProfile будет служить идентификатором пользователя вместе с соответствующим набором упорядоченных пар «имя таблицы — значение счетчика». Второй шаг — определение параметра AnomalousSessionCount путем подсчета количества значений SessionTableAccessCount, не соответствующих заданному профилю пользователя. Если значение AnomalousSessionCount больше, чем для любого из пользователей, особенно привилегированных, это может указывать на необходимость существенной перестройки и переработки частей Web-приложения, отвечающих за его устойчивость.
Нарушение управления идентификацией и пользовательскими сеансами
Данное нарушение означает, что приложение не обеспечивает должной защиты удостоверений учетных записей и сеансовых маркеров. Взломщики, которые вычисляют пароли, ключи, компрометируют сеансовые файлы cookies и другие маркеры, могут нарушить ограничения идентификации и присвоить себе учетные данные других пользователей.
Примером метрики времени выполнения в этом случае является параметр BrokenAccountCount, который вычисляется путем подсчета числа учетных записей, не использованных в течение более чем 90 дней, но при этом имеющих неограниченный срок действия. Существует риск, что посредством таких учетных записей будут предприняты попытки несанкционированного доступа.
Использование языка сценариев для взаимодействия между сайтами
С помощью этого метода (cross-site scripting, XSS) взломщики могут использовать Web-приложение как транспортный механизм для атаки на браузер пользователя. Успешная атака может открыть маркер пользователя и позволит преодолеть защиту локального компьютера или подделать содержимое с целью обмана пользователя.
Пример метрики времени выполнения — XsiteVulnCount, который можно получить через инструмент проверки возможности проникновения. Результаты напоминают процесс отслеживания дефектов программы (разработчики могут быстро исправлять ошибки, связанные с XSS). Однако в данном случае чем раньше будет обнаружена ошибка, тем лучше.
Переполнение буфера
Переполнение буфера может разрушать такие компоненты Web-приложения, как библиотеки и драйверы, написанные на языках, не позволяющих подтвердить ввод, а иногда взломщики могут использовать их для контроля над процессом.
Пример метрики времени развертывания — OverflowVulnCount, его можно получить с помощью стандартных средств обнаружения уязвимых мест, которые идентифицируют уровень доработки установленного программного обеспечения по сравнению с уровнем доработки, требуемым для устранения известных недостатков, связанных с переполнением буфера. Другой полезный набор метрик дает статистику доработок, обеспечивающих устранение уязвимости к переполнению буфера. Для вычисления этих метрик следует определить минимальное, максимальное, среднее и стандартное отклонения числа минут, часов или дней, которые требуются для устранения недостатков, приводящих к переполнению, в течение данного периода времени. Большое значение среднего или стандартного отклонения указывает на то, что доработки выполняются либо медленно, либо несогласованно.
Неустойчивость к «инъекциям»
Эта опасность угрожает Web-приложению в момент передачи параметров при доступе к внешним системам или локальным операционным системам. Если взломщик присоединит к этим параметрам вредоносные команды, внешняя система может выполнить их от имени данного приложения.
Пример метрики времени выполнения — InjectionFlawCount, который можно вывести из результатов тестов на проникновение, передающих работающей копии Web-приложения недействительные параметры. Эта метрика характеризует уязвимость приложения для возможных атак. Другая метрика времени выполнения, ExploitedFlawCount, может быть получена из сообщений о случаях успешного использования взломщиками приложения путем добавления лишних команд. Эта метрика характеризует влияние реальных атак, которые испытала система.
Некачественная обработка ошибок
Седьмой элемент перечня OWASP — некачественная обработка ошибок — относится к исходному коду приложения, который недостаточно правильно обнаруживает и обрабатывает исключительные ситуации, возникающие в ходе нормальной работы. Если взломщик спровоцирует ошибки, не обрабатываемые Web-приложением, то он может получить подробную информацию о системе, отключить сервис, вызвать сбой механизмов защиты или сбой сервера.
Для получения метрики времени разработки следует использовать средство статического анализа, чтобы подсчитать число вызовов функций, не проверяющих возвращаемые значения. Подсчет «случаев на одно приложение» дает достоверный показатель некачественной обработки исключений, причем лучше всего использовать простой подсчет строк.
Незащищенное хранение
Незащищенное хранение показывает, как часто Web-приложения используют криптографические функции для защиты информации и удостоверений. Однако доказано, что, когда эти функции и код нуждаются в интеграции, правильное кодирование затруднено, что часто приводит к ослаблению защиты.
Для определения уровня защиты, обеспечиваемой рабочей средой Web-приложения, можно вычислить метрику времени развертывания, получив процент серверов с установленным и работающим автоматически механизмом шифрования содержимого жесткого диска. Чем выше значение этой метрики, тем выше уровень защиты.
Отказ в обслуживании
Предпринимая атаку данного типа хакеры могут перегрузить ресурсы Web-приложения до такой степени, что легитимные пользователи попросту не смогут получить доступа к приложению. Злоумышленники также могут заблокировать пользователей, не позволяя им работать со своими учетными записями или даже вызвать отказ приложения.
Для получения метрики времени выполнения следует использовать результаты тестов на возможность проникновения, включающих проверку вероятности проведения атак, приводящих к отказу в обслуживании. Обнаружение уязвимости здесь может помочь, но предотвращение отказа в обслуживании может оказаться сложной задачей для разработчиков.
Незащищенная настройка
В данном случае анализируется, в какой мере Web-приложения зависят от конфигурации сервера. Сервер имеет много параметров настройки, влияющих на безопасность, но ни одну конфигурацию нельзя изначально считать защищенной.
Чтобы получить метрику времени развертывания, следует подсчитать число учетных записей сервиса (используемых программой для доступа к таким сервисам, как СУБД) со слабыми паролями или паролями, заданными «по умолчанию». Этот показатель помогает количественно оценить риск несанкционированного доступа, нарушения конфиденциальности и потери целостности.
Карточка безопасности
Карточка, показанная на рисунке, объединяет относительно тонкие метрики на основе данных тестов на проникновение, статического анализа кода, систем управления сбоями, средств обнаружения уязвимых мест и другого инструментария. Такую карточку можно использовать для отслеживания процесса улучшения защиты, выполняемого разработчиками Web-приложений.
Следующие шаги, вытекающие из методологии Six Sigma (www.isixsigma.com), помогают построить рейтинг метрик.
-
Представление каждой метрики как отношения числа дефектов к числу возможностей. Если, например, Web-приложение имеет 100 вводных форм и 12 из них имеют дефект подтверждения ввода, то приложение получает рейтинг 88. Соответствующее уравнение выглядит так: 1.0 — (#defects/#opportunities).
-
Цветовое отображение метрик, основанное на сравнении с пороговыми значениями. К примеру, красный цвет может использоваться для отображения величин, которые меньше 80, желтый — для диапазона от 81 до 90, а зеленый — для величин больше 91.
-
Агрегрегирование всех параметров отдельного Web-приложения в категорию уязвимости, чтобы построить «суммарный» рейтинг.
Теперь можно задать отображение многих рейтингов на одно состояние, выделенное определенным цветом, например:
-
заданное состояние внутренней категории уязвимости примите за наихудшее значение или обозначьте цветом, определенным для наихудшего;
-
с помощью порогового механизма задайте определенный цвет для обозначения среднего рейтинга;
-
вычислите средневзвешенное значение всех отдельных метрик согласно принятой важности (здесь ключевую роль играет соглашение); задайте средневзвешенное значение для состояния, используя пороговый механизм;
-
задайте отображение разности среднего и стандартного отклонения для всех отдельных метрик состояний отдельной категории.
Карточка безопасности содержит дополнительные показатели, позволяющие графически отобразить тенденцию в данный период времени по сравнению с предыдущими периодами. Чтобы дополнить количественные рейтинги, аналитики также должны включить в карточки качественные, неструктурированные комментарии, поясняющие, как использовать приведенные данные, для каких целей они служат, как интерпретировать результаты и какие действия предприняла компания после того, как проанализировала представленные данные. Таким образом, организации могут начать упорядочивать множество тонких метрик, полученных из существующей у них инфраструктуры, и эффективно улучшать защиту приложений.
С течением времени можно создать и регулярно просматривать карточку, подобную изображенной на рисунке, начиная с легкодоступных метрик, таких как результаты существующих тестов на проникновение, статических сканеров кода и систем управления сбоями. В наших собственных тестах, в которых была использована платформа построения необходимых метрик защиты, на составление карточки потребовалось примерно две недели работы, от начального проектирования до развертывания приложения.
Литература
-
D.E. Geer, A.R. Jaquith, K. Soo Hoo, Information Security: Why the Future Belongs to the Quants. IEEE Security & Privacy, vol. 1, no. 4, 2003.
Элизабет Николс (ean@clearpointmetrics.com) — директор по технологиям компании ClearPoint Metrics; Гуннар Петерсон (gunnar@arctecgroup.net) — основатель и директор компании Arctec Group, специализирующейся на создании ИТ-архитектур и консалтинге по принятию стратегических решений.
Elizabeth Nichols, Gunnar Peterson. A Metrics Framework to Drive Application Security Improvement. IEEE Security & Privacy, March/April 2007. IEEE Computer Society, 2007. All rights reserved. Reprinted with permission.
