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

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

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

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

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

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

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

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

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

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

Меру ИТ-риска можно определить как произведение угроз, уязвимостей и стоимости активов :

${\text{Risk}}={\text{Threat}}\times {\text{Vulnerability}}\times {\text{Asset}}$

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

${\text{Risk}}=(({\text{Vulnerability}}\times {\text{Threat}})/{\text{Counter measure}})\times {\text{Asset value at risk}}$

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

Определения

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

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

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

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

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

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

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

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

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

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

Согласно системе Risk IT, разработанной ISACA , ИТ-риск распространяется на все четыре категории. ИТ-рисками следует управлять в рамках управления рисками предприятия: аппетит к риску и чувствительность к риску всего предприятия должны определять процесс управления ИТ-рисками. ERM должно обеспечивать контекст и бизнес-цели управления ИТ-рисками.

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

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

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

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

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

Составляющие процессы управления рисками

ИСО/МЭК 27005:2008	БС 7799-3:2006	НИСТ СП 800-39	Риск ИТ
Установление контекста	Организационный контекст	Рамка	Точнее, домены RG и RE. RG1.2 Предложить толерантность к ИТ-рискам, RG2.1 Установление и поддержание подотчетности за управление ИТ-рисками RG2.3 Адаптировать практику управления рисками ИТ к практике управления рисками предприятия, RG2.4 Обеспечить достаточные ресурсы для управления ИТ-рисками, RE2.1 Определить объем анализа ИТ-рисков.
Оценка риска	Оценка риска	Оценивать	Процесс RE2 включает в себя: RE2.1 Определить объем анализа ИТ-рисков. RE2.2 Оценить ИТ-риск. RE2.3 Определить варианты реагирования на риски. RE2.4 Провести экспертную оценку анализа ИТ-рисков. В общем, элементы как описанные в процессе ISO 27005, все включены в Риск ИТ; однако некоторые из них структурированы и названы по-другому.
Обработка рисков	Обработка рисков и принятие управленческих решений	Отвечать	СР. 2.3 Определить варианты реагирования на риски RR2.3 Реагировать на обнаруженные риски и возможности
Принятие риска			RG3.4 Принятие ИТ-рисков
Информирование о рисках	Текущая деятельность по управлению рисками		RG1.5 Продвижение культуры осознания рисков в сфере ИТ RG1.6 Поощрение эффективного информирования об ИТ-рисках RE3.6 Разработать индикаторы ИТ-рисков.
Мониторинг и анализ рисков		Монитор	RG2 Интеграция с ERM. RE2.4 Провести экспертную оценку анализа ИТ-рисков. RG2.5 Обеспечить независимую гарантию управления ИТ-рисками

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

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

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

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

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

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

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

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

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

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

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

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

• Старшее руководство
• Главный информационный директор (CIO)
• Владельцы систем и информации, такие как директор по данным (CDO) или директор по конфиденциальности (CPO).
• бизнес и функциональные менеджеры
• [ https://www.elits.ae/services/ Сотрудник по безопасности информационных систем] (ISSO) или главный специалист по информационной безопасности (CISO)
• Специалисты по ИТ-безопасности
• Тренеры по вопросам безопасности

Оценка риска

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

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

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

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

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

Структура ISO 27005

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

• Анализ рисков , дополнительно разделенный на:
  • Идентификация рисков
  • Оценка риска
  • Оценка рисков

В следующей таблице эти процессы ISO 27005 сравниваются с процессами структуры Risk IT Framework:

Составляющие процессы оценки рисков

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

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

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

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

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

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

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

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

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

Оценка риска

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

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

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

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

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

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

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

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

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

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

Структура NIST SP 800 30

Оценка риска в соответствии со стандартом NIST SP 800-30, рисунок 3-1.

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

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

Снижение рисков

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

Структура ISO 27005

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

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

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

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

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

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

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

Структура NIST SP 800 30

Блок-схема методологии снижения рисков из NIST SP 800-30, рисунок 4-2.

Действия по снижению риска согласно NIST SP 800-30, рисунок 4-1.

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

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

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

Информирование о рисках

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 2-1. Интеграция управления рисками в SDLC

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

НИСТ СП 800-64 посвящен этой теме.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Описание NIST пакетов автоматизированного управления рисками, которые исследовала исследовательская лаборатория управления рисками NIST/NCSC, обновлено в 1991 г.
• ЭНИСА в 2006 году; список методов и инструментов доступен в Интернете вместе с механизмом сравнения. Среди них наиболее широко используются:
  • 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
  • TIK IT Risk Framework, разработанный IT Risk Institute
  • Octave, разработанный Университетом Карнеги-Меллона, SEI ( Институт программной инженерии ). Операционная оценка критических угроз, активов и уязвимостей (OCTAVE). ^СМ ) подход определяет метод стратегической оценки и планирования безопасности на основе рисков.
  • IT-Grundschutz (Руководство по базовой защите ИТ), разработанное Федеральным ведомством информационной безопасности (BSI) (Германия); IT-Grundschutz предоставляет организации метод создания системы управления информационной безопасностью (ISMS). Он включает в себя как общие рекомендации по ИТ-безопасности для создания применимого процесса ИТ-безопасности, так и подробные технические рекомендации для достижения необходимого уровня ИТ-безопасности для конкретного домена.

Отчет Эниса классифицировали различные методы относительно полноты, бесплатной доступности, инструментальной поддержки; результат таков:

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

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

FAIR получила хорошее признание, в основном со стороны The Open Group и ISACA .

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

Инициатива « Построить безопасность внутри » Министерства внутренней безопасности США, цитирует FAIR. Инициатива Build Security In — это совместная работа, которая предоставляет практики, инструменты, рекомендации, правила, принципы и другие ресурсы, которые разработчики программного обеспечения, архитекторы и специалисты по безопасности могут использовать для обеспечения безопасности программного обеспечения на каждом этапе его разработки. Так что в основном речь идет о безопасном кодировании .

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

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

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

Стандарты

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

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

Законы

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

См. также

• Контроль доступа
• Актив (вычисления)
• Управление активами
• Оценка
• Атака (вычисления)
• Доступность
• Контрольный показатель
• Лучшая практика
• Непрерывность бизнеса
• План обеспечения непрерывности бизнеса
• Бизнес-процесс
• Главный информационный директор
• Главный специалист по информационной безопасности
• КОБИТ
• Распространенные уязвимости и риски (CVE)
• Коммуникации
• Компьютерная небезопасность
• Компьютерная безопасность
• Конфиденциальность
• КОСО
• Противодействие (компьютер)
• КРАММ
• Общая система оценки уязвимостей (CVSS)
• Теория принятия решений
• ЭБИОС
• ЭНИСА
• Управление рисками предприятия
• Экологическая безопасность
• Оценка
• Эксплойт (компьютерная безопасность)
• Факторный анализ информационного риска
• ФИСМА
• Полное раскрытие информации (компьютерная безопасность)
• Закон Грэма-Лича-Блайли
• Закон о переносимости и подотчетности медицинского страхования
• Департамент внутренней безопасности
• Человеческие ресурсы
• Управление инцидентами
• Информационная безопасность
• Форум по информационной безопасности
• Управление информационной безопасностью
• Информационные технологии
• Аудит безопасности информационных технологий
• Страхование
• Честность
• ИСАКА
• ИСО
• ИСО/МЭК 15408
• ИСО/МЭК 17799
• Серия ISO/IEC 27000
• ИСО/МЭК 27001
• ИСО/МЭК 27005
• Базовая защита ИТ
• ИТ-риск
• Мехари
• Методология
• Национальный учебно-образовательный центр информационного обеспечения
• Национальная безопасность
• НИСТ
• Организация
• ОВАСП
• Патч (компьютерный)
• Тест на проникновение
• Физическая безопасность
• Конфиденциальность
• Соответствие нормативным требованиям
• Риск
• Анализ рисков (инжиниринг)
• Аппетит к риску
• Оценка риска
• Фактор риска (вычисления)
• Управление рисками
• Риск ИТ
• Реестр рисков
• Безопасное кодирование
• Контроль безопасности
• Политика безопасности
• Риск безопасности
• Служба безопасности (телекоммуникации)
• Заинтересованная сторона (корпоративная)
• Жизненный цикл разработки систем
• Открытая группа
• Угроза
• Уязвимость
• Оценка уязвимости
• Управление уязвимостями
• w3af
• атака нулевого дня
• Модель Гордона – Леба для инвестиций в кибербезопасность

Внешние ссылки

• Руководство по информационной безопасности Internet2: эффективные практики и решения для высшего образования
• Управление рисками - Принципы и инвентаризация управления рисками / Методы и инструменты оценки рисков , Дата публикации: 1 июня 2006 г. Авторы:Проведено Техническим отделом ENISA. Раздел «Управление рисками».
• Clusif Французский клуб информационной безопасности
• 800-30 Руководство по управлению рисками NIST
• 800-39 NIST DRAFT Управление рисками информационных систем: организационная перспектива
• Публикация FIPS 199, Стандарты категоризации безопасности федеральной информации и информации.
• Публикация FIPS 200 «Минимальные требования безопасности для федеральной информации и информационных систем».
• 800-37 Руководство NIST по применению структуры управления рисками к федеральным информационным системам: подход к жизненному циклу безопасности
• FISMApedia — это сборник документов и обсуждений, посвященных федеральной ИТ-безопасности США.
• Андерсон, К. « Оценка угроз для информационных сетей и инфраструктур на основе разведывательных данных: Белая книга », 2005 г.
• Дэнни Либерман, « Использование количественного подхода практического моделирования угроз для обеспечения безопасности данных », 2009 г.