Содержание
- Что такое тестирование безопасности?
- Виды тестирования безопасности
- Тест-кейсы и сценарии безопасности
- Подходы к тестированию безопасности
- Что такое DevSecOps?
- Тестирование безопасности данных
- Средства тестирования безопасности
- Лучшие практики тестирования безопасности
Что такое тестирование безопасности?
Тестирование безопасности позволяет проверить уязвимость ПО к кибератакам и узнать, как на его работу влияют вредоносные или неожиданные входные данные. Оно гарантирует, что системы и информация безопасны и надежны и не допускают несанкционированного ввода данных.
Фактически, тестирование безопасности – это разновидность нефункционального тестирования. В отличие от функционального, которое фокусируется на правильной работе функций ПО, нефункциональное тестирование фокусируется на том, правильно ли спроектировано и настроено приложение.
Основные цели тестирования безопасности:
- Определение активов. Активы – это то, что необходимо защитить. Например, программные приложения и вычислительная инфраструктура.
- Выявление угроз и уязвимостей. Определение действий, способных нанести ущерб активу, или слабых мест в одном или нескольких активах, которые могут быть использованы злоумышленниками.
- Идентификация риска. Тестирование безопасности призвано оценить риск того, что конкретные угрозы или уязвимости окажут негативное влияние на бизнес. Чтобы оценить риск, мы определяем серьезность угрозы или уязвимости.
- Проведение исправлений. Тестирование безопасности – это не просто пассивная оценка активов. Оно предоставляет практические рекомендации по устранению обнаруженных уязвимостей и может подтвердить, что они были успешно устранены.
Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.
Основные принципы тестирования безопасности
Цель тестирования безопасности — убедиться, что системы, приложения и данные организации соответствуют следующим принципам:
- Конфиденциальность – ограничение доступа к конфиденциальной информации, управляемое системой.
- Целостность – обеспечение согласованности, точности и достоверности данных на протяжении всего их жизненного цикла и невозможности их изменения неавторизованными лицами.
- Аутентификация – обеспечение защиты конфиденциальных систем или данных с помощью механизма, который проверяет личность человека, получившего к ним доступ.
- Авторизация – обеспечение надлежащего контроля доступа к чувствительным системам или данным для аутентифицированных пользователей в соответствии с их ролями или разрешениями.
- Доступность – обеспечение доступности критически важных систем или данных для их пользователей в нужный момент.
- Безотказность – гарантирует, что отправленные или полученные данные не могут быть отклонены, путем обмена информацией об аутентификации с доказуемой отметкой времени.
Виды тестирования безопасности
Тестирование на проникновение (этичный хакинг)
Тестирование на проникновение – это процесс стимулирования реальных кибератак на программу, систему или сеть в безопасных условиях. С его помощью мы оцениваем, насколько существующие меры безопасности окажутся эффективными в условиях реальной атаки. Самое главное, тестирование на проникновение позволяет обнаружить неизвестные уязвимости, включая угрозы “нулевого дня” и пробелы бизнес-логики.
Традиционно тестирование на проникновение проводилось вручную проверенными и сертифицированными специалистами по безопасности, известными как этичные хакерк. Хакеры работали в оговоренных рамках, пытаясь взломать системы компании контролируемым образом, не причиняя ей никакого ущерба. В последние годы инструменты автоматизации тестирования на проникновение помогают организациям достичь аналогичных преимуществ при меньших затратах и более частом тестировании.
Тестирование безопасности приложений (AST)
Тестирование безопасности приложений (AST – Application security testing ) описывает методы, которые организации могут использовать для поиска и устранения уязвимостей в программах. Эти методы включают в себя тестирование, анализ и составление отчетов о состоянии безопасности ПО на протяжении всего жизненного цикла его разработки (SDLC).
Основная цель тестирования безопасности приложений – предотвратить уязвимости ПО до его выхода на рынок, а в случае неудачи – быстро выявить и устранить их в процессе эксплуатации. Успешно внедрив AST, мы можем создавать более надежный и безопасный исходный код и улучшить защиту от внутренних и внешних угроз.
Тестирование безопасности веб-приложений
Цель тестирования безопасности веб-приложений – определить их уязвимость к атакам. При этом применяются различные автоматические и ручные методы тестирования.
В фокусе тестирования веб-приложения на проникновение:
- сбор информации о приложении
- обнаружение слабых мест или недостатков системы
- исследование успешности использования этих недостатков
- оценка риска уязвимостей приложения.
Тестирование безопасности API
Тестирование безопасности API (Application Programming Interface) помогает выявить уязвимости в интерфейсах прикладного программирования и веб-сервисах, а также помочь разработчикам своевременно их устранить. API предоставляют доступ к конфиденциальным данным, и злоумышленники могут использовать их в качестве точки входа во внутренние системы. Тщательное и регулярное тестирование API может защитить их от несанкционированного доступа и злоупотреблений.
API особенно уязвимы к таким угрозам, как атаки типа “человек посередине” (Man in the middle). При них злоумышленники могут подслушивать API-коммуникации и красть данные или учетные записи. Также существуют API-инъекции, при которых злоумышленники могут внедрить вредоносный код во внутренние системы, и отказ в обслуживании (DoS – denial of service attack), при котором злоумышленники наводняют API фальшивым трафиком, чтобы отказать в обслуживании законным пользователям.
Для снижения этих угроз должна быть реализована строгая аутентификация пользовательских запросов и авторизация пользователей в соответствии с принципом наименьших привилегий. Все коммуникации дожны шифроватьсяс помощью SSL/TLS. Пользовательский ввод должен очищаться для предотвращения инъекций и взлома кода. Все упомянутое нужно проверять в ходе тестирования безопасности API.
Управление уязвимостями
Управление уязвимостями позволяет выявлять и оценивать пробелы безопасности в конечных устройствах, рабочих нагрузках и в сетях, а также управлять ими и устранять их. Для обнаружения уязвимостей обычно используются специальные инструменты сканирования, а для их устранения применяют ручные или автоматизированные процессы.
Надежная программа управления уязвимостями использует аналитику угроз и знание IT-операций. Это помогает понять реальное влияние уязвимостей на бизнес, определить приоритетность рисков и как можно быстрее устранить наиболее высокоприоритетные из них.
Сканирование конфигурации
Сканирование конфигурации – это процесс выявления неправильных настроек ПО, сетей и других вычислительных систем. Этот тип сканирования обычно проверяет системы на соответствие списку лучших практик, определенных исследовательскими организациями или стандартами.
Автоматизированные инструменты сканирования выявляют неправильные конфигурации и предоставляют отчет с более подробной информацией по каждой из них и предложениями по их устранению.
Аудиты безопасности
Аудит безопасности – это структурированный процесс проверки ПО на соответствие определенному стандарту. Аудит обычно включает в себя проверку кода или архитектуры с учетом требований безопасности, анализ слабых мест и оценку уровня безопасности аппаратных конфигураций, операционных систем и организационных методов. Также оценивается соответствие нормативным требованиям и стандартам.
Оценка рисков
Оценка рисков позволяет организации выявить, проанализировать и классифицировать риски безопасности, которым подвергаются критически важные для бизнеса активы. Она помогает понять, какие угрозы являются наиболее важными для инфраструктуры организации, и определить приоритетность восстановления систем. Она также может помочь в долгосрочном планировании и составлении бюджета инвестиций в безопасность.
Оценка состояния безопасности
Оценка уровня безопасности сочетает в себе сканирование системы безопасности, этичный взлом и оценку рисков, чтобы определить не только риски, с которыми сталкивается организация, но и текущие средства защиты и их эффективность. Она позволяет выявить пробелы в имеющейся системе безопасности и рекомендовать изменения или улучшения, которые позволят повысить безопасность защищаемых активов.
Тест-кейсы и сценарии безопасности
Аутентификация
Тестирование безопасности систем аутентификации должно включать следующие пункты:
- Проверка правил паролей. Проверьте уровень безопасности и качество паролей, требуемых сайтом.
- Идентификация уязвимости перечисления имен пользователей. Проверьте, отличается ли ошибка в зависимости от наличия зарегистрированного пользователя.
- Проверка надежности пароля. Минимальные требования для создания пароля.
- Идентификация уязвимости восстановления учетных записей. Проверьте, можно ли с помощью атак восстановить учетные записи (например, путем изменения электронной почты или пароля).
- Проверка имени пользователя. Убедитесь, что имена пользователей уникальны.
- Выявление аутентификации с отказом. Проверьте, предоставляет ли система открытый доступ при неудачной аутентификации.
- Проверка масштабирования файлов cookie. Проверьте, привязаны ли файлы cookie к домену и могут ли злоумышленники их украсть.
Валидация ввода
Тестирование входных данных должно включать следующее:
- Параметры запроса. Проверка на отраженные параметры и открытое перенаправление.
- Идентификация уязвимости к:
- SQL-инъекции – проверьте, обрабатывает ли система параметры как SQL.
- SOAP-инъекции – проверьте, отвечает ли приложение на запросы SOAP.
- LDAP-инъекции – проверьте, не удалось ли системе очистить входные данные.
- XML-инъекции – проверьте, влияет ли внедренный XML на работу приложения.
- XXE-инъекции – проверьте, могут ли злоумышленники внедрять внешние объекты.
Приложения и бизнес-логика
Эти тесты важны для тестирования безопасности. Они требуют ручного вмешательства, так как слишком сложны для автоматизации из-за уникальности логики каждого приложения. Такие тесты должны включать следующее:
- Определение того, как выглядит атака на логику приложения. То, что делает приложение.
- Проверка передачи данных от клиентов. Посмотрите, не отличается ли передача информации между приложениями.
- Определение валидации ввода на стороне клиента. Проверьте, где приложение основывает свою логику.
- Определение недостатков логики в многоэтапных процессах. Проверьте, возможно ли обойти этапы.
- Тест обработки неполного ввода. Проверьте, обрабатывает ли приложение ошибочный ввод.
- Проверка доверительных отношений. Проверьте, могут ли пользователи получить доступ к функциям администратора.
Другие тесты
Существуют дополнительные тесты, которые помогают обеспечить безопасность приложения и выявить следующие уязвимости:
- Уязвимости DOM, такие как XSS (Cross-Site Scripting — «межсайтовый скриптинг»)
- Отсутствие заголовков безопасности HTTP
- Локальные уязвимости конфиденциальности
- Слабые и постоянные файлы cookie
- Слабые шифры SSL
- Параметры URL, содержащие конфиденциальную информацию
Подходы к тестированию безопасности
Тестирование “черного ящика”
При тестировании методом “черного ящика” тестировщик безопасности оценивает защищенность системы извне, не зная внутренних процессов, генерирующих ответные реакции. Черный ящик – это непрозрачная система, то есть наблюдаемыми являются только входные и выходные данные. В некоторых случаях тестировщик игнорирует внутреннюю структуру системы, даже если ее можно понять.
Тестирование “черного ящика” обеспечивает разделение между тестировщиком и создателем кода. Оно заставляет тестировщика принимать точку зрения стороннего наблюдателя и проводить проверку ПО с точки зрения злоумышленника. Социальное и техническое разделение между тестированием и разработкой продукта позволяет тестировщику манипулировать приложением способом, который не был учтен разработчиком.
Тестирование “белого ящика”
При тестировании методом “белого ящика” тестировщик разрабатывает тест-кейсы на основе исходного кода ПО. Тестировщик знает и понимает структуру кода, в отличие от метода “черного” или “серого ящика”. Из-за этой наблюдаемости тестирование “белого ящика” также называют тестированием “прозрачного” или “стеклянного” ящика.
Эта техника тестирования фокусируется на внутренней работе приложения и его программных компонентов. Команды тестирования могут применять ее для системных, интеграционных и модульных тестов.
Тестирование “серого ящика”
Тестирование методом “серого ящика” – это своего рода гибрид “белого” и “черного ящика”. В этом случае тестировщик имеет частичное представление о внутренней структуре и работе системы.
Тестировщики могут основывать свои тесты на ограниченном понимании базовой архитектуры и кода приложения. Таким образом, объект тестирования становится полупрозрачным или “серым”.
Тестировщики “серого ящика” ориентируются на код приложения, но комбинируют это с разнообразными подходами “черного ящика”, такими как функциональное и регрессионное тестирование. Таким образом они могут одновременно оценивать то, что видит пользователь, и внутреннюю работу ПО.
Что такое DevSecOps?
DevSecOps – это стратегия разработки программного обеспечения и управления проектами, объединяющая процессы разработки, безопасности и эксплуатации. Она сочетает их с инфраструктурой как кодом для создания автоматизированных конвейеров непрерывной доставки.
Главная цель конвейера DevSecOps – обеспечить автоматизацию, мониторинг и другие процессы безопасности на протяжении всего жизненного цикла разработки ПО. Это гарантирует безопасность на каждом этапе, в том числе на этапах планирования, разработки, создания, тестирования, выпуска, доставки и развертывания.
Включение безопасности во все этапы процесса разработки важно для непрерывной интеграции. Это позволяет командам быстрее создавать безопасное ПО, одновременно снижая риск возникновения дорогостоящих ошибок и откатов. В рамках DevSecOps все члены команды разделяют ответственность за безопасность с самого начала.
Тестирование безопасности данных
Обеспечение безопасности данных – сложная задача для многих организаций. Бизнес-данные являются основной частью большинства критически важных бизнес-процессов. Их утечка может подвергнуть организации риску нарушения нормативно-правовых требований, нанести репутационный ущерб и привести к финансовым потерям. Поэтому компании тратят значительную долю своего бюджета на защиту конфиденциальных данных от атак.
Организации должны тщательно проверять свои средства управления безопасностью, чтобы убедиться в их соответствии своим собственным требованиям безопасности, а также государственным нормам и отраслевым стандартам. Во многих случаях стандарты соответствия прямо требуют проведения тестирования безопасности, чтобы доказать аудиторам, что данные защищены должным образом.
Аудит безопасности данных
Организациям следует проводить аудит безопасности данных не реже одного раза в несколько месяцев. Это позволяет выявить риски и слабые места в механизмах защиты данных. Аудиты могут проводиться внутренними службами безопасности или отделами по соблюдению нормативных требований, однако нелишним будет привлечение сторонних аудиторов или специалистов по тестированию на проникновение. Добровольные аудиты позволяют обнаружить важные проблемы безопасности и устранить их прежде, чем организация подвергнется рискованному и стрессовому внешнему аудиту.
Основным результатом такого аудита является отчет, в котором подробно описаны слабые места и недостающие элементы в модели безопасности данных. Необходимо приложить усилия для определения приоритетности этих недостатков и их устранения.
Тестирование на соответствие
Тестирование на соответствие – это процесс мониторинга и оценки систем, устройств, сетей и облачных сред для проверки их соответствия нормативным требованиям и отраслевым стандартам кибербезопасности.
Отслеживать соблюдение требований не всегда легко, особенно в жестко регулируемых отраслях и секторах. Нормативные акты и стандарты часто меняются и могут содержать очень подробные требования, затрагивающие каждый аспект IT-среды. Сегодня большинство организаций переносят рабочие нагрузки в облако, при этом динамичный характер облачных сред может усложнить соблюдение требований.
Тестирование на соответствие требованиям может включать отслеживание конфиденциальных активов, проверку личной информации, а также проведение плановых учений или тестов на проникновение, чтобы убедиться, что организация готова к взлому. Ключевой частью этого тестирования является обнаружение и классификация данных – понимание того, где хранятся конфиденциальные данные, с последующим подтверждением того, что приняты соответствующие меры безопасности.
Тестирование безопасности на базе облачных технологий
Cloud Native – это набор принципов проектирования и технологий, позволяющих создавать приложения, способные в полной мере использовать преимущества облачных сред. Модели разработки Cloud Native, включая контейнеризацию и бессерверные вычисления, направлены на повышение масштабируемости и эластичности, а также на ускорение разработки и развертывания.
Одной из проблем облачных нативных сред является низкий уровень видимости. В “облачном” приложении может быть много подвижных частей, большинство из которых эфемерны и недолговечны. Тестирование безопасности “облачных” приложений включает в себя обнаружение элементов такого приложения и выявление слабых мест в системе безопасности, таких как неправильные настройки, отсутствие передовых методов обеспечения безопасности и уязвимости.
Двумя важными направлениями тестирования собственной облачной безопасности являются сканирование образов контейнеров и сканирование инфраструктуры как кода (IaC – Infrastructure-as-Code). Шаблоны IaC являются важной поверхностью для атак, поскольку они используются для автоматического создания облачных ресурсов в большом масштабе.
Тестирование безопасности баз данных
Безопасность баз данных подразумевает защиту их серверов, таких как Oracle, Microsoft SQL Server и MySQL, от несанкционированного доступа и кибератак. В базах данных обычно хранится критически важная бизнес-информация, поэтому они являются ценной мишенью для злоумышленников.
Тестирование безопасности базы данных направлено на проверку защищенности ее ключевых элементов, включая базовую систему управления базами данных (СУБД), сервер хостинга, данные, хранящиеся в БД, приложения, подключенные к серверу БД, и сетевую инфраструктуру, используемую для доступа к базе данных.
Важным аспектом тестирования безопасности базы данных является проверка общих векторов угроз, таких как SQL-инъекции, NoSQL-инъекции и локальные файловые инъекции (LFI). Тестирование безопасности БД направлено на выявление в ней слабых мест и предоставление практической информации, которая поможет защитить ее от вторжения, неправомерного использования и компрометации.
Тестирование облачных данных
Облачное тестирование – это процесс тестирования программных приложений, развернутых на облачных вычислительных ресурсах по модели “инфраструктура как сервис” (IaaS – Infrastructure as a Service) или обслуживаемых сторонними поставщиками услуг по модели “платформа как сервис” (PaaS – Platform as a Service) или “программное обеспечение как сервис” (SaaS – Software as a Service).
Тестирование облачных данных позволяет обеспечить оптимальную производительность, доступность и безопасность данных, а также минимизировать время простоя соответствующей инфраструктуры или платформы.
Основное внимание при тестировании облачных данных уделяется обеспечению выполнения обещаний, данных поставщиками облачных услуг и SaaS. Например, тестирование облачных данных позволяет убедиться в том, что поставщики соблюдают соглашения об уровне обслуживания в отношении производительности, проверить, действительно ли данные реплицируются в несколько мест, а также убедиться, что процессы аварийного восстановления работают правильно.
Средства тестирования безопасности
Статическое тестирование безопасности приложений (SAST)
Инструменты SAST (Static Application Security Testing) оценивают исходный код в состоянии покоя. Цель SAST – выявить уязвимости, которые можно использовать, и предоставить подробный отчет с выводами и рекомендациями.
Вы можете запустить SAST для выявления проблем в исходном коде, чтобы обнаружить такие проблемы, как проверка ввода, числовые ошибки, обходные пути и т.д. SAST также можно использовать в скомпилированном коде, но для этого требуются бинарные анализаторы.
Динамическое тестирование безопасности приложений (DAST)
Инструменты DAST (Dynamic Application Security Testing) проверяют приложение во время его выполнения. Цель DAST – обнаружить уязвимости в приложении во время его работы, используя широкий спектр атак.
Инструмент DAST часто использует фаззинг для выброса в приложение больших объемов известных недопустимых ошибок и неожиданных тест-кейсов, пытаясь обнаружить условия, при которых приложение может быть использовано.
Тесты DAST можно запускать для проверки широкого спектра компонентов, включая сценарии, сеансы, внедрение данных, аутентификацию, интерфейсы, ответы и запросы.
Интерактивное тестирование безопасности приложений (IAST)
Инструменты IAST (Interactive Application Security Testing) используют как статическое, так и динамическое тестирование для создания гибридного процесса. Цель – определить, можно ли использовать известные уязвимости исходного кода во время выполнения. Инструменты IAST часто используются для снижения количества ложных срабатываний.
Инструмент IAST сочетает в себе различные методы тестирования для создания множества сценариев атак с использованием предварительно собранной информации о потоке данных. Затем инструменты рекурсивно выполняют динамический анализ.
Благодаря циклам динамического анализа инструмент IAST продолжает узнавать больше о приложении в зависимости от того, как оно реагирует на каждый тест-кейс. Такой инструмент может использовать результаты анализа для создания новых тест-кейсов, чтобы получить больше информации о приложении.
Анализ конфигурации программного обеспечения (SCA)
Анализ конфигурации программного обеспечения (SCA – Software Configuration Analysis) – это технология, используемая для управления и защиты компонентов с открытым исходным кодом. Команды разработчиков могут использовать SCA для быстрого отслеживания и анализа этих компонентов, развернутых в их проектах.
Средства SCA могут обнаружить все необходимые компоненты, библиотеки, которые их поддерживают, а также прямые и косвенные зависимости. В каждом из найденных компонентов они могут выявить уязвимости и предложить меры по их устранению. В процессе сканирования создается спецификация материалов (BOM – Bill of Materials), в которой содержится полный список программных активов проекта.
Лучшие практики тестирования безопасности
Вот несколько лучших практик, которые помогут реализовать успешное проведение тестирования безопасности.
Сдвиг тестирования безопасности влево
С переходом на DevSecOps организации внедряют методы обеспечения безопасности на более ранних этапах процесса разработки. Обычно инструменты тестирования безопасности интегрируются в цикл непрерывной интеграции / непрерывной доставки (CI/CD).
Сдвиг тестирования безопасности влево может помочь разработчикам понять проблемы безопасности и внедрить передовые методы ее обеспечения, пока ПО находится в стадии разработки. Это также может помочь тестировщикам найти проблемы безопасности на ранней стадии, до того как ПО будет выпущено в прод. Наконец, группы эксплуатации и безопасности могут использовать тестирование безопасности в производстве, чтобы выявлять проблемы и работать с другими командами над их устранением.
Тестирование внутренних интерфейсов
Тестирование безопасности обычно сосредоточено на внешних угрозах, таких как ввод данных пользователем в общедоступных веб-формах. Однако все чаще злоумышленники используют слабые места во внутренних системах. С помощью тестирования безопасности важно убедиться, что между внутренними системами существуют безопасные интерфейсы, а внутренние угрозы или взломанные учетные записи не могут быть использованы для повышения привилегий.
Автоматизация и частое тестирование
Несмотря на важность ручного тестирования безопасности, например, тесты на проникновение или аудит безопасности, организации должны автоматизировать этот вид тестирования и проводить его как можно чаще – желательно при каждом изменении приложений или вычислительной инфраструктуры.
В корпоративных приложениях используется большое количество компонентов, которые могут требовать обновлений безопасности или перестать поддерживаться поставщиками программного обеспечения. Очень важно тестировать критически важные для бизнеса системы, придавать высокий приоритет проблемам безопасности, которые их затрагивают, и оперативно выделять ресурсы на их устранение.
Компоненты сторонних производителей и безопасность открытого кода
Организации должны проводить тестирование безопасности стороннего кода, используемого в их приложениях, особенно компонентов с открытым исходным кодом.
Неразумно доверять коммерческому программному обеспечению и не менее важно проверять компоненты с открытым исходным кодом, которые могут требовать обновлений или не быть должным образом защищены. Сканировать и исправлять код сторонних разработчиков следует так же, как и свой собственный, а приоритетными являются обновления, исправления или замена небезопасных компонентов.
Использование руководства OWASP по тестированию веб-безопасности
Руководство по тестированию веб-безопасности WSTG (The Web Security Testing Guide) – это онлайн-ресурс по тестированию кибербезопасности для специалистов по безопасности и разработчиков веб-приложений. Он был создан профессионалами в этой области совместно с добровольцами, чтобы предоставить основу лучших практик для проверки безопасности веб-сервисов и приложений.
Перевод статьи «Security Testing: Types, Tools, and Best Practices».