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

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

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

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

Разбираю ответы на мои вопросы с эфира AM Live по Vulnerability Management-у. Часть 3/3. Поддержка методик ФСТЭК.

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

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

Сложно комментировать поддержку документа, который на момент эфира существовал только в проекте (но сейчас уже официально опубликован). 🙂 По факту обсуждения руководства и не было. Был только ответ Сергея Уздемира из АЛТЭКС-СОФТ (1:07:37), что есть такой документ и с ним нужно ознакомиться. В своем ответе Сергей упомянул также и методику оценки критичности уязвимостей ФСТЭК. Поэтому когда последовал следующий вопрос "насколько вы в своих решениях сейчас им [методикам] соответствуете?", то представители VM-вендоров стали отвечать про методику оценки критичности, а про руководство по управлению уязвимостями больше не вспоминали. 😉 А жаль, в руководстве есть что пообсуждать.

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

Ответ начиная с 1:10:05. Четыре вендора заявили о поддержке этой методики. Для Positive Technologies MaxPatrol VM я смотрел текущую реализацию, для R-Vision VM, АЛТЭКС-СОФТ RedCheck и Фродекс VulnsIO пока нет.

Основной проблемой видится то, что для приоритизации по методике ФСТЭК необходимо каким-то образом получать Temporal и Environmental метрики CVSS. Теоретически это можно как-то автоматически генерировать из дополнительной информации об уязвимостях и инфраструктуре, но на практике я пока этого не видел. Так что если вам будут рассказывать про реализацию этой методики, то задавайте вопросы про CVSS. 😉

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

Напрямую этот вопрос не задавался, но темы проверки обновлений несколько раз касались. Причем в основном при обсуждении автопатчинга. В том смысле, что автопатчинг вещь может и хорошая, но необходимость проверки обновления западного ПО как в рамках алгоритма НКЦКИ, так и по методологии ФСТЭК никто не отменял (2:29:29). И там же была реплика "Но это же не наша зона ответственности, по идее это зона ответственности IT" (2:30:15). Это конечно же не так, потому что IT уж точно не смогут оценить безопасность патчей по сложному процессу.

Поэтому варианта 2: либо VM-вендор возьмет задачу анализа обновлений на себя, либо это так и останется проблемой на стороне клиента.

В 2:51:02 Владимир Михайлов из Фродекс/VulnsIO предложил идею проверки обновлений на стороне гипотетического консорциума VM-вендоров: "заказчик, перед тем как накатить патч, установить новую версию ПО, должен проверить его по рекомендациям ФСТЭК. Он маловероятно это сам сделает. Ни один из VM-вендоров это тоже самостоятельно не сделает. Но если мы объединимся под крышей того же БДУ ФСТЭК, мы теоретически сможем собирать базу проверенных обновлений". Причем более полном виде, чем это есть сейчас в БДУ. Очень хотелось бы, чтобы из этой идеи что-то получилось. 🙏

Часть 2

Послушал выступление Алексея Андреева, управляющего директора Positive Technologies, о движений компании в Open Source

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

Послушал выступление Алексея Андреева, управляющего директора Positive Technologies, о движений компании в Open Source

Послушал выступление Алексея Андреева, управляющего директора Positive Technologies, о движений компании в Open Source.

Начиная с 2:15:19:

"Вся индустрия страдает от простой вещи - нет доступных оцифрованных знаний, чтобы ими все могли пользоваться. И как будто бы сейчаc мы очень хорошо чувствуем, что это всё неправильно. Кто-то скажет, это ведь конкурентное преимущество! И наверное для какой-то другой компании это было бы так: наше знание, наше конкурентное преимущество. Но, чёрт побери, если мы заявляемся, что мы лидер Cyber Security и хотим стать мировым гигантом нельзя заниматься такими подходами.

Для нас, наверное, сейчас самое время, чтобы мы дали в Open Community и средства, которые позволяют собирать экспертизу, и внесли свою экспертизу в Open Source. У нас большой проект сейчас в этом направлении движется. Мы хотим с помощью наших телодвижений в Open Source создать такой прецедент, когда крупнейшая компания в области безопасности вывела и набор средств, необходимых для работы со знаниями, и поделилась всеми своими знаниями. И мы не хотим конкурировать в этой плоскости. Хочется поделиться всем, чем мы владеем и призвать всех остальных делиться.

От этого забенефитит весь мир. Все почувствуют насколько иной уровень зрелости и знаний в области кибербезопасности станет доступен каждой первой компании и каждому первому вендору. В этом наш большой смысл и задача. И мы явно туда будем идти весь этот год. И что-то в этом направлении будет происходить."

Я не особо понимаю о каких именно знаниях здесь идет речь, но звучит интересно и многообещающе. 🙂 Я, конечно, сразу думаю в сторону баз уязвимостей и детектов. Очень хотелось бы, раз уж взят такой курс на открытость, чтобы знания о том какие уязвимости умеет детектировать MaxPatrol 8 / MaxPatrol VM были доступны в виде открытого фида. Хотя бы в виде одного только набора CVE идентификаторов. А если бы целиком правила детектирования уязвимостей открыли, вот это было бы реально круто! 😊

Вчера на PHDays 12 посетил "тайную комнату", в которой показывали продукты PT

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

Вчера на PHDays 12 посетил тайную комнату, в которой показывали продукты PTВчера на PHDays 12 посетил тайную комнату, в которой показывали продукты PTВчера на PHDays 12 посетил тайную комнату, в которой показывали продукты PTВчера на PHDays 12 посетил тайную комнату, в которой показывали продукты PTВчера на PHDays 12 посетил тайную комнату, в которой показывали продукты PTВчера на PHDays 12 посетил тайную комнату, в которой показывали продукты PT

Вчера на PHDays 12 посетил "тайную комнату", в которой показывали продукты PT. Приятно пообщались про MaxPatrol VM, в основном в части реализации оценки критичности уязвимостей по методике ФСТЭК.

Сейчас это реализовано через PDQL запросы, в которые добавили математические функции. Есть 2 варианта:

1. Через активы и группы. За счёт группы можно показать находится ли хост в DMZ, либо внутри. Но если с этим бардак и опубликованные активы могут находиться в произвольных сетках, то тут уж сами виноваты. 😏
2. Через пользовательские поля в карточке уязвимости. Практически ручной способ.

Основная проблема в CVSS. Методика требует "расчета базовых, временных и контекстных метрик". Базовые есть в NVD/БДУ. Временные иногда предоставляет вендор или их можно пробовать генерить. Контекстных по определению готовых нет и генерить их сложно. Поэтому, строго говоря, требования методики по учёту CVSS в MaxPatrol VM пока не реализуются в полной мере.

Positive Community Talent Award

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

Positive Community Talent Award
Positive Community Talent Award

Positive Community Talent Award. Вот такие штуки вручили. Видео на Youtube. Хороший повод немного порефлексировать.

1. Большое спасибо PT, а особенно команде VM! Понимаю, что вы здесь сильно поспособствовали. 🙂 Спасибо, что вы адекватно воспринимаете критику, которая с моей стороны иногда исходит. Вы крутые и по праву являетесь лидерами российского VM рынка. Я горжусь, что продолжительное время работал в PT, это мой бэкграунд и PT всегда в моём сердечке. ❤️

2. Большое спасибо подписчикам! Я считаю, что это наша общая награда. Судите сами, другие награды были за непосредственную работу связанную с комьюнити пользователей продуктов PT. А мне дали по сути за посты. Стал бы я их писать, если бы вас тут не было? Вряд ли. Когда вы читаете, ставите реакции, репостите, коментите в вк, вы тем самым участвуете в российском VM комьюнити, которое пока формируется, но обязательно оформится во что-то вполне осязаемое и функциональное.

Спасибо!

2023 год: точка бифуркации

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

2023 год: точка бифуркации

2023 год: точка бифуркации. В пике́ или на пи́ке?

Алексей Волков, VK: "Все последние инциденты, которые я знаю, которые произошли за последний год, были достаточно длительны во времени. С момента проникновения в инфраструктуру и до момента вредоносных действий проходило очень долгое время. 4-5 месяцев, а то и больше. Мне известны случаи, когда и по 1,5 года сидели в инфраструктуре и наблюдали. Самое главное, что причиной подавляющего числа инцидентов были НЕ использование каких-то серьезных инструментов, каких-то 0day, каких-то супер-техник и тактик. Причина большинства инцидентов - это банальный IT-шный бардак. Антивирус есть - не обновляется. Операционные системы - патчи не ставятся. Второй фактор не прикручен. Админки торчат наружу. Никакого управления доступом там в помине нет. Я уж не говорю о каких-то SSDLC. Когда мы говорим про то, что нужно делать прямо сейчас, все очень просто. Идите засучите рукава и наведите порядок в базе!"

Все, о чем вы хотели, но боялись спросить регулятора

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

Все, о чем вы хотели, но боялись спросить регулятора

Все, о чем вы хотели, но боялись спросить регулятора

Виталий Лютиков, ФСТЭК России. Ответ про уязвимости в контексте использования зарубежных NGFW:

"Сам факт использования зарубежного сетевого экрана, особенно в КИИ, не столько критичен, сколько использование уязвимого зарубежного межсетевого экрана. Поэтому я всем рекомендую, у кого на периметре стоят такие средства, озадачиться вопросом анализа уязвимоcтей (которые сейчас по некоторым классам продуктов всё чаще и чаще появляются, и критичные, в том числе эксплуатируемые удаленно) и формированием компенсирующих мер, выработкой сигнатур, постановке на мониторинг, анализом событий и т.д. Для того, чтобы эти риски компенсировать. Вот это более критично чем факт использования зарубежного сетевого экрана, по крайней мере до 25го года."

"Если отсутствие технической поддержки привело к наличию уязвимости, которое не компенсируется другими способами или средствами, то тогда данное нарушение мы рассматриваем с соответствующими санкциями. Если [компенсирующие меры] выработаны, тогда рекомендация по переходу к соответствующему сроку, но санкции не применяются."

Владимир Бенгин, Минцифры России. Рассказал про положительный опыт багбаунти Госуслуг. Нашли десятки уязвимостей, хотя ожидалось, что после всех пентестов ничего не найдут. Опыт будут масштабировать и будут продвигать. Завтра будут подробности.

Ещё было пара реплик, что "Руководство по управлению уязвимостями программного обеспечения и программно-аппаратных средств в органе (организации)" ФСТЭК могут на днях зарелизить. Видимо об этом было на предыдущих секциях. Ждем. 🙂

Про историю Vulnerability Management-а

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

Про историю Vulnerability Management-а. Иногда люди говорят публично что-то странное, но делают это настолько уверенно, что сам начинаешь в себе сомневаться. Вдруг они лучше знают? Ну или может ты их не так понял? Вот, например, посмотрел ролик "Traditional Vulnerability Management is Dead!" с Stefan Thelberg, CEO Holm Security. Это те ребята, которые считают, что без встроенного Антифишинга VM уже не VM.

В начале Stefan Thelberg заявляет про историю Vulnerability Assessment-а (Vulnerability Management-а) буквально следующее:

1. Оригинальная идея Vulnerability Assessment-а появилась в гайдлайнах NIST-а.
2. Прошло 20 лет и появились первые Vulnerability Assessment продукты.
3. Большая часть Vulnerability Assessment продуктов родились из опенсурсного проекта OpenVAS.
4. Один из наиболее распространенных продуктов на рынке, Nessus, это коммерческий форк OpenVAS.
5. Прошло ещё несколько лет и около 2000-го появилось несколько больших компаний: Rapid7, Tenable, Qualys.

То, что VA/VM родился из каких-то публикаций NIST-а не проверишь особо, организация в 1901 году основана, вполне вероятно что-то и было в 80х. Но заявление, что сначала был OpenVAS, а потом Nessus это очень странно. Первая версия The Nessus Project вышла в 1998 как GPL проект. Первая версия XSpider (тогда Spider) также появилась в 1998, а в 2000 он стал публично доступным. Компания Qualys была основана в 1999, Rapid7 в 2000, Tenable в 2002, Positive Technologies в 2002. Проект OpenVAS (GNessUs) появился не раньше 2005-го как форк последней опенсурсной версии Nessus-а, т.к. сам Nessus с 2005 года стал проприетарным продуктом Tenable.

Вот и думай теперь, то ли Stefan Thelberg говорит о том, о чем понятия не имеет. То ли он как-то странно называет OpenVAS-ом оригинальный Nessus 1998-го года. Но даже говорить, что другие VM продукты родились из Nessus-а или OpenVAS-а более чем странно, как минимум потому что другие продукты (Qualys, Rapid7 Nexpose, XSpider/MaxPatrol) не используют и не использовали NASL-скрипты, которые составляют основу Nessus. Может, конечно, у самих Holm Security движок это OpenVAS и они всех по себе меряют, не знаю. 😏

Немного про остальной ролик. Само обоснование почему традиционный VM уже не живой это отличный пример борьбы с "соломенным чучелом". Определяют "традиционный VM" так, как удобно. Что он, дескать, не поддерживает новые технологии (облака, IoT, SCADA). Добавляют свой спорный тезис, что обучение пользователей через Антифишинг это тоже обязательная часть VM. И дальше получившееся удобное "соломенное чучело" атакуют. Хотя чего бы "традиционному VM-у" не поддерживать все типы активов, которые в организации есть - непонятно. Да и какой-то проблемы прикрутить к VM-у Антифишинг, если так уж хочется, тоже нет.