Прочитал недавно одну чрезвычайно здравую мысль . Но речь не о ней, а о примере, который был приведен в блоге. История с тюнингом Хаммера очень напоминает то, как некоторые компании проводят тесты на проникновение (pentest) .
Например, компании необходимо (ну приспичило) выполнить проверку эффективности используемых ею средств обеспечения информационной безопасности. Для этого существует специальный комплекс мероприятий, тест не проникновение, в ходе которого специально обученные (обычно сторонние) специалисты в разных областях ИБ имитируют действия злоумышленников с целью скомпрометировать критичные ИТ-системы компании-заказчика. Естественно, все происходит вполне легально, по предварительной договоренности. Как правило, тест заканчивается по достижении определенной заранее оговоренной цели, например после получения доступа к критичной БД или овладения административными правами на файловом сервере. Или же по истечении срока достижения этой цели, такое случается реже.
"Тест на проникновение" и "исследование уязвимостей" - понятия смежные, схожие, но все-таки различные. В то время, как исследование уязвимостей включает в себя сбор информации, анализ, классификацию и поиск путей предотвращения всех (в идеале) возможных угроз безопасности компании, тест на проникновение - это воплощение реалистичного сценария по использованию всех уязвимостей, которые приведут нас к поставленной цели - вкусной информации заказчика. Но при этом выбор уязвимостей, используемых в ходе теста, подрядчик оставляет за собой. Иначе о какой объективности может идти речь?
На практике все происходит несколько иначе.
Подрядчик является к заказчику на предварительную встречу. У подрядчика при себе готовый шаблон договора, который содержит (как минимум):
- формальное разрешение заказчика на проведение теста;
- рамки, которыми ограничен подрядчик, а также ответственность, которую он несет за их несоблюдение;
- соглашение о неразглашении конфиденциальной информации.
И тут начинается самое интересное: правка "рамок" заинтересованными лицами со стороны заказчика. Подрядчику разрешается провести тест в рабочее время, предварительно уведомив ИТ/ИБ-департамент заказчика. Также, из фронта работ исключаются социальная инженерия, проверка физических контролей, инспекция сложности паролей. В ходе теста подрядчику запрещается использовать вредоносное (с точки зрения заказчика) ПО, а также каким-либо образом взаимодействовать с бизнес-критичными системами.
После некоторой возни, подрядчик формирует "кастрированный" договор, в котором ему предоставляется эксклюзивная возможность протестировать только сервисы заказчика, доступные из Интернет, при помощи заранее оговоренных средств тестирования и эксплуатации уязвимостей, что едва ли составляет 5% первоначального коммерческого предложения. Естественно, такую задачу пентестом назвать уже сложно, и ни о какой объективной оценке ситуации речь идти не может. Но времена сейчас сложные, и подрядчик сцепив зубы принимается за "работу" и завершает ее красочным отчетом с диаграммами и рекомендациями.
Главная ошибка, допущенная заказчиком, состоит в допуске заинтересованных лиц к формированию фронта работ. В идеале о предстоящем пентесте должно знать только высшее руководство компании-заказчика. У корпоративного ИТ и/или ИБ существует очевидный конфликт интересов, и он сделает все от него зависящее для того, чтобы сократить объем работ провайдера до минимума. А в идеале от них нужен лишь ответ на вопрос, готовы ли они к пентесту. Положительный ответ - правильный. Отрицательный - не очень, но спасибо за правду. В таких условиях тестирование проводить еще рано, зато самое время провести исследование уязвимостей и составить план их исправления.
