ZN2021_Rybin.pdf

Transcript

1. О МЕТРИКАХ С ПРАКТИЧЕСКОЙ ТОЧКИ ЗРЕНИЯ Denis ttffdd Rybin
2. 2 Whoami Денис ttffdd Рыбин Head of AppSec @ mail.ru Соавтор ИБ-подкаста Мимокрокодил Ресерчер Пентестер
3. 3 Spoiler #1 Авторский доклад: • Личные мнение + релевантный опыт работы • Общение с коллегами и сбор позиций • Публичные материалы показавшиеся интересными
4. 4 Зачем вообще метрики? • Для себя. Ответить на вопрос «какой результат моих действий и полезно ли это компании?» • Для бизнеса. Обосновать бюджет/ресурсы/премии etc. Так тоже можно, но не единственный путь
5. 5 Почему метрики не нравятся? Топ 4: • "Мне достаточно моей чуйки" • "Невозможно посчитать" • "Вода, результаты не применимы на практике" • "Пока будешь метрики считать тебя взломают"
6. 6 Мне достаточно моей чуйки • Мы не хотим "думать на бумажке". Если хотим, не надо называть это метрикой • Для обоснования бизнесу может и сработать, но нам пользы в понимании не даст. 𝑓 𝑓 𝑓(𝑐ℎ𝑢𝑦𝑘𝑎 + 𝑓 𝑐ℎ𝑢𝑦𝑘𝑎 ) ∗ 𝑓(𝑐ℎ𝑢𝑦𝑘𝑎) ! " Пример "плохой" метрики: Вероятность эксплуатации * потенциальный ущерб = Итоговый риск Как обычно выглядит на практике : 𝑓 𝑐ℎ𝑢𝑦𝑘𝑎 ∗ 𝑓(𝑐ℎ𝑢𝑦𝑘𝑎) = 𝑓(𝑐ℎ𝑢𝑦𝑘𝑎) ! Уход от объективной реальности с квадратичной скоростью
7. 7 Мне достаточно моей чуйки Ваша чуйка все равно никуда не денется и будет влиять на выбор
8. 8 Невозможно посчитать • Реальная проблема всех метрик, нужно быть предельно осторожным • Крутая сферическая метрика в вакууме это RoSI (Return On Security Investment). Просто, понятно бизнесу, полезно бизнесу. • Только никто еще не научился считать пользу безопасности в сэкономленных деньгах не на основе 𝑓 𝑐ℎ𝑢𝑦𝑘𝑎 (Точно не я) • Но это не значит, что пользу извлечь невозможно!
9. 9 Вода, результаты не применимы на практике Самый дискуссионный аргумент, все упирается в качество метрик и понимание зачем они вам. Поэтому я и делаю этот доклад.
10. 10 Пока будешь метрики считать тебя взломают • Действительно, до определенно уровня зрелось такие "высокие материи" должны волновать мало, если все плохо и это очевидно, вам не нужны продвинутые методы анализа, бегом чинить прод! • Однако, спустя какое-то время прод станет взрываться реже и вы задумаетесь чем теперь правильно заняться. (или не станет, тогда вы что-то делаете не так и чтобы понять что, вам могут помочь метрики)
11. 11 Хорошая метрика, это вообще как? Daniel Miessler считает так: • Decision-enabling • Tangible • Narrative-supporting • Data-backed • Repeatable • Resource-adjusted • Discrete • Track what matters, not what is trackable • Less is Usually More
12. 12 Data-backed and data-driven Важно пояснить. Мы хотим перейти из состояния принятий решения по методике chuyka-driven в data- driven + щепотка chuyka-driven Data-driven это такой полноценный buzzword из мира бизнеса, чем мы хуже?
13. 13 Метрики это observability У безопасников есть мантра ”Нельзя защитить систему о существовании которой ты не знаешь" Это мантра применима и к уровню защищённости ”Нельзя улучшить безопасность системы, если ты не знаешь её текущий уровень защищённости"
14. 14 Spoiler #2 • Метрики для AppSec • Все метрики имеет смысл считать хотя бы квартальными итерациями • Никак советов как настроить Defect Dojo, Grafana, Jira etc
15. 15 Сигналы (данные) • Bug Bounty • DevSecOps/automatization • SOC/SIEM • Development + Code Review • Pentests
16. 16 Конкретика (finally!) Лучший материал на тему - презентация HP Magic Numbers, настоятельно рекомендую ознакомиться напрямую.
17. 17 Weighted Risk Trend • Упражнение номер 0 • Инвентаризация активов, ранжирование по бизнес критичности, понять trust boundary. • Пытаемся не скатиться в 𝑓 𝑐ℎ𝑢𝑦𝑘𝑎 • Нужно скользящее окно Что считаем? [ (critical x defects) + (high x defects) + (medium x defects) + (low x defects)] * Criticality business
18. 18 Defect Remediation Window • Сложнее, чем кажется • Отдельно для легаси и новых проектов • Отдельно для критов и не критов • Для не критов намного важнее Что считаем? Время от обнаружения до устранения Альтернатива Признак сходимости
19. 19 Defect discovery window* • Определить для себя, что считать появлением • Напрямую влияет на вероятность эксплуатации • Позволяет оценивать здоровье BugBounty и аудитов • Опять приходится делить на легаси и новое Что считаем? Время с момента появления уязвимости до обнаружения и подтверждения * - Нет в Magic Numbers
20. 20 Specific Coverage Metric • Непонятно зачем как метрика • Но очень полезное упражнение • Умеете ли вы получать список всех своих проектов/серверов/API? Что считаем? ПОКРЫТИЕ
21. 21 Альтернатива 87 66 15 9 Проекты Активно разрабатываются Есть выделенный безопасник Есть тесты безопасности Воронка безопасности* * - Этапы должны соответствовать используемыми вами практиками ИБ
22. 22 Security to Quality defect Ratio • Самая простая для расчета • Важно понять сразу ваши разработчики плохо разрабатывают безопасно или просто плохо разрабатывают • С первым можно воевать самостоятельно, со вторым - нет Что считаем? Дефекты безопасности Все дефекты При этом поглядывать на абсолютные значения.
23. 23 По хорошему, that's all
24. 24 По хорошему, that's all Но я люблю поговорить
25. 25 OWASP SAMM v2
26. 26 OWASP SAMM v2 • Не метрика, а maturing model • Очень крутой способ «думать на бумажке» • Полезно для стратегического планирование, работает в связке с метриками • Как метрика очень близко к 𝑓 𝑐ℎ𝑢𝑦𝑘𝑎 потому что self-assessment
27. 27 OWASP ASVS
28. 28 OWASP ASVS • Может использоваться для аудитов и выдавать сигнал для метрик • Слишком большой и трудоемкий для не критичных для бизнеса проектов • Мне не нравится
29. 29 Ну и конечно • Безопасность системы это безопасность наиболее слабого звена цепи бла-бла-бла… • AppSec не существует в отрыве от людей, процессов и инфраструктуры бла-бла-бла… • Команда безопасности осуществляет контроль, изменения вносит разработка бла-бла-бла…
30. THANKS FOR ATTENTION
31. QUESTIONS THANKS FOR ATTENTION