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

Следующим мероприятием, в котором я собираюсь поучаствовать, будет форум "ПРОВЕРКА НА ПРОЧНОСТЬ: практика анализа защищённости"

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

Следующим мероприятием, в котором я собираюсь поучаствовать, будет форум ПРОВЕРКА НА ПРОЧНОСТЬ: практика анализа защищённости

Следующим мероприятием, в котором я собираюсь поучаствовать, будет форум "ПРОВЕРКА НА ПРОЧНОСТЬ: практика анализа защищённости". Пройдёт это мероприятие 14 октября в "Холидей Инн Сокольники". Фактически это спин-офф "Территории Безопасности" с фокусом на работе с уязвимостями во всех проявлениях. 😇

В программе - дискуссии, доклады и мастер-классы о реальной оценке защищённости, управлении уязвимостями (и экспозициями), анализе поверхности атаки, выборе методов проверки (аудит, пентест, Red Team, Purple Team, Bug Bounty), применении ИИ и автоматизации, метриках, защите АСУ ТП, проверке подрядчиков и правовых аспектах этичного хакинга.

В общем, наконец-то мы дождались большой нейтральной конфы, где VM/CTEM будет непосредственно в фокусе, а не где-то сбоку. 🤩🥳

Мои активности:

🔹 Выступлю с 20-минутным докладом "Трендовые уязвимости в 2026 году: как определить, что действительно важно". Расскажу о различных методах оценки критичности уязвимостей, о трендовых уязвимостях текущего года и о том, как мы в Positive Technologies их отбираем. 😉🤫

🔹 Буду модерировать часовой круглый стол "VM, DETECTION & RESPONSE: Придёт ли к нам реальная автоматизация?". Побеседуем о перспективном и наболевшем в VM/VMDR/CTEM. Со стороны вендоров заявлены Андрей Никонов из Vulns io VM, Дмитрий Черняков из RedCheck, Кирилл Евтушенко из Кауч. Со стороны клиентов заявлены Владимир Мельников из SOC Билайн, Дарина Кривошеева из VK, Иван Советкин из МТС Банк. Состав топовый, должно пройти интересно. Накидывайте в комментарии каверзные вопросы. 😏

Все на ПнП 14 октября! 🏃‍♂️

Коллеги из команды Vulners обновили утилиту Getsploit

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

Коллеги из команды Vulners обновили утилиту Getsploit

Коллеги из команды Vulners обновили утилиту Getsploit. Утилита позволяет искать публичные эксплоиты в базе данных Vulners.com. При этом поддерживается как онлайн-режим работы (поисковые запросы выполняются на сервере Vulners), так и полностью офлайн-режим (данные об эксплоитах из Vulners складываются в локальный индекс SQLite FTS5, по которому выполняется дальнейший поиск). Второй вариант, как мне кажется, наиболее интересный и выгодный. 😉 Скачивание данных выполняется одной командой getsploit --update, итоговый размер базы ~1,7 ГБ.

Дальше можно искать эксплоиты локально, по CVE или полнотекстово:

$ getsploit --local CVE-2024-3094
$ getsploit --local "wordpress 4.7 remote code execution"

В результате получаете информацию об эксплоитах в формате: ID, Title и URL на сайте Vulners.

Если использовать ключик "--mirror", то тексты найденных эксплоитов будут сохраняться в отдельные файлики. Это работает со всеми базами эксплоитов Vulners кроме githubexploit и gitee.

Зачем вообще искать эксплоиты? Это может быть весьма полезно для обогащения данных по уязвимостям в вашем VM-решении и, соответственно, для более адекватной приоритизации. Если вы приоритизируете уязвимости по методике ФСТЭК, то информация об эксплоитах будет нужна для определения показателя Iat. Ну и для редтимовской работы тоже может быть весьма полезно отслеживать появление новых инструментов эксплуатации. 😉

Что почём? Один запрос на обновление getsploit расходует 10 кредитов. Согласно прайс-листу, в бесплатном плане сейчас 100 кредитов в месяц. Соответственно, если обновлять данные по эксплоитам раз в 3 дня, то можно пользоваться вообще бесплатно. 🆓 За $600 можно получить 600 кредитов в месяц, и этого хватит, чтобы обновлять getsploit ~ дважды в день.

Послушал четвёртый эпизод подкаста КиберДуршлаг про Управление Уязвимостями и Харденингом в банке

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

Послушал четвёртый эпизод подкаста КиберДуршлаг про Управление Уязвимостями и Харденингом в банке

Послушал четвёртый эпизод подкаста КиберДуршлаг про Управление Уязвимостями и Харденингом в банке. Гостями подкаста в этот раз были Сергей Алешинский и Андрей Исхаков из ПСБ (Промсвязьбанк). Т.к. я тоже 6 лет VM-ом в банке занимался, было интересно послушать. 🙂 Выписал некоторые тезисы.

1. IT стремятся занять позицию "давайте мы сейчас построим, а потом вы к нам придёте, мы вас послушаем и может быть что-то поправим". ИБ должны не допускать такого.
2. VM это прежде всего процесс взаимодействия людей. Важно уметь договариваться, в том числе на уровне руководства. Необходимость VM следует доносить грамотно, аргументированно и регулярно.
3. Доказывать необходимость исправления уязвимостей непросто, но это развивает технически и IT, и ИБ.
4. В ПСБ был выстроенный процесс обновления десктопов (АРМов), но после 22 года он усложнился. Теперь есть команда в составе RedTeam, которая проверяет обновления и новые версии западного ПО на закладки (дополнительно к проверенным обновлениям из БДУ). Также проходят проверки и собственные разработки.
5. Также применяется исправление уязвимостей путем отказа от legacy систем или внедрения компенсирующих мер (аудит сетевых подключений, максимальное урезание интеграций, обслуживание через терминальные станции).
6. Есть проблема с отсутствием бюллетеней безопасности отечественных вендоров. Отечественных вендоров СЗИ/САЗ это тоже касается.
7. Категоризация активов по сегментам, бизнесам, выделение наиболее критичных скоупов (например, DMZ).
8. Категоризация уязвимостей по автоматизированной методике оценки критичности уязвимостей ФСТЭК.
9. В идеале информацию об активах нужно забирать из супер-актуальной CMDB, которую обслуживает IT. А ИБ должна проводить поиск теневых активов в факультативном режиме. На практике вовлеченность ИБ в поиск проблем CMDB выше, в т.ч. приходится самим искать владельцев систем и обслуживающих подразделений. Периодичность рескана фиксируется в документации на IT-систему. Статус комплаенса систем будет виден на уровне CMDB. Необходимо внедрять VM в ITSM.
10. Проводится сканирование периметра извне. Необходимо следить за состоянием внешних сканеров, т.к. они зачастую добавлены в white list. Для внутренних сканеров, проводящих сканирование с аутентификацией, это ещё более критично.
11. У каждого компонента IT-систем есть утвержденный стандарт настроек. Разработка стандартов настроек выполняется внешней организацией. Проверки на соответствие реализуют сами. Конкретные требования зависят от контура, в котором находится сервер. Желательно иметь возможность перенести этот набор скриптов в VM-решение.
12. Этапы процесса Управления Соответствием: утверждение стандарта, тестирование на ограниченном скоупе, расширение скоупа и контроль соответствия. Центр IT-архитектуры утверждает единый тех. стек допустимых технологий. Его необходимо ограничивать и иметь в виде реестра а-ля CMDB. Проблема расширения стека (в глобальном смысле) это и проблема VM-вендора, который должен уметь всё.
13. При наслоении стандартов (например, ОС и СУБД) могут быть конфликты. Отхождения от стандарта должны согласовываться и журналироваться.
14. Трендовые уязвимости на периметре фиксятся оперативно без формального обоснования критичности. Согласование в рамках конфколла. Но тестирование патча на ограниченном скоупе всё равно необходимо выполнять.
15. Еженедельные отчёты: новая инфраструктура введенная в эксплуатацию, какая инфраструктура прошла проверки, какие уязвимости выявлены с приоритизацией. Отчёты также нужны для аудиторов.
16. Нужно стремиться к открытости VM-решений: полнота базы знаний детектов, обязательство поддерживать API-интеграции.