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

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

Элементы управления рисками

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

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

Управление ИТ-рисками можно рассматривать как компонент более широкой системы управления рисками предприятия . ^[1]

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

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

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

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

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

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

${\ displaystyle Risk = Threat * Vulnerability * Asset}$

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

${\displaystyle Risk=((Vulnerability*Threat)/CounterMeasure)*AssetValueatRisk}$^[6]

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

Определения [ править ]

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

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

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

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

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

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

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

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

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

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

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

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

Термин « методология» означает организованный набор принципов и правил, управляющих действиями в определенной области знаний. ^[3]

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

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

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

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

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

Установление контекста [ править ]

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

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

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

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

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

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

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

• Руководство
• Главный информационный директор (CIO)
• Владельцы систем и информации
• бизнес-менеджеры и функциональные менеджеры
• сотрудник по безопасности информационной системы (ISSO) или директор по информационной безопасности (CISO)
• Практики ИТ-безопасности
• Тренеры по вопросам безопасности

Оценка риска [ править ]

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

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

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

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

Структура ISO 27005 [ править ]

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

• Анализ рисков , далее разделенный на:
  • Выявление риска
  • Оценка риска
  • Оценка риска

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

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

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

Идентификация риска [ править ]

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

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

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

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

Оценка риска [ править ]

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

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

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

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

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

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

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

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

Оценка риска [ править ]

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

Структура NIST SP 800 30 [ править ]

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

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

Снижение риска [ править ]

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

Структура ISO 27005 [ править ]

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

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

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

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

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

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

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

Структура NIST SP 800 30 [ править ]

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

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

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

Сообщение о рисках [ править ]

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

Мониторинг и обзор рисков [ править ]

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

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

Оценка и оценка ИТ [ править ]

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

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

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

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

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

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

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

Этой теме посвящен NIST SP 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)
  • Mehari разработан Clusif Club de la Sécurité de l'Information Français ^[26]
  • Система ИТ-рисков TIK, разработанная Институтом ИТ-рисков ^[27]
  • Octave, разработанный Университетом Карнеги-Меллона, SEI ( Институтом инженерии программного обеспечения ). Подход Operationally Critical Threat, Asset, and Vulnerability EvaluationSM (OCTAVE) определяет метод стратегической оценки и планирования безопасности на основе рисков.
  • IT-Grundschutz (Руководство по базовой защите ИТ), разработанное Федеральным ведомством информационной безопасности (BSI) (Германия); IT-Grundschutz предоставляет организациям метод создания системы управления информационной безопасностью (СМИБ). Он включает как общие рекомендации по ИТ-безопасности для установления применимого процесса ИТ-безопасности, так и подробные технические рекомендации для достижения необходимого уровня ИТ-безопасности для определенного домена.

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

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

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

FAIR получил одобрение, в основном, Open Group и ISACA .

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

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

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

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

Стандарты [ править ]

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

Законы [ править ]

См. Также [ править ]

Ссылки [ править ]

Внешние ссылки [ править ]

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

• Руководство по информационной безопасности Internet2: эффективные методы и решения для высшего образования
• Управление рисками - Принципы и инвентаризация для управления рисками / Методы и инструменты оценки рисков , Дата публикации: 1 июня 2006 г. Авторы: Проведено Техническим отделом отдела управления рисками ENISA
• Clusif Club de la Sécurité de l'Information Français
• 800-30 Руководство по управлению рисками NIST
• 800-39 NIST DRAFT Управление рисками из информационных систем: организационная перспектива
• Публикация 199 FIPS, Стандарты категоризации безопасности федеральной информации и информации
• Публикация FIPS 200 Минимальные требования безопасности для федеральных информационных и информационных систем
• 800-37 Руководство NIST по применению структуры управления рисками к федеральным информационным системам: подход на основе жизненного цикла безопасности
• FISMApedia - это сборник документов и дискуссий, посвященных федеральной ИТ-безопасности США.
• Андерсон, К. " Интеллектуальные оценки угроз для информационных сетей и инфраструктур: Белая книга ", 2005.
• Дэнни Либерман, " Использование количественного подхода к практическому моделированию угроз для защиты данных ", 2009 г.