Можно ли вывести градацию уязвимостей?

Question

[Сергей]

Всех приветствую.
Пытаюсь для себя понять градацию опасности схем проникновения во внутренний контур.
Вспоминая недавние взломы крупных операторов связи, когда попадают в VMWare VCenter и удаляют всё что можно, а потом еще и до бэкапов добираются, которые доступны из той же сети.
Можно даже взять какую-нибудь госконтору с их веб-сервисами, в том числе и те, которые не видны снаружи, например ведомственные СЭД и разные АС.

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

И может еще есть какие-то более опасные варианты?

Answer 1

[hint000]

Человеческий фактор - всегда главная угроза.

Предполагаю что самое слабое звено - это то что всегда торчит наружу, т.е. сайт.

Сам по себе сайт не создаёт дыру. Её создаёт "человеческий фактор" -

• админы, которые что-то неправильно настроили,
  
• программисты, которые наделали ошибок,
  
• тестировщики, которые пропустили ошибки,
  
• менеджеры, которые дали неправильные распоряжения админам, урезали сроки тестирования, урезали бюджет на железо и ПО для ИБ, проигнорировали предупреждения подчинённых, не провели аудит,
  
• рекрутеры, которые нарекрутили всех этих аболтусов. :)
  

Всё это - человеческий фактор, а не только какой-нибудь бухгалтер, попавшийся на фишинг.

Answer 2

[Василий Банников]

Можно классифицировать по шкалам:
1. Последствия эксплуатации уязвимости
2. Сложность эксплуатации уязвимости

И чем ближе уязвимость к углу "может эксплуатировать даже школьник, а последствия катастрофические", тем важнее должна быть уязвимость и тем скорее её надо закрывать.

Ну и да, самое уязвимое звено - это люди и очень часто без злого умысла.

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

Answer 3

[CityCat4]

Предполагаю что самое слабое звено - это то что всегда торчит наружу, т.е. сайт.

Нет.
Самое слабое звено - это человек.

Сайт не обижается, что ему не повысили зп.
Сайт не мечтает "Я вам всем покажу!"
Сайт не оставляет закладок на неавторизованный доступ при увольнении.

Хотите живой пример? Настоящий, не придуманный?

Контора N увольняет админа Васю и нанимает вместо него админа Петю. Петя ответственно меняет рутовые пароли на всех серверах, но в детали их настройки не погружается так как слишком много нужно проаудировать. Через несколько месяцев Петя замечает, что вдруг примерно несколько дней назад почта директора стала форвардиться на некий адрес на гмыле.
Петя форвард прибил, провел форензику и выяснил, что Вася перед увольнением оставил закладку - демона pppd, к которому можно было подключиться терминалом, что Вася и сделал (last это четко показал). Рута у него уже не было, но нагадить Вася все-таким смог, создав запись о перенаправлении почты в postfix, который использовал mysql.
В итоге все внешние серваки времен Васи были снесены нафиг и перестановлены.