Ой эй 😟

приятные мелочи, но все же мило ;)

🏆 Управление Findings: реальность метрик

Когда toolchain начинает лить сотни срабатываний — команда быстро перестаёт им доверять и ценность AppSec резко падает. Думаю, что все таки стоит разобраться с тем, как это полечить, поэтому возьмем кейсы на базе моей практики.

На конфе я рассказал кулуарно как это считается, почему именно такой подход выбрал и что же важно для него. Давай смотреть на метрики:

• False Positive Rate = (закрыто как FP / всего срабатываний) × 100% - на ruleset пороги инструмента (SQL Injection, XSS, SSRF и т.д.)

Реко:
— ≤ 15% — инструмент адекватно считает (если вы делали качественно и не все в исключение отправляли)
— 15–30% — жёлтая зона, нужна донастройка правил
— > 30% — красная зона, следовательно немедленный аудит правил инструмента
— < 5% — проверьте False Negative или что-то повалилось

• FPR по CWE: FPR(CWE XXX) = FP / все сработки × 100% - отдельные критичные моменты, которые подходят чисто под вашу специфику и стек. Если FPR по CWE > 30%, то добавляйте sink/ source whitelist, context-aware фильтры, исключения по аннотациям для правила сработки.

Пример:
— CWE-89 (SQL Injection) — низкий FPR при правильном парсинге AST, но высокий при regex
— CWE-79 (XSS) — FPR зависит от контекста вывода HTML/ JS/ attr
— CWE-22 (Path Traversal) — высокий FPR из-за ложных taint-цепочек в ORM
— CWE-611 (XXE) — низкий FPR и частый FN из-за кастомных XML
— CWE-502 (Insecure Deserialization) — один из самых назойливых FPR

• Risk-based приоритизация срабатываний: Priority Score = CVSS × EPSS × Reachability × Business Impact

Коэффициенты:
— EPSS — вероятность эксплуатации в 30 дней (0.0–1.0)
— Reachability: 1.0  — endpoint достижим снаружи/ из смежного контура;  0.2  — изолирован, нет маршрута
— Business Impact:  2.0  — external API, user data;  1.0  — internal сервис;  0.5  — dev/ test среда

Пример:
— Score = 7.5 × 0.65 × 1.0 × 2.0 = 9.75 → CRITICAL и акцент на приоритете, который эксплуатируем

• Где нет CVSS/ EPSS, то используем: AppSec Priority = Severity × Confidence (подтверждение сработки по уровню) × Reachability × Business Impact

Итого: минимальный процесс внедрения будет следующий

• Считать FPR отдельно по каждому критическому CWE — раз в спринт, общий раз в крватал или H (полугодие)
• CWE с FPR > 30% на аудит правила, не отключение
• Для каждого срабатывания считать AppSec Priority Score
• Порог для сути, где берём в работу немедленно: Priority Score > 10
• Пересматривать Confidence-коэффициенты под свой инструмент по типу 1.0  — High,  0.5  — Medium,  0.1  — Low

#appsec #reco #devsecops #specialty #paper #research #toolchain

Салюты,
Сегодня «сияем»

#lol

Ууу, родной(ая), делюсь приятностями уже от МФТИ со Сколково, оч хорошо, что после двух полноценных потоков получилась такая ОС, доволен 🫶

🤔 Метрики оценки: тащим STLC в AppSec правильно

Салют.
Часто показываю слайд с восемью метриками оценки из STLC — это классика QA-мира. На конфе, которая была, словил инсайд: необходимость доносить годность для AppSec, когда мы приравниваем баги к уязвимостям кодовой базы. Поэтому поделюсь с тобой своими мыслями. В целом эти метрики и нужны, но не прямо в лоб, потому что скопировать их нельзя, нужно переопределять.

Сначала договоримся с тобой так — тут зарыта главная подмена, где в STLC дефект — это баг, тест — тест-кейс, требование — функциональное требование. А теперь прикол в том, что:

• Дефект - это подтверждённая уязвимость True Positive
• Тест - правило/ политика анализатора ruleset
• Требование - класс угроз CWE, контроль ASVS, пункт безопасной разработки ГОСТ 56939-2024

А теперь чекай слайд:

• «Убойность» правил = подтверждённые уязвимости (TP) / число активных правил ruleset

— Низкая по ruleset, где правила сбоят или мертвы
— Аномально высокая на одном правиле, тут либо системный дефект кода, либо правило сбоит

• Доля покрытия классов угроз (широта) = CWE-классы и контроли, реально проверяемые toolchain / все релевантные для стека × 100%

— < 60% — токсично
— 60–85% — рабочая зона
— > 85% — зрелое покрытие

• Доля отклонённых срабатываний = (FP + accepted / risk accept) / все срабатывания × 100%

— высокая из-за FP, то инструмент сбоит, следовательно делаем аудит правил
— высокая из-за accepted risk, то есть то, что валит процесс, делай эскалацию

• Плотность покрытия (глубина) = число правил / число контролей (CWE / ASVS)

— < 1, показывает, что контроль покрыт формально
— несколько правил с разной логикой (AST + taint analys+ semantic ruleset)

• Плотность уязвимостей = подтверждённые уязвимости (TP) / покрытие кодовой базы (кандидаты на Secure Code Review)

• Доля регрессий уязвимостей (reopen rate) = уязвимости, вернувшиеся после «устранения» / все устранённые × 100%

— > 15% — фиксят не то и не там
— на каждую устранённую Critical/ High следует правило в Quality Gate

• Эффективность AppSec = уязвимости, взвешенные по критичности / трудозатраты AppSec (часы скан + триаж). Веса обычно: Critical 10, High 5, Medium 2, Low 0.5, а лучше перевернуть в «стоимость одной Critical-находки» = часы / число Critical.

• Плотность уязвимостей после поставки = уязвимости, найденные в PROD / обьем кодовой базы (про результат). Если плотностьне падает от релиза к релизу, лезем в проектное управление команды и собираем evidence к ним. Считай Defect Removal Efficiency для ИБ = найдено до релиза / (до релиза + после) × 100%.

Итого:

• Широту покрытия и глубину (плотность правил) считать в паре — раз в спринт детально по критичным CWE, общий срез раз в квартал или H
• Долю отклонённых всегда расщеплять на FP и accepted risk
• Плотность уязвимостей и долю регрессий смотреть каждый релиз
• Эффективность считать через стоимость Critical-находки
• Главный KPI зрелости — Defect Removal Efficiency для ИБ > 90%

#appsec #devsecops #reco #toolchain #paper #specialty

Салюты, интересное подьехало - почекай

Всем привет!

Open source по выходным: я выпустил новый релиз моей карты средств защиты ядра Linux.

Теперь она соответствует относительно свежему ядру v6.17.

Я добавил в нее новые средства защиты, устранил несколько ошибок и сделал связи еще более красивыми 🖼

Радуюсь, что все-таки находятся силы развивать этот проект!

https://github.com/a13xp0p0v/linux-kernel-defence-map

Всегда вот смотришь и думаешь, типо топовые, но с кем не бывает, да, правда ведь? 🙃

#lol

Жизненное

#lol

🤔 S.T.R.I.D.E. как рабочее решение моделирования и контроля угроз ИБ

Салюты,
Давай сегодня посмотрим на шесть классов угроз описанных в S.T.R.I.D.E. По сути это можно было увидеть во многих выступлениях, но лучше обьяснить смысл и принцип, так как без обвязки он не работает и чтобы превратить её в инструмент нужно DFD и привязка к контролям митигации.

Мы же не живем в идеально иллюзорном мире и всегда приходится что-то куда то "натягивать".

Фундаментом является Data Flow Diagram, как threat modeling с потоками данных, границами доверия. ПО факту это будут у тебя: external entity, процессы, flow, data store, trust boundaries. После только этого ты сможешь перейти к самому S.T.R.I.D.E. Концептуально это все аналитика по принципу:

• Какое свойство Паркеровской гексады нарушается?
• Типовые векторы
• Контроли
• Митигации и оценка рисков ИБ

S.T.R.I.D.E.

• S — Spoofing: подмена, где нарушается подлинность субъекта

Вектора:
• подмена пользователя, session fixation, replay токена
• подмена сервиса, как MITM, фальшивый endpoint, DNS-hijack, отсутствие mTLS между микросервисами
• подмена identity в логах через X-Forwarded-User без проверки

Контроли: MFA, mTLS с проверкой сертификатов, OAuth2/ OIDC с PKCE, привязка токенов, типа DPoP, mTLS-bound, WebAuthn/ FIDO2, anti-replay (nonce, timestamps, jti)

• T — Tampering: фальсификация, где нарушается целостность (data flow (in transit), data store (at rest), процесс (целостность кода и конфигов))

Вектора:
• модификация трафика
• подмена параметров запроса (IDOR через hidden fields, JWT с alg=none, манипуляции client-side state)
• модификация хранимых данных в обход приложения
• supply chain: подмена артефактов сборки, образов, зависимостей

Контроли: TLS актуальных версий, цифровые подписи и HMAC, контроль целостности (checksums, FIM), append-only / WORM журналы, signed commits, signed images, SBOM, контроль конфигураций)

• R — Repudiation (отказ от действий), где нарушается неотказуемость и подотчётность

Вектора:
• пользователь отрицает действие, а доказать нечем
• shared/ служебные аккаунты без идентификации
• админ модифицирует журналы постфактум
• разработчик коммитит без подписи в общую ветку

Контроли: централизованное журналирование с защитой целостности (append-only, WORM), синхронизация времени NTP, корреляция в SIEM, цифровая подпись чувствительных операций, signed commits, запрет shared accounts

• I — Information Disclosure (раскрытие информации), где нарушается: конфиденциальность

Вектора:
• нешифрованная передача
• stack trace и подробные ошибки в ответе пользователю
• BOLA / IDOR — обращение к чужим объектам по перебору ID
• PII (персонификация) и секреты в логах
• side-channel: тайминг, размер ответа, кэш-различия

Контроли: TLS, шифрование at-rest (envelope / KMS / HSM), generic-ответы об ошибках без деталей, output filtering и явные DTO, маскирование PII в логах, минимизация данных, secret management

• D — Denial of Service (отказ в обслуживании), где нарушается доступность

Вектора:
• объёмные DDoS уровней L3/ L4
• application-layer DoS: медленные запросы (slowloris), catastrophic regex backtracking, zip/XML-бомбы, billion laughs
• исчерпание ресурсов: утечки памяти, connection pool, unbounded queues

Контроли: rate limiting и throttling, WAF / DDoS-защита, ограничения размера, времени и глубины, circuit breakers, авто-масштабирование, бэкапы и DR, capacity planning

• E — Elevation of Privilege, где нарушается: авторизация

Вектора:
• BOLA / BFLA: нет проверки прав на объект или функцию
• вертикальная эскалация
• горизонтальная эскалация
• sandbox escape
• JWT-tampering
• RCE через десериализацию

Контроли: RBAC / ABAC с deny-by-default, проверка авторизации на каждом запросе (а не один раз на входе в API-gateway), Segregation of Duties, least privilege, изоляция контейнеров (rootless, seccomp, AppArmor / SELinux), валидация входа, role-claims с клиента

#appsec #devsecops #reco #paper #specialty #riskanalysis

"восстание"

#lol

Салюты,
Я тут как то забыл сказать, что мне подарили второго котенка, то есть у меня пополнение, а имя у него: Коннор ;) кто в теме, тот в теме

А вот моя первая красотка 🙃

Ух, меня тут позвали на съемку 15 выпуска новостного подкаста по безопасной разработке, вот посмотри как это выглядит тут.

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

#appsec #devsecops #specialty #paper