Рациональное невежество и безопасность

Одно из основных правил при организации защиты звучит примерно так: «Затраты на организацию защиты не должны превышать сумму возможного ущерба». Доля правды в этом есть, и немалая! Ну во-первых, чистая экономика: смысл любой защиты - уберечь активы от ущерба, так как ущерб влечет за собой потери, а потери - собственно затраты. Затраты на защиту, превышающие затраты от потерь, есть суть тот же ущерб, только законный и официальный. Ну это, я надеюсь, понятно.
Во-вторых, теория систем. Любая система должна надлежащим образом управляться, а управление обеспечивается наличием сильного руководящего центра и достаточного количества связей. Таким образом, система защиты должна быть управляемым компонентном основной системы, менее сложным. И, как минимум, не подрывать надежность родительской системы. А в случае высокого уровня затрат на организацию защиты, как правило, сложно обеспечить достаточную надежность и простоту системы защиты, что влечет за собой потери для объекта защиты.
Ну и тут в общем-то подключается здравый смысл, и все вроде бы ясно. Однако, есть у этой почти что теоремы, оказывается, еще одно обоснование, на этот раз более наукоемкое. Это так называемое рациональное невежество. Правда, прикладывается это понятие к сильно обобщенной системе защиты, однако, попытаюсь изложить суть кратко и четко.
Итак, в общем виде на сегодняшний момент система защиты представляет собой суть следующее: некий объект подвержен наличию негативных возможностей, читай, рисков, которые могут реализоваться и нанести ущерб. Риски имеют под собой факторы, которые являются множеством угроз, то есть намерений нанести вред, и уязвимостей, то есть недостатков объекта, позволяющих этот вред допустить. Таким образом, задача защиты формируется как ряд действий, направленных на поиск рисков, выявление их факторов, и минимизацию их возможного влияния, то есть компенсация недостатков и защита от намерений. Этот ряд действий, в совокупности со средствами их реализации, можно рассматривать как источник затрат на организацию защиты. Также следует отметить, что задача защиты решается тем точнее и успешнее, чем более точным и объективным было выявление рисков. Сложность и точность анализа рисков - вопрос отдельного обсуждения, которое, наверное, никогда не иссякнет, а сейчас посмотрим на это с другой стороны.
Рациональным называют невежество, когда стоимость самостоятельного изучения предмета достаточно высока и может перевесить любые потенциальные преимущества, которые можно ожидать от тщательно продуманного принятия решения, поэтому было бы иррационально тратить на неё время. В нашем случае предмет - это объект защиты в его нынешнем состоянии с неопределенностью относительно возможных рисков, а изучение - новый уровень анализа, увеличивающий объем и точность знаний об этом объекте. На определенном этапе анализа затраты на его дальнейшее осуществление превысят выгоды от подобного точного и объективного подхода к защите. Следовательно, задача защиты состоит еще и в том, чтобы найти ту степень изучения предмета, при которой объемов полученных знаний достаточно, чтобы обеспечить защиту на должном уровне, но совокупные затраты на получение этих объемов не превысили выгоду от их наличия. Можно также сказать, что нижняя граница отсутствия информации о защищаемом объекте наступает тогда, когда это отсутствие знание (невежество) становится рациональным.
Вообще приложение математических теорий принятия решений, таких как теория игр и теория перспектив, к безопасности является крайней интересным моментом. Возможно, далеко не новым, но моя задача - не описать принципиально новое в профессии, это удается сделать единицам, но изучить, аргументировать и найти применение тому, что есть.

Превратности современного управления безопасностью. Риски. Увертюра

А вы, друзья, как ни садитесь...

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

Собственно само по себе управление рисками является, на мой взгляд, грамотным и адекватным методом, как минимум, распределения приоритетов защитных мер и аргументации принятия решений при обеспечении безопасности информации. Однако, учитывая последнюю моду - а иначе это и не назвать, - его принято внедрять везде и всюду, в любую деятельность, во все организации и структуры. Не обошла стороной эта тенденция и нынешнего клиента организации, в которой я работаю. Клиент этот, надо заметить, организация финансовая, поэтому информатизация в ней является именно что обеспечивающей сферой деятельности, услугой для бизнеса в нынешнем понимании сервисного подхода. Встала передо мной задача описать группу процессов (именно так, ни больше ни меньше) управления рисками проектов для сферы информатизации этой организации. Исходя из приближенной процессной модели, управление рисками там предполагается, состоит из нескольких процессов, практически соответствующих стандартам и методологиям управления рисками, ну и вообще востребовано и желанно. Необходимо только описать входы и выходы для процессов, т. е. определить реальные документы, поступающие на вход и получаемые на выходе, их цели, задачи и практическую пользу. Вроде бы всего делов-то, однако, ключевое слово здесь - РЕАЛЬНЫЕ документы.

В большинстве методик управление рисками какой-то деятельности заключается в их (рисков) идентификации, описании, анализе, выработке ответных действий и дальнейшем контроле и совершенствовании. Для управления рисками в рамках проекта существует целый ряд методических руководств, некоторых из которых стали стандартами де-факто. Одним из таких стандартов является Руководство по использованию свода знаний по управлению проектами (Project Management Body of Knowledge Guide, PMBOK Guide), разработанное Институтом проектного управления (Project Management Institute, PMI). Управление рисками представлено в рамках данного Руководства группой процессов, описанных, например здесь или особенно подробно (а если быть откровенным, то полностью содрано, назло всем сторонникам интеллектуальной собственности) здесь. Как любой другой межотраслевой общий стандарт (хотя Руководство все же позиционируется как стандарт в области управления ИТ проектами), PMBOK содержит массу исчерпывающих рекомендаций, использование которых практически нереально без помощи интеграторов, внедряющих управления в соответствии с данным Руководством за совсем несимволическую мзду. Поэтому при попытке применить к жизни и суровой отечественной реальности, испытываешь некий когнитивный диссонанс. Но это вроде как нормально - иначе интеграторам просто не за что было бы платить, достаточно было бы один раз заплатить за сам стандарт. Но с рисками ситуация, по-моему, иная.
Во-первых, сложность и условность организации самих процессов. К примеру, идентификация рисков проекта должна осуществляться уже после того, как будут определены такие аспекты проекта как этапность, сроки выполнения (например, технологический график проекта) и стоимостные показатели проекта. Потому что основная суть управления рисками в данном случае (возможно, и в любом другом, но сейчас речь идет конкретно про эту область знаний) - проанализировать влияние неопределенностей проекта на его характеристики и минимизировать его, меняя требования к проекту (содержание, работы, операции) и ограничения, заявленные спонсорами (бюджет, сроки, возможности технологий и т. д.). Следовательно, после определения основных составляющих проекта необходимо идентифицировать возможные неопределенности и либо изменить текущие ограничения, либо заложить допуски для изменения в дальнейшем. То есть в дальнейшем существует перспектива, что вследствие какого-то вероятного события придется изменить стоимость выполнения работ по проекту, привлечь больше сотрудников, или половину прогнать, а может быть проект затянется на срок в три раза дольше. И все это выяснится уже после того, как будут согласованы с заказчиками и исполнителями сроки, затраты и ресурсы.
Во-вторых, какими реальными документами можно формализовать эти действия? В Руководстве PMBOK предлагается как минимум три основных документа этой группы процессов - реестр рисков, план управления рисками и план реагирования на риски. В некотором роде это не совсем документы, их можно рассматривать в качестве управленческих сущностей, источников информации соответствующего типа. Однако, каждый из этих документов крайне спорен. Реестр рисков - это перечень идентифицированных рисков, с их характеристиками, результатами анализов: количественного и качественного, а также предварительные меры обработки этих рисков. Кто должен формировать этот документ? Не мифический менеджер команды управления рисками, а кто из участников реального проекта - заказчик, исполнитель, со-исполнители, отдельные эксперты? Кто будет заинтересован в дальнейшей привязке этих документов к реальности проекта, да так, чтобы потом можно было использовать эту информации в будущем, скажем, как часть базы знаний? План управления рисками - это документ, регламентирующий методические подходы к управлению рисками в проекте. Составлять для каждого проекта такой документ - сущее самоубийство, только если вы не строите каждую неделю по Большому адронному коллайдеру. Ну и наконец план реагирования на риски, согласно логике Руководства PMBOK, должен содержать необходимые изменения аспектов проекта для обхода рисков, выявленных или свершившихся. При этом исполнители различных работ проекта (одной или нескольких) должны ориентироваться на собственные планы и графики, игнорируя всяческие общие документы по рискам, качеству и прочим модным прибамбасам. Это нормально, это практика. Таким образом, данный документ просто содержит обоснование для изменения фундаментальных показателей проекта и соответствующих документов. Кто будет это делать, кто увидит в этом практический смысл? И насколько это допустимо в условиях реального бюджетирования, выделения времени, ресурсов и т. д.?

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