Как управлять рисками информационной безопасности? Как оценить риски информационной безопасности


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



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

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

Следующие вопросы должны быть учтены при определении ценности активов:

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

Определение стоимости активов полезно для компании по целому ряду причин, включая следующие:

  • Для проведения анализа затраты/выгоды (cost/benefit analyse)
  • Для выбора конкретных контрмер и защитных средств
  • Для определения необходимого уровня страхового покрытия
  • Для понимания, чем именно рискует компания
  • Для выполнения требований законодательства, регуляторов, соблюдения должной заботы (due care)
Активы могут быть материальным (компьютеры, оборудование, материалы) или нематериальные (репутация, данные, интеллектуальная собственность). Обычно трудно оценить количественно ценность нематериальных активов (например, репутации), которая может меняться с течением времени.


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

Таблица 1-2 Взаимосвязь угроз и уязвимостей

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

После выявления уязвимостей и связанных с ними угроз должны быть проанализированы последствия их использования, т.е. риски потенциального ущерба. Ущерб может быть связан с повреждением данных или систем (объектов), несанкционированным разглашением конфиденциальной информации, снижением производительности работы и т.д. При проведении анализа рисков, группа должна также рассмотреть вероятный отложенный ущерб (delayed loss), который может произойти по прошествии некоторого времени (от 15 минут до нескольких лет) после реализации риска. Отложенный ущерб может быть вызван, например, снижением производительности работы через определенный период времени, снижением дохода компании, ущербом ее репутации, накопительными штрафами, дополнительными расходами на восстановление окружения, приостановкой приема средств от клиентов и т.д.

Например, если в результате атаки на веб-серверы компании они перестали обслуживать клиентов, непосредственным ущербом может быть повреждение данных, затраты рабочего времени на восстановление работы серверов, обновление уязвимого программного обеспечения на них. Кроме того, компания потеряет определенный доход в следствие невозможности обслуживания клиентов в течение времени, которое потребуется ей на восстановление работы своих веб-серверов. Если восстановительные работы займут значительное время (например, неделю), компания может потерять настолько большой объем прибыли, что будет уже не в состоянии оплачивать счета и другие расходы. Это и будет являться отложенным ущербом. А если кроме всего прочего компания еще и потеряет доверие клиентов, она может полностью потерять свой бизнес (на некоторое время или навсегда). Это является крайним случаем отложенного ущерба.

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

Методики оценки рисков. Для оценки рисков используется множество различных методик. Давайте рассмотрим некоторые из них.
NIST SP 800-30 и 800-66 являются методологиями, которые могут использоваться коммерческими компаниями, хотя 800-66 изначально разрабатывалась для здравоохранения и других регулируемых отраслей. Подход NIST учитывает угрозы ИТ и соответствующие риски информационной безопасности. Он предусматривает следующие шаги:
  • Описание характеристик системы
  • Идентификация угроз
  • Идентификация уязвимостей
  • Анализ защитных мер
  • Определение вероятности
  • Анализ воздействия
  • Определение риска
  • Рекомендации защитных мер
  • Документирование результатов
Методология оценки рисков NIST SP 800-30 часто используется консультантами и специалистами по безопасности, внутренними ИТ-подразделениями. Она ориентируется в основном на компьютерные системы. Отдельные люди или небольшие группы собирают данные из сети, из используемых практик по безопасности, а также от людей, работающих в компании. Собранные данные используются в качестве исходных данных для выполнения шагов анализа рисков, описанных в документе 800-30.
Другой методологией оценки рисков является FRAP (Facilitated Risk Analysis Process – Групповой процесс анализа рисков). Она создана для проведения качественной оценки рисков способом, который позволяет вести проверки по различным аспектам и с использованием различной методологии. Она предоставляет способы, позволяющие компании принимать решения о направлении действий и конкретных действиях в конкретных обстоятельствах для учета различных проблем. Это дает возможность посредством предварительного отбора определить те области в компании, которые действительно нуждаются в анализе рисков. FRAP построен таким образом, что любой человек с хорошими навыками организации групповой работы сможет успешно провести анализ рисков по этой методике.
Еще одним видом методологии является OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation – Оценка критичных угроз, активов и уязвимостей). Это методология, которую следует применять в ситуациях, когда весь процесс анализа рисков информационной безопасности проводится силами сотрудников компании (без привлечения внешних консультантов). Она основана на идее, что сотрудники компании лучше всех понимают, что действительно нужно компании, и перед лицом каких рисков она стоит. Выбранные для участия в процессе оценки сотрудники сами решают, какой подход будет наилучшим для оценки безопасности их компании.
В то время, как методологии NIST и OCTAVE направлены на угрозы ИТ и риски информационной безопасности, AS/NZS 4360 использует гораздо более широкий подход к управлению рисками. Эта методология может использоваться для понимания рисков компании в области финансов, защиты людей, принятия бизнес-решений и т.д. Она не была разработана специально для анализа рисков безопасности, хотя может успешно использоваться и для этой цели.
ПРИМЕЧАНИЕ. Вы можете найти дополнительную информацию по этим подходам к анализу рисков и их использованию в статье Шон Харрис на странице http://searchsecurity.techtarget.com/generic/0,295582,sid14_gci1191926,00.html .

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


Анализ связующего дерева (Spanning Tree Analysis) – это методология, которая создает дерево всех потенциальных угроз и недостатков, которые могут нарушить работу системы. Каждая ветвь является обобщенной темой или категорией, неприменимые ветви могут удаляться в процессе проведения анализа рисков.

FMEA (Failure Modes and Effect Analysis) – это метод определения функций, выявления функциональных дефектов, оценки причин дефекта и его последствий с помощью структурированного процесса. Применение этого процесса в случае постоянных дефектов позволяет определить место, где ошибка, скорее всего, произойдет. Это очень помогает выявить уязвимые места, точно определить границы уязвимостей и последствия их эксплуатации. В свою очередь, это позволяет не только упростить применение исправлений, устраняющих уязвимости, но и обеспечить более эффективное использование ресурсов в рамках этой задачи.

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

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

В таблице 1-3 приведен пример проведения и документирования FMEA. Хотя большинство компаний не имеют ресурсов для столь детальной проработки каждой системы и контроля, она должна проводиться для критичных функций и систем, которые могут оказать существенное влияние на компанию. Очень важно проанализировать защитную меру или систему от микро- до макро-уровня, чтобы в полной мере понять, где могут находиться потенциальные уязвимости или дефекты и каковы последствия эксплуатации этих недостатков. Каждая компьютерная система может состоять из множества различных временных бомб на разных уровнях ее структуры. На уровне компонентов это может быть переполнение буфера или опасные компоненты ActiveX, что может позволить злоумышленнику получить контроль над системой, воспользовавшись уязвимостью. На программном уровне приложение может небезопасно проводить авторизацию или может не защищать свои криптографические ключи должным образом. На системном уровне ядро операционной системы может иметь недостатки, что позволит злоумышленнику без особого труда получить административный доступ. Различные ужасные вещи могут произойти на любом уровне, поэтому необходим столь детальный подход.

Таблица 1-3 Пример проведения и документирования FMEA

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

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

Рисунок 1-7 Дерево сбоев и логические элементы


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

Некоторые из наиболее распространенных программных сбоев, которые могут быть исследованы с помощью анализа дерева сбоев, приведены ниже:

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

НИУ ИТМО, *****@***com

Научный руководитель - д. т.н., профессор НИУ ИТМО, *****@

Аннотация

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

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

Введение

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

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

    вероятность существования угрозы; вероятность существования уязвимости (незащищенности); потенциальное воздействие.

Если любая из этих переменных приближается к нулю, полный риск так же стремится к нулю.

Методы оценки рисков

ISO/IEC 27001. В отношении методологии расчета значения риска сказано: выбранная методология должна гарантировать, что оценки риска дают сравнимые и воспроизводимые результаты. При этом в стандарте не приводится конкретной формулы расчета.

NIST 800-30 предлагает классическую формулу расчета риска:

где R - значение риска;

P(t) - вероятность реализации угрозы ИБ (применяется смесь качественной и количественной шкалы);

S - степень влияния угрозы на актив (цена актива в качественной шкале и количественной).

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

ГОСТ Р ИСО/МЭК ТО 7. Расчет риска, в отличии от стандарта NIST 800-30 происходит по трем факторам:

R = P(t) * P(v) * S,

где R - значение риска;

P(t) - вероятность реализации угрозы ИБ;

P(v) - вероятность наличия уязвимости;

S - ценность актива.

В качестве примера значений вероятностей P(t) и P(v) приведена качественная шкала с тремя уровнями: низкая, средняя и высокая. Для оценки значения ценности актива S представлены числовые значения в интервале от 0 до 4. Сопоставление им качественных значений должна произвести организация, в которой производится оценка рисков информационной безопасности.

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

R = S * L(t) * L(v),

где R - значение риска;

S - ценность актива/ресурса;

L(t) - уровень угрозы;

L(v) - уровень/степень уязвимости.

На практике вычисление рисков ИБ происходит по таблице позиционирования значений уровня угроз, степени вероятности использования уязвимости и стоимости актива. Значение риска может изменятся в диапазоне от 0 до 8, в результате по каждому активу получается список угроз с различными значениями риска. Так же стандарт предлагает шкалу ранжирования рисков: низкий (0-2), средний (3-5) и высокий(6-8), что позволяет определить наиболее критичные риски.

СТО БР ИББС. Согласно стандарту оценка степени возможности реализации угрозы ИБ производится по качественно-количественной шкале, нереализуемая угроза - 0%, средняя - от 21% до 50% и т. д. Определение степени тяжести последствий для разных типов информационных активов так же предлагается оценивать с использованием качественно-количественной шкалы, т. е. минимальное - 0,5% от величины капитала банка , высокое - от 1,5% до 3% от величины капитала банка.

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

где R - значение риска;

P(v) - вероятность реализации угрозы ИБ;

S - ценность актива (степень тяжести последствий).

Предложенный метод

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

Таким образом предлагается разделить процедуру расчета риска на два этапа:

1. Вычисление значения технического риска.

2. Вычисление потенциального ущерба.

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

Rc = Kc * P(T) * P(V), Ri = Ki * P(T) * P(V),

Ra = Ka * P(T) * P(V),

где Rс - значение риска конфиденциальности;

Ri - значение риска целостности;

Ra - значение риска доступности;

Kс - коэффициент конфиденциальности информационного актива;

Ki - коэффициент целостности информационного актива;

Ka - коэффициент доступности информационного актива;

P(T) - вероятность реализации угрозы;

P(V) - вероятность использования уязвимости.

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

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

где L - значение ущерба;

Rср - среденее значение риска;

S - потери (в денежном эквиваленте).

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

Литература

1. ISO/IEC 27001. Международный стандарт содержит требования в области информационной безопасности для создания, развития и поддержания системы менеджмента информационной безопасности. 20с.

2. ГОСТ Р ИСО/МЭК ТО 7. Национальный стандарт Российской Федерации. Методы и средства обеспечения безопасности. Часть 3. Методы менеджмента безопасности информационных технологий. Москва. 20с.

3. BS 7799-2:2005 Спецификация системы управления информационной безопасностью. Англия. 20с.

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

5. Risk Management Guide for Information Technology Systems. Recommendations of the National Institute of Standards and Technology. США. 20с.

6. Электронный источник Википедия, статья "Риск" .

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

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

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

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

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

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

Определение целей управления информационной безопасностью

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

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

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

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

Цель управления ИБ состоит в сохранении конфиденциальности, целостности и доступности информации. Вопрос только в том, какую именно информацию необходимо охранять и какие усилия прилагать для обеспечения ее сохранности (рис. 1).

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

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

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

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

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

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

Но экономическая эффективность процесса управления ИБ во многом зависит именно от осознания того, что нужно защищать и какие усилия для этого потребуются, так как в большинстве случаев объем прилагаемых усилий прямо пропорционален объему затрачиваемых денег и операционных расходов. Управление рисками позволяет ответить на вопрос, где можно рисковать, а где нельзя. В случае ИБ термин «рисковать» означает, что в определенной области можно не прилагать значительных усилий для защиты информационных активов и при этом в случае нарушения безопасности организация не понесет значимых потерь. Здесь можно провести аналогию с классами защиты автоматизированных систем: чем значительнее риски, тем более жесткими должны быть требования к защите.

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

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

Анализ источников проблем

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

Модель нарушителя

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

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

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

Модель угроз

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

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

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

Идентификация уязвимостей

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

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

Оценка рисков

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

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

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

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

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

Принятие решения

Что же можно сделать с полученным результатом оценки?

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

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

Отчет об анализе рисков отражает следующие сведения:

  • наиболее проблемные области обеспечения ИБ в организации;
  • влияние угроз ИБ на общую структуру рисков организации;
  • первоочередные направления деятельности отдела ИБ по повышению эффективности обеспечения ИБ.

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

Политика обработки рисков

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

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

Подведем итоги

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

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

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

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

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

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

Отдел ИБ и организация в целом в случае структурирования своей деятельности путем непрерывного анализа рисков получают следующие весьма значимые преимущества:

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

В связи с управлением рисками и управлением ИБ необходимо отметить еще несколько моментов.

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

Установленный процесс анализа рисков - это обязательное требование стандарта СТО-БР ИББС-1.0-2006 по обеспечению информационной безопасности в банковской сфере.

Постановка процесса анализа рисков необходима организации, если в ней принято решение о прохождении сертификации на соответствие требованиям международного стандарта ISO/IEC 27001:2005.

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

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Подобные документы

    Природа банковской деятельности. Понятие и причины возникновения банковских рисков. Характеристика основных банковских рисков. Основные методы минимизации банковских расходов. Анализ минимизации банковских рисков на примере АО "Народный Банк Казахстана".

    курсовая работа , добавлен 06.12.2008

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

    реферат , добавлен 22.02.2017

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

    дипломная работа , добавлен 21.01.2015

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

    дипломная работа , добавлен 07.05.2014

    Функции и состав собственных и привлеченных средств кредитной организации. Изучение ресурсной базы российских коммерческих банков. Анализ собственного капитала, вкладов, долговых обязательств ЗАО "ЮниКредит Банк". Проблемы привлечения финансовых ресурсов.

    курсовая работа , добавлен 20.02.2013

    Риски в банковской деятельности. Уровень банковских рисков. Классификация рисков в банковском деле. Система оптимизации банковских рисков. Банковская система России - основные тенденции и перспективы развития.

    реферат , добавлен 28.09.2006

    Характеристика банка АО "ЮниКредит Банк". Структура и динамика активов и пассивов баланса. Факторный анализ процентных доходов и расходов от операций с ценными бумагами. Анализ платежеспособности, финансовой устойчивости банка и перспектив его развития.

    курсовая работа , добавлен 21.03.2016

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

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

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

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

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

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

Оценка информационных рисков компании может быть выполнена в соответствии со следующим планом:

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

Риски характеризуют опасность, которая может угрожать компонентам корпоративной информационной системы.

Информационные риски компании зависят от:

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

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

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

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

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

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

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

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

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

Для решения данной задачи были разработаны программные комплексы анализа и контроля информационных рисков: CRAMM, FRAP, RiskWatch, Microsoft, ГРИФ. Ниже приведены краткие описания ряда распространенных методик анализа рисков.

Распространенные методики анализа рисков:

  • ? методики, использующие оценку риска на качественном уровне (например, по шкале "высокий", "средний", "низкий"). К таким методикам, в частности, относится FRAP;
  • ? количественные методики (риск оценивается через числовое значение, например размер ожидаемых годовых потерь). К этому классу относится методика RiskWatch;
  • ? методики, использующие смешанные оценки (такой подход используется в CRAMM, методике Microsoft и т.д.).

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

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

  • ? коммерческий профиль;
  • ? правительственный профиль.

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

Результатом этого этапа является построение модели системы, с деревом связи ресурсов. Эта схема позволяет выделить критичные элементы. Ценность физических ресурсов в CRAMM определяется стоимостью их восстановления в случае разрушения.

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

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

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

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

Уровень угроз оценивается, в зависимости от ответов, как очень высокий, высокий, средний, низкий и очень низкий. Уровень уязвимости оценивается, в зависимости от ответов, как высокий, средний и низкий.

На основе этой информации рассчитываются уровни рисков в дискретной шкале с градациями от 1 до 7. Полученные уровни угроз, уязвимостей и рисков анализируются и согласовываются с заказчиком.

Основной подход, для решения этой проблемы состоит в рассмотрении:

  • ? уровня угрозы;
  • ? уровня уязвимости;
  • ? размера ожидаемых финансовых потерь.

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

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

На этой стадии CRAMM генерирует несколько вариантов мер противодействия, адекватных выявленным рискам и их уровням.

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

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

Недостатки метода CRAMM:

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