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

Когда совершенствуешься в каком-либо деле, хорошо иметь представление о том, на каком этапе находишься и куда стоит двигаться дальше. Процесс совершенствования должен быть непрерывным, и его необходимо измерять. Требование «непрерывности и измеримости» заявлено одним из основных результатов этой книги. Непрерывные целенаправленные измерения называются метриками. В связи с этим в данной главе приводится модель зрелости метрик операционной безопасности. В отличие от прочих моделей зрелости, связанных с аналитикой (да, их много), наша начинается и заканчивается прогностической аналитикой.

С этой главы мы начнем разбирать некоторые вопросы на уровнях руководства и реализации. Ричард Сирсен, один из авторов книги, хорошо разбирающийся в данной теме, здесь и далее будет обращаться к своим коллегам, используя термины и концепции, с которыми они должны быть уже знакомы. Дополнительные технические вопросы будут затронуты лишь выборочно для иллюстрации практических действий. Итак, мы рассмотрим следующие темы.

• Модель зрелости метрик операционной безопасности. Модель зрелости, представляющая собой матрицу типовых вопросов и источников данных.

• Анализ скудных данных (АСД). Самый первый этап метрик, здесь используются количественные методы для моделирования риска на основе ограниченных данных. В частности, этот этап можно использовать для обоснования новых инвестиций в безопасность. В конце главы приведен подробный пример АСД с использованием языка программирования R. Это дополнительный материал, который не только иллюстрирует метод АСД, но и демонстрирует возможность анализа без использования Excel.

• Функциональные метрики безопасности. Метрики, специфичные для конкретного объекта и основывающиеся на ранних инвестициях в безопасность. Большинство программ метрик безопасности останавливается на этом этапе зрелости.

• Витрины данных безопасности. Раздел посвящен измерениям в связанных с безопасностью областях, обладающих большими наборами данных. Эта тема рассматривается в следующей главе.

• Предписывающая аналитика безопасности. Краткий разбор новой для мира безопасности темы, представляющей собой смесь науки о принятии решений и науки о данных. Эта объемная тема достойна отдельной книги в будущем.

Введение: модель зрелости метрик операционной безопасности

Прогностическая аналитика, машинное обучение, наука о данных – все эти темы популярны. Существует множество моделей зрелости и схем построения аналитики. Попробуйте поискать в Google картинки по запросу «модели зрелости в аналитике», их там предостаточно. Наш подход (рис. 10.1) отличается от других.

Рис. 10.1. Модель зрелости аналитики безопасности

Для начала работы нам не требуются большие объемы данных или особые возможности. И, по сути, изученные ранее практические методы предстают на этом этапе во всей красе: они помогают определить типы вложений, которые следует сделать, чтобы довести программу до зрелого состояния. Поэтому нет нужды торопиться с инвестициями в средства обработки больших данных и инструменты науки о данных. Не поймите неправильно – мы всячески поддерживаем их использование, когда оно оправданно. Однако за блеском всех этих аналитических концепций и технологий кроется множество факторов, отвлекающих от принятия решений, которые помогли бы защититься от злоумышленников прямо сейчас. Поэтому мы придерживаемся точки зрения, что любые стоящие модели зрелости и схемы построения аналитики всегда начинаются с принятия решения.

Анализ скудных данных

Вот теперь можно применить прогностическую аналитику. То есть использовать продвинутые методы, хотя ваша программа безопасности еще не обязательно зрелая. Все модели, представленные в главах 8 и 9, идеально подходят в данном случае. Отсутствие возможности собрать большие массивы информации, касающейся безопасности, еще не означает, что нельзя корректировать свои суждения по мере получения новых данных. В сущности, единственными доступными вам данными вполне могут оказаться суждения экспертов о вероятных будущих убытках. Иначе говоря, проведение анализа со скудными данными – зрелая функция, но она не зависит от зрелости мер обеспечения безопасности.

С точки зрения аналитики АСД – единственный подход в условиях нехватки информации. Скорее всего, вы не вкладывали средства в новую программу безопасности. Вас вообще могли недавно нанять на должность руководителя отдела информационной безопасности и поручить инвестировать в программу обеспечения безопасности, создав ее с нуля. И чтобы определить, какими должны быть вложения, вы прибегнете к АСД. Однако, как только новые инвестиции (люди, процессы, технологии) будут привлечены, необходимо проводить измерения для определения эффективности вложений и постоянного улучшения их работы. Пример АСД с большим количеством технических подробностей представлен в разделе «Пример модели АСД: R-программирование» в конце главы.

Функциональные метрики безопасности

Сделав крупные вложения в новые возможности обеспечения безопасности предприятия, как узнать, что от них действительно есть толк? Функциональные метрики безопасности направлены на оптимизацию эффективности основных составляющих операционной безопасности, для чего устанавливаются ключевые показатели эффективности (КПЭ), связанные с операционным охватом, конфигурацией систем и снижением рисков в ключевых областях. Есть несколько книг по метрикам безопасности, посвященных данному этапу измерения безопасности. Одной из первых была книга Эндрю Джеквита Security Metrics² («Метрики безопасности»), которая вывела эту важную тему на передний план. В книге много внимания уделено тому, что мы будем называть «метриками охвата и конфигурации». К сожалению, большинство компаний все еще не в полной мере реализуют этот уровень зрелости. Они вполне могут вкладывать десятки, если не сотни миллионов в персонал и технологии безопасности. Могут оптимизировать людские ресурсы, процессы и технологии определенных обособленных функций, но маловероятно, что все области безопасности анализируются с использованием изометрических подходов к измерениям.

Большинство организаций обеспечивают некоторые из перечисленных функций (не обязательно в таком порядке):

• защиту от вредоносного ПО;

• управление уязвимостями;

• тестирование на проникновение;

• безопасность приложений;

• сетевую безопасность;

• архитектуру безопасности;

• управление идентификацией и доступом;

• соответствие требованиям безопасности;

• предотвращение потери данных;

• реагирование на инциденты и сетевую криминалистику

и многие другие.

Для каждой функции может быть несколько корпоративных и автономных решений обеспечения безопасности. По сути, все организации в идеале должны иметь сложные метрики безопасности, связанные с каждой из их функций. Такие метрики делятся на две макрообласти.

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, которая сама по себе является учебным пособием. У автора этого модуля, Джима Альберта, есть замечательная книга³ и несколько учебных пособий, доступных онлайн, к которым можно обращаться в случае возникновения вопросов, как это делаем мы. Если у вас нет R, можно загрузить его для нужной платформы по ссылке: https://cran.rstudio.com/index.html. Мы также рекомендуем среду разработки RStudio, которая значительно облегчит написание кода на R: https://www.rstudio.com/products/rstudio/download/.

Скачав RStudio, вам нужно будет ее запустить, введите для этого в командной строке:

Вот факты для нашего сценария.

• Теперь вы – часть команды, которой поручено провести аудит с целью оценки приобретения стоимостью несколько миллиардов долларов.

• Компания, о которой идет речь, имеет значительное глобальное облачное присутствие.

• Вам сообщили, что у компании есть несколько сотен облачных приложений, обслуживающих различные критически важные отрасли с миллионами пользователей.

• Вам дали меньше недели, чтобы, как говорит ваш генеральный директор, «определить, насколько все плохо, есть ли какие-либо подводные камни и, кроме того, насколько вырастет наш технический долг с точки зрения безопасности».

• Ваша организация – одна из нескольких, заинтересованных в сделке с данной компанией. Это что-то вроде срочной распродажи в том смысле, что правление компании-продавца хочет быстрее со всем покончить.

• Вы не сможете получить всю желаемую информацию. Фактически вам даже толком не дадут провести формальную оценку.

Поскольку вы хотите, чтобы ваша работа была состоятельна с точки зрения технической оценки, вы решили сосредоточиться на некоторых аспектах безопасности из Матрицы мер безопасности для облаков от Cloud Security Alliances. Она соотносится со всеми крупными системами контроля вроде ISO, NIST и прочих. Вы сокращаете список до пяти обязательных макроэлементов. Отсутствие любого из этих средств контроля может привести к затратам в несколько сотен тысяч долларов на исправление одного приложения или даже больше.

После проведения небольшого исследования вы на 50 % уверены, что на самом деле истинная доля средств контроля безопасности менее 40 %. Непонятно? Все потому, что мы пытаемся объяснить «картину в пропорции». Лучше всего представлять эту информацию в виде графика. У вас есть колоколообразная кривая, наивысшая точка которой немного смещена влево от центра – отметки 40 % на оси x. Вы также на 90 % уверены в том, что истинное значение (процент действующих средств контроля безопасности) находится на графике ниже отметки 60 %, что сдвигает кривую на графике еще немного левее. Если бы вы были на 90 % уверены, что количество действующих средств контроля безопасности менее 50 %, исходная кривая была бы выше и ýже, т. е. плотнее вокруг отметки 40 %.

Предположим, вы проводите первый аудит/опрос по поводу 10 приложений и обнаруживаете, что в 3 из 10 приложений установлены базовые средства контроля безопасности. И теперь вы вводите свои «априорные суждения» о компании, добавив к ним недавно полученные данные, в R:

Как указано выше, согласно априорным суждениям, вы считаете, что количество действующих средств контроля безопасности для большинства облачных приложений, о которых идет речь, составляет около 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. Можно вывести значения на экран, набрав следующее:

Вы занимаетесь только вашими суждениями и новыми данными. Значения альфа и бета работают в фоновом режиме, формируя бета-распределение по мере получения большего количества данных. А затем используется функция triplot, чтобы объединить новую информацию (3,7; 3 успеха и 7 неудач) с априорными суждениями и создать новое апостериорное суждение:

Предположим, вы проводите 35 полных аудитов, и только пять облачных приложений удовлетворяют самым основным требованиям «глубокой эшелонированной защиты», предъявляемым к средствам контроля безопасности. Больше 200 приложений не подвергались аудиту. Теперь скорректируйте модель, добавив новые данные (рис. 10.3).

Рис. 10.3. Трилинейная диаграмма Байеса, бета (4,31, 6,3) априорные данные, у = 5, н = 30

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

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

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

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

Как видно из модели, можно быть на 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).

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

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

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

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

Задача данной главы – дать базовое, интуитивно понятное объяснение одного из элементов бизнес-аналитики: размерного моделирования.

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

Рис. 11.1 – это схема, что используется для размерного моделирования в большинстве случаев, ее обычно называют «кубом» трех ключевых измерений: времени, ценности и риска. Такую форму принимают почти все метрики операционной безопасности, и фактически единственное, что меняется в зависимости от области, это конкретный изучаемый риск. Время и ценность оказываются согласованной соединительной тканью, позволяющей измерять (т. е. прорабатывать) все области риска. Помните, что это лишь краткий обзор размерного моделирования. Нам хотелось бы надеяться, что размерные подходы к метрикам безопасности со временем будут развиваться. Сейчас, когда идет рост больших данных и соответствующих аналитических приложений, самое подходящее время.

Рис. 11.1. Стандартная витрина данных безопасности

Решение проблем, связанных с БА

При упоминании БА многие читатели наверняка представляют себе раздутые хранилища данных со сложными ETL-системами (извлечение, преобразование и загрузка). И действительно, для осуществления процессов ETL и даже визуализации требуется немало времени. Причина этой проблемы в сложности инфраструктуры нижележащей реляционной базы данных, а также особенностях формирования результатов анализа. В части инфраструктуры проблема более или менее решаема: многие облачные провайдеры предлагают средства для работы с большими данными. Например, у таких компаний, как Amazon, Google и Microsoft, есть зрелые продукты для масштабируемых облачных баз данных. Даже редактор Excel явно стал мощнее, так как способен увеличивать объем до миллиардов строк записей с помощью надстройки PowerPivot.

Если не хочется зависеть от какого-то одного поставщика, воспользуйтесь решениями с открытым исходным кодом, скажем, Apache Drill предоставляет унифицированный интерфейс на языке SQL (язык структурированных запросов) для большинства хранилищ данных, в том числе баз данных NoSQL, различных типов файлов (CSV, JSON, XML и т. д.), а также коннекторы Open Database Connectivity для устаревших баз данных (включая Excel). Идея заключается в том, чтобы полностью убрать для конечных пользователей аналитические барьеры, вызванные сложностью ETL-систем. Подобный процесс наблюдался более десяти лет назад в области визуализации данных. Инструменты визуализации значительно ослабили барьер, мешавший конечным пользователям проводить анализ. Но для этого, безусловно, должен иметься правильно сформированный и понятный источник данных. К сожалению, последние достижения в области создания баз данных, такие как Hadoop и NoSQL-системы, не смогли значительно продвинуться в решении этой проблемы. Собственно говоря, сложность доступа к данным только возросла. Но постепенно тот же самый «беспроблемный» подход, применявшийся в визуализации, реализуется и в области доступа к данным. В общем, технические барьеры, связанные с размером, скоростью и интерфейсом, полностью стираются. Что остается после решения технических вопросов? Логическое формулирование проблем анализа и выбор правильных подходов для их решения.

В отношении аналитического подхода также существуют свои предубеждения. Возможно, вам встречалось такое: «БА – это все равно, что пытаться вести бизнес вперед, глядя в зеркало заднего вида». Еще можно услышать, что «Бизнес-аналитика мертва!». Но это все равно, что сказать «Описательная аналитика мертва!» или «Изучение явлений с помощью данных за прошлые периоды мертво!». Что мертво или должно быть мертвым, так это бестолковые, трудоемкие подходы к аналитике, не имеющие стратегической ценности. Те, кто делает подобные заявления, просто подвержены заблуждению «обогнать медведя», или Еxsupero Ursus, упоминавшемуся в главе 5. Разумеется, вся прогностическая аналитика опирается на события, произошедшие в прошлом, что позволяет прогнозировать будущее! Проще говоря, когда дело доходит до наблюдаемых фактов, составляющих прогностическую модель, всегда существует некоторая задержка. Мы даже видим решения потоковой аналитики, где создаются микрокубы (мини-витрины данных) в памяти. Это волнующее время для бизнес-аналитики!

Теперь, когда вроде бы разрушены все предрассудки, связанные с противопоставлением БА, больших данных, NoSQL и прогностической аналитики, можно перейти к сути данной главы – определению эффективности взаимодействия вложений в безопасность с помощью размерного моделирования.

Только факты. Что такое размерное моделирование и зачем оно мне нужно?

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

Размерное моделирование представляет собой логический процесс проектирования с целью получения витрин данных. Оно имеет дело с двумя макрообъектами: фактами и измерениями. Совокупность измерений, окружающая список фактов, – это и есть витрина данных. На рис. 11.2 показана простая логическая витрина данных для уязвимостей. Обратите внимание, что она построена по схеме, представленной на рис. 11.1. Уязвимость в данном случае соответствует конкретному измерению риска. Активы – измерению ценности, при этом под ценностью понимается то, что следует защищать. И остается измерение даты или времени, присутствующее почти во всех моделях.

В центре размерных таблиц находится так называемая таблица фактов, которая содержит указатели на таблицы измерений и может насчитывать миллионы или даже миллиарды строк. Если ваше измерение активов составляет сотни тысяч, а то и миллионы строк (одному из авторов доводилось моделировать подобный вариант), то в таблице фактов их точно будут миллиарды. Здесь чистая математика: на один актив может приходиться N уязвимостей, существующих в определенный момент времени. Также обратите внимание, что прозвучало слово «логический». Это напоминание о том, что не обязательно создавать физические объекты, такие как таблицы измерений и фактов. При современных подходах, когда делаются запросы к различным источникам данных, все это можно виртуализировать в один простой объект данных в памяти. Так что не позволяйте различным рисункам и схемам запутать вас, они нужны лишь для понимания и удобства.

Рис. 11.2. Витрина уязвимости

Совпадающие или общие измерения позволяют соединять витрины данных и задавать новые интересные вопросы. Вероятно, самым распространенным совпадающим измерением является «дата/время». На втором месте, по крайней мере в безопасности, будет «актив». Активы можно разложить на различные элементы: портфель, приложение, продукт, сервер, виртуальный сервер, контейнер, микросервис, данные и т. д. Актив – это ценность, которая защищена средствами контроля безопасности, подвергается вредоносным атакам и используется по назначению авторизованными пользователями. Следовательно, вам, скорее всего, понадобятся витрины данных, связанные с состоянием уязвимостей, конфигурациями и смягчением последствий. У всех этих витрин данных может быть одна общая концепция актива. Такое «совместное использование» в разных областях безопасности позволяет задавать вопросы как по горизонтали, так и по вертикали. Или, как мы любим говорить в мире БА, совпадающие измерения позволяют осуществлять кросс-детализацию.

Чтобы понять возможности применения кросс-детализации, представьте, что у вас есть метрика под названием «цельнометаллическая оболочка». Цельнометаллическая оболочка, как показано на рис. 11.3, представляет собой ряд требований макрозащиты для определенных классов активов. В частности, у вас есть КПЭ в виде наименьшей привилегии (конфигурации), состояния исправлений, скорости устранения последствий в конечных точках и блокирующие средства контроля в сети. Все они на самом деле являются метриками охвата контроля в отношении некоторой концепции ценности (актива). Приведенная ниже простая структура послужит пояснением. Вы можете определить, в каких областях есть совершенно незамеченный и, вероятно, эксплуатируемый остаточный риск, и сравнить его с тем, который контролируется с помощью конфигурации или смягчения последствий.

Рис. 11.3. Расширенная витрина данных с совпадающими измерениями

В этой модели не хватает понятия «угрозы», определяющего, насколько хорошо ваша макроконцепция защиты ценности (цельнометаллическая оболочка) противостоит определенным векторам угрозы. На рис. 11.4 представлен расширенный вариант модели, учитывающий этот аспект. В данном случае витрина данных анализа вредоносного ПО интегрируется с соответствующими витринами данных. Это просто, поскольку витрина вредоносного ПО совпадает с ними по активу и дате.

Такая витрина данных может ответить на сотни и даже тысячи вопросов о ценности различных форм защиты от вредоносного программного обеспечения. Например, в измерении смягчения последствий можно задавать вопросы о том, что более эффективно в борьбе с адресным фишингом: локальные файрволы или встроенные в систему средства защиты.

Рис. 11.4. Измерение вредоносного ПО

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

Любопытно, что в размерном моделировании факты в таблицах фактов также называют мерами, поскольку они измеряют процесс на атомарном уровне. «Атомарный» означает, что измеряемое событие нельзя дальше разложить на составляющие. Типичным фактом в бизнесе может быть продажа продукта, скажем банки фасоли. Мерой в данном случае будет цена продажи. Возможно, вы захотите узнать, сколько определенного товара продали в конкретный момент времени в конкретном месте. При этом можно еще проследить за показателями продаж этого товара квартал за кварталом. Или вы захотите сравнить прибыльность двух конкретных продуктов с учетом географических рынков и/или размещения в магазинах, и т. д. Это все традиционная БА.

Что такое «факт безопасности»? Это просто наступившее событие. Возможно, правило файрвола было изменено или система предотвращения вторжений блокировала некую атаку. Или это может быть состояние конкретного элемента программного обеспечения в облачном приложении в определенный момент времени. Суть в том, что фиксируется наступление или ненаступление события (или изменения состояния). Состояние может поменяться за миллисекунды или за год. Из-за этой метрики наличия/отсутствия, отличающейся от денежной меры, про факт безопасности говорят, что в нем «нет факта». По сути, суммируется куча «1» вместо долларов и центов. Для простой витрины данных уязвимости таблица фактов в традиционном понимании могла бы тогда выглядеть примерно как табл. 11.1.

В классических витринах данных первые три столбца представляют собой идентификаторы, являющиеся ссылками на таблицы измерений. Итог (событие) подводится на основе критериев измерений. Табл. 11.2, пусть и с некоторыми, возможно, излишними техническими подробностями, показывает, как может выглядеть та же структура данных с расшифрованными идентификаторами (обратите внимание, что в столбце даты указано Unix-время).

Здесь есть различные CVE (common vulnerabilities and exposures), что буквально переводится как «общеизвестные уязвимости и риски». А в таблице измерения уязвимости будут содержаться все основные характеристики уязвимости, которые могут еще сузить запрос. Есть IP-адрес, но опять же в измерении актива может иметься еще 100 характеристик, которые можно использовать для формулирования вопросов. И, наконец, есть метка времени.

Измерение – это разложение на составляющие объекта интереса, совокупность описательных характеристик какого-либо факта, позволяющих задать множество разнообразных вопросов. Например, в нашем измерении актива могут быть такие характеристики, как операционная система или версия пакета обновления. На самом деле, если для хранилища теоретически можно отслеживать во времени полный список установленного программного обеспечения и его версий, связанных с определенной концепцией актива, этот актив, в свою очередь, может стать одной или несколькими витринами данных с фактами, которые вы отслеживаете. Главное – убедиться, что для вашего анализа требуется такой уровень разложения. Хотя БА значительно упрощается, бесполезные разложения могут привести к тому, что усилия будут потрачены впустую. Проведите мозговой штурм с заинтересованными сторонами и сначала попробуйте добиться гибких результатов. Воспользуйтесь принципом KISS (Keep It Simple, Stupid – «Будь проще!»).

В табл. 11.3 представлен пример объекта измерения, в ширину такая таблица может достигать 100 или более столбцов.

Теперь, когда разобраны основы размерного моделирования, перейдем к созданию модели. Мы постараемся сделать объяснение простым, интуитивно понятным и нетехническим. Не нужно создавать «Размерную модель для управления Вселенной», способную предвосхищать все возможные вопросы. Значения можно добавлять по мере необходимости.

Пример применения размерного моделирования: повышенная угроза кражи данных

Давайте предположим, что в организации были разработаны КПЭ для новой характеристики, которую назвали «повышенная угроза кражи данных», или сокращенно ПУКД. Угроза определена как «вредоносное ПО, похищающее данные и изначально не замеченное применяемыми коммерческими готовыми решениями в области безопасности». То есть ПУКД активна в течение некоторого времени, пока наши вложения не «догонят» и не остановят ее. Пусть с помощью Excel и R или Python был проведен быстрый анализ нескольких выборок ПУКД за последний год. В частности, выполнен так называемый анализ выживаемости, чтобы получить график, представленный на рис. 11.5.

Что такое анализ выживаемости? Это анализ имеющих жизненный цикл объектов, у которых со временем каким-либо образом меняется статус, вплоть до окончания цикла. Анализ выживаемости первоначально появился в медицинской сфере, а теперь также применяется в инженерном деле, страховании, политологии, управлении бизнесом, экономике и даже безопасности. Центральное место в анализе занимает функция выживания. В нашем случае это кривая, отображающая переменную времени относительно доли объектов, продолжающих существовать. Функция позволяет делать выводы о продолжительности жизни определенных явлений, например ПУКД.

Рис. 11.5. Дни существования ПУКД до обнаружения

Обратите внимание на два случая, в которых произошло финансовое воздействие. За неимением лучших вариантов принимается решение «улучшить кривую в целом», особенно в связи с этими двумя случаями убытков. Таким образом, нашим КПЭ становится «Увеличение на 20 % эффективности поиска повышенных угроз, сохраняющихся в течение 70 дней и более». Вы решаете в обозримом будущем тщательно измерять этот показатель (и мы действительно рекомендуем измерять его как основную метрику безопасности). Как перейти от стратегической аналитической модели, позволившей обосновать новые вложения, к метрике безопасности? Для этого необходимо мыслить как конструктор размерных моделей.

К счастью, размерные модели, над которыми мы работали до сих пор, применимы и здесь. Итак, перечислим различные имеющиеся у нас «измерения» и выясним, как они могли бы вписаться в витрину анализа выживаемости ПУКД (табл. 11.4). Цель – понять, каким образом наши вложения на самом деле справляются с ПУКД и справляются ли вообще. Можно ли оптимизировать конкретное решение на основе получаемой информации? Срабатывает ли решение конкретного поставщика быстрее других или же отстает? Или, если формулировать точнее, были ли какие-то изменения конфигурации, исправленные уязвимости, новые средства контроля для смягчения последствий или новые антивирусные программы особенно эффективны в борьбе с ПУКД?

Витрина данных с рис. 11.6 использует уже существующие витрины и добавляет связанные с HTTP данные с прокси-серверов. Такой витрины будет достаточно для полного анализа ПУКД.

Рис. 11.6. Высокоуровневая витрина ПУКД

Глядя на табл. 11.5, можно заметить, какой простой в итоге оказалась наша таблица фактов. Столбцы измерений, как правило, широкие, а фактов – относительно узкие. Вот как работает наша таблица фактов.

• Если смягчение последствий отвечает за блокировку, то в поле mit_id будет указан идентификатор конкретного решения поставщика средств защиты, ответственного за предотвращение атаки. В противном случае это значение будет равно 0. Сам идентификатор отсылает к измерению смягчения последствий.

• Если с ликвидацией угрозы справилась защита от вредоносного ПО, то в поле mal_id будет указан идентификатор конкретной программы, полученный из измерения вредоносного программного обеспечения.

• В поле http_id указывается URL-адрес конкретного командного сервера, с которым актив пытался связаться в момент, когда ему помешали.

• Поле date_http_start_id указывает на измерение даты и отображает, когда впервые была замечена ПУКД. В девяти случаях из десяти для этого необходимо отправить запрос обратно через прокси-журналы HTTP, после того как система смягчения последствий и/или система борьбы с вредоносным ПО узнает об угрозе. Процесс можно легко автоматизировать, но, как уже говорилось ранее, журналы, скорее всего, будут находиться в системе больших данных.

• Поле date_https_end_id аналогично предыдущему, но для случая, когда ПУКД была предотвращена.

• Поле asset_id указывает на рассматриваемый актив.

• Поле vuln_id заполняется, если есть корреляция с известной уязвимостью. Если это – единственный заполненный идентификатор, помимо даты и актива, значит, за предотвращение ПУКД был ответствен патч, ранее исправивший определенную уязвимость.

Моделирование процессов работы с людьми

Размерные модели идеально подходят метрикам безопасности, потому что они разработаны для измерения процессов, а безопасность – это, определенно, процесс. Очевидно, что в случае с ПУКД процесс является техническим. А если требуется измерить процессы, в большей степени связанные с людьми? Что если у процесса есть несколько логических элементов и/или этапов? Это тоже легко размерно смоделировать. Такой тип модели называется «накопительный снимок», и накапливается в нем время выполнения каждой фазы процесса.

С точки зрения безопасности подобная модель имеет ключевое значение для численного измерения процесса разработки до и после выпуска продукта (релиза) и деятельности по исправлению недочетов или их в комплексе. Например, если вы внедрили методику жизненного цикла безопасной разработки Security Development Lifecycle (а мы надеемся, что так и есть), то, скорее всего, захотите измерить ее основные макрофазы: безопасность по замыслу, безопасность по умолчанию (разработка) и безопасность в применении. И неважно, используете ли вы методологию водопада, Agile или смешанный подход. Можно инструментировать все процессы. Подобные инструменты и измерения являются ключевыми при работе в контексте практики непрерывной интеграции и непрерывной доставки (continuous integration and continuous development, CICD). CICD ежедневно поддерживает постоянный поток развертывания программных продуктов. Новые разработки и исправления происходят непрерывно. Это одна из многих функций, которые можно и даже нужно бесконечно размерно моделировать, измерять и оптимизировать.

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

Рис. 11.7. Факты рабочего процесса по исправлению

Например, одна витрина может моделировать устранение уязвимости системы, а другая – процесс исправления веб-приложений и т. д. Измерение риска здесь выступает просто обобщением для всех типов уязвимостей, и взять можно любой тип. «Актив» – тоже обобщение, это может быть приложение или даже операционная система. Измерение исправлений предполагает наличие в организации некой тикет-системы, которая будет содержать список незавершенных задач, включая данные о различных людях, участвующих в исправлениях. Время в данном случае представляет наибольшую сложность. Видно, что есть четыре измеряемых элемента и один общий. С временным измерением связано более 20 различных дат. В каждой из пяти групп есть итоговое поле, например Days_Existing или Analysis_Days_Reviewing. Эти поля увеличиваются, пока не будет заполнено итоговое поле даты для каждой области. Накопитель позволяет значительно повысить скорость обработки запросов и дополнительных агрегированных величин при анализе процессов исправлений.

Эту модель можно взять в качестве простого шаблона для дальнейшего моделирования связанных с безопасностью процессов, состоящих из нескольких этапов. Используемые в ней измерения также подходят и для моделирования технических решений. Таким образом, мы не нарушаем требований простоты, гибкости и повторного использования.

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

В данной главе предпринята попытка объяснить в очень общих чертах столь необходимый подход к метрикам кибербезопасности. Надеемся, нам удалось вас заинтересовать.

Заключительная глава посвящена человеческой стороне «управления рисками кибербезопасности» в организации. Мы опишем различные роли и обязанности, а также расскажем о перспективах эффективного управления программами.

Как внедрить управление рисками кибербезопасности

В этой книге есть три общие темы:

1) что такое измерения;

2) как применять измерения;

3) как улучшить измерения.

От своих предшественниц, книг «Как измерить все, что угодно. Оценка стоимости нематериального в бизнесе» и The Failure of Risk Management, она отличается тем, что ориентирована на конкретную область. Более того, книга создавалась как дорожная карта для построения системы управления рисками кибербезопасности и стратегических технологических методов управления рисками для руководителей высшего звена. По нашему мнению, на данный момент кибербезопасность как операционную функцию необходимо переопределить на основе количественных показателей управления рисками. Данная книга пропагандирует количественные методы и предлагает дополнительные аргументы в их пользу. Если вам кажется, что управление рисками кибербезопасности (УРК) должно представлять собой программу, а не набор количественных приемов, то эта глава как раз для вас. Здесь мы рассмотрим, как может выглядеть такая программа и как она может работать вместе с другими функциями, связанными с технологическими рисками.

Составление стратегической хартии управления рисками кибербезопасности

Данный раздел отвечает на вопрос «Какова должна быть стратегическая корпоративная роль управления УРК?». То, что понимается нами под функцией УРК, должно стать первым аспектом для рассмотрения крупных инвестиций на уровне высшего руководства или совета директоров. Решения по-прежнему принимают руководители, но они пользуются количественными методами для сложения, умножения и деления долларов и вероятностей. Порядковые шкалы и другие фальшивые методы оценки риска неприемлемы.

Функция УРК является функцией уровня руководства высшего звена. Выполнение этой функции может возлагаться на руководителя отдела информационной безопасности, но мы бы отнесли ее выше по субординации – к его начальнику, в свою очередь подчиняющемуся непосредственно генеральному директору или совету директоров. Если руководитель отдела информационной безопасности обладает подобными полномочиями, тогда это, конечно, тоже может сработать, но для этого ему придется сменить круг обязанностей. «Информация и безопасность» завязаны на «риск», который рассматривается исключительно как вероятность и воздействие в понимании актуария. Что касается обязанностей или изменения должности, нам встречались такие варианты, как «главный специалист по управлению технологическими рисками» и «главный специалист по рискам». К сожалению, последний, как правило, выполняет чисто финансовые и/или юридические функции. Как бы ни называлась должность, она не должна находиться в подчинении у директора по IT / технического директора, в противном случае это все равно, что назначить лису следить за курятником. Функция УРК отвечает интересам генерального директора и совета директоров и нужна для защиты бизнеса от неудачных инвестиций в технологии.

Хартия в целом такова.

• Деятельность по УРК подотчетна генеральному директору и/или совету директоров. Должность руководителя может называться «главный специалист по управлению технологическими рисками», «главный специалист по рискам» или, возможно, «руководитель отдела информационной безопасности», при условии что его обязанности будут качественно переопределены.

• Функция УРК должна рассматривать все крупные инициативы с учетом технологических рисков, в том числе корпоративные поглощения, крупные инвестиции в новые технологии для предприятия, венчурные инвестиции и т. п. «Рассматривать» здесь означает количественно оценивать и прогнозировать потери, прибыли и стратегические меры по смягчению последствий, а также связанные с этим оптимизации.

• В обязанности УРК также входит мониторинг и анализ существующих вложений в средства контроля безопасности. Задача состоит в оптимизации вложений в технологии с учетом вероятных будущих убытков. Размерное моделирование и связанные с ним техники, описанные в главе 11, являются при этом ключевыми. С операционной точки зрения целью данной функции является ответ на вопрос «Эффективно ли взаимодействуют между собой наши вложения в борьбе с ключевыми рисками?».

• В УРК применяются проверенные количественные методы для понимания и передачи информации о риске в денежном выражении. Кривые вероятности превышения потерь должны стать средством для обсуждения и визуализации рисков, а также связанных с ними инвестиций в смягчение последствий с учетом рискоустойчивости. Сюда входят риски, связанные с одним приложением, и/или их совокупность из одного или нескольких портфелей риска.

• Специалист по УРК отвечает за поддержание рискоустойчивости компании совместно с финансовым директором, главным юрисконсультом и советом директоров. В частности, КПЭ, используемым для управления рисками, должно быть «превышение допустимого риска».

• Функция УРК отвечает за руководство технологическими программами управления исключениями, нарушающими допустимый уровень риска, и их мониторинг.

• Функция УРК обеспечивает политику киберстрахования совместно с юридической и финансовой функциями, в том числе УРК определяет базовые параметры, на основе которых строятся модели страхования.

Роли и обязанности УРК в организации

На рис. 12.1 показан пример организационной структуры УРК. Такая структура больше подходит для крупной компании (вроде тех, что входят в список Fortune 1000) с оборотом в сотни миллионов, а то и в миллиарды долларов, которые могут оказаться под угрозой. Отсюда следует, что инвестиции в технологии являются ключевой стратегической инициативой, которую довольно просто претворить в жизнь в наши дни. А также что риски кибербезопасности находятся в пятерке, если не в тройке самых серьезных рисков, рассматриваемых на уровне совета директоров или генерального директора.

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

Рис. 12.1. Функция управления рисками кибербезопасности

Важно подобрать правильное соотношение проведения количественного анализа и задач по оценке риска. С практической точки зрения в каждый конкретный момент времени для запуска и сопровождения доступно ограниченное количество моделей. Соотношение 10:1 новых моделей на одного аналитика кажется целесообразным. Но это зависит от сложности моделей. Кроме того, завершенные модели нуждаются в постоянном отслеживании текущих рисков относительно уровня рискоустойчивости. Здесь, безусловно, большим подспорьем оказываются корпоративные технологии, однако даже с продвинутой предписывающей аналитикой необходимость консультирования по поводу превышения допустимого уровня риска все равно никуда не исчезает. То есть если потребуется оптимизировать определенный портфель рисков, возможно путем приобретения новых технологий и/или вывода из эксплуатации неудачных инвестиций, то надо учитывать, что весь этот процесс занимает время. Ведь количественный анализ рисков будет задействован и во всех текущих обсуждениях по определению рисков, и в разработке моделей с использованием статистики и статистических инструментов (R, Python и т. д.), и в координации работы с технологами компании с целью проектирования и создания систем мониторинга рисков в режиме реального времени.

При помощи команды специалистов по количественному анализу рисков можно, конечно, собрать обучающие материалы по количественной оценке и даже проводить тренинги, но все же основная задача здесь – внедрить количественный подход на различных уровнях организации. Это похоже на построение общей структуры безопасности в инженерных и IT-командах (мы предполагаем, что вы уже этим занимаетесь).

Ваши возможности по расширению штата специалистов по количественному анализу рисков весьма ограничены – их мало, они дорого обходятся, и их трудно удержать, ведь такие специалисты очень востребованы. Поэтому, если вы собираетесь бороться со злоумышленниками, необходимо активно развивать соответствующие инструменты и навыки в целом. И для выполнения этой функции понадобится команда по разработке и предоставлению контента, а также кто-то, кто ее возглавит. При этом использование технологий для достижения результата становится ключевым моментом в крупных, распределенных организациях.

Самая дорогостоящая и затратная в операционном плане функция. Она предполагает использование больших данных, потоковой аналитики и облачных решений для поддержки множества результатов аналитической деятельности. Команде аналитиков предстоит управлять перемещением больших массивов данных и соответствующим развертыванием телеметрии в системах. Если вы надеетесь внедрить хотя бы часть практик из главы 11, пользуясь методологией Agile, именно данная группа должна этим заниматься. В ее составе должны быть системные инженеры, администраторы баз больших данных, программисты и т. д. Это оптимизированное IT-подразделение, ориентированное на аналитические результаты.

Деятельность, затрагивающая множество функций в нескольких подразделениях, является программой. Функция УРК, как правило, как раз реализуется в различных подразделениях. Команда количественного анализа рисков занимается технической стороной, но всё вместе, от вовлечения через обучение и развитие до технологий, связывает функция управления программой. Не стоит перегибать палку в этом вопросе, но и не экономьте на управлении программой, иначе вас ждет провал.

Можно было бы еще подробнее обсудить каждую роль и функцию, расписав различные матрицы, должностные инструкции, диаграммы Ганта и т. п. Но в этом нет необходимости. Все описанные в книге практики знакомят с основным содержанием более крупной функции управления рисками кибербезопасности. Роли и обязанности достаточно адаптивны. Вы можете для начала потренироваться с минимальными затратами на одном или двух проектах с помощью одних лишь предоставленных электронных таблиц. Однако, если вы всерьез намерены противостоять злоумышленникам с помощью аналитики, вам нужен план. Прежде всего определите, на каком этапе модели зрелости, описанной в начале третьей части, вы находитесь. Затем наметьте курс развития навыков и систем, которые позволят создать возможности для предписывающей аналитики. Наличие плана устраняет ключевое препятствие на пути к успеху. Как сказал Бенджамин Франклин: «Те, кто не готовится, готовятся к неудаче!»

Существует множество потенциальных преград вроде неудачного планирования, мешающих добиться успеха, но есть одна институциональная преграда, способная затруднить количественный анализ: аудиты соответствия. В теории аудиторские проверки должны помочь убедиться, что действия происходят в нужное время и нужным образом. В этом смысле аудиты – отличная вещь. Но они становятся проблемой, когда функции управления рисками фокусируются на удовлетворении аудита вместо управления реальными рисками. Именно поэтому, вероятно, генеральный директор компании Target был шокирован, когда у них произошла утечка данных. Согласно его официальному заявлению, компания соответствовала стандарту индустрии платежных карт. Другими словами, настрой на соответствие преобладает над настроем на управление рисками, и это смертельная ошибка перед лицом наших врагов.

А если бы существовала функция аудита, оценивающая (действительно измеряющая) эффективность подходов к управлению рисками? То есть могла бы она определить фактическое влияние на снижение риска мягких методов в сравнении с количественными методами? А если проверить алгоритмы балльной оценки? Конечно же, тогда нужно будет протестировать и передовые методы, такие как симуляции по методу Монте-Карло, бета-распределение и т. п. Прекрасно! Опять же мы считаем одной из причин неудач непроверенные мягкие методы.

Однако есть риск, что это приведет к противоположному результату. Например, что, если методы, основанные на измерении неопределенности, подвергались бы аудиту потому, что считаются новыми, а методы, где используются матрицы рисков, порядковые шкалы и системы балльных оценок, уже по обратной причине оставались без проверки? Это могло бы помешать внедрению количественных методов. К сожалению, как вы узнаете далее, так и произошло по крайней мере в одной отрасли. Мы приводим эту ситуацию как пример аудита соответствия, который вышел из-под контроля и мог бы оказать сильное негативное влияние на управление рисками кибербезопасности.

Аудит аудита

Аудит играет ключевую роль в обеспечении качества моделей риска, особенно в таких жестко регулируемых областях, как банковское дело и страхование. При разработке новых количественных моделей, оказывающих влияние на финансовые операции, аудит является необходимой контрольной точкой, позволяющей убедиться, что модели не приведут к непредвиденным последствиям, скажем, из-за простых ошибок, вкравшихся в сложные формулы. Подобный тщательный анализ должен применяться к любой модели, предложенной для финансовых операций и, конечно, для решений, касающихся подверженности организации таким рискам, как неопределенность рынка и кибератаки.

Аудиторы могут воодушевиться, увидев модель, содержащую сложные математические вычисления. Каждый аудитор в какой-то момент своей карьеры проходит через подобное. Здорово ведь наконец-то получить возможность применить на практике что-то, на изучение чего когда-то было потрачено так много времени и сил. Поэтому они с рвением, как им и следует, примутся за модели, содержащие некоторые статистические данные и, возможно, симуляции по методу Монте-Карло. Если заявляется, что метод основан на каких-то научных исследованиях, о которых аудиторы не слышали, они должны потребовать ссылки на исследования. Если модель довольно сложная, вероятно, следует провести аудит дважды, пригласив двух разных специалистов. И если в процессе проверки в модели обнаружится ошибка, то те, кто эту модель разработал, если их интересует в первую очередь качество, должны с радостью ее исправить.

Однако даже добросовестные и квалифицированные аудиторы, сами того не желая, мешают внедрению более совершенных моделей при принятии решений. В некоторых случаях более сложная модель приходит на смену очень мягкой, ненаучной модели. Фактически так было со всеми моделями, разработанными и представленными авторами этой книги. Наши разработки пришли на смену моделям, основанным на методах, против которых здесь уже приводились аргументы: выполнении арифметических действий с порядковыми шкалами, использовании определений типа «средний» в качестве оценки риска, тепловых картах и т. д. Тем не менее все эти мягкие методы не подвергаются такой же тщательной проверке со стороны аудиторов. Если в сфере кибербезопасности появляется метод, в котором нужно лишь субъективно оценить вероятность и воздействие, а затем выразить их с помощью субъективных оценок с использованием неоднозначных шкал, аудиторы не требуют ссылки на исследования, показывающие измеренную эффективность некалиброванных субъективных оценок, обосновывающие метод математически или указывающие на проблемы при использовании вербальных шкал для обозначения риска.

Что же происходит, когда проверяются только методы, содержащие более сложные расчеты? Тех, кто использует простую систему подсчета баллов, которую они сами только что придумали, не будут проверять так же тщательно, как сторонников передовых методов, только благодаря тому, что их метод простой. Это лишает стимула совершенствовать работу с помощью применения количественных и научно обоснованных методов управления рисками и принятия решений.

Чтобы аудит не превратился (наверняка непреднамеренно) в такую дестимулирующую меру в сфере совершенствования процесса принятия управленческих решений, необходимо начать проводить аудит мягких методов так же тщательно, как он проводится в отношении методов, позволяющих аудиторам вспомнить свои знания статистики.

• Аудит проводится для ВСЕХ моделей. Все решения принимаются на основе модели, будь то интуиция руководителя, субъективная система баллов, детерминированный анализ экономической эффективности, стохастические модели или подбрасывание монетки. Аудитору не стоит проверять только то, что сама организация называет моделями. Если какие-то решения принимаются интуитивно, то надо изучить также обширные исследования ошибок интуиции и чрезмерной уверенности и затребовать доказательства того, что такие проблемы никак не касаются рассматриваемой ситуации.

• Модель не должна проверяться строго в своих рамках. Например, если применяется детерминированная модель экономической эффективности в виде электронной таблицы для оценки средств контроля кибербезопасности, недостаточно просто проверить правильность основных финансовых расчетов или спросить, откуда взялись исходные данные. Лучше аудитору начать с вопроса: можно ли вообще применять подобный подход моделирования в этом случае, почему детерминированные методы используются для принятия решений, которые явно опираются на неопределенные исходные данные?

• Тот факт, что вывод модели неоднозначен, не указывает на невозможность измерить ее эффективность. Если модель говорит, что риск «средний», следует задаться вопросом: действительно ли события средней степени риска происходят чаще, чем события низкой степени, и реже, чем события высокой степени риска? Количественные модели часто привлекают внимание, так как их выводы однозначны и могут отслеживаться для сравнения с фактическими результатами. Именно поэтому аудиторы предпочитают изучать статистические, а не мягкие модели. И это на самом деле говорит в пользу первых.

• Аудитору следует попросить предоставить исследования, подтверждающие относительную эффективность данного метода по сравнению с альтернативными вариантами. Если метод предполагает создание цветной тепловой карты, можно обратиться к работам Тони Кокса. Если опирается на вербальные шкалы – к работам Дэвида Будеску и Ричарда Хойера. И если утверждается, что предложенный более мягкий метод каким-то образом позволяет избежать выявленных этими исследователями проблем, то должны быть предоставлены соответствующие доказательства.

• Даже утверждения о том, какие уровни сложности допустимы в организации, не должны приниматься за чистую монету. Если более простой метод балльной оценки предлагается из соображения, что руководство не поймет более сложные методы, то стоит потребовать исследований, подтверждающих данное утверждение (совокупный опыт авторов свидетельствует об обратном).

Одно из обоснованных опасений заключается в том, что аудитору, возможно, придется выполнять очень большой объем работы. Мы, конечно, понимаем, что у них много важных дел и часто не хватает персонала, но все же в ходе аудита можно по крайней мере проверять какие-то ключевые методы, особенно когда они содержат псевдовычисления. Если хотя бы часть мягких моделей начнет подвергаться аудиту в той же степени, что и модели, содержащие математические вычисления, у организаций исчезнет стимул придерживаться научно не обоснованных методов только для того, чтобы избежать аудиторских проверок.

Что должна сделать экосистема кибербезопасности для вашей поддержки

Ранее в этой книге были подробно рассмотрены популярные методы анализа рисков и установлена их несостоятельность. Они не добавляют ценности и, по сути, привносят ошибки. Кто-то скажет, что такие методы помогают хотя бы «начать разговор» об управлении рисками, но поскольку это же можно сделать с помощью многих методов, почему бы сразу не выбрать те, что показывают измеримое улучшение оценок? Кроме того, нельзя продолжать заявлять, что количественные методы непрактичны, поскольку они применялись нами в реальных условиях, будь то симуляции по методу Монте-Карло, байесовские эмпирические методы или более продвинутые их комбинации, описанные в главах 8 и 9. И, наконец, ничего в сведениях о недавних крупных утечках данных не указывает на то, что существующие широко применяемые методы вообще хоть как-то помогали управлять рисками.

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

1. Организации по стандартизации должны прекратить продвижение в сфере управления рисками кибербезопасности матриц риска как «лучших практик» и начать продвигать обоснованные (научные) подходы, если только не будут получены доказательства их неэффективности. Как было нами продемонстрировано, в отношении мягких методов подобных доказательств предостаточно.

2. В дополнение к первому пункту организации по стандартизации должны принять научно обоснованные методы для выявления лучших практик вместо существующих методов, в основе которых лежат рекомендации или мнения комиссий. Если организации по стандартизации смогут продемонстрировать эмпирические доказательства эффективности своих текущих рекомендуемых методов, которых окажется достаточно для опровержения уже имеющихся эмпирических данных, свидетельствующих против них (что кажется маловероятным), только тогда эти методы можно будет снова продвигать.

3. Можно создать организацию, которая будет отслеживать и измерять эффективность работы самих методов оценки риска. Она может быть сформирована по образцу Национальной базы данных уязвимостей, которую ведет NIST, а может – даже как часть этой базы (в конце концов, плачевное состояние методов оценки риска определенно стоит считать уязвимостью уровня государства). Тогда организации по стандартизации могли бы при выборе опираться на информированный, основанный на фактах анализ альтернативных методов.

4. Программы сертификации, обучающие применению матриц рисков и порядковых шкал, должны перейти на обучение как уже существующим научно обоснованным методам, так и новым методам, появляющимся по мере накопления доказательств (полученных из опубликованных исследований и благодаря осуществлению перечисленных выше действий).

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

6. Регулирующие органы должны способствовать изменениям. Понятно, что консервативные регуляторы меняются медленно, но им следует хотя бы начать процесс признания неадекватности методов, которые в настоящее время считаются «соответствующими требованиям», и поощрять более эффективные методы.

7. Поставщики, консультанты и страховые компании должны ухватиться за коммерческие возможности, связанные с методами, описанными в этой книге. Опрос, упомянутый в главе 5, показал высокий уровень принятия количественных методов среди специалистов по кибербезопасности. Растет количество доказательств неэффективности ряда наиболее популярных методов и эффективности строгих научно обоснованных методов. Те, кто первыми станут продвигать методы, способные показать измеримые улучшения, получат преимущество. Страховые компании уже начинают понимать, что научно обоснованные методы – верное решение. Применение таких методов клиентами страховых компаний и качество их применения должны в итоге стать частью процесса страхования.

Удастся ли избежать «Большого взлома»?

«Большой взлом», который упоминался в главе 1, представляет собой масштабную кибератаку, затрагивающую несколько крупных организаций. В том числе следствием может стать сбой в работе основных служб, например оказывающих коммунальные услуги и услуги связи. Это в сочетании со значительным снижением доверия к онлайн-транзакциям и операциям по платежным картам может оказать на экономику гораздо большее влияние, чем затраты отдельной крупной компании – даже крупнейшей из пострадавших на сегодняшний день.

Характер атаки на компанию Target – один из показателей природы риска. Она была атакована таким образом, что раскрыла угрозу, общую для многих предприятий: компании и их поставщики связаны друг с другом, и многие из них соединены в сети со множеством прочих компаний. Так или иначе с ними связаны даже правительственные учреждения. Все организации разделены всего одним или двумя уровнями связи. Если поставщик услуг может обнажить уязвимость компании и если у этого поставщика много клиентов, а у этих клиентов много поставщиков, то получается своего рода общий сетевой риск, который хотя еще и не эксплуатировался, но вполне возможен.

Анализ рисков, связанных с подобной ситуацией, слишком сложен, чтобы его можно было выполнить с помощью существующих популярных методов или в голове любого из ведущих экспертов. Правильный анализ потребует создания реальных количественных моделей для расчета воздействия всех связей. Организации с ограниченными ресурсами (а они, конечно же, ограничены у всех) должны будут применять рациональные научно обоснованные методы, решая, каким образом снижать такие риски. Начав соглашаться с этим, мы сможем повысить шансы на то, что удастся избежать «Большого взлома» или, по крайней мере, восстановиться после него с меньшими затратами.