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

Завтра открывается фестиваль PHDays 12!

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

Завтра открывается фестиваль PHDays 12! Непосредственно про Vulnerability Management я выступлений в программе не нашел. Но есть разборы конкретных уязвимостей и выступления на смежные темы, которые я себе наметил. Возможно кому-то тоже будет интересно. Первый день буду слушать фоном в онлайне, а в субботу планирую быть на площадке в Парке Горького.

Обязательно загляну на стенд Positive Technologies с MaxPatrol VM, вчера на AM Live обещали показать реализацию оценки критичности уязвимостей по методике ФСТЭК! 🔥Очень интересно откуда они временные и контекстные метрики CVSS берут, а также тип уязвимого актива. 🙂

19 мая

🔸12:00–13:00 Кто, как и зачем атакует Linux-инфраструктуры. DEFENSE
Олег Скулкин. BIZONE

🔸13:45–14:45 Все, о чем вы хотели, но боялись спросить регулятора. БИЗНЕС ТРЕК 1
Виталий Лютиков, ФСТЭК России
Владимир Бенгин, Минцифры России
Алексей Лукацкий, Positive Technologies

🔸15:00–16:00 Интернет-картография в 2023 году. Чего не может Shodan. OFFENSE
Сергей Гордейчик, CyberOK
Александр Гурин, CyberOK

🔸15:00–16:00 SCAзка о SCAнерах. DEVELOPMENT
Виктор Бобыльков, Райффайзенбанк
Дмитрий Евдокимов, Luntry

🔸17:00–18:00 Опыт тестирования и верификации ядра Linux. DEVELOPMENT
Алексей Хорошилов, ИСП РАН

🔸17:15–18:30 Киберсуверенитет: вклад открытого кода. БИЗНЕС ТРЕК 1
Сергей Гордейчик, CyberOK
Кирилл Севергин, АЛРОСА
Сергей Золотарев, Arenadata
Александр Гутин, ГК «Астра»
Иван Панченко, Postgres Professional

-------------------------

20 мая

🔹11:00–11:40 People as code: сотрудник как актив и объект защиты. БИЗНЕС ТРЕК 2
Сергей Волдохин, «Антифишинг»

🔹13:00–14:00 Внедрение кода в процессы из контекста ядра Linux. OFFENSE
Илья Матвейчиков

🔹13:00–14:00 Как обезопасить от санкций ваш открытый проект на GitHub. DEVELOPMENT
Александр Попов, Positive Technologies

🔹14:00–15:00 История одной уязвимости. DEVELOPMENT
Андрей Наенко, Kaspersky

🔹14:00–15:00 Топ-10 артефактов Linux для расследования инцидентов. DEFENSE
Лада Антипова, Angara Security

🔹15:10–15:40 Отечественные ОС сегодня: вызовы, задачи, перспективы. ЭФИРНАЯ СТУДИЯ
Александр Попов, Positive Technologies
Алексей Хорошилов, ИСП РАН
Владимир Тележников, «РусБИТех»

🔹16:00–17:00 Антология способов программного мониторинга и защиты Linux в пользовательском пространстве. OFFENSE
Тимур Черных, F.A.С.С.T.

🔹17:00–18:00 Positive Awards. ЭФИРНАЯ СТУДИЯ

Уточнение по предоставлению доступа к базе детектов уязвимостей от АЛТЭКС-СОФТ (RedCheck)

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

Уточнение по предоставлению доступа к базе детектов уязвимостей от АЛТЭКС-СОФТ (RedCheck)

Компания дает возможность выгрузки ОVAL feed-ов, используемых для детекта уязвимостей в RedCheck, на следующих условиях:

1. Доступ предоставляется крупным заказчикам и частным исследователям, не аффилированным с конкурентами. Быть клиентом необязательно.
2. Доступ предоставляется для запрашиваемых платформ.
3. Доступ предоставляется на некоторый оговоренный промежуток времени.
4. Доступ предоставляется при условии заключения соглашения на запрещение коммерческого использования, что не запрещает публикацию, критику и сравнение с конкурентами в исследовательских целях.

При этом фиды АЛТЭКС-СОФТ, которые поддерживаются в рамках проекта ScanOVAL ФСТЭК полностью открыты и фактически доступны для изучения.

Спасибо большое Сергею Уздемиру за уточнение! Конкуренция на рынке имеет место и понятно, что есть справедливые опасения. Хотя, имхо, держать такую информацию в секрете довольно бесполезно, т.к. кому надо, тот доступ к ней всё равно получит тем или иным способом, а честное исследование ради общей пользы это усложняет.

Если кто-то ещё из представителей VM-вендоров хочет добавить уточнения по своей позиции - пишите в личку, всегда выкладываю без проблем. 🙂

Разбираю ответы на мои вопросы с эфира AM Live по Vulnerability Management-у

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

Разбираю ответы на мои вопросы с эфира AM Live по Vulnerability Management-у. Часть 1/3. Доступность баз детектов уязвимостей для анализа.

Вопрос был такой:

> 1. Вы предоставляете информацию об уязвимостях (идентификаторы CVE, БДУ), которые может детектировать ваше VM-решение, чтобы клиенты (текущие и потенциальные) могли оценить полноту базы детектов вашего VM-решения?

Зачем я задавал этот вопрос? Хотелось бы делать сравнения отечественных средств детектирования уязвимостей, также как я делал сравнения для Nessus и OpenVAS. Но тут проблема - нет публичных данных, перечней детектируемых CVE-шек для сравнения.

Вопрос задали и на него начали отвечать в 1:00:38:

"Есть у нас вопрос от Александра Леонова, как раз в тему. А насколько вы предоставляете информацию об уязвимостях, которые ваше решение детектирует? Т.е., проще говоря, ваша база данных уязвимостей…"

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

Positive Technologies: "В нашем решении в VM-е можно с помощью фильтра вывести все уязвимости, которые есть. Если не ошибаюсь, их сейчас там около 100.000, близко к этому. И в режиме real time можно посмотреть какие есть, можно точечно уязвимость проверить. Поэтому никаких секретов в этом нет."

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

АЛТЭКС-СОФТ: "У нас собственный репозиторий уязвимостей, который могут смотреть все пользователи мира. Наша база данных сканера доступна не только пользователям продукта, но и любому человеку".

Подчеркивается, что одно дело доступность для клиентов, другое публичная доступность. И для АЛТЭКС-СОФТ это действительно в большей степени справедливо - есть поисковый интерфейс OVAL репозитория. В вебинтерфейсе видны уязвимости и их идентификаторы. Но какой-то возможности выгрузить всё для изучения ведь там тоже нет. Только если сделать робота, который всё это сграбит через веб-интерфейс.

Эшелон: "У нас консолидированная база уязвимостей, можно проверить наличие любой уязвимости, которая только вышла. Обновления ежедневно".

Список уязвимостей Сканер-ВС 6 доступен для клиентов, но не является доступным публично. В случае Эшелона дать список всех детектируемых уязвимостей сложно, т.к. для детекта используется поиск по базе. Допустим VM-вендор взял NVD и ищет в ней по продуктовым cpe-идентификаторам. Спроси его: какие он уязвимости может детектить? Да он сам не знает. В принципе всё, что в NVD есть может в каком-то случае найтись. Правда не любые cpe могут прийти на вход от средства инвентаризации. Но поиск может идти не только по cpe. Поэтому получить перечень потенциально детектируемых уязвимостей затруднительно.

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

Хорошо, что вопрос взяли в обсуждение. Плохо, что не задали четко в лоб: "где ваши публичные данные о детектируемых уязвимостях, доступные для стороннего анализа?" Чтобы получить ответы: "да вот они" или "их нет и вот почему". 🙂 Имхо, основная причина почему их нет в опасениях, что публично доступная информация о НЕдетектируемых уязвимостях может использоваться в маркетинговых бэтл-картах конкурентов. И зачем так делать и дискутировать о возможностях детектирования разных решений, если можно не делать. 😉 Хотя для развития качества детектирования уязвимостей это было бы крайне полезно.

Пока спасение утопающих — дело рук самих утопающих. Запрашивайте данные и делайте сравнение баз детектируемых уязвимостей непосредственно в ходе пилотных проектов. Обращайтесь или используйте мои наработки в проекте VulnKBdiff.

До онлайн-конференции AM Live по Vulnerability Management-у осталось всего несколько часов

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

До онлайн-конференции AM Live по Vulnerability Management-у осталось всего несколько часов. Начало в 11:00 по Москве. До встречи в чатике трансляции! 😉

Каверзные вопросы к онлайн-конференции AM Live по Vulnerability Management-у

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

Каверзные вопросы к онлайн-конференции AM Live по Vulnerability Management-у

Каверзные вопросы к онлайн-конференции AM Live по Vulnerability Management-у. Те вопросы, которые сейчас программе заявлены и на которые я отвечал (Часть 1, Часть 2, Часть 3), как по мне слишком базовые и поверхностные. Мне было бы интересно узнать ответы VM-вендоров на следующие 5 вопросов, в основном касающихся недавних инициатив регуляторов:

1. Вы предоставляете информацию об уязвимостях (идентификаторы CVE, БДУ), которые может детектировать ваше VM-решение, чтобы клиенты (текущие и потенциальные) могли оценить полноту базы детектов вашего VM-решения?

2. Вы согласны, что бесплатный сканер ScanOVAL ФСТЭК может рассматриваться как эталонное средство детектирования уязвимостей для хостов под управлением Windows и отечественных Linux-ов?

3. Ваше VM-решение позволяет проводить приоритизацию уязвимостей с использованием "Методики оценки уровня критичности уязвимостей программных, программно-аппаратных средств" ФСТЭК?

4. Когда ваше VM-решение рекомендует установку апдейтов западного софта, учитывается ли при этом "Методика тестирования обновлений безопасности программных, программно-аппаратных средств" ФСТЭК? Является ли тестирование обновлений по методике частью VM-процесса?

5. Что вы думаете о проекте "Руководства по управлению уязвимостями программного обеспечения и программно-аппаратных средств в органе (организации)" ФСТЭК? Ваше VM-решение позволит работать по этому процессу?

Раз уж меня не будет на онлайн-конференции AM Live по Vulnerability Management-у, поотвечаю на вопросы из программы здесь (3/3)

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

Раз уж меня не будет на онлайн-конференции AM Live по Vulnerability Management-у, поотвечаю на вопросы из программы здесь (3/3). 😉

Часть 3. ПРОГНОЗЫ РАЗВИТИЯ СИСТЕМ УПРАВЛЕНИЯ УЯЗВИМОСТЯМИ

1. Как будут развиваться системы управления уязвимостями в ближайшее время?

Здесь хотелось бы разделить на 2 части:

- Как хотелось бы, чтобы развивались?

Про это писал в "Трендах/драйверах Vulnerability Management рынка". Всё повторять здесь не буду. Ключевым направлением мне кажется анализируемость баз детектов уязвимостей. Чтобы можно было делать сравнения (хотя бы по CVE) и делать выводы по возможностям детектирования у тех или иных решений. Если в этом отношении ситуация улучшится, можно будет даже со стороны клиента пропушивать улучшение качества детекта.

- Как скорее всего будут развиваться?

Кажется, что основное, куда кидаются ресурсы это не улучшение качества детектирования, а дальнейшие интеграции со сторонними системами и высокоуровневая аналитика для ТОПов. Желательно, чтобы ещё и работало автоматически.

Алексей Лукацкий в своём канале это так недавно описал:

"Мечта ИБшника - средство защиты с одной кнопкой «защити меня», а не вот это вот все с тысячами настроек… Само смотрит телеметрию, само коррелирует и выстраивает цепочки атак, само оценивает опасность, само реагирует, само генерит и отправляет отчет об успехе с привязкой к бизнес-целям предприятия (недопустимым событиям). Сказка, а не ИБ. […] Так что думаю не за горами тот момент, когда в одном решении будет и SIEM, и SOAR, и сканер уязвимостей, и встроенная CMDB, и ASM, и много чего еще"

И я в общем-то не против всего этого, но очень хотелось бы, чтобы этот космолет развивался не в ущерб базовой функциональности детектов. Потому что детекты это база, а всё что выше это надстройка.

2. Можно ли будет полностью автоматизировать процесс управления уязвимостями в организации?

Можно. Когда будут полностью автоматизированы (и формализованы) процессы IT. 😏

3. Как можно будет использовать в этом процессе искусственный интеллект?

Уже сейчас используются для анализа уязвимостей, например в EPSS. Вполне вероятно, что AI будет активно использоваться при анализе состояния защищенности активов и построение цепочек атак.

Часть 2

Раз уж меня не будет на онлайн-конференции AM Live по Vulnerability Management-у, поотвечаю на вопросы из программы здесь (2/3)

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

Раз уж меня не будет на онлайн-конференции AM Live по Vulnerability Management-у, поотвечаю на вопросы из программы здесь (2/3). 😉

Часть 2. ПРАКТИКА УПРАВЛЕНИЯ УЯЗВИМОСТЯМИ

1. С чего начать построение процесса управления уязвимостями?

Имхо, самое важное сразу решить: вы будете использовать полноценное коробочное решение или попробуете обойтись без него, комбинируя разные средства детектирования уязвимостей и разрабатывая что-то самостоятельно. Первый путь - дорого и много боданий с вендором, чтобы пропушивать нужные фичи и багфиксы. Второй путь - дольше стартовать, гораздо более трудоемко, но гибче и, как правило, дешевле.

2. Какие регламенты нужно разработать в компании?

Политика управления уязвимостями должна какая-то быть. Но не важно какая именно бумажка мотивирует исправлять уязвимости, главное чтобы уязвимости по факту исправлялись.

4. Как правильно составить SLA для такого процесса?

Единого правильного пути нет. Прогрессивным считается согласовать требования по регулярным безусловным обновлениям в заданные сроки и согласовать процесс "пожарного" патчинга супер-критичных уязвимостей.

5. Как правильно определить границы процесса управления уязвимостями?

Фиг знает что понимается под границами. Имхо, всё что является технической уязвимостью можно подгрести под Управление Уязвимостями, т.е. аппсечные темы тоже (см. карту). Но VM-вендоры под VM-ом понимают, как правило, только управление уязвимостями инфраструктуры.

6. На какие параметры обращать внимание при выборе системы управление уязвимостями?

В первую очередь оценить качество детектирования уязвимостей, всё остальное сильно вторично.

7. С какими типами ресурсов могут работать системы управления уязвимостями?

Правильнее задать вопрос: то VM-решение, которое вы покупаете, покрывает ли все типы активов, которые есть у вас в организации. И если нет, то что делать с непокрываемыми. Выяснить это ваша задача.

8. Обязательно ли идентифицировать все активы в инфраструктуре? И как проще это сделать?

Безусловно. Имхо, это задача IT и логично это делать в рамках CMDB системы. Но если есть уговор делать это в рамках VM-а, почему бы нет.

9. Кто и как правильно оценивает приоритет уязвимостей?

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

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

"Нигде кроме как в Моссельпроме!" © Видимо правильный ответ подразумевается "в платном фиде VM-вендора". 😏 На самом деле CISA KEV и бюллетени регуляторов вполне адекватно подсвечивают критичное.

11. Можно ли в рамках процесса определять ошибки конфигурации и проводить контроль целостности?

Можно рассматривать мисконфигурации как уязвимости, но вообще правильный Hardening это отдельная непростая тема. А контроль целостности это скорее SOC-овская тема.

12. В каких случаях возможен автопатчинг или переконфигурирование?

В тех случаях, когда VM-вендор может его безопасно делать. 😏 В первую очередь это должно касаться third-party софта на десктопах: браузеры, pdf-читалки, архиваторы, офисные продукты, java и т.п.

13. Какие метрики эффективности на практике лучше применять для управления уязвимостями?

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

Часть 1