Безопасная и измеримая среда для разрешённого тестирования на проникновение

1. Сразу определите цель теста и полномочия

Сначала сформулируйте вопрос: могут ли два клиента видеть записи друг друга, поддаются ли проверке действия администратора, существует ли ненужный доступ к интерфейсу управления филиалом? Узкие измеримые вопросы связывают результат тестовой команды с конкретной задачей разработчика или администратора сети. Отчёт сканирования, анализ исходного кода и тестирование на проникновение имеют разный объём; не описывайте их в закупочной документации как одну и ту же услугу.

NIST SP 800-115 рассматривает планирование оценки безопасности, анализ результатов и улучшения; приложение B содержит исходный шаблон правил проведения работ. [1] В письменном разрешении должны быть ясны владелец системы, активы в объёме теста, время, разрешённые действия, исключённые области, правила работы с данными и лицо, уполномоченное остановить тест. При использовании облака или сторонней услуги нужно отдельно проверить соответствующие правила тестирования этих поставщиков.

2. Отделите учебную лабораторию от рабочих систем

Контролируемая лаборатория может состоять из тестовых устройств, целевого приложения и средств наблюдения. Отдельная виртуальная сеть и правила доступа должны препятствовать переходу в рабочие системы, а внешние соединения — ограничиваться нужными сервисами. Административный доступ также следует отделить. Метка виртуальной машины или другой диапазон IP сами по себе не доказывают изоляцию; проверьте как разрешённые, так и подлежащие блокировке пути.

Для обучения можно использовать приложения с намеренно внесёнными уязвимостями; OWASP Juice Shop — один из таких учебных проектов. [2] Наполнять такую цель клиентскими данными или размещать её на публичном рабочем сервере — неподходящий способ построения лаборатории. Создайте среду под своим управлением с ограниченным доступом. Учебные навыки не дают разрешения тестировать сторонние системы. Это руководство также не содержит инструкций по тестированию внешних систем.

3. Данные и учётные записи должны принадлежать лаборатории

Работайте с синтетическими клиентами, заказами и пользователями. Если реальные данные необходимы, используйте согласованный с ответственным за данные метод и узкий круг доступа; по возможности применяйте маскирование или сокращение данных. Действующие рабочие API-ключи, пароли и платёжные сведения нельзя переносить в тестовую копию. У тестовых учётных записей должны быть определены владелец, роль и срок закрытия.

Для проверки полномочий нужны записи с разными ролями и у разных условных клиентов. Подход OWASP к тестированию авторизации помогает свести ожидаемые разрешения между ролями и операциями в ясную матрицу. [3] Например, если роль должна читать только собственную запись, зафиксируйте результат проверки вместе с соответствующей записью журнала приложения. Цель — не получить данные реального человека, а на контролируемых данных проверить, действует ли заданная граница.

4. Подготовьте воспроизводимое исходное состояние и наблюдение

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

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

5. Находка, исправление и повторная проверка в одной цепочке

OWASP Web Security Testing Guide связывает тестирование безопасности с жизненным циклом разработки; один инструмент не покрывает все проблемы безопасности. [4] В отчёте указывайте не только критичность, но и затронутый рабочий процесс, предварительные условия, наблюдавшийся результат и предлагаемый контроль. Резюме для руководства должно помогать принимать решения, а техническое приложение — давать уполномоченной команде достаточно ясности для повторной оценки находки.

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

6. Проверьте перед началом работ

Техническая работа не должна начинаться, пока не готовы перечисленные ниже записи. Если один из пунктов меняется, владелец объёма и исполняющая команда должны использовать один актуальный документ.

• Есть ли письменное разрешение, перечень активов, временной интервал и лицо для остановки теста?
• Подтверждены ли условия сторонних и облачных услуг?
• Ограничен ли доступ лаборатории к рабочим системам и ненужным внешним целям?
• Готовы ли синтетические данные, отдельные тестовые записи и исходная конфигурация?
• Определены ли ответственные за доступ к доказательствам, хранение, очистку и откат?
• Явно ли включены в объём отчёт, исправления и результаты повторной проверки?