Новые методы эксплуатации инъекций в ORM

27.05 мне в очередной раз посчастливилось выступать на HITB@AMS. Даю ссылку на нашу презу. Также она доступна на сайте конференции. Этот доклад - продолжение темы, подсвеченной на ZN, но более расширенное и углубленное. Заниматься этим подстегивало весьма незначительное количество публикаций по теме, надеемся, нам удастся, хотя бы частично, заполнить этот информационный вакуум.

New methods for exploiting ORM injections in Java applications from Mikhail Egorov

Как обычно, в нашем докладе были демки, которые традиционно доступны на YouTube у Миши, ссылки на видео есть на слайдах презентации, дублирую здесь:
Exploiting JPQL injection against EclipseLink ORM
Exploiting HQL injection against Hibernate ORM with Unicode method
Exploiting HQL injection against Hibernate ORM with Java Constants method

После доклада был вопрос, на котором стоит также остановиться: "Как находить такие инъекции?" Они находятся также как и обычные SQLi, однако, в отличии от них они эксплуатируются несколько иначе. Собственно, доклад как раз о том, как такие инъекции эксплуатировать - предложены методы, которыми можно пользоваться в зависимости от комбинации СУБД-ORM - см таблицу на слайде 81.

Хонипоты в интерпрайзе

В презентации, рассказывая про атаки, я упомянул (этого нет в слайдах, но, по-моему, это было сказано), что с подавляющим большинством атак достаточно эффективно сражаются стандартные средства защиты, типа IPS, антивирусов и пр., и лишь небольшой процент (я слышал цифру ~1%) можно отнести к сложным целевым атакам (aka "APT"), с которыми надо работать как-то по-другому - используя другие инструменты с более глубоким вовлечением именно аналитика. 

Я много игрался с хонипотами, но потребность в них по-прежнему не очевидна. Просматриваются две основные идеи их применения. Во-первых, это может замедлить потенциальную атаку, о чем с некоторой подменой смысла повествовалось в статье уважаемого института. Однако, беря во внимание первый абзац этого поста, если мы имеем дело с "типовой" атакой, мои "стандартные" средства защиты прекрасно с этим справятся и без хонипота. Если же мы имеем дело с профессиональной атакой, то такой злоумышлениик раскусит наш хонипот за время, едва ли имеющее важное значение в общем таймлайне атаки. В этом случае, эффективность хонипота сводится к эффективности стандартной IDS - просто обнаружить то, с чем далее надо разбираться. Следует признаться, что когда в Амстердаме мы показывали видео про то, как ловить "хакеров" с помощью kippo, народ в зале отметил, что демонстрируемое поведение позволяет судить о далеко не высоком профессионализме атакующего. Если же мы будем разворачивать более хорошую эмуляцию (high-interaction honeypots), то это - полноценная новая система, которая, по Закону сохранения, утянет ресурсы, которые было бы куда более разумно потратить на обеспечение безопасности реальных информационных активов. Итого, от сложных неизвестных атак мы этим не защитимся, от известных - поможет "антивирус" (далее буду использовать как собирательный образ типовых привентивных технических средств обеспечения безопасности).

Второй задачей, решаемой хонипотом, обычно называют возможность исследования атаки: пока злоумышленник понимает, что он атакует хонипот, мы собираем эвиденс, который позволяет нам расследовать что происходит. Понятно, что едва ли нужно расследовать типовые атаки, где "антивирус" все заблокирует... Однако, хонипот не нужен и для сложных атак, поскольку, а) как было отмечено выше, его быстро раскусят, б) в случае необходимости расследования сложной целевой атаки у нас есть неотъемлемый "хонипот" - вся наша инфраструктура и приложения. Поэтому не надо сразу кидаться все вычищать, надо сначала понаблюдать и разобраться - это позволит избежать потенциальных проблем и радикально повысить эффективность вашего респонса. Об этом пишут все умные книжки про Incident response и об этом же говорил коллега в презентации (шикарная, на мой взгляд преза, полезно ознакомиться) - прежде чем кидаться в бой, надо максимально изучить противника (ну, безусловно, надо смотреть по обстоятельствам, не надо злоупотреблять "созерцанием и ничего не деланием", никогда не надо перегибать палку, красота - посередине). Итого, для исследования сложных атак в интерпрайзе хонипот тоже не нужен, так как все самое нужное и актуальное можно собраться собственно с защищаемой сети. А для "типовых" атак - достаточно, что хонипоты или любые другие подобные эмуляторы есть у производителей систем "антивирусов", которые я использую, и они регулярно и своевременно поставляют мне сигнатуры, защищающие меня от ~99% зла. 

Мониторинг своими руками

Выкладываю презентацию с CISO Forum 2016.

Мониторинг своими руками from Sergey Soldatov

Соответствие Спроса и Предложения

Так сложилось, что сегодня, общаясь с приятелями, я в разном контексте и абсолютно от разных людей услышал, по сути, один вопрос - почему, несмотря на то, что мы все тут CISO встречаемся и, вроде как, друг друга понимаем, читаем одни и те же книжки, однако, как правило, на предприятии все наоборот: культивируем перегибы, охотимся на ведьм, осваиваем бюджеты, вместо решения конкретных задач... - в общем, делаем типовые действия по инерции, ошибочность которых вполне очевидна. Я не раз утверждал, что Умный учится на своих ошибках, и поэтому не отвергаю необходимость хождения по граблям, однако, сколько же можно делать одно и то же!? А ответ прост - столько, сколько соответствует нашему пониманию. К сожалению, единственный инструмент дифференциации "правильно" от "неправильно" - это наше понимание действительности, этакая наша собственная Модель зрелости. Говоря максимально предметно: чтобы понимать, что "правильно" - это  на самом деле правильно ("правильно" - то, что лучше адаптировано к фактической действительности), нужно иметь определенную Модель зрелости, наша Модель зрелости - характеризует нашу способность выбирать из возможных вариантов развития наиболее правильный. В целом, это то же, что опыт и профессионализм, однако мысль поста - другая, а именно - для осознания действительной необходимости того  или иного продукта (не важно, будь то коробка или сервис) нужно иметь определенную Модель зрелости. Не достигнув определенной модели зрелости мы не будем в состоянии выбрать правильный продукт, а если даже выберем, мы не сможем его использовать эффективно. Как не странно на первый взгляд, второй исход для производителя еще более неудачен - его продукт будет неэффективен и никто не будет разбираться в причинно-следственной связи о том, что его не умеют использовать, или используют неправильно, или не использую вовсе. Тень неудачи продукта в конкретном случае упадет на производителя и мы получим эффект отсутствующей плитки.

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

Ровно также и в жизни: чтобы приобретать эффективные продукты (сервисы и\или технологии) надо, как минимум, понимать что они есть и в чем их эффективность перед другими, возможно, имеющими даже аналогичную классификацию, а дополнительно - надо уметь ими правильно пользоваться, чтобы продукт раскрывался на все 100% своего функционала, показывая максимальную эффективность и результативность. 
К сожалению, как невозможно первокласснику объяснить все преимущества производной, так и безопаснику на определенном уровне своей Модели зрелости невозможно объяснить необходимость того или иного продукта. Очень важно понимать, что это и не хорошо и не плохо. Очевидно, почему это плохо, - потому что действительно качественные решения остаются аутсайдерами, поскольку способность понимания этого качества предъявляет определенные требования к потребителю, который действительно должен быть профессионалом. Но это и не плохо, поскольку, как я отмечал выше, профессиональный инструмент в неумелых руках, как минимум, не приносит ожидаемого эффекта (что плохо для производителя!!), а, как максимум, может сотворить беду, поэтому пускай лучше автоматом пользуется тот, кто умеет из него стрелять, а мартышка никогда не примеряет очки.
Еще один важный момент для понимания, что, как правило, руководитель имеет команду, соответствующую ему по пониманию действительности. Относительно этого поста это означает, что, как правило, и руководитель и подчиненный имеют одну Модель зрелости. Различие в Модели зрелости приведет к тому, что либо подчиненный сам уволится, потеряв надежду выровнить с собой руководство, либо руководство уволит невыравниваемого с собой подчиненного. Работающие долго команды, как правило, имеют одну Модель зрелости. Это не стоит понимать буквально, что набор предметных знаний руководителя и подчиненного одинаков, но он эквивалентен с учетом уровня позиции. Поясню проще: CEO подбирает CISO эквивалентного своей Модели зрелости в области безопасности на уровне CEO, т.е. если для CEO безопасность - это антивирус, на позицию CISO будет взят человек с таким же концептуальным пониманием, но, может быть, с более глубокими техническими знаниями, например, тот, кто был админом антивируса в бэкграунде. CISO, который будет "на другой волне" не пройдет по квалификационным требованиям, даже если он будет говорить правильные вещи, очевидные с точки зрения более высокого уровня Модели зрелости (понятно, что под уровнем Модели зрелости здесь следует понимать степень приближенности к фактической действительности). Здесь этот несчастный, своеобразная белая ворона, может быть сравним с Гигантами прошлого, чьи изобретения и произведения искусства опережали свое время и не были по достоинству оценены при жизни авторов.
В общем, идея понятна, теперь давайте разберемся что же можно сделать творцам шедевров, чтобы потребителям, находящимся на уровне ВАЗ2106 уметь предоставлять BMW5.
1. Если вопрос себестоимости просто не стоит (понятно, что делать BMW дороже чем Жигули), то можно про BMW говорить категориями, применимыми к Жигулям. Т.е. свой высокотехнологический продукт продавать в "обертке", понятной потребителю (~махорка американская). Понятно, что для разного потребителя "обертка" будет разная. Причем здесь нет никакой лжи - это аналогично изложению на понятном языке.
2. Если вопрос себестоимости стоит, то здесь надо бить на компоненты и группировать их в пакеты, соответствующие разным Моделям зрелости. При переходе на новую Модель - предлагать новые фичи. Да, да, комплектации продуктов надо компановать не только на основе каких-то сценариев использования, но и на основе потребностей (способностей понимания, Модели зрелости) потенциального клиента. Не надо предлагать сигары тому, кто курит махорку и т.п.
3. Ну и, конечно, надо бороться с невежеством. В понятной доступной форме объяснять проблематику и рассказывать о том, как эти проблемы могут быть решены - так будет повышаться Модель зрелости потребителя, и это позволит нам всем в целом повысить среднюю Модель зрелости в отрасли и тем самым сделать Мир лучше!

Аутсорсинг мониторинга и реагирования на инциденты

Вчера общался с коллегами на тему SOC.
Наиболее любопытной мне показалась все еще актуальная проблема распространенности категоричного взгляда на вещи. Да, мы все постоянно твердим, что Мир не черный или белый, а серый, причем весьма неравномерно. Однако, эта простая аналогия, почему-то, не способствует вытеснению безапелляционных мнений о невозможности аутсорсинга безопасности, или ИТ, или их части.

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

Из этой, т.н. "Стратегии Великих", важно понять, что принцип использования и развития сильных сторон актуален и применительно к аутсорсингу. Не надо заниматься тем, что не есть ваша сильная сторона, и сокрушаться по этому поводу. Особенно неразумно этим заниматься, если есть кто-то доступный, кто делает это много лучше. Но правильно заниматься тем, что является вашей сильной стороной или тем, что никто кроме вас не сделает. Последнее (на всякий случай сделал его курсивом) должно стать принципом вашего планирования развития.

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

Итак, что же получается. 
Сильные стороны интерпрайзной ИБ: 
- она знает чего боится - понимая свои корпоративные бизнес-процессы она понимает что критично, может правильно расставить приоритеты и сформулировать цели;
- она знает свою инфраструктуру и приложения, что позволяет понять потенциальное "поле боя";
- она знает своих работников - вопросы кадровой безопасности, лояльности сотрудников очень важны и это обязательно следует анализировать (немного этой темы я коснулся здесь);
Очевидно, что все эти сильный стороны корпоративной ИБ - слабые стороны аутсорсера, но, с другой стороны, профессиональный сервис:
- видит глубже и шире проблему, поскольку у него больше опыта, он от большего количества клиентов имеет данные, поэтому "новая" для вас атака, может быть известной для профессионального сервиса, а вместе с тем известным станет и контекст атаки - цели атакующего, инструменты, TTP; да и вообще, понимание того видите ли вы атаку или легальную активность для профессионального сервиса много четче;
- профессионален в специальных областях: пентест, реверс, форенсика, анализ малвари и т.п., поскольку эти ребята изо дня в день это делают, и это - их основная работа.

Проанализируйте свои возможности и возможности потенциальных аутсорсеров под призмой развития сильных сторон, думаю, это поможет вам определиться с вопросом где проходит граница между "делать самому" и "купить на рынке".

О сборе логов

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

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

Адаптируя свой лог-менеджмент к этой новой парадигме получается примерно следующее:
а) собирать логи надо все и обрабатывать централизованно (т.е. искать по всем сразу), поскольку едва ли удастся угадать где что полезного можно будет обнаружить в рамках расследования,
б) хранить именно сырые логи и иметь возможность в будущем их по-разному анализировать, - технологии атак меняются, меняются и подходы их обнаружения и расследования, а раз так, то надо иметь возможность делать различные выборки, по-разному отображая одни и те же данные; иными словами, по мере расследования я буду получать все новую информацию, которая позволит мне строить более точные запросы к данным и доставать все новые детали,
в) хранить логи надо долго, так как, обнаружив сейчас постэксплуатацию, надо уметь ее "отмотать" на неопределенно долгий срок назад, с целью понять "как это было" и "с чего все началось", чтобы, в конце концов, имея целостную картину, выработать эффективное противостояние.

Получается, что в таких условиях задача службы мониторинга уже не просто "как можно раньше прокукарекать и заткнуть все, что получится", а именно расследовать с целью выработки более эффективных мер. Тут хорошая аналогия вспоминается из практики: в логах антивируса фиксировалось постоянно заражение и успешное лечение одной и той же рабочей станции. В целом, можно было бы забить - заражение завершалось успешным лечением, однако несложное исследование показало, что дроппер не обнаруживался этим антивирусом, причем сидел уже настолько хорошо, что самые свежие сигнатуры были ни по чем, а то, что успешно лечилось - это уже его "полезные нагрузки" и вопрос был только в некотором временном лаге, когда-таки прилетел бы "правильно запакованный\пересобранный" малварь, приведший уже к последствиям, совпадающим с мотивами злоумышленника. Этот банальный пример показывает, что здесь мы видим именно постэксплуатацию, ибо прошляпили как залетел и как закрепился дроппер. Анализ проводился на большом периоде, поскольку попытки закачать "полезную нагрузку" не были чаще чем раз в день, причем разброс по времени был случаен. Но уже потом, вытащив дроппер, было интересно поискать его следы в логах Web-прокси, почтовой системы, пошариться SCCM-ом и антивирусом по всем десктопам в интерпрайзе, поискать его в логах системы контроля доступа к периферийным устройствам и вообще везде, от чего у нас есть логи (очевидно желание все это сделать одним поиском). Причем, с учетом того, что "грамотный" дроппер, закрепившись, не стал бы палиться сразу, ретроспективный анализ следов его залета к нам необходимо проводить на неопределенной глубине данных.

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

Сканеры уязвимостей@Enterprise

Следуя правильной причинно-следственной логике, прежде чем выбирать инструмент решения, следует понять задачу. Очевидно, сканер уязвимостей нужен для поиска уязвимостей, чтобы их потом латать и так, постепенно, улучшать свои ИТ-системы в предположении, что минимизация уязвимостей == повышение безопасности, наверно, это так и есть. 
Ранее, мы разбирались с уязвимостями (кому лень читать, можно послушать), в совокупности с предположением, что в компании не разрабатывается ПО, с необходимостью сканера не все понятно. 
Вообще, аудит мне подтверждает две вещи: что я делаю правильные вещи, и что я делаю эти вещи правильно. Второе - это аудит соответствия. Первое - пентест, этакая Зарница,  в идеале, может, даже и без оповещения, что мы в состоянии игры. Как я не раз отмечал, в большом интерпрайзе управляемость - один из важнейших моментов, а следовательно, обычно, есть централизованные системы управления элементами ИТ-комплекса, типа SCCM, выполняющих любые виды инвентаризации. Чем вам такая инвентаризация не аудит соответствия? Сейчас уже у любого производителя есть руководство по безопасной настройке, так называемые hardening-гайды, - аудит соответствия такому гайду легко автоматизировать, да и многие производители имеют автоматизированные инструменты, которые проверят соответствие (некоторые потом даже предложат и исправить) - совсем нетрудно дергать такие проверялки при инвентаризации. В общем, очевидно, уязвимости конфигурации средствами инвентаризации легко закрываются. 
Но закрываются и ошибки разработчиков, поскольку уязвимости коммерческого ПО решаются для интерпрайза единственным образом - установкой патчей. Если я имею дело с 0-day, то такие риски компенсируются другими "эшелонами" моей безопасности: сегментацией, "навесными" средствами с разными модными технологиями, типа "virtual patch", контролем доступа, постоянным мониторингом и пр. К тому же, если производитель нормальный (я рекомендую, и от души желаю, работать только с нормальными производителями), скорее всего он выпустит какие-нибудь рекомендации, что нам всем делать, пока он не выпустил патч. Производитель, в софте которого вы нашли уязвимость, а затем безрезультатно закидываете его enhancements request-ами с требованиями исправить проблему, - не достоин называться "нормальным", поэтому неразумно держать сканер исключительно для таких случаев.
Перейдем к пентестам. Здесь мы пытаемся удостоверитья, что мы делаем правильные вещи. Безусловно, здесь уже нужна автоматизация... Но, в случае уязвимости конфигурации - эксплуатация тривиальна, как правило, можно и не пробовать, а в случае уязвимости ПО - вопрос эксплуатируемости, обычно, исследован вендором, и этому исследованию можно и нужно верить, а проверять экплуатируемость сканером - ну разве что только из спортивного интереса - насколько хорошо производитель сканера реализовал эксплоит. Более того, исследовать вопрос насколько правильные вещи я делаю, мне едва ли нужно часто. А раз так, то, наврено, эффективнее нанять профессиональную команду, где натренированные практики будут использовать десятки инструментов, чем я-любитель буду в автоматизированном режиме использовать один, имеющейся у меня сканер.
Прниципиальная вещь: сканер не находит неизвестные уязвимости и вряд ли найдет больше, чем известно "нормальному" производителю исследуемого ПО.

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

Подводя итог всему написанному, хочется все-таки понять, когда же мне нужен сканер:
0. У меня огромный разнородный ИТ-комплекс, поэтому мне невозможно детально разбираться с каждым, используемым у меня производителем (заниматься харденинком его решений), мне проще запустить комбайн, который на приемлемом уровне решит проблему (ну или хотя бы сделает что-то, что лучше, чем ничего).
1. Я не знаю свою инфраструктуру. Отсканировал - получил какое-то представление (почти п.0, но с условием необходимости быстрых результатов при отсутствии времени).
2. У меня нет систем управления ИТ-инфраструктурой, поэтому я это компенсирую сканером, реализовав следующий процесс управления ИТ-инфраструктурой: отсканировал --> нашел узявимости --> устранил --> отсканировал --> ...
2,5. У меня плохие отношения с ИТ, поэтому я не могу использовать их системы управления ИТ-инфраструкурой и должен обязательно иметь свою штуку.
3. У меня стандартные системы, чтобы в сканере под них были сигнаруты\профили.
4. Я не хочу разбираться с безопасной настройкой каждой из используемых у меня систем, мне удобнее иметь комбайн, который все мои ошибки конфигурации (в целом, отсутствующий патч тоже можно считать уязвимостью конфигурации) найдет мне в виде уязвимостей (тоже почти п.0, но при отсутствии объективной невозможности разобраться с рекомендациями производителей, я просто лентяй).
5. Меня вынудил комплайнс, требующий от меня наличия сканера, или инструмента управления уязвимостями, или еще чего подобного.
6. У меня есть желание поразвлечься - посмотреть эксплуатируемость стандартных уязвимостей (== доступных в сигнатурах\проверках сканера)
7. Я хочу\должен кому-то что-то продемонстрировать или доказать, сделать вау-эффект, или эффективность моей работы характеризуется количетсвом найденных уязвимостей.
8. Сканер - это мой инструмент situational awareness (что-то около п.1) - фундаментальное требование для эффективной работы SOC.

На практике мы, конечно же, имеем комбинацию перечисленного + что-то уникальное, до чего я даже не догадываюсь.