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