Основные разделы плана управления рисками. Область знаний – управлении рисками проекта

Автор работы: Пользователь скрыл имя, 10 Марта 2013 в 23:31, лабораторная работа

Краткое описание

Стандарты в области информационной безопасности, которые должны соблюдать и отечественные предприятия, например ISO17799, BS7799, ISO27001, также предусматривают механизмы управления ИТ - рисками. Оценка последних позволяет компании определить оптимальный объем расходов на обеспечение информационной безопасности и разумно спланировать мероприятия по ее поддержке.

Вложенные файлы: 1 файл

Основные разделы плана управления рисками. Область знаний – управлении рисками проекта.docx

— 114.00 Кб (Скачать файл)

Министерство образования и науки, молодежи и спорта

ОДЕССКИЙ НАЦИОНАЛЬНЫЙ ПОЛИТЕХНИЧЕСКИЙ  УНИВЕРСИТЕТ

Институт радиоэлектронники  и телекоммуникаций

Кафедра информационной безопасности

 

 

 

ПРОТОКОЛ

Лабораторной работы №2

«Основные разделы плана управления рисками. Область знаний – управлении рисками проекта»

 

 

Выполнил студент гр. РБ-081

 

_________________ Семененко И.И.

(подпись)

“___” ____________ 2013 р.

 

 Проверил:

__________________ Сафронов О.С.

(подпись)

“___” ____________ 2013 р.

 

 

 

Одесса 2013

Цель: Научится планировать и систематизировать разделы в плане

управления рисками

 

  1. Основные разделы плана управления рисками

 

    1. Методология управления рисками

 

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

Управление ИТ-рисками  состоит из их периодической оценки и выполнения мероприятий по снижению выявленных рисков до приемлемого уровня. При этом величины выявленных рисков используются для определения размеров разумных инвестиций в информационную безопасность. На Западе законодательство предписывает компаниям управлять  ИТ-рисками, к примеру, в США этого  требует закон Сарбейнса - Оксли, принятый в 2002 году. Стандарты в области информационной безопасности, которые должны соблюдать и отечественные предприятия, например ISO17799, BS7799, ISO27001, также предусматривают механизмы управления ИТ - рисками. Оценка последних позволяет компании определить оптимальный объем расходов на обеспечение информационной безопасности и разумно спланировать мероприятия по ее поддержке.

К сожалению, не существует очевидных правил, утверждающих, в  каком конкретном случае следует  применять ту или иную методологию  управления ИТ – рисками, например CORAS, OCTAVE или CRAMM. В российских компаниях ситуация осложняется ограничениями отечественных программных продуктов, предназначенных для оценки и управления ИТ-рисками. Большинство из них базируются не на методологиях управления ИТ-рисками, а на стандартах информационной безопасности, например BS7799 или ISO17799, а потому позволяют определить не уровень ИТ-рисков, а степень соответствия тому или иному стандарту. Кроме того, обычно они не учитывают мнения владельцев информационных активов при определении величин потенциального ущерба.

Рассмотрим методологию управления ИТ-рисками

Методология CORAS разработана в рамках программы Information Society Technologies. Ее суть состоит в адаптации, уточнении и комбинировании таких методов проведения анализа рисков, как Event-Tree-Analysis, цепи Маркова, HazOp и FMECA.

CORAS использует технологию UML и базируется на австралийском/новозеландском  стандарте AS/NZS 4360: 1999 Risk Management и ISO/IEC 17799-1: 2000 Code of Practiсe for Information Security Management. В этом стандарте учтены рекомендации, изложенные в документах ISO/IEC TR 13335-1: 2001 Guidelines for the Management of IT Security и IEC 61508: 2000 Functional Safety of Electrical/Electronic/Programmable Safety Related.

В соответствии с CORAS информационные системы рассматриваются не только с точки зрения используемых технологий, но с нескольких сторон, а именно как сложный комплекс, в котором  учтен и человеческий фактор. Правила  данной методологии реализованы  в виде Windows- и Java-приложений.

OCTAVE. Методология OCTAVE (Operationally Critical Threat, Asset and Vulnerability Evaluation) была разработана в Институте программной инженерии при Университете Карнеги—Меллона и предусматривает активное вовлечение владельцев информации в процесс определения критичных информационных активов и ассоциированных с ними рисков. Ключевые элементы OCTAVE:

  • идентификация критичных информационных активов;
  • идентификация угроз для критичных информационных активов;
  • определение уязвимостей, ассоциированных с критичными информационными активами;
  • оценка рисков, связанных с критичными информационными активами.

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

Методология CRAMM (CCTA Risk Analysis and Management Method) разработана британским Центральным компьютерным и телекоммуникационным агентством в 1985 году и применяется как для крупных, так и для небольших организаций правительственного и коммерческого сектора. Версии программного обеспечения CRAMM, ориентированные на разные типы организаций, различаются своими базами знаний, или «профилями».

CRAMM предполагает использование  технологий оценки угроз и  уязвимостей по косвенным факторам  с возможностью проверки результатов.  В нее заложен механизм моделирования  информационных систем с позиции  безопасности с помощью обширной  базы данных по контрмерам. CRAMM нацелен на детальную оценку рисков и эффективности, предполагаемых к использованию комбинаций различных контрмер. Имеются коммерческие программные продукты, реализующие положения CRAMM. В частности, компания Siemens предлагает продукты CRAMM Expert и CRAMM Express.

До принятия решения о  внедрении той или иной методологии  управления ИТ-рисками следует убедиться, что она достаточно полно учитывает  бизнес-потребности компании, ее масштабы, а также соответствует лучшим мировым практикам и имеет достаточно подробное описание процессов и требуемых действий. В качестве критериев оценки при сравнении методологий управления ИТ-рисками целесообразно воспользоваться стандартом COBIT.

Аббревиатура COBIT (Control Objectives for Information and Related Technologies) подразумевает под собой набор документов, в которых изложены принципы управления и ИТ-аудита, основанные на лучших мировых практиках. В качестве критериев оценки методологий управления ИТ-рисками можно использовать инструкции COBIT по аудиту ИТ-процесса «Оценка рисков».

Используя COBIT для анализа  методологий управления ИТ-рисками, следует учитывать, что существуют некоторые ограничения. Например, методология OCTAVE предусматривает адаптацию к  конкретным условиям применения, а COBIT нет. При выборе методологии управления рисками не последнюю роль играют стоимость и время внедрения. Эти параметры не включены в оценку, так как они субьективны и могут сильно варьироваться в разных компаниях. Метод сравнительного анализа не учитывает объем, в котором компания планирует внедрение методологии, то есть, организация может поставить своей целью только выявление и оценку величины рисков без управления ими или без мониторинга. Согласно стандарту COBIT, концепция управления рисками подразумевает обход риска, его снижение или принятие. Такой способ управления рисками, как их перенос (т.е. страхование), не рассматривается. Перенос риска обычно используется в тех случаях, когда вероятность наступления нежелательного события мала, а потенциальный ущерб относительно высок.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

 

    1. Ответственность участвующих в управлении рисками

 

Роли и ответственность  распределены в соответствии со следующими принципами:

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

Надзор за эффективностью управления рисками осуществляет Комитет по аудиту  (Совет директоров).

В таблице кратко представлено распределение ролей и обязанностей участников СУР.

Таблица 5.2. Роли и обязанности  участников СУР

Участник

Роль

Функции и ответственность

Комитет по аудиту при Совете директоров

Контролер

  • Надзор за эффективностью управления рисками.

Генеральный директор (Правление)

Гарант

  • Организация эффективного управления рисками в рамках своей структурной единицы.
  • Утверждение бюджетов на мероприятия.
  • Утверждение реестра рисков уровня Правления.
  • Утверждение реестра рисков.
  • Формирование бюджетов на мероприятия.
  • Разрешение спорных ситуаций.

Подразделения (руководители и участники  бизнес-процессов)

Исполнители, владельцы рисков

  • Выявление и оценка рисков.
  • Разработка и исполнение мероприятий.
  • Своевременная передача информации о рисках и мероприятиях координаторам СУР.
  • Фиксация и передача информации о реализовавшихся рисках.

Координаторы СУР

Методолог-координатор

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

 

 

 

 

 

 

 

    1. Бюджет для управления рисками

 

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

На практике это выглядит следующим образом: представитель  Заказчика на старте проекта (или менеджер при найме руководителя проекта) обязательно интересуется об используемом подходе к управлению рисками, задает для проверки вопрос в стиле: «Чем отличается риск от проблемы?». На такие шаблонные вопросы, как правило, следуют не менее шаблонные ответы и на этом совместное прояснение подхода к риск-менеджменту завершается.

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

Данная ситуация обусловлена  рядом разнородных обстоятельств, таких как: незрелость методик и процессов управления проектами, сложность и длительность полноценного жизненного цикла каждого риска, а также стремительно развивающиеся подходы к организации проектных работ в ИТ-индустрии. В целом, на мой взгляд, переломить ситуацию сможет только накопление положительного и отрицательного опыта и взросление методологий и процессов у крупных игроков.

Впрочем, любая нестабильная ситуация всегда представляет собой  как потенциальные проблемы, так  и скрытые возможности. В случае с управлением рисками руководитель проектов стоит перед выбором – закрыть глаза на несовершенство подхода к организации проекта или найти способ активно воздействовать и смягчать последствия рисков. Например, часть рисков можно представить неизбежными и включить в планы-ресурсы для ликвидации негативного влияния таких рисков. Это позволит, в случае если удастся такие риски нивелировать до их активации, получить определенный ресурс для ликвидации последствий других рисков. Также, одна из задач менеджера проекта – последовательное и настойчивое развитие методологий по управлению рисками и изменение отношения Заказчика к данной проблеме. Что позволит находить взаимопонимание сторон даже в традиционно трудных вопросах бюджета и ресурсов. Такая деятельность повышает ценность специалиста как внутри компании, так и на рынке, что благоприятно влияет на его карьерные возможности.

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

Информация о работе Основные разделы плана управления рисками. Область знаний – управлении рисками проекта