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