Архив метки: насспрашивают

Должен ли VM-щик в задаче на устранение уязвимости указывать конкретный патч, который нужно установить на хосте?

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

Должен ли VM-щик в задаче на устранение уязвимости указывать конкретный патч, который нужно установить на хосте?

Должен ли VM-щик в задаче на устранение уязвимости указывать конкретный патч, который нужно установить на хосте? Я думаю так:

🔻 Eсли есть простой способ отдавать такую информацию в IT, то нужно это делать. Например, если такие рекомендации выдаёт сканер уязвимостей.

🔻 Если же это требует трудоёмкого ресёрча, то заниматься этим не следует. Иначе это превратится в очередное "докажи-покажи". И вместо построения VM-процесса для повышения безопасности всей организации вы будете выяснять какая уязвимость какой KB-шкой закрывается. Такое себе. 😏

Важно не забывать, что если уязвимость детектируется на хосте, то это уже косяк IT. В идеале всё должно фикситься в рамках процесса безусловного регулярного патчинга. А сканы на уязвимости должны лишь подтверждать, что всё действительно регулярно обновляется. 🟢👍 Если IT внедрять такой процесс не готовы, то пусть возятся с исправлением конкретных продетектированных уязвимостей, включая поиск нужных патчей. 😉

Закончилась пора ЕГЭ

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

Закончилась пора ЕГЭ. Начали задавать вопросы по поводу учёбы на безопасника в МГТУ им. Баумана (ИУ8). 🙂 Я учился в 2003-2009. Остался доволен. Ну так-то сложно быть недовольным, когда поступил довольно неожиданно и легко (собеседование для медалистов - была такая тема 😉), учился на бюджете, отсрочка от армии, военная кафедра, гос. диплом. Да ещё при этом научили чему-то полезному и дали неплохой начальный нетворкинг! Это ж просто праздник какой-то! 🤩

Нравилась ли мне программа обучения? Местами да, местами не особо. Часто говорят, что много лишних предметов. Как по мне, экология, валеология (!), философия, история это же всё чтобы мозги немного расслабились. Никаких проблем с этими предметами, естественно, не было. Основная жесть это была дискретка под разными соусами в конских количествах практически все 6 лет. Особенно Жуковы на первых курсах. 😱 До сих пор иногда снится, что мне её сдавать. 😅 Нужно ли было так много? Не знаю, возможно криптографам и нужно. Сейчас вроде появилась специализация с меньшими объемами математики и простым смертным стало чуть полегче. От предметов, которые преподавали Эшелоновцы у меня самые приятные воспоминания остались, особенно от курса ТОИБАС Валентина Цирлова и курса по выбору на основе CISSP CBK Алексея Маркова. Вот это действительно было полезно и отражало то, чем обычно безопасники в реальной жизни занимаются. Программирования можно было и побольше, а курсы по ОС и сетям были неплохие.

В целом же, что касается каких-то практических навыков, то тут мне кажется важнее найти развивающую первую работу на старших курсах или участвовать в дополнительных обучающих программах. В случае МГТУ это Образовательный центр VK или ISCRA. Конечно, было бы здорово, если бы основная программа была более полезной практически, чтобы не приходилось добирать на стороне, но тут всё упирается в образовательные стандарты. Поэтому я не сказал бы, что в Бауманке прямо идеальная программа обучения ИБшников, но сильно сомневаюсь, что где-то в России их готовят лучше.

Спросили сегодня как по инвентаризационным данным из GLPI получать cpe-идентификаторы для последующего детектирования уязвимостей

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

Спросили сегодня как по инвентаризационным данным из GLPI получать cpe-идентификаторы для последующего детектирования уязвимостей

Спросили сегодня как по инвентаризационным данным из GLPI получать cpe-идентификаторы для последующего детектирования уязвимостей. Сам я таким не занимался. Согласен, что получить из результатов инвентаризации cpe-идентификаторы это проблема. Но основная проблема в том, что получившиеся cpe-идентификаторы тоже достаточно бесполезны, т.к. если детектировать уязвимости с помощью них по данным из NVD, можно обнаружить, что они не всегда мапятся качественно и разбирать получившиеся false positive ошибки придется руками. Возьмем, например, CVE-2020-1102. Все версии sharepoint_server 2016 и 2019 всегда уязвимы что ли? Там патчи есть, их установку нужно учитывать.

Я скептически отношусь к разработке собственных универсальных утилит для детектирования уязвимостей (специализированных, например детектилки по бюллетеням конкретного Linux дистрибутива - это делать реально). Разработку универсальных средств детектирования лучше оставить VM-вендорам, у которых большой штат специалистов и они занимаются этим на фулл-тайм. А на стороне клиента лучше сосредоточиться на приоритизации уже продетектированных уязвимостей.

Про дипломные проекты в ВУЗах

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

Про дипломные проекты в ВУЗах. Недавно спрашивали про актуальные темы для диплома в области ИБ.

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

Если это не вариант, то можно дипломный проект воспринимать как инструмент для последующего трудоустройства. Смотрим на рынок - ищем "компанию мечты", выясняем чем они занимаются, выбираем тему из того, что хорошо будет смотреться на будущем собесе. 😏 Допустим компания это вендор какого-то продукта по ИБ, в разработке которого нам было бы интересно поучаствовать. Собираем проблемы/тренды для этого класса продуктов (для VM-а недавно скидывал) и попытаемся предложить для какой-нибудь из проблем свое решение. Такой дипломный проект это отличная тема для разговора на собесе (важно: даже если про тему диплома написано в резюме, не забудьте голосом акцентировать внимание на этом!). Будете выглядеть уже не как "белый лист", а как специалист с некоторым практическим опытом, который может приносить пользу практически с первого дня. Это дорогого стоит. Ну и в процессе подготовки дипломного проекта неизбежно прокачаетесь в нужную сторону. 😉

Брать тему совсем с потолка или переделывать чужой диплом про мясокомбинат с помощью ChatGPT не советую. 🙂 Конечно, может и такое прокатить, но польза от этого всего будет минимальная.

Тренды/драйверы Vulnerability Management рынка

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

Тренды/драйверы Vulnerability Management рынка. Пару месяцев назад попросили накидать. С моей колокольни выглядит как-то так:

1. Изменение IT-ландшафта в странах в силу геополитических изменений. Соответственно меняются и ожидания того какие продукты должны поддерживать VM решение.
2. База знаний VM вендора должна быть анализируемой. Для того, чтобы понимать можем ли мы в достаточной мере детектировать уязвимости, нужно знать что на самом деле умеет и не умеет VM решение.
3. Не будет одного VM-решения, которое продетектирует все уязвимости. Разные части инфраструктуры придется покрывать разными решениями. Детектирование уязвимостей отделяется от анализа, приоритизации и исправления.
4. Правильная инвентаризация активов. В организациях сейчас слишком много разнообразных активов. Для эффективного VM-а нужно покрыть их все. Причем необходимо понимать можем ли мы детектировать уязвимости для актива и если не можем, то что с этим делать? В качестве вариантов: покупать или разрабатывать механизмы для детекта, выводить актив из эксплуатации, принимать риски.
5. Правильная приоритизация уязвимостей. Слишком много CVE, слишком мало actionable информации. Необходимо уметь отличать экспулатабельное от неэксплуатабельного. Как это сделать непонятно, но видимо необходимо лучше работать с объектами относящимися к уязвимостям, в первую очередь с эксплоитами и сообщениями об атаках.
6. Автоматическое обновление активов. Дилемма: если не обновлять автоматом, это нагружает IT-администраторов массой однообразной работы, если обновлять автоматом, то непонятно кто будет нести ответственность в случае если что-то сломается. Решение: изменение архитектуры, чтобы обновляться было проще, обновляться постепенно, начиная с тестовых хостов.
7. Если не обновление, то что? Для уязвимостей VM решение должно знать набор компенсирующих мер, уметь их детектировать и желательно автоматически применять.
8. Обоснование комплаенс-требований. Для большей части CIS контролей не ясно как детектируемые мисконфигурации могут использовать злоумышленники в реальных атаках. Отсюда скепсис.

Если вендор не предоставляет воркэраунд для исправления инфраструктурной уязвимости, возможно ли выработать его внутри организации? Если да, то кто должен за это отвечать? RedTeam? InfraSec? Совместно?

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

Если вендор не предоставляет воркэраунд для исправления инфраструктурной уязвимости, возможно ли выработать его внутри организации? Если да, то кто должен за это отвечать? RedTeam? InfraSec? Совместно?

Честно говоря, не особо верю в тему разработки эффективных workaround-ов для уязвимостей внутри организации без участия вендора, т.к. по-хорошему каждый раз это будет тянуть на полноценное исследование.

1. В рамках этого исследования для начала нужно получить рабочий эксплоит, чтобы можно было оценить результативность workaround-а. Хорошо если эксплоит доступен публично и работоспособен. Или хотя бы есть подробное описание уязвимости. А если нет? В любом случае это скорее задача RedTeam. Без эксплоита рассуждения о workaround-ах становятся чисто теоретическими.

2. Когда есть рабочий инструмент для атаки, можно продумывать какой workaround можно применить. Заниматься этим вероятнее всего должны сотрудники InfraSec вместе с системными администраторами и владельцами уязвимых систем. Компенсирующие меры могут повлиять на функциональность систем, поэтому одни только безопасники этот вопрос решить не смогут.

3. На тестовом скоупе применяем workaround. Проверяем на хостах из этого скоупа, что эксплуатация уязвимости с помощью нашего эксплоита там больше невозможна. С помощью RedTeam подтверждаем, что легкого способа обойти это исправление нет. Принимаем решение о массовом применении workaround-а.

Всё это сложно, трудозатратно, очень плохо масштабируется и по определению является ненадежным временным решением. Посмотрите, например, сколько раз MS меняли рекомендуемый workaround для ProxyNotShell. А у них там лучшие эксперты работают и занимаются этим на фулл-тайм. Поэтому если есть возможность исправить уязвимость обновлением, лучше обновиться. Workaround-ы и компенсирующие меры лучше брать готовые от вендора или регулятора (для многих уязвимостей они есть прямо в БДУ!) и применять их только на время, пока обновление недоступно.

В чем различие между "уязвимостями инфраструктуры" и "уязвимостями приложений"?

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

В чем различие между "уязвимостями инфраструктуры" и "уязвимостями приложений"? По мне так разница между "уязвимостями инфраструктуры" и "уязвимостями приложений" не техническая, а скорее в способе детектирования и исправления. Это условное разделение, чтобы понимать чем должен заниматься отдел Application Security, а чем отдел Infrastructure Security. Если уязвимость публично известная и у неё есть CVE/BDU, она детектируется сканерами уязвимостей и должна исправляться обновлением ПО/воркэраундом полученным от вендора, то это "уязвимость инфраструктуры". Если уязвимость публично неизвестная, была обнаружена с помощью SAST/DAST инструментов и должна исправляться изменением в коде самописного приложения, то это "уязвимость приложения". А технически и то, и другое может быть уязвимостью одного типа, например, Path Traversal. Технических типов уязвимостей можно выделить великое множество (см. CWE), но в рамках Vulristics я стараюсь всё раскладывать в несколько основных типов, отталкиваясь от уязвимостей, которые заводит MS.