Как оценить риски в кибербезопасности. Лучшие инструменты и практики - Ричард Сирсен

Вам все еще многое неизвестно о реальном состоянии средств обеспечения облачной безопасности компании, но, кажется, ситуация даже хуже, чем вы предполагали. Поэтому, чтобы было проще сделать выводы, вы решаете смоделировать большое количество результатов, основанных на новых суждениях (апостериорных). Это такой завуалированный способ сказать: «У меня нет времени проводить аудит всех приложений. Что если использовать известные мне данные в качестве вводных для симуляции?

Симуляция смоделирует 1000 аудитов и даст мне представление о том, какими могут быть будущие результаты аудита, учитывая уже известные данные». Кроме того, вы формулируете результат в виде 90 %-ного ДИ, что означает: «Я на 90 % уверен, что истинное значение действующих средств контроля безопасности компании XYZ находится между x% и y%». Давайте сначала получим 90 %-ный ДИ:

> beta.post.par <– beta.par + c(5, 30)

> qbeta(c(0.05, 0.95), beta.post.par[1], beta. post.par[2])

[1] 0.1148617 0.3082632

Все довольно просто: получаем значения альфа и бета из новых апостериорных данных и передаем их в простую функцию под названием qbeta. Первый параметр, c(0.05,0.95), просто обозначает наш 90 %-ный ДИ. Теперь смоделируем множественные тесты и получим 90 %-ный ДИ из них для более тщательной проверки.

> post.sample <– rbeta(1000, beta.post.par[1], beta.post.par[1], beta.post.par[2])

> quantile(post.sample, c(0.05, 0.95))

5% 95%

0.1178466 0.3027499

Похоже, интересующая нас доля, скорее всего (с уверенностью 90 %), окажется в диапазоне от 12 до 30 %. Можно пойти дальше и попытаться спрогнозировать, какие результаты будут получены в следующих 200 аудитах. Делается это так:

> num <– 200

> sample <– 0:num

> pred.probs <– pbetap(beta.post.par, num, sample)

> discint(cbind(sample, pred.probs), 0.90)

> [1] 0.9084958

> $set

[1] 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

[20] 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

[39] 55 56

Как видно из модели, можно быть на 91 % уверенными в том, что у следующих 200 аудитов будет от 17 до 56 успешных результатов. Теперь нужно построить финансовые модели для оценки стоимости устранения последствий и вероятности нарушения безопасности. Именно этот последний вопрос вызывает наибольшее беспокойство. Какой риск на самом деле вам перейдет? Какова вероятность того, что нарушение безопасности уже произошло или происходит сейчас?

Это был очень простой пример, который можно легко реализовать в Excel, Python или на «умном» калькуляторе. Суть в том, что начинать интересные и полезные измерения можно прямо сейчас. Как лидер вы будете прибегать к этому типу аналитики как к личному оружию гораздо чаще, чем к любым другим метрикам.

1. Andrew Gelman, “N Is Never Large,” Statistical Modeling, Causal Inference, and Social Science (blog), July 31, 2005, http://andrewgelman.com/2005/07/31/n_is_never_larg/.

2. Andrew Jaquith, Security Metrics: Replacing Fear, Uncertainty, and Doubt (Upper Saddle River, NJ: Pearson Education, 2007).

3. Jim Albert, Bayesian Computation with R (New York: Springer Science & Business Media, 2009).

Глава 11. Насколько эффективно взаимодействуют мои вложения в безопасность?

В главе 10 была представлена модель зрелости метрик операционной безопасности, которая начиналась с анализа скудных данных. Такова в действительности и основная тема данной книги: «Как проводить измерения, а затем принимать решения, во что инвестировать при высокой степени неопределенности, вызванной ограниченными эмпирическими данными». В главах 8 и 9 представлены основные методы моделирования, используемые для анализа скудных данных. Цель – принять наилучшее решение с учетом обстоятельств. И, если помните, решение – это «бесповоротное распределение ресурсов». Другими словами, выписывая чек, вы знаете, что приняли решение. Прекращаются ли измерения, после того как вложения сделаны? Конечно, нет!

Что же измеряется дальше? После принятия решения (т. е. инвестиций) определяется, получены ли те результаты, ради достижения которых делались вложения. Для специалиста по безопасности это – область метрик операционной безопасности. Инвестировав в безопасность, необходимо измерить, насколько вложения соответствуют конкретным показателям, под которыми часто понимаются КПЭ.

Если вы инвестировали значительные денежные средства, следом потребуются непрерывные «автоматизированные» измерения, направленные на оптимизацию. Скорее всего, вами сделано несколько вложений, и все вместе они воздействуют на один или несколько ключевых рисков. Когда речь идет об интеграции источников данных для оценки сведений об эффективности за предшествующий период, необходимы метрики безопасности, больше напоминающие бизнес-аналитику (БА). Есть много замечательных книг по БА. Большинство из них толстые, а некоторые даже насчитывают несколько томов. Так зачем углубляться в эту тему и чего можно добиться всего за одну главу?

Лично мы не знаем ни одной книги, в которой БА рекомендовали бы для измерений в сфере кибербезопасности. И это полное безобразие. В своей книге, Security Metrics, Джеквит даже отговаривает от подобного подхода. Более 10 лет назад, возможно, мы бы разделили его мнение (хотя один из авторов в то время витрины данных безопасности пек как блины). Однако риски и технологии развиваются, и нам следует развиваться тоже. Усовершенствовались аналитические технологии, особенно с открытым исходным кодом, а системы безопасности все чаще «дружат» между собой. У большинства решений по обеспечению безопасности на уровне предприятия есть интерфейс программирования приложений (API) и/или прямое подключение к базе данных для извлечения корректно сформированных и согласованных данных. Проще и быть не может. Так что наша первоочередная цель – познакомить читателей с этой классической