8.1. Требования к информационной системе управления рисками
При желании можно найти программные пакеты, реализующие те или иные средства управления рисками. Гораздо сложнее подобрать комплексную систему управления рисками, которая бы специализировалась на области информационных технологий и могла отслеживать риски проекта и контролировать проект.
При выборе систем следует учитывать широту охвата основных процессов управления рисками: идентификации рисков, оценки (качественной и количественной), выбора методов реагирования, мониторинга и контроля противорисковых мероприятий. Следует обратить особое внимание на функциональность обновления величин рисков, мониторинга эффективности используемых способов управления и способов управления остаточными рисками (например, перерасчет максимально допустимых величин рисков; процесс реагирования на инциденты и прочее), качества процесса реагирования на риски. Иногда инструмент оценки ИТ-рисков программных проектов позволяет отследить связи между выявленными рисками и причинами, которые ведут к ним, что является преимуществом выбранного решения.
Критериями выбора системы могут выступать следующие категории требований:
• информация о поставщике и продукте;
• функциональные требования;
• технические требования;
• цены и условия.
Информация о поставщике и продукте содержит контактную информацию о поставщике, опыт работы и финансовые показатели. Также в информации о поставщике, как правило, приведены масштабы деятельности, географический охват и направления деятельности компании-поставщика, его стратегические партнеры. С помощью такой информации можно оценить репутацию компании, успешный опыт по внедрению подобных систем, стаж пребывания компании на рынке, число продаж. Интересной информацией может быть количество работающих систем в России и отзывы пользователей/компаний, на которые поставщик услуг может предоставить ссылку.
Функциональные требования содержат требования к функциональности системы управления рисками в сфере ИТ. Функциональные требования включают также описания возможности настройки данной функциональности в системе (например, возможность настраивать поля, формулы, оформление графиков, шаблонов отчетов). Иногда в функциональные требования входят перспективы развития системы с учетом стратегических планов развития бизнеса. Поэтому в функциональных требованиях может рассматриваться либо только основная функциональность, либо основная и дополнительная – требуемая для будущего развития.
Дополнительно может изучаться вопрос о стратегии внедрения: насколько быстро осуществляется внедрение основной функциональности и какова возможность последующего расширения функциональности и интеграции с другими системами.
Могут существовать критерии, связанные с внутренней политикой компании, такие, например, как стратегия развития системы и соответствие общей стратегии развития бизнеса и общему плану внедрения. При необходимости анализируются возможности соответствия ПО политикам внутренней службы безопасности компании-заказчика.
Технические требования содержат критерии по техническим требованиям к аппаратному и программному обеспечению, описание конфигурации, необходимой для полнофункциональной работы информационной системы управления рисками. В состав технических требований, как правило, включены:
• технологичность решения;
• терминология и качество локализации системы;
• модульность;
• гибкость;
• масштабируемость;
• архитектура и техническая платформа;
• операционная среда и СУБД.
Цены и условия содержат оценку стоимости покупки (лицензии), внедрения и поддержки системы управления рисками с учетом приведенного примера количества пользователей.
Дополнительно могут использоваться бизнес-сценарии, описывающие бизнес-задачу и предлагающие разработчику программного решения оптимальное решение по реализации поставленной задачи. Сценарии конкретных ситуаций разработаны для того, чтобы оценить способность поставщика предоставить прямые решения задач, описанных в сценариях, либо альтернативные решения. Излишней детализации и использования реальных данных на данном этапе не требуется, поскольку это будет темой отдельных демонстраций. Поставщики должны показать логику выполнения данных требований, какие модули или функциональные области системы будут задействованы. Ответы на задачи, представленные в сценариях, должны содержать подробное описание возможности решения предложенных проблем в системе управления рисками.
Для каждой группы критериев (общие, функциональные, технические требования) определяются шкала оценок и относительная значимость критериев (рис. 25).
Рис. 25. Пример портфеля критериев по выбору программного продукта
Также при выборе системы огромную роль играет стоимость системы, при которой оцениваются как разовые инвестиции, так и расходы на последующую поддержку системы. Сильное впечатление на заказчиков системы производят результаты демонстраций систем. Важными критериями являются удобство интерфейса и настройки, а также профессионализм сотрудников компании – поставщика ПО.
Веса группы критериев расставляются в зависимости от потребностей и приоритетов ИТ-проекта. Например, при более сложной функциональности программного продукта по управлению рисками увеличивается вес функциональных требований, в то время как вес технических требований может увеличиваться при необходимости интегрировать ПО управления рисками в существующую сложную ИТ-инфраструктуру компании, жестких политиках безопасности.
Для каждой группы показателей (общие, функциональные, технические требования, бизнес-сценарии) определяются шкала оценок и относительная значимость критериев.
На верхнем уровне детализации веса определяются путем экспертной оценки (табл. 8).
Таблица 8.
Пример распределения доли критериев
Требования могут отличаться по значимости и ранжироваться по приоритетности на три группы: «Критично», «Важно», «Желательно» (табл. 9). На основе этого каждому требованию присваивается вес в общей оценке (табл. 12). Для определения весов для оценки требований необходимо согласовать их приоритетность. Наименьший вес принимается за единицу, следующая категория присваивается группе критериев с условно в два раза большей значимостью и т. д. Веса рассчитываются на основе единиц относительной значимости. Сумма весов должна быть равна 100 %.
Таблица 9.
Приоритеты требований
После формулировки критериев начинается выбор системы управления рисками, чтобы автоматизировать все рутинные процессы управления рисками, для предотвращения рисковых событий за счет имеющихся баз данных рисков и последствий, снижения возможных убытков и расходов по их нейтрализации.
Среди функциональных критериев по выбору системы управления ИТ-рисками могут быть следующие:
• хранение данных в справочниках: риски, рисковые события, бизнес-процессы, классификаторы, статусы рисков;
• ведение единого реестра рисков;
• использование иерархии классификации;
• формирование отчетов и графических форм;
• открытость системы для дальнейшего развития и интеграции с другим ПО;
• разделение прав доступа к хранимой информации о рисках, рисковых событиях на основе ролевого подхода;
• механизм автоматической генерации уведомлений по электронной почте;
• возможность внесения изменений в систему с учетом пожеланий заказчика.
Могут существовать функциональные требования для связывания рисков и рисковых событий, факторов риска и бизнес-процессов.
Общие требования к сбору данных о рисках могут содержать пожелания к ведению стадий жизненного цикла обработки рисков. Это осуществляется за счет разделения доступа к информации о рисках в зависимости от подразделения, к которому относится пользователь, различного состава обязательных для заполнения полей на разных стадиях жизненного цикла, учета распределения ответственности за обработку рисков в подразделении по управлению рисками, прикрепления вложенных файлов с описанием риска, возможности построения отчетов по истории жизненного цикла риска.
Для функционирования этапов управления рисками, отчетов и аналитики разрабатываются справочники, способные обеспечить взаимосвязь данных разных справочников для упрощения работы по этапам управления рисками, единую модель метаданных, иерархическую структуру данных, управление нормативно-справочной информацией, интеграцию с внешними базами и хранилищами данных.
Автоматизация процесса управления рисками подразумевает выполнение многочисленных функций, таких как поддержка количественной и качественной оценок рисков, четкое и своевременное измерение рисков, развитая аналитическая информация о рисках. Как правило, стандартная функциональность программных продуктов по управлению рисками содержит реестр рисков, позволяющий осуществлять хранение истории присвоения риску качественных оценок и присвоение риску множественных значений классификаторов (бизнес-процессы, типы рисковых событий). Также практически во всех системах присутствуют ключевые индикаторы риска, которые дают возможность выполнять фильтрацию и сортировку индикаторов риска в зависимости от текущего состояния (в зоне риска, вне зоны риска). Оценка риска происходит за счет ведения статусов заполнения опросных листов, импорта заполненных опросных листов из внешних систем, конвертации результатов опроса в оценку риска.
Вне зависимости от выбранного типа решения программный продукт по управлению рисками в ИТ-проекте должен отвечать сформулированным требованиям и выполнять основные задачи управления рисками за счет:
• функций системного автоматизированного подхода в области управления рисками ИТ-проекта;
• механизмов анализа рисков с применением современных статистико-математических методов;
• функций контроля выполнения мероприятий по минимизации рисков и расчету экономического эффекта;
• механизмов автоматического мониторинга эффективности системы управления рисками;
• реализации сводной аналитической отчетности по управлению рисками в режиме реального времени.
Хорошо структурированные критерии выбора решений по управлению рисками и наличие программы внедрения уменьшают вероятность приобретения продуктов, становящихся «мертвым грузом», мешающим развитию общей информационной системы компании. Кроме непосредственно выбора решений, также должно учитываться качество предоставляемых поставщиками сервисных и обучающих услуг.
8.2. Сравнение коробочного и собственного ПО управления рисками
Построение собственной системы управления ИТ-рисками является более сложной задачей, чем выбор существующего пакетного решения, и требует не только хороших теоретических знаний в области методологии управления рисками, но и практического опыта внедрения. Следует заранее предпринять действия, чтобы не допустить типичных ошибок, которые состоят в отсутствии доверия к полученным результатам оценки ИТ-рисков со стороны руководства, недостаточной обоснованности расходов на снижение рисков, а также в сопротивлении внедрению мер снижения рисков в функциональных подразделениях и технических службах.
При выборе следует обратить внимание на три фактора: сроки внедрения, качество внедрения, стоимость внедрения.
Собственная разработка, в отличие от готового коробочного решения, предполагает самостоятельную разработку технической архитектуры и спецификаций в соответствии с функциональными и техническими требованиями в системе, самостоятельное планирование и управление процессами на всех стадиях разработки, самостоятельное тестирование, отладку и запуск системы в эксплуатацию. Также придется взять на себя обучение пользователей и формирование комплекта документации.
Часть функций можно передать сторонним разработчикам и выполнить заказную разработку решения по управлению рисками (табл. 10).
Таблица 10.
Критерии выбора заказного/готового программного продукта
Передача части функций сторонним разработчикам позволит компании, для которой разработка программного обеспечения не является основной деятельностью, заручиться поддержкой специалистов и обеспечить приемлемый уровень качества программного продукта.
К преимуществам собственной/заказной разработки можно отнести тот факт, что разработка ведется с учетом конкретных целей и особенностей бизнеса заказчика в точном соответствии с функциональными и техническими требованиями. Также привлекает сравнительно низкая стоимость разработки программного обеспечения по сравнению с «пакетным решением». Очевидны преимущества в реализации корпоративной стратегии за счет уникального и адаптированного к бизнесу решения. Также для заказной разработки характерна возможность выполнения пользовательских настроек на любом уровне программного решения.
Существенным недостатком является то, что разработанная система может не в полной мере отвечать специфике бизнеса из-за отсутствия опыта разработки подобных систем в той же индустрии. Необходимы значительные усилия со стороны заказчика в части предоставления данных, формулировки требований и написания технических заданий. Длительные сроки внедрения и необходимость контроля над процессом разработки и внедрения могут оказаться неблагоприятным фактором при выборе программного решения. Тестирование системы может быть осуществлено не в полной мере в связи с отсутствием подобного опыта. Характерны ограниченные возможности расширения и изменения функциональности.
При принятии решения об использовании пакетного (готового) решения в области управления рисками программных проектов также существуют существенные ограничения. Это и необходимость придерживаться шаблонных процессов, и сложность интеграции с существующими приложениями в случае нестандартной базовой ИТ. Также возможны трудности с самостоятельным выбором подходящего поставщика и формированием объективных критериев. Существует возможность избыточной функциональности и неудобства программного интерфейса. Очень часто необходимо выполнять пользовательские настройки и решать проблемы локализации (для западных продуктов).
Но не надо забывать о преимуществах, к которым относится большой опыт внедрения компаний-поставщиков в подобной отрасли и наличие положительных отзывов от существующих клиентов, соответствие общим тенденциям и требованиям рынка, меньшее число вовлеченных специалистов и отрыв от непосредственных обязанностей сотрудников, контрактные обязательства по выполнению услуг по разработке системы.
При выборе готового решения происходит существенная экономия времени на фазах планирования и дизайна системы, ее тестировании и вводе в эксплуатацию. Вместо этого возможны быстрая настройка системы, запуск и начало эксплуатации. Также пользователю представится возможность использования лучшей практики автоматизации управления рисками и применения широкого спектра статистических и математических методов. При этом стоимость проекта может оказаться гораздо ниже, по сравнению с собственной разработкой или заказной разработкой.
Процесс выбора поставщика программного решения по управлению рисками, как правило, происходит в соответствии с основными этапами: обзор рынка, формирование требований к системе и подготовка информационного запроса поставщикам (при необходимости), рассылка информационного запроса и анализ ответов поставщиков программного обеспечения, выбор системы (рис. 26).
На начальном этапе происходят определение требований к системе управления рисками, согласование требований внутри проектной команды. Далее происходят анализ рынка решений и предварительный просмотр систем, где определяются наличие требуемой функциональности, опыт внедрения, отзывы от предыдущих аналогичных проектов. На основе предварительного просмотра систем происходит выбор сокращенного списка поставщиков. Далее осуществляется более детальный анализ на соответствие функциональным, техническим и прочим требованиям на основе взвешенной модели оценки. Если поставщикам рассылался запрос на предоставление информации (Request for Information – RFI), проводится качественный анализ ответов. Вместе с анализом ответов составляются сценарии показа систем на соответствие требованиям. Демонстрации систем оцениваются с помощью балльной оценки, основанной на анализе сильных и слабых сторон продукта, впечатления от поставщика решения. По окончании анализа поставщиков на соответствие требованиям и демонстрации системы формируется решение по выбору поставщика системы управления рисками. После заключения контракта происходит внедрение выбранного решения.
Рис. 26. Этапы отбора поставщиков ПО
До принятия решения о внедрении той или иной системы управления ИТ-рисками программных проектов следует убедиться, что она достаточно полно учитывает бизнес-потребности компании, ее масштабы, а также соответствует лучшим мировым практикам и имеет достаточно подробное описание процессов и требуемых действий.
8.3. Обзор ПО: преимущества и недостатки
В настоящее время существует большое количество систем, так или иначе реализующих функции управления рисками. Некоторые из них представляют собой информационные системы управления проектами, в которых присутствует модуль управления рисками, другие являются приложениями к системам календарного планирования либо самостоятельными программными продуктами по управлению рисками. Третьи специализируются на рисках информационной безопасности, а потому позволяют определить не уровень рисков программных проектов, а степень соответствия тому или иному стандарту (например, ISO17799).
В качестве продукта поддержки процессов управления рисками при реализации программных проектов может использоваться как специализированная система, так и модули управления рисками многофункциональных систем управления проектами (Microsoft Project, Open Plan, Primavera) или же модули системы управления предприятием (Oracle, SAP, Microsoft Axapta и прочие). Как было описано выше, возможно создание собственной разработки в области управления рисками программных проектов.
В зависимости от типов рисков выделяют различные системы управления рисками. Ниже представлена классификация ПО в области управления рисками, содержащая наиболее распространенные в России программные продукты.
1. Управление операционными/банковскими рисками на уровне всего предприятия реализовано в программных продуктах Egar Technology, SAS, IBM, прочих.
2. Поддержка рисков информационной безопасности (с привязкой к существующим стандартам, например ISO 17799) отражена в решениях Cramm, RiskWatch, Кондор+, Cobra, прочих.
3. Для управления рисками проектов (как один из инструментов Project Management Software) используются системы Primavera Project Planning, Spider Project, Open Plan, прочие.
4. Управление рисками программных проектов (на основе методологий разработки ПО) реализовано практически всеми крупными разработчиками программного обеспечения, наиболее известны продукты IBM Rational Portfolio Manager, OCTAVE-S.
Рис. 27. Рейтинг систем управления рисками, Standish Group Report, 2009 (RiskTech100TM)
Помимо перечисленных систем, на российском рынке также присутствуют такие многофункциональные системы в области управления рисками, как: @Risk Professional for Project, Dekker TRAKKER, Enterprise project, ER Project 1000, Intelligent Planner, Mesa/Vista Risk Manager, Risk Track, Open Plan. ERA by Methodware, NetRisk/RiskOps 2.3, Pacemetrics. Обзор наиболее популярных западных систем представлен на рис. 27.
Проведем более детальный анализ основных программных продуктов по управлению рисками, отвечающих специфике ИТ-проектов.
1. IBM Rational Portfolio Manager (IBM). Система полностью поддерживает методологию COBИТ и предоставляет инфраструктуру для введения элементов управления, которые помогут обеспечить соответствие законодательным нормативам, таким как закон Сарбейнса-Оксли и соглашение Basel II, и устранить разрыв между потребностями управления, техническими проблемами, бизнес-рисками и требованиями показателей производительности и реализацией инструментов финансового контроля.
По данным компании IBM, Portfolio Manager осуществляет поддержку процессов идентификации и контроля рисков, позволяет выявить и уменьшить самые высокие воздействия рисков путем задания пользовательского триггера, который уведомит вас о возникновении риска. Можно предоставить показатели, которые уведомят о том, например, насколько хорошо выполняется снижение риска, с периодической фиксацией количества событий триггера, интенсивности событий триггера, того, сколько времени ушло на разрешение события и какой уровень эскалации потребовался.
2. OCTAVE-S – Operationally Critical Threat, Asset and Vulnerability Evaluation System (SEI). Система OCTAVE-S разработана институтом Software Engineering Institute (SEI) при университете Карнеги Меллон для моделирования поведения оценки рисков в организации. OCTAVE спроектирована на основе методологии информационной безопасности и предусматривает высокую степень гибкости, достигаемую путем выбора критериев, которые предприятие может использовать при адаптации под собственные нужды, и позволяет поддерживать следующие процессы управления рисками:
• идентификацию критичных информационных активов;
• идентификацию угроз для критичных информационных активов;
• определение уязвимостей, ассоциированных с критичными информационными активами;
• оценку рисков, связанных с критичными информационными активами.
Особенность данной методики заключается в том, что весь процесс анализа производится силами сотрудников организации, без привлечения внешних консультантов. Для этого создается смешанная группа, включающая как технических специалистов, так и руководителей разного уровня, что позволяет всесторонне оценить последствия возможных инцидентов и разработать контрмеры. В качестве инструмента моделирования и оценки OCTAVE предлагает при описании профиля использовать «деревья вариантов». В доступной базе данных рассматриваются компоненты следующих классов: серверы; сетевое оборудование; СЗИ; персональные компьютеры; домашние персональные компьютеры «надомных» пользователей, работающих удаленно, но имеющих доступ в сеть организации; мобильные компьютеры; системы хранения; беспроводные устройства и связанные с ними риски.
Вся документация по OCTAVE общедоступна и бесплатна, что делает методику особенно привлекательной для предприятий с жестко ограниченным бюджетом.
3. Risk Watch (RiskWatch, Inc). Компания RiskWatch разработала собственную методику анализа рисков и семейство программных средств, в том числе для информационных рисков ИТ-проектов (RiskWatch for Information Systems), и является мощным средством анализа и управления рисками. Программное обеспечение охватывает физические методы защиты ИС, а также информационные риски и служит для оценки требованиям стандарта ISO 17799. В семейство RiskWatch входят программные продукты для проведения различных видов аудита безопасности, которые позволяют вводить в модель системы безопасности новые категории, описания, а также получать качественные и количественные ответы на вопросы безопасности, исходя из данных в системе.
В качестве критериев для оценки и управления рисками используются «предсказание годовых потерь» (Annual Loss Expectancy – ALE) и оценка «возврата от инвестиций» (Return on Investment – ROI). В части оценки рисков система дает возможность устанавливать связи между ресурсами, потерями, угрозами и уязвимостями, рассчитывать математические ожидания потерь с учетом частоты возникновения угрозы риска и стоимость ресурса, который подвергается риску. Дополнительно рассматриваются сценарии «что, если», которые позволяют описать аналогичные ситуации при условии внедрения средств защиты.
Для выявления возможных уязвимостей используется вопросник, база которого содержит более 600 вопросов, связанных с категориями ресурсов. Также задаются частота возникновения каждой из выделенных угроз, степень уязвимости и ценность ресурсов. Для многих видов угроз в системе есть среднегодовые оценки возникновения, которые используются в дальнейшем для расчета эффекта от внедрения средств защиты.
Risk Watch позволяет оценить не только те риски, которые сейчас существуют у предприятия, но и ту выгоду, которую может принести внедрение физических, технических, программных и прочих средств и механизмов защиты. Подготовленные отчеты и графики дают материал, достаточный для принятия решений об изменении информационной системы предприятия.
4. CRAMM (CCTA Risk Analysis and Management Method – CCTA UK). Система CRAMM создана на основе методологии управления рисками CRAMM и предполагает использование технологий оценки угроз и уязвимостей по косвенным факторам с возможностью проверки результатов. В основе метода CRAMM лежит комплексный подход к оценке рисков, сочетающий количественные и качественные методы анализа. В модель оценки заложен механизм моделирования информационных систем с позиции безопасности с помощью обширной базы данных по контрмерам. Для каждой группы ресурсов и каждого из 36 типов угроз/уязвимостей генерируется список вопросов, допускающих однозначный ответ. Уровень угроз и уязвимостей оценивается, в зависимости от ответов, как очень высокий, высокий, средний, низкий и очень низкий. Далее CRAMM объединяет угрозы и уязвимости в матрице риска. Система нацелена на детальную оценку рисков и эффективности предполагаемых к использованию комбинаций методов управления рисками. Помимо анализа рисков, CRAMM позволяет решать ряд параллельных задач, включая:
• проведение обследования используемой/внедряемой ИТ и выпуск сопроводительной документации на всех этапах его проведения;
• проведение аудита на основе стандарта безопасности информации BS 7799:1995;
• разработку политики безопасности и плана обеспечения непрерывности бизнеса.
CRAMM является универсальным методом и подходит как для крупных, так и для малых организаций, как правительственного, так и коммерческого сектора. Версии программного обеспечения CRAMM, ориентированные на разные типы организаций, отличаются друг от друга своими базами знаний (profiles).
5. КОНДОР+ (Digital Security). Программный продукт позволяет менеджерам ИТ-проектов проверить политику информационной безопасности компании на соответствие требованиям ISO 17799. КОНДОР+ включает в себя более 200 вопросов, ответив на которые специалист получает подробный отчет о состоянии существующей политики безопасности, а также модуль оценки уровня рисков соответствия требованиям ISO 17799.
В отчете отражаются все положения политики безопасности, которые соответствуют и не соответствуют стандарту, а также существующий уровень риска невыполнения требований политики безопасности в соответствии со стандартом. Элементам, которые не выполняются, даются комментарии и рекомендации экспертов. По желанию специалиста, работающего с программой, могут быть выбраны генерация отчета, например по какому-то одному или нескольким разделам стандарта ISO 17799, общий подробный отчет с комментариями, общий отчет о состоянии политики безопасности без комментариев для представления руководству. Все варианты отчетов для большей наглядности сопровождаются диаграммами.
КОНДОР+ дает возможность специалисту отслеживать вносимые на основе выданных рекомендаций изменения в политику безопасности, постепенно приводя ее в полное соответствие с требованиями стандарта, а также иметь возможность представлять отчеты руководству, свидетельствующие о целесообразности и обоснованности инвестиций в обеспечение безопасности информационной системы компании. К недостаткам системы можно отнести отсутствие возможности установки пользователем веса на каждое требование и внесения пользователем комментариев.
6. Отечественные программно-инструментальные комплексы «Управление рисками», «Уязвимость», «Анализ безопасности» (в составе комплекса «Моделирование процессов в жизненном цикле систем – ноу-хау», свидетельство Роспатента № 2004610858) и «Программно-вычислительный комплекс оценки качества производственных процессов» (свидетельство Роспатента № 2010614145) – см. рис. 28–35. Дружественный пользовательский интерфейс делает работу с комплексами удобной и доступной практически любому пользователю.
Рис. 28. Заставка комплекса «УПРАВЛЕНИЕ РИСКАМИ»
Комплексы базируются на применении математических методов и моделей, согласно требованиям системообразующих стандартов (ГОСТ Р ИСО 9001 «Системы менеджмента качества. Требования», ГОСТ Р ИСО/МЭК 15288 «Системная инженерия – Процессы жизненного цикла систем», ГОСТ Р ИСО/МЭК 12207 «Системная и программная инженерия – Процессы жизненного цикла программных средств», ГОСТ Р ИСО/МЭК 16085 «Менеджмент риска. Применение в процессах жизненного цикла систем и программного обеспечения», ISO/IEC 31000 «Риск-менеджмент. Принципы и руководства» и др.), в том числе в процессе разработки проекта и системы, при проведении контроля, аудита и сертификации. Применение комплексов обеспечивает аргументированное решение следующих научно-технических задач: организация эффективных систем менеджмента качества на предприятиях; обоснование системотехнического облика и количественных требований технического задания к характеристикам систем, технологиям их создания и функционирования, к квалификации разработчиков и пользователей; оценка и обоснование технических решений, анализ и снижение рисков при управлении проектами; исследование вопросов защищенности систем от потенциальных угроз безопасности (в том числе информационной безопасности), выявление «узких мест» и уязвимостей систем и рациональных путей их устранения с указанием условий, когда это принципиально возможно, и др.
Рис. 29. Исходная форма для выбора моделей
Рис. 30. Заставка комплекса «УЯЗВИМОСТЬ»
Рис. 31. Исходная форма для выбора моделей
Рис. 32. Заставка комплекса «АНАЛИЗ БЕЗОПАСНОСТИ»
Рис. 33. Исходная форма для выбора моделей
Рис. 34. Заставка ПВК для оценки качества производственных процессов
Рис. 35. Исходная форма для выбора моделей
Десятки расчетных примеров, приведенные в монографиях [10], [11], доказывают практичность этих комплексов для управления качеством и рисками (при анализе безотказности функционирования сложных систем, конструируемых из ненадежных элементов; управлении своевременностью представления, полнотой и достоверностью информации; сравнении защищенности информации в открытой и закрытой сетях; прогнозировании качества функционирования информационных систем; выборе рациональных способов построения и модернизации систем теплоснабжения; оценке человеческого фактора; анализе технологических процессов, управлении рисками в опасном производстве и оценке эффективности методов неразрушающего контроля; анализе экологической безопасности; прогнозировании безопасности функционирования трубопроводов; анализе уязвимости морских нефтегазодобывающих систем; выработке рекомендаций по повышению защищенности важных наземных объектов и др.).
Рассмотрим сравнительные характеристики специализированных систем в области управления рисками для реализации программных проектов, которые представлены в табл. 11.
Таблица 11.
Сравнительный анализ систем по управлению рисками в области программных проектов
Анализ систем позволяет сделать вывод, что в качестве продукта поддержки процессов управления рисками может использоваться как специализированная система, так и модуль управления рисками многофункциональной системы поддержки управления проектами. Непосредственная работа с рисками начинается в момент определения перечня рисков, воздействующих на проект, создания карты рисков. На этом этапе для измерения рисков используются в основном экспертные оценки. Начинается накопление исторической базы данных. По мере накопления данных появляется возможность проведения исторического тестирования, организации статистических оценок рисков. И наконец, создание комплексной системы управления рисками подразумевает учет всех видов рисков и организацию интегрированной оценки воздействующих на ИТ-проект рисков. С началом накопления исторических данных по рисковым событиям проект нуждается в организации базы данных по рискам. Применение современных методов риск-менеджмента вызывает потребность в соответствующем инструментарии. Наконец, построение комплексной системы управления рисками с возможностью учета всех рисков, применение к ним наилучших методов измерения и управления, интегральная оценка комплекса рисков могут быть поддержаны промышленной системой управления рисками. Критериями выбора будут масштаб и особенности проекта, а также предпочтения менеджера проекта.
Качественная система управления рисками позволит менеджеру программного проекта принимать более обоснованные управленческие решения на основе количественных данных и обеспечить лучшее взаимодействие команды проекта. Программные продукты анализа рисков существенно снижает трудоемкость выполнения всех этапов анализа рисков. С другой стороны, использование ПО требует высокой квалификации аналитика, достаточно длительного периода обучения и опыта применения.
В заключение приведем несколько наглядных примеров извлечения пользы для бизнеса на основе рационального применения систематизированных знаний в области управления рисками. Расчеты базируются на программно-инструментальных комплексах «Управление рисками», «Уязвимость», «Анализ безопасности» и «Программно-вычислительного комплекса оценки качества производственных процессов» – см. рис. 28–33.
Пример 1. Для сравнения рассмотрим деятельность двух конкурирующих компаний, являющихся для определенности поставщиками труб для транспортировки нефтегазовой продукции и руководствующихся в своей деятельности различными техническими политиками в области качества и рисков. Первая из этих компаний, ориентирующаяся на инновационный путь развития с рациональным применением современных информационных технологий, эффективно использует (как она полагает) существующие новшества для управления качеством и рисками. Вторая компания использует более дешевый труд и устаревшие технологии, сохраняя за счет этого конкурентоспособность на рынке. Опуская вопросы прибыли владельцев компаний за рамками примеров, сравним реализуемые технические политики этих компаний в терминах рисков, затрат и возможных ущербов для потребителей.
На предприятиях применяются различные методы неразрушающего контроля для выявления дефектов в выпускаемой трубопродукции. Полагается, что скорость интерпретации событий позволяет проверять все 100 % предъявленной на контроль продукции.
Первая компания закупает продукцию, прошедшую контроль качества всеми рекомендованными видами (акустическим, магнитным, оптическим, проникающими веществами, радиационным, радиоволновым, тепловым и электромагнитным) и методами неразрушающего контроля, что подтверждено сертификатами соответствия на систему менеджмента качества по ИСО 9001 и на выпускаемую продукцию, а также протоколами испытаний продукции. В итоге при общем объеме контролируемой продукции в 100 000 условных единиц в месяц (например, погонных метров или тонн продукции) доля возможных дефектов до контроля составляет 5 %, частота ошибок при контроле – пропуск не более 2 дефектов в год (это скрытые дефекты, не выявляемые существующими методами или пропущенные при контроле).
Вторая компания довольствуется сертификатом на систему менеджмента качества по требованиям ИСО 9001. Причем у поставщика используется лишь радиоволновой метод неразрушающего контроля, позволяющий выявить такие дефекты, как расслоения и отклонения металлопродукции по толщине (то есть не более 10 % возможных дефектов). За счет этого доля возможных дефектов до контроля составляет уже 20 %, более того, при контроле возможен пропуск множества скрытых дефектов литья (шлаковых и флюсовых включений, усадочных раковин, газовых пузырей, трещин и др.), дефектов обработки давлением (внутренних и поверхностных трещин, разрывов, закалов, вмятин и др.), дефектов термообработки (перегревов, пережогов, трещин закалочных и водородных и др.) – суммарно около 30 дефектов в год.
Требуется сравнить эффективность систем контроля качества для обеих компаний по показателям риска ошибочных аналитических выводов в течение месяца.
Для решения используется модель «Риск ошибочных аналитических выводов» инструментария «УЯЗВИМОСТЬ» (также может быть использована модель «Оценка риска неадекватной интерпретации событий» комплекса «Управление рисками»). Исходные данные и результаты расчетов отражены на рис. 36.
Рис. 36. Сравнительная оценка эффективности систем контроля качества, пример 1
Сравнительный анализ полученных зависимостей показал:
1) риск ошибочных аналитических выводов для 1-й компании составляет 0,15, а для 2-й – 0,92 (!);
2) при изменении объема контролируемой продукции от 50 000 до 200 000 условных единиц в месяц риск ошибочных аналитических выводов возрастает для 1-й компании с 0,08 до 0,58, а для 2-й компании – с 0,71 до 0,96;
3) увеличение доли возможных дефектов вдвое принципиально не влияет на значение риска ошибочных аналитических выводов, то есть эффективность применяемых технологий контроля зависит существенно от других параметров, в частности от частоты возможных ошибок;
4) при увеличении частоты возможных ошибок контроля вдвое риск ошибочных аналитических выводов возрастает для 1-й компании с 0,08 до 0,28, а для 2-й компании – с 0,71 до 0,99.
Выводы: 1. Для 1-й компании риск ошибочных аналитических выводов на уровне 0,15 при контроле продукции в течение месяца на предприятии-поставщике может быть признан как приемлемый.
2. Для 2-й компании предприятие-поставщик реализует откровенно бракованную продукцию (брак ежемесячно имеет место с вероятностью около 0,9), что негативно скажется в дальнейшем при эксплуатации системы.
Это – недвусмысленные выводы для дальнейшего ведения бизнеса.
Пример 2. В процессе длительной эксплуатации неизбежны аварии на трубопроводах. У первой из сравниваемых компаний их ожидается меньше за счет более эффективного управления качеством и рисками. Положим, на поддержание системы контроля качества на предприятиях-поставщиках ежегодные расходы 1-й компании, практикующей, в отличие от 2-й компании, различные виды проверок трубопродукции (акустические, магнитные, оптические, с проникающими веществами, радиационные, радиоволновые, тепловые и электромагнитные), оцениваются в 5 млн. руб., а 2-й компании – в 1 млн. руб., за 2 года расходы считаются вдвое больше. На мониторинг и контроль ситуации в процессе эксплуатации трубопровода 1-я компания, применяющая современные методы, включая комбинацию дистанционного зондирования интегральных и локальных методов инспекции, методов внутритрубной инспекции, расходует в течение 2 лет 50 млн. руб., а 2-я, использующая лишь вертолетное обследование и регулярные рентгенографические методы инспекции, – 10 млн. руб. Кроме этого, на меры противодействия рискам 1-я компания, применяющая в дополнение к мерам 2-й компании проверку качества выпускаемой продукции всеми рекомендованными видами и методами неразрушающего контроля и дистанционное зондирование (космический мониторинг и авиационную съемку), расходует в течение 2 лет 14 млн. руб., а 2-я компания – 12 млн. руб. Более детальные условия примера см. в монографиях [10], [11].
Требуется провести комплексный сравнительный анализ технической политики обеих компаний по показателям рисков и возможных ущербов с учетом затрат на систему контроля качества на предприятиях.
Для решения используются модели инструментария «УЯЗВИМОСТЬ». Комплексный сравнительный анализ технической политики обеих компаний по показателям рисков и возможных ущербов с учетом затрат на систему контроля качества на предприятиях, мониторинга и контроля при эксплуатации и принимаемых мер противодействия показал следующее (см. рис. 37, 38).
Рис. 37. Исходные данные и результаты анализа для 1-й компании, пример 2
Техническая политика 1-й компании характеризуется показателями: при суммарных затратах на меры ситуационного анализа, мониторинга и контроля и противодействия рискам в объеме 74 млн. у.е. риск негативного воздействия на компанию равен 0,334, а математическое ожидание (МОЖ) ущерба – 3,34 млн. у.е. Наибольший вес в уязвимость (риск равен 0,121 из 0,334) вносят неэффективные мониторинг и контроль. Если практически при разумных затратах принятые меры мониторинга и контроля неулучшаемы, то полученные риски и ущербы должны восприниматься 1-й компанией как неизбежные. Как интегральный результат показатели эффективности технической политики 1-й компании могут быть приняты в качестве положительного ориентира для аналогичного рода предприятий.
Рис. 38. Исходные данные и результаты анализа для 2-й компании, пример 2
Несмотря на существенно меньшие расходы 2-й компании (24 против 74 млн. у.е.), математическое ожидание ущерба 9,92 млн. у.е. в три раза превышает ожидаемый ущерб 1-й компании (3,34 млн. у.е.), при этом ущерб соизмерим с затратами. Наибольший вес в уязвимость (0,656 из 0,992) вносят неэффективные мониторинг и контроль и слабые меры противодействия рискам. Риск негативного воздействия на компанию, равный 0,992, свидетельствует о неизбежности реализации потенциальных угроз 2-й компании в течение ближайших 2 лет, несомненно, это отрицательно скажется на конкурентоспособности продукции и услуг компании. Более того, цифры говорят о том, что если даже принимаемые меры ситуационного анализа, мониторинга и контроля и противодействия рискам 2-й компании оформлены в виде документа «Техническая политика», приходится констатировать отсутствие таковой политики из-за ее неэффективности.
Пример 3. Положим, требуется оценить уровень информационной безопасности для крупного холдинга, включающего в свой состав головное предприятие и два других подчиненных предприятия. Территориально распределенная система информационной безопасности характеризуется подсистемами безопасности головного предприятия (подсистема 1), подсистемой связи (подсистема 2) и подсистемой из двух подчиненных предприятий (подсистема 3), каждая из которых базируется на средствах и технологиях защиты, принятых в головном предприятии (рис. 39).
Предполагается, что различного рода угрозы безопасности возникают с частотой не более 1 раз в час, среднее время восстановления системы безопасности после случайного или умышленного выведения из строя составляет не более 30 минут. При этом подсистема 1 защиты головного предприятия использует модель нарушителя, характеризуемую комплексом преград из таблицы на рис. 39. Непрерывный мониторинг осуществляется лишь для 10-й преграды, то есть системы криптографической защиты, наработка на ошибку соизмерима со стойкостью и принята на уровне 2 лет. Наработка на ошибку средств непрерывного мониторинга подсистемы связи составляет 1 месяц. В каждом из подчиненных предприятий подсистемы 3 реализованы те же технические решения по системе защиты, что и в подсистеме 1, поэтому они характеризуются теми же табличными данными, что отражены на рисунке. Каждый из оставшихся компонентов (на рисунке это отдельные клеточки, соединенные последовательно) подсистемы 3 – это обеспечивающие средства сбора и хранения данных, а на предприятии сверху – еще и средства отображения в виде контролируемого табло коллективного пользования, причем все без непрерывного мониторинга их состояния. Пусть характеристики этих средств одинаковы, они отражены справа внизу на рис. 39. Требуется количественно спрогнозировать степень информационной безопасности такой системы при функционировании в течение месяца и года и выявить ее узкие места.
Рис. 39. Структура системы информационной безопасности холдинга, пример 3
Решение базируется на использовании модели «Анализ комплексной безопасности» комплекса «Анализ безопасности». Результаты расчетов комплексной безопасности отражены на рис. 40.
Рис. 40. Результаты анализа и прогноза уровня информационной безопасности холдинга, пример 8.4.3
Результаты анализа и прогноза информационной безопасности холдинга показали:
• 1-я и 2-я подсистемы приблизительно равномощны, при этом для 1-й подсистемы мониторинг криптографической системы защиты (10-й преграды) эффективен;
• 3-я подсистема – наиболее узкое место в системе, внутри нее узкими звеньями являются средства сбора, хранения и отображения данных;
• при реализации мониторинга и контроля в течение месяца преодоления всех преград исключены с вероятностью 0,9, а в течение года – с вероятностью 0,43, без мониторинга и контроля эти показатели снижаются до уровня 0,83 и 0,29 соответственно. Несмотря на высокую эффективность мониторинга и контроля для 1-й подсистемы, в целом они малоэффективны. Это говорит о том, что в течение года возможны случаи нарушения информационной безопасности холдинга.
По результатам моделирования сформулированы следующие рекомендации: для безопасного функционирования системы в целом необходимо, чтобы все подсистемы были равнопрочны. Требуется разработка специальной технологии обеспечения информационной безопасности в экстренных случаях, когда штатная технология выводится из строя.
Рис. 41. Сравнительная оценка безопасности авиаполетов в России и США до 11 сентября 2001 года
Полученные рекомендации, обоснованные количественными расчетами, несомненно, способствуют укреплению бизнеса.
Пример 4. Исследования эффективности мер повышения безопасности авиаполетов проиллюстрируем на исходных данных, полученных в результате анализа террористических акций на пассажирских авиалиниях (детальные исходные данные см. в монографиях [10], [11]). Многие из указанных рекомендаций, опубликованных сразу после 11 сентября 2001 года, уже реализованы.
В поисках ответа на вопрос «Насколько эффективной была существовавшая до 11 сентября 2001 года система обеспечения безопасности полетов в России и США с точки зрения противодействия террористам?» получены следующие результаты анализа рисков (см. рис. 41).
1. И в России, и в США существовавшая система обеспечения безопасности была весьма эффективной против необученного или неподготовленного террориста (риск нарушения безопасности за время полета не выше 0,002 – см. рис. 36 слева). Это достигалось за счет предполетного электронного досмотра и проверки пассажиров и багажа.
2. Риски нарушения безопасности авиаполетов в России и США с возможным проникновением в кабину пилотов при террористическом воздействии со стороны подготовленных террористов приблизительно одинаковы – около 0,5 (см. рис. 36 справа для преград с 1-й по 4-ю). А при оперативном оповещении земли о захвате и возможности за счет этого какого-либо существенного противодействия террористам эта вероятность снижается лишь до уровня 0,24. При этом в России существенной преградой являлись бронированная дверь самолета, а в США – более современная электронная система досмотра. Собственно, как для России, так и для США до 11 сентября 2001 года проведенные расчеты показали недопустимо высокую вероятность достижения террористических целей при соответствующей степени подготовки террористов к этому акту.
3. Полученные откровенно озадачивающие цифры (риск на уровне 0,47–0,48) означают, что время одиночных террористов «с улицы» практически ушло. Они могут сохраниться лишь на местных авиалиниях развивающихся стран, где отсутствуют средства электронного досмотра и проверки пассажиров. То есть расчеты позволяют с достаточной степенью уверенности сделать заключение о том, что практически все состоявшиеся террористические акты совершались подготовленными преступниками после тщательного планирования операции.
Но это еще не все. Полученные количественные результаты наводят на мысль, что либо вопросы противодействия террористам не моделировались, либо используемые модели для анализа рисков являлись не вполне адекватными, поскольку вывод напрашивается очевидный: реальной системы обеспечения безопасности против технически грамотных террористов практически не существовало! Действительно, согласно расчетам, каждый второй из готовящихся террористических актов грозил воплотиться в совсем не галливудскую реальность.
Рис. 42. Анализ эффективности дополнительных мер для снижения рисков, пример 5
Вывод: в России и США существовавшая до 11 сентября 2001 года система обеспечения безопасности авиаполетов являлась малоэффективной против планируемых действий со стороны подготовленных террористов, наиболее «узким» местом были слабая защищенность кабины пилотов и отсутствие мер активного противодействия на борту самолета.
Пример 5. Насколько реально может быть повышен уровень безопасности полетов и за счет чего?
Результаты анализа предыдущего примера показали, что за счет бронирования дверей (аналогично российским самолетам) можно предотвратить проникновение террористов в кабину пилотов. Но этого далеко не достаточно. Нужны комплексные меры активного противодействия террористам уже на борту самолета. Таковых мер можно придумать множество, однако способы их применения должны быть тщательно обоснованы в зависимости от сценария действия террористов. Остановимся лишь на некоторых из мер, уже во многом реализующихся в различных аэропортах.
Мера 1. Введение устройств для распознавания спецматериалов (в том числе керамики), идентификация пассажиров по отпечаткам пальцев, сканирование глазного яблока. Более тщательная проверка при регистрации путем использования общих баз данных предполагаемых преступников, ограничений на ручную кладь. Обозначим меру 1 как 6-ю преграду в дополнение к рассмотренным в предыдущем примере.
Мера 2. Подавление энергии взрыва на борту в багажном отделении. Это 7-я преграда.
Мера 3. Бронированная дверь в кабину пилота (или две двери, вторая открывается только после того, как будет заперта первая).
Мера 4. Мониторинг за пассажирским салоном с помощью видеокамер. Как только кабина пилотов становится неприступной, она может быть превращена в центр телемониторинга состояния безопасности пассажирского салона. Тем самым перед пилотами, а также наземным персоналом открывается реальная картина происходящего. Они будут иметь доступ к полной и достоверной информации обо всем, творящемся на борту. Мониторинг на борту будем рассматривать с вспомогательной точки зрения для осуществления иных дополнительных мер.
Мера 5. Специальная служба сопровождения полета. В то же время возможен обратный эффект – встретив сопротивление, угонщики могут детонировать взрывное устройство, а если террористам удастся разоружить охрану, у них появится дополнительное оружие. Практически это – 9-я преграда.
Мера 6. Специальные меры противодействия (временная разгерметизация, нелетальное воздействие). Реально это – 10-я преграда.
Все перечисленные меры кажутся на первый взгляд весьма внушительными, но насколько они эффективны? Действительно, их эффективность должна быть доказана количественно!
Результаты расчетов показали (см. рис. 42), что при реализации предложенных мер интегральный риск нарушения безопасности авиаполета в течение 5 часов террористических угроз равен 0,000004, а при возрастании длительности угроз до 5 суток риск повышается с 0,000004 до 0,002 (!). Даже с учетом существенной погрешности исходных предпосылок это – явный показатель эффективности дополнительных мер безопасности.
Проведенные расчеты позволяют сформулировать окончательный ответ на поставленный в примере вопрос. Итак, насколько реально может быть повышен существовавший до 11 сентября 2001 года уровень безопасности и за счет чего? Ответ: за счет реализации дополнительных мер противодействия террористам при контроле и на борту риск нарушения безопасности полетов может быть реально уменьшен с 0,47–0,48 до уровня ниже 0,002. То есть реализация вышеуказанных мер приводит к снижению риска нарушения безопасности на несколько порядков! Но это далеко не победа. Очевидно, что первые же неудачи заставят террористов анализировать их причины и искать новые недостатки системы безопасности, тем самым ожидается длительное противоборство. Успешным это противоборство может оказаться лишь тогда, когда будут приниматься упреждающие меры, эффективность которых может быть доказана или опровергнута с использованием математического моделирования.
Приведенные примеры демонстрируют важность, практичность и эффективность применения современных инструментариев для рационального управления рисками.