Пентесты на рынке

Почему-то снова в Сети стали вспоминать про пентесты. Какое-то время назад я тоже об этом много думал. Как ни странно, мое мнение на этот счет не изменилось и к написанному мне особенно добавить нечего (обычно, с годами мое профессиональное мнение изменяется, - и это мне сильно греет душу, ибо дает основания считать, что я развиваюсь, эволюционирую....), но все же хочется прояснить ряд моментов, поэтому еще один пост.

Как я отмечал 4 года назад у пентеста и аудита соответствия разные цели, соответственно, разумно их применять для решения разных задач. Во-первых, я вижу мало смысла в пентесте коммерческого продукта: зачем мне финансировать исследования безопасности, скажем, Microsoft, - достаточно того, что я честно купил их продукты и исправно плачу за поддержку!
Во-вторых, между обнаружением уязвимости и ее успешной эксплуатацией - огромная разница, стоящая подчас колоссальных ресурсов. Отчасти, именно для того, чтобы хоть как-то адресовать эти ресурсы, товарищи из Microsoft придумали свой индекс эксплуатируемости.
В-третьих, я склонен считать пентесты продуктом, выходящим за рамки умения пользоваться готовыми инструментами, так как для последних есть специальное название, да и я сам так умею :). Я в понятие "пентест" вкладываю понятие "исследование". Именно это мне дает надежду считать, что когда я наразрабатываю кучу софта, понастрою систем, где заказчиком, архитектором и исполнителем работ буду я сам, найдутся реальные исследователи, способные обнаружить уязвимости в моем творении, исследовать вопрос их эксплуатируемости и довести эту эксплуатацию, возможно, с моей помощью, до реального бизнес-влияния, которое докажет не только мне самому, но моему топ-менедженту необходимость как-то адресовать проблемы с безопасностью. Этот абзац очень важен, поэтому я скомпилирую его в дайджест: есть 3 уровня результата аудита: 1-ый - только обнаружить уязвимость; 2-ой - исследовать ее эксплуатируемость, проэксплуатировать; 3-ий - сделать из этой эксплуатации бизнес-кейс, поднять эксплуатацию до реального профита для атакующего\ущерба для бизнеса. Так вот, для заказчика важен результат именно третьего уровня.

В своих последних постах на эту тему коллеги пишут, что пентест - стандартная работа, типа приходят парни со скриптами, за полчаса находят непатченную рабочую станцию, получают на ней локального админа, ждут пока там появится админ домена, перехватывают его пароль/хеш, делают учетку в Enterprise Admins и рапортуют об успехе. Я немного огорчился, увидев как в твиттере ребята, специализирующиеся именно на пентестах, подхватили, что пентест - стандартная работа. Не, мне не нужна стандартная работа, - работу по сценарию может делать и автоматический сканер (собственно, сценарий :) ), а где нужно немножко подумать - запускающий его человек, мне нужно именно исследование, мне нужна эксплуатация не Micosoft Windows, а АИС "Моя АБС", - за ее безопасность никто не отвечает, кроме меня, и я хочу серьезно подойти к этой своей ответственности. 
Возможно, сторонники commodity-услуги правы в том, что с точки зрения аудитора подход все равно будет одинаков: пентестит он Active Directory или АИС "Моя АБС", по крайней мере начало, - есть понятный набор практик и подходов, определенный набор инструментов, как умею, так и работаю :), да и моя супер-пупер-уникальная система все равно может быть представлена как совокупность стандартных компонетов: стандартной ОС, стандартной СУБД, стандартного сервера приложений и т.п. Но неправильно провоцировать людей думать, что раз услуга стандартна, то стандартно и предложение на рынке, откуда делается неправильный вывод, что любой игрок, предлагающий такую стандартную услугу, окажет ее со стандартным уровнем качества, регулируемым все тем же рынком. Нет, не так. Именно потому что здесь велика доля ресерча, качество результата далеко нестандартно и инструменты типа Критерия минимальной цены здесь отработают неэффективно.

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

Категории инцидентов

Все, кто  пытается отстроить сервисы мониторинга   событий безопасности рано или поздно приходят к вопросу необходимости классификации инцидентов. Здесь, как и в случае с отчетностью следует использовать подход "по цели", а уже понимание целей позволит определить критерии классификации. 
1. По критичности/важности/приоритету/потенциальному ущербу, иногда сюда же замешивают "влияние". Цель здесь - приоритезация усилий по реагированию: наиболее приоритетные - в первую очередь, наименее - можно отложить. Обычно в этом случае для определения критичности используется какая-то матрица в виде (Количество затронутых пользователей) х (Критичность подразделений для предприятия, либо грейд/позиция этих людей).
2. По типу инцидента/сути инцидента. Здесь цель - организовать правильную маршрутизацию, чтобы информация об инциденте с минимальным количеством хопов попала сразу в правильную группу реагирования. Обычно здесь используются типы, как-то коррелирующие с имеющимися группам эксплуатации. Например, DOS-атаки надо как-то совместно решать сетевикам с ISP, проблему спама могут адресовать почтовые админы и админы антиспам-фильтров (если это другие люди), проблемы на Интернет-сайте предприятия разумно направить сразу админам сайта, вирусы на рабочих станциях пользователя - в поддержку рабочих мест, чтобы они вытащили сэмпл, передали админу антивируса, который направит его в поддержку, получит экстру и всех сразу вылечит. Если кто-то сливает данные на флешки/в Интернет - разумно аккуратно переговорить с его линейным руководителем, чтобы уточнить возможную бизнес-потребность такого поведения. Если кто-то сканирует сеть, надо выяснить кто это: если админ - уточнить что он делает, если пользователь - исследовать удаленно насколько это возможно, если не все понятно - направить туда поддержку рабочих мест. Полезно в ходе расследования уточнять является атака специализированной "под вас" или "просто залетело" - это также следует учитывать в классификации. .... подобные "если, то" можно продолжать бесконечно, ибо мы одарены безграничной фантазией, поэтому надо смотреть по месту.
3. По вектору атаки. Может переплетаться с "По типу инцидента" (если погуглить, то большинство из того, что выпадет в результат будет содержать слитые эти типы категорий вместе - это тоже нормально и тоже определяется вашей целью). Достигаемая здесь цель - контроль эффективности используемых систем безопасности. Если, например, у меня большинство подтвержденных взломов прошло через Интернет-прокси - надо что-то в нем менять; если большинство прилетело по почте, то надо поднастроить почтовый шлюз. Может, при просмотре статистики инцидентов будет установлено, что почти все занесли со съемных носителей, то надо поставить какую-нибудь контролировалку флешек, а может, даже и запретить копировать с них исполняемые файлы; ну а если стало известно что все наши проблемы из-за того, что пользователи не задумываясь о последствиях сливают важную информацию направо и налево, то имеет смысл заняться повышением осведомленности.
4. По источнику обнаружения. Возможно, предыдущий тип классификации вам не нужен, но есть потребность оценивать эффективность используемых систем обнаружения (имеется в виду не только IDS), тогда полезно в инциденте указывать каким образом он был обнаружен. Это позволит понимать во-первых насколько существующие системы здорово выполняют свою работу (может, их надо заменить на другие или получше подконфигурировать), во-вторых, понять в какие места еще что было бы полезно поставить, чтобы обнаруживать инциденты быстрее/дешевле.
5. ....

Атака может быть комбинацией: сначала пользователя заспамили, затем зафишили, затем drive-by, затем зловред, и понеслась... - в этом случае для более удобного анализа я бы регистрировал несколько связанных инцидентов, но опять же обязательно иметь понимание как информация об этих инцидентах будет обрабатываться и какой результат хочется получить из операционной отчетности.

Может показаться, что иметь много категорий - это хорошо, так как это покажет ситуацию в разных перспективах, но надо помнить, что множество параметров затрудняет процесс регистрации, снижает операционную эффективность процесса, чего мы всегда стремимся избегать, поэтому здесь функционал впрок тоже не нужен - любая категоризация обязательно должна под собой иметь цель.

Для облегчения первичной регистрации часть работ по классификации можно отнести на период уже после отработки инцидента: классификацию, влияющую на маршрутизацию инцидента и оперативность реагирования - делать в первую очередь, классификацию, позволяющую анализировать тренды и поддерживать какие-либо стратегические/тактические решения - можно делать уже после, в рамках Lessons learned, может, даже, специально обученными для этого людьми :)

Как видите преследуемые классификацией цели сугубо индивидуальны, сильно зависят от среды, как следствие, индивидуален и подход к классификации, поэтому универсального подхода не придумать, но, надеюсь, накидать идей/мыслей у меня получилось.