Глава 10. На пути к зрелости метрик безопасности
Когда совершенствуешься в каком-либо деле, хорошо иметь представление о том, на каком этапе находишься и куда стоит двигаться дальше. Процесс совершенствования должен быть непрерывным, и его необходимо измерять. Требование «непрерывности и измеримости» заявлено одним из основных результатов этой книги. Непрерывные целенаправленные измерения называются метриками. В связи с этим в данной главе приводится модель зрелости метрик операционной безопасности. В отличие от прочих моделей зрелости, связанных с аналитикой (да, их много), наша начинается и заканчивается прогностической аналитикой.
С этой главы мы начнем разбирать некоторые вопросы на уровнях руководства и реализации. Ричард Сирсен, один из авторов книги, хорошо разбирающийся в данной теме, здесь и далее будет обращаться к своим коллегам, используя термины и концепции, с которыми они должны быть уже знакомы. Дополнительные технические вопросы будут затронуты лишь выборочно для иллюстрации практических действий. Итак, мы рассмотрим следующие темы.
• Модель зрелости метрик операционной безопасности. Модель зрелости, представляющая собой матрицу типовых вопросов и источников данных.
• Анализ скудных данных (АСД). Самый первый этап метрик, здесь используются количественные методы для моделирования риска на основе ограниченных данных. В частности, этот этап можно использовать для обоснования новых инвестиций в безопасность. В конце главы приведен подробный пример АСД с использованием языка программирования R. Это дополнительный материал, который не только иллюстрирует метод АСД, но и демонстрирует возможность анализа без использования Excel.
• Функциональные метрики безопасности. Метрики, специфичные для конкретного объекта и основывающиеся на ранних инвестициях в безопасность. Большинство программ метрик безопасности останавливается на этом этапе зрелости.
• Витрины данных безопасности. Раздел посвящен измерениям в связанных с безопасностью областях, обладающих большими наборами данных. Эта тема рассматривается в следующей главе.
• Предписывающая аналитика безопасности. Краткий разбор новой для мира безопасности темы, представляющей собой смесь науки о принятии решений и науки о данных. Эта объемная тема достойна отдельной книги в будущем.
Введение: модель зрелости метрик операционной безопасности
Прогностическая аналитика, машинное обучение, наука о данных – все эти темы популярны. Существует множество моделей зрелости и схем построения аналитики. Попробуйте поискать в Google картинки по запросу «модели зрелости в аналитике», их там предостаточно. Наш подход (рис. 10.1) отличается от других.
Рис. 10.1. Модель зрелости аналитики безопасности
Для начала работы нам не требуются большие объемы данных или особые возможности. И, по сути, изученные ранее практические методы предстают на этом этапе во всей красе: они помогают определить типы вложений, которые следует сделать, чтобы довести программу до зрелого состояния. Поэтому нет нужды торопиться с инвестициями в средства обработки больших данных и инструменты науки о данных. Не поймите неправильно – мы всячески поддерживаем их использование, когда оно оправданно. Однако за блеском всех этих аналитических концепций и технологий кроется множество факторов, отвлекающих от принятия решений, которые помогли бы защититься от злоумышленников прямо сейчас. Поэтому мы придерживаемся точки зрения, что любые стоящие модели зрелости и схемы построения аналитики всегда начинаются с принятия решения.
Анализ скудных данных
N (данных) никогда не бывает достаточно, как только начинает казаться, что их «достаточно», у вас тут же возникает следующая проблема, для решения которой требуется больше данных. Примерно как с деньгами, которых всегда не хватает, но это уже совсем другая история.
Вот теперь можно применить прогностическую аналитику. То есть использовать продвинутые методы, хотя ваша программа безопасности еще не обязательно зрелая. Все модели, представленные в главах 8 и 9, идеально подходят в данном случае. Отсутствие возможности собрать большие массивы информации, касающейся безопасности, еще не означает, что нельзя корректировать свои суждения по мере получения новых данных. В сущности, единственными доступными вам данными вполне могут оказаться суждения экспертов о вероятных будущих убытках. Иначе говоря, проведение анализа со скудными данными – зрелая функция, но она не зависит от зрелости мер обеспечения безопасности.
С точки зрения аналитики АСД – единственный подход в условиях нехватки информации. Скорее всего, вы не вкладывали средства в новую программу безопасности. Вас вообще могли недавно нанять на должность руководителя отдела информационной безопасности и поручить инвестировать в программу обеспечения безопасности, создав ее с нуля. И чтобы определить, какими должны быть вложения, вы прибегнете к АСД. Однако, как только новые инвестиции (люди, процессы, технологии) будут привлечены, необходимо проводить измерения для определения эффективности вложений и постоянного улучшения их работы. Пример АСД с большим количеством технических подробностей представлен в разделе «Пример модели АСД: R-программирование» в конце главы.
Функциональные метрики безопасности
Сделав крупные вложения в новые возможности обеспечения безопасности предприятия, как узнать, что от них действительно есть толк? Функциональные метрики безопасности направлены на оптимизацию эффективности основных составляющих операционной безопасности, для чего устанавливаются ключевые показатели эффективности (КПЭ), связанные с операционным охватом, конфигурацией систем и снижением рисков в ключевых областях. Есть несколько книг по метрикам безопасности, посвященных данному этапу измерения безопасности. Одной из первых была книга Эндрю Джеквита Security Metrics2 («Метрики безопасности»), которая вывела эту важную тему на передний план. В книге много внимания уделено тому, что мы будем называть «метриками охвата и конфигурации». К сожалению, большинство компаний все еще не в полной мере реализуют этот уровень зрелости. Они вполне могут вкладывать десятки, если не сотни миллионов в персонал и технологии безопасности. Могут оптимизировать людские ресурсы, процессы и технологии определенных обособленных функций, но маловероятно, что все области безопасности анализируются с использованием изометрических подходов к измерениям.
Большинство организаций обеспечивают некоторые из перечисленных функций (не обязательно в таком порядке):
• защиту от вредоносного ПО;
• управление уязвимостями;
• тестирование на проникновение;
• безопасность приложений;
• сетевую безопасность;
• архитектуру безопасности;
• управление идентификацией и доступом;
• соответствие требованиям безопасности;
• предотвращение потери данных;
• реагирование на инциденты и сетевую криминалистику
и многие другие.
Для каждой функции может быть несколько корпоративных и автономных решений обеспечения безопасности. По сути, все организации в идеале должны иметь сложные метрики безопасности, связанные с каждой из их функций. Такие метрики делятся на две макрообласти.
1. Метрики охвата и конфигурации. Это метрики, связанные с операционной эффективностью с точки зрения глубины и широты вовлеченности организации. Измерения в метрике включают в себя временные ряды, связанные со скоростью развертывания и эффективностью конфигурации. Работает ли (активировано ли) решение в соответствии со спецификацией и есть ли у вас доказательства этого? Вы можете приобрести файрвол и установить его как положено, но если в его правилах задано значение «any: any» (то есть фактически отсутствие ограничений доступа), а вы об этом не знаете, скорее всего, эффекта не будет. Предусмотрено ли журналирование для ключевых приложений? Ведется ли оно в действительности? Если ведется, отправляются ли лог-файлы для анализа соответствующими средствами безопасности? Настроены ли оповещения для указанных средств безопасности и соотносятся ли они между собой? Каковы показатели ложноположительных и ложноотрицательных результатов и есть ли у вас метрики для снижения информационного шума и выделения фактических сведений? Измеряете ли вы также сопутствующий рабочий процесс по преодолению последствий данных событий?
2. Метрики смягчения последствий. Это показатели, связанные со скоростью появления и ликвидации риска для организации. Например, метрика может быть такой: «Для систем с выходом в интернет удаленно эксплуатируемые уязвимости необходимо устранять в течение одного рабочего дня, а эффективный встроенный мониторинг или смягчение последствий должны быть запущены в течение 1 часа».
Витрины данных безопасности
Примечание: руководство по проектированию витрины данных безопасности представлено в главе 11. В этом разделе лишь вводится понятие в контексте модели зрелости.
Для некоторых аналитиков словосочетание «витрина данных» – тревожный сигнал. Оно вызывает в памяти образы раздутых хранилищ данных и сложных ETL-систем (ETL: extraction, transformation, load – извлечение, преобразование, загрузка). Однако, говоря «витрина данных», мы дистанцируемся от любой конкретной реализации. Если формулировать идеальное определение, мы бы сказали, что это «предметно-специфическое, неизменяемое, гибкое, сильно распараллеленное и предоставляющее быстрый доступ хранилище данных, которое легко соединяется с другими предметными хранилищами данных». Непонятная формулировка? Перевод: сверхбыстрое во всех своих операциях, масштабируется с увеличением объема данных, и его необходимость легко аргументировать конечным пользователям. Еще можно добавить «находящееся в облаке». И то лишь потому, что так можно не возиться с внедрением и сосредоточиться на управлении рисками безопасности. Реальность такова, что большинство читателей этой книги могут иметь свободный доступ к традиционным реляционным системам управления базами данных (РСУБД), даже со своих ноутбуков.
Витрины данных безопасности отвечают на вопросы, связанные с кросс-программной продуктивностью. Эффективно ли взаимодействие людей, процессов и технологий для снижения риска в нескольких областях безопасности? (Примечание: под системой безопасности обычно понимается объединение людей, процессов и технологий.) Или, если говорить конкретнее, с течением времени способность вашей системы к уменьшению риска повышается или снижается? В качестве примера здесь можно привести вопросы вроде «У конечных пользователей, эксплуатирующих системы со средствами контроля безопасности XYZ, меньше шансов подвергнуться взлому? Среди решений, предлагаемых поставщиками средств безопасности, или их сочетаний есть ли те, что эффективнее остальных? Нет ли среди вложений бесполезных излишеств?». Скажем, в случае эффективности мер безопасности для конечных точек подобные типы вопросов могут опираться на данные лог-файлов, поступающих из таких источников, как:
• инструментарий Microsoft Enhanced Mitigation Experience Toolkit (EMET);
• белые списки приложений;
• система предотвращения вторжений на хост;
• мониторинг целостности файлов;
• конфигурация системы (контрольные показатели Центра интернет-безопасности (CIS) и т. д.);
• настройки безопасности и конфиденциальности браузера;
• управление уязвимостями;
• Endpoint reputation;
• антивирус
и т. п.
Могут быть и другие вопросы, например: «Как долго остаточный риск, который могут использовать злоумышленники, находится в конечных точках, до того как его обнаружат и задача по его устранению станет приоритетной? Достаточно ли быстрая наша „система“? Какой должна быть скорость и сколько нужно потратить, чтобы ее достичь?»
Витрины данных идеально подходят для ответа на вопросы о том, сколько времени может просуществовать скрытая вредоносная активность до момента обнаружения. Решения SIEM (security information and event management – управление событиями и информацией о безопасности) тут не помогут, хотя их можно использовать как источник сведений для витрин данных. В конце концов, средства поставщиков систем безопасности обнаружат злоумышленников в вашей сети, но времени может пройти немало. Возможно, потребуется несколько минут или месяцев, а то и лет. Например, объекты инвестиций, определяющие хорошую или плохую репутацию внешних систем, обновляются по ходу дела. Некоторые из этих систем могут использоваться злоумышленниками в качестве командно-контрольных серверов для управления зараженными системами в вашей сети. Такие серверы могут просуществовать несколько месяцев, прежде чем поставщик услуг безопасности подтвердит их наличие. Антивирусы обновляются регулярно по мере появления новых вредоносных программ. Однако вредоносные программы могут месяцами находиться в конечных точках, пока не выйдет обнаруживающее их обновление. Системы управления уязвимостями обновляются по мере обнаружения новых уязвимостей нулевого дня или каких-то других. Уязвимости могут существовать в течение многих лет, прежде чем о них узнают поставщики ПО или систем безопасности. Все это время злоумышленники могут использовать эти уязвимости без вашего ведома.
Тема измерения остаточного риска в сфере кибербезопасности – очень скользкая. В любой момент времени вы подвержены опасности, а решения поставщиков услуг безопасности, по сути, всегда запаздывают. Любой профессионал в области безопасности скажет вам, что это очевидный факт. А если он так очевиден, то почему остаточный риск не измеряют, чтобы попытаться исправить ситуацию? Он легко измерим и должен быть в приоритете. Измерение степени подверженности постороннему воздействию и инвестирование в ее снижение, так чтобы добиться наилучшей окупаемости инвестиций, – ключевая практика в управлении рисками кибербезопасности, осуществлению которой способствуют витрины данных безопасности, в сочетании со всем тем, что вы узнали из предыдущих глав. В главе 11 будет рассмотрен КПЭ под названием «анализ выживаемости», учитывающий необходимость измерения срока существования остаточного риска. И откроем маленький секрет: если не измерять остаточную степень незащищенности, то, скорее всего, ситуация будет только ухудшаться. Если собираетесь бороться за правое дело, нужно уметь задавать вопросы, затрагивающие разные области безопасности. Поймите, что под атаки злоумышленников попадают они все и, чтобы справиться с этой реальностью, аналитикам следует преодолеть функциональную обособленность.
Предписывающая аналитика
Как отмечалось ранее, предписывающая аналитика – тема для отдельной объемной книги. Здесь мы хотим лишь слегка ее затронуть применительно к индустрии безопасности. Прежде всего давайте определим место предписывающей аналитики среди трех категорий аналитики.
• Описательная аналитика. По большей части аналитика описательна. Это просто сводные показатели, такие как суммы и средние значения в определенных вызывающих интерес группах данных, например ежемесячное усиление и ослабевание отдельных видов риска. Такова стандартная описательная аналитика. Стандартная оперативная аналитическая обработка данных (Standard Online Analytical Processing, OLAP) хорошо сочетается с описательной аналитикой. Однако, как уже говорилось, бизнес-аналитика с позиций OLAP-технологии не получила достаточного распространения в сфере безопасности. Функциональный подход и витрины данных безопасности в основном состоят из описательной аналитики, за исключением случаев, когда требуется использовать эти данные для обновления суждений в аналитических моделях на основе скудных данных.
• Прогностическая аналитика. Прогностическая аналитика подразумевает прогнозирование будущего, но, строго говоря, этого не делает. Данные за прошлые периоды используются для составления прогноза относительно возможного будущего результата. Большинство программ метрик безопасности не достигают этого уровня. Некоторые специалисты по безопасности и поставщики услуг безопасности могут возразить: «А как же машинное обучение? Мы этим занимаемся!» Здесь стоит сделать небольшое отступление на тему сравнения машинного обучения, также известного как наука о данных, с наукой о принятии решений.
Применение методов машинного обучения стоит несколько в стороне от анализа решений. Действительно, поиск закономерностей с помощью машинного обучения становится все более значимой практикой борьбы со злоумышленниками. Как уже говорилось, поставщики услуг безопасности не справляются с ранним обнаружением новых угроз, а вот машинное обучение кажется здесь очень многообещающим. Однако вероятностные сигналы, применяемые к данным в реальном времени, потенциально могут стать дополнительным шумом, мешающим расстановке приоритетов. «Расставить приоритеты» – значит определить следующее действие в разгар боя. Вот что на самом деле означает «управление» (M, management) в SIEM – расстановку приоритетов в дальнейших действиях. И в этом плане анализ решений также мог бы здесь отлично сработать (к сожалению, рынок SIEM не признает анализа решений, придерживаясь вместо этого сомнительных порядковых подходов при определении приоритетности действий по реагированию на инциденты).
• Предписывающая аналитика. Если коротко, предписывающая аналитика задействует множество моделей как из анализа решений, так и из области науки о данных и предоставляет наиболее рациональные рекомендации для принятия решений. В контексте больших данных и потоковой аналитики такие решения могут приниматься в режиме реального времени, а иногда и без усилий с вашей стороны, что сближает предписывающую аналитику с искусственным интеллектом.
Проще говоря, согласно нашей модели, следует начать с анализа решений и придерживаться его на протяжении всего времени накопления эмпирических данных. На предписывающем уровне выходные данные модели науки о данных становятся входными данными для моделей анализа решений. Все эти модели работают вместе, предлагая, а в некоторых случаях динамически принимая решения. Решения могут быть обработаны и, следовательно, снова введены в модель. Примером использования предписывающей аналитики может служить так называемая «погоня за кроликами». Как уже говорилось, большая часть технологий операционной безопасности связана с повторением по кругу процессов обнаружения, блокировки и удаления. В общем смысле именно так работают антивирусное ПО и различные виды встроенной защиты. Только если происходит нарушение или какой-то прорыв обороны, средства защиты объединяются. А что насчет серой зоны, которая предшествует нарушению и/или может быть признаком продолжающегося нарушения? То есть нет фактических доказательств текущего нарушения, имеются лишь доказательства, что определенные активы были скомпрометированы, и в данный момент они уже восстановлены.
Например, рассмотрим вредоносное ПО, которое было успешно удалено, но перед удалением службы внутренней защиты блокировали его связь с командно-контрольным сервером. Вы собираете дополнительные доказательства того, что взломанные системы пытались отправлять сообщения на заблокированные сейчас командно-контрольные серверы. Процесс длился месяцами. Что делать? Вредоносное ПО удалено, но вдруг осталась пока не обнаруженная утечка данных? Или, возможно, была утечка, которая уже закончилась, но ее не заметили? Иначе говоря, стоит ли начинать криминалистическую экспертизу на предмет наличия еще одной, а то и нескольких более крупных вредоносных «кампаний», выкачивающих данные или занимавшихся этим ранее?
В идеальном мире с неограниченными ресурсами ответ был бы «Да!», но реальность такова, что ваша группа реагирования на инциденты, как правило, на 100 % занята расследованием подтвержденных инцидентов и им не до «вероятных» взломов. Возникает дилемма, ведь если не отреагировать на «возможные взломы», они грозят перерасти в полномасштабные, долгосрочные утечки данных. На самом деле, скорее всего, вы никогда не столкнетесь с такой дилеммой, если научитесь расставлять приоритеты среди имеющихся данных. Мы предполагаем, что подходы, аналогичные представленным в главе 9, можно интегрировать в существующие системы обнаружения нарушений почти в режиме реального времени. Например, модель линзы позволяет проводить расчеты быстро, благодаря тому что не требует массивных вероятностных таблиц узлов. К тому же она целиком и полностью байесовская и может работать как с эмпирическими доказательствами, получаемыми непосредственно от детерминированных и недетерминированных (наука о данных) систем безопасности, так и с калиброванными суждениями экспертов в области безопасности. Поскольку модель линзы – байесовская, то, основываясь на результатах решений самой модели, можно постоянно обновлять представления о различных типах сценариев и рекомендации, когда следует проводить дальнейшее расследование определенных событий из «серой зоны». Такой подход начинает все сильнее напоминать применение искусственного интеллекта в сфере кибербезопасности. Опять же это объемная тема для следующей книги, и нашей целью было лишь немного пролить свет на будущее направление.
Поговорим еще немного об АСД. В данном примере нами будет использоваться язык программирования R, но с таким же успехом можно работать с помощью Excel, Python и т. п. Данный раздел не является исчерпывающей инструкцией по работе с языком программирования R. Мы поясним код ровно настолько, насколько это поможет объяснить идеи анализа. Наша цель – интуитивное понимание программы. Потребность в интуиции нельзя переоценить. Интуиция подскажет творческое решение проблем. В связи с этим мы считаем, что Excel и скриптовые языки программирования – отличные варианты, позволяющие новичкам в анализе рисков быстро развить интуицию для аналитики. В сущности, если какие-либо понятия из предыдущих глав все еще кажутся вам непонятными, поработайте дополнительно с инструментами Excel. Изображение и программа могут стоить нескольких тысяч слов. То же самое и здесь: установите R и попробуйте с ним поработать, тогда все покажется гораздо более логичным.
Чтобы узнать больше о языке программирования R, мы рекомендуем воспользоваться многочисленными книгами и бесчисленными учебными пособиями в интернете. Мы будем работать с библиотекой R под названием LearnBayes, которая сама по себе является учебным пособием. У автора этого модуля, Джима Альберта, есть замечательная книга3 и несколько учебных пособий, доступных онлайн, к которым можно обращаться в случае возникновения вопросов, как это делаем мы. Если у вас нет R, можно загрузить его для нужной платформы по ссылке: https://cran.rstudio.com/index.html. Мы также рекомендуем среду разработки RStudio, которая значительно облегчит написание кода на R: https://www.rstudio.com/products/rstudio/download/.
Скачав RStudio, вам нужно будет ее запустить, введите для этого в командной строке:
install.packages(«LearnBayes»).
Вот факты для нашего сценария.
• Теперь вы – часть команды, которой поручено провести аудит с целью оценки приобретения стоимостью несколько миллиардов долларов.
• Компания, о которой идет речь, имеет значительное глобальное облачное присутствие.
• Вам сообщили, что у компании есть несколько сотен облачных приложений, обслуживающих различные критически важные отрасли с миллионами пользователей.
• Вам дали меньше недели, чтобы, как говорит ваш генеральный директор, «определить, насколько все плохо, есть ли какие-либо подводные камни и, кроме того, насколько вырастет наш технический долг с точки зрения безопасности».
• Ваша организация – одна из нескольких, заинтересованных в сделке с данной компанией. Это что-то вроде срочной распродажи в том смысле, что правление компании-продавца хочет быстрее со всем покончить.
• Вы не сможете получить всю желаемую информацию. Фактически вам даже толком не дадут провести формальную оценку.
Поскольку вы хотите, чтобы ваша работа была состоятельна с точки зрения технической оценки, вы решили сосредоточиться на некоторых аспектах безопасности из Матрицы мер безопасности для облаков от Cloud Security Alliances. Она соотносится со всеми крупными системами контроля вроде ISO, NIST и прочих. Вы сокращаете список до пяти обязательных макроэлементов. Отсутствие любого из этих средств контроля может привести к затратам в несколько сотен тысяч долларов на исправление одного приложения или даже больше.
После проведения небольшого исследования вы на 50 % уверены, что на самом деле истинная доля средств контроля безопасности менее 40 %. Непонятно? Все потому, что мы пытаемся объяснить «картину в пропорции». Лучше всего представлять эту информацию в виде графика. У вас есть колоколообразная кривая, наивысшая точка которой немного смещена влево от центра – отметки 40 % на оси x. Вы также на 90 % уверены в том, что истинное значение (процент действующих средств контроля безопасности) находится на графике ниже отметки 60 %, что сдвигает кривую на графике еще немного левее. Если бы вы были на 90 % уверены, что количество действующих средств контроля безопасности менее 50 %, исходная кривая была бы выше и ýже, т. е. плотнее вокруг отметки 40 %.
Предположим, вы проводите первый аудит/опрос по поводу 10 приложений и обнаруживаете, что в 3 из 10 приложений установлены базовые средства контроля безопасности. И теперь вы вводите свои «априорные суждения» о компании, добавив к ним недавно полученные данные, в R:
> library(LearnBayes)
>
> beta.par <– beta.select(list(p=0.5, x=0.40), list(p=0.90, x=.60))
> triplot(beta.par, c(3,7))
Как указано выше, согласно априорным суждениям, вы считаете, что количество действующих средств контроля безопасности для большинства облачных приложений, о которых идет речь, составляет около 40 %. По мере получения дополнительных данных ваши соображения начинают «обретать форму». Это отражено в апостериорных данных, под которыми понимаются данные, полученные после проведения анализа. Если использовать апостериорные данные для нового анализа, то в нем они станут априорными. Данные, с которых вы начинаете прогноз, являются априорными для получения выходных данных, которые будут апостериорными. Разброс ваших суждений уменьшается, диапазоны сужаются и, следовательно, становятся более определенными. Конечно, это только после 10 опросов.
Обратите внимание на график «Вероятность». Эта функция описывает степень вероятности того, что вы сможете увидеть желаемые данные с учетом вашей модели (гипотезы). Формально это было бы записано так: P(Данные | Гипотеза). В нашем случае было три успеха и семь неудач. Если модель последовательна, то вероятность, что она отражает наши данные, должна быть относительно высокой.
Рис. 10.2. Трилинейная диаграмма Байеса, бета (4,31, 6,3) априорные данные, у (успех, попадания) = 3, н (неудачи, промахи) = 7
В приведенном выше коде функция beta.select используется для создания (выбора) двух значений из входных данных априорной вероятности. У этих двух значений причудливые названия: a и b, или альфа и бета. Их также называют параметрами формы. Они формируют кривую, или распределение, показанное на рис. 10.2. Представьте, что распределение – это глина, а параметры – руки, которые придают глине форму. Как написано в главе 9, формальное название этого конкретного типа распределения (формы) – бета-распределение. По мере увеличения aи b отображение суждений, представленных бета-распределением, становится выше и ýже. Это означает, что ваши суждения о чем-то неопределенном становятся более определенными (плотными). В данном случае неопределенностью является состояние средств контроля безопасности примерно 200 облачных приложений. Вы можете заметить, что два списка отражают убеждения, которые были у руководителя отдела информационной безопасности: beta.select(list(p=0.5, x=0.40), list(p=0.90, x=.60)). Эти вводные данные преобразуются с помощью функции beta.select в значения a и b и сохраняются в переменной beta.par. Можно вывести значения на экран, набрав следующее:
> beta.par
[1] 4.31 6.30
Вы занимаетесь только вашими суждениями и новыми данными. Значения альфа и бета работают в фоновом режиме, формируя бета-распределение по мере получения большего количества данных. А затем используется функция triplot, чтобы объединить новую информацию (3,7; 3 успеха и 7 неудач) с априорными суждениями и создать новое апостериорное суждение:
> triplot(beta.par, c(3,7))
Предположим, вы проводите 35 полных аудитов, и только пять облачных приложений удовлетворяют самым основным требованиям «глубокой эшелонированной защиты», предъявляемым к средствам контроля безопасности. Больше 200 приложений не подвергались аудиту. Теперь скорректируйте модель, добавив новые данные (рис. 10.3).
> triplot(beta.par, c(5,30))
Рис. 10.3. Трилинейная диаграмма Байеса, бета (4,31, 6,3) априорные данные, у = 5, н = 30
Вам все еще многое неизвестно о реальном состоянии средств обеспечения облачной безопасности компании, но, кажется, ситуация даже хуже, чем вы предполагали. Поэтому, чтобы было проще сделать выводы, вы решаете смоделировать большое количество результатов, основанных на новых суждениях (апостериорных). Это такой завуалированный способ сказать: «У меня нет времени проводить аудит всех приложений. Что если использовать известные мне данные в качестве вводных для симуляции?
Симуляция смоделирует 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).