"Бухгалтерия и банки", 2007, N 2

ИНФОРМАЦИОННЫЕ РИСКИ: АНАЛИЗ И КОЛИЧЕСТВЕННАЯ ОЦЕНКА

(Окончание. Начало см. "Бухгалтерия и банки", 2007, N 1)

Оценка стоимости IT-активов и величины потерь

Для количественной оценки рисков необходимо оценивать частотность потерь и стоимость потерь (распределение величины потерь), зависящую от стоимости информационных активов банка. Но сама стоимость информационных активов банка не ограничивается стоимостью замены данных, аппаратных средств или программного обеспечения. Если для кредитного риска величина активов, находящихся под риском (Credit Exposure), очевидна, то в случае операционных рисков, включая IT-риски, ее довольно сложно определить. Помимо этого можно привести еще несколько существенных причин, затрудняющих оценку возможных потерь:

- IT-активы имеют, как правило, не одну и не две ценностные характеристики, как, например, в случае рыночного риска;

- потери могут принимать разные виды;

- реализация одного рискового события может приводить к потерям многих видов;

- между возникновением потерь различных видов существуют сложные системные взаимосвязи;

- множество факторов влияет на величину потерь.

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

Для первичной оценки можно ограничиться, как мы уже упоминали, построением карты рисков или скоринговой оценкой, которые строятся на основе экспертных шкал.

Для стоимости информационных активов это может быть, например, шкала типа:

- низкая стоимость - от актива не зависят критически важные процессы, он может быть восстановлен с небольшими затратами денег и времени;

- средняя стоимость - от актива зависит ряд важных функций процессов, актив может быть восстановлен за допустимое время, стоимость восстановления средняя;

- высокая стоимость - от актива зависят критически важные процессы, время восстановления превышает критически допустимое и (или) стоимость восстановления очень высока.

Оценив возможную частотность потерь и уязвимости, можно далее построить скоринговую матрицу, которая позволит принимать решения в отношении выбора средств для контроля за той или иной категорией IT-рисков. Достоинство методологии в том, что она позволяет довольно быстро и с точностью, зависящей от квалификации экспертов, расположить риски по приоритетам (отранжировать) и выявить те области, где незамедлительно требуется принять решение по контролю над рисками собственными силами или передать его. Однако если банк ставит целью оценку экономического капитала под информационные риски, то этого будет недостаточно, так как карты риска и скоринговая оценка не позволяют рассчитать его величину.

Используемые в документах по информационной безопасности методы оценки тоже не помогут, поскольку они оперируют только ожидаемыми потерями. Классический количественный алгоритм для оценки риска информационных потерь был разработан <*> еще в 1974 г. и используется по сей день. Согласно ему:

Asset Value x Exposure Factor x Annualized Rate of Occurrence = Annualized Loss Expectancy.

     
   ————————————————————————————————
   

<*> Guidelines for Automated Data Processing Physical Security and Risk Management, NIST FIPSPUB-65, 1974.

И если в подходе внутренней оценки (Internal Measurement Approach - IMA) Базель II, где первоначально также оценивается величина ожидаемых потерь для каждой пары "бизнес-линия - категория потерь", вводится множитель, позволяющий перевести ожидаемые потери в неожидаемые, то для информационных рисков, которые являются "смесью" многих категорий, его ввести на основе отраслевой статистики затруднительно ввиду существенного различия как в типах IT-активов, так и в бизнес-процессах. Поэтому, на наш взгляд, если банк настроен на последовательное внедрение количественной оценки величины операционного риска на основе продвинутых подходов, следует выбирать способы моделирования, которые позволяют учесть как исторические данные о потерях, так и экспертные знания.

Количественная оценка IT-рисков

В предыдущей статье мы рассмотрели основные подходы и модели для оценки операционных рисков. Какие же основные свойства сферы IT определяют способы и модели, применимые для количественной оценки IT-рисков?

Во-первых, это высокая динамичность. Технологии постоянно обновляются и становятся все более продвинутыми и сложными, автоматизируются бизнес-процессы и отдельные их участки, изменяются потоки данных, внедряются и обновляются информационные системы, модернизируется оборудование - в течение одного-двух лет информационно-технологическая среда банка существенно изменяется. Новые информационные технологии несут новый риск. С точки зрения оценки рисков это налагает ограничения на использование методов, основанных только на статистике прошлых убытков банка, поскольку соответствующая информация в базе данных операционных потерь быстро устаревает и остающейся актуальной статистической информации оказывается недостаточно для использования статистических методов. Даже если банк выполняет требования Базеля, согласно которым статистические подходы к оценке ОР должны быть основаны как минимум на 3 - 5-летней истории операционных потерь, эта база лишь отчасти поможет построить адекватную статистическую модель IT-рисков.

Во-вторых, это высокая комплексность взаимосвязей в IT-среде. Большинство технологических компонентов банка связано между собой компьютерными сетями, бизнес-процессы используют в качестве ресурсов многие IT-активы, потоки данных разных систем и разных бизнес-процессов интегрируются в аналитических и отчетных модулях. При оценке IT-рисков это выводит на первый план методы и модели, позволяющие отразить причинно-следственные связи, поскольку в полностью автоматизированной среде реализация одного фактора риска может приводить к "эффекту домино".

В свете этих особенностей идеальным для оценки IT-рисков был бы метод, позволяющий использовать разнородные по своей природе данные (экспертные оценки и численную информацию о понесенных банком убытках), а также подходящий для моделирования причинно-следственных взаимосвязей. Такой метод существует - это построение каузальных моделей оценки ОР, в частности байесовских сетей. Дополнительной мотивацией для применения банком этого подхода к оценке ОР в IT-сфере может служить также то, что он очень органично позволяет встроить в общую модель IT-риска модели нарушителей, проводить их своевременную модификацию.

Напомним, что байесовская сеть представляет собой графовую модель, в которой рисковые события и причины этих событий (факторы риска) обозначаются в виде окружностей (называемых концептами графа), а причинно-следственные взаимосвязи между ними - в виде направленных стрелок (ребер графа), соединяющих концепты. В основе методологии байесовских сетей лежит теорема Байеса, ценность которой применительно к оценке ОР заключается в ее способности комбинировать данные о вероятности событий, получаемые экспертным и статистическим путем. Для отдельных факторов риска (угроз), для которых нет статистики потерь, оценки вероятности рисковых событий могут быть основаны с использованием теоремы Байеса, только на экспертных знаниях; а для других - на статистике потерь, если объем собранных данных достаточен для целей моделирования.

Построение байесовской сети для оценки IT-рисков разумно ввиду трудоемкости данного процесса проводить для наиболее значимых факторов риска и наиболее ценных и обладающих высокой чувствительностью IT-активов банка. Источники угроз, уязвимости IT-активов банка и установленные средства контроля, взаимосвязи в IT-среде, возможные рисковые события, выявленные в процессе идентификации рисков, составляют основную часть концептов байесовской сети. Они дополняются моделями нарушителей (см. рис. 2, где, по сути, применен тот же подход, который используется для построения сети). Кроме того, в модель необходимо включить события, которые могут стать последствиями реализации риска в IT-активах банка. При реализации этих событий банк и несет основные потери, поскольку наибольший ущерб банку наносят не сами сбои IT-систем, а именно связанная с ними остановка или нарушение работы бизнес-процессов, важных для осуществления миссии банка. На этом этапе построения модели риск-менеджерам необходимо привлечь к работе не только IT-специалистов, но и менеджеров подразделений, осуществляющих основные процессы (процессы основной деятельности), вспомогательные процессы (процессы по видам обеспечения), процессы управления банком. На основе данных отчета по идентификации IT-рисков строится "скелет" сети, небольшой фрагмент которой в упрощенном виде представлен на рис. 3.

     
                                                                      ————————————¬  
                                                          ———————————>| Упущенная |  
   ——————————————¬                  ——————————————¬       |      ————>|   выгода  |
   |Периодичность|                  |Периодичность|       |      |    L————————————
   

¦ обновления ¦ ¦ проверки ¦ ¦ ¦

¦антивирусного¦ ¦ сервера ¦ ¦ ¦ ------------¬

¦ ПО +¬ -------------¬ L------T------- ------+-----¬¦--->¦ Потеря ¦

L--------------¦ ¦ Заражение ¦ ¦ ¦ Остановка +++-->¦ рабочего ¦

L->¦компьютерным¦ ¦ -->¦ расчетных +++-¬ ¦ времени ¦

     
   ——————————————¬——>|   вирусом  +¬      \|/    |  |  операций +++¬| |сотрудников|
   |   Уровень   ||  L—————————————|  —————+————¬|  L————————————|||| L————————————
   

¦ дисциплины +- L->¦Остановка+- ¦¦¦¦ ¦пользователей¦ -->¦ сервера +¬ ¦¦¦¦ ------------¬ L-------------- ¦ L----------¦ ------------¬¦¦¦L>¦ Штрафы, ¦ ¦ ¦ ¦ Нарушение +-¦¦ ¦ неустойки ¦ ¦ L->¦доступности+--¦ L---------- ———— -----------------¬ ----------¬¦ ¦ данных ¦ ¦ ¦Функционирование+-->¦Хакерская+- L------------ ¦ ------------¬ ¦ сетевого экрана¦ ¦ атака ¦ L->¦ Ущерб ¦ L----------------- L---------- ¦ репутации ¦ L---------- ————

Рис. 3

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

Для концептов, которые на графе не имеют входящих стрелок, например событий, которые являются драйверами (факторами) риска, должна быть указана абсолютная вероятность каждого из возможных исходов события. Для тех концептов, на которые влияют другие концепты, указывается условная вероятность для каждой комбинации связанных концептов. Пример экспертного задания таблицы условной вероятности показан в табл. 3.

Таблица 3

     
                     ———————————————————————————————————————————————¬
                     |               Исходы — условия               |  
   ——————————————————+——————————————————————T———————————————————————+
   |Хакерская атака  |Да                    |Нет                    |
   +—————————————————+——————————T———————————+———————————T———————————+
   |Заражение вирусом|Да        |Нет        |Да         |Нет        |
   +—————————————————+——————————+———————————+———————————+———————————+
   |         Вероятность исхода события "Остановка сервера"         |
   |                      для различных условий                     |
   +—————————————————T——————————T———————————T———————————T———————————+
   |Произойдет       |    0,3   |    0,15   |    0,10   |    0,02   |
   +—————————————————+——————————+———————————+———————————+———————————+
   |Не произойдет    |    0,7   |    0,85   |    0,90   |    0,98   |
   L—————————————————+——————————+———————————+———————————+————————————
   

Затем с помощью теоремы Байеса составляется композиция указанного экспертами распределения с распределением, построенным на основе фактических данных. Полученное распределение-композиция принимается для дальнейших расчетов по сети как наиболее точно описывающее поведение концепта. Из таблицы условной вероятности (как видно из табл. 3) не вполне очевидно, с какой частотой будет происходить остановка сервера. Чтобы провести количественную оценку, необходимо вычислить абсолютные вероятности реализации этого события. Для этого применяется формула условной вероятности, позволяющая провести расчет на основе заданных условных вероятностей и известных вероятностей реализации событий (причин) рассматриваемого события. Таким образом, последовательно продвигаясь по сети и применяя теорему Байеса в связке с формулой условной вероятности, можно вычислить вероятность каждого исхода для каждого рискового события. Осталось определить для каждого события еще одну характеристику - величину возможных потерь от его реализации, которая может определяться на основе статистики, экспертно, по данным других организаций с учетом эффекта масштаба. При оценке этого параметра задача существенно облегчается, если концепты определены верно, т.е. присутствуют все необходимые типы потерь и нет лишних. Классификация типов последствий может быть составлена с различных точек зрения, при построении графа полезно рассматривать два взаимосвязанных уровня классификации. Так, на первом уровне классификации можно разделять последствия с точки зрения изменений в технологических и информационных активах. Для информационных активов традиционно приняты три категории последствий - нарушение целостности, доступности, конфиденциальности, а для материальных активов ущерб определяется по шкале - от полной утраты актива до сбоя (остановки, неполадки) на несущественный промежуток времени. Возможна балльная оценка. В качестве второго уровня классификации возможных потерь могут рассматриваться: упущенная выгода; штрафы, пени, неустойки; потеря рабочего времени сотрудников, снижение производительности труда; потеря репутации и др.

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

Когда построение байесовской сети закончено, ее можно использовать для оценки риска в различных разрезах. Если требуется оценить совокупный риск какого-либо IT-актива, например информационной системы, то можно произвести суммирование распределений потерь по нескольким рисковым событиям, потенциально способным реализоваться в этой системе. Суммирование распределений потерь по отдельным рисковым событиям, кроме того, необходимо для определения ожидаемых и неожидаемых потерь, получаемых на основе расчета математического ожидания и VaR - агрегированного распределения IT-риска банка. Такое суммирование по байесовской сети проводится, как правило, с помощью Монте-Карло-симуляции, которая заключается в имитации случайного возникновения различных исходов событий - драйверов, которые подаются на входы сети. Существует и другой аналитический подход к суммированию распределений, однако его применение затруднено из-за высокой трудоемкости.

В целом, как видно даже из краткого описания методики построения байесовской сети, это достаточно трудоемкий процесс, поэтому его лучше проводить с помощью специально разработанных программных средств. Их использование, по различным оценкам, позволяет сократить временные затраты на оценку риска в 5 - 10 раз. Оценка риска завершается выработкой предложений по техническим, технологическим, организационным средствам контроля риска, направленным на его минимизацию.

Снижение IT-рисков

Поскольку снижение IT-рисков сопряжено с затратами, при рассмотрении возможных действий по снижению риска необходимо разработать различные варианты средств минимизации для каждой единицы портфеля рисков, оценить потенциальный эффект от их внедрения (например, используя сценарный анализ в построенной байесовской сети) и стоимость этого внедрения, т.е. провести анализ "издержки - выгода" (cost-benefit analysis). Выработать реалистичный и эффективный план снижения IT-рисков можно путем комплексного анализа структуры портфеля IT-рисков банка и сравнения возможных действий, направленных на снижение риска, между собой по ряду значимых характеристик. В этом смысле разработка такого плана является типичным примером многомерной управленческой задачи выбора, которую разумнее всего решать в рамках поэтапного процесса, по своей сути схожего с методологией дерева решений.

Группы возможных методов снижения риска для каждой единицы портфеля IT-рисков стандартные для риск-менеджмента.

- Принятие риска. Банк признает потенциальные потери приемлемыми для себя и не реализует специальные меры по снижению риска.

- Избежание риска. Банк принимает решение, направленное на удаление данной единицы риска из портфеля IT-рисков, в частности, устраняя причину соответствующей угрозы (например, отказывается от использования установленного ПО, существенно нарушающего требования информационной безопасности).

- Ограничение риска. Банк внедряет специальные средства контроля, снижающие вероятность реализации угрозы IT-активам и (или) уменьшающие последствия этой реализации.

- Передача риска. Банк создает условия для компенсации потенциальных потерь путем передачи риска третьему лицу, например, используя страхование или отдавая отдельные функции на аутсорсинг.

Указанные способы не являются взаимоисключающими и часто применяются в комплексе. Основная цель ограничения риска - это его снижение до приемлемого для банка уровня, но поскольку риск при этом не устраняется полностью, то его часть, оставшаяся после ограничения, должна быть принята банком. При выборе мер воздействия на каждую единицу портфеля рисков необходимо разделить все выявленные IT-риски на подконтрольные и неподконтрольные банку. Эта характеристика, по сути, разбивает портфель IT-рисков на два субпортфеля с различным составом возможных методов снижения рисков. Так, банк не может воздействовать на неподконтрольные ему риски (такие, как природные угрозы и некоторые угрозы технологической среды), и, следовательно, он может либо принять их, либо передать путем страхования. Для субпортфеля подконтрольных IT-рисков применимы все из описанных методов воздействия на риск, но для этого субпортфеля. Если мы далее сравним денежную оценку каждого элемента портфеля рисков с порогом принятия риска, определяемым на основе "аппетита на риск", установленного высшим руководством и акционерами банка, то это позволит нам выделить еще один субпортфель - субпортфель приемлемого риска. Для каждой единицы этого субпортфеля величина потенциальных потерь не превосходит порог принятия риска, поэтому эти риски могут быть полностью приняты банком. Хотя банк может пожелать еще больше снизить риски из этого субпортфеля в силу существующих ограничений по ресурсам, до этого доходит чрезвычайно редко, поскольку в первую очередь средства из бюджета разумно направлять на самые значимые для банка риски.

Таким образом, область анализа после первых двух этапов сузилась до одного субпортфеля подконтрольных, но неприемлемых для банка рисков, которые следует минимизировать наиболее подходящими средствами контроля. Необходимым шагом, предшествующим ранжированию средств контроля, является составление списков инструментов контроля (ограничения) риска для каждой единицы субпортфеля. Средства контроля делятся на три категории по применяемым в их рамках методам воздействия на источник риска:

- организационные (управленческие) средства подразумевают создание надежной и безопасной системы управления IT-рисками (разделение ответственности за обеспечение безопасности IT-активов, управление мероприятиями по оценке и снижению рисков, обеспечение правильной подготовки пользователей IT-систем, создание механизмов реагирования в экстренных ситуациях и т.п.);

- технические средства заключаются в использовании автоматизированных механизмов контроля безопасности IT-активов (например, использование криптографической защиты информации, защищенных каналов связи, программных методов аутентификации и авторизации, антивирусной защиты);

- технологические (операционные) средства помогают обеспечить и контролировать непрерывность функционирования IT-активов банка (например, контроль физического доступа к оборудованию, архивирование и резервное копирование информации, защита от пожаров, обеспечение бесперебойного энергоснабжения и т.п.).

Все эти средства довольно подробно описаны в Стандарте ИБ, причем там указаны и инструменты, наиболее подходящие для различных процессов, поэтому мы не будем останавливаться на их описании. Подчеркнем важную особенность Стандарта ИБ, который делает акцент на корпоративном управлении и корпоративной этике как важном элементе соблюдения политики информационной безопасности. Установленные стандарты корпоративного управления, основанные на лучших практиках, очень существенны в решении проблемы инсайдеров, которые рассматриваются как основные источники угроз и уязвимостей информационной безопасности. Предотвращение конфликтов интересов, разделение полномочий и ролей, недопущение наделения суперполномочиями, контроль над обращением конфиденциальной информации - все эти организационные средства, значимые для любых видов операционного риска, приобретают исключительное значение для IT-рисков ввиду их взаимосвязи практически со всеми бизнес-процессами банка.

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

Новые риски возникают не только при ограничении IT-риска, но и при передаче его путем аутсорсинга. Возрастающие объемы функций, которые западные финансовые институты передают в аутсорсинг, заставили Базельский комитет <**> обратить пристальное внимание на эту проблему. Понятно, что передача какой-то функции на аутсорсинг редко служит цели только минимизации IT-риска, но обычно включает и эту цель. Например, у европейских банков на первых двух местах находятся мотивы, связанные со снижением совокупной стоимости владения данной функцией и доступ к новым технологиям. Базельский комитет указывает, что наряду с выгодами, которые приобретаются при передаче функций на аутсорсинг, следует эффективно управлять возникающими при этом рисками. Укажем некоторые из них, связанные с IT-сферой. К группе стратегических рисков, например, относится риск того, что финансовый институт не обладает достаточным опытом и знаниями, чтобы осуществлять адекватный надзор за сервис-провайдером. Возможные технологические сбои, мошенничество и ошибки, отказ от обслуживания, нарушение конфиденциальности - вот неполный список угроз, которые следует, по мнению Базеля, рассматривать в связи с аутсорсингом.

     
   ————————————————————————————————
   

<**> Outsourcing in Financial Services, Basel, Switzerland, February 2005.

Особенности IT-рисков требуют, чтобы защитные меры осуществлялись непрерывно, регулярно проверялись на адекватность угрозам, связанные с применением мер снижения риски учитывались в профиле риска банка. Актуализация информации о факторах риска, оценка риска и обновление (разработка) комплекса мероприятий по его минимизации должны проводиться с определенной периодичностью, зафиксированной во внутренних документах банка. Мониторинг уровня IT-риска, например, по ключевым показателям риска разумнее поручать специалистам, которые не являются сотрудниками информационно-технологических служб банка, поскольку они смогут обеспечить объективную оценку и анализ. Лучшие практики свидетельствуют, что ключевыми факторами успеха в процессе реализации программы снижения рисков является поддержка высшего руководства банка, наличие документально оформленных процедур всех этапов управления IT-рисками, четкое распределение ответственности за внедрение каждого средства контроля, тестирование внедряемых и уже внедренных контрольных инструментов.

Планирование на случай непредвиденных обстоятельств

Мы обошли в предыдущих разделах вопрос о минимизации последствий реализации риска. Этот вопрос особенно важен в отношении рисков, которые нельзя устранить, ограничить или передать, но они представляют чрезвычайную опасность для банка. Поскольку внедрение большинства средств контроля не позволяет свести риск к абсолютному нулю, а для отдельных единиц портфеля рисков их применение невозможно, определенная часть IT-риска, сохраняющаяся после принятия мер по снижению, принимается банком. Эту часть принято обозначать термином "остаточный риск", который является разностью между всем присущим банку IT-риском и его контролируемой частью. Таким образом, вероятность и величина потерь от реализации факторов остаточного риска не контролируется банком, а значит, банк не защищен от его возможных проявлений. Такого рода чрезвычайные риски выявляются посредством процедур стресс-тестирования, которые основываются, как правило, на экспертных знаниях специалистов банка (либо привлеченных экспертов, консультантов). Некоторые банковские специалисты, занимающиеся вопросами риск-менеджмента, рассматривают анализ чувствительности и стресс-тестирование как аналогичные процедуры. Однако процедура анализа чувствительности не позволяет учесть ни одновременное действие нескольких факторов риска, ни чрезвычайно сильные отклонения, ни взаимоусиление факторов и последствий, а также широкое распространение последствий реализации даже одного фактора. Поскольку очень редкие, но несущие высокие потенциальные потери события даже в рамках отрасли происходят нечасто, провести количественное моделирование из-за недостатка данных затруднительно. Уровень надежности качественного анализа напрямую будет зависеть от знаний и опыта экспертов.

Устранить или существенно снизить такие чрезвычайные риски нельзя, но можно минимизировать их последствия с тем, чтобы даже в этих чрезвычайных условиях банк продолжил обслуживание клиентов, быстро восстановил нормальный режим работы. Это делается путем разработки плана действий на случай непредвиденных обстоятельств (contingency plan). При этом план действий в области IT должен быть составной частью комплексного общебанковского плана обеспечения непрерывности деятельности, поскольку в стрессовых ситуациях одновременно проявляются многие виды банковских рисков, такие как стратегический риск, риск ликвидности, репутационный риск, прочие категории операционного риска.

План действий на случай непредвиденных обстоятельств в области IT, чтобы быть эффективным, должен как минимум содержать следующие разделы:

- политика банка в области планирования действий в кризисных ситуациях в сфере IT, в которой формализованно выражаются цели и задачи плана и определяется общий порядок функционирования банка в кризисных ситуациях: структура управления и разделения полномочий и ответственности (которая может отличаться от "штатной" управленческой структуры), порядок выделения необходимых финансовых и людских ресурсов и т.д. В этом разделе также определяется порядок перехода банка в кризисный режим работы и обратно, регламентируются общие подходы к соответствующему обучению персонала, тестированию плана и его периодическому обновлению;

- описание состава кризисных ситуаций (сценариев), для борьбы с возможными последствиями которых был разработан план;

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

- состав задач, которые необходимо решить в случае возникновения каждой конкретной кризисной ситуации, если, несмотря на превентивные меры, возникновение этой ситуации нанесло или может нанести значительный ущерб ("что нужно сделать");

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

Как свидетельствуют лучшие практики <***>, при разработке плана следует особое внимание уделить процедурным вопросам, связанным с распределением ответственности, определением оптимальной последовательности решения задач. Применительно к IT эти задачи, как правило, заключаются в восстановлении нормального функционирования различных информационных систем, оборудования, восстановлении целостности и доступности ключевых данных. Эта специфика IT-рисков существенно облегчает расстановку приоритетов в задачах плана - последовательность выполнения задач определяется сравнительной критичностью элементов IT-инфраструктуры, функционирование которых нарушено. При этом порядок действий персонала разумно разбивать на три этапа:

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

- восстановительный этап предусматривает выполнение прописанных в плане работ, направленных на восстановление нормальной работы IT-среды банка;

- этап финализации предусматривает выполнение заключительных работ, таких как восстановление всей информации с резервных носителей, тестирование восстановленных систем, информирование служащих о возврате к обычному порядку работы.

     
   ————————————————————————————————
   

<***> High-level Principles for Business Continuity, Basel, Switzerland, August 2006. Поскольку наступление кризисных ситуаций практически невозможно прогнозировать, план действий в случае непредвиденных обстоятельств должен быть готов к использованию каждый день. Это предусматривает периодический пересмотр и обновление плана (на предмет актуальности информации о структуре IT-среды и организационной структуры банка, полноты состава рассматриваемых рисков и т.д.), а также его тестирование (проведение "учебных тревог"). Важную роль играет обучение персонала - каждый сотрудник должен знать порядок своих действий в кризисной ситуации и местоположение всех необходимых ресурсов. * * * В заключение еще раз хотелось бы подчеркнуть, что управление информационной безопасностью кредитной организации, особенно в части идентификации, оценки и мониторинга IT-риска, следует проводить в рамках управления операционными рисками. Учитывая, что Россия намерена уже в 2009 г. присоединиться к соглашению Базель II по капиталу, согласно которому банки должны соблюдать требования к достаточности собственных средств с учетом как кредитных и рыночных рисков, так и операционных рисков, времени осталось не так уж и много. А с точки зрения минимизации IT-риска внедрение Стандарта ИБ, который сейчас имеет рекомендательный характер, позволит улучшить контрольную среду банка, снизив таким образом долю невыявленного риска и остаточного риска. Соответственно, снизятся затраты банка на ожидаемые потери, а также требования к капиталу под операционный риск. Что касается достаточности капитала, которая в условиях растущего рынка становится больным вопросом для многих, особенно крупных и средних банков, не позволяя им расти далее с достигнутыми темпами, вопрос заключается еще и в том, разрешит ли российский регулятор рассчитывать требования к регуляторному капиталу на основе продвинутых подходов или остановится на уровне стандартизованного подхода. В.Зинкевич Руководитель отдела консалтинга компании "Франклин & Грант. Финансы и аналитика" Д.Штатов Консультант компании "Франклин & Грант. Финансы и аналитика" Подписано в печать 22.01.2007 ————