Оценка уязвимостей помогает найти и проанализировать слабые места в согласованном наборе систем. Тестирование на проникновение проверяет, можно ли использовать эти слабые места для достижения конкретной цели, например доступа к защищённым данным. Оба подхода полезны, но отвечают на разные вопросы. Чтобы выбрать проверку, сначала определите, какое решение вы будете принимать на основании её результатов.
Если вам нужен список проблем для регулярного устранения, начните с оценки уязвимостей. Если вам необходимо проверить определенный путь атаки или устойчивость важного приложения в определенном сценарии, рассмотрите возможность проведения тестирования на проникновение. Ни один отчет не гарантирует защиту от всех атак. Каждый тест имеет ограничения по времени, области, доступу и разрешенным действиям.
Понимание того, что проверяет каждый подход
Оценка уязвимостей: от обнаружения до подтвержденных результатов
Оценка может включать автоматическое сканирование, проверку конфигурации и ручной анализ результатов. Сканер сравнивает обнаруженные компоненты и их состояние с известными признаками проблем. Специалист подтверждает, соответствуют ли результаты, удаляет дубликаты и ложные срабатывания, оценивает последствия и предлагает действия. Таким образом, экспорт данных сканера не является полноценной оценкой.
Внешнее тестирование показывает внешне доступную часть системы. Внутреннее тестирование изучает условия внутри определенной сети или среды. Тестирование с использованием учетных данных может выявить больше информации о версиях и настройках, чем внешнее наблюдение, но его охват зависит от предоставленных разрешений и успешной авторизации. Неуспешная авторизация сканера не доказывает отсутствие уязвимостей. Выбирайте эти варианты для выполнения задачи, а не предполагайте, что один метод является лучшим.
Тестирование на проникновение: проверка определенного сценария
Тестировщики исследуют целевую систему и пытаются подтвердить путь к достижению определенного результата. Они могут объединять несколько уязвимостей, которые кажутся менее серьезными по отдельности. Работа включает использование инструментов и ручной анализ. Эксплуатация, повышение привилегий, доступ к данным и тестирование реакции защитных средств разрешены только в пределах определенных границ.
Тест не обязательно должен охватывать все устройства и все возможные атаки. Иногда достаточно безопасных доказательств возможного доступа, без копирования реальных данных, чтобы подтвердить риск. Правила проведения определяют глубину. Невозможность воспроизвести атаку в отведенное время не означает, что путь недоступен.
Сравните методы, исходя из условий работы
|
Критерий |
Оценка уязвимостей |
Тестирование на проникновение |
|---|---|---|
|
Основной вопрос |
Какие недостатки были обнаружены, какие они влияют и что нужно исправить? |
Могут ли определенные недостатки или их комбинация достичь поставленной цели? |
|
Область применения |
Согласованный набор активов, услуг и методов доступа. Часто требуется широкое, повторяемое покрытие. |
Согласованные приложения, среды или сценарии. Объем может быть узким или широким в зависимости от задачи. |
|
Метод |
Сканирование, проверка конфигурации и анализ, чтобы определить, применимы ли полученные результаты. |
Исследование сценариев, ручное тестирование и авторизованное подтверждение возможности проведения атаки. |
|
Авторизация |
Необходимы одобрение владельца, границы, методы и начальные условия. |
Требуются письменные правила с явно разрешенными и запрещенными действиями. |
|
Операционный риск |
Активное тестирование также может создавать нагрузку или нарушать работу критически важного сервиса. |
Попытки эксплуатации увеличивают риск последствий; необходимы условия остановки и восстановления. |
|
Результат |
Список проверенных результатов, доказательств, применимости, рекомендаций и ограничений области применения. |
Подтвержденные пути, достигнутые результаты, ограничения, доказательства и рекомендации. |
|
Частота |
Проводить по мере необходимости, в зависимости от рисков, изменений и применимых требований. Автоматизация полезна, но не заменяет анализ. |
Проводить при необходимости тестирования сценария, после существенных изменений и в соответствии с применимыми требованиями. |
|
Основное ограничение |
Не все результаты сканирования являются реальными; неизвестные ошибки и сложная логика могут оставаться незамеченными. |
Время, знания команды и разрешенные действия ограничивают глубину. Полные результаты не гарантируются. |
Размер компании сам по себе не определяет метод. Небольшой разработчик может нуждаться в глубоком тестировании клиентского приложения, в то время как крупная организация нуждается в регулярных оценках для множества устройств. Сравните предложения с одинаковым объемом и ожидаемым результатом. Стоимость зависит от сложности, доступа, ручного труда, составления отчетов и повторного тестирования. Универсальная цена или продолжительность не помогут.
Выберите подходящий метод тестирования
|
Ситуация |
Практический выбор |
Условия для достижения полезного результата |
|---|---|---|
|
Не существует надежного списка уязвимостей для управляемых систем |
Оценка уязвимостей с подтвержденным охватом и применимостью. |
Доступны владельцы активов и люди, способные анализировать и устранять выявленные проблемы. |
|
Доступ к данным других пользователей должен быть протестирован перед запуском важного приложения |
Целевой тест на проникновение с авторизованными сценариями и учетными записями для различных ролей. |
Подготовлена безопасная среда, данные и правила тестирования; разработчики готовы устранять проблемы. |
|
Существуют средства защиты, но их способность блокировать конкретный путь атаки неясна |
Протестируйте согласованный сценарий. При необходимости, отдельно протестируйте обнаружение и реагирование. |
Оценка реагирования включена в задание, с согласованными ролями и методами уведомления. |
|
Существует длинный список известных проблем без назначенных действий |
Сначала проанализируйте, расставьте приоритеты и устраните подтвержденные проблемы. |
Закажите новое тестирование для устранения конкретной неопределенности, вместо того, чтобы заниматься решением известных проблем. |
|
Инфраструктура изменилась или была устранена важная проблема. |
Переоцените область, затронутую инцидентом, или проведите целенаправленное тестирование предыдущего пути атаки. |
Изменения, которые проверяются, и любые связанные с ними зависимости, на которые могло повлиять тестирование, должны быть четко определены. |
После инцидента сначала выполните согласованный план реагирования, сохраните доказательства и ограничьте последствия. Планированное тестирование на проникновение не заменяет расследование. Согласуйте тестирование исправлений и оставшихся путей атаки после стабилизации, чтобы оно не мешало восстановлению и анализу.
Оценка соответствия, программа для внешних исследователей по поиску уязвимостей и тренировка команды безопасности имеют свои собственные цели и правила. Они не являются автоматическими синонимами для тестирования на проникновение. Если клиент ожидает обнаружения или тестирования реакции сотрудников, включите это отдельно в задание, вместо того, чтобы рассматривать его как обязательную часть каждого теста.
Подготовьте область и безопасные условия работы.
Получите разрешение от уполномоченного владельца системы. Для внешних услуг и облачной инфраструктуры проверьте условия предоставления услуг. Договор компании с тестировщиком не дает разрешения на тестирование ресурсов другого лица. Укажите разрешенные адреса, приложения, учетные записи и среды. Укажите исключения, запрещенные воздействия и процесс утверждения изменений области отдельно.
- Укажите цель, даты, временной интервал, начальную точку и информацию, которую получает команда заранее.
- Определите, разрешены ли активные проверки, попытки эксплуатации, тестирование персонала и доступ к данным. Отсутствие запрета не заменяет разрешение.
- Назначьте оперативные и аварийные контакты, условия немедленной остановки и процесс возобновления.
- Согласуйте ограничения нагрузки, меры восстановления и подготовку резервных копий, если тестирование может повлиять на работу. Сначала обсудите безопасный метод тестирования для критически важных систем.
- Опишите защиту результатов, хранение доказательств, предоставление отчетов и удаление временного доступа и артефактов. Пароли и конфиденциальные данные не должны отображаться в общедоступных отчетах.
Объем предоставляемой информации также влияет на результат. Тестирование без внутренних моделей дизайна ограничивает знания, но обнаружение требует времени. Предоставление архитектуры и доступа позволяет более глубокое тестирование выбранных условий. Это не шкала качества. Подход должен соответствовать вопросу клиента. Записывайте предоставленную информацию и активные ограничения, чтобы результаты можно было сравнить.
Согласуйте отчет и проверьте результаты путем подтверждения устранения проблем.
Какие результаты должны содержать
- Краткое заключение для ответственного лица: что было протестировано, что было обнаружено и какое решение требуется.
- Фактический объем, даты, методы, доступ, исключения и неудачные проверки. Не протестированные активы должны оставаться видимыми в отчете.
- Для каждого обнаруженного факта: затронутый актив, условия, вызвавшее проблему, доказательства, уровень уверенности и возможные последствия.
- Рекомендации с четко определенным ожидаемым эффектом. Тестирование на проникновение также требует описания подтвержденного пути и результата, достигнутого в пределах разрешенных границ.
- Процесс уведомления о критических обнаружениях во время тестирования, критерии повторного тестирования и правила предоставления подробного технического отчета.
Техническая серьезность помогает сравнивать обнаруженные факты, но не заменяет оценку их важности для конкретной системы. Приоритет устранения также учитывает доступность пути атаки, подтвержденное использование, роль актива и существующие ограничения. Поддерживайте подробную матрицу приоритетов отдельно. Задача тестирования должна обеспечивать достаточно доказательств для ее заполнения.
Кто является владельцем работы после предоставления отчета
Назначьте владельца для каждой подтвержденной проблемы и исполнителя для ее решения. Согласуйте сроки, зависимости и безопасный период изменений. Если выявление вызывает споры, запросите проверку применимости и сохраните обоснование. Отклоняйте ложные срабатывания на основе доказательств, а не из-за неудобства устранения. Документируйте любую невозможность немедленного изменения как временное решение с указанием владельца и даты пересмотра.
После внесения изменений протестируйте соответствующий компонент и условия, которые ранее вызывали проблему. Для подтвержденной цепочки атак убедитесь, что путь к цели был удален, а не только одно обнаруженное нарушение. Протестируйте работу приложения отдельно. Повторное тестирование может подтвердить конкретное исправление, но не делает всю среду навсегда безопасной. Верните результаты в стандартный процесс управления уязвимостями.
Подтвердите частоту тестирования и необходимые форматы в соответствии с применимыми контрактами, требованиями и их объемом. Не делайте вывод о том, что каждая компания обязана, просто из названия отрасли или стандарта. Запросите точное требование и критерии принятия перед выбором поставщика. Оценка уязвимостей и тестирование на проникновение могут дополнять друг друга, но одно не автоматически удовлетворяет требование другого.
Если вам необходимо получить подтвержденное представление о технических уязвимостях, обсудите задачу с ответственными лицами через страницу Оценка безопасности. Согласуйте объем, начальную информацию и ожидаемые результаты оценки.
