Ознакомительная версия. Доступно 19 страниц из 92
Моделирование процессов работы с людьми
Размерные модели идеально подходят метрикам безопасности, потому что они разработаны для измерения процессов, а безопасность – это, определенно, процесс. Очевидно, что в случае с ПУКД процесс является техническим. А если требуется измерить процессы, в большей степени связанные с людьми? Что если у процесса есть несколько логических элементов и/или этапов? Это тоже легко размерно смоделировать. Такой тип модели называется «накопительный снимок», и накапливается в нем время выполнения каждой фазы процесса.
С точки зрения безопасности подобная модель имеет ключевое значение для численного измерения процесса разработки до и после выпуска продукта (релиза) и деятельности по исправлению недочетов или их в комплексе. Например, если вы внедрили методику жизненного цикла безопасной разработки 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) как улучшить измерения.
От своих предшественниц, книг «Как измерить все, что угодно. Оценка стоимости нематериального в бизнесе» и The Failure of Risk Management, она отличается тем, что ориентирована на конкретную область. Более того, книга создавалась как дорожная карта для построения системы управления рисками кибербезопасности и стратегических технологических методов управления рисками для руководителей высшего звена. По нашему мнению, на данный момент кибербезопасность как операционную функцию необходимо переопределить на основе количественных показателей управления рисками. Данная книга пропагандирует количественные методы и предлагает дополнительные аргументы в их пользу. Если вам кажется, что управление рисками кибербезопасности (УРК) должно представлять собой программу, а не набор количественных приемов, то эта глава как раз для вас. Здесь мы рассмотрим, как может выглядеть такая программа и как она может работать вместе с другими функциями, связанными с технологическими рисками.
Составление стратегической хартии управления рисками кибербезопасности
Данный раздел отвечает на вопрос «Какова должна быть стратегическая корпоративная роль управления УРК?». То, что понимается нами под функцией УРК, должно стать первым аспектом для рассмотрения крупных инвестиций на уровне высшего руководства или совета директоров. Решения по-прежнему принимают руководители, но они пользуются количественными методами для сложения, умножения и деления долларов и вероятностей. Порядковые шкалы и другие фальшивые методы оценки риска неприемлемы.
Функция УРК является функцией уровня руководства высшего звена. Выполнение этой функции может возлагаться на руководителя отдела информационной безопасности, но мы бы отнесли ее выше по субординации – к его начальнику, в свою очередь подчиняющемуся непосредственно генеральному директору или совету директоров. Если руководитель отдела информационной безопасности обладает подобными полномочиями, тогда это, конечно, тоже может сработать, но для этого ему придется сменить круг обязанностей. «Информация и безопасность» завязаны на «риск», который рассматривается исключительно как вероятность и воздействие в понимании
Ознакомительная версия. Доступно 19 страниц из 92
