Архив метки: SLA

Сентябрьский выпуск "В тренде VM": 7 трендовых уязвимостей, фальшивая рекапча, ливанские пейджеры, годовые премии IT-шников

Добавить комментарий

Сентябрьский выпуск "В тренде VM": 7 трендовых уязвимостей, фальшивая рекапча, ливанские пейджеры, годовые премии IT-шников. Начиная с этого месяца, мы решили несколько расширить тематику и увеличить длительность роликов. Я рассказываю не только про трендовые уязвимости сентября, но и про примеры использования социальной инженерии, эксплуатацию уязвимостей реального мира и практики процесса Управления Уязвимостями. В конце объявляем конкурс вопросов по Управлению Уязвимостями с подарками. 🎁

📹 Ролик "В тренде VM" на VK Видео, RUTUBE, YouTube
🗞 Пост на Хабре на основе сценария ролика "В тренде VM"
🗒 Компактный дайджест с техническими деталями на официальном сайте PT

Содержание:

🔻 00:58 Elevation of Privilege - Windows Installer (CVE-2024-38014) и уточнения по этой уязвимости
🔻 02:49 Security Feature Bypass - Windows Mark of the Web "LNK Stomping" (CVE-2024-38217)
🔻 03:57 Spoofing - Windows MSHTML Platform (CVE-2024-43461)
🔻 05:14 Remote Code Execution - VMware vCenter (CVE-2024-38812)
🔻 06:27 Remote Code Execution - Veeam Backup & Replication (CVE-2024-40711), пока монтировали ролик появились данные об эксплуатации вживую
🔻 08:40 Cross Site Scripting - Roundcube Webmail (CVE-2024-37383)
🔻 09:38 SQL Injection - The Events Calendar plugin for WordPress (CVE-2024-8275)
🔻 10:40 Человеческие уязвимости: фальшивая reCAPTCHA
🔻 11:57 Уязвимости реального мира: взрывы пейджеров и других электронных устройств в Ливане, последствия для всего мира
🔻 14:53 Практики процесса управления уязвимостями: привязать годовые премии IT-специалистов к выполнению SLA по устранению уязвимостей
🔻 16:10 Финал и объявление конкурса
🔻 16:31 Бэкстейдж

Сегодня на вебинаре в рамках курса Positive Technologies по Vulnerability Management-у (уже третий набор ❗️) обсуждали, в том числе, и способы материальной мотивации IT-шников к устранению уязвимостей

Добавить комментарий

Сегодня на вебинаре в рамках курса Positive Technologies по Vulnerability Management-у (уже третий набор ❗️) обсуждали, в том числе, и способы материальной мотивации IT-шников к устранению уязвимостей

Сегодня на вебинаре в рамках курса Positive Technologies по Vulnerability Management-у (уже третий набор ❗️) обсуждали, в том числе, и способы материальной мотивации IT-шников к устранению уязвимостей. Сразу вспомнилась мемная картиночка. 🙂 Идея-то, в целом, неплохая. Но нужно понимать, что попытка внедрения таких практик встретит всевозможное сопротивление со стороны IT. От рядовых инженера и до CIO. Они не поленятся найти те таски на устранение уязвимостей, где есть какие-то косяки: неочевидная эксплуатабельность, подозрение на false positive и т.п. И они используют эти кейсы, чтобы представить дело так: это вы недостаточно хорошо выполняете свою работу и наваливаете им бесполезные задачи! 🤷‍♂️😏

Приведите таски в порядок, подготовьте контраргументы и убедитесь, что у вас хватит административного ресурса на продавливание таких непопулярных решений. Без должной подготовки лучше в лобовые атаки не ходить. Вы же не Бессмертный (и не Неувольняемый 😉).

Где SLA, Лебовски?

1 комментарий

Где SLA, Лебовски?

Где SLA, Лебовски? В посте с критикой БОСПУУ Алексей Лукацкий задаёт вопрос про SLA для задач на устранение уязвимостей: "Кто его устанавливает? ИТ?" И дальше предполагает, что сроки для устранения критичных уязвимостей будут неадекватно завышены.

Здесь сошлюсь на хорошую статью по управлению уязвимостями, которую я уже разбирал ранее.

SLA на выполнение задач по устранению уязвимостей (плановому и приоритетному) согласовывают совместно ИБ и ИТ/бизнес.

При этом учитывается:

🔹 критичность активов
🔹 требования к доступности активов и к версионности
🔹 технологические окна

Если какие-то активы невозможно обновлять даже в окна, следует рассмотреть возможность дублирования систем или обновления по частям.

Процесс согласования формального SLA непростой. Но если его не установить, задачи на устранение уязвимостей вообще не будут выполняться. 🤷‍♂️ По этой же причине следует аккуратно фиксировать просрочки, разбираться в их причинах и, при необходимости, пересматривать SLA.

По поводу идеи Jacob Williams использовать "Accepted Insecure Time" вместо "Service-level Agreement" при обсуждении уязвимостей и патчей

1 комментарий

По поводу идеи Jacob Williams использовать Accepted Insecure Time вместо Service-level Agreement при обсуждении уязвимостей и патчей

По поводу идеи Jacob Williams использовать "Accepted Insecure Time" вместо "Service-level Agreement" при обсуждении уязвимостей и патчей. Логика в этом есть. Действительно, термин SLA скрывает суть проблемы: пока уязвимость не исправлена (даже если IT укладывается в SLA), компанию могут ВЗЛОМАТЬ. И это уже не выполнение сервисных операций, а что-то другое, что-то более важное.

С другой стороны, а где этот новый термин употреблять?

🔹 IT понимают про сервисы. Предлагаете идти к ним со своим новоязом? Выглядит неконструктивно. Сейчас же принято с бизнесом разговаривать на их языке. Почему с IT разговариваете на ИБшном? 🤔
🔹 Или приходить с этим к бизнесу, а потом транслировать в SLA для IT? Не слишком ли избыточно? 🙂

В любом случае, я бы переводил не как "разрешенное время незащищенности", а как "принятое время незащищённости". По аналогии с "принятым риском". И сокращённо это будет ПВН, что создаёт дополнительные аллюзии на PWN. 😉