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

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

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

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

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

ПО анализа рисков, присутствующее на рынке по состоянию на 1998 год было рассмотрено в [1]. Рассмотрим современное состояние этого рынка и основные тенденции его развития.

В 2000 году был принят международный стандарт ISO 17799, за основу которого был взят Британский стандарт BS 7799, рассмотрений в [1,2]. В результате большинство инструментальных средств (ПО анализа и управления рисками) было в последнее время модифицировано таким образом, чтобы обеспечить соответствие требованиям этого стандарта.

В обзоре ПО условно разделено на 2 группы:

• ПО базового уровня;

• ПО полного анализа рисков.

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

4.1 Инструментарий базового уровня

Вначале рассмотрим инструментарий, соответствующий ISO17799:

• Справочные и методические материалы.

• ПО анализа рисков и аудита «Cobra».

• ПО анализа рисков и аудита «Software Tool».

4.1.1 Справочные и методические материалы

Ряд Британских фирм [9] предлагает следующие продукты:

• Information Security Police

• SOS - INTERACTIVE 'ONLINE' SECURITY POLICIES AND SUPPORT

• Security Professionals Guide

Эти продукты представляют собой справочники, посвященные практическим аспектам реализации политики безопасности в соответствии с ISO17799, вид справочника приводится на рис. 4.1. Демонстрационные версии (Evaluation version) можно загрузить с сайта [11].

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

Еще один продукт подобного рода — «THE ISO17799 TOOLKIT» - текст стандарта ISO17799 с комплектом методических материалов и презентацией [11].

4.1.2 COBRA

ПО COBRA [9], производитель — C & A Systems Security Ltd., позволяет формализовать и ускорить процесс проверки на соответствие режима информационной безопасности требованиям Британского стандарта BS 7799 (ISO 17799) и провести анализ
Сильной стороной данного метода является возможность описания разноплановых взаимосвязей, адекватного учета многих факторов риска.

4.2.2 АванГард

В настоящее время на российском рынке продается отечественное ПО «АванГард», разработка института системного анализа РАН, подробное описание в [15].

«АванГард» позиционируется как экспертная система управления информационной безопасностью. Предлагаются две версии метода: «АванГард-Анализ» — для проведения анализа рисков, «АванГард-Контроль» — управление рисками. Структура и функции комплекса приводятся на рис. 4.9.

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

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

Оценка и анализ рисков нарушений ИБ

Оценка эффективности мер и мероприятий по защите Оценка по критерию «эффективность-стоимость» вариантов комплексов мероприятий по защите

Построение профилей защиты критических составляющих Контроль и анализ выполнения мер и требований по обеспечению ИБ
The various incident classes associated with this threat are shown in the following table: Incident Class SLE ALE % of total ALE Delays/Denials, Communications Equipment $26,401. $52,801. 68.0% Delays/Denials, Data/Information $4,400. $8,800. 11.3% Delays/Denials, Physical Inventory/Product $2,750. $5,500. 7.1% Direct Loss, Cash $2,200. $4,400. 5.7% Delays/Denials, Production Resources $1,100. $2,200. 2.8% Direct Loss, Physical Inventory/Product $1,100. $2,200. 2.8% Direct Loss, Data/Information $550. $1,100. 1.4% Direct Loss, Production Resources $275. $550. 0.7% Direct Loss, Communications Equipment $39. $77. 0.1% Табл 6. Фрагмент отчета
Рис. 4.14 Результирующие оценки по одной из угроз (кражи) • Задается частота возникновения каждой из выделенных угроз, степень уязвимости и ценность ресурсов. Все это используется в дальнейшем для расчета эффективности внедрения средств защиты.

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

Для рисков рассчитываются математические ожидания потерь за год по формуле:

m = p * v

где p — частота возникновения угрозы в течении года, v — стоимость ресурса, который подвергается угрозе.

Например, если стоимость сервера $150000, а вероятность того, что он будет уничтожен пожаром в течение года равна 0.01, то ожидаемые потери составят $1500.

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

4) Четвертая фаза — генерация отчетов (Табл. 6). Типы отчетов:

• Краткие итоги.

• Полные и краткие отчеты об элементах, описанных на стадиях 1 и 2.

• Отчет о стоимости защищаемых ресурсов и ожидаемых потерь от реализации угроз.

• Отчет об угрозах и мерах противодействия.

• Отчет о результатах аудита безопасности.

Возможности RiskWatch

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

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

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

4.2.4 CRAMM

Метод анализа и управления рисками CRAMM, разработанный Британской правительственной организацией CCTA, в России в настоящее время используется несколькими компаниями — системными интеграторами.

Возможности версии CRAMM 3.2 были рассмотрены в [1]. Отличительными особенностями новой версии CRAMM 4.0 являются:

• Соответствие стандарту BS 7799 (ISO 17799).

• Увеличено количество возможных отчетов, добавлены возможности управления их содержанием.

• Добавлены новые классы информационных ресурсов.

• Существенно расширена база данных по контрмерам.

В области обеспечения соответствия стандарту BS 7799, наиболее важным нововведением является возможность генерации отчетов:

• Политика информационной безопасности. • Система управления информационной безопасностью.

• План обеспечения бесперебойной работы.

• Ведомость соответствия.

Эти отчеты необходимы при проведении аудита информационной безопасности в соответствии с BS 7799. Метод CRAMM в настоящее время является наиболее часто используемым ПО, если требуется провести аудит в соответствии с требованиями Британского стандарта BS 7799.

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

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

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

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

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

Приложение_

Определения основных терминов, относящиеся к тематике анализа рисков, управления рисками

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

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

Полный (Full) анализ рисков [1] — анализ рисков для информационных систем, предъявляющих повышенные требования в области ИБ (более высокие, чем базовый уровень защищенности). Это предполагает:

• определение ценности ресурсов;

• оценку угроз и уязвимостей;

• выбор адекватных контрмер, оценку их эффективности.

Угроза (Threat) [1] — совокупность условий и факторов, которые могут стать причиной нарушения целостности, доступности, конфиденциальности.

Угроза ИБ [Threat] [14] — возможная опасность (потенциальная или реально существующая) совершения какого-либо деяния (действия или бездействия), направленного против объекта защиты (информационных ресурсов), наносящего ущерб собственнику, владельцу или пользователю, проявляющегося в опасности искажения и/или потери информации.

Источник угрозы [14] — это потенциальные антропогенные, техногенные или стихийные носители угрозы безопасности.

Последствия (атака) [14] — это возможные последствия реализации угрозы (возможные действия) при взаимодействии источника угрозы через имеющиеся факторы (уязвимости).

Как видно из определения, атака — это всегда пара «источник — фактор», реализующая угрозу и приводящая к ущербу.

Уязвимость (Vulnerability) [1] — слабость в системе защиты, которая делает возможной реализацию угрозы. Уязвимость (фактор) [Vulnerability] [14] Присущие объекту причины, приводящие к нарушению безопасности информации и обусловленные недостатками процесса функционирования объекта, свойствами архитектуры АС, протоколами обмена и интерфейсами, применяемыми ПО и аппаратной платформой, условиями эксплуатации.

Анализ рисков[1] — процесс определения угроз, уязвимостей, возможного ущерба, а также контрмер.

Терминология и определения на английском языке. Определения взяты из глоссария [16] и даются в переводе.

Риск (risk)

• Ожидаемые потери или возможный результат реализации угрозы при наличии уязвимости и определенных обстоятельств или событий, приводящих к реализации угрозы. [FCvl], [AJP].

• Возможность того, что определенная угроза реализуется вследствие наличия определенной уязвимости системы. [AJP].

• Вероятность потерь вследствие того, что определенная угроза при наличии определенной уязвимости реализуется и приведет к негативным последствиям. [RFC2828].

• Возможность потери из-за одной или более угроз для информационных ресурсов (не путать с финансовым или деловым риском) [RFC2828].

• Ситуация, в которой существует уязвимость и потенциальный нарушитель имеет возможность и желание воспользоваться ею. [IATF] .

• Возможность того, что специфическая уязвимость будет использована. [AFSEC].

• Потенциал, который данная угроза имеет вследствие наличия уязвимости информационных ресурсов. В результате реализации этого потенциала организации может быть причинен вред. [ISO/IEC PDTR 13335-1 (11/2001)] [SC27].

• Вероятность того, что специфическая угроза реализуется вследствие наличия специфической уязвимости системы. [NCSC/TG004].

Анализ риска (risk analysis)

• Процесс идентификации рисков, определение их величины и выделение областей, требующих защиты. Анализ риска — часть управления рисками. [AJP] [NCSC/TG004].

• Систематический процесс оценки величины рисков. [ISO/IEC PDTR 13335-1 (11/2001)] [SC27].

Оценка риска (risk assessment)

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

• (C) Составление списка рисков, ранжированных по цене и критичности. Список позволяет определить, где контрмеры должны примениться в первую очередь. Обычно невозможно предложить контрмеры, снижающие все аспекты рисков до нуля, и некоторые остаточные риски останутся даже после того, как все доступные (по цене) контрмеры были применены. [FP031, R2196] [RFC2828].

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

• Процесс, в который входят: идентификация риска, анализ риска, оценка риска. [ISO/IEC PDTR 13335-1 (11/2001)].

• Оценка угроз, воздействия на уязвимости информационных ресурсов и информационных процессов а также вероятности их возникновения ISO/IEC 17799: 2000] [SC27].

Идентификация риска — процесс идентификации рисков, при котором рассматриваются бизнес-цели, угрозы и уязвимость, как основа для дальнейшего анализа. [ISO/IEC PDTR 13335-1 (11/2001)] [SC27].

Управление рисками (risk management)

• Процесс идентификации, управления, устранения или уменьшения вероятности событий, которые могут негативно воздействовать на системные ресурсы системы. [RFC2828] .

• Процесс, включающий идентификацию, управление и устранение или уменьшение вероятности событий, которые могут затрагивать информационные ресурсы системы. [ISO/IEC PDTR 13335-1 (11/2001)].

• Процесс идентификации, управления и уменьшения рисков безопасности, которые могут воздействовать на информационную систему при условии приемлемой стоимости комплекса. [ISO/IEC 17799: 2000] [SC27] . • Процесс идентификации, управления, устранения или уменьшения вероятности событий, которые могут негативно воздействовать на системные ресурсы системы. Этот процесс включает анализ риска, анализ стоимость/эффективность, выбор, построение и испытание подсистемы безопасности и исследование всех аспектов безопасности. [AJP] [NCSC/TG004].

• Процесс идентификации, управления, устранения или уменьшения потенциального воздействия возможных происшествий. Цель процедуры управления риском состоит в том, чтобы уменьшить риски до уровней, одобренных DAA (Designated Approving Authority — лицо, уполномоченное выбрать уровни рисков). [NSAINT] [AFSEC].

Учет рисков (risk treatment) процесс планирования системы управления рисками, основанный на оценке рисков. [ISO/IEC PDTR 13335-1 (11/2001)] [SC27] .

Уязвимость (vulnerability)

• Слабость в защите, которая может быть объектом воздействия (например, из-за неверно проведенного анализа, планирования или реализации системы защиты).

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

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

[AJP].

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

• (C) Большинство систем имеют уязвимости в программном обеспечении, но из этого не следует, что информационные системы нельзя использовать по причине их возможных брешей. Не каждая угроза в случае ее реализации или атака приведет к успеху. Успех зависит от степени уязвимости, потенциала угрозы (атаки) и эффективности используемых контрмер. Если для реализации угрозы необходимо наличие уязвимости, которая практически не возникает, тогда с существованием уязвимости можно примириться. Если потенциальная выгода от осуществления атаки невелика, тогда может быть терпима даже уязвимость, которую можно легко использовать. Но если некоторый тип атаки хорошо известен и потенциально легко осуществим для большого числа пользователей, тогда, вероятно, найдется желающий осуществить нападение. [RFC2828]. • Слабость защиты в объекте потенциальной атаки (например, из-за недоработок на стадиях анализа, проектирования, построения системы или эксплуатации). [ITSEC].

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

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

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

• Слабость в процедурах обеспечения безопасности, системном проекте, реализации, системе управления и т.д., которая может способствовать нарушению политики безопасности. [NCSC/TG004].

• Слабость ресурса или группы ресурсов информационной системы, которая может способствовать реализации угрозы. [SC27] [ISO/IEC PDTR 13335-1 (11/2001)].

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

Анализ уязвимости (vulnerability analysis)

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

• Систематически проводимая экспертиза информационной системы, позволяющая определить адекватность мер защиты, идентифицировать погрешности в построении защиты, собрать исходные данные, чтобы оценить эффективность предложенных мер защиты. [SRV-BOOKS. [AJP] [NCSC/TG004].

Объект оценки (Target of Evaluation (TOE))

• Отдельные элементы информационной системы, результаты ее работы или вся система в целом, включая администратора, пользовательскую документацию и руководства, которая является объектом оценки. [CC2] [CC21] [IATF] [ISO/IEC 15408-1: 1999] [SC27].

• Отдельные элементы информационной системы, результаты ее работы или вся система в целом, которая рассматривается на предмет оценки защищенности. [AJP] [CC1] [ITSEC].

Оценка уязвимости (vulnerability assessment)

• Аспект оценки эффективности защиты объекта оценки (TOE), а именно: могла ли определенная уязвимость в объекте оценки на практике компрометировать (поставить под угрозу) его защиту. [ITSEC].

• Измерение уязвимости, которая включает восприимчивость исследуемой системы к определенному виду атаки и возможность агента угрозы осуществить нападение. [AJP] [SRVBOOKS] [NCSC/TG004].

Угроза (threat)

• Действие или событие, которое может нанести ущерб безопасности.

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

• Любое обстоятельство или события, которые потенциально могут причинить вред информационной системе в форме разрушения, раскрытия, модификации данных или отказа в обслуживании (DoS). [AJP]. • (I) потенциал для нарушения режима безопасности, который существует, когда складываются обстоятельства, производятся определенные действия или происходят события, которые могут нарушать режим безопасности и причинять вред.

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

• В некоторых контекстах, типа следующего, термин «Угроза» используется узко и относится только к умышленным угрозам:

• (N) В американских (U.S.) правительственных документах: способность враждебного юридического лица обнаруживать, эксплуатировать или выводить из строя дружественные информационные системы и намерение данного юридического лица (демонстрируемое или предполагаемое) заняться такой деятельностью. [RFC2828].

• Потенциальная причина нежелательного инци

дента, который может кончаться причинением ущерба информационной системе или организации. [SC27] . [ISO/IEC PDTR 13335-1

(11/2001)].

• Действие или случай, который мог бы нанести ущерб системе защиты. [ITSEC].

• Любое обстоятельство или случай, потенциально способные причинить вред системе в форме разрушения, раскрытия, модификации данных или отказа в обслуживании (DoS). [NCSC/TG004] [SRVBOOKS].

• Потенциал для реализации уязвимости. [SRV-BOOKS].

• Объект или события, которые потенциально могут навредить системе. [SRVBOOKS].

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

• Средства, при помощи которых агент угрозы намеривается причинить ущерб информационной системе, отдельным информационным ресурсам или операциям. [AFSEC] [NSAINT].

• Потенциально возможное нарушение защиты. [AFSEC] [NSAINT].

Jet Info

• Потенциал реализации уязвимости, имеющий последствием компрометацию защиты системы или сетей. Даже если уязвимость не известна, это представляет угрозу в соответствии с этим определением. [RFC2504].

Действие угрозы (threat action)

• Нападение на системную защиту. [RFC2828].

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

• Нападения.

• Случайные события.

•Различные виды возможных воздействий угрозы определяются как подклассы 'множества последствий угрозы'. [RFC2828].

Агент угрозы (threat agent)

• Метод, использующий уязвимость в системе, операциях (технологическом процессе) или отдельных средствах (элементах системы). [AJP] [NCSC/TG004] [SRVBOOKS].

• Методы и средства, основанные на использовании уязвимостей в информационной системе, операциях или средстве; пожар, природные катаклизмы и т.д. [AFSEC] [NSAINT].

Анализ угрозы (threat analysis)

• Оценка вероятности событий и анализ возможных последствий разрушительных действий к системе. [RFC2828].

• Экспертиза всех действий и событий, которые могли бы неблагоприятно воздействовать на систему или результат ее функционирования. [AFSEC] [AJP] [NCSC/TG004] [SRVBOOKS].

Процесс оценки угрозы (threat assessment) —

процесс формальной оценки степени серьезности угрозы информационной системе и описание характера угрозы. [AFSEC] [NSAINT].

Литература_

[1] С. Симонов. Анализ рисков, управление рисками. — Jet Info, 1, 1999

[2] С.В. Симонов. Методология анализа рисков в информационных системах «Конфидент» , №

1, 2001

[3] С.В. Симонов. Анализ рисков в информационных системах. Практические аспекты. «Конфидент» , № 2, 2001

[4] Обзор модели приводится на

[5] Risk Management Guide for Information Technology Systems, NIST, Special Publication 800-30

[6] Anne Marie Willhite Systems Engineering at MITRE Risk Management MP96B0000120, R1 September 1998



sk/sys_eng_mitre.html

[7] Risk Matrix



sk/risk_matrix.html

[8] Петренко С.А., Симонов С.В. Анализ и управление информационными рисками. «АйТи» 2003 (в печати)

[9] The ISO 17799 Service & Software Directory

[10] Сайт компании MethodWare

[11]

[12] Сайт компании RiskWatch .

[13] RA Software Tool Демо -версия метода:

[14] С. В. Вихорев, Р. Ю. Кобцев. Как узнать — откуда напасть или откуда исходит угроза безопасности информации. Конфидент, № 2 2002

[15] А. Кононов. Страхование нового века. Как повысить безопасность информационной инфраструктуры. // М. Connect № 12, 2001

[16] Глоссарий терминов по информационной безопасности Jet Info

ИНФОРМАЦИОННЫЙ БЮЛЛЕТЕНЬ

Издается с 1995 года

Главный редактор: Дмитриев В.Ю. () Технический редактор: Овчинникова ГЮ. () Россия, 127006, Москва, Краснопролетарская, 6 тел. (095) 972 11 82, 972 13 32 факс (095) 972 07 91

email:

Издатель: компания Джет Инфо Паблишер

Подписной индекс по каталогу Роспечати



Содержание раздела

---