Архив рубрики: Темы

Закончил обучение на курсе "Управление Уязвимостями" от Inseca

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

Закончил обучение на курсе Управление Уязвимостями от Inseca

Закончил обучение на курсе "Управление Уязвимостями" от Inseca. В целом, ожидания оправдались. 🙂 Опишу то, что понравилось и то, что можно было бы улучшить.

1. Практические домашние работы. 👍 Их было 11 штук. С учётом того, что курс шёл 6 недель, получалось в среднем 2 работы в неделю. Они рассчитаны max на 1-2 часа, так что делать по вечерам было комфортно.

Большая часть домашних работ строилась вокруг 3 стендов в VirtualBox:

🔻 Виртуалка с Kali на которую нужно было поставить Nessus Essentials
🔻 Виртуалка с необновлённым Windows уязвимая к EternalBlue
🔻 Виртуалка с необновлённой Ubuntu и развёрнутым DWVA

Работы были такие:

🔹 Развернём сканер уязвимостей
🔹 Проэксплотируем EternalBlue с помощью Metasploit, забёрем хэши и побрутим их
🔹 Посканим виртуалки в режиме "чёрного ящика"
🔹 Настроем учётки на виртуалках и посканируем их с аутентификацией
🔹 Посканим DVWA Nessus-ом и Acunetix-ом и посмотрим разницу
🔹 Выгрузим уязвимости из Nessus через API, обогатим отчёты данными по эксплоитам и активной эксплуатации
🔹 Пофиксим уязвимости через обновление или отключение уязвимых сервисов, проверим, что они не детектируются или не эксплуатируются

Ещё 2 работы не были завязаны на стенды. В одной нужно было составить CVSS Base Vector-ы по описаниям уязвимостей. В другой нужно было по версии софта найти уязвимости (поиск по CPE), а затем выделить для них эксплуатабельные (эта задачка хорошо решалась с помощью Vulristics 😉).

➡️ Вопрос: можно ли проделать такие учебные активности самостоятельно? Конечно. Но это искать надо, а тут уже готовые стенды, подробно описанные методички (кроме подзадачек со звёздочкой), проверка преподавателем. Сервис. 🙂

Как видно из описания работ, упор на практическое детектирование, приоритизацию и исправление уязвимостей. Без привязки к решениям VM-вендоров.

2. Вебинары-семинары. 👍 Их было 5 штук. Проходили по субботам в 12:00. Длительность около 1,5 часов. Дмитрий Топорков рассказывал нам какую-то тему, касающуюся текущего модуля и в процессе можно было задавать вопросы, дискутировать, обмениваться опытом. Один вебинар был с Давидом Ордяном из Metascan, я о нём уже писал подробнее. Получалось лампово, посещал эти онлайн-созвоны с удовольствием.

3. Тьюторство. 👍 Каждую неделю в телегу скидывали табель с принятыми заданиями и посещёнными вебинарами. При открытии модуля скидывали оповещение с темой модуля и количеством домашек. За три дня до дедлайна оповещение, что надо домашку сдавать. Оповещения о вебинарах за день и за час. Вроде мелочи, а забота приятна. 😇 Ну и Дмитрий очень оперативно домашки проверял. 🔥

4. Контент. 👌 Большая часть контента - текст. Скринкасты в основном были доп. материалом для практических занятий. Я к текстовому контенту хорошо отношусь, т.к. его удобнее быстро просматривать. Тексты качественные. Не скажу, что по содержанию для меня были какие-то откровения, но лишний раз перечитать было прикольно. Тем, кто видит подобный контент в первый раз, должно быть интересно. Порог входа небольшой, всё разжёвывается подробно.

5. Что улучшить? 🤔 Исходя из концепции, что это базовый вендерно-нейтральный курс с фокусом на низкоуровневую работу с уязвимостями напрашивается следующее:

🔹 Добавить лабу для работу с опенсурсным решением, на котором можно построить процесс управления уязвимостями, например, Faraday Security или DefectDojo
🔹 Выделить больше времени на разбор веб-уязвимостей DVWA
🔹 Добавить про анализ безопасности конфигураций, например с помощью OpenSCAP

В целом, неплохо бы дать более цельное представление как строить VM-процесс в организации с использованием конкретных тулов. Но как курс для старта вполне норм. 👍

Спасибо коллегам из Inseca за предоставленный доступ к курсу!

PS: Также мне подарили термокружку Inseca. 😅 Я в одном из Прожекторов отмечал, что термокружки очень уж часто дарят. Но эта кружка прям норм. 🔥 Добротная, прорезиненная где надо, без каких-то ненужных наворотов. Вещь! Передаривать не буду, оставлю себе. За кружку тоже спасибо! 🙂

Про определение имени уязвимого продукта по CPE в Vulristics

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

Про определение имени уязвимого продукта по CPE в Vulristics

Про определение имени уязвимого продукта по CPE в Vulristics. Для тех, кто не в курсе, моя утилита, кроме прочего, решает задачку получения для CVE-шки описательной строки "тип уязвимости - уязвимый продукт". В итоге пришёл к выводу, что хоть метод определения имени уязвимого продукта по CPE хорош своей скоростью и универсальностью, но в качестве основного он не годится.

Проблема не в самих CPE, а в том как их используют в NVD: иногда для CVE их слишком много, иногда их вообще нет, иногда они нерелевантные. Возьмём, для примера, Log4Shell (CVE-2021-44228). Согласитесь, что для этой уязвимости было бы неплохо в качестве уязвимого продукта получить Apache Log4j2 или хотя бы Apache Log4j. И он там даже есть в виде a:apache:log4j. Но в общем случае автоматически выделить именно этот CPE идентификатор среди десятков других, связанных с этой CVE, задача такая себе. 🤷‍♂️ Теоретически это можно было бы делать, если бы была какая-то иерархия CPE, анализируя которую можно было бы понять, что a:apache:log4j имеет больший приоритет, т.к. это уязвимая либа, которую использую другие уязвимые продукты. Но этого нет. Тот же официальный CPE dictionary это просто перечень CPE идентификаторов со ссылками на сайты вендоров и прочие сайты без какого-либо дополнительного полезного контекста.

Поэтому основным способом определения имени уязвимого продукта остаётся анализ текстового описания по ключевым словам. Несмотря на все недостатки в виде относительно долгого времени работы (которое увеличивается с увеличением количества описанных продуктов и, соответственно, ключевых слов), фолсов первого и второго рода, необходимости наполнять базу продуктов ручками и т.п. Разумеется с возможными оптимизациями там, где это возможно (например, для генеренных описаний уязвимостей Microsoft).

А детект по CPE оставить на случай, когда анализ текстового описания ничего не дал и лучше попробовать показать хоть что-то, чем Unknown Product.

Прожектор по ИБ, выпуск №17 (23.12.2023): Слово пацана или стих от Mr

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

Прожектор по ИБ, выпуск №17 (23.12.2023): Слово пацана или стих от Mr. X

🔸 Александр Леонов, "Управление уязвимостями и прочее"
🔸 Лев Палей, "Вести из Палей"
🔸 Максим Хараск, "Global Digital Space"

Перебрались для записи эпизода с ТГ на платформу VK Звонки. По-моему вполне удачно. В первый раз выходим в 1080p! 🙂 Это последний эпизод в этом году, следующий выпуск планируем записать уже в январе.

00:00 Здороваемся и смотрим статистику по предыдущему эпизоду
02:20 Злоумышленники получили доступ к корпоративным системам компании MongoDB
05:35 Декабрьский Linux Patch Wednesday
10:04 ФСТЭК России 50 лет
12:32 CISA BOD 23-01 и аналогичные инициативы отечественных регуляторов
20:41 Презентация POCA Мобайл и Р-ФОН
26:29 Ежегодная предновогодняя Поибешечка
32:12 Хакер, который участвовал во взломе Rockstar Games, останется в закрытой клинике до конца жизни
37:32 Сериал "Слово пацана"
40:27 Производитель косметики EOS выпустил кодовый замок для своего лосьона, чтобы мужчины не могли пользоваться им
44:56 Правительство займётся безопасностью видеоигр
48:22 Запрет на использование телeфонов в школе
51:22 В Санкт-Петербурге проведены аресты по делу о телефонном мошенничестве
53:20 Так совпало - Гарвард и ГРЧЦ Роскомнадзора поделились своими взглядами на развитие ИИ в 2024-м году
59:24 DevSecOps Maturity Model 2023
1:01:25 Прощание в стихах от Mr. X

Декабрьский Linux Patch Wednesday

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

Декабрьский Linux Patch WednesdayДекабрьский Linux Patch WednesdayДекабрьский Linux Patch WednesdayДекабрьский Linux Patch WednesdayДекабрьский Linux Patch WednesdayДекабрьский Linux Patch WednesdayДекабрьский Linux Patch Wednesday

Декабрьский Linux Patch Wednesday. Вчера была третья среда месяца, поэтому смотрим на уязвимости Linux. Основная беда прошлого месяца с непродетектированными продуктами практически решена. 🎉 Я реализовал детекты по сокращённому CPE-идентификатору (тип:вендор:продукт) в Vulristics. Смотрю как оптимальнее совместить детекты по CPE и по текстовому описанию, но уже гораздо информативнее. 🙂

Всего 158 уязвимостей. Только для 16 уязвимостей не определился продукт, из них 11 это пустые заглушки-кандидаты.

В топе:

🔻 RCE - Perl (CVE-2022-48522). Есть ссылка на NVD типа Exploit. CVSS 9.8.
🔻 RCE - Safari (CVE-2023-42917). В CISA KEV.
🔻 Memory Corruption - Chromium (CVE-2023-6345). В CISA KEV, Skia.
🔻 RCE - Redis (CVE-2022-24834). Эксплоит на гитхабе.
🔻 Memory Corruption - Safari (CVE-2023-42916). В CISA KEV.

Всего 29 уязвимостей с потенциальными эксплоитами. В основном это ссылки из NVD типа "Exploit", относиться к ним следует с долей скепсиса.

🗒 Vulristics report

По случаю изучил прошлогодний CISA BOD 23-01 "Улучшение видимости активов и обнаружение уязвимостей в федеральных сетях"

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

По случаю изучил прошлогодний CISA BOD 23-01 Улучшение видимости активов и обнаружение уязвимостей в федеральных сетях

По случаю изучил прошлогодний CISA BOD 23-01 "Улучшение видимости активов и обнаружение уязвимостей в федеральных сетях". Собирался больше года назад, а возможность представилась только сейчас. Интересная тема с точки зрения контроля VM-процесса в организациях со стороны регулятора.

Допустим вы CISA, т.е. приблизительный американский аналог нашего ФСТЭКа. У вас есть подопечные - американские федеральные агентства. Их много, сложно даже сказать сколько. От 60 до 430+. Вы для них подсвечиваете критичные уязвимости в активной эксплуатации, по мере сил, устанавливаете к какому сроку их нужно фиксить. А с безопасностью и с уязвимостями у этих федералов всё равно полный швах. Что делать?

Безопасники CISA почесали голову и решили - давайте насаждать в федеральных агентствах базовые ИБ-процессы.

🔻 Во-первых, пусть ищут активы в своих сетках. Пофиг как. Хоть активным сканированием, хоть снифанием трафика, хоть через API какую. Главное регулярно, раз в неделю. Управление активами - это база.

🔻 Во-вторых, пусть эти активы сканируют на уязвимости. И чтобы не блекбоксом, а нормально, агентно или с привилегированной учёткой. Чтобы скан запускался каждые 2 недели со свежей базой детектов уязвимостей. Не успеваете всё просканить за 2 недели? А пофиг, всё равно запускайте следующий скан. Главное регулярность.

Тю? И всё? Просто рекомендации, выполнение которых никак не проверишь? 😏

Нет, не всё. 😈

🔻 В третьих, результаты сканирования активов требуют складывать в шайтан-поделье CDM Agency Dashboard не позже чем за 72 часа после завершения сканов на уязвимости. Откуда эти данные передаются в CDM Federal Dashboard для изучения аналитиками CISA. Также требуется скидывать "vulnerability enumeration performance data", т.е. по сути логи сканов, чтобы видно было насколько результаты сканирования адекватны.

Таким образом, регулятор очень оперативно видит состояние инфраструктуры органа/организаций, может самостоятельно делать выводы о выполнении требований по исправлению уязвимостей и проводить необходимые стимуляции. 🥕

Есть, конечно, и странности. Почему-то не написано напрямую, что инфу по обнаруженным активам тоже нужно CISA скидывать и что адекватность детектирования активов нужно подтверждать. Но, возможно, это подразумевается или добавят потом. Вообще документ прикольный, много тонких технических моментов разъясняется по-человечески.

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

Отчитал лекцию по Управлению Уязвимостями в Росатоме

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

Отчитал лекцию по Управлению Уязвимостями в Росатоме

Отчитал лекцию по Управлению Уязвимостями в Росатоме. Зарегистрировалось около ста человек. Раньше я этот материал читал только студентам-безопасникам. А тут мало того, что далеко не студенты, а взрослые опытные люди, так в основном ещё и из IT. Учитывая, что у меня значительная часть контента про то как мотивировать IT-шников наводить порядок в активах и как противостоять их попыткам саботажа VM-процесса ("как челобитную царю подаёшь" и "докажи-покажи") было волнительно как это зайдет на такую аудиторию. 🙂 Но прошло хорошо. Вопросы были конструктивные. VM-щики, конечно, тоже не всегда ангелы. 😈

Чтобы соответствовать названию "мастер-класс" уделил больше времени разбору примеров уязвимостей, способов их детекта и приоритизации (Vulners Linux Audit, Scanvus, OpenSCAP, ScanOVAL, Vulristics).

Большое спасибо отраслевой IT-школе Росатома за приглашение и Positive Education за организацию!

Запись буду использовать как основу для книги. 😉

ФСТЭК России 50 лет!

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

ФСТЭК России 50 лет!

ФСТЭК России 50 лет! Сегодня день основания Гостехкомиссии СССР (18 декабря 1973), которая в итоге превратилась во ФСТЭК. С праздником, коллеги! 🎉

ФСТЭК это главный российский регулятор в области Управления Уязвимостями:

🔸 Руководство по организации процесса управления уязвимостями в органе (организации)
🔸 Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств
🔸 База угроз и уязвимостей; регламент добавления
🔸 Бесплатный сканер уязвимостей ScanOVAL
🔸 ГОСТ Р 56546-2015 Классификация уязвимостей информационных систем
🔸 ГОСТ Р 56545-2015 Правила описания уязвимостей
🔸 Методика тестирования обновлений безопасности программных, программно-аппаратных средств