Vulnerability Management чек-лист для финансовых организаций от Positive Technologies

2 комментария

Vulnerability Management чек-лист для финансовых организаций от Positive Technologies. Статья вышла в BIS Journal 22 февраля, но я только сейчас её увидел. Мне в целом, импонирует подход PT к VM процессу. Особенно то, что Евгений Полян и Анастасия Зуева транслируют в своих выступлениях. Поэтому мимо их совместной статьи пройти никак не мог. Собрал краткую выжимку, за деталями рекомендую обратиться к исходной статье.

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

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

3. Разрабатываете/внедряете новую систему? Проверьте, что в ТЗ учтены:
3.1. Технологические окна для регулярных обновлений
3.2. Возможность сканирования (от меня: лучше даже шире - проверить, что есть средство детектирования уязвимостей для системы)
3.3. План реагирования на появление новых опасных уязвимостей для ИТ и ИБ

4. Пока не убрали уязвимости, новую систему в промышленную эксплуатацию не берем. Как взяли - продолжаем поддерживать уровень безопасности.

5. Три шага к организации процесса управления уязвимостями:
5.1. Определить перечень недопустимых для организации событий c бизнесом и ТОПами
5.2. Определить риск-рейтинг активов
5.3. Составить регламент работы и обслуживания каждого типа активов, согласовать с бизнесом и IT

6. Зафиксируйте роли подразделений:
6.1. Руководство компании - приоритеты и перечень недопустимых событий
6.2. Топ-менеджмент - перечень наиболее важных сервисов
6.3. ИТ-подразделение - обновление в соответствии с SLA
6.4. ИБ-подразделение - приоритеты устранения уязвимостей, критерии эффективности процессов ИБ, контроль уровня защищенности, определение ключевых активов

7. Определение сроков обновления систем и регламента обновлений:
7.1. Выделить ключевые активы (контроллеры домена, серверы Exchange, системы управления виртуализацией, рабочие станции администраторов и т.д.)
7.2. Установить регламенты по обновлению, определить SLA (и что делать если SLA будет нарушаться)
7.3. Для зарубежного ПО использовать алгоритм НКЦКИ и результаты тестирования обновлений ПО от ФСТЭК

Что мне нравится в этой статье: большой акцент на регулярных обновлениях. Ситуация когда месяцами-годами системы не патчатся и все ждут ИБ-шников, которые должны просканить и поставить задачу на обновление - это не норма. IT-шник, если есть обновление безопасности - иди ставь! ИБшник (VM-щик) нужен для того, чтобы удостовериться, что все хорошо и по регламенту работает, а не для того, чтобы всех пушить постоянно. Ну и для того, чтобы бить в рынду, когда появляется что-то реально критичное.

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

Тинькофф в Бауманке

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

Тинькофф в Бауманке

Тинькофф в Бауманке. 15 марта Дмитрий Гадарь проведет лекцию "Разбор целенаправленной атаки", организаторы ITS BMSTU. Лекция про распространенные векторы атак и методы защиты. Для регистрации заполните форму. Студенты не из МГТУ тоже могут присутствовать, но нужно будет дополнительно получить пропуск.

Чем хороши отчетные мероприятия?

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

Чем хороши отчетные мероприятия? Такие как выступления на конференциях. Тем, что они имеют четкий дедлайн. Выступать придется, нужно добивать заявленную тему. 🙂 В моём случае неотвратимо приближающийся CISO Forum мотивирует доделать-таки карту отечественных около-VM-ных вендоров. Она сейчас готова на 1/6 и это ещё без учета презентации. А времени осталось чуть больше месяца.

Добавлю немного интерактивчика. Ниже свечу предварительный набор вендоров/решений для оставшихся категорий. Если вам кажется, что каких-то вендоров/решений там не хватает (или наоборот лишние), то дайте знать (см. описание категорий). Краткие характеристики решений, которые будут на карте, я стараюсь по возможности согласовывать с представителями вендоров, чтобы не было недопонимания. Для некоторых вендоров у меня контактов сейчас нет (они помечены *). Если подскажите на кого лучше по этому поводу выйти, буду благодарен. Написать можно в личку тг @leonov_av, в комментарии поста в вк или в личку в вк. Спасибо!

2. Средства Детектирования Уязвимостей Сетевого Периметра (СДУСП)
Metascan
СКАНФЭКТОРИ
Group-IB - Attack Surface Management
BIZONE - Continuous Penetration Testing

3. Средства Детектирования Уязвимостей Приложений (СДУП)
Positive Technologies - BlackBox, Application Inspector
* Стингрей
* Pentestit - Nemesida Scanner
* Ростелеком Солар - Solar appScreener

4. Средства Детектирования Уязвимостей Кода (СДУК)
Positive Technologies - Application Inspector
* Стингрей
* Ростелеком Солар - Solar appScreener
* InfoWatch - Appercut
* ИСП РАН
* PVS-Studio
Codescoring
Эшелон - AppChecker Cloud

5. Средства Анализа Уязвимостей (САУ)
R‑Vision SOAR
SECURITM

6. Средства Исправления Уязвимостей (СИУ)
Kaspersky

С международными женским днём!

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

С международными женским днём!

Пользуясь случаем, хотел бы отреспектовать всем женщинам, работающим в области ИБ, особенно в Vulnerability Management! Желаю комфортных условий труда, справедливой его оплаты, равных карьерных возможностей! Спасибо, что вы есть! 👩‍💻

Прочитал пост в блоге Rapid7 про разницу "Vulnerability Assessment" и "Vulnerability Management"

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

Прочитал пост в блоге Rapid7 про разницу "Vulnerability Assessment" и "Vulnerability Management".

О различии между VA и VM они пишут так: "Однако ключевое различие между ними заключается в том, что управление уязвимостями представляет собой непрерывный цикл, включающий vulnerability assessment. Там, где VA идентифицирует и классифицирует риски в вашей сетевой инфраструктуре, VM делает шаг вперед и включает решения о том, следует ли устранять, смягчать или принимать риски. VM также занимается общим улучшением инфраструктуры и созданием отчетов." Дальше просто описание VM-цикла от Gartner, который в жизни не встречается, уже разбирали его.

Люблю, когда люди хотят подчеркнуть большую разницу, чтобы продать свою дорогую VM-пепяку, а в итоге выходит, что как таковой разницы и нет. Если вы надетектили уязвимости как-то и приняли решение, что с ними дальше делать (устранять, смягчать, оставить как есть) и сделали отчет для начальства, то поздравляю, это уже Vulnerability Management. Как минимум исходя из поста в блоге Rapid7. 😉

Ещё порадовало, в Vulnerability Assessment они включают и детектирование уязвимостей в людях. "Эти уязвимости обычно относятся к одной из трех категорий: […] Человеческие. Эти уязвимости связаны с проблемами безопасности пользователей, такими как слабые (или утекшие) пароли, нажатие ссылок на вредоносных веб-сайтах и человеческие ошибки, такие как открытие фишингового электронного письма. Из трех категорий командам NetOps зачастую труднее всего контролировать и обеспечивать соблюдение требований для этой категории." Получается мешать VA/VM и Антифишинг это уже не придурь одного шведского VM-вендора, а уже почти мейнстрим. 😆

А вот и эксплоит для Remote Code Execution – Microsoft Word (CVE-2023-21716), которую я подсвечивал в февральском Patch Tuesday

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

А вот и эксплоит для Remote Code Execution – Microsoft Word (CVE-2023-21716), которую я подсвечивал в февральском Patch Tuesday

А вот и эксплоит для Remote Code Execution – Microsoft Word (CVE-2023-21716), которую я подсвечивал в февральском Patch Tuesday. Тут подробности. Об этой уязвимости писали, что она эксплуатируется через панель предварительного просмотра Outlook. Хороший повод форсировать патчинг, если вы пока ещё нет.

PS: У Joshua J. Drake очень классный сайт. 👍

Тренды/драйверы Vulnerability Management рынка

2 комментария

Тренды/драйверы Vulnerability Management рынка. Пару месяцев назад попросили накидать. С моей колокольни выглядит как-то так:

1. Изменение IT-ландшафта в странах в силу геополитических изменений. Соответственно меняются и ожидания того какие продукты должны поддерживать VM решение.
2. База знаний VM вендора должна быть анализируемой. Для того, чтобы понимать можем ли мы в достаточной мере детектировать уязвимости, нужно знать что на самом деле умеет и не умеет VM решение.
3. Не будет одного VM-решения, которое продетектирует все уязвимости. Разные части инфраструктуры придется покрывать разными решениями. Детектирование уязвимостей отделяется от анализа, приоритизации и исправления.
4. Правильная инвентаризация активов. В организациях сейчас слишком много разнообразных активов. Для эффективного VM-а нужно покрыть их все. Причем необходимо понимать можем ли мы детектировать уязвимости для актива и если не можем, то что с этим делать? В качестве вариантов: покупать или разрабатывать механизмы для детекта, выводить актив из эксплуатации, принимать риски.
5. Правильная приоритизация уязвимостей. Слишком много CVE, слишком мало actionable информации. Необходимо уметь отличать экспулатабельное от неэксплуатабельного. Как это сделать непонятно, но видимо необходимо лучше работать с объектами относящимися к уязвимостям, в первую очередь с эксплоитами и сообщениями об атаках.
6. Автоматическое обновление активов. Дилемма: если не обновлять автоматом, это нагружает IT-администраторов массой однообразной работы, если обновлять автоматом, то непонятно кто будет нести ответственность в случае если что-то сломается. Решение: изменение архитектуры, чтобы обновляться было проще, обновляться постепенно, начиная с тестовых хостов.
7. Если не обновление, то что? Для уязвимостей VM решение должно знать набор компенсирующих мер, уметь их детектировать и желательно автоматически применять.
8. Обоснование комплаенс-требований. Для большей части CIS контролей не ясно как детектируемые мисконфигурации могут использовать злоумышленники в реальных атаках. Отсюда скепсис.