24 Июня, 2014

Об этике пентестера/ИБ-аудитора

Алексей Лукацкий
Нахожусь в культурной столице нашей необъятной Родины. Общаюсь с коллегами, друзьями, заказчиками... И вот один из заказчиков поднимает интересную тему, можно даже сказать философскую. Про этику пентестера. А навеяно это было нехорошей ситуацией. Известная питерская фирма, занимающаяся аудитом, провела пентест инфраструктуры заказчика, включая и его Web-сайт, предназначенный для электронной коммерции. Как водится по результатам был выдан отчет, что все чисто, никаких серьезных не обнаружено, спите спокойно. И вот спустя несколько дней после сдачи отчета в Интернете публикуется информация об уязвимости Heartbleed, существовавшей много лет и только недавно ставшей достоянием гласности. Банальная проверка Web-сайта, использующего OpenSSL, показывает, что дыра в нем присутствует в полный рост. Как ни странно, в сданном питерским пентестером отчете, о дыре ни слова. Вот на этом фоне и возникла у нас непростая дискуссия об аудите, об этике, о распальцованных аудиторах, о состоянии отрасли...

Мне иногда удается посмотреть различные отчеты о результатах пентестов у разных заказчиков. В том числе и проверке Web-сайтов, порталов и т.п. решений. Нигде я не помню упоминаний Heartbleed. Отсюда закономерный вопрос или даже несколько. В последнее время некоторые уязвимости, присутствовавшие в софте много лет, получили скандальную известность (Heartbleed, Cupid и т.п.). Почему они не обнаруживаются в результате пентеста? Если пентестер так крут, как он себя считает, то почему он не нашел дыру? Или он просто обычный сканер, ищущий только известные уязвимости, запускает?

Заказчику я посоветовал при очередной встрече с питерским ИБ-аудитором задать несколько вопросов:
  • В скольких ваших отчетах, составленных до широкого обнародования, вы информировали заказчиков об этих критически важных уязвимостях? Маркетинговые службы аудиторских/пентестерских компаний работают хорошо и регулярно публикуют отчеты об очередном ИБ-апокалипсисе, мобильной угрозе и т.п. Почему в отчетах про безопасность ДБО, Web-сайтов и т.п. про Heartbleed ни слова?
  • Если вы не находили ни разу Heartbleed, то это потому что вы не анализировали системы с SSL? А как можно анализировать Web-сайт с SSL и обойти ее вниманием?
  • Или вы умалчивали о найденной уязвимости? А может вам кто-то приказал молчать о ней?
  • Или вы не придали этой дыре значения?
  • А может вы просто не знали про нее и не смогли ее обнаружить?
Допустим что аудитор, несмотря на звание "№1 в аудите безопасности", в не способен был обнаружить Heartbleed. Ну бывает, никто не идеален. Но где гарантия, что злоумышленники тоже не знали об этой уязвимости и не воспользовались ею?

И вот тут мы и вступаем на путь обсуждения этики аудита ИБ. Аудитор дал заключение, что у заказчика все чисто (на момент аудита) и нет проблем с ИБ. А потом оказывается, что на момент пентеста у клиента была серьезная дыра, ставшая публичной уже после подписания акта сдачи-приемки работ. И в каком положении находится аудитор? Является ли он дезыинформатором или нет? Должен ли он признать свою некомпетентность или халатность или несовершенство? А не должен ли он за свой счет провести повторный аудит? А где гарантия, что при повторном аудите он что-то найдет (люди те же, подходы те же, инструменты те же)? Ох, непростые вопросы подняты были на встрече с заказчиком. Но и они еще не конец беседы.

В конечном итоге, мы вновь возвращаемся к исходному вопросу, который нередко задается на разных мероприятиях и на разных Интернет-ресурсах, но так и не получает ответа. Что такое аудит или пентест? В чем сухой остаток от его проведения? Остановитесь на мгновение и попробуйте ответить себе на этот вопрос.

Отличается ли понимание "аудита" заказчика и исполнителя? Может быть для исполнителя это просто показ потенциального пути взлома? Или демонстрация своей крутизны (смотрите, я крутой, я взломал мобильный банкинг)? Или это единственное, что исполнитель может делать? Кстати, именно поэтому я не люблю "хакерские конференции". При всем интересе к тому, что там показывается и рассказывается, они однобоки, т.к. эксплуатируют только одну сторону - демонстрируют проблемы, но не ее решение (на это либо времени не остается, либо "хакер" просто не знает, как бороться с тем, что он накопал). Многие аудиторы/пентестеры живут по тому же принципу. Это как модель угроз, которая не содержит описания мер, нейтрализующих актуальные угрозы. Кому нужна такая модель? Но вернемся к этике аудита.

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

Не пора ли вводить профессиональную ответственность аудиторов ИБ? У обычных аудиторов есть свой кодекс  профессиональной этики. Может и в нашей отрасли пора такое же вводить? Может пора сдуть пыль с проекта  концепции аудита ИБ, разработанного ФСТЭК, дополнив ее немного? Или лучше оставить все как есть? "Безответственный консалтинг", не предполагающий никаких гарантий и никакой ответственности?..

ЗЫ. К разработчикам средств защиты это тоже относится, но там немного иная концепция. Да и подходы по решению этой "этической" проблемы существуют. Про них поговорим завтра.
или введите имя

CAPTCHA
doom
24 Июня, 2014
Нормальный аудит должен быть на соответствие чему-то. Точка. Тогда не будет недопонимания в отношении результатов аудита. А все эти попытки выявить все-все-все уязвимости заведомо бесплодны - понятно, что все не выловят. Понятно, что часть невозможно закрыть (если они by design), а еще куча появится с установкой новых версий софта и т.п. (или просто обнаружат новые уязвимости). Если короче - чудес не бывает. С аудитором надо на берегу обговаривать, что он сделает и какие цели у всей этой движухи (ну и не надо ждать, что за 100 тыс. руб. кто-то полезет исследовать уязвимости всех библиотек, вспомогательных сервисов и т.п. при анализе защищенности web-сайта).
0 |
  • Поделиться
  • Ссылка
Сергей Городилов
24 Июня, 2014
Алексей, давайте повесим на ответственность аудиторов все неизвестные на данный момент уязвимости, коих пруд пруди, тысячи каждый год, которые существовали несколько лет до того!? И тогда аудитом перестанут заниматься! Как могло быть известно аудитору об уязвимости Heartbleed, если о ней не знал никто, даже поставщики сканеров? Опубликовали - ВСЕ В ШОКЕ. Может Вы назовете того, кто знал о ней? Сейчас всего ДВА месяца прошло с момента публикации. Сколько отчетов было выпущено за это время и которые Вы видели? Я так понимаю, что в Вашей заметке речь об аудите, который был выполнен до известности Heartbleed. Так об чем речь тогда? Решение такое: аудит должен касаться известных уязвимостей, лучше с указанием конкретных границ поиска, классов, что и должно быть прописано в ТЗ. Поиск неизвестных уязвимостей в софте - это другого уровня проблема, уровня SDL и др., но не аудита.
0 |
  • Поделиться
  • Ссылка
Александр О
24 Июня, 2014
Алексей, Вы удивляете, у Вас нет понимания, что такое уязвимость Например, вы не могли измерить в 16 веке радиационный фон сарая с дровами, потому что не открыли атомную энергию. Хотя инструменты для обнаружения радиационного фона теоретически можно было построить. Но радиационный фон - был, а его не обнаруживали. Так и уязвимости, бывают которые детектятся, вооружившись более-менее доступным инструментарием и знаниями, а бывают которые как новый вид энергии - хоть ты какой ученый, не откроешь, только случайно, опять же в течение несколько лет.
0 |
  • Поделиться
  • Ссылка
Алексей Лукацкий
24 Июня, 2014
Коллеги, вы похоже не догоняете сути заметки. В ней не идет речь о том, что аудитор всевидящ Речь об определении правил игры ДО ее начала. doom прав - на берегу надо все оговаривать. Scope, глубину проверки, ответственность или ее снятие, гарантии и т.д. Вот тогда аудит будет профессиональным, а поведение аудитора этичным.
0 |
  • Поделиться
  • Ссылка
Алексей Лукацкий
24 Июня, 2014
DISCLAIMER: термины "аудит" и "пентест" в контексте данной заметки считать синонимами!
0 |
  • Поделиться
  • Ссылка
Владимир Кочетков
24 Июня, 2014
>Остановитесь на мгновение и попробуйте ответить себе на этот вопрос. Не знаю, как там у тех, кто является "№1 в аудите безопасности" (и, к слову, знают ли они, что в ИТ нумерация традиционно ведется с нуля? =/), но вообще - это достаточно формализованные понятия. Есть аудит, который, как справедливо заметил doom, должен быть анализом на соответствие конкретным критериям по конкретной методике, что позволяет воспроизвести его результаты третьей стороной, в случае необходимости. И тут тяжело себе представить ситуацию, когда _компетентный_ аудитор безоговорочно вынес недостоверную оценку соответствия какому-либо критерию. А пентест, являющийся блэкбокс-методикой анализа защищенности, целью которого является построение максимально развесистого дерева атак в рамках заранее оговоренного скоупа, которое выполняется посредством имитационного моделирования действий потенциального атакующего. Пентест дает приблизительный ответ на один вопрос: что из себя будет представлять дерево атак в том случае, если квалификация атакующего будет не ниже квалификации пентестера и, если он будет располагать определенным объемом вводной информации и некоторыми, ограниченными ресурсами. Результаты пентеста, как и результаты любого другого имитационного моделирования носят статистический характер и тем точнее отражают суровую реальность, чем больше человек принимало в нем участие + чем больше времени им было отведено -> тем больше итераций они успели завершить. Разумеется, если на пентест было выделено 100 человекочасов, то не исключена возможность того, что на 101-ый реальный атакующий сможет проковырять то, что не смогли пентестеры (даже, если его квалификация не выше их). И единственная этическая дилемма здесь, IMO, заключается исключительно в доведении до заказчика всей этой информации на этапе согласования работ. Кроме того, я не просто так оговорился на тему заранее оговоренного скоупа. Зачастую, окружение веб-приложения не входит в этот скоуп (например потому, что заказчик выделяет под это дело отдельный стенд и не готов обеспечить 100% соответствие его окружения окружению продуктивной копии веб-приложения). И в этом случае, тот же heartbleed никто бы даже не пытался обнаружить. В случаях же, когда окружение входит в скоуп, перечень работ, как правило, явно ограничен его тестированием на уже известные уязвимости (т.к. никакого разумного времени не хватит, чтобы протестировать каждый продукт/протокол/api и т.п., составляющий это самое окружение), что снов приводит к уже упомянутой выше дилемме.
0 |
  • Поделиться
  • Ссылка
Владимир Кочетков
24 Июня, 2014
Глаза не видят, руки делают, блин =/ >А пентест, являющийся блэкбокс-методикой анализа защищенности... Просьба читать, как "А пентест, суть - блэкбокс-методика анализа защищенности..."
0 |
  • Поделиться
  • Ссылка
Алексей Лукацкий
24 Июня, 2014
Володя, ну так об этом и речь О формировании в голове заказчика четкого понимания того, что на выходе даст аудит/пентест. Ну а насчет "тяжело представить"... Вспомнить можно ситуацию с PCI DSS, в котором (в первых версиях) говорилось о наличии антивируса на объектах инфраструктуры, но не требовалось его на банкоматах. И только после того, как были эпидемии на банкоматах, ситуация поменялась и требование стали трактовать по другому
0 |
  • Поделиться
  • Ссылка
Алексей Лукацкий
24 Июня, 2014
И формировать такое видение должен именно аудитор/пентестер
0 |
  • Поделиться
  • Ссылка
Александр О
24 Июня, 2014
Если имелось в виду что пентестеру, который пишет в акте, что уязвимостей нет, необходимо указать на то, что могут существовать не известные ему уязвимости - то да, смысл заметок понятен. Но тут как бы ожидания/техническая грамотность заказчика играет роль. Неграмотный заказчик скорее выберет того пентестера, который напишет что уязвимостей вообще нет и быть не может. А грамотный есть шанс что вообще к пентестерам не обратится
0 |
  • Поделиться
  • Ссылка
Алексей Лукацкий
24 Июня, 2014
Так вот проблема именно в том, что аудитор/пентестер и должен формировать ожидания неграмотного заказчика. Если заказчик считает, что аудитор ему выдаст вердикт "все чисто", а аудитор понимает, что это не так, но не говорит об этом, то эти неэтичность аудитора. Заметка про это, а не про неспособность аудитора найти все
0 |
  • Поделиться
  • Ссылка
Michael
24 Июня, 2014
Тема про аудит в таком разрезе бездонна. У нас есть иллюстрации из другой области - Леман Бразерс, Юкос. Мне кажется, тут вопрос не совсем в этической плоскости лежит (хотя этикой, как правилами совместной жизни в обществе, можно объяснить все). Есть такой вид логики - модальная. Она, в отличие от математической, различает "я считаю, что уязвимостей нет" и "уязвимостей нет". ИМХО заказчики/пентестеры/аудиторы часто не делают различий между условиями истинности этих утверждений. Я проводил пентесты силами разных поставщиков: процесс, результат и ощущение доверия к результатам - различные, но всегда есть понимание, что не все нашли...
0 |
  • Поделиться
  • Ссылка
Алексей Лукацкий
24 Июня, 2014
Миша, про модальную логику ты хорошо загнул Буду использовать в работе
0 |
  • Поделиться
  • Ссылка
Омар Ганиев
24 Июня, 2014
WTF, складывается ощущение, автор вообще не изучал computer science и никогда не искал уязвимости. Зачем тогда об этом писать, тем более в таком агрессивном ключе? Во-первых, поиск всех уязвимостей -- заведомо неразрешимая задача (в терминах теории алгоритмов), и в модели нарушителя в отчёте явно бывает описано, какие результаты будут у пентеста. Ведётся поиск известных уязвимостей в стороннем ПО, ошибки конфигурации, уязвимости в продуктах заказчика и т.п. По-Вашему пентестер за стоимость работ по анализу сайта должен ещё проводить детальный аудит OpenSSL? LOL! Может, ещё полный аудит Linux провести, если сайт работает на этой ОС? О какой этике Вы говорите, Алексей? Про конференции тоже убило: решения почти всегда есть, и хакер это понимает, равно как и разработчики. Или для Вас решение может существовать лишь в виде длинного бумажного документа с печатями и подписями?
0 |
  • Поделиться
  • Ссылка
Michael
24 Июня, 2014
Омар, не надо путать. Алексей правильно поставил вопрос. Уязвимость эксплуатируема без низкоуровневого внедрения. Суть в том, что не все понимают, что именно дает пентест, что скрывается за декларациями. Даже мелким шрифтом в конце договора не написано "Все сделанное, является моим мнением, ограничено моими знанием и инструментарием". Могу сказать, что перед первым пентестом, который я организовывал (как заказчик), я даже не знал как к ТЗ подступиться... Уверен, что подобные проблемы есть не только у меня
0 |
  • Поделиться
  • Ссылка
Сергей Борисов
24 Июня, 2014
Опытные эксперты и аудиторы тут все отлично разложили и расписали. Но некторая проблема есть - заказчик вынужден верить на слово пентестеру. Фактически никаких результатов кроме "существенных уязвимостей обнаружить не удалось" он не получает. В такой ситуации под соусом "пентест" можно продавать все что угодно (никаких механизмов проверки выполнения работ пентестером)
0 |
  • Поделиться
  • Ссылка
Сергей Борисов
24 Июня, 2014
С аудитом на соответствие чему-то проще. Тут можно и свидетельства и обоснования оценки по каждому пункту запросить и проверить.
0 |
  • Поделиться
  • Ссылка
Омар Ганиев
24 Июня, 2014
Михаил, причём здесь то, как она эксплуатируема? Факт в том, что, по словам Алексея, она была обнародована после сдачи отчёта некой компанией, значит, искать её пентестерам не надо было, потому что это отдельная большая работа по аудиту целого продукта (OpenSSL). Не знаю, у кого что не написано =) В отчётах, которые мне доводилось готовить, всегда было введение, модель нарушителя, резюме, и там в явном виде написано, что является целью работ, и какие результаты ожидаются. P.S. Модальная логика -- тоже математическая, просто определённого вида ==== Сергей, если пентестер не нашёл уязвимостей, он всё равно должен детально отразить в отчёте, что он проверял. Другое дело, что на рынке анализа защищённости действительно нет экспертизы качества, которая могла бы выявить много "фирм-сканеров", которые не проводят интеллектуальный анализ, а лишь бездумно пользуются инструментами.
0 |
  • Поделиться
  • Ссылка
Владимир Кочетков
24 Июня, 2014
Сергей, годный отчет по пентесту в случае "уязвимостей не обнаружено" на каждую не обнаруженную уязвимость содержит утверждение вида: "ИС не подвержена классу атак A вследствие того, что в ней достаточной мере реализованы защитные меры B, C и D". Описание защитных мер осуществляется таким образом, чтобы справедливость таких утверждений могла быть верифицирована третьей стороной без повторного проведения тестирования.
0 |
  • Поделиться
  • Ссылка
Michael
24 Июня, 2014
Выводы, которые я сделал: 1. Вопрос корректности (этичности) аудита сводится к контролю качества (все, что надо в документах написано, ограничения обозначены, все по ISO и т.п.) 2. Заказчик, в своем большинстве, подобен лоху, который ведется на маркетинг, не понимает, что значат термины и ограничения, которые написал подрядчик, покупает "кота в мешке", ставит галку. 3. Раньше пентест продавали как хорошее неформализованное дополнение к чек-листу (например по PCI DSS). Теперь, когда пентест делается по чек-листу, пора искать что-то еще... PS. если провести аналогию со здоровьем, лично я выбираю врача, а не клинику.
0 |
  • Поделиться
  • Ссылка
24 Июня, 2014
Интересно, Алексей реально уже забыл даже разницу между тестированием сайта на уязвимости и поиском 0-day в OpenSSL или просто троллит )
0 |
Ronin
28 Июня, 2014
2Tomas - требования к pentest в РД - это как? Мы можем определить что тестировать и очень обще на что, по какой методике и т.д. Но ОЧЕНЬ высокоуровнево. Даже если взять одну из самых детальных методик на сегодня - OSSTMM, по ней можно легко сделать тест, который ничего не найдет там, где объективно куча всего. И никакой РД не сравнится с ней. В общем, как общий итог по многим рассуждениям - не стоит делать предположений. А по самому материалу - наверное, стоит аккуратнее излагать мысли, если хочется донести одно, а возникает море вопросов и возражений по другому. У меня тоже до уточнений возникла негативная реакция, что автор совершенно некомпетентен в вопросах аудита и пентеста. Про ограничеия, scope, методики, риски и прочее понятно. Скажу по секрету, фактически во всех стандартах и методиках про это говорится и pentest по сути во многом похож на аудит и приемлет его практики и ограничения, за рубежом все это четко оговаривается и включается. У нас опять свои особенности - сами тестеры не парятся формальностями, Заказчики считают, что им должны выявить все-все-все. Кстати, pentest не выявляет все уязвимости, а лишь показывает возможность проникновения. Если я подобрал пароль к записи админа, то я и не пойду дальше искать HeartBleed и инжекшены и буду прав. Для обнаружения уязвимостей делается анализ защищенности (инструментальный или шире). И да, особенность нашего рынка с другой стороны - у заказчика есть свое понимание что ему должны. И если сказать и четко прописать все ограничения, возможные риски и т.д., то он скажет, что ему это не подходит и вообще вы просто халтурщики. И пойдет к другим халтурщикам, которые работу может сделают и не лучше, но просто не предупредят о всех деталях. Что с этим делать? Ну а по факту, у нас в стране есть буквально по пальцам одной руки контор, которые могут сделать приличный пентест (в смысле там есть специалисты высокого уровня, но не обязательно все такие). Думаю они должны быть известны многим. Все остальное - комплектация пакета услуг в фирмах/интеграторах, формализм или необходимость сделать такой тест за 100 тыщ за неделю )) ps да, самое интересное - ни один пентест ничего не гарантирует, поэтому ни о какой ответственности не может быть и речи, это просто глупо на самом деле. Если ее вводить, то пентестеров не останется и услуга вымрет просто.
0 |
  • Поделиться
  • Ссылка
1 Июля, 2014
"ps да, самое интересное - ни один пентест ничего не гарантирует, поэтому ни о какой ответственности не может быть и речи, это просто глупо на самом деле. Если ее вводить, то пентестеров не останется и услуга вымрет просто" Уррра, давайте лицензировать пентестеров
0 |