Представляю вашему вниманию продолжение перевода второй главы Owasp Testing Guide. В данной статье речь пойдет о требованиях к тестированию безопасности.

Определяем требования к тестированию безопасности

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

Цели тестирования

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

Другой целью является тестирование самих механизмов безопасности. Они проверяются на наличие общих уязвимостей, например, из OWASP топ-10, а также уязвимостей, которые были обнаружены ранее при проверках безопасности на стадиях ЖЦ.

Документация требований к безопасности

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

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

Перечень подходящих отраслевых стандартов безопасности также должен быть зафиксирован. Например, в случае с приложениями, которые хранят данные кредитных карточек их пользователей, соответствие стандарту PCI DSS запрещает хранить ПИН и CVV2 коды, требует защиты данных магнитной ленты в хранилище, передачи их с шифрованием и вывод на экран с маскировкой символов. Такие требования безопасности PCI DSS могут быть проверены в ходе анализа исходного кода.

Кроме этого, общие требования к приложению должны соответствовать политикам и стандартам по ИБ, действующим в организации. Что касается функциональных требований к механизмам безопасности, они должны быть выделены в отдельную главу стандартов по ИБ в организации. Примером такого требования: «сложность пароля 6 букв/цифр обязательна и должна поддерживаться средствами контроля аутентификации, используемыми в приложении».

Когда требования защиты соответствуют законодательству, тест безопасности может указать на наличие правовых рисков. Если он найдёт нарушения соответствия стандартам и политикам ИБ, это будет риском, который может быть задокументирован и которым должен управлять бизнес.

Проверка требований к безопасности

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

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

Пример такой проверки: используются только допустимые в организации алгоритмы шифрования (например, SHA-256, RSA, AES) с допустимой минимальной длиной (например, более 128бит для симметричного и более 1024бит для асимметричного шифрования).

Требования безопасности можно проверять на разных стадиях ЖЦ ПО с использованием средств и методологий тестирования. Например, моделирование угроз направлено на поиск бреши в системе безопасности, допущенной в ходе проектирования; анализ исходного кода направлен на поиск проблем безопасности в исходном коде, допущенных в процессе разработки; тестирование на проникновение направлено на поиск уязвимостей в приложении в процессе тестирования.

Проблемы безопасности, найденные на ранних стадиях ЖЦ, могут быть отмечены в плане тестирования. Таким образом их можно будет повторно проверить на поздних стадиях. Комбинируя результаты разных методов тестирования можно вывести более качественные тест-кейсы и увеличить собственную уверенность в достаточности требований безопасности. Например, выделение реальных уязвимостей из тех, которые нельзя эксплуатировать, возможно только когда результаты пентеста и анализа исходного кода совмещены вместе.

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

Классификация угроз и контрмер

Классификация угроз и контрмер, которая рассматривает и источники причин появления уязвимостей, это критический фактор в подтверждении того, что механизмы безопасности спроектированы, разработаны и развёрнуты должным образом для смягчения воздействия от реализации таких уязвимостей. В случае с веб-приложениями, воздействие на механизмы безопасности общеизвестных уязвимостей, таких как OWASP топ-10, может быть хорошей отправной точкой для формулирования общих требований безопасности. Более подробно по данному вопросу можно посмотреть классификацию [https://msdn.microsoft.com/en-us/library/ms978518.aspx#tmwacheatsheet_webappsecurityframe] уязвимостей, которые могут быть задокументированы в различных руководствах и стандартах и проверены с помощью тестов.

Целью классификации угроз и контрмер является определение требований безопасности в терминах угроз и корневых причин уязвимостей. Угрозы могут быть категоризированы по классификации STRIDE [https://msdn.microsoft.com/en-us/library/aa302418.aspx] на такие категории как:

• спуфинг,
• несанкционированное вмешательство,
• возможность отказа от авторства (прим. repudiation),
• раскрытие информации,
• отказ в обслуживании,
• эскалация прав.

Корневые причины могут быть категоризированы следующим образом:

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

Например, корневой причиной слабой аутентификации может быть недостаток двусторонней аутентификации, когда данные переходят за доверенный периметр между клиентской и серверной частями приложения. Обнаружение угрозы неотказываемости (прим. non—repudiation https://en.wikipedia.org/wiki/Non—repudiation) во время анализа архитектуры приложения и внесение её в требования к безопасности позволит в дальнейшем разработать требования к контрмерам (например, двусторонней аутентификации).

Классификация угроз и контрмер может быть также использована для создания стандартов безопасного программирования в организации. Примером распространённой ошибки в коде механизмов аутентификации является применение хэш функций для шифрования пароля без использования вектора псевдослучайных чисел [https://en.wikipedia.org/wiki/Random_seed]. С точки зрения безопасного программирования это уязвимость, оказывающая воздействие на шифрование, используемое для аутентификации, и корневой причиной является ошибка в коде. Чтобы этого избежать, необходимые требования должны быть задокументированы в стандарте безопасного программирования и затем их выполнение нужно протестировать.

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

Требования безопасности должны брать во внимание значимость уязвимостей при разработке стратегии по смягчению рисков. Если в организации поддерживается репозиторий найденных уязвимостей, то выявленные проблемы безопасности могут быть отсортированы по типу, проблеме, способам смягчения, корневой причине и связи с приложениями, в которых они были найдены. Такая база знаний уязвимостей также может быть использована показателями эффективности для оценки тестов безопасности в ЖЦ ПО.

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

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

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

Определяем функциональные и нефункциональные требования к тестированию

Функциональные требования к безопасности

Что касается функциональных требований безопасности, подходящие стандарты, политики и законы нужны как для выбора типа механизма безопасности, так и для его функциональности. Такие требования иногда называют «положительные требования», т.к. они определяют ожидаемую функциональность, которая может быть подтверждена с помощью тестов. Примеры положительных требований: «приложение будет блокировать пользователя после шести неудачных попыток входа» или «пароли должны быть минимальной длины 6 букв/цифр». Проверка положительных требований производится воссозданием условий тестирования и запуском теста с ранее определённым вводом. Результатом является прохождение либо не прохождение теста.

Требования к безопасности должны исходить из функций, а также освещать ожидаемую функциональность (что?) и неявно их реализацию (как?). Примерами высокоуровневых требований к безопасности в интерфейсе аутентификации могут быть:

1. защищайте персональные данные и секретную информацию при передаче и хранении;
2. скрывайте конфиденциальную информацию на дисплее (пароли, счета);
3. блокируйте аккаунт после нескольких неудачных попыток входа;
4. не показывайте пользователю подробные ошибки при неудачной попытке входа;
5. устанавливайте особые требования к паролю: буквы/цифры + несколько особых символов, минимальную длину 6 (чтобы сделать атаку перебором паролей сложнее);
6. настройте возможность смены пароля только для авторизованных пользователей с вводом старого пароля, нового пароля и ответа на секретный вопрос для предотвращения брутфорса пароля через интерфейс смены пароля;
7. форма сброса пароля должна проверять имя пользователя и email регистрации перед отправкой временного пароля пользователю по почте. Временный пароль должен быть одноразовым. Ссылка на страницу сброса пароля должна также содержаться в письме. Страница сброса пароля должна иметь поля временного пароля пользователя, нового пароля и ответа на секретный вопрос.

Риск-ориентированные требования безопасности

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

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

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

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

• Шифруйте данные аутентификации в хранилище и при их передаче для снижения риска раскрытия информации и атак на протоколы аутентификации;
• шифруйте пароли используя необратимые алгоритмы шифрования, такие как свёртка строки (например, хэш-функцией) и используя вектор псевдослучайных чисел для предотвращения возможности атак по словарю;
• Блокируйте аккаунты после достижения порога попыток ошибочного ввода и принуждайте создавать сложные пароли для снижения риска брутфорса паролей;
• Отображайте общие ошибочные сообщения (без указания на то, что именно было введено некорректно) после подтверждения имени пользователя и пароля для снижения риска перебора имён пользователей;
• Совместно аутентифицируйте клиента и сервер для предотвращения неотказываемости и атаки «человек посередине».

Средства моделирования угроз, такие как деревья угроз и библиотеки атак могут быть полезны для определения отрицательных сценариев тестирования. Дерево угроз будет допускать корневую атаку (например, злоумышленник сможет прочитать чужие сообщения) и определить возможные ошибки в механизмах безопасности (например, ошибки проверки данных из-за уязвимости к SQL-инъекциям) или необходимые контрмеры (например, установить проверку данных и параметризованные запросы) эффективность которых может быть подтверждена в смягчении таких атак.

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

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

Также, как и сценарии использования, сценарии неверного обращения [http://folk.uio.no/nik/2001/21-sindre.pdf] с ПО описывают непредназначенные и вредоносные сценарии использования приложения. В них содержатся предположения о том, как злоумышленник мог бы обходить защиту в приложении. Рассуждая над тем, как на каждом шаге мог бы поступить злоумышленник, потенциальные бреши безопасности или плохо определённые аспекты приложения могут быть обнаружены. Требуется описать все возможные, или хотя бы наиболее критичные сценарии корректного и неверного использования.

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

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

шаг 1) описать функциональный сценарий использования: пользователь аутентифицируется, предоставляя имя пользователя и пароль. Приложение даёт доступ пользователям, прошедшим аутентификацию, или выдаёт определённую ошибку если проверка не прошла;

шаг 2) описать отрицательный сценарий: злоумышленник взламывает аутентификацию с помощью брутфорса либо атак на пароли по словарю и уязвимости для сбора логинов пользователей приложения. Ошибки подтверждения входа дают возможность злоумышленнику понять, какие логины существуют в системе. Затем он брутфорсит пароли для таких логинов. Атака брутфорсом на минимальную длину в 4 символа, если все они цифры, может быть успешной за ограниченное количество попыток (в данном случае 10^4);

шаг 3) описать функциональный и отрицательные сценарии в вариантах корректного и некорректного использования приложения. Графический пример на рисунке ниже (см. рис. 5) изображает вывод требований безопасности через корректные и некорректные сценарии использования. Функциональный сценарий состоит из действий пользователя (ввод имени пользователя и пароля) и действий приложения (аутентификация пользователя и вывод сообщения об ошибке если он не подтверждён). Некорректные сценарии использования состоят из действий злоумышленника, например, попытки обойти систему аутентификации брутфорсом пароля через атаку по словарю и собирая существующие имена пользователей исходя из сообщений об ошибке. Графическое представление связи угроз и действий пользователей делает возможным вывод контрмер в приложении для смягчения данных угроз.

Рис. 5. Сценарии использования приложения

шаг 4) сформулировать требования безопасности. В данном случае, необходимо выделить следующее:

1. пароли должны состоять из букв и цифр, в верхнем и нижнем регистре, длиной минимум 7 символов
2. необходимо временно блокировать логины после 5 неудачных попыток входа
3. сообщения об ошибках не должны давать дополнительной информации, т.е. должны быть общими при любой ошибке.

Эти требования должны быть задокументированы и протестированы.