Смарт ТВ 

Цель менеджмента рисков информационной безопасности. Управление рисками информационной безопасности в россии

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

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

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

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

Наконец, до сих пор не устоялось само определение риска в контексте проблемы информационной безопасности. Достаточно взглянуть на изменения в терминологии документа ISO Guide 73:2009 в сравнении с версией от 2002 года. Если раньше риск определялся как потенциал нанесения ущерба вследствие эксплуатации уязвимости какой-либо угрозой, то теперь это эффект отклонения от ожидаемых результатов. Аналогичные концептуальные изменения произошли и в новой редакции стандарта ISO/IEC 27001:2013.

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

Учитывая сказанное, с какой стороны лучше подойти к задаче оценки рисков информационной безопасности?

Свежий взгляд

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

  1. избегать излишней детализации;
  2. опираться на мнение бизнеса;
  3. использовать примеры;
  4. рассматривать внешние источники информации.

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

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

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

Факторы риска

Будем считать, что с составом оцениваемых активов мы определились. Далее необходимо идентифицировать угрозы и уязвимости, связанные с ними. Однако такой подход применим только при выполнении детального анализа рисков, где объектом оценки выступают объекты среды информационных активов. В новой версии стандарта ISO/IEC 27001:2013 фокус оценки рисков сместился с традиционных ИТ-активов на информацию и ее обработку. Поскольку на текущем уровне детализации мы рассматриваем укрупненные бизнес-процессы компании, достаточно идентифицировать только высокоуровневые факторы риска, присущие им.

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

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

Рис. 1. Бизнес-модель информационной безопасности

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

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

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

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

Персонал:

  • Недостаточная квалификация (ребро Human Factors на рис. 1)
  • Нехватка сотрудников (ребро Emergence)
  • Низкая мотивация (ребро Culture)

Процессы:

  • Частое изменение внешних требований (ребро Governing)
  • Неразвитая автоматизация процессов (ребро Enabling & Support)
  • Совмещение ролей исполнителями (ребро Emergence)

Технологии:

  • Устаревшее ПО (ребро Enabling & Support)
  • Низкая подотчетность пользователей (ребро Human Factors)
  • Гетерогенный ИТ-ландшафт (ребро Architecture)

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

Влияние на бизнес

Как следует из определения риска, он характеризуется степенью оказываемого влияния на бизнес-показатели организации. Удобным инструментом, позволяющим определить характер влияния сценариев реализации риска на бизнес, является система сбалансированных показателей (Balanced Scorecards). Не углубляясь в детали, отметим, что Balanced Scorecards выделяет у любой компании 4 бизнес-перспективы, связанные иерархическим образом (см. рис. 2).

Рис. 2. Четыре бизнес-перспективы системы сбалансированных показателей

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

Рис. 3. Основные показатели бизнеса

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

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

Задача анализа этих последствий является экспертной, поэтому она должна решаться с привлечением профильных бизнес-подразделений (правило 2). Для дополнительного контроля полученных оценок полезно использовать внешние источники информации, содержащие статистические данные о величине потерь в результате произошедших инцидентов (правило 4), например, ежегодный отчет «Cost of Data Breach Study».

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

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

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

Для оценки можно использовать простую 3-уровневую шкалу, где:

3 - реализованные контрмеры в целом достаточны;

2 - контрмеры реализованы недостаточно;

1 - контрмеры отсутствуют.

В качестве справочников с описанием контрмер можно использовать профильные стандарты и руководства, например CobiT 5, ISO/IEC 27002 и др. Каждая контрмера должна быть связана с конкретным фактором риска.

Важно помнить, что мы анализируем риски, связанные не только с использованием ИТ, но и с организацией внутренних информационных процессов в компании. Поэтому и контрмеры нужно рассматривать шире. Не зря в новой версии ISO/IEC 27001:2013 есть оговорка, что при выборе контрмер необходимо использовать любые внешние источники (правило 4), а не только Annex A, присутствующий в стандарте в справочных целях.

Величина риска

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

Табл. 1. Матрица оценки риска

В том случае, если фактор риска затрагивает несколько бизнес-перспектив, например «Клиенты» и «Финансы», их показатели суммируются. Размерность шкалы, а также допустимые уровни рисков ИБ можно определять любым удобным способом. В приведенном примере высокими считаются риски, имеющие уровень 2 и 3.

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

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

Детальная оценка

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

Все это применимо и для других областей оценки. При изменении детализации узла «People» объектами оценки могут стать роли персонала или даже отдельные сотрудники. Для узла «Process» ими могут быть конкретные рабочие регламенты и процедуры.

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

  • степень влияния риска на бизнес-перспективы;
  • достаточность контрмер.

Российский синдром

Выход стандарта ISO/IEC 27001:2013 поставил многие российские компании в непростое положение. С одной стороны, у них уже сложился определенный подход к оценке рисков ИБ, основанный на классификации информационных активов, оценке угроз и уязвимостей. Национальные регуляторы успели выпустить ряд нормативных актов, поддерживающих этот подход, например, стандарт Банка России, приказы ФСТЭК. С другой стороны, в задаче оценки рисков давно назрела необходимость изменений, и теперь нужно модифицировать устоявшийся порядок, чтобы он отвечал и старым, и новым требованиям. Да, сегодня всё еще можно пройти сертификацию по стандарту ГОСТ Р ИСО/МЭК 27001:2006, который идентичен предыдущей версии ISO/IEC 27001, но это ненадолго.

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

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

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

В этой части рассмотрены следующие вопросы:

  • Управление безопасностью
  • Распределение обязанностей по управлению безопасностью
  • Подход "сверху-вниз"
  • Администрирование безопасности и защитные меры
  • Основные принципы безопасности (AIC-триада)
  • Доступность
  • Целостность
  • Конфиденциальность
  • Определения безопасности (уязвимость, угроза, риск, воздействие, контрмеры)
  • Безопасность посредством неизвестности

Обновлено: 21.02.2010


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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

  • Административные меры включают в себя разработку и публикацию политик, стандартов, процедур и руководств, управление рисками, подбор персонала, проведение тренингов по вопросам безопасности, внедрение процедур управления изменениями.
  • Т ехнические (логические) меры включают внедрение и поддержку механизмов управления доступом, управления паролями и ресурсами, методами идентификации и аутентификации, устройствами безопасности, а также настройками инфраструктуры.
  • Ф изические меры включают в себя контроль доступа людей в здание и различные помещения, использование замков и удаление неиспользуемых дисководов и приводов CD-ROM, защиту периметра здания, выявление вторжений, контроль окружения.
Рисунок 1-1 иллюстрирует совместную работу административных, технических и физических мер безопасности, обеспечивающую необходимый уровень защиты.

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


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

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

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

Существует несколько маленьких и больших задач программы безопасности, но 3 основных принципа есть во всех программах: доступность, целостность и конфиденциальность. Это называется AIC-триадой (Availability, Integrity, Confidentiality). Уровень безопасности, необходимый для реализации этих принципов, отличается в различных компаниях, так как каждая компания имеет собственное уникальное сочетание целей бизнеса и безопасности, а также потребностей. Все защитные меры и механизмы безопасности внедряются для реализации одного (или нескольких) из этих принципов, а все риски, угрозы и уязвимости измеряются по их потенциальной способности нарушения одного или всех принципов AIC. AIC-триада показана на Рисунке 1-2.

Рисунок 1-2 AIC-триада


Доступность

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


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

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

Целостность

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


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

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

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



Конфиденциальность

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


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

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




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

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

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

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

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

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

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

Рисунок 1-3 Взаимосвязь между различными компонентами безопасности


Ссылки

Риск информационной безопасности (information security risk) - «возможность того, что данная угроза сможет воспользоваться уязвимостью актива или группы активов и тем самым нанесет ущерб организации» .

В соответствии с ГОСТ Р 51897-2011 «Менеджмент риска. Термины и определения» и международным стандартом ISO 27001-2013 «Система управления информационной безопасностью» - процесс управления рисками представляет собой скоординированные действия по управлению и контролю организации в отношении риска информационной безопасности. Управление рисками включает в себя оценку риска, обработку риска, принятие риска и сообщение о риске.

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

Базовый уровень безопасности (baseline security) - обязательный минимальный уровень защищенности для ИС. В ряде стран существуют критерии для определения этого уровня. В качестве примера приведем критерии Великобритании - ССТА Baseline Security Survey, определяющие минимальные требования в области ИБ для государственных учреждений этой страны. В Германии эти критерии изложены в стандарте BSI.

Существуют критерии ряда организаций - NASA, X/Open, ISACA и другие. В нашей стране это может быть класс защищенности в соответствии с требованиями ФСТЭК России, профиль защиты, разработанный в соответствии со стандартом ISO-15408, или какой-либо другой набор требований.

Тогда критерий достижения базового уровня безопасности - это выполнение заданного набора требований.

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

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

Согласно ГОСТ Р ИСО/МЭК 27005-2010 процесс менеджмента ИБ состоит из этапов, представленных на рис. 1.

Оценка риска

Анализ риска

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

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

  • 0 х:
    • (Ъ о;

Оценка риска

Вторая точка принятия решения. . Результат обработки риска удовлетворительный?

Рис. 1.

Согласно ГОСТ Р ИСО/МЭК 27005-2010 процесс оценки риска состоит из анализа риска и собственно оценки риска.

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

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

Следуя рекомендациям ГОСТ Р ИСО/МЭК 27002-2012 оценки рисков следует выполнять периодически, чтобы учитывать изменения в требованиях безопасности и в ситуации, связанной с риском, например, в отношении активов, угроз, уязвимостей, воздействий, оценивания рисков.

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

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

В результате оценки риска согласно ГОСТ Р ИСО/МЭК 27003-2012 необходимо:

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

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

  • 1. Определение активов.
  • 2. Определение угроз.
  • 3. Выявление уязвимостей.
  • 4. Определение последствий.
  • 5. Оценка вероятности инцидента.
  • 6. Установление значений уровня рисков.
  • 7. Соотнесение рисков с критериями.
  • 8. Определение мер обработки риска.

Схема деятельности по обработке риска показана на рис. 2.

Удовлетворительная

Первая точка принятия решения. Результат оценки риска удовлетворительный?

ОБРАБОТКА РИСКА


Рис. 2.

с ГОСТ Р ИСО/МЭК 27005-2010

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

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

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

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

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

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

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

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

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

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

Информация, полученная на этапе идентификации рисков, используется в процессе анализа рисков для определения:

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

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

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


Рис. 3.

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

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

Следующим этапом анализа рисков является оценка вероятности реализации угроз.

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

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

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

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

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

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

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

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

Для решения задачи оценки рисков информационной безопасности классическими являются следующие программные комплексы: CRAMM, FRAP, RiskWatch, Microsoft Security Assessment Tool (MSAT), ГРИФ, CORAS и ряд других. Все известные методики можно классифицировать следующим образом :

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

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

В табл. 1 представлен сравнительный анализ классических методик (CRAMM, ГРИФ, RiskWatch, CORAS, MSAT).

Таблица 1

Сравнение программного инструментария для управления рисками ИБ

Критерии сравнения

ГРИФ

RiskWatch

Риски

Использование понятия максимально допустимого риска

Подготовка плана мероприятий по снижению рисков

Управление

Информирование руководителя

План работ по снижению рисков

Включает проведение тренингов, семинаров, собраний

Оценка бизнес-рисков/операционных рисков/ИТ-рисков

Оценка рисков на организационном уровне

Оценка рисков на техническом уровне

Предлагаемые способы снижения рисков

Обход (предотвращение) риска

Снижение риска

Принятие риска

Процессы

Использование элементов риска

Материальные активы

Нематериальные активы

Ценность активов

Уязвимости

Меры безопасности

Потенциальный ущерб

Вероятность реализации угроз

Критерии сравнения

Рассматриваемые типы рисков

Бизнес-риски

Риски, связанные с нарушением законодательных актов

Риски, связанные с использованием технологий

Коммерческие риски

Риски, связанные с привлечением третьих лиц

Риски, связанные с привлечением персонала

Способы измерения величин рисков

Качественная оценка

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

Способы управления

Качественное ранжирование рисков

Использование независимой оценки

Расчет возврата инвестиций

Расчет оптимального баланса между различными типами мер безопасности, такими как:

Меры предотвращения

Меры выявления

Меры по исправлению

Меры по восстановлению

Интеграция способов управления

Описание назначения способов управления

Процедура принятия остаточных рисков

Управление остаточными рисками

Мониторинг рисков

Применение мониторинга эффективности мер ИБ

Проведение мероприятий по снижению рисков

Использование процесса реагирования на инциденты в области ИБ

Структурированное документирование результатов оценок рисков

Примечание: Таблица сравнения программного инструментария для анализа и оценки рисков приводится по материалам статьи: Баранова Е.К., Чернова М.В. Сравнительный анализ программного инструментария для анализа и оценки рисков информационной безопасности // Проблемы информационной безопасности. Компьютерные системы. -

2014.-№4.- С. 160-168.

Оценка С RAMM

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

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

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

Оценка ГРИФ

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

Оценка RiskWatch

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

Оценка CORAS

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

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

Оценка MSA Т

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

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

Рассмотренные методики хорошо соответствуют требованиям групп «Риски» и «Процессы (Использование элементов риска)», но некоторые из них (CRAMM, CORAS) имеют недостатки в соответствии с разделами «Мониторинг» и «Управление», а также со многими подразделами «Процессы». Немногие (ГРИФ, RiskWatch, MSAT) дают подробные рекомендации по поводу составления расписания проведения повторных оценок рисков.

В тех случаях, когда требуется выполнить только разовую оценку уровня рисков в компании среднего размера, целесообразно рекомендовать использование методики CORAS. Для управления рисками на базе периодических оценок на техническом уровне лучше всего подходит CRAMM. Методики Microsoft Security Assessment Tool и RiskWatch предпочтительны для использования в крупных компаниях, где предполагается внедрение управления рисками ИБ на базе регулярных оценок, на уровне не ниже организационного и требуется разработка обоснованного плана мероприятий по их снижению.

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

  • ГОСТ Р ИСО/МЭК 13335-1-2006. Информационная технология. Методы и средства обеспечения безопасности. Часть 1. Концепция и модели менеджмента безопасности информационных и телекоммуникационных технологий.
  • Баранова Е.К. Методики и программное обеспечение для оценки рисков в сфере информационной безопасности // Управление риском. - 2009. - № 1(49). - С. 15-26.
  • Баранова Е. К. Методики анализа и оценки рисков информационной безопасности// Вестник Московского университета им. С.Ю. Витте. Серия 3: Образовательные ресурсы и технологии. - 2015. - № 1(9). - С. 73-79.

    • «Ничто так не удивляет людей, как здравый смысл и действия по плану».

    Ральф Эмерсон, американский писатель

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

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

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

    ___________________________________

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

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

    ______________________________________

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

    Приоритетизация мер по обработке рисков может осуществляться следующим образом:

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

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

    3. Повышается приоритет контрмер, обеспечивающих наибольший возврат инвестиций ROI.

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

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

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

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

    • Для комментирования войдите или зарегистрируйтесь

    На практике применяются количественный и качественный подходы к оценке рисков ИБ. В чем их разница?

    Количественный метод

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

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

    Как провести количественную оценку рисков?

    1. Определить ценность информационных активов в денежном выражении.

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

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

    3. Определить вероятность реализации каждой из угроз ИБ.

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

    4. Определить общий потенциальный ущерб от каждой угрозы в отношении каждого актива за контрольный период (за один год).

    Значение рассчитывается путем умножения разового ущерба от реализации угрозы на частоту реализации угрозы.

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

    По каждой угрозе необходимо принять решение: принять риск, снизить риск либо перенести риск.

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

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

    Перенести риск — значит переложить последствия от реализации риска на третье лицо, например с помощью страхования.

    В результате количественной оценки рисков должны быть определены:

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

    Количественный анализ рисков информационной безопасности (пример)

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

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

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

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

    Качественный метод

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

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

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

    Как провести качественную оценку рисков:

    1. Определить ценность информационных активов.

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

    2. Определить вероятность реализации угрозы по отношению к информационному активу.

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

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

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

    4. Сделать вывод об уровне риска на основании ценности информационного актива, вероятности реализации угрозы, возможности реализации угрозы.

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

    5. Провести анализ полученных данных по каждой угрозе и полученному для нее уровню риска.

    Часто группа анализа рисков оперирует понятием «приемлемый уровень риска». Это уровень риска, который компания готова принять (если угроза обладает уровнем риска меньшим или равным приемлемому, то она не считается актуальной). Глобальная задача при качественной оценке — снизить риски до приемлемого уровня.

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

    Какой метод выбрать?

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

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

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

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

    Станислав Шиляев , руководитель проектов по информационной безопасности компании «СКБ Контур»