Как справиться с тестом на проникновение
Тест на проникновение, или тест на проникновение, как его иногда называют, включает в себя выполнение серии тестов, чтобы определить, уязвимы ли ИТ-ресурсы организации для атаки. Хотя квалифицированная команда ИТ-безопасности может выполнить тест на проникновение, такие тесты обычно передаются консалтинговой фирме, которая специализируется на тестировании на проникновение.
Организации крайне редко получают отличные оценки по тесту на проникновение. Если тестировщики на проникновение ничего не находят, это означает либо то, что организация проявила чрезмерную бдительность в отношении своей кибербезопасности, либо то, что команде, проводящей тест, не хватает навыков для проведения действительно всестороннего тестирования.
В подавляющем большинстве случаев тест на проникновение выявляет уязвимости. В некоторых случаях может быть найдено всего несколько уязвимостей, но в других случаях группа тестирования может составить длинный список уязвимостей. Так что же делать организации, если она получила отрицательный тест на проникновение? Для начала ИТ-персонал организации должен провести долгую и откровенную дискуссию с группой тестирования.
Есть две основные вещи, которые должны быть достигнуты в ходе этой дискуссии.
Во-первых, ИТ-персонал организации должен понимать уязвимости, о которых сообщалось. Это означает, что группа тестирования должна объяснить, что влечет за собой конкретная уязвимость, почему она важна и что группа тестирования рекомендует делать для устранения уязвимости. ИТ-персонал организации должен делать подробные записи во время этого обсуждения, чтобы задокументировать технические детали и рекомендации.
Второе, что организация должна сделать во время встречи с группой тестирования на проникновение, — это подтвердить результаты тестирования. В идеале группа тестирования должна быть в состоянии показать вам, как они обнаружили уязвимость, или, по крайней мере, дать вам список шагов, которые вы можете выполнить, чтобы убедиться, что уязвимость существует. Это не означает, что команда тестирования на проникновение не заслуживает доверия. Просто перед тем, как вкладывать ресурсы в устранение уязвимости, рекомендуется убедиться, что вы можете протестировать уязвимость. В противном случае вы не сможете сказать, было ли ваше решение эффективным.
После того, как организация провела предварительную встречу с группой тестирования на проникновение и независимо проверила уязвимости, перечисленные в отчете группы, следующим шагом в этом процессе является разработка плана исправления.
Одним из первых шагов при разработке плана исправления является определение приоритетности уязвимостей. Некоторые из уязвимостей, обнаруженных группой тестирования, вероятно, будут относительно незначительными, в то время как другие могут быть критическими. Критические уязвимости — это те, которые допускают удаленное выполнение кода, могут раскрывать данные или могут использоваться для компрометации учетной записи пользователя. Такие уязвимости следует устранять до любых менее значительных уязвимостей.
Помните, что хотя группа тестирования добросовестно дает рекомендации по устранению проблем, эти решения могут не обязательно подходить для вашей организации. Поэтому важно провести некоторое тестирование и тщательно рассмотреть влияние предлагаемых решений, а не слепо выполнять рекомендации тестировщика. Например, группа тестирования на проникновение может порекомендовать установить определенный патч безопасности, но этот патч может вызвать проблемы с некоторыми вашими приложениями. Вот почему тестирование так важно.
Еще одно важное соображение заключается в том, что рекомендации группы тестирования часто можно улучшить, приняв стороннее программное обеспечение.
Предположим, например, что тест на проникновение показывает, что политика паролей Active Directory в организации неадекватна. В такой ситуации организация может легко создать или изменить несколько параметров групповой политики, чтобы привести свою политику паролей в соответствие с рекомендациями группы тестирования. Тем не менее, эти рекомендации, вероятно, будут подпадать под ограничения собственных настроек групповой политики. Групповая политика может, например, установить минимальную длину пароля и частоту смены, но у нее нет возможности проверить, известно ли, что конкретный пароль был скомпрометирован. Таким образом, организация, которой необходимо исправить свою политику паролей, скорее всего, не увидит «проверить скомпрометированные пароли» в списке рекомендаций группы тестирования. Очевидно, что тестирование скомпрометированных паролей — хорошая идея, но это выходит за рамки собственных возможностей Active Directory, поэтому группа тестирования может не рекомендовать его.
Программное обеспечение сторонних производителей может помочь организации не только устранить уязвимости, перечисленные в отчете о тестировании на проникновение, но и повысить уровень безопасности, значительно превышающий минимальный уровень исправления, рекомендованный группой тестирования.
Например, политика паролей Specops может помочь организации определить, не были ли скомпрометированы какие-либо пароли ее пользователей. Он делает это, сравнивая эти пароли с базой данных миллиардов паролей, которые, как известно, были утекли. Кроме того, политика паролей Specops может помочь в создании правил паролей, выходящих за рамки правил, которые можно определить с помощью собственных параметров групповой политики. В то время как групповая политика может использоваться для обеспечения соблюдения требований к сложности пароля, политика паролей Specops может использоваться для блокировки определенных слов, последовательных символов, добавочных паролей или паролей, содержащих часть предыдущего пароля. Кроме того, пользователи получают обратную связь в режиме реального времени всякий раз, когда они меняют свой пароль, что снижает разочарование и количество обращений в службу поддержки.