Linux privilege escalation: defensive checklist
Проверка SUID/SGID, sudoers, cron, root-сервисов, writable scripts и секретов должна быть регулярным baseline, а не реакцией после инцидента.
читать> linux / hardening// threat intel feed
Свежая повестка безопасности
Короткие аналитические заметки: что произошло, чем опасно, что проверить в инфраструктуре и как это превратить в понятный action plan.
// update
Privilege escalation и attack paths как язык защиты
Новые материалы на этой неделе связаны одной идеей: зрелая безопасность смотрит не только на CVE, но и на путь атаки. Linux hardening, Active Directory graph, KEV-first patching и supply-chain контроль должны сходиться в один remediation roadmap.
LINUXADKEVCI/CDSECRETSRETEST
Active Directory attack paths для защитников
Сервисные аккаунты, delegation, ADCS, GPO и CI/CD-узлы нужно рассматривать как граф движения к Tier 0, а не как разрозненные настройки.
читать> active-directoryKEV-first triage
Патчи нужно сортировать по эксплуатации, exposure и бизнес-роли актива. CVSS остаётся полезным, но не должен быть единственным рулём.
читать> kev / patchingSupply chain и CI/CD secrets
Главная зона риска - не только зависимость, но и runner, который видит publish-токены, cloud credentials и внутренние артефакты.
читать> supply-chainEdge-устройства снова стали первой линией атаки
По обсуждениям в профессиональных сообществах видно одно: атакующие все чаще начинают не с домена Windows, а с VPN, шлюзов, панелей управления и забытых reverse proxy. Поэтому внешний периметр нужно проверять как живой организм: версия, экспозиция, MFA, журналы входа, странные страны и внезапные ночные сессии.
источник > kev / edge-securityAI-пентест стал полезным, когда у него есть границы
Тренд из LinkedIn и AppSec-дискуссий: бизнесу нужен не автономный "робот-хакер", а помощник, который объясняет риск, убирает шум, связывает evidence с remediation и не выходит за подтвержденный scope. SecMon должен развиваться именно так: AI как аналитик, а не бесконтрольный исполнитель.
источник > ai-security / aptsБраузерный стек требует отдельного SLA
Chrome, Chromium-браузеры, Electron-приложения и расширения живут быстрее классического patch management. Если рабочая станция администратора отстает на несколько релизов, это уже не мелочь, а полноценная точка входа в инфраструктуру.
источник > browser-securityPatch Tuesday без ретеста оставляет слепую зону
Обновить систему мало. После патчей нужно переснять внешний профиль: какие порты остались открыты, не вернулись ли RDP/SMB наружу, не изменились ли TLS-настройки, не появился ли новый сервис после установки "временного" агента.
источник > patch-managementSupply chain обсуждают уже не как редкость, а как рабочую угрозу
На Reddit и в инженерных чатах все чаще спорят не о том, "бывают ли" атаки через зависимости, а о том, как быстро заметить подмену пакета, токена, CI-секрета или контейнерного образа. Практический вывод простой: SBOM, pinning, секреты вне репозитория и контроль release pipeline становятся базовой гигиеной.
источник > supply-chainРусскоязычная повестка сместилась к практичной защите
На Хабре и в русскоязычных security-обсуждениях хорошо видно взросление темы: меньше магии вокруг "сканера уязвимостей", больше разговоров про инвентаризацию, журналы, расследования, hardening, понятные отчеты и ответственность за исправления.
источник > ru-infosec// defensive checklist
Что проверить на этой неделе
KEV-first очередь: сначала CVE, которые уже эксплуатируют
VPN, reverse proxy, панели управления и SSH только по allowlist
Chrome/Chromium/Electron обновлять отдельным SLA
SBOM, pinning зависимостей и проверка CI/CD секретов
Ретест публичных доменов после каждого крупного обновления
Журналы входов: страны, ASN, время, user-agent, неудачные MFA
// source radar
Как я читаю повестку
Смотрю, что обсуждают CISO, AppSec и продавцы PTaaS: где боль бизнеса, какие формулировки покупают, какие функции требуют в enterprise security review.
Reddit / форумы
Ищу живые споры практиков: какие уязвимости реально ломают инфраструктуру, где сканеры шумят, а где дают полезный сигнал.
Хабр / RU-сообщество
Отдельно отмечаю русскоязычный контекст: администрирование, импортозамещение, VPN, SOC-практика, Windows/Linux hardening и доступный язык для читателя.
// ai security update
AI skill risk guard
Новая заметка в блоге разбирает, почему LLM-планировщик в security automation должен проходить через risk taxonomy, verified scope, allowlisted catalog и validation layer. AI-предложения остаются гипотезами до подтверждения evidence.
// обновлено
Threat Intel как action plan
Раздел дополнен свежими прикладными темами: edge/VPN hardening, 404 bursts, secrets response, SBOM triage и detection-as-code. Фокус не на сенсациях, а на том, что проверить в инфраструктуре и как превратить сигнал в задачу.
// обновлено
Threat Intel и detection engineering: меньше шума, больше решений
Threat Intel полезен, когда превращается в action plan: какие hunt hypotheses проверить, какие rules шумят, где не хватает provenance, какой telemetry layer опасно перегружать и почему release trust надо считать частью perimeter.
Detection engineering: считайте не только правила, но и шум
Количество rule files почти ничего не говорит о зрелости detection program. Намного важнее coverage intent, false positive burn rate, скорость правки и способность превратить red-team/pentest lessons в стабильные сигналы.
читать разбор →Threat hunting: гипотеза должна переживать смену инструментов
Когда hunting завязан на один SIEM-запрос или одну ручную заметку, он не переживает смену источника логов. Намного полезнее описывать hunt как reusable hypothesis flow: сущности, шаги, enrichment и критерий остановки.
читать разбор →SBOM без provenance оставляет слепую зону релиза
Компонентный состав важен, но сам по себе не отвечает на вопрос, откуда взялся артефакт и кто подтвердил его сборку. Поэтому разговор о release trust неизбежно приходит к attestations, digest pinning и verification gate.
читать разбор →// updated
SOC-поток как отдельная рабочая лента
Threat Intel теперь связан с отдельным SOC Research stream: telemetry contracts, Sigma validation, hunt-flow design, query budgets и шум как измеряемая инженерная проблема.
Detection-as-code: Sigma как язык между пентестом и SOC
Хороший пентест должен оставлять после себя не только PDF, но и идеи детектирования. Sigma помогает описать сигнал один раз и затем переводить его в SIEM-запросы.
читать разбор →Osquery/Fleet: видимость должна быть безопасной для хоста
Visibility-инструменты ценны, пока не начинают вредить целевой машине. Osquery и Fleet хороши там, где есть query budget, ownership, интервал, label targeting и понимание цены каждой таблицы.
читать разбор →Threat hunting: гипотеза должна переживать смену инструментов
Когда hunting завязан на один SIEM-запрос или одну ручную заметку, он не переживает смену источника логов. Намного полезнее описывать hunt как reusable hypothesis flow: сущности, шаги, enrichment и критерий остановки.
читать разбор →SOC Research
Отдельный исследовательский поток о том, как строить detection program без самообмана: telemetry contracts, Sigma validation, query budgets, hunt-flow design, KPI шума и нормальная передача lessons learned из пентеста и DFIR обратно в SOC.
Открыть поток →