Содержание статьи
Алексей Синцов
Известный white hat, докладчик на security-конференциях, соорганизатор ZeroNights и просто отличный парень. В данный момент занимает должность Principal Security Engineer в компании Nokia, где отвечает за безопасность сервисов платформы HERE. alexey.sintsov@here.com
Проблемы рынка номер 1
Уже прошли времена, когда пентест был услугой редкой, для «особых клиентов» от «особых исполнителей». Причем прошли они давно, теперь это стандартная услуга, которую не предлагает разве что ленивый. Это означает, что спрос растет, — этому способствует и общая озабоченность проблемой «взлома», и грамотный маркетинг на рынке, и подливание масла в огонь регуляторами. Вместе с этим растет и энтропия. На рынке появляется множество некачественных и откровенно жульнических услуг, включая и этот ваш пентест. Ухудшает ситуацию и такая же энтропия «специалистов по ИБ» со стороны заказчиков/покупателей — порог вхождения в это нечто под названием «ИБ» становится довольно низким с обеих сторон. Любой плохой админ, научившийся запускать Nmap и вставлять кавычку, — пентестер. Любой выпускник вуза, который прочитал про ISO 27001 и полистал блоги о ПДн, — специалист по ИБ. В этом непонятном котле под названием рынок они чудесно варятся друг с другом. Я бы мог ныть, мол, как все плохо, один я тут в белом стою, но на самом деле все логично и является закономерным развитием того, что все мы делаем. Просто кроме отличного качественного товара из‑за нехватки ресурсов и из‑за высокой потребности рынок (рынок кадров, услуг, товаров — неважно) заполняет откровенный треш. Ныть по этому поводу бессмысленно и глупо. На самом деле такое положение даже на руку тем, кто предлагает действительно качественные услуги, — ведь все познается в сравнении. Однако порой происходят обидные казусы, ведь в конечном счете действует правило «покупатель всегда прав, даже когда не прав». Это означает, что продавец в ответе даже за некачественного клиента. Пример из блога А. Лукацкого. Клиент заказал пентест. По его итогам заказчик получил отчет, в котором сказано что‑то типа «В результате проделанной работы уязвимостей обнаружено не было». И все, разошлись как в море корабли. Вроде бы все хорошо, в отчете и в договоре все было грамотно описано: список работ, что сделано и результат — ничего не найдено. Как это прочитал клиент: «Спите спокойно, ваш сайт неуязвим». На следующий день в интернете бомба: новая уязвимость — Heartblead, которой подвержен в том числе и сервис заказчика. Заказчик в шоке: как так?! Вот он, отчет, где сказано, что уязвимостей нет, а получается, что есть, причем все плохо. Очевидно, заказчик не понимал, что заказывал, за что он платит деньги и что вообще делали эти люди. Но так как ему «надо было купить какой‑то там пентест», то он это честно сделал. Поэтому очень важно понимать, что ты покупаешь и за какой результат ты платишь деньги.
Совет 1. Изучи список работ, которые обязался сделать пентестер, подумай, нужно ли тебе это.
Проверяют ли на наличие только известных уязвимостей? Какими методами? Означает ли это только скан нмапа + Nessus, или исполнитель будет анализировать отпечатки и поведение системы и выявлять неявные сервисы? Какими методами он ищет уязвимости в веб‑приложениях? Как работает с софтом третьей стороны — библиотеками, демонами, сервисами и прочим, проводятся ли работы с клиентским приложением — если у тебя ActiveX / Java Applet или толстый клиент? Анализируется ли логика системы, приложений? Используется ли динамический анализ при тестировании — фаззинг, реверс‑инжиниринг — того же ActiveX?
Так можно уточнять довольно много и копаться все глубже и глубже. Чем больше описано — тем лучше видно, что ты покупаешь. При этом главная проблема — осведомленность и образование заказчика. В том примере из блога подробное описание было. Но заказчик не понимал — можно ли так найти Heartbleed или нет. Заказчик не осознает, что для того, чтобы можно было толкать претензии по Heartbleed, должна быть указана работа «Динамический анализ и анализ исходных кодов сторонних библиотек. Список сторонних библиотек: OpenSSL. Методы динамического анализа: фаззинг прокола handshake» и так далее и тому подобное. При этом клиент вообще должен знать, что такие работы существуют. Конечно, цена услуг выросла бы более чем в десять раз, но когда клиент совсем не понимает, что покупает, он легко обижается, что заплатил за пентест 5 тысяч долларов, а пентестеры не нашли дырку на миллион баксов.
Хороший же исполнитель всегда старается донести до заказчика, что именно входит в список услуг, а что нет, чтобы его ожидания были реальны и соответствовали деньгам и потраченному времени. Другое дело, что возможна ситуация, когда исполнитель не понял, что заказчик — днище:
Исполнитель: Вот наши услуги. То есть мы проверим ваш сервис на все уязвимости, которые можно найти за это время этими методами, ОК?
Заказчик: Заткнись и возьми мои деньги!
Исполнитель: Договорились!
Заказчик вообще не готов к техническим разговорам, а это ведь только верхушка айсберга! Желательно, чтобы исполнитель более доходчиво объяснил, что за пять килобаксов и четыре дня работы найти все просто нельзя.
Совет 2. По возможности проверяй то, что обязался делать пентестер.
Одна из основных проблем — заказчик не знает, что действительно делал пентестер. Может, только сканер запустил, а руками и головой не работал совсем. Что‑то проверить нельзя, но многое можно: смотри логи веб‑сервера, смотри активность тестовых аккаунтов, статистику запросов к СУБД и так далее. Твои логи — твой главный советчик.
Собственность клиента
Иногда клиенты хорошо представляют, зачем им нужен пентест. Они хотят проверить свои системы ИБ, контрмеры, персонал, а иногда — вендора или интегратора. Но что собой представляет получаемый отчет? Как правило, описание крутых хаков, векторов атак, примеры успешного использования уязвимостей и тому подобное. Но есть еще кое‑что: список уязвимостей. Для простоты я разделю их на несколько категорий:
- Уязвимости в результате ошибок конфигурации.
- Уязвимости, допущенные на стадии разработки/архитектуры в кастомном продукте (0day).
- Уязвимости, допущенные на стадии разработки/архитектуры в стороннем продукте (0day).
- Уязвимости пункта 3, только известные сообществу и вендору (1day).
Очевидно, что уязвимости класса 4 не являются собственностью клиента или исполнителя — это всеобще известная информация. Первый и второй класс уязвимостей представляет собой собственность клиента, но вот что делать с третьим классом? Чья это собственность?
Совет 3. Уточняй в договоре то, что покупаешь.
Не просто какой‑то там отчет, но и информацию, не подлежащую разглашению, например об уязвимостях в 3rd party продуктах, или наоборот — исполнитель поможет скоординировать работу с вендором. Конечно, это зависит от целей и твоих желаний, но это надо документировать и обговаривать. Это может быть неважным пунктом для одних и интересным для других.
Один заказчик как‑то сказал: «Опять нашли 0day в VMware за наш счет, нам неинтересно помогать разработчикам VMware...». То есть он вообще был не заинтересован в том, чтобы искали уязвимости в софте сторонних вендоров (что логично и правильно). Тогда как другой заказывает пентест, специально чтобы посмотреть, что втюхал ему вендор или интегратор, и ему нужны эти уязвимости, чтобы «давить» на них. Пентестер будет работать эффективнее, если будет знать твою цель. Кроме того, тут опять проклевывается этическая составляющая. Допустим, пентестер нашел 0дей в ДБО вендора А, в банке Б. Он потратил свое время и деньги банка Б. Все круто, но потом он пошел в банк В, который пользуется тем же решением А. Не тратя ни копейки, пентестер сообщает об этой же уязвимости банку В. Таким образом, банк Б частично (процентов на 80) помог банку В за свой счет. Но кроме того, банк В знает уже и о проблемах банка Б, и хорошо, что всем на это плевать, и конкуренция у нас здоровая, и банки друг друга поддерживают. Но я за то, чтобы документировать собственность на такого рода уязвимости в договоре, — мелочь, зато профессионально :).
И еще много вопросов…
Рынок постепенно взрослеет, и многие вопросы не поднимаются ни заказчиком (не дозрел), ни исполнителем (не в его интересах либо тоже не дозрел). Я надавал тут каких‑то сложных советов, это правда, и главный аргумент: если мы знаем все эти детали и можем вот так проверять работу пентестеров, то зачем нам пентестеры, мы сами все можем? Но это лишь частично так. Отличить сканер от работы человека и понять логику того, что делал аккаунт в приложении, может любой инженер, хотя бы чтобы определить явных жуликов, потом, этот инженер получит неплохой опыт :). И да — нужно повышать квалификацию своих ИБ‑шнков, а не надеяться на честность консультанта. Я понимаю, что не все могут позволить себе нанять инженера, который смыслит что‑то в ИБ, но если безопасность для вашего бизнеса будет становиться все большим приоритетом, то такие кадры окажутся очень ценными и полезными для всей компании. Потом в любом случае, при большом периметре и большом количестве проектов, нанимать пентестеров, интеграторов или покупать решения по ИБ придется. И если у вас в команде будет человек, который сможет определить необходимость и эффективность, а также координировать такие работы, — это будет намного эффективнее, чем если это будут делать консультанты и интеграторы, ведь мотивация и цели будут разными.
Так что вывод мой таков: рынок ИБ будет давать более качественные услуги и уменьшать количество буллшит‑услуг в пропорциональной зависимости от роста культуры и квалификации заказчиков. То есть заказчики должны не ждать, когда вдруг рынок станет «хорошим», а самим становиться лучше.
Удачи нам всем!
