Эта статья для тех, кому пришлось столкнуться с проблемами безопасности своих ресурсов, в первую очередь — корпоративной сети либо веб-приложений, но они не имеют четкого представления о том, как это тестирование осуществляется на практике.

В каких случаях может понадобиться тестирование безопасности?

Вариантов, разумеется, может быть множество, вот лишь некоторые из них:

  • после проведенной кибер-атаки либо ее попытки;
  • при наличии корпоративной сети или веб-приложения, тестирование безопасности которых проводилось давно либо не проводилось вообще;
  • после добавления новой функциональности в уже имеющийся продукт;
  • при значительном изменении топологии корпоративной сети;
  • при миграции приложения из тестовой среды в производственную;
  • при наличии требований отраслевых стандартов (PCI DSS, HIPAA).

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

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

Итак, при всем осознании важности проведения тестов безопасности, что же делать дальше? Как определить, какой именно вид тестов безопасности вам нужен? Здорово, если есть требования к проверке безопасности системы, сформулированные, к примеру, внешним аудитором. В таком случае определить перечень работ по тестированию достаточно просто. А что делать, если требований к безопасности нет, а необходимость ее проверки есть? Часто люди приходят в компании, оказывающие услуги по тестированию, со следующим запросом: «У меня есть сайт/сеть, хочу протестировать безопасность!» Далее специалисты начинают уточнять детали запроса, что иногда занимает несколько дней. Гораздо проще изначально сформулировать детальный запрос, тем самым сэкономив ценное время. О том, как можно детализировать свои нужды в тестировании безопасности, поговорим далее.

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

  1. цели тестирования;
  2. данные о системе, которые можно предоставить аудиторам;
  3. точка входа в систему (актуально только для тестирования локальных сетей).

Исходя из целей, тестирование безопасности делится на два вида: тестирование на проникновение (англ. Penetration Testing) и оценка защищенности (англ. Vulnerability Assessment).

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

Таким образом, если главное выяснить велика ли опасность реального взлома злоумышленниками, то тестирование на проникновение — это ваш вариант.

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

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

Рассмотрим небольшой практический пример, наглядно показывающий отличие тестирования на проникновение от оценки защищенности.

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

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

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

Очевидно, что чем «белее» ящик, тем более полную информацию о защищенности вашей системы вы сможете получить по завершении тестирования. Однако тем большим количеством важной информации вам придется поделиться с третьей стороной и тем затратнее по времени и финансам будет проведение тестирования.

Последний критерий — точка входа в систему. Этот критерий учитывается только при проведении тестирования на проникновение на уровне локальной сети. Здесь может быть два варианта:

  • внешний тест на проникновение — тестам подвергаются только внешние IP-адреса компании, доступные из Интернета;
  • внутренний тест на проникновение — тест проводится внутри корпоративной сети; тестировщикам предоставляется выделенное рабочее место в компании либо доступ во внутреннюю сеть по VPN.

Как правило, внутренний тест на проникновение проводится только при наличии соответствующих требований в отраслевых стандартах либо если необходимо проверить уровень защищенности от так называемых инсайдерских атак, т. е. осуществляемых сотрудниками самой компании.

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

Автор статьи — инженер департамента тестирования безопасности OOO «Технологии качества» (бренд A1QA).