Tadviser пишет, что менеджмент российского SAP-а отказался выкупать компанию

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

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

"Клиенты лишатся доступа к системе, через которую оказывается техподдержка – получение обновлений ПО, патчей безопасности, размещение заявок на решение различных проблем".

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

Заниматься Управлением Уязвимостями для SAP всегда было не сахар. Мало сканеров его поддерживают, по сути выбор выбор был между ERPScan и MaxPatrol8. Обновлять этого монстра всегда было страшновато, не обновлять ещё страшнее. Как это теперь будут делать без возможности уточнить какие-то моменты у поддержки вообще непонятно. Стойкости коллегам, которые вынуждены этим заниматься. 🙂

Но основное веселье ждет тех, кто будет отвечать за миграцию с этого безобразия на условный 1С и переписывание чертовой уймы кастомных ABAP скриптов. 🤩

Ъ пишет, что Huawei закрывает подразделение Enterprise Business Group в РФ (корпоративные продажи систем хранения данных и телекоммуникационного оборудования, 2000 человек)

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

Ъ пишет, что Huawei закрывает подразделение Enterprise Business Group в РФ (корпоративные продажи систем хранения данных и телекоммуникационного оборудования, 2000 человек). Это подтверждает тезис, что демонстративного пересаживания на мейнстримные китайские решения не будет. А будет что-то другое. При этом российские R&D центры Huawei, куда активно хантили последние годы, похоже остаются.

Выпустил свои размышлизмы о том, что такое Zero Day уязвимость как отдельный эпизод с видяшкой на английском

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

Выпустил свои размышлизмы о том, что такое Zero Day уязвимость как отдельный эпизод с видяшкой на английском. На русском было тут.

Все пишут, я тоже напишу: если вам пришло такое сообщение от кого-то в ТГ, то это фишинг в результате которого у ваc отожмут акк в ТГ и разошлют такие же сообщения вашим контактам

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

Все пишут, я тоже напишу: если вам пришло такое сообщение от кого-то в ТГ, то это фишинг в результате которого у ваc отожмут акк в ТГ и разошлют такие же сообщения вашим контактам

Все пишут, я тоже напишу: если вам пришло такое сообщение от кого-то в ТГ, то это фишинг в результате которого у ваc отожмут акк в ТГ и разошлют такие же сообщения вашим контактам.

Схема примитивная. Если бы там была просто ссылочка на внейшний сайт, никто бы особенно велся на это. Но ботам с кнопочками почему-то больше верят.

Активно ищем людей в Департамент Информационной Безопасности Tinkoff

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

Активно ищем людей в Департамент Информационной Безопасности Tinkoff

Активно ищем людей в Департамент Информационной Безопасности Tinkoff. Особенно активно ищем вот сюда:

1. Application Security Expert Senior/Middle (Любой город)
2. DevSecOps Engineer (Любой город)
3. Security Partner (Москва/Санкт-Петербург)
4. Аналитик DLP (Mосква)
5. Security Operations Center Engineer (Любой город)
6. Руководитель группы (Москва)

Непосредственно к нам в инфраструктурную безопасность ищем заинтересованных и адекватных людей, которым хотелось бы разбираться с инфраструктурными уязвимостями (оценка критичности, детект, организация исправления и т.д.) и автоматизировать решение своих задач на Python. Кидайте резюме мне в личку телеграмма @leonov_av.

Vulnerability Management решения и Zero Day уязвимости (3/3)

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

Vulnerability Management решения и Zero Day уязвимости (3/3)

Если мы условимся трактовать Zero Day уязвимости так широко, то можем рассмотреть такие их виды:

1. Публичные уязвимостей, для которых в момент публикации не было патча от вендора ПО (например, #ProxyNotShell). Такие уязвимости Vulnerability Management решения могут иногда детектировать. НО VM вендор должен приложить к этому дополнительные усилия. Большая часть правил детекта уязвимостей работают за счет проверки установки патчей или проверки версий ПО/пакетов. Раз обновления устраняющего уязвимость пока нет, значит требуется детектировать как-то иначе. Например попытаться проэксплуатировать уязвимость. Разработка таких правил это ручная работа, требующая больших усилий.
2. Непубличные уязвимости, о которых кто-то знает и возможно использует, но о которых не знает вендор ПО (например, #EternalBlue до утечки из NSA). Такие уязвимости вероятно могут находиться в некоторых непубличных базах уязвимостей. Обнаружить такие уязвимости при помощи VM решения невозможно. С обнаружением эксплуатации таких уязвимостей в какой-то степени могут помочь EDR решения и практики SOC.
3. Непубличные уязвимости, о которых вообще никто не знает. VM решение также не сможет продетектировать такие уязвимости. Это уже из области исследования ПО и SAST/DAST/IAST решений.

Так могут ли VM решения детектировать Zero Day уязвимости? Да, могут детектировать определенные Zero Day уязвимости в некоторых исключительных случаях. Это будет обычное сканирование на уязвимости и затем фильтрация по признаку "у уязвимости нет патча". Но обнаруженные таким образу уязвимости будут лишь малой частью от всех Zero Day уязвимостей (в том смысле как мы их определили выше). VM решения заточены на работу с известными уязвимости для которых вендором уже выпущены патчи. Именно такие уязвимости (а не Zero Day!) обычно и являются основной причиной взлома компаний. Zero Day уязвимости применяются все же довольно редко и в основном в таргетированных атаках.

Vulnerability Management решения и Zero Day уязвимости (2/3)

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

Vulnerability Management решения и Zero Day уязвимости (2/3)

Если несознательный исследователь опубликует полный ресерч по уязвимости, вообще не информируя вендора, т.е. сразу сделает full disclosure, это будет классический Zero Day. Тут вопросов нет. Но есть тонкости:

➡️ Является такая уязвимость Zero Day до момента публичного раскрытия?
➡️ Если сознательный исследователь информирует вендора, является ли уязвимость Zero Day от момента обнаружения её исследователем до момента передачи данных о ней вендору и во время разработки патча вендором?
➡️ Если уязвимость была Zero Day, то после выхода патча вендором, корректно ли продолжать называть такую уязвимость Zero Day?

Есть разные мнения и определения:

1. Trendmicro: "A zero-day vulnerability is a vulnerability in a system or device that has been disclosed but is not yet patched".
2. Kaspersky: "A zero-day vulnerability is a software vulnerability discovered by attackers before the vendor has become aware of it."
3. Portswigger: "A zero-day (0day) vulnerability refers to a security vulnerability for which no mitigation or patch is available at the time it is disclosed or made public".
4. ScienceDirect: "Zero-day vulnerability is defined as a security flaw that has not yet been disclosed to the vendor or developers".

Как видим, согласно некоторым определениям раскрытие информации (disclosure) требуется для отнесения уязвимости к Zero Day, а согласно другим вроде как и нет.

В глоссарии NIST нет понятия "zero day vulnerability".

В глоссарии ФСТЭК Уязвимость нулевого дня (Zero-day vulnerability) это "уязвимость, которая становится известной до момента выпуска разработчиком программного обеспечения информационной системы мер защиты информации по ее устранению, исправлений ошибок или соответствующих обновлений". Тут тоже не вполне понятно "становится известной" широкому кругу лиц или вообще, даже одному исследователю?

Лично мне НЕ нравится идея называть уязвимость Zero Day только в момент её опубликования. Почему? Если мы определяем таким образов, то в случае тайного зловредного использования уязвимости (например #Eternalblue до утечки из NSA) мы не можем сказать что это было использование Zero Day уязвимости. Публикации же (пока) не было! Хотя очевидно это было именно использование Zero Day уязвимости.

Ок, можем подкрутить и говорить, что нужно либо опубликование, либо использование. И какое использование? Вот есть исследователь, нашедший уязвимость. В ходе ресерча он эту уязвимость явно как-то использовал / тестировал на чем-то. Получается нужно не простое использование, а зловредное. А как определить зловредность? Это тоже добавляет неразберихи.

Поэтому мне кажется, что проще и непротиворечивее считать за Zero Day вообще любую уязвимость до момента появления фикса от вендора (патч или workaround). После публикации фикса называть уязвимость Zero Day оправдано только если мы говорим о каких-то прошедших событиях, когда фикса ещё не было.