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

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

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

Таблица 11.3. Измерение актива

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

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

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

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

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

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

Таблица 11.4. Описание измерений ПУКД

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

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

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

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

Таблица 11.5. Факт блокировки ПУКД

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

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

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

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