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

Алексей Лукацкий подсветил сегодня мои посты про Прожектор по ИБ и КиберДуршлаг

Алексей Лукацкий подсветил сегодня мои посты про Прожектор по ИБ и КиберДуршлаг. Очень приятно и большое спасибо! 😊 Накидаю тоже на тему "а зачем оно вообще надо?"

1. Мне кажется целеполагание "я делаю это для людей" хоть и имеет право на существование, но не особо эффективное и устойчивое, т.к. сводит процесс самовыражения в бесконечную погоню за расширением аудитории/лайками/подписками/репостами. Сам я как-то не размышляю о том, что будет лучше восприниматься аудиторией, текст или аудио/видео. Что хочу, то и делаю. В первую очередь для себя. 🙂

2. Для меня мои телеграмм-каналы и блог это прежде всего расшаренная записная книжка. Что-то показалось интересным - записал. Если вдруг понадобилось - нашёл и как-то использовал. Частенько приходят ко мне с каким-то вопросом, а я к краткому ответу добавляю "а вот у меня посты на эту тему были". Удобненько. То, что кто-то это читает и кому-то заходит, это безусловно приятное, но побочное явление.

3. Я вообще человек необщительный. Насколько я понимаю, некоторым людям нравится собираться, тусить, общаться, публично выступать и т.д. Они от этого заряд энергии получают. Вообще не моя тема. 🙂 Я на общение энергию только трачу, а потом в условной изоляции восстанавливаюсь. Поэтому энергию на общение я стараюсь экономить. Прожектор по ИБ в этом отношении идеален для меня. Созваниваюсь в онлайне на час и обсуждаю с интересными мне людьми интересные темы. Как побочный продукт получается видяшка, которой (после минимальной редактуры) можно поделиться. Т.е. у меня, как думаю и моих собеседников, основная мотивация приятно провести время в разговоре. А если это ещё и кто-то другой вдруг послушает и ему понравится, так вообще же отлично. Милости просим на наши посиделки. 🙂

4. Насколько я могу судить со стороны, КиберДуршлаг это более амбициозная активность. В этих разговорах с гостями-VMщиками, как мне кажется, нарабатывается общая база знаний российского Vulnerability Management-а, которая может быть затем осмыслена, переработана и использована в рамках множества интересных и полезных инициатив. Такие интервью это возможность вынести пласты скрытых знаний на поверхность, что, как мне кажется, было бы гораздо сложнее сделать в оффлайновой текстовой форме, без живой дискуссии и проговаривания. Так что очень жду этого подкаста в паблике. 🙂

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

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

Прожектор по ИБ, выпуск №2 (10.09.2023). Вчера вечером записали ещё один эпизод нашего новостного ток-шоу по ИБ. Компания у нас всё та же:

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

00:00 Вступление
01:08 Что случилось с бюджетами CISO? Обсуждаем опросы и исследования по ИБ
10:36 Байкалы выставлены на аукцион? Что с отечественными процессорами?
16:39 Atomic Heart в контексте ИБ. Впечатления от игры и книги Предыстория «Предприятия 3826»
26:39 Р-ФОН, ОС Аврора и "понты нового времени"
36:48 Утечка из МТС Банка?
45:04 Мошенники размещают QR-коды возле школ
50:18 Qualys TOP 20 эксплуатируемых уязвимостей
54:18 Прощание от Mr. X

Что нам стоит Vulnerability Management решение построить?

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

Что нам стоит Vulnerability Management решение построить? В прошлом году у меня была серия постов о сложности создания своего VM-продукта (часть 1, часть 2, часть 3). Сегодня посмотрел выступление Михаила Козлова на недавнем IT-пикнике, которое тоже раскрывает эту тему. Михаил руководит продуктом MaxPatrol VM в Positive Technologies. И, кстати, у него тоже есть телеграмм-канал @KozTV, заходите подписывайтесь! 😉 Первая половина его выступления это подводка про уязвимости для широкой аудитории, а вторая половина, с 9:48, это срыв покровов про то как устроена разработка MaxPatrol VM, какие там есть нестандартные команды, чем ребята занимаются, как результаты их работы между собой стыкуются. Мне кажется, это должно быть интересно и для клиентов, чтобы осознавать масштаб и сложность того, что происходит под капотом MP VM, и для разработчиков VM-решений (текущих и будущих). 😉

Какие команды были упомянуты:

🔹Команда пентестеров. Их экспертиза используется для определения трендовых уязвимостей.
🔹Команда пайплайнов. Разрабатывают роботов, которые занимаются сбором информации об уязвимостях. Уже более 150 роботов работает! Тоже когда-то этим занимался для наполнения базы знаний MP8. 🙂
🔹Команда сбора инвентаризационных данных из систем (для работы сканирующего агента, модуля Аудит, модуля Пентест). Разные специализации, т.к. разные требования к реализуемым проверкам.
🔹Команда экспертов по системам.
🔹Команда ML. Определяют кандидатов на трендовые уязвимости.
🔹Команда ядра MaxPatrol VM. Отвечают за масштабирование системы.

Кстати, как видим на скрине, пока сбор данных об активах исключительно безагентный, но полноценных агентов тоже ждём. 🙏

Насчёт медийной активности по Vulnerability Management-у, о которой вчера писал

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

Насчёт медийной активности по Vulnerability Management-у, о которой вчера писал. Раз уж Михаил уже засветил её в своём канале, то тоже не буду интригу нагнетать. 🙂 Речь о новом еженедельном подкасте КиберДуршлаг от Positive Technologies. Подкаст будет целиком посвящён Vulnerability Management-у. Меня позвали туда гостем в первый выпуск. Обсудили кучу тем, начиная от обучения в ВУЗе (как обычно, попиарил курс по ТОИБАСу), заканчивая размышлениями о необходимости сертификации сканеров по функциональным возможностям и качеству детектирования уязвимостей. 🫣 Не знаю, что в итоге получится после монтажа, но процесс записи был увлекательным, час пролетел незаметно. Судя по гостям, которых вы можете на фотках видеть, другие эпизоды тоже должны быть огонь! 🔥 Собираюсь смотреть. 🍿🙂

PS: Гостям там, среди прочего, дарили ведро. Типа "не будь дуршлагом, будь ведром". Вы когда-нибудь ездили через всю Москву на общественном транспорте с оцинкованным ведром? Непередаваемые ощущения, могу вам сказать. 😁

Постоянное офигивание ITшников это нормальное следствие работающего Vulnerability Management процесса

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

Постоянное офигивание ITшников это нормальное следствие работающего Vulnerability Management процесса. В чём вообще задача процесса Управления Уязвимостями? В том чтобы в инфраструктуре не было критичных уязвимостей и ими не мог воспользоваться злоумышленник. Именно за это VM-щику платят деньги и за это он отвечает (при плохом раскладе вплоть до уголовки 🤷‍♂️). А для того, чтобы таких уязвимостей в инфраструктуре не было, их нужно (сюрприз-сюрприз!) исправлять. 🙂 Чаще обновлениями, реже переконфигурированием.

Если уж в организации есть какой-никакой процесс управления активами, то покрыть эти активы детектами и открыть бесконечный поток новых обнаруженных уязвимостей дело выполнимое. Насколько мощным будет этот поток? Если брать совсем минимум, то с Patch Tuesday обязательно прилетит KB-шная RCE-шка в Windows ядре или стандартном компоненте, а также RCE в Linux-овом ядре или стандартной утилите. По сетевым устройствам возможно пореже - раз в 2 месяца. Вот и считай - ежемесячное обновление всех Linux/Windows хостов и двухмесячное для всех сетевых устройств. И это с необходимостью эти обновления тестировать перед накаткой. 👨‍🏫 Это минимум!

Класс, да? Каждый админ/девопс будет просто счастлив открывающимся перспективам дополнительно свалившейся на него со стороны ИБшников работы! 🙂 Как и его руководители вплоть до CIO/CTO. И будьте уверены, что они приложат все возможные усилия и все доступные меры корпоративной борьбы, чтобы этого замечательного VM-процесса в итоге не случилось. Не говоря уж о таких мелочах как разнообразные "словесные интервенции". 📣😏

Крепись, VM-щик! Не позволяй выхолостить процесс!

Qualys выпустили свой ТОП-20 наиболее эксплуатируемых уязвимостей (24 CVE)

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

Qualys выпустили свой ТОП-20 наиболее эксплуатируемых уязвимостей (24 CVE). Я их выписал. Стало интересно, а есть ли что-то, что не входит в недавние англосаксонские списки. Оказалось, что не входят 12 CVE, т.е. ровно половина:

CVE-2012-0158
CVE-2012-0507
CVE-2012-1723
CVE-2013-0074
CVE-2014-6271
CVE-2017-0143
CVE-2017-0144
CVE-2017-0145
CVE-2017-8570
CVE-2018-0802
CVE-2018-8174
CVE-2019-2725

Это #Shellshock, MS17-010, 3 RCE для Office, 2 RCE для VBScript и Silverlight, 3 уязвимости для Oracle Java и WebLogic. Видимо англосаксы намерили, что в 2022 это было уже не актуально. 🤷‍♂️

Выпустил отчёты Vulristics:

🗒 Qualys TOP 20 2023
🗒 Qualys TOP 20 2023 NOT in Joint report

Самая важная часть Vulnerability Management-а не имеет прямого отношения к уязвимостям

6 комментариев

Самая важная часть Vulnerability Management-а не имеет прямого отношения к уязвимостям. Подумал, что если суммировать весь опыт практического внедрения VM-а и выделить самое важное, то это будет оно.

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

По закону подлости именно там будет основное адище и именно там будут резвиться злоумышленники. А когда произойдёт инцидент, VM-щику будет нечего сказать кроме "а я не знал, что у нас такие активы есть" и вид он будет иметь весьма бледный. 😱

К существующей в организации системе инвентаризации должно быть максимальные недоверие. У вас действительно нет неучтённых активов? А если найду? (с)

Вопросы навскидку к системе инвентаризации:

🔹 А филиалы все? А дочерние/купленные компании все?
🔹 А десктопы все? И ноутбуки все? И у удалёнщиков, которые по VPN-у не подключаются? И на всех ОС?
🔹 А сервера все? И которые не в домене? И которые в закрытых сетках? И которые в облаке? И которые на других внешних хостингах когда-то подрядчиками развернуты? А ERP-система? А Kubernetes?
🔹 А сетевые устройства все?
А вот телефония? А вот камеры? А вот СКУДы? А вот экраны в переговорках? А вот система бронирования переговорок?

Можно до бесконечности продолжать.

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

Когда есть информация, что активы в принципе есть, можно копать вглубь:

🔸 А кто ответственный за актив? Кто должен обновлять этот актив? С какой периодичностью это делается? Что будет, если обновление по факту не производится?
🔸 А что это за актив? Какая у него критичность?
🔸 А можем ли мы сканировать этот актив на уязвимости? А если не можем, то как мы будем с этим активом дальше жить? Откажемся от использования актива, купим сканер, напишем свой сканер, будем руками проверять?
🔸 Если это сервер/десктоп можно уже инвентаризацией софтов заниматься и тоже прикидывать есть ли у нас средства для детектирования уязвимостей для этих софтов и как жить, если нет. Откажемся от использования софта, купим сканер, напишем свой сканер, будем руками проверять?

Посыл такой:

➕ С более-менее адекватной инвентаризацией активов и возможностью транслировать политики в сторону IT нам (крамола!) возможно и детектировать уязвимости не так и важно. 🙄 Видим хосты и то, что они полностью обновляются раз в месяц - отлично. Скорее всего там всё +- нормально. Если видим хост с EOL операционкой, то тоже сканировать на уязвимости излишне - нужно мигрировать. Если видим хост, который не обновлялся год, то тоже сканировать смысла нет - критичных уязвимостей за год гарантированно набежит, нужно разбираться почему процесс регулярного обновления не сработал.

➖ А вот когда у нас нормальной инвентаризации активов нет, то VM-процесс будет напоминать мальчика, который увлеченно ковыряет в грязной луже палочкой. Ну, чего-то там сканим, как-то эти сканы разбираем, какие-то таски на обновление заводим, как-то эти таски закрывают. Можно график нарисовать. Насколько этой активности достаточно и насколько она вообще реальный уровень защищенности повышает - да пёс его знает. Соблазнительно сказать: а вот мы пока на ограниченном скоупе запустимся, а потом - ух! Как расширимся на всё! Очень маловероятно, что это расширение действительно произойдет, т.к. в итоге мало кто в этом расширении скоупа оказывается заинтересован. Так что гораздо лучше изначально правильно акценты расставлять.

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

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