Управление ИТ-рисками - IT risk management

«Управление информационными рисками» перенаправляется сюда. О риске получения неточной информации см. Услуги по заверению.
Элементы управления рисками

Управление ИТ-рисками это применение управление рисками методы для информационные технологии чтобы управлять IT риск, то есть:

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

Управление ИТ-рисками можно рассматривать как компонент более широкого Управление рисками система.[1]

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

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

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

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

Вообще говоря, риск это произведение времени вероятности влияние (Риск = Вероятность * Воздействие).[4]

Мера ИТ-риска может быть определена как результат угрозы, уязвимости и актив значения:[5]

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

[6]


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

Определения

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


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

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

Отношения между субъектом ИТ-безопасности

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

Американец Национальный учебно-образовательный центр по обеспечению информационной безопасности определяет управление рисками в сфере ИТ как:[9]

  1. Полный процесс выявления, контроля и минимизации воздействия неопределенных событий. Целью программы управления рисками является снижение риска и получение и поддержание утверждения DAA. Этот процесс облегчает управление рисками безопасности на каждом уровне управления на протяжении всего жизненного цикла системы. Процесс утверждения состоит из трех элементов: анализ риска, сертификация и одобрение.
  2. Элемент управленческой науки, связанный с идентификацией, измерением, контролем и минимизацией неопределенных событий. Эффективная программа управления рисками включает следующие четыре этапа:
    1. а Оценка рисков, основанная на оценке угроз и уязвимостей.
    2. Управленческое решение.
    3. Осуществление контроля.
    4. Обзор эффективности.
  3. Полный процесс выявления, измерения и сведения к минимуму неопределенных событий, влияющих на ресурсы AIS. Это включает в себя анализ риска, анализ рентабельности, выбор средств защиты, тестирование и оценка защиты, внедрение средств защиты и анализ систем.
  4. Полный процесс выявления, контроля и устранения или минимизации неопределенных событий, которые могут повлиять на системные ресурсы. Он включает в себя анализ рисков, анализ затрат и выгод, выбор, внедрение и тестирование, оценку безопасности защитных мер и общий обзор безопасности.

Управление рисками как часть управления рисками предприятия

Некоторые организации имеют, а многие другие должны иметь комплексную Управление рисками (ERM) на месте. Четыре рассматриваемые объективные категории, согласно Комитет организаций-спонсоров Комиссии Тредуэя (COSO):

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

Согласно Рисковать IT рамки ISACA,[10] ИТ-риск распространяется на все четыре категории. Управление ИТ-риском должно осуществляться в рамках управления рисками предприятия: Склонность к риску и Чувствительность к риску всего предприятия должна определять процесс управления ИТ-рисками. ERM должна обеспечивать контекст и бизнес-цели для управления ИТ-рисками.

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

ENISA: процесс управления рисками в соответствии со стандартом ISO 13335

Хотя методология не описывает конкретные методы; тем не менее, он определяет несколько процессов (составляют общую структуру), которым необходимо следовать. Эти процессы могут быть разбиты на подпроцессы, они могут быть объединены или их последовательность может измениться. Упражнения по управлению рисками должны реализовывать эти процессы в той или иной форме. В следующей таблице сравниваются процессы, предусмотренные тремя ведущими стандартами.[3] В ISACA Рисковать IT рамки более свежие. Руководство для практикующего ИТ-специалиста по рискам[11] сравнивает риск IT и ISO 27005.

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

Общее сравнение показано в следующей таблице.

Составляющие процессы управления рисками
ISO / IEC 27005: 2008BS 7799-3: 2006NIST SP 800-39Рисковать IT
Установление контекстаОрганизационный контекстРамкаТочнее, домены RG и RE
  • RG1.2 Предложить толерантность к ИТ-рискам,
  • RG2.1 Создание и поддержание подотчетности за управление ИТ-рисками
  • RG2.3 Адаптировать практики управления рисками ИТ к практике управления рисками предприятия,
  • RG2.4 Обеспечить адекватные ресурсы для управления рисками ИТ,
  • RE2.1 Определите область анализа ИТ-рисков.
Оценка рисковОценка рисковОценивать

Процесс RE2 включает:

  • RE2.1 Определите область анализа ИТ-рисков.
  • RE2.2 Оценить ИТ-риск.
  • RE2.3 Определите варианты реагирования на риски.
  • RE2.4 Выполните экспертную оценку анализа ИТ-рисков.

В общем, все элементы, описанные в процессе ISO 27005, включены в Risk IT; однако некоторые из них имеют другую структуру и названия.

Обработка рисковОбработка рисков и принятие управленческих решенийОтвечать
  • RE 2.3 Определение вариантов реагирования на риски
  • RR2.3 Реагировать на обнаруженные риски и возможности
Принятие рискаRG3.4 Принять ИТ-риск
Уведомление о рискахТекущая деятельность по управлению рисками
  • RG1.5 Содействовать культуре осведомленности о рисках в ИТ
  • RG1.6 Поощрение эффективного информирования об ИТ-рисках
  • RE3.6 Разработайте индикаторы ИТ-риска.
Мониторинг и анализ рисковМонитор
  • RG2 Интеграция с ERM.
  • RE2.4 Выполните экспертную оценку анализа ИТ-рисков.
  • RG2.5 Обеспечение независимой гарантии управления ИТ-рисками

Из-за вероятностного характера и необходимости анализа рентабельности управление ИТ-рисками осуществляется в соответствии с NIST SP 800-30 можно разделить на следующие этапы:[8]

  1. оценка рисков,
  2. снижение риска, и
  3. оценка и оценка.

Эффективное управление рисками должно быть полностью интегрировано в Жизненный цикл разработки систем.[8]

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

Установление контекста

Этот шаг - первый шаг в ISO ISO / IEC 27005 рамки. Большинство элементарных мероприятий предусмотрено в качестве первого подпроцесса оценки рисков в соответствии с NIST SP 800–30. Этот шаг подразумевает получение всей необходимой информации об организации и определение основных критериев, цели, объема и границ деятельности по управлению рисками и организации, ответственной за деятельность по управлению рисками. Обычно целью является соблюдение требований законодательства и предоставление доказательств должной осмотрительности, подтверждающих СМИБ которые могут быть сертифицированы. Объем может быть планом сообщения об инцидентах, план продолжения работы компании.

Другой областью применения может быть сертификация продукта.

Критерии включают оценку риска, принятие риска и критерии оценки воздействия. Это обусловлено:[13]

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

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

Организация по управлению безопасностью

Предполагается, что создание организации, отвечающей за управление рисками, частично выполняет требование по предоставлению ресурсов, необходимых для создания, внедрения, эксплуатации, мониторинга, анализа, поддержки и улучшения СМИБ.[14] Основные роли внутри этой организации:[8]

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

ENISA: оценка рисков в управлении рисками

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

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

В соответствии с Национальный учебно-образовательный центр по обеспечению информационной безопасности оценка рисков в сфере ИТ - это:[9]

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

Структура ISO 27005

Оценка риска получает в качестве входных данных результат предыдущего шага. Установление контекста; Результатом является список оцененных рисков, которым присвоен приоритет в соответствии с критериями оценки рисков. Процесс можно разделить на следующие этапы:[13]

В следующей таблице сравниваются эти процессы ISO 27005 с Рисковать IT рамочные процессы:[11]

Составляющие процессы оценки рисков
ISO 27005Рисковать IT
Анализ риска
  • RE2 Анализ рисков включает в себя нечто большее, чем то, что описано в шаге процесса ISO 27005. RE2 ставит своей целью получение полезной информации для поддержки решений о рисках, которые учитывают значимость факторов риска для бизнеса.
  • RE1 Сбор данных служит входными данными для анализа риска (например, для определения факторов риска, сбора данных о внешней среде).
Идентификация рискаЭтот процесс включен в СР.2.2 Оценка ИТ-риска. Идентификация риска включает следующие элементы:
  • Сценарии риска
  • Факторы риска
Оценка рискаRE2.2 Оценка ИТ-риска
Оценка рискаRE2.2 Оценка ИТ-риска

В ISO / IEC 27002: 2005 Свод правил управления информационной безопасностью рекомендует при оценке рисков изучить следующее:

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

OWASP: взаимосвязь между агентом угрозы и влиянием на бизнес

Идентификация риска указывает, что может привести к потенциальным убыткам; необходимо указать следующее:[13]

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

Выход подпроцесса состоит из:

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

Оценка риска

Существует два метода оценки рисков в области информационной безопасности: количественный и качественный.[15]

Чисто количественная оценка риска - это математический расчет, основанный на показателях безопасности на актив (система или приложение) .Для каждого сценарий риска, принимая во внимание различные факторы риска а Ожидаемая разовая потеря (СКВ) определяется. Затем, учитывая вероятность возникновения за определенный период, например, годовой коэффициент возникновения (ARO), Годовые ожидаемые убытки определяется как продукт ARO и SLE.[5]Важно отметить, что ценности ресурсы Следует учитывать стоимость всех задействованных активов, а не только стоимость непосредственно затронутого ресурса.
Например, если вы рассматриваете сценарий риска, связанный с угрозой кражи портативного компьютера, вы должны учитывать ценность данных (связанных активов), содержащихся в компьютере, а также репутацию и ответственность компании (других активов) в результате потери доступности. и конфиденциальность данных, которые могут быть задействованы. Легко понять, что нематериальные активы (данные, репутация, ответственность) могут стоить гораздо больше, чем физические ресурсы, подверженные риску (в данном случае оборудование портативного компьютера).[16]Стоимость нематериальных активов может быть огромной, но ее нелегко оценить: это может быть аргументом против чисто количественного подхода.[17]

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

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

  • оценка последствий посредством оценки активов
  • оценка вероятности инцидента (посредством оценки угроз и уязвимостей)
  • присвоить значение вероятности и последствиям рисков

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

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

Во время оценки риска обычно используются три значения данного актива, одно для потери одного из ЦРУ характеристики: Конфиденциальность, Честность, Доступность.[19]

Оценка риска

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

Фреймворк NIST SP 800 30

Оценка риска согласно NIST SP 800-30 Рисунок 3-1

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

  • Шаг 1 Характеристика системы
  • Шаг 2 Идентификация угрозы
  • Шаг 3 Идентификация уязвимости
  • Шаг 4 Контрольный анализ
  • Шаг 5 Определение правдоподобия
  • Шаг 6 Анализ воздействия
  • Шаг 7 Определение риска
  • Шаг 8 Рекомендации по контролю
  • Шаг 9 Документация результатов

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

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

Структура ISO 27005

Процесс обработки рисков направлен на выбор мер безопасности для:

  • уменьшать
  • удерживать
  • избегать
  • передача

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

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

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

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

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

Фреймворк NIST SP 800 30

Блок-схема методологии снижения рисков из NIST SP 800-30 Рисунок 4-2
Точка действий по снижению риска в соответствии с NIST SP 800-30 Рисунок 4-1

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

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

Устранение наибольших рисков и стремление к достаточному снижению рисков с наименьшими затратами с минимальным влиянием на другие возможности миссии: это предложение, содержащееся в[8]

Уведомление о рисках

Основная статья: Управление рисками § Уведомление о рисках

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

Мониторинг и анализ рисков

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

Регулярные аудиты должны планироваться и проводиться независимой стороной, то есть кем-то, кто не находится под контролем и несет ответственность за внедрение или ежедневное управление СМИБ.

Оценка и оценка ИТ

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

Оценка уязвимости, как внутренние, так и внешние, и Тест на проникновение являются инструментами для проверки состояния мер безопасности.

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

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

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

Интеграция управления рисками в жизненный цикл разработки системы

Эффективное управление рисками должно быть полностью интегрировано в SDLC. SDLC ИТ-системы состоит из пяти этапов: инициирование, разработка или приобретение, внедрение, эксплуатация или обслуживание, а также утилизация. Методология управления рисками одинакова независимо от этапа SDLC, для которого проводится оценка. Управление рисками - это итеративный процесс, который может выполняться на каждой основной фазе SDLC.[8]

Таблица 2-1 Интеграция управления рисками в SDLC[8]
Фазы SDLCФазовые характеристикиПоддержка со стороны деятельности по управлению рисками
Фаза 1: ИнициированиеВыражается потребность в ИТ-системе, а цель и область применения ИТ-системы документируются.Выявленные риски используются для поддержки разработки системных требований, включая требования безопасности, и концепции безопасности операций (стратегии).
Этап 2: Разработка или приобретениеИТ-система спроектирована, приобретена, запрограммирована, разработана или сконструирована иным образом.Риски, выявленные на этом этапе, могут быть использованы для поддержки анализа безопасности ИТ-системы, что может привести к компромиссам в архитектуре и дизайне во время разработки системы.
Этап 3: РеализацияФункции безопасности системы должны быть настроены, включены, протестированы и проверены.Процесс управления рисками поддерживает оценку внедрения системы в соответствии с ее требованиями и в смоделированной операционной среде. Решения относительно выявленных рисков должны быть приняты до начала эксплуатации системы.
Этап 4: Эксплуатация или техническое обслуживаниеСистема выполняет свои функции. Обычно система постоянно модифицируется путем добавления оборудования и программного обеспечения, а также изменений организационных процессов, политик и процедур.Действия по управлению рисками выполняются для периодической повторной авторизации системы (или повторной аккредитации) или всякий раз, когда в ИТ-систему вносятся серьезные изменения в ее операционной, производственной среде (например, новые системные интерфейсы).
Этап 5: УтилизацияЭтот этап может включать удаление информации, оборудования и программного обеспечения. Действия могут включать перемещение, архивирование, удаление или уничтожение информации, а также дезинфекцию оборудования и программного обеспечения.Действия по управлению рисками выполняются для компонентов системы, которые будут утилизированы или заменены, чтобы гарантировать, что оборудование и программное обеспечение утилизируются должным образом, что остаточные данные обрабатываются надлежащим образом, и что миграция системы выполняется безопасным и систематическим образом.

NIST СП 800-64[22] посвящена этой теме.

Ранняя интеграция безопасности в SDLC позволяет агентствам максимизировать отдачу от инвестиций в свои программы безопасности за счет:[22]

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

Это руководство[22] фокусируется на компонентах информационной безопасности SDLC. Во-первых, представлены описания ключевых ролей и обязанностей по обеспечению безопасности, которые необходимы при разработке большинства информационных систем. Во-вторых, предоставляется достаточная информация о SDLC, чтобы позволить человеку, незнакомому с процессом SDLC, понять взаимосвязь между информационной безопасностью и SDLC. Документ объединяет шаги безопасности в линейный, последовательный (также известный как водопад) SDLC. Пятиступенчатый SDLC, процитированный в документе, является примером одного метода разработки и не предназначен для обязательного использования этой методологии. Наконец, SP 800-64 дает представление об ИТ-проектах и ​​инициативах, которые не так четко определены, как разработки на основе SDLC. , например, сервис-ориентированные архитектуры, межорганизационные проекты и разработки ИТ-оборудования.

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

  • Требования безопасности для информационных систем
  • Правильная обработка в приложениях
  • Криптографические средства контроля
  • Безопасность системных файлов
  • Безопасность в процессах разработки и поддержки
  • Управление техническими уязвимостями

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

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

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

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

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

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

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

Управление рисками как научная методология критиковалось как поверхностное.[3] Основные программы управления ИТ-рисками для крупных организаций, например, утвержденные США. Федеральный закон об управлении информационной безопасностью, подверглись критике.

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

Однако лучшего способа разобраться с этой темой не появилось.[3]

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

Довольно сложно перечислить большинство методов, которые хотя бы частично поддерживают процесс управления ИТ-рисками. Усилия в этом направлении были предприняты:

  • NIST Описание пакетов автоматизированного управления рисками, изученных научно-исследовательской лабораторией управления рисками NIST / NCSC, обновленное в 1991 г.
  • ENISA[24] в 2006 г .; список методов и инструментов доступен в режиме онлайн с механизмом сравнения.[25] Среди них наиболее широко используются:[3]
    • CRAMM Разработано британским правительством, соответствует требованиям ISO / IEC 17799, Закон Грэмма – Лича – Блайли (GLBA) и Медицинское страхование Портативность и Акт об ответственности (HIPAA)
    • EBIOS Разработанный правительством Франции, он соответствует основным стандартам безопасности: ISO / IEC 27001, ISO / IEC 13335, ISO / IEC 15408, ISO / IEC 17799 и ISO / IEC 21287
    • Стандарт надлежащей практики разработан Форум информационной безопасности (ISF)
    • Мехари разработан Clusif Club de la Sécurité de l'Information Français[26]
    • Концепция ИТ-рисков TIK, разработанная Институтом ИТ-рисков[27]
    • Octave, разработанный Университетом Карнеги-Меллона, SEI (Институт программной инженерии ) Подход Operationally Critical Threat Threat, Asset, and Vulnerability EvaluationSM (OCTAVE) определяет метод стратегической оценки и планирования безопасности на основе рисков.
    • IT-Grundschutz (Руководство по базовой защите ИТ), разработанное Федеральным ведомством по информационной безопасности (BSI) (Германия); IT-Grundschutz предоставляет организациям метод создания системы управления информационной безопасностью (СМИБ). Он включает как общие рекомендации по ИТ-безопасности для установления применимого процесса ИТ-безопасности, так и подробные технические рекомендации для достижения необходимого уровня ИТ-безопасности для конкретного домена.

Отчет Ениса[2] классифицировал различные методы в отношении полноты, бесплатности, поддержки инструментов; в результате:

  • EBIOS, методы ISF, IT-Grundschutz глубоко охватывают все аспекты (идентификация рисков, анализ рисков, оценка рисков, оценка рисков, обработка рисков, принятие рисков, информирование о рисках),
  • EBIOS и IT-Grundschutz - единственные свободно доступные и
  • только у EBIOS есть инструмент с открытым исходным кодом для его поддержки.

В Факторный анализ информационного риска (FAIR) основной документ, «Введение в факторный анализ информационных рисков (FAIR)», Risk Management Insight LLC, ноябрь 2006 г .;[17]Подчеркните, что в большинстве вышеперечисленных методов отсутствует четкое определение риска и его факторов. FAIR - это не еще одна методология управления рисками, но она дополняет существующие методологии.[28]

FAIR получила хорошее признание, в основном Открытая группа и ISACA.

ISACA разработала методологию, названную Рисковать IT, для устранения различных рисков, связанных с ИТ, в основном рисков, связанных с безопасностью. Он интегрирован с COBIT, общая основа для управления ИТ. Риск ИТ имеет более широкую концепцию IT риск чем другие методологии, он охватывает не только отрицательные влияние операций и предоставления услуг, которые могут привести к разрушению или снижению стоимости организации, а также к риску, связанному с упущенными возможностями использования технологий для поддержки или улучшения бизнеса или управления ИТ-проектами, такими как перерасход или задержка доставки. с неблагоприятным влиянием на бизнес.[1]

"Обеспечьте безопасность в"инициатива Департамент внутренней безопасности США, цитируется FAIR.[29]Инициатива Build Security In - это совместная работа, которая предоставляет методы, инструменты, руководства, правила, принципы и другие ресурсы, которые разработчики программного обеспечения, архитекторы и специалисты по безопасности могут использовать для обеспечения безопасности программного обеспечения на всех этапах его разработки. Так что это в основном адрес Безопасное кодирование.

В 2016 году Threat Sketch запустил сокращенную оценку рисков кибербезопасности специально для небольших организаций.[30][31] В методологии используются реальные варианты для прогнозирования и определения приоритетов фиксированного списка угроз высокого уровня.

Оперативная память СНГ[32] - это метод оценки рисков информационной безопасности, который помогает организациям разрабатывать и оценивать внедрение CIS Controls ™. Разработано CIS® (Центром интернет-безопасности) и основано на стандарте Duty of Care Risk Analysis (DoCRA),[33] CIS RAM помогает моделировать «разумное» использование CIS Controls для выполнения миссии, целей и обязательств каждой среды.

Стандарты

Основная статья: ИТ-риск § Стандарты организации и стандарты

Существует ряд стандартов относительно IT риск и управление ИТ-рисками. Описание см. В основной статье.

Законы

Основная статья: ИТ-риск § Законы и нормативные акты о ИТ-рисках

Смотрите также

Рекомендации

  1. ^ а б c «ISACA - ОСНОВА ДЛЯ ЭТОГО РИСКА (требуется регистрация)» (PDF).
  2. ^ а б c Ениса Управление рисками, Инвентаризация оценки рисков, стр.
  3. ^ а б c d е ж Кацикас, Сократис К. (2009). «35». В Вакке, Джон (ред.). Справочник по компьютерной и информационной безопасности. Публикации Моргана Кауфмана. Elsevier Inc. стр. 605. ISBN  978-0-12-374354-1.
  4. ^ «Риск - это комбинация вероятности возникновения опасного события или воздействия (я) и серьезности травмы или плохого состояния здоровья, которые могут быть вызваны событием или воздействием (ями)» (OHSAS 18001: 2007).
  5. ^ а б c Кабальеро, Альберт (2009). «14». В Вакке, Джон (ред.). Справочник по компьютерной и информационной безопасности. Публикации Моргана Кауфмана. Elsevier Inc. стр. 232. ISBN  978-0-12-374354-1.
  6. ^ [нужна цитата ]
  7. ^ ISACA (2006). Руководство по обзору CISA, 2006 г.. Ассоциация аудита и контроля информационных систем. п. 85. ISBN  978-1-933284-15-6.
  8. ^ а б c d е ж грамм час я j k Феринга, Алексей; Гогуэн, Алиса; Стоунбернер, Гэри (1 июля 2002 г.). «Руководство по управлению рисками для систем информационных технологий» - через csrc.nist.gov.
  9. ^ а б "Словарь терминов". www.niatec.iri.isu.edu.
  10. ^ Инфраструктура управления рисками от ISACA, ISBN  978-1-60420-111-6
  11. ^ а б Руководство для ИТ-специалиста по рискам, Приложение 3 ISACA ISBN  978-1-60420-116-1 (требуется регистрация)
  12. ^ Стандарт надлежащей практики Форума по информационной безопасности (ISF) Раздел SM3.4 Методологии анализа информационных рисков
  13. ^ а б c d ISO / IEC, «Информационные технологии. Методы безопасности. Управление рисками информационной безопасности» ISO / IEC FIDIS 27005: 2008
  14. ^ а б ISO / IEC 27001
  15. ^ а б Официальное (ISC) 2 Руководство по CISSP CBK. Управление рисками: публикации Ауэрбаха. 2007. с. 1065.
  16. ^ «Статья CNN о коллективном иске по делу об украденном ноутбуке ветеранского дела».
  17. ^ а б «Введение в факторный анализ информационных рисков» (FAIR), Risk Management Insight LLC, ноябрь 2006 г. В архиве 2014-11-18 в Wayback Machine;
  18. ^ Spring, J .; Kern, S .; Саммерс, А. (2015-05-01). «Глобальное моделирование противоборства». Симпозиум APWG по исследованию электронных преступлений (ECrime) 2015 г.: 1–21. Дои:10.1109 / ECRIME.2015.7120797. ISBN  978-1-4799-8909-6.
  19. ^ Британский институт стандартов «СМИБ - Часть 3: Руководство по управлению рисками информационной безопасности» BS 7799-3: 2006
  20. ^ Костас Ламбриноудакиса, Стефанос Грицалиса, Петрос Хацопулос, Афанасиос Н. Яннакопулос, Сократис Кацикаса, «Формальная модель ценообразования договоров страхования информационных систем», Компьютерные стандарты и интерфейсы - Том 27, Выпуск 5, июнь 2005, страницы 521-532 Дои:10.1016 / j.csi.2005.01.010
  21. ^ «Обзор снижения рисков». rro.sourceforge.net.
  22. ^ а б c Гулик, Джессика; Фахлсинг, Джим; Россман, Харт; Шолль, Мэтью; Стайн, Кевин; Кисель, Ричард (16 октября 2008 г.). «Соображения безопасности в жизненном цикле разработки системы» - через csrc.nist.gov.
  23. ^ «Вики-контент теперь доступен в Spaces». wiki.internet2.edu.
  24. ^ «Инвентаризация риск-менеджмента / методов оценки рисков». www.enisa.europa.eu.
  25. ^ «Инвентаризация методов и инструментов управления рисками / оценки рисков». www.enisa.europa.eu.
  26. ^ «Архивная копия». Архивировано из оригинал на 2010-10-26. Получено 2010-12-14.CS1 maint: заархивированная копия как заголовок (связь)
  27. ^ http://itriskinstitute.com/
  28. ^ Техническая стандартная таксономия рисков ISBN  1-931624-77-1 Номер документа: C081 Опубликовано Open Group, январь 2009 г.
  29. ^ «Обеспечьте безопасность в - US-CERT». www.us-cert.gov.
  30. ^ «Очерк угроз: стартап растет в квартале инноваций». Центр инноваций. 2016-10-05. Получено 2016-11-15.
  31. ^ «Триада предпринимателей делятся бизнес-идеями на выходных для стартапов». Новости TWC. Получено 2016-11-15.
  32. ^ «СНГ РАМ - Центр Интернет-безопасности».
  33. ^ «DoCRA - разумный риск».

внешняя ссылка