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

Год с великого исхода западных вендоров: судьба специалиста

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

Год с великого исхода западных вендоров: судьба специалиста. С трудом уже верится, но раньше в РФ было возможно строить IT/ИБ системы, используя западные решения. 🙂 Более того, это был абсолютный мейнстрим. Как следствие, сотрудники российских компаний естественным образом развивались в крутых специалистов по продуктам Microsoft, Oracle, CISCO, PaloAlto, AWS, Tenable/Qualys/Rapid7 и т.д. 😉 Собирали комплекты вендорских сертификатов, выстраивали красивые CV-шки.

Безусловно, в этом была своя прелесть. Ты используешь те же решения, что и крупные компании во всем развитом мире, твои скилы также востребованы в общемировом масштабе. А значит релокация туда, где лучше, выглядит как вполне себе план Б (а у кого-то и как план А). Минусом шла привязка к западным вендорам и их судьбе в России. Но что с ними сделается-то? 😏

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

- продолжать делать то, что делали, а значит релоцироваться туда, где можно продолжать строить системы на западных решениях;
- остаться и строить системы на тех решениях, которые остались/появились в РФ;
- остаться, перестать строить системы и принять участие в копировании западных решений.

Релокация это всегда мероприятие на любителя. Тем более сейчас, когда "жить на 2 страны" стало совсем не так просто и комфортно. Переезд на запад теперь выглядит скорее как дорога в один конец.

Остаться и развиваться в чем-то другом это и потеря конкурентных преимуществ, и необходимость быстро учиться новому, и переход в новый локальный контекст. Опыт с Яндекс Клауд и Астра Линукс безусловно менее универсален, чем с AWS и RHEL. 🙂 Это нужно осознать и принять.

Никого не осуждаю, у всех свои ситуации. Но милей мне, безусловно, оставшиеся. Мы в одной лодке, выгребем. 🛶 🙂

Это второй выпуск Vulnerability Management news and publications

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

Это второй выпуск Vulnerability Management news and publications. В этот раз меньше цитат из новостных статей, больше моих мыслей. Выглядит вроде получше, вам как?

Основная мысль этого эпизода. Microsoft это ангажированная компания. Фактически их можно теперь воспринимать как ещё одно американское агентство. Значит ли это, что нам нужно о них забыть и прекратить отслеживать, что они делают? Нет, не значит. Они делают много интересных вещей, которые как минимум можно исследовать и копировать. Значит ли это, что нужно отказаться от использования продуктов Microsoft? В некоторых локациях (вы сами знаете каких) точно да, в некоторых можно продолжать использовать, если это оправдано, но нужно иметь план Б. И это касается не только Microsoft. Т.е. видится гибкий подход. Здесь - поступаем так, там - по-другому. Кажется, что довольно жесткая фрагментация рынка IT это долгосрочный тренд и надо к нему приспосабливаться.

В этом эпизоде:

01:03 Microsoft выпустили пропагандистский отчет, что это значит для нас?
06:48 Microsoft выпустили функцию Autopatch, стоит ли ее применять?
09:59 Нелепая уязвимость: захардкоженный пароль в Confluence Questions
11:50 Новый Nessus Expert и почему это, по-видимому, худший релиз Tenable
13:20 Новые фичи Rapid7 Nexpose/InsightVM, добавленные во втором квартале 2022 года: хорошее и странное
16:46 Palo Alto: вредоносное сканирование через 15 минут после публикации CVE. Да неужели?
19:36 6 групп уязвимостей, которые чаще всего используются в атаках, согласно Palo Alto, и конец ИТ-глобализации

Video: https://youtu.be/_waOzdBvIyU
Video2 (for Russia): https://vk.com/video-149273431_456239097
Blogpost: https://avleonov.com/2022/08/14/vulnerability-management-news-and-publications-2/

В том же отчете Palo Alto 2022 Unit 42 Incident Response Report есть ещё один прикольный момент

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

В том же отчете Palo Alto 2022 Unit 42 Incident Response Report есть ещё один прикольный момент

В том же отчете Palo Alto 2022 Unit 42 Incident Response Report есть ещё один прикольный момент. Группы уязвимостей, через которые чаще всего ломали компании. "В случаях, когда респонденты положительно идентифицировали уязвимость, используемую злоумышленником, более 87% из них попали в одну из шести категорий CVE".

Категории:

• 55% Microsoft Exchange ProxyShell (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207)
• 14% Log4j
• 7% SonicWall CVEs
• 5% Microsoft Exchange ProxyLogon (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, CVE-2021-27065)
• 4% Zoho ManageEngine ADSelfService Plus (CVE-2021-40539)
• 3% Fortinet CVEs

• 13% Other

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

С другой стороны это показывает насколько тема с уязвимостями и инцидентами зависит от конкретного региона. Ну допустим Exchange везде используют, это да. Log4j также всех затронул так или иначе. Можно представить, что в наших широтах кое-кто крепко сидит на Fortinet. Но вот SonicWall и Zoho кажутся чем-то совсем экзотичным. А там, где Unit 42 incident response кейсы решает, это очень значимые штуки. Или вспомнить прошлогоднюю эпопею, когда массово пошифровали компании через уязвимости Kaseya VSA. Больше тысячи компаний пострадали, но опять же это не в нашем регионе, поэтому нам не особо это интересно было.

С учетом исхода западных вендоров с российского рынка IT ландшафты "здесь" и "там" будут все больше и больше различаться. И все большую роль в российских инцидентах будут играть уязвимости в софте, о котором западные ИБ вендоры возможно и не слышали никогда. И это в обе стороны работает. Значит ли это, что и Vulnerability Management решения нам понадобятся все более и более заточенные под наши российские реалии? Ну видимо да.

Похоже, что время безусловной глобализации в IT уходит, а вместе с тем и возможности VM-вендоров относительно просто внедрять свои решения в новых регионах. Что поделать.

Вот тут Palo Alto утверждают занятное: что обычно злоумышленники начинают сканировать периметр организаций на наличие уязвимости через 15 минут после публикации CVE

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

Вот тут Palo Alto утверждают занятное: что обычно злоумышленники начинают сканировать периметр организаций на наличие уязвимости через 15 минут после публикации CVE. Прям вот так:

"The 2022 Attack Surface Management Threat Report found that attackers typically start scanning for vulnerabilities within 15 minutes of a CVE being announced".

Как конкретно эти 15 минут получили вроде нигде не пишут. Но видимо могли засекать на ханипотах/ids попытки эксплуатации каких-то определенных уязвимостей и связали это с датой публикации уязвимости.

Пример приводят, что они через 5 дней после публикации уязвимости выпустили сигнатуру и за 10 часов насобирали две с половиной тысячи попыток эксплуатации.

"For example, Palo Alto Networks released a Threat Prevention signature for the F5 BIG-IP Authentication Bypass Vulnerability (CVE-2022-1388), and within just 10 hours, the signature triggered 2,552 times due to vulnerability scanning and active exploitation attempts".

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

Но не суть. Не так важно действительно ли через 15 минут сканы начинаются или несколько позже. Факт, что злоумышленники мониторы новостной поток об уязвимостях. И факт, что они мотивированы сканить ваш периметр чаще, использовать для этого нестандартные проверки, а не только те, что есть в вашем коммерческом сканере.

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

Сказать-то конечно проще, чем сделать.