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

У моего коллеги Дмитрия Фёдорова, автора телеграмм-канала "Кибербез образование", вышла обновленная диаграмма треков развития карьеры в ИБ и там есть отдельный трек по Управлению Уязвимостями

У моего коллеги Дмитрия Фёдорова, автора телеграмм-канала "Кибербез образование", вышла обновленная диаграмма треков развития карьеры в ИБ и там есть отдельный трек по Управлению Уязвимостями.

Похоже на правду, но хотелось бы расставить акценты.

1. По мне так скиллы IT-администратора для VMщика первичны, т.к. именно с админами ему придётся контактировать больше всего. Важно, чтобы они не водили его за нос.

2. Необходимо разбираться в VM-ной методологии, т.к. ваш замечательный VM процесс, построенный из соображений реальной безопасности, должен как-то биться с требованиями регуляторов. Как минимум чтобы аудиты проходить.

3. Нужны ли Offensive скиллы? Неплохо бы для базового понимания контекста того, с чем мы боремся, и более адекватной приоритизации уязвимостей. Но помогут ли эти знания в ежедневном пропушивании фиксов для уязвимостей, о которых мы знаем только пару строк описания на NVD? Да вряд ли. 🌝 VM это не про докажи-покажи. С Offensive скиллами лучше в RedTeam.

Буду завтра читать лекцию по Управлению Уязвимостями в Физтехе

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

Буду завтра читать лекцию по Управлению Уязвимостями в Физтехе. Уже во второй раз, первый был 5 лет назад. На этот раз удалённо. По случаю обновил учебную презентацию. В отличие от материала для Бауманского курса, выделил 4 примерно равные части:

🔹 Анализ Защищённости - уязвимости и детект уязвимостей
🔹 Управление Активами - избавляемся от хаоса в инфраструктуре
🔹 Управление Уязвимостями - построение процесса с фокусом на приоритизацию уязвимостей
🔹 Управление Обновлениями - всё, что касается исправления уязвимостей и взаимоотношений с IT

В основном переработал Управление Активами и Управление Уязвимостями. Кажется, получилось неплохо сопрячь РезБез/PTшный подход, методические указания регуляторов и собственные соображения. Пойдёт и для гостевых лекций, и понятно как это с пользой расширить до 4 отдельных лекций (а то и побольше). Доволен. 🙂

Кстати, Физтех под санкциями ЕС, США, Великобритании, Японии, Швейцарии и Новой Зеландии. Достойное заведение. 🙂👍

Прожектор по ИБ, выпуск №8 (22.10.2023)

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

Прожектор по ИБ, выпуск №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

Получил неофициальное разъяснение от ФСТЭКа по поводу использования методики оценки уровня критичности уязвимостей

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

Получил неофициальное разъяснение от ФСТЭКа по поводу использования методики оценки уровня критичности уязвимостей. Это по вопросу расчета Iinfr, который я вчера поднимал:

"Изначально задумывалось, что уязвимость оценивается для всей ИС. Но, поскольку это не прописано в методике явно, то допускаются оба сценария оценки."

Т.е. основной вариант 1 (единый Iinfr для всей инфраструктуры/информационной системы, через максимизацию значения показателей) но можно использовать и 1, и 2 (считаем Iinfr независимо для каждого уязвимого актива).

Вопрос по поводу практического применения методики оценки уровня критичности уязвимостей ФСТЭК

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

Вопрос по поводу практического применения методики оценки уровня критичности уязвимостей ФСТЭК. Наверное у каждого, кто пробовал применять методику возникал вопрос. Ну хорошо, 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. Получил неофициальное разъяснение от ФСТЭК. Задумывался первый вариант, но можно оба.

Расписал таймкоды, комментарии и ссылки на дополнительные материалы для выпуска подкаста "КиберДуршлаг" про Управление Уязвимостями со мной

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

Расписал таймкоды, комментарии и ссылки на дополнительные материалы для выпуска подкаста "КиберДуршлаг" про Управление Уязвимостями со мной.

00:00 Паша торжественно бьёт в дуршлаг, здороваемся, я рассказываю чем занимаюсь и пиарю свои телеграмм-канальчики. 🙂
01:32 Как я начал заниматься безопасностью и VM-ом. Рассказываю как я довольно случайно прошёл на ИУ8 МГТУ Баумана по собеседованию для медалистов. VM-ом начал заниматься из-за первой работы в Позитиве и вот так дальше пошло-поехало.
04:06 Пригодился ли мне универ? Рассказываю, что, как и многие, не понял прикол с дикими объемами дискретки. Но безусловно базу дало. Не устаю пиарить курс Валентина Цирлова по ТОИБАС.
06:00 Начинаем с определения уязвимости. Определяю как багу, которую может использовать злоумышленник. Миша накидывает про мисконфигурации. Я вспоминаю про CCE и CCSS.
08:23 Классическая тема: сканеры уязвимостей, Vulnerability Management решения, Vulnerability Management процесс. Выражаю скепсис по поводу принципиальной разницы между сканером уязвимостей и VM-решением. Вспоминаю про шведов с Антифишингом в VM-ме. Паша накидывает: а нужен ли в VM-е контроль целостности? VM-процесс он про исправление уязвимостей, причём силами IT.
13:36 Миша спрашивает: "Что входит в процесс управления уязвимостями"? По факту на вопрос не отвечаю, а рассказываю почему основа VM-а это управление активами. 😏
18:59 Обсуждаем CVSS и методику оценки критичности уязвимостей ФСТЭК. Вспоминаю ОСОКу. Трендовых уязвимостей тоже касаемся. Агитирую за безусловный патчинг, указывая на куцые описания уязвимостей из MS Patch Tuesday. Вспоминаю про Linux Patch Wednesday.
30:38 Безусловные обновления плохо сочетаются с требованиями по проверке патчей западного ПО, включая open source. Выход? Импортозамещение! Рекомендательный алгоритм НКЦКИ и методика оценки обновлений ФСТЭК, что из этого более приоритетно? Вопрос к методологам.
34:40 Призываем отечественных вендоров публиковать уязвимости.
37:38 Vulnerability Management процесс в организации сложно построить? Какие люди нужны? Организации разные. Начинать нужно с руководства. Рассказываю про докажи-покажи.
43:21 Можно ли построить VM-процесс на open source решениях? Вполне реально сканить порты, детектить линуксовые уязвимости по пакетам. Но есть ограничения детектирования и спросить вам будет не с кого. С Windows всё плохо.
48:16 Обсуждаем уход западных VM-решений с российского рынка. Как это было?
50:17 Обсуждаем должен ли Compliance Management входить в VM и в чём проблема текущей реализацией CM в VM решениях и текущих стандартов конфигурирования.
56:52 Какая функциональность должна быть реализована в VM решении это вопрос регуляторный. Может нужна сертификация? 🤔
58:24 Крутое VM-решение для каждого клиента своё. Кому-то нужна "коробка", кому-то только детекты.
01:02:11 Вопрос VM-вендорам: почему такая разница в результатах детектирования между решениями от двух вендоров? Может сертификация нужна? 🤔 Паша и Миша накидывают кейсы по MS, которые могут давать расхождения. Хорошо, когда логика детектирования прозрачна и доступна для изучения.
01:07:00 Как я вижу развитие VM решений. Хотелось бы хорошего качества детектирования с фокусом в сторону импортозамещающей инфры. Также хотелось бы возможностей по добавлению уязвимостей со стороны и собственных детектов.
01:11:09 Торжественное вручение мне ведра с подарками. 😁

Подписывайтесь на КиберДуршлаг на удобных вам платформах по ссылкам в официальном посте!

Ещё одно размышление после конференции R-Vision, про таски на исправление уязвимостей

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

Ещё одно размышление после конференции R-Vision, про таски на исправление уязвимостей. На этой теме был акцент и в основном выступлении про R-Vision VM, и в кейсе НРД. Несмотря на то, что таски могут быть предметом долгих разбирательств IT и ИБ, имхо, таски должны быть. Почему?

1. Слова (как и дашборды, доступ для IT-шников в VM-систему, нотификации в почте/мессенджерах и прочее) к делу не пришьёшь. А тут формальная задачка. С критичностью, исполнителем и датой заведения. И для аудитов есть, что показать, и в случае инцидента пригодится. 😏
2. Вполне вероятно, что в организации уже внедрены процессы оценки эффективности работы подразделений на основе анализа статусов тасков, можно и исправление уязвимостей оценивать по аналогии.
3. Руководство ФСТЭК требует заводить таски. Можно, конечно, рассуждать об обязательности этого руководства, но если можно соответствовать, то лучше соответствовать. 😉

Какие это должны быть таски?

Имхо, это должны быть атомарные таски 1 актив и 1 уязвимость. Почему так?

1. Удобно отслеживать реальный прогресс. Иначе, если сделать связь один ко многим или многие ко многим, как абсолютно справедливо заметил в своём вчерашнем докладе Олег Кусеров, это будет приводить к большому количеству частично выполненных тасков.
2. Удобно менять критичность таска в случае изменения критичности уязвимости или актива.
3. Удобно делать интеграцию с системами управления уязвимостями. По сути таск просто привязывается к статусу уязвимости на активе.

Сколько таких тасков будет? Допустим, у нас для одного Linux хоста за месяц выходят 100 новых уязвимостей. Допустим, у нас 10000 Linux хостов в инфраструктуре. Получается миллион тасков за месяц. 12 миллионов в год. И это только Linux!

Отсюда следует:
1. Система для учёта тасков должна быть готова к таким объемам.
2. Вручную работать с такими тасками практически нереально.

Таски должны заводиться и закрываться автоматически по результатам детектирования уязвимостей.

✅ Таким образом ITшники, которые будут выполнять регулярный патчинг своих систем, возможно вообще без оглядки на продетектированные уязвимости, будут, в целом, автоматически соответствовать требованиям по исправлению уязвимостей и будут молодцы. 👍

❓А те ITшники, которые считают, что полное регулярное обновление им не подходит, смогут разбираться с каждой уязвимостью отдельно и тем способом, который сочтут нужным. Включая их ручную обработку. 🤷‍♂️ Может в процессе они скорректирую свои взгляды относительно регулярных обновлений. 😏

Александр В. Леонов

Управление Уязвимостями и прочее