Содержание статьи
- Secure by Design: принципы построения защищенных систем от Google
- Стратегия выявления угроз: на чем сосредоточить усилия при разработке методов обнаружения?
- Анализ уязвимостей нулевого дня, которые применялись для атак в прошлом году
- Повышение уровня наблюдаемости процессов DevSecOps
- Уязвимости на GitHub: в библиотеке Ruby, которую скачали 250 тысяч раз, в модулях для электронных замков и в популярных играх
- Подборка исследований с Black Hat 2024
- RSA Conference 2024: анонсы перспективных технологий
- Перспективные инструменты: средство для поиска вредоносных зависимостей PyPI и NPM
- Перспективные инструменты: файл со списком самых популярных паролей
- О чем может рассказать тень на фото?
- Критическая уязвимость в сетевом стеке Windows
Вообще говоря, материал не совсем за год: предыдущую подборку я публиковал в апреле 2024-го. Но с того времени исследователи накопили много всего интересного. Давай пройдемся по ресерчам и посмотрим, что из этого можно будет применять на практике, а что просто стоит закинуть в голову.
Secure by Design: принципы построения защищенных систем от Google
Весной этого года в новых версиях широко применяемой библиотеки liblzma нашли умело спрятанный бэкдор, а я тогда как раз изучал документ Secure by Design at Google. В нем инженеры безопасности пересмотрели принципы построения современных приложений.
Цель материала — сократить разрыв между концептуальными требованиями Secure by Design и их практическим применением.
Инженеры Google столкнулись с вызовом: скорость изменений в программном обеспечении и в особенности в облачном ПО настолько высока (несколько релизов в день), что не позволяет реализовать существующие требования безопасности, которые актуальны скорее для физических систем. Потому что в физических системах после тщательного проектирования архитектуры риск появления дефектов на этапе производства низкий по сравнению с риском появления дефектов в ежедневных обновлениях ПО.
Дизайн, ориентированный на пользователя, пожалуй, ключевое требование. На практике оно означает необходимость готовить требования безопасности и архитектуру продукта вокруг действий его пользователя. Для каждого действия нужно проводить оценку того, как оно может привести к неблагоприятным последствиям. При этом разработчик тоже пользователь.
Еще один интересный момент — дизайн‑мышление в терминах инвариантов. Инвариант — свойство системы, которое остается неизменным при любых действиях ее пользователя или действиях атакующего. В контексте безопасности инвариант означает неизменяемое состояние системы, например: весь сетевой трафик, проходящий через незащищенные каналы, всегда защищен с использованием надежного протокола.
Инварианты безопасности помогают исключить требования к пользователям и при проектировании сфокусироваться на требованиях к системе, с которой работает этот пользователь. При этом реализация всех инвариантов может быть проверена автоматически на этапе анализа качества ПО.
Кстати, когда‑то появилась концепция «неизменяемой инфраструктуры» (Immutable Infrastructure), и теперь инварианты дают архитектору возможность реализовать эти принципы на этапе разработки.
Стратегия выявления угроз: на чем сосредоточить усилия при разработке методов обнаружения?
Как эффективно выявлять угрозы при ограниченном ресурсе? Как оценить качество методов обнаружения? Я встретил серию статей, автор которых ищет ответы на эти вопросы.
Security-инженеры и аналитики SOC знают, что ключевая цель при выявлении угроз — создание механизмов для обнаружения и предотвращения как можно большего количества методов, которые использует злоумышленник для продвижения.
Эта цель превращается в решение задачи: не допустить, чтобы атакующий прошел все этапы своего пути и остался незамеченным. С этого момента начинается игра вероятностей: насколько вероятно, что атакующий пойдет по пути, который не заметит защищающийся?
Здесь помогает следующая модель:
- Представляем каждую технику матрицы MITRE ATT&CK в виде точки.
- Путь атакующего от получения первичного доступа до продвижения цели можно представить в виде определенной последовательности точек.
- Техники матрицы, у которых есть множество подтехник, можно также разложить на группы точек (размер группы увеличивает вероятность успешного применения конкретной техники).
- Каждую подтехнику можно применить с помощью разных процедур и инструментов — это добавляет еще больше точек в группы.
- Тактика выявления: чем больше процедур в рамках одной подтехники охватывает метод обнаружения, тем лучше такой метод. Эффективный метод обнаружения — тот, который выявляет процедуру с наибольшим количеством связей с другими процедурами.
И вот тут возникает гипотеза, которую можно проверить в рамках исследовательской работы: составить граф всех процедур MITRE ATT&CK и определить узлы с наибольшим количеством связей (пример на рисунке отмечен желтым).

Продолжение доступно только участникам
Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
Вариант 2. Открой один материал
Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.
Я уже участник «Xakep.ru»