Что такое Cloud Security KPI и существуют ли они в природе?
Пойди туда... не знаю, куда... И принеси то... не знаю, что...
Последние несколько недель сражаюсь с задачей выработки набора KPI для оценки эффективности мер, направленных на обеспечение безопасности облачных систем. (Напомню, что, согласно определению, KPI - это метрика, оценивающая степень эффективности достижения стратегических целей.)
С первого взгляда - вроде бы, простая задача. Если запросить в гугле "cybersecurity kpi to track in 2022", то выдача будет содержать достаточно много релевантных результатов разной степени полезности. Но если начать вчитываться, то бОльшую часть этих KPI никак невозможно применить к облаку. А те, что можно, - скорее, не KPI, а scorecards/benchmarks. Запрос в лоб "cloud security kpis" ведет к статьям, подобным вот этой, где метрики определяются для оценки с точки зрения финансов, айтишников, бизнеса... чего угодно, только не безопасности.
На какое-то время я погрузилась в изучение разницы между KPI, OKR (objectives and key results) и BSC (balanced score cards). Я посмотрела несколько интересных видео, например Tanya Janca - Security Metrics That Matter или Creating a Security Metrics Program: How to Measure Success. Потому как из определения следует, что каждый KPI является метрикой, но не каждая метрика является KPI.
Я нашла рекомендации по выработке KPI для SOC с использованием CMM (capability maturity level). Если сделать запрос "cloud securiy cmmc", то в результатах будет лишь система сертификации для контрактников US DoD, поддерживаемая FedRAMP. Ну тут все просто: если ты работаешь в зарегулированной области - будь добр соблюдать соответствующие стандарты. Вот тебе и хороший compliance KPI. А что если ты - просто коммерческое предприятие, но тоже хочешь понять, "насколько" ты в безопасности или улучшилась ли безопасность за заданный промежуток времени?
Я пыталась выяснить, как можно использовать CSPM (Cloud Security Posture Management) для выработки или оценки правильности выбора KPI. Попутно чуть не потерялась в лесу аббревиатур CSPM/CWPP/CNAPP/CASB, но вовремя опомнилась.
С практической точки зрения, достижение приемлимого уровня безопасности для облака мало чем отличается от процедур для "традиционной системы": получайн уведомления о релевантных уязвимостях, рекомендованных настройках, новых патчах. Не ленись патчить (и тестировать патчи перед выкатыванием в прод!). Настрой агрегатор логов с автоматическим анализатором, чтобы не утонуть в потоке информации. Автоматизируй коррекцию выявленных проблем, насколько возможно. Делай бэкапы или убедись, что их за тебя делает провайдер. Обучай админов и пользователей.
Более того, теперь у каждого вендора есть свой Security Score Card. Например, в Azure Security Center maximum score = 50, a в AWS Security Hub можно получить максимум 100 очков.
Логичным подходом было бы посмотреть, на каких проблемах ты теряешь очки, и что можно сделать, чтобы приблизиться к заветным 50 и 100 пунктам, соответственно (все варианты хороши, кроме "отправить все проблемы, которые мне не нравятся, в игнор"). Но я могу себе легко представить ситуацию, когда в двух облачных системах одинаковый security score, но в одной больше проблем повышенной критичности, а в другой - просто очень много мелких недочетов. Поэтому нельзя KPI строить только на основе security score.
Или ввести, например, правило, чтобы минимально приемлемый уровень был 40 и 80, соответственно? А почему именно 40 и именно 80?
Можно еще ввести правило, что не менее 70% выявленных проблем должны решаться автоматически (с другой стороны, легче изначально запретить создание, например, машин с публичным айпишником в заведомо внутренней сети, тогда ситуация и не дойдет до выявления проблемы). Или вообще сказать, что у меня весь продакшен - infrastructure as a code, ничего ручками там никому трогать не разрешено, и все автоматизировано. Тогда возникнут претензии к таким вещам, как container registry или vm image library, а это, как мне сказали, находится за пределами *облачной* безопасности. Опять плохой выбор KPI.
У меня такое впечатление, что если бы cloud security kpi можно было бы выработать, то соответствующий буклетик был бы у каждого вендора, потому что бизнес любит KPI и не хочет говорить на языке технологий. Чем больше ты можешь говорить на языке ценностей бизнеса - тем лечге продавать. В реальности же ничего лучше scorecards/benchmarks, требующих индивидуальной интерпретации, они предложить не могут.
Хотелось бы запросить помощь зала :-Р
Последние несколько недель сражаюсь с задачей выработки набора KPI для оценки эффективности мер, направленных на обеспечение безопасности облачных систем. (Напомню, что, согласно определению, KPI - это метрика, оценивающая степень эффективности достижения стратегических целей.)
С первого взгляда - вроде бы, простая задача. Если запросить в гугле "cybersecurity kpi to track in 2022", то выдача будет содержать достаточно много релевантных результатов разной степени полезности. Но если начать вчитываться, то бОльшую часть этих KPI никак невозможно применить к облаку. А те, что можно, - скорее, не KPI, а scorecards/benchmarks. Запрос в лоб "cloud security kpis" ведет к статьям, подобным вот этой, где метрики определяются для оценки с точки зрения финансов, айтишников, бизнеса... чего угодно, только не безопасности.
На какое-то время я погрузилась в изучение разницы между KPI, OKR (objectives and key results) и BSC (balanced score cards). Я посмотрела несколько интересных видео, например Tanya Janca - Security Metrics That Matter или Creating a Security Metrics Program: How to Measure Success. Потому как из определения следует, что каждый KPI является метрикой, но не каждая метрика является KPI.
Я нашла рекомендации по выработке KPI для SOC с использованием CMM (capability maturity level). Если сделать запрос "cloud securiy cmmc", то в результатах будет лишь система сертификации для контрактников US DoD, поддерживаемая FedRAMP. Ну тут все просто: если ты работаешь в зарегулированной области - будь добр соблюдать соответствующие стандарты. Вот тебе и хороший compliance KPI. А что если ты - просто коммерческое предприятие, но тоже хочешь понять, "насколько" ты в безопасности или улучшилась ли безопасность за заданный промежуток времени?
Я пыталась выяснить, как можно использовать CSPM (Cloud Security Posture Management) для выработки или оценки правильности выбора KPI. Попутно чуть не потерялась в лесу аббревиатур CSPM/CWPP/CNAPP/CASB, но вовремя опомнилась.
С практической точки зрения, достижение приемлимого уровня безопасности для облака мало чем отличается от процедур для "традиционной системы": получайн уведомления о релевантных уязвимостях, рекомендованных настройках, новых патчах. Не ленись патчить (и тестировать патчи перед выкатыванием в прод!). Настрой агрегатор логов с автоматическим анализатором, чтобы не утонуть в потоке информации. Автоматизируй коррекцию выявленных проблем, насколько возможно. Делай бэкапы или убедись, что их за тебя делает провайдер. Обучай админов и пользователей.
Более того, теперь у каждого вендора есть свой Security Score Card. Например, в Azure Security Center maximum score = 50, a в AWS Security Hub можно получить максимум 100 очков.
Логичным подходом было бы посмотреть, на каких проблемах ты теряешь очки, и что можно сделать, чтобы приблизиться к заветным 50 и 100 пунктам, соответственно (все варианты хороши, кроме "отправить все проблемы, которые мне не нравятся, в игнор"). Но я могу себе легко представить ситуацию, когда в двух облачных системах одинаковый security score, но в одной больше проблем повышенной критичности, а в другой - просто очень много мелких недочетов. Поэтому нельзя KPI строить только на основе security score.
Или ввести, например, правило, чтобы минимально приемлемый уровень был 40 и 80, соответственно? А почему именно 40 и именно 80?
Можно еще ввести правило, что не менее 70% выявленных проблем должны решаться автоматически (с другой стороны, легче изначально запретить создание, например, машин с публичным айпишником в заведомо внутренней сети, тогда ситуация и не дойдет до выявления проблемы). Или вообще сказать, что у меня весь продакшен - infrastructure as a code, ничего ручками там никому трогать не разрешено, и все автоматизировано. Тогда возникнут претензии к таким вещам, как container registry или vm image library, а это, как мне сказали, находится за пределами *облачной* безопасности. Опять плохой выбор KPI.
У меня такое впечатление, что если бы cloud security kpi можно было бы выработать, то соответствующий буклетик был бы у каждого вендора, потому что бизнес любит KPI и не хочет говорить на языке технологий. Чем больше ты можешь говорить на языке ценностей бизнеса - тем лечге продавать. В реальности же ничего лучше scorecards/benchmarks, требующих индивидуальной интерпретации, они предложить не могут.
Хотелось бы запросить помощь зала :-Р