Содержание статьи
- 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 и определить узлы с наибольшим количеством связей (пример на рисунке отмечен желтым).
Продолжение доступно только участникам
Материалы из последних выпусков становятся доступны по отдельности только через два месяца после публикации. Чтобы продолжить чтение, необходимо стать участником сообщества «Xakep.ru».
Присоединяйся к сообществу «Xakep.ru»!
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее