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

Какие требования к вендорам отечественных Linux дистрибутивов можно было бы предъявить для упрощения Управления Уязвимостями?

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

Какие требования к вендорам отечественных Linux дистрибутивов можно было бы предъявить для упрощения Управления Уязвимостями?

Какие требования к вендорам отечественных Linux дистрибутивов можно было бы предъявить для упрощения Управления Уязвимостями? Если б я был регулятор. 🙂

1) Обновления безопасности должны быть. Критичная общелинуксовая уязвимость, должна быть пофикшена и в отечественном дистрибе. Или должно быть опубликовано обоснование, почему она неэксплуатируема.
2) Бюллетени безопасности должны быть. Клиенты должны как-то узнавать какую версию пакета нужно поставить, чтобы избавиться от критичной уязвимости.
3) Бюллетени безопасности должны быть публично доступны. Cпорный момент. Зависит от отношения к "security through obscurity". По мне закрытие доступ к бюллетеням усложняет жизнь исследователям, а злоумышленники все равно их получат через любого клиента.
4) Бюллетени безопасности должны быть доступны в машиночитаемом виде. Желательно в формате OVAL, раз уж он так распространен (RHEL, Suse, Ubuntu, Debian и даже отечественный RedOS)

Кстати узнал, что для RedOS есть официальный OVAL-контент (XML, 1.1 мб)

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

Кстати узнал, что для RedOS есть официальный OVAL-контент (XML, 1.1 мб)

Кстати узнал, что для RedOS есть официальный OVAL-контент (XML, 1.1 мб). И даже есть статья на русском как его использовать для детектирования уязвимостей на хостах при помощи OpenSCAP. VM-щикам сканеристам теперь можно удобно обновлять свои базы знаний, забирая данные из этой публично доступной XML-ки в стандартном формате. А не возиться с черти как оформленными бюллетеньками, которые ещё и не факт, что вообще есть. Нужно ли говорить, что в моём личном рейтинге отечественных операционных систем RedOS теперь взлетела в самый-самый топ. 😍 Молодцы 👍

Чем ответит купечество, т.е. остальные вендоры российских Linux-ов? 🙂

Про программный код, отношения и эпикуреизм

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

Про программный код, отношения и эпикуреизм

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

Но надо понимать, что использование чужого кода порождает зависимость от него. В известной степени это означает вступление в определенные отношения с автором кода. Возможно весьма токсичные. Придется приспосабливаться к возможным тараканам в голове этого человека. Автор сделал изменения, умышленно или случайно, которые поломали ваше приложение и/или испортили ваши данные? Ну что ж, вы сами виноваты. Лучше надо было тестироваться. На сайт проекта заглядывать, интересоваться что там автор делает и какую позицию по разным вопросам имеет. Уязвимости и баги в коде автора это теперь ваши общие уязвимости и баги. Автор в своем праве исправлять их в сколь угодно большие сроки или вовсе не обращать на них внимание.

Конечно без использования чужого кода не получится. Но следует проявлять при этом разумность и умеренность. Если неограниченно плодить зависимости (а значит отношения с авторами этого кода), это перестанет быть сколько-нибудь контролируемым и неизбежно приведет к проблемам. Тем более, когда использование чужого кода оправдывается не объективными насущными причинами, а тем, что так "проще писать", "на N строчек короче", "работает на 10% быстрее", "да все так делают", "уважаемый эксперт N сказал, что так делать правильно".

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

Прежде чем вкорячивать в проект очередную монструозную вундервафлю, подумай не создаёшь ли ты сам себе проблемы на ровном месте.

К примеру, если мне потребуется интеграция через http-based API я скорее разберусь сам как оно устроено и буду сам делать запросы, чем понадеюсь на непонятно кем и как поддерживаемый модуль. Если для моей частной задачи будет достаточно небольшого самописного "велосипеда", то я буду использовать его, а не мега-комбайн (привет log4j, ага).

Итого, Keep It Simple Stupid и в отношении чужого кода тоже. Лучше лишний спросить себя действительно ли эта новая зависимость нужна и не хватит ли того, на что мы уже завязались (и чьим авторам доверились).

"Величайший плод ограничения желаний — свобода." © Эпикур.

Весной-летом я толкал речи на тему как Vulnerability Management поменялся в 2022 году

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

Весной-летом я толкал речи на тему как Vulnerability Management поменялся в 2022 году. Пришла зима, скоро уже новый год, есть повод порефлексировать и скорректировать видение.

Что сканировать?

1) Оценка "стабильности" IT-вендоров похоже оказалась не особо востребованной и в итоге свелась к переходу на отечественное. Тут и позиция регуляторов направляет, и нежелание зарубежных вендоров подставляться лишний раз под вторичные санкции. Пока выглядит так, что новые IT и ИБ решения будут в основном российские (пусть даже они будут функционально хуже).
2) С другой стороны массового выпиливания продуктов Microsoft пока не наблюдается. MS пока не нагнетают. Позиция регуляторов достаточно умеренная и сводится к требованию контроля обновлений. Видима зависимость настолько велика, что требовать чего-то другого не реалистично.
3) Массового отказа от мейнстримных Linux дистрибутивов тоже не наблюдается. Пока не было громких кейсов с активным участием западных вендоров Linux дистрибутивов. Миграция c Ubuntu/Debian/CentOS Stream/Alma/Rocky на российские дистрибы связана с техническими сложностями и значительными финансовыми затратами. В целом, в ширнармассах пока не ощущается понимание зачем это нужно (за исключением случаев когда это прямое указание регулятора).

Чем сканировать?

Какого-то значимого изменения ландшафта на рынке VM-решений пока не видится.
1) Кто-то продолжает использовать западные решения с помощью разного рода ухищрений.
2) Кто-то активнее переходит на продукты традиционных отечественных VM вендоров (Positive Technologies, Алтэкс-Софт, Эшелон, Газинформсервис).
3) Есть некоторая активность от нового игрока Vulns.io.
4) Есть развитие у периметровых сервисов Metascan и ScanFactory.
5) Интересно развитие VM как доп. функциональности у Kaspersky: если все равно антивирус заменять, удобно получить в результате и агент детектирующий уязвимости. Win-win в духе Microsoft Defender for Endpoint. Выглядит как перспективная тема для агентного сканирования.
6) Достаточно много больших российских компаний приняли решение пилить свои VM решения, т.к. доступные коммерческие дороги и/или чем-то не устраивают. Есть вероятность появления таких решений на рынке.

Ещё один пример того, что NIST и MITRE не справляются с ведением базы уязвимостей

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

Ещё один пример того, что NIST и MITRE не справляются с ведением базы уязвимостей

Ещё один пример того, что NIST и MITRE не справляются с ведением базы уязвимостей. И американским регуляторам, включая CISA, видимо наплевать.

Mozilla Foundation Security Advisory 2022-09
Announced March 5, 2022
CVE-2022-26486: Use-after-free in WebGPU IPC Framework

Эта уязвимость есть в CISA Known Exploited Vulnerabilities Catalog. Значит эта критичная уязвимость эксплуатируется в реальных атаках.

Но если вы попробуете перейти по ссылке на CVE-2022-26486, например из той же CISA KEV, на сайт на NVD, то вы увидете "CVE ID Not Found". В MITRE аналогично: "RESERVED". Статус 9 месяцев не менялся (и видимо не поменяется). Что-то где-то пошло не так.

Могли бы CISA попушить NIST, MITRE или Mozilla, чтобы с этой критичной CVE навели порядок? Запросто. Но они это не делают. Им видимо норм ссылаться в никуда.

А вот в БДУ ФСТЭК для CVE-2022-26486 видим вполне адекватное описание с CVSS и всем, что нужно. ФСТЭК молодцы. 👍

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

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

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

Вспомнилась старая студенческая шутка "а сердечник для катушки выбираем деревянный, потому что все равно никто текст дипломного проекта не читает". Уязвимость Print Spooler оказывается каким-то боком касается JScript9 scripting language. 😜

Qulays по ошибке подставили для "CVE-2022-41073 | Windows Print Spooler Elevation of Privilege (EoP) Vulnerability" описание из "CVE-2022-41128 | Windows Scripting Languages Remote Code Execution (RCE) Vulnerability". Причем это же описание вставили ещё и в "CVE-2022-41091 | Windows Mark of the Web Security Feature Bypass Vulnerability". Но кто ж это читает-то. 😏

На днях вышел бюллетень CISA про эксплуатацию уязвимости Log4Shell (CVE-2021-44228) в некоторой американской государственной организации

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

На днях вышел бюллетень CISA про эксплуатацию уязвимости Log4Shell (CVE-2021-44228) в некоторой американской государственной организации. В pdf бюллетене приводится подробное описание атаки. Ознакомился. Мне, конечно, было наиболее интересно собственно про Log4Shell и начальную эксплуатацию.

1. В какой организации произошел инцидент? Непонятно. Это одна из FCEB organizations. Это может быть всем известная NASA, а может быть какая-нибудь Commission of Fine Arts. Но по большей части организации в списке выглядят критично.

2. Когда нашли? В апреле 2022. Предположительное время компрометации - февраль 2022 года.

3. Как нашли? Через ретроспективный контроль трафика с помощью CISA-вской EINSTEIN IDS. Увидели ip-адрес ранее засветившийся в атаках использующих Log4Shell.

4. Как известно Log4Shell (CVE-2021-44228 заведена 10.12.2021) касается кучи продуктов, а что именно поломали? VMware Horizon. Патч вышел 16.12.2021. Детект у Tenable для этой уязвимости (без аутентификации) вышел 07.01.2022. CISA требовали зафиксить все Log4Shell уязвимости до 24.12.2021.

5. Исходя из таймлайна, в сроки CISA (7 дней по факту) уложиться было мало реально. Причем это нужно было сделать ещё до появления нормальных детектов. Но то, что не уложились даже за 1-2 месяца вплоть до успешной атаки злоумышленников это конечно неслабое нарушение. И раз такое в принципе было возможно, CISA видимо не особо контролирует VM процесс в подопечных FCEB организациях, а сроки устранения, которые они спускают через свой Known Exploited Vulnerabilities Catalog видимо по факту не выдерживаются.