Под конец недели пришла в голову идея игрушки-обучалки по Vulnerability Management-у. Рабочее название "Бесконечный VM". 😁 По сюжету Олег Иванович Игнатов устраивается на работу в компанию ООО "ГазБанкСервис" и получает от своей начальницы, Анны Михайловны Смирновой, задачу - внедрить в организации Vulnerability Management процесс.
Как вам? Поиграли бы в такое?
11 ноября стартует ещё один онлайн-курс по Управлению Уязвимостями, на этот раз от компании Инсека. Продлится он 6 недель. Обещают 30 часов теории, 30 часов практики, стоимость удовольствия 64 800 ₽.
Судя по общему описанию модулей, из практики будет подробно про CVSS, эксплуатацию EternalBlue, сканирование инфры с помощью Nessus Essentials, сканирование веб-приложения с помощью Acunetix, сканирование периметра с помощью Metascan, экспорт данных из Vulners API для приоритизации уязвимостей. По теории вроде все основные темы заявлены. Про ФСТЭК-овские методики аж 1,5 модуля. 👍 На мой вкус было бы неплохо побольше добавить про Asset Management (про критичность активов вижу только в 5.1) и согласование безусловных регулярных обновлений.
Бесплатно дают доступ к 4 урокам: про публичные источники данных об уязвимостях (увидел там скриншот с моим телеграмм-каналом - приятно 😊), различные виды сканирований (внешнее, внутреннее, в режиме белого и чёрного ящика), лаба на сканирование уязвимостей (образы для VirtualBox c Nessus Essentials и Windows-таргетом дают готовые; по итогам нужно скинуть результаты детекта), особенности сканирования внешнего периметра и веб-приложений.
В целом, выглядит как вполне неплохой начальный курс для вкатывания в тему Vulnerability Management-а. Без особой жести и нагрузки. И вендерно-нейтральный. Почитать, потыкать лабы, понять нравится таким заниматься или не особо. Ну или как повод освежить знания и получить сертификат тоже почему бы и нет. 😉 Говорят, что самое эффективное обучение, когда большая часть материала вам уже знакома. Nessus Essentials с ограничением на 16 IP-адресов и без комплаенс-сканов это, конечно, совсем не для реальной жизни. Да и все продукты Tenable и Acunetix сейчас в России не особо актуальны. Но для учебных целей, в качестве первого опыта, почему бы и нет. А Metascan и Vulners это вполне себе практически полезные инструменты.
Если дадут доступ курсу, то тоже пройду и поделюсь впечатлениями. Мне это в первую очередь интересно со стороны "как люди учат VM-у", но вполне возможно почерпну там что-то такое, с чем раньше не сталкивался. 🙂
Больше курсов по Vulnerability Management-у хороших и разных!
У моего коллеги Дмитрия Фёдорова, автора телеграмм-канала "Кибербез образование", вышла обновленная диаграмма треков развития карьеры в ИБ и там есть отдельный трек по Управлению Уязвимостями.
Похоже на правду, но хотелось бы расставить акценты.
1. По мне так скиллы IT-администратора для VMщика первичны, т.к. именно с админами ему придётся контактировать больше всего. Важно, чтобы они не водили его за нос.
2. Необходимо разбираться в VM-ной методологии, т.к. ваш замечательный VM процесс, построенный из соображений реальной безопасности, должен как-то биться с требованиями регуляторов. Как минимум чтобы аудиты проходить.
3. Нужны ли Offensive скиллы? Неплохо бы для базового понимания контекста того, с чем мы боремся, и более адекватной приоритизации уязвимостей. Но помогут ли эти знания в ежедневном пропушивании фиксов для уязвимостей, о которых мы знаем только пару строк описания на NVD? Да вряд ли. 🌝 VM это не про докажи-покажи. С Offensive скиллами лучше в RedTeam.
Буду завтра читать лекцию по Управлению Уязвимостями в Физтехе. Уже во второй раз, первый был 5 лет назад. На этот раз удалённо. По случаю обновил учебную презентацию. В отличие от материала для Бауманского курса, выделил 4 примерно равные части:
🔹 Анализ Защищённости - уязвимости и детект уязвимостей
🔹 Управление Активами - избавляемся от хаоса в инфраструктуре
🔹 Управление Уязвимостями - построение процесса с фокусом на приоритизацию уязвимостей
🔹 Управление Обновлениями - всё, что касается исправления уязвимостей и взаимоотношений с IT
В основном переработал Управление Активами и Управление Уязвимостями. Кажется, получилось неплохо сопрячь РезБез/PTшный подход, методические указания регуляторов и собственные соображения. Пойдёт и для гостевых лекций, и понятно как это с пользой расширить до 4 отдельных лекций (а то и побольше). Доволен. 🙂
Кстати, Физтех под санкциями ЕС, США, Великобритании, Японии, Швейцарии и Новой Зеландии. Достойное заведение. 🙂👍
Прожектор по ИБ, выпуск №8 (22.10.2023). Записали очередной эпизод. Из основного: обсуждали Аврору ОС и отечественные смартфоны/планшеты, разобрали актуальные уязвимости с упором на Linux, немного коснулись регуляторики. К сожалению, у нас был какой-то сбой с видео, поэтому с 35:37 мы без камер. 🤷♂️
Мы это:
🔸 Александр Леонов, "Управление уязвимостями и прочее"
🔸 Лев Палей, "Вести из Палей"
🔸 Максим Хараск, "Global Digital Space"
00:00 Здороваемся и радуемся, что прошлый выпуск вроде неплохо смотрели 🙂
01:45 Лев поучаствовал в IVADAY 2023 и ему подарили отечественный планшет от БайтЭрг
08:40 Кажется, что смартфоны нa Авроре для физиков могут появиться в ноябре. Обсуждаем зачем и кому это вообще нужно
19:23 Телеканалы и операторов связи обяжут создать ИБ-подразделения
23:17 Auth bypass в Cisco IOS ХЕ (CVE-2023-20198)
27:47 13 эксплоитов ботнета Mirai
30:37 RCE уязвимость в JetBrains TeamCity (CVE-2023-42793)
33:56 Женщина сама себя сняла с электронной очереди в детский сад в Астане
35:37 Смотрим отчёт по октябрьскому Linux Patch Wednesday
37:52 GNOME уязвим перед RCE-атаками из-за ошибки в библиотеке libcue
41:20 Охарактеризуйте олдскульную ИБ одним словом и шлите нам свои мемасики
42:38 ФБР предупредила о хакерах-вымогателях, атакующих клиники пластической хирургии в США и мире
43:43 В CISA KEV появилась новая колонка, отвечающая за использование уязвимости в атаках шифровальщиков
45:13 Практический вопрос использования методики оценки уровня критичности уязвимостей ФСТЭК
49:43 Сходка "ПоИБэшечка: К истокам" 31 октября
51:50 Прощание от Mr. X
Получил неофициальное разъяснение от ФСТЭКа по поводу использования методики оценки уровня критичности уязвимостей. Это по вопросу расчета Iinfr, который я вчера поднимал:
"Изначально задумывалось, что уязвимость оценивается для всей ИС. Но, поскольку это не прописано в методике явно, то допускаются оба сценария оценки."
Т.е. основной вариант 1 (единый Iinfr для всей инфраструктуры/информационной системы, через максимизацию значения показателей) но можно использовать и 1, и 2 (считаем Iinfr независимо для каждого уязвимого актива).
Вопрос по поводу практического применения методики оценки уровня критичности уязвимостей ФСТЭК. Наверное у каждого, кто пробовал применять методику возникал вопрос. Ну хорошо, Iinfr зависит от типа уязвимого актива. А что делать, если у меня разные типы активов (хостов) подвержены данной CVE/БДУ уязвимости? Например, у меня уязвимость Windows, которая детектируется и на десктопах, и на серверах. Какое тогда значение показателя K выбирать? Или, например, у меня уязвимости подвержены и хосты на периметре, и глубоко во в внутрянке. Тоже непонятно какое значение показателя P выбирать.
Кажется, что здесь могут быть два основных подхода:
1. Единый Iinfr для всей инфраструктуры, через максимизацию значения показателей. То есть если уязвимость есть на десктопах и серверах, то берём значение K для серверов. Если есть хоть один уязвимый хост на периметре, то берем P для средств доступных из Интернет.
✅ Плюс: в итоге получаем один уровень критичности V для уязвимости, этакий "улучшенный CVSS" и используем его так, как использовали бы CVSS.
⛔ Минус: получается, что этот максимизированный V будет аффектить все активы и задавать требования по оперативности исправления. Если у нас уязвимость на 100 десктопах и одном сервере, то будьте любезны пофиксить её на десктопах с той же срочностью, что и на сервере. Ну или сначала пофиксить на сервере, и потом пересчитать Iinfr и, соответственно, V. Получим меньшую критичность и более комфортные сроки устранения уязвимости.
2. Считаем Iinfr независимо для каждого уязвимого актива. То есть сколько у нас активов (или групп однотипных активов), столько у нас будет Iinf и, соответственно, V.
✅ Плюс: получаем атомарность, практически избавляемся от неоднозначности.
⛔ Минус: это уже будет не "улучшенный CVSS", нельзя будет сказать, а какова критичность этой CVE/БДУ, т.к. для каждого уязвимого актива она может отличаться. В прочем, с CVSS может быть та же история, если активно подкручивать Temporal часть вектора для каждого актива (на практике я правда такое не встречал).
А как правильно? 🧐 Видится, что можно жить и с первым, и со вторым вариантом. Но было бы здорово получить разъяснения ФСТЭК о том, как оно изначально задумывалось, и на это уже ориентироваться.
Upd. Получил неофициальное разъяснение от ФСТЭК. Задумывался первый вариант, но можно оба.
Это мой личный блог. Всё, что я пишу здесь - моё личное мнение, которое никак не связано с моим работодателем. Все названия продуктов, логотипы и бренды являются собственностью их владельцев. Все названия компаний, продуктов и услуг, упоминаемые здесь, упоминаются только для идентификации. Упоминание этих названий, логотипов и брендов не подразумевает их одобрения (endorsement). Вы можете свободно использовать материалы этого сайта, но было бы неплохо, если бы вы разместили ссылку на https://avleonov.ru и отправили мне сообщение об этом на me@avleonov.com или связались со мной любым другим способом.