Размещено на http://www.allbest.ru/

Московский институт электроники и математики им. А.Н. Тихонова

Выпускная квалификационная работа

Исследование и разработка моделей управления рисками в ИТ

Ковалев Александр Вадимович



Введение

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

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

Объект исследования диссертации: риски ИT-процессов.

Предмет исследования диссертации: модель управления рисками в ИT.

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

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

Целью исследования магистерской диссертации является разработка рекомендаций и модели управления рисками в ИТ.

Задачи исследования:

1) анализ научной литературы по проблеме исследования;

2) анализ существующих стандартов и мировых практик управления рисками в ИТ;

3) исследование и классификация основных рисков в ИТ;

4) разработка рекомендаций и создание модели управления рисками.

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

Научная новизна исследования:

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

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

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



1. Обзор предметной области

1.1 Риски в ИТ

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

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

Понятие риска можно рассматривать по-разному:

- как опасность или угроза, если речь идет о каких-то негативных событиях, потерях, хищениях, ущербе;

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

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

Условно все риски в ИТ можно разделить на несколько групп:

· риски безопасности, связанные с утечкой информации;

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

· риски готовности, которые определяются временем простоя и восстановления информационных систем после природных катастроф, отказа или из-за ошибки работника;

· операционные риски, обусловленные несогласованными или неквалифицированными действиями персонала компании.

Классификация рисков

В основу классификации рисков входят причины возникновения, характер, время, основные факторы и возможные последствия [1].

По времени появления:

- прошлые (ретроспективные);

- текущие;

- будущие (перспективные).

Детальный анализ ретроспективных рисков дает возможность более точно управлять текущими и прогнозировать будущие угрозы.

По характеру:

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

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

По причине возникновения:

- организационные (ОР), связанные с внутренней организацией работ, работой менеджмента, системой внутреннего контроля и т.д.;

- процессные (ПР),

- проектные (ПРР), характеризующие угрозы выполнения как проекта в целом, так и его отдельных этапов;

- операционные (ОПР) - риски бизнес-операций

По последствиям:

- коммерческие риски, которые могут принести как убытки, так и прибыль;

- чистые риски, которые несут только потери. Их причинами могут быть стихийные бедствия, несчастные случаи и т.д.;

- допустимые риски, которые могут принести и потери, и прибыль, причем прибыль в данном случае превышает ущерб;

- критические риски, которые могут привести к разрушению всей системы;

- катастрофические риски, которые могут нести угрозу не только целостности компании, но и угрозу человеческой жизни.

По типу внедрения:

- «коробочное» внедрение ПО, т.е. не требующее доработки ИТ-системы - может привести к интеграционным рискам в связи с конфликтом с установленным ПО и существующей базой данных;

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

- внедрение системы «с нуля» - может привести к техническим, коммерческим и интеграционным рискам.

Управление рисками в ИТ

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

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

Идентификация рисков

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

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

Выбор методов идентификации зависит от конкретной ситуации, специфики деятельности компании и поставленной цели. Есть чисто математические, например, метод Монте-Карло, есть менее формальные и более доступные для широкой аудитории специалистов (метод Brianstorming или метод мозгового штурма), SWOT-анализ, есть узконаправленные для конкретных процессов. Наибольшего эффекта можно достичь путем комплексного использования различных методик.

Таблица 1. Сравнительный анализ методов идентификации рисков

Метод идентификации	Преимущества	Недостатки
Метод идентификации основных причин	Для его проведения не требуются дополнительные ресурсы и участие экспертов	Необходима определенная база документов
Мозговой штурм	Не требует финансовых затрат и занимает минимум времени. Способствует эффективному взаимодействию членов группы.	Есть зависимость от личности участника группы. Позволяет проводить анализ только в конкретных областях.
Метод Дельфи	Отсутствует доминирование одной личности, хотя и требует участия каждого члена группы. Может проводиться дистанционно. Лишен проблемы ранней оценки.	Требует высокой загрузки ведущего, а также занимает много времени.
SWOT-анализ	Универсален в применении, достаточно гибок и обладает широким спектром применения.	Субъективен, дает только качественное описание факторов и их поверхностную оценку.
Метод Монте-Карло	Универсальность применения к любым данным не зависимо от источника их возникновения.	Техническая сложность метода, необходимость в квалифицированных специалистах и большие временные затраты.
Карточки Кроуфорда	Не занимает много времени, легко реализуется, позволяет быстро достигнуть конечного результата.	Обладает более низкой социальной ориентированностью по сравнению с методом мозгового штурма.

Обработка рисков

Процесс обработки риска заключается в его анализе и оценке [3]. При этом основными параметрами являются:

- выбор критериев принятия риска;

- анализ доступных ресурсов;

- определение основных подходов к оценке риска;

- подбор критериев оценки (нормативные и договорные требования, операционные последствия, конфиденциальность, репутация и т.д.);

- стратегические цели компании.

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

Ожидаемая величина риска = Вероятность * Угроза

Для наглядности результаты такого анализа представляются в виде карты рисков.

Рисунок 1. Пример карты рисков (качественная оценка)

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

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



Рисунок 2. Пример карты рисков (полуколичественная оценка)

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

Ожидаемая стоимость риска = Вероятность риска * Оценка стоимости влияния риска

При этом качество такой оценки напрямую зависит от точности и полноты представленной для анализа информации.

Наиболее распространенными методами количественной оценки являются:

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

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

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

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

- метод аналогов, построенный на анализе прошлых факторов риска.

Очень важно, чтобы во время всего процесса менеджмента риска проходила коммуникация риска всем заинтересованным сторонам: персоналу и руководству компании.

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

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

В основу методологии управления рисками в ИТ входят «лучшие практики» [4]: CORAS, OCTAVE, CRAMM, MOF risk management и т.д., которые базируются на существующих стандартах в области информационной безопасности: ISO17799, BS7799, ISO27001, а также стандартах в области управления информационной безопасностью ISO 27001 и в области разработки программного обеспечения ISO 12207, ISO 15288, ISO15504 и других.

Однако все они разрабатывались для западных компаний, поэтому не учитывают особенностей российского рынка и программных продуктов отечественного производства.

CORAS

Целью методологии CORAS [5], разработанной в рамках научно-технической программы ЕС «Технологии информационного общества», является адаптация и комбинация таких методов анализа рисков как HazOp, FMECA, Event-Tree-Analysis, которые позволяют рассматривать используемые в информационных системах технологии, а также учитывать человеческий фактор. Используемая технология UML (графическое описание для объектного моделирования в области разработки программного обеспечения) позволяет представить результаты анализа рисков с помощью специальных встроенных диаграмм.

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

Рисунок 3. Структура методологии CORAS

Программный продукт, реализующий CORAS распространяется бесплатно, что является несомненным плюсом.

Недостатком данной методологии является отсутствие оценки эффективности управления рисками и возможность использования лишь для разовой оценки без учета динамики.

OCTAVE

Методология OCTAVE [6], разработанная в американском Университете Карнеги--Меллона, позволяет привлечь к определению рисков владельцев информации: сотрудников подразделений, эксплуатирующих систему, и сотрудников ИТ-департамента, которые объединяются в аналитическую группу с целью изучения информационной безопасности. OCTAVE была разработана для крупных компаний и отличается тем, что не дает количественной оценки рисков, однако позволяет выполнить оценку организационных аспектов, IT-инфраструктуры предприятия и определить уязвимости информационных активов для их последующего ранжирования и разработки стратегии обеспечения информационной безопасности. При этом технические риски в данной методологии учитываются лишь косвенно.

Рисунок 4. Схема анализа по методу OCTAVE

В отличие от CORAS, данная методология предусматривает регулярную переоценку рисков и позволяет адаптировать предлагаемые решения к особенностям законодательства, размеру и специфике компании.

Недостатком OCTAVE является отсутствие количественной оценки рисков и такого способа управления, как исключение риска.

CRAMM

Методология CRAMM [7], разработанная британским Центральным компьютерным и телекоммуникационным агентством, позволяет на основе анализа косвенных факторов сделать оценку существующих уязвимостей и угроз, выполнить моделирование информационной системы с точки зрения безопасности и снижения рисков.

Рисунок 5. Схема анализа по методу CRAMM

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

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

MOF risk management

Методология MOF risk management [8], предложенная корпорацией Microsoft, на сегодняшний день является наиболее распространенной. Она включает в себя определение рисков, их динамическое отслеживание, контроль и анализ, оценку вероятности возникновения, оценку ущерба, а также планирование мероприятий, позволяющих избежать риска или минимизировать его последствия. Кроме того, MOF предлагает модель команды для распределения ответственности и полномочий в соответствии с происходящими процессами между сотрудниками ИТ-подразделения.



Рисунок 6. Методология MOF

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

ГРИФ

Существует и отечественная методология информационной безопасности - ГРИФ [9], которая предлагает анализ уровня защиты на основе описания имеющихся ресурсов компании и вида информации, оценку возможного ущерба, а также выбор контрмер для обеспечения эффективного управления рисками. Сложность внутренних алгоритмов данной методологии компенсируется простотой в использовании.

Рисунок 7. Процесс обеспечения информационной безопасности ГРИФ



К недостаткам метода можно отнести отсутствие возможности сравнения отчётов на различных стадиях внедрения мер по обеспечению защищённости [10].

Таблица 2. Сравнительные характеристики основных систем анализа рисков

Примечание.

+ методология отвечает критерию;

- не соответствует критерию;

? соответствие критерию зависит от других факторов.

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

Стандарты управления информационными рисками

Использование существующих методологий на российском рынке осложняется тем, что отечественные программные продукты ориентированы не на оценку и управление рисками в ИТ, а на их соответствие существующим стандартам информационной безопасности [11].

Все существующие стандарты можно разбить на следующие классы:

- международные стандарты, разрабатываемые международными организациями на основе «лучших практик» и мирового опыта. Например, ISO - Международная организация по стандартизации, PMI - Международный институт управления проектами. Эти стандарты имеют рекомендательный характер;

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

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

- государственные стандарты, которые разрабатываются государственными органами с учетом мирового опыта, «лучших практик» и на основе отраслевых стандартов. Они могут иметь как обязательный, так и рекомендательный характер.

На сегодняшний день существует множество международных стандартов информационной безопасности: ISO 17799 (BS7799), ISO 15408, ISO 27001, BSI; а также стандартов аудита, отражающих вопросы информационной безопасности, COBIT, COSO, SAC, SAS 55/78 и другие.

ISO 17799

Разработанный в Великобритании в 1995 году стандарт BS 7799 стал доработанной версией пособия о практических аспектах обеспечения информационной безопасности в коммерческих компаниях. В 1998 году опубликована вторая часть стандарта по вопросам аудита информационной безопасности, а в 2000г. бал принят стандарт ISO 17799 [12], основанный на BS 7799. В настоящее время данный стандарт является наиболее полным и распространенным документам, широко используемым различными компаниями, хотя в нем отсутствует раздел, посвященный аудиту.

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

Модификации стандарта:

- BS 7799-1:2005 - включает в себя рекомендации по практическому управлению информационной безопасностью;

- BS 7799-2:2005 - содержит основные требования к системам управления информационной безопасностью;

- BS 7799-3:2006 - представляет собой руководство по управлению рисками информационной безопасности.

Рисунок 8. Стандарт BS 7799



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

К недостаткам стандарта можно отнести низкую адаптацию к специфике современных распределенных систем.

COBIT 5 for Risk

Стандарт COBIT 5 for Risk (Control Objectives for Information and related Technology) [13], разработанный ассоциацией ISACA, предлагает управление рисками с двух точек зрения: risk function и risk management, т.е. рассматриваются не только объекты контроля, но и принципы управления и аудита. Предлагаемые данным стандартом инструменты основаны на существующих ИТ-процессах с «лучшими» практиками.

Согласно стандарту все информационные ресурсы делятся на 4 группы: данные (Information), приложения (Applications), существующая инфраструктура (Infrastructure) и пользователи (People). Все ИТ-процессы в свою очередь сгруппированы в 4 домена:

- приобретение и ввод в эксплуатацию;

- организация и планирование;

- предоставление и поддержка;

- мониторинг и оценка.

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



Рисунок 9. Структура стандарта COBIT

Однако данный стандарт не предполагает разработки мер по совершенствованию ИТ-процессов и услуг [14], а также их внедрения, поэтому он подходит больше для оценки (аудита) существующих процессов с целью дальнейшей разработки мероприятий по их совершенствованию.

BSI и BSI-Standards 100-3

Разработанные в Германии в 1998 г стандарты BSI и BSI-Standards 100-3 «Руководство по защите информационных технологий для базового уровня защищенности» представляют собой текстовые справочники, в которых изложена методология управления информационной безопасностью, ее основные компоненты, инфраструктура, программное обеспечение, системы передачи данных, базы данных, каталоги угроз и перечень контрмер.

Все каталоги ранжированы по классам угроз с предлагаемым сценарием контрмер и являются наиболее подробными из существующих.

В отличие от стандарта ISO 17799 (BS 7799), в котором даются более общие принципы, в стандарте BSI больше внимания уделяется рассмотрению «частных случаев», хотя все случаи предусмотреть не в состоянии даже он (что можно отнести к недостаткам), хотя он более адаптирован к современным сетям.

NIST 800-30

Американский стандарт NIST 800-30 [15] подробно рассматривает вопросы управления ИТ-рисками с целью минимизации возможных последствий. Для этого систему управления рисками необходимо интегрировать в общую систему управления жизненным циклом информационных технологий.

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

Риски оцениваются с точки зрения вероятности реализации потенциальной угрозы с градацией на низкий, средний и высокий уровень. Также определяется цена нарушения информационной безопасности с классификацией последствий и выработкой рекомендаций по управлению рисками.

Отечественные стандарты безопасности

Отечественные стандарты безопасности [16] можно условно разделить на государственные стандарты (ГОСТ), такие как, например,

- ГОСТ Р 52069.0-2003 «Защита информации. Система стандартов. Основные положения»

- ГОСТ Р 52447-2005 «Защита информации. Техника защиты информации. Номенклатура показателей качества»

- ГОСТ Р ИСО/МЭК 15408-2008 «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий.»

и стандарты, разработанные специально для банковской системы (СТО БР ИББС), например,

- ИББС-1.0-2006 «Обеспечение информационной безопасности организаций банковской системы РФ. Общие положения»,

- ИББС-1.1-2007 «Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Аудит информационной безопасности»,

- ИББС 2.2-2008 «Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Методика оценки рисков нарушения информационной безопасности».

В 2007 г. в России были приняты стандарты ГОСТ ИСО/МЭК 17799 и ГОСТ ИСО/МЭК 27001, которые по сути являются аналогами международных стандартов ISO 27000, основанных на британском стандарте BS 7799.

При всей схожести данных стандартов есть и отличия. ISO 27000 ориентирован на создание модели управления рисками, в то время как ИББС ориентирован на «модель нарушителя», хотя он более практичен с точки зрения потребителя, так как в нем предлагаются четкие алгоритмы внедрения, адаптированные к российской действительности.

В 2010г. научно-техническим центром «ИНТЕК» был разработан стандарт ГОСТ Р ИСО 31000-2010 «Менеджмент риска. Принципы и руководство», а в 2011 г. АНО «НИЦ КД» разработала ГОСТ Р ИСО/МЭК 31010-2011 «Менеджмент риска. Методы оценки риска». Оба стандарта являются аутентичным переводом на русский язык международного стандарта ISO/IEC 31010:2009 «Risk management -- Risk assessment techniques».

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

1.3 Аудит ИТ-процессов

Каждый существующий стандарт предполагает процедуру аудита ИТ-процессов [17], оценку рисков и разработку рекомендаций по их снижению (предотвращению). Аудитором формируется перечень рисков на каждом этапе ИТ-процесса:

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

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

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

- управление проектами - выбор методики управления, оценка трудозатрат;

- разработка ИТ-инфраструктуры - отсутствие стандартизации эксплуатации ИТ, риски безопасности и снижение производительности;

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

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

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

Рисунок 10. Пример результатов аудита

Результаты аудита ИТ-процессов позволят руководству компании:

· оценить эффективность работы существующей ИТ-службы;

· оценить риски в ИТ;

· оценить соответствие ИТ-процессов международным стандартам;

· разработать стратегию развития ИТ-инфраструктуры;

· обосновать необходимость приобретения новых программных комплексов и систем, повышения квалификации сотрудников.



2. Разработка модели управления рисками в ИТ

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

2.1 Исследование процессов управления ИT-сервисами и услугами

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

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

Таблица 3. Класс критичности ИТ-сервиса

Класс критичности	Показатели восстановления
	RTO	RPO
Mission Critical	15 минут	0 минут
Business Critical	4 часа	1 час
Business Operational	24 часа	24 часа
Office Productivity	1 неделя	24 часа

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

Таблица 4. ИТ-сервисы компании

Название системы	Сегмент	Критичность	RTO/RPO	Критичные процессы
АВТОРИЗАЦИЯ
Фронт офис сопровождения авторизаций ПС Visa	ОПЕРАЦИОННЫЙ	Mission Critical	15 мин / 0 мин	Обеспечение авторизации клиентов по ПС Visa
Фронт офис сопровождения авторизаций ПС MasterCard	ОПЕРАЦИОННЫЙ	Mission Critical	15 мин / 0 мин	Обеспечение авторизации клиентов по ПС MasterCard
Сервис резервных авторизаций ПС Visa	ОПЕРАЦИОННЫЙ	Mission Critical	15 мин / 0 мин	Обеспечение резервной авторизации резервной авторизации по ПС Visa
Сервис резервных авторизаций ПС MasterCard	ОПЕРАЦИОННЫЙ	Mission Critical	15 мин / 0 мин	Обеспечение резервной авторизации резервной авторизации по ПС MasterCard
КЛИРИНГ
Система расчета клиринга по картам ПС Visa	ОПЕРАЦИОННЫЙ	Business Critical	4 часа / 1 час	Обеспечение выполнения клиринга по картам ПС Visa
Система расчета клиринга по картам ПС MasterCard	ОПЕРАЦИОННЫЙ	Business Critical	4 часа / 1 час	Обеспечение выполнения клиринга по картам ПС MasterCard
БЕЗОПАСНОСТЬ
Система контроля мошеннических операций	ОПЕРАЦИОННЫЙ	Business Operational	24 часа / 24 часа	Выявление мошеннических операций. Блокировка карт.
Система информационной безопасности	ОПЕРАЦИОННЫЙ	Business Critical	4 часа / 1 час
КЭШБЭК
Система кэшбэк расчетов	ОПЕРАЦИОННЫЙ	Business Operational	24 часа / 24 часа
Хранение Данных
Архив API	ОПЕРАЦИОННЫЙ	Business Critical	4 часа / 1 час	Хранение API
Корпоративные Системы
1С	КОРПОРАТИВНЫЙ	Business Critical	4 часа / 1 час
1С: Холдинг	КОРПОРАТИВНЫЙ	Business Operational	24 часа / 24 часа
Confluence / JIRA	КОРПОРАТИВНЫЙ	Business Critical	4 часа / 1 час
Docsvision	КОРПОРАТИВНЫЙ	Office Productivity	1 неделя / 24 часа	Организация и ведение бумажного и электронного документооборота
eStaff	КОРПОРАТИВНЫЙ	Business Operational	24 часа / 24 часа	Расчет и выплата заработной платы
ServiceDesk	КОРПОРАТИВНЫЙ	Business Critical	4 часа / 1 час
Система учета мат.активов	КОРПОРАТИВНЫЙ	Business Operational	24 часа / 24 часа
Консультант+	КОРПОРАТИВНЫЙ	Business Operational	24 часа / 24 часа
СИСТЕМЫ ИБ. (информационная безопасность)
Система антивирусной защиты Kaspersky Total Security, Kaspersky DDOS-Prevention	ОПЕРАЦИОННЫЙ	Mission Critical	15 мин / 0 мин
	КОРПОРАТИВНЫЙ
Система защиты информации от несанкционированного доступа и система контроля целостности Secret Net	ОПЕРАЦИОННЫЙ	Business Critical	4 часа / 1 час
Система контроля действий привилегированных пользователей CyberArk	ОПЕРАЦИОННЫЙ	Mission Critical	15 мин / 0 мин
Система анализа конфигурации активного сетевого оборудования	ОПЕРАЦИОННЫЙ	Business Operational	24 часа / 24 часа
	КОРПОРАТИВНЫЙ
Система противодействия таргетированным атакам	КОРПОРАТИВНЫЙ	Business Operational	24 часа / 24 часа
Система предотвращения утечек конфиденциальной информации - Infowatch	КОРПОРАТИВНЫЙ	Office Productivity	1 неделя / 24 часа
Система управления событиями информационной безопасности HP ArcSight ESM	ОПЕРАЦИОННЫЙ	Mission Critical	15 мин / 0 мин
	КОРПОРАТИВНЫЙ
Технологические Системы
Система мониторинга Zabbix	КОРПОРАТИВНЫЙ	Business Critical	15 мин / 0 мин
Система управления и мониторинга сетевого оборудования	КОРПОРАТИВНЫЙ	Mission Critical	15 мин / 0 мин
Система централизованного управления учетными записями пользователей (ActiveDirectory)	ОПЕРАЦИОННЫЙ	Business Operational	24 часа / 24 часа
Система резервного копирования (netbackup)	ОПЕРАЦИОННЫЙ	Business Operational	24 часа / 24 часа
	КОРПОРАТИВНЫЙ
Система видеоконференц связи	КОРПОРАТИВНЫЙ	Business Operational	24 часа / 24 часа
Электронная почта (MS Exchange)	КОРПОРАТИВНЫЙ	Mission Critical	15 мин / 0 мин
Шлюз доступа	ОПЕРАЦИОННЫЙ	Mission Critical	15 мин / 0 мин

2.2 Тестирование ИТ-систем

Тестирование базы данных

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

Цель: контроль доступа к данным и отсутствие нарушения их целостности.

Способы: реализовать все методы доступа к БД с вводом правильных и неправильных данных (или запросов к данным). Проанализировать БД на корректность её заполнения данными и обработки событий.

Критерий завершенности: все процедуры и методы заполнения БД функционируют без нарушения её целостности.

Тестирование вычислительных систем

Тестирование приложений, основанное на технике «черного ящика», т.е. проверка корректности приема, обработки и возврата данных путем взаимодействия с приложением через GUI, а также анализ результата.

Цель: обеспечение надежной работы приложений, ввода данных, поиска и обработки.

Способы: ожидаемые результаты возникают при использовании допустимых данных. При использовании недопустимых данных появляются соответствующие сообщения об ошибках/предупреждениях.

Критерий завершенности: все запланированные тесты были выполнены. Все идентифицированные дефекты были устранены.

Тестирование цикличных бизнес-процессов

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

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

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

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

- при использовании недопустимых данных отображаются соответствующие сообщения об ошибках/предупреждениях.- правило каждого бизнес-правила применяется правильно.

Критерий завершенности: все запланированные тесты были выполнены. Все идентифицированные дефекты были устранены.

Тестирование интерфейса

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

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

Способы: создавать/изменять тесты для каждого окна, чтобы проверить правильность навигации и состояния объектов для каждого окна приложения и объектов.

Критерий завершенности: каждое окно успешно проверено, чтобы оставаться совместимым с эталонной версией или приемлемым стандартом.

Тестирование производительности

Тестирование производительности позволяет провести оценку времени отклика системы, скорости выполнения операций и другие временные характеристики. В ходе ТП для проверки и подтверждения критериев производительности используется разная «загрузка в фоновом режиме»: от «номинальной», подобной нормальной (прогнозируемой для данной системы), до максимальной. Помимо контроля это тестирование можно использовать для настройки производительности системы в зависимости от конфигурации и условий использования.

Цель: проверять время ответа системы на определенные транзакции или бизнес-функции в следующих двух условиях:- нормальный ожидаемый объем- ожидаемый худший объем

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

Критерий завершенности: отдельная транзакция/одиночный пользователь: успешное завершение тестовых сценариев без сбоев и в пределах ожидаемого/требуемого распределения времени (для каждой транзакции); несколько транзакций / несколько пользователей: успешное завершение тестовых скриптов без сбоев и в пределах приемлемого распределения времени.

Тестирование загрузки

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

Цель: проверять время ответа системы на определенные транзакции или бизнес-кейсы при различных условиях рабочей нагрузки.

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

Критерий завершенности: несколько транзакций / несколько пользователей: успешное завершение тестов без сбоев и в пределах приемлемого распределения времени.

Стресс-тестинг

Стресс-тестинг предназначен для нахождения ошибок, которые не видны при работе в штатном режиме. Они могут возникать из-за дефектов программного обеспечения, недостатка памяти или места на диске в случае их совместного использования разными компонентами, вследствие блокирования БД при одновременном их использовании несколькими пользователями или приложениями. Стресс-тестинг позволит определить максимальную загрузку, которую может выдержать система.

Цель: убедиться, что система и программное обеспечение работают правильно и без ошибок в следующих условиях стресса:

- на сервере недостаточно памяти или нет (RAM и DASD);

- максимальное (фактическое или физически работоспособное) число подключенных (или смоделированных) клиентов;

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

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

Критерий завершенности: все запланированные тесты выполняются и заданные предельные значения системы достигаются/превышены без сбоя программного обеспечения или программного обеспечения (или условий, при которых системный сбой происходит, выходит за указанные условия).

Тестирование объема загрузки

Тестирование объема необходимо для определения лимита загрузки программного обеспечения данными, который приведет к сбою работы системы, а также длительности и объема максимальной загрузки за определенный период.

Цель: убедиться, что приложение/система успешно функционирует в следующих сценариях большого объема:

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

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

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

Критерий завершенности: все запланированные тесты выполнены, заданные предельные значения системы достигнуты/превышены без сбоя программного обеспечения.

Тестирование контроля доступа и безопасности

ТКДБ ориентировано на два ключевых направления безопасности:

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

· безопасность системы, обеспечивающая доступ к системе (включая регистрацию/дистанционный доступ) только некоторым пользователям.

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

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

Критерий завершенности: для каждого известного типа пользователя доступны соответствующая функция/данные, и все транзакции функционируют должным образом и выполняются в предыдущих тестах функциональных возможностей приложения.

Тестирование падения/восстановления

Тестирование падения/восстановления выявляет условия, при которых система или её отдельные приложения дают сбой, связанный с большой потерей данных.

Тестирование на падение позволяет обеспечить работоспособность системы за счет запуска резервных систем для сохранения данных.

Тестирование на восстановление (противоположный процесс) позволяет запустить проверку системы после возникновения сбоя на корректность работы приложений и сохранность БД.

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

- прерывание питания клиенту

- прерывание питания на сервере

- прерывание связи через сетевой сервер(ы)

- прерывание, связь или потеря мощности для контроллеров DASD и/или DASD

- неполные циклы (процессы фильтра данных прерваны, процессы синхронизации данных прерваны)

- неверный указатель базы данных/ключи

- недопустимый/поврежденный элемент данных в базе данных.

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

- Прерывание питания клиенту: выключите компьютер

- Прерывание питания на сервере: моделирование или инициирование процедур выключения сервера

- Прерывание через сетевые серверы: имитировать или инициировать потерю связи с сетью (физически отключать линии связи или отключать сетевой сервер(ы)/маршрутизаторы)

- Прерывание, связь или потеря мощности для контроллеров DASD и / или DASD: имитировать или физически устранить связь с одним или несколькими контроллерами или устройствами DASD.

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

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

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

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

...