В главе 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. Эти поля увеличиваются, пока не будет заполнено итоговое поле даты для каждой области. Накопитель позволяет значительно повысить скорость обработки запросов и дополнительных агрегированных величин при анализе процессов исправлений.
Эту модель можно взять в качестве простого шаблона для дальнейшего моделирования связанных с безопасностью процессов, состоящих из нескольких этапов. Используемые в ней измерения также подходят и для моделирования технических решений. Таким образом, мы не нарушаем требований простоты, гибкости и повторного использования.
В этой главе дан очень краткий обзор мощного логического инструмента для работы с метриками операционной безопасности: размерного моделирования. Такой уровень метрик эффективности редко практикуется в сфере безопасности, и это, повторимся, вопиющее безобразие. По нашему мнению, анализ эффективности вложений не менее важен, чем применение прогностической аналитики при принятии решения об инвестициях. Мы бы даже сказали, что, не прибегая к подобным измерениям операций, вы играете на руку и своим врагам, и недобросовестным поставщикам средств контроля безопасности. С появлением больших данных и упрощением доступа к данным высокоразмерные метрики безопасности должны стать основным подходом к измерениям и оптимизации.
В данной главе предпринята попытка объяснить в очень общих чертах столь необходимый подход к метрикам кибербезопасности. Надеемся, нам удалось вас заинтересовать.
Заключительная глава посвящена человеческой стороне «управления рисками кибербезопасности» в организации. Мы опишем различные роли и обязанности, а также расскажем о перспективах эффективного управления программами.