Не совсем понял ваш ответ... Это точно к моему вопросу? 😁

https://www.wired.com/story/notpetya-cyberattack-ukraine-russia-code-crashed-the-world/
The result was more than $10 billion in total damages, according to a White House assessment confirmed to WIRED by former Homeland Security adviser Tom Bossert, who at the time of the attack was President Trump’s most senior cybersecurity-focused official.

Если пентест проводит внешняя компания - то они и определяют по своей методике или cvss. С другой стороны, лучше своих ИБшников критичность никто не определит. Стоит озаботиться этим зарание и внедрить процесс управление уязвимостями, определить участников процесса, методику определения уровня критичности (в привязке именно к вашей инфраструктуре), и в зависимости от уровня критичности установить сроки устранения таких уязвимостей. Дополнительно предусмотреть компенсирующие меры для тех случаев, когда уязвимость не может быть устранена (когда система настолько старая, что лучше ее не трогать). + определить ответственных за принятие рисков, если уязвимость остается жить. Так делал у себя.

на самом деле очень хороший вопрос. Мы долгое время пользовались CVSS, но он зачастую не учитывает критичность для бизнес процессов и критичность в конкретном сетапе компании.
В то же время заказчик сам зачастую тоже не может оценить критичность в виду специфичности области.
Потому пришли к тому, что нужна своя система скоринга.
Рекомендую кроме CVSS ввести свой скоринг, учитывающий конфигурацию и бизнес процессы. Но обращаю внимание, что формулы расчёта могут быть сколь угодно сложные, но на выходе светофор. Три уровня вполне достаточно, чтобы работать дальше.

тут есть крайности:
1) пентестер, который может так радоваться своей находке, что будет считать её супер критичной и гордиться технически крутым багом, игнорируя реально возможный ущерб;
2) инженер, который всеми способами будет пытаться приуменьшить уровень риска, чтоб не признавать ошибку.

На практике бизнес-риски адекватно может оценить только заказчик (и то, далеко не всегда). Задача пентестеров — описать всевозможные технические способы эксплуатации уязвимости с точки зрения хакера.

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

Очень часто люди , которые знают как взломать не знают как защищать . Не знают насколько критичны те или иные уязвимостям для инфраструктуры. Этого часто и заказчик не знает

Что качается устранения, тут есть ряд параметров, которые объективно могут не дать вам выполнить полный цикл управления уязвимостями(размеры инфраструктуры, как работают LUSы, регламенты обновления и тд), но всё это должно обходится и должен быть отработан манёвр по устранению ДЕЙСТВИТЕЛЬНО КРИТИЧНЫХ вещей. Тогда все в ружьё, хоть в субботу ночью и погнали устранять.
Кстати, такое лучше оттрепетировать.

Коснулся этого выше. Для этого и нужны смешанные команды с хорошими энтерпрайз админами

не панацея, но зачастую именно они подсвечивают такое.

Из живых кейсов. Была пустячная уязвимость, очень простая в эксплуатации, которая позволяла отправлять неавторизовано смс. И пентестеры даже критичной эту уязвимость не назвали. А можно было слать подряд. много. сотни в секунду.
Теперь переложим это на бизнес. За ночь можно влететь в такие долги провайдеры сотовой связи, что можно закрывать бизнес.

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

вот тут как раз про это писал

Это я читал . Я просто как итог для себя подвёл .

действитльно некрасивая ситуация. Я стараюсь скипать подобные проекты. Но иногда безе НУЖНО показать насколько всё плохо на C-Level.

чтобы защитить бюджеты и тд. Ну и тогда wow-проект, с измением зарплаты на рубль какому-нибудь топу.

Это тоже вполне себе задача.

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

обычно эксплуатация уязвимости с демонстрацией получения доступа в рамках пентеста (или внутреннего аудита самостоятельного) как раз помогает в таких случаях

В целом мы как-то провели анализ бизнес-процессов, указали на имеющиеся недостатки, после провели пентест, который многое подтвердил. Но убедить все равно не удаётся

Однажды даже пришлось "взломать" одного из руководителей - вот это подействовало! И ещё как 😁 Но не всегда же так делать... Как вы выстраивали комюнити между бизнесами и ИБ?