Contextual Vulnerability Management With Security Risk As Debt

Я думаю, каждый, кто занимался построением программы управления уязвимостями или хотя бы раз пытался добиться от ИТ-команд их устранения, знает, насколько сложно обеспечить соблюдение установленных SLA. Зачастую SLA берутся «с потолка» и, как правило, далеки от реальных возможностей организации по быстрому устранению выявленных уязвимостей. В результате в организации возникает общая фрустрация, где все сталкиваются с удручающими отчетами. А CISO за "кружкой пива" мрачно заявляет, что "у него в бэклоге 3 миллиона уязвимостей" и "он/она не знает, что с ними делать!". И хотя из общих соображений понятно, что здесь придется обращаться к приоритезации и мудрости в духе общества анонимных алкоголиков:

Господи, дай мне спокойствие принять то, чего я не могу изменить, дай мне мужество изменить то, что я могу изменить. И дай мне мудрость отличить одно от другого.

Всегда интересно понять, а как конкретно можно реализовать эффективный vulnerabilty management? Сегодня мы предлагаем вам ознакомиться с опытом DigitalOcean по внедрению методики «технического долга». Суть такова:

1) При выявлении новой уязвимости ей присваивается определенный уровень критичности.

2) В зависимости от уровня критичности уязвимости определяется рекомендуемое время для ее устранения. Это время известно как «Accepted Insecure Time» — период, в течение которого уязвимость должна быть устранена, чтобы не накапливать долг.

3) Если уязвимость не устранена в течение рекомендованного времени, начинает накапливаться долг по безопасности. Долг рассчитывается ежедневно: за каждый день, в течение которого уязвимость остается нерешенной после истечения срока, к общему долгу добавляется определенная величина, зависящая от критичности уязвимости. Чем выше критичность, тем быстрее накапливается долг.

4) Команды могут видеть свои показатели долга по безопасности через панель управления. Они могут анализировать, какие уязвимости вносят наибольший вклад в долг, и решать, на каких из них сосредоточить свои усилия в первую очередь.

5) Для каждой команды или бизнес-подразделения устанавливается определенный порог долга — максимально допустимая сумма накопленного долга по безопасности. Если долг превышает этот порог, это сигнализирует о необходимости устранить уязвимости, чтобы вернуть показатели в допустимые рамки.

6) Для всех бизнес-подразделений рассчитывается показатель соответствия порогу долга по безопасности (Security Debt Adherence), то есть процент команд, у которых долг по безопасности соответствует ожидаемому уровню (или, иначе говоря, установленному уровню обслуживания (SLO)). Вначале DigitalOcean достигали 75% и постепенно продвигались к цели в 95%. Этот порог является согласованным компромиссом между бизнес-подразделением и командой безопасности относительно того, насколько гибким может быть график выполнения работ по безопасности. Если ускорение разработки продукта, критическая инициатива, инцидент безопасности или другой фактор изменяет верхнеуровневую оценку этой гибкости, DigitalOcean может повысить или снизить порог долга для соответствующей части организации.

В результате, по словам DigitalOcean, снизилась "ментальное давление" на команды и улучшились отношения с бизнес-подразделениями, что привело к тому, что многие другие команды начали адаптировать концепцию технического долга.

Очень красивая success story. И что характерно очень соответствующая ситуационным моделям управления ИБ, которые мы упоминали во вчерашнем посте. А как выстраиваете свой VM вы, и что используете в качестве "центральной шины"?

#vm #experience

Enhancing LinkedIn’s security posture management with AI-driven insights

В сегодняшнем нашем посте инженеры LinkedIn рассказывают о собственной Security Posture Platform (SPP) — внутренней системе, которая предоставляет динамическое представление об инфраструктуре компании и упрощает управление уязвимостями. Основная цель SPP заключается в предоставлении актуальной картины безопасности всей цифровой экосистемы компании. Платформа интегрируется с существующими инструментами безопасности и автоматизирует сбор и анализ данных, что позволяет оценивать риски практически в режиме реального времени. Это помогает проактивно управлять безопасностью, сокращая количество ручных операций.

Ключевые особенности SPP:

- Каталогизация активов: SPP собирает данные обо всех цифровых активах компании, включая физические устройства и облачные ресурсы. Это обеспечивает полную видимость инфраструктуры, что упрощает приоритизацию рисков.
- Анализ рисков и автоматизированные решения: Платформа использует метаданные для постоянной оценки рисков. Это позволяет оперативно реагировать на новые угрозы, включая упреждающие меры, такие как изоляция устройств с высоким уровнем риска.
- Централизованное управление рисками: В основе SPP лежит Security Knowledge Graph — граф знаний, который объединяет информацию о взаимосвязях между активами. Это помогает быстрее идентифицировать риски и принимать обоснованные решения. Визуальные панели предоставляют полную информацию о состоянии безопасности пользователей и активов.

Для повышения эффективности в условиях большого числа активов, команда LinkedIn добавила в SPP поддержку AI, позволяя безопасникам обрабатывать данные с помощью промптов.

Немного про AI в платформе:

- Генерация контекста: Исходные данные, такие как метаданные из различных источников, преобразуются в формат, понятный AI-моделям, что повышает эффективность ответов на запросы пользователей.
- Создание запросов: AI анализирует пользовательские запросы и трансформирует их в команды для поиска данных в графе знаний, используя нетривиальные механизмы для оптимизации запросов и повышения точности.
- Маршрутизация запросов: Запросы распределяются по различным источникам данных с минимальной задержкой, что обеспечивает высокую скорость ответов.
- Обобщение данных: AI также выполняет обобщение информации, предоставляя краткие и информативные ответы.

В процессе разработки системы команда LinkedIn столкнулась с рядом технических проблем. Одной из них было ограничение ранних AI-моделей (старая модель Davinci, относящаяся к GPT3) , которые не справлялись с объемами данных в графе знаний. Также возникали сложности с управлением «галлюцинациями» AI, когда система предоставляла неверные ответы. Для решения этих проблем были внедрены сложные системы тестирования и итеративная настройка моделей, что значительно повысило точность ответов.

Результаты работы SPP впечатляют: время реагирования на уязвимости сократилось на 150%, а охват цифровой инфраструктуры увеличился на 155%.

Красивая success-story без единого скриншота и ссылок на open-source😄

#ai #experience

How to 10X Your Security (without the Series D)

Мы регулярно обращаем внимание на работы и выступления экспертов, за которыми следим, и на этот раз хотим выделить Рами МакКарти, имя которого слышно на конференциях по облачной безопасности. Недавно он опубликовал материалы своего доклада под названием "How to 10X Your Cloud Security (Without the Series D)”, за интригующим заголовком которого скрывается гораздо больше, чем облака. Ключевые тезисы доклада ниже. Запись доступна по ссылке
 
Основные "философские идеи" для компаний, стремящихся к быстрому масштабированию:
 

- Занимайтесь тем, что нельзя автоматизировать, и автоматизируйте всё возможное, чтобы эффективно масштабироваться. Не нужно автоматизировать то, что можно сделать быстрее руками. Автоматизируйте те процессы, которые очевидно подвергнуться масштабированию (например, предоставление доступов).
- Масштабируйтесь только тогда, когда отработали процессы на небольшом объёме, чтобы избежать излишней нагрузки на дашборды.
- Делайте выбор в пользу guardrails, а не gatekeepers. Про эту тему мы не так давно делали отдельный пост.
- Интегрируйте безопасность в процессы разработки с самого начала, рассматривая её как партнёра, а не как отдельную структуру. Избегайте ситуации, когда безопасность становится лишь консультантом команд, так как эта модель не масштабируется. Стремитесь к shared responsibility, делая безопасность общей задачей. А ещё это единственный стратегический вариант закрыть дефицит кадров и демографический спад, если вы не ооочень большая и интересная для ширнармас компания.
- Сведите к минимуму количество инициатив по внедрению новых решений в области безопасности, не стремитесь интегрировать всё увиденное на конференциях. Лучшее враг хорошего + keep it simple никто не отменял.
- Не бойтесь использовать пробные версии и демо-версии решений от поставщиков для получения полезных инсайтов без значительных затрат. Это не исключает дальнейшее добавление вендора в шорт-лист, но позволит вам изучить новые подходы и инновации на практике.

 
Рами выделяет ключевые категории безопасности, которые способствуют масштабированию компании:
 

- Security Program
- Invariants
- Vulnerability & Asset Management
- Identity & Access Management 
- Detection (Engineering)
- Deployment

 
В заключении представлен план действий на первые 30-60-90 дней:

- В первые 30 дней сосредоточьтесь на оценках, выстраивании отношений с коллегами и установлении baselines.
- В течение следующих 60 дней реализуйте одно заметное улучшение, которое продемонстрирует результат.
- В течение следующих 90 дней начните планировать масштабирование, создавая повторяющиеся процессы и стратегию для дальнейшего укрепления безопасности.

 
Стоит отметить, что доклад создан на основе работы "How to 10X Your Security (Without the Series D)" (https://youtu.be/tWA_EBNsQH8?si=KYsJs41Wk7DaLFmP) Клинта Файбера, материалы которого уже не раз упоминались в нашем канале.

Вроде бы все банально. Но как часто эти идеи реализуются на практике? И что мешает их воплощению в жизнь?

#cloud #experience #management