Управление рисками ИТ - это применение методов управления рисками для информационные технологии для управления ИТ-риском, то есть:
Управление ИТ-рисками можно рассматривать как компонент более широкой системы управления рисками предприятия.
Создание, обслуживание и постоянное обновление Системы управления информационной безопасностью (СМИБ) убедительным свидетельством того, что компания использует систематический подход для оценки и управления рисками информационной безопасности.
Для управления ИТ-рисками были предложены различные методологии, каждая из которых разделена на процессы и
концепции Риск IT, сюда входят не только отрицательные Влияние операций и услуг, которые могут привести к разрушению или уменьшению стоимости организации, но также и к преимуществу, позволяющему создать риск, связанному с упущенными возможностями технологий для обеспечения или управления ИТ-проектами для использования таких услуг, как перерасход или задержка с неблагоприятным влиянием на бизнес.
<930>риск строго привязан к неопределенности, теория принятия решений должна использовать для управления рисками как науки, т. е. рационального выбора в условиях неопределенности.
В общем, риск - это произведение времени вероятности воздействия (риск = вероятность * воздействие).
Мера ИТ-может быть определен риск угроз, уязвимости и значений активации :
Более актуальный Структура управления рисками для ИТ-рисков будет представлять собой TIK:
. Процесс управления рисками - это непрерывный итеративный процесс. Это нужно повторять бесконечно. Бизнес-среда постоянно меняется, и каждый день появляются новые и уязвимости. Выбор контрмер (контрмер ), используемый для управления рисками, должен использоваться для баланса между производительностью, стоимостью, эффективностью контрмер и стоимостью защищаемого информационного актива.
Сертифицированный аудитор информационных систем Руководство по обзору 2006 г., выпущенное ISACA, международной профессиональной ассоциацией, специализирующейся на ИТ, следующее определение управления рисками: «Управление рисками - это дает возможность уязвимостей и угроз для информационных ресурсов, использовать организацию для достижения бизнес-целей, и принять решения о том, какие меры противодействия, если таковые имеются, принять меры по снижению риска до приемлемого уровня, исходя из значений информационного ресурса для организации ».
. Управление рисками - это процесс, который позволяет ИТ-менеджерам сбалансировать операционные и экономические затраты на защиту, измеряет и увеличивает возможности выполнения миссии, защищая ИТ-системы и данные, которые входят в миссии организации своей организации. Этот процесс характерен не только для ИТ-среды; на самом деле он проникает в процесс принятия решений во всех сферах нашей повседневной жизни.
Глава организационного подразделения должен убедиться, что у организации есть возможности, необходимые для выполнения своей миссии. Эти владельцы миссий могут определить возможности, которые должны иметь их ИТ-системы для обеспечения желаемого уровня поддержки миссии перед лицом угроза. У всех организаций ограниченный бюджет на ИТ-безопасность; Следовательно, расходы на ИТ-необходимо проанализировать так же тщательно, как и другие управленческие решения. Хорошо структурированная методология управления рисками при эффективном использовании может помочь руководству определить соответствующие средства для важных функций контроля безопасности.
Взаимоотношения между объектами безопасности ИТУправление рисками в мире ИТ - довольно сложная многосторонняя деятельность, во многом связанная с другими сложными видами деятельности. На картинке показаны отношения между различными родственными терминами.
Американский Национальный учебный и образовательный центр по обеспечению информации определяет управление рисками в сфере контроля как:
Некоторые организации имеют многие другие комплексные управление рисками предприятия (ERM). Согласно Комитет спонсорских организаций Комиссии Тредуэя (COSO), рассматривает четыре категории целей:
Согласно Риск ИТ согласно ISACA, ИТ- риск на все четыре категории. Риском ИТ следует управлять в рамках системы управления рисками предприятия: Аппетит к риску и чувствительность к риску всего предприятия должны определять процесс управления рисками ИТ. ERM должен содержать контекст и бизнес-цели для управления рисками ИТ.
Хотя методология не утвержденных методов; тем не менее, он определяет несколько общих структур, которым необходимо менее следовать. Эти процессы могут быть разбиты на подпроцессы, они могут быть объединены или их последовательность может измениться. Упражнения по управлению рисками реализовывать процессы в той или иной форме. В следующей таблице сравниваются процессы, предусмотренные тремя ведущими стандартами. Структура ISACA Risk IT появилась позже. В Руководстве для практикующего специалиста по рискам ИТ сравнивается риск ИТ и ISO 27005.
Термин методология означает организованный набор принципов и правил, которые определяют действия в определенной области знаний.
Общее сравнение показано в следующей таблице.
ISO / IEC 27005: 2008 | BS 7799-3: 2006 | NIST SP 800-39 | ИТ-риски |
---|---|---|---|
Установление контекста | Организационный контекст | Кадр | RG и RE Домены, точнее
|
Оценка рисков | Оценка рисков | Оценка рисков | Процесс RE2 включает:
В целом, все элементы, описанные в процессе ISO 27005, включены в Risk IT; однако некоторые из них имеют другую структуру и название. |
Обработка риска | Обработка риска и принятия управленческих решений | Ответить |
|
Принятие риска | RG3.4 При ИТ-риск | ||
Информирование о рисках | Текущие мероприятия по управлению рисками |
| |
Мониторинг и анализ рисков | Монитор |
|
Из-за вероятного характера и анализа рентабельности управление ИТ-рисками осуществляется в соответствии с процессом, в соответствии с NIST SP 800-30 можно разделить на следующие этапы:
Эффективное управление рисками должны быть полностью интегрированы в e Жизненный цикл разработки системы.
Информация Анализ рисков, проводимый для приложений, компьютерных установок, сетей и систем в стадии разработки, должен проводиться с использованием структурированных методологий.
Этот шаг является первым шагом в структуре ISO ISO / IEC 27005. Большинство элементов мероприятий предусмотрены как первый подпроцесс оценки рисков в соответствии с NIST SP 800–30. Этот шаг подразумевает получение всей необходимой информации об организации и определении критериев цели, объема и границ деятельности по управлению рисками и организации, ответственной за деятельность по управлению рисками. Обычно является соблюдением требований законодательства и предоставления поддержки судебной осмотрительности в поддержку СМИБ, которая может быть сертифицирована. Областью применения может быть план сообщения об инцидентах, план непрерывности бизнеса.
. Другой областью применения может быть сертификация продукта.
Критерии включают в себя оценку риска, принятия риска и воздействия. Они обусловлены:
Устанавливает объем и границы, организация должна быть изучена: ее миссия, ее ценности, ее структура; его стратегия, его расположение и культурная среда. Ограничения (бюджетные, культурные, политические, технические) организации должны быть собраны и задокументированы в качестве руководства для следующих шагов.
Создание организации, ответственной за управление рисками, частичное выполнение требований по предоставлению ресурсов, необходимых для создания, внедрения, эксплуатации, мониторинга, анализа и т.д. поддерживать и улучшать СМИБ. Основными ролями внутри этой компании являются:
Управление рисками - это повторяющаяся деятельность, связанная с анализом, планированием, реализацией, контролем и мониторингом реализованных измерений и принудительной политики безопасности. Напротив, оценка рисков выполняется в дискретные моменты времени (например, один раз в год, по запросу и т. Д.) И - до выполнения выполнения оценки - обеспечивает временное обеспечение оцененных параметров и параметров процесса управления рисками. Этот взгляд на взаимосвязь управления рисками с оценкой рисков изображен на рисунке, взятом из OCTAVE.
Оценка рисков часто проводится в несколько итераций, первая из которых представляет собой оценку высокого уровня для высоких рисков, в то время как другие риски детализировали анализ основных рисков и других рисков.
Согласно Национальному учебно-образовательному центру по оценке информационной безопасности риски в сфере ИТ представляет собой:
Оценка риска получения в качестве входных данных выходные данные предыдущего шага Установление контекста ; выходом является список оцененных рисков с приоритетом в соответствии с критериями оценки рисков. Процесс можно разделить на следующие этапы:
В следующей таблице сравниваются эти процессы ISO 27005 с ИТ-риски рамочные процессы:
ISO 27005 | ИТ-риски |
---|---|
Анализ рисков |
|
Идентификация риска | Этот процесс включен в СР.2.2 Оценка ИТ-риска. риск включает следующие элементы:
|
Оценка риска | RE2.2 Оценка ИТ-риска |
Оценка риска | RE2.2 Оценка ИТ-риска |
В ISO / IEC 27002: 2005 Практический кодекс по менеджменту информационной безопасности рекомендует изучить следующее во время оценки риска:
Идентификация риска указывает, что может вызвать потенциальные убытки; следующие подлежащие идентификации:
Выходные данные подпроцесса состоят из:
Существует два метода оценки риска в области информационной безопасности: количественный и качественная.
Чисто количественная оценка риска - это математический расчет, основанный на показателях безопасности для актива (системы или приложения). Для каждого сценария риска, принимая во внимание различные факторы риска, определяется ожидаемая величина единичной потери (SLE). Затем, учитывая вероятность возникновения на основе данного периода, например, годовой коэффициент возникновения (ARO), Ожидаемая годовая вероятность убытков определяется как произведение ARO и SLE. Важно отметить, что необходимо учитывать значения активов всех задействованных активов, а не только стоимость непосредственно затронутого ресурса.. Например, если вы рассматриваете сценарий риска При угрозе кражи ноутбука вам следует учитывать ценность данных (связанных активов), содержащихся в компьютере, а также репутацию и ответственность компании (других активов), возникающую из-за потери доступности и конфиденциальности данных, которые могут быть задействованы. Легко понять, что нематериальные активы (данные, репутация, ответственность) могут стоить гораздо больше, чем физические ресурсы, подверженные риску (оборудование портативного компьютера в примере). Стоимость нематериальных активов может быть огромной, но ее нелегко оценить: это может быть соображением против чистоколичественного подхода.
Качественная оценка риска (оценка от трех до пяти шагов, от очень высокой до низкой) выполняется, когда организация требует, чтобы оценка риска была проведена в относительно короткие сроки или в рамках небольшого бюджета, значительный объем данных соответствующих недоступен, или, выполняющие оценку, не обладают сложными математическими, финансовыми знаниями лица и опыта оценки рисков требуется. Качественная оценка рисков может быть выполнена за более короткий период времени и с меньшим объемом данных. Качественная оценка обычно выполняется путем интервьюирования персонала из всех соответствующих групп организации, отвечающих за безопасность оцениваемого актива. Качественные оценки рисков носят описательный характер, не измеримые. Обычно проводится качественная классификация, за которой следует количественная оценка наивысших показателей для сравнения с затратами на меры безопасности.
Оценка риска риска анализа и может быть разделена на следующие этапы:
Результатом является список рисков с присвоенными уровнями значений. Это может быть задокументировано в реестре рисков.
. Риски, вызывающие в результате угрозы безопасности и атакующего злоумышленника, могут быть особенно трудными для оценки. Эта трудность усугубляется тем, что, по крайней мере, для любой ИТ-системы, подключенной к Интернету, любой злоумышленник с намерением и может атаковать, поскольку физическая близость или доступ не может атаковать. Для решения этой проблемы были предложены некоторые начальные модели.
Во время оценки обычно используются три значения данного актива, одно для одного потери из свойств CIA : Конфиденциальность, Целостность, Доступность.
На входе процесс оценки получает выходные данные процесса анализа риска. Он сравнивает каждый уровень риска с критериями приемлемости и устанавливает приоритетность списка рисков с указаниями по риску.
Для определения вероятности будущего неблагоприятного события, угрозы ИТ-системы должны быть связаны с потенциальными уязвимостями и средствами контроля, действующими для ИТ-системы.. Воздействие относится к величине ущерба, который может быть причинен в результате реализации уязвимости угрозой. Уровень воздействия потенциальным воздействием на миссию и дает дополнительную ценность для стимулирующих ИТ-активов и ресурсов (например, критичность компонентов и данных ИТ-системы). Методология оценки рисков включает девять основных этапов:
Снижение рисков, второй процесс в соответствии с SP 800–30, третий в соответствии с ISO 27005 управления рисками, включает установление приоритетов, оценку и внедрение соответствующих рисков управления рисками, рекомендованных в процессе оценки рисков. Использование наиболее подходящих средств контроля для снижения риска миссии до приемлемого уровня с минимальными затратами используется для использования с наименьшими затратами и внедрением наиболее подходящих средств контроля для снижения риска миссии до приемлемого уровня с минимальными затратами. неблагоприятное воздействие на ресурсы и миссию.
Целью процесса обработки риска является выбор мер безопасности, чтобы:
риск и составить план обработки, то есть результат с помощью остаточного риска, риска процесса с помощью метода принятия руководства.
Существует некоторый список для выбора подходящих мер безопасности, но одна организация может выбрать наиболее подходящий из них в соответствии с бизнес-стратегией, ограничениями своей среды и обстоятельствами. Выбор должен быть рациональным и задокументированным. Важность принятия риска, слишком дорого обходится для снижения, очень высока и привела к тому, что принятие риска как отдельный процесс.
Перенос метода, если риск имеет очень большое влияние, но это непросто для значительного снижения вероятности с помощью мер безопасности: страховую премию следует сравнивать с затратами на смягчение последствий, в конечном итоге оценивая некоторую смешанную стратегию для частичной обработки риска. Другой вариант - передать риск кому-то более эффективному для управления риском.
Избежание возможного любого действия, при котором способы ведения бизнеса меняются, чтобы избежать возникновения риска. Например, отказ от хранения конфиденциальной информации о клиенте может помочь избежать риска кражи данных о клиенте.
Остаточные риски, то есть риск, остающийся после принятия решения по обработке риска, следует оценивать, чтобы достижение достаточной защиты. Если остаточный риск неприемлем, процесс обработки следует повторить.
Снижение риска - это систематическая методология, используемая высшим руководством для риска миссии.. Снижение риска может быть достигнуто с помощью любого из вариантов снижения риска:
Устранение рискованных рисков и стремление к эффективному снижению рисков с наименьшими затратами с минимальными возможностями миссии: это содержащееся предложение в
Уведомление о рисках - это горизонтальный процесс, который двунаправленно взаимодействует со всеми другими процессами управления рисками. Его цель - установить общее понимание всех возможностей среди всех сторон организации. Установление общего понимания важно, поскольку оно влияет на принимаемые решения. Метод обзора снижения риска разработан специально для этого процесса. Он представляет собой понятный обзор согласованности рисков, мер и остаточных рисков для достижения общего понимания.
Управление рисками - это непрерывный, нескончаемый процесс. В рамках этого процесса внедряемые меры безопасности регулярно контролируются и анализируются, чтобы они работали, чтобы они работали по плану и что изменения в окружающей среде сделали их неэффективными. Бизнес-требования, уязвимости и угрозы могут меняться со временем.
Регулярные аудиты должны планироваться и проводиться независимой стороной, т. Е. Кем-либо, не находящимся под контролем, ответственным за внедрение или ежедневное управление СМИБ.
Меры безопасности должны быть проверены. Технический контроль - это сложные сложные системы, которые необходимо протестировать и проверить. Самая часть для проверки - это людьми процедурных средств контроля и реальной эффективности процедур безопасности в повседневной работе.
Оценка уязвимости, как внутренняя, так и внешняя, и Тест на проникновение. инструменты для проверки статуса мер безопасности.
Аудит безопасности информационных технологий - это организационный и процедурный контроль с целью оценки безопасности. ИТ-системы организаций развиваются довольно быстро. Управление рисками должно быть с помощью авторизации изменений после повторной оценки рисковутых систем и процессов и периодического анализа рисков и действий по их снижению.
Мониторинг системных событий в соответствии со стратегией мониторинга безопасности, планомерное реагирование на инциденты и проверка безопасности и метрики фундаментальных действий для обеспечения оптимального уровня безопасности.. Важно отслеживать новые уязвимости, применять процедурные и технические средства безопасности, такие как регулярное программное обеспечение обновление программного обеспечения, и оценивать другие виды контроля для борьбы с атаками нулевого дня.
Отношение вовлеченных людей к сравнительному анализу с передовой практикой и соблюдению семинаров профессиональных ассоциаций в секторе есть факторы, обеспечивающие состояние практики управления ИТ-рисками в организации.
Эффективное управление рисками должно быть полностью интегрировано в SDLC. SDLC ИТ-системы состоит из пяти этапов: инициирование, разработка или приобретение, внедрение, эксплуатация или обслуживание и утилизация. Методология управления рисками независимо от этапа SDLC, для которого проводится оценка. Управление рисками - это итеративный процесс, который может выращивать на каждой основной фазе SDLC.
Фазы SDLC | Характеристики фаз | Поддержка деятельности по управлению рисками |
---|---|---|
Этап 1: Инициирование | Выражается Потребность в ИТ-системе, и документируются цель и объем ИТ-системы | Выявленные риски для поддержки разработки системных требований, включая требования безопасности, и концепцию операций безопасности (стратегия) |
Этап 2: Разработка или приобретение | ИТ-система спроектирована, приобретена, запрограммирована, бюджет или сконструирована иным образом | Риски, выявленные на этом этапе, могут привести к поддержке анализа безопасности ИТ-системы, что может привести к приведению в компуре и дизайне во время разработки системы |
Этап 3: Внедрение | Функции безопасности должны быть настроены, включены, протестированы и проверены | Процесс управления рисками поддерживает оценку внедрения системы в соответствии с его требованиями и в смоделированной операционной среде. Решения относительно выявленных рисков должны быть приняты до начала работы системы. |
Этап 4: Эксплуатация или обслуживание | Система выполняет свои функции. Обычно система модифицируется на постоянной основе путем добавления оборудования и программного обеспечения, а также путем изменения организационных процессов, политик и процедур | Действия по управлению рисками выполняются для периодической повторной авторизации (или повторной аккредитации) системы или в случае значительного В ИТ-систему вносятся изменения в ее операционной, производственной среде (например, новые системные интерфейсы) |
Этап 5: Удаление | Этот этап может включать удаление информации, оборудования и программного обеспечения. Действия могут включать перемещение, архивирование, удаление или уничтожение информации и дезинфекцию оборудования и программного обеспечения | Действия по управлению рисками выполняются для компонентов системы, которые будут утилизированы или заменены, чтобы гарантировать, что оборудование и программное обеспечение утилизируются должным образом., что остаточные данные обрабатываются надлежащим образом и что миграция системы выполняется безопасным и систематическим образом. |
NIST SP 800-64 посвящен этой теме.
Ранняя интеграция безопасности в SDLC позволяет агентствам максимизировать отдачу от инвестиций в свои программы безопасности за счет:
В этом руководстве основное внимание уделяется компонентам информационной безопасности SDLC. Во-первых, представлены описания ключевых ролей и обязанностей по обеспечению безопасности, которые необходимы при разработке большинства информационных систем. Во-вторых, предоставляется достаточная информация о SDLC, чтобы позволить человеку, незнакомому с процессом SDLC, понять взаимосвязь между информационной безопасностью и SDLC. Этот документ объединяет шаги безопасности в линейный, последовательный (также известный как водопад) SDLC. Пятиступенчатый SDLC, процитированный в документе, является примером одного метода разработки и не предназначен для обязательного использования этой методологии. Наконец, SP 800-64 обеспечивает понимание ИТ-проектов и инициатив, которые не так четко определены, как разработки на основе SDLC, таких как сервис-ориентированные архитектуры, межорганизационные проекты и разработки ИТ-объектов.
Безопасность может быть включена в приобретение информационных систем, разработка и сопровождение внедрения эффективных методов обеспечения безопасности в следующих областях:
Безопасность информационных систем начинается с включения безопасности в процессах для любого нового приложения или улучшения. Безопасность должна быть заложена в систему с самого начала. Требования безопасности представляются поставщиком на этапе требований при покупке продукта. Перед покупкой продукта необходимо провести формальное тестирование, чтобы определить, соответствует ли продукт требуемым спецификациям безопасности.
Правильная обработка в важна для предотвращения ошибок использования приложений потерь, несанкционированного изменения или неправильного информации. Эффективные методы кодирования проверки входных и выходных данных, защиты целостности сообщений с помощью шифрования, проверки обработки и создания журналов активности.
При правильном применении криптографические средства контроля обеспечивают эффективные механизмы защиты конфиденциальности, подлинности и целостности информации. Учреждение должно представить использование шифрования, включая платежное управление ключами. Шифрование диска - это один из способов защиты данных в состоянии покоя. Транслируемые данные могут быть защищены от изменений и несанкционированного просмотра с помощью сертификатов SSL, выданных центра сертификации, который реализовал инфраструктуру открытых ключей.
Системные файлы, используемые, должны быть защищены, безопасность и стабильность приложения. Использование репозиториев исходного кода с версией, всестороннее тестирование, производственные планы отклика и соответствующие приложения к программному коду - вот некоторые эффективные меры, которые можно использовать для файловых приложений.
Безопасность в процессах разработки и поддержки является неотъемлемой частью всеобъемлющего процесса обеспечения качества и контроля производства и обычно включает обучение и постоянный контроль со стороны наиболее опытных сотрудников.
Наблюдайте и проверьте и исправлять на уязвимостях. Процедуры применения для определения их пригодности и возможности их успешного удаления в случае исправления негативного воздействия.
Управление рисками как научная методология подверглась критике как поверхностная. Были подвергнуты критике основных программ управления ИТ-рисками для крупных программ, например, предусмотренные Федеральным законом США об использовании информационной безопасностью .
За счет предотвращения сложности, которая сопровождает формальную вероятностную модель рисков и неопределенности, управлениеами больше похоже на процесс, который пытается угадать, а не формально предсказать будущее на основе статистических данных. Это очень субъективно при оценке стоимости активов, вероятности возникновения угроз и значимости воздействия.
Однако лучшего способа справиться с этой проблемой не появилось.
Довольно сложно перечислить большинством методов, которые хотя бы частично включают процесс управления ИТ-рисками. Усилия в этом направлении были приняты:
В Enisa классифицируют различные методы в отношении полноты, бесплатной доступности и поддержки инструментов ; В результате:
Основной документ Факторный анализ информационных рисков (FAIR), «Введение в факторный анализ информационных рисков (FAIR)», Risk Management Insight LLC, ноябрь 2006 г.; Подчеркните, что в большинстве вышеперечисленных методов отсутствует строгое определение риска и его факторов. FAIR не является еще одной методологией управления рисками.
FAIR получила хорошее признание, в основном Открытая группа и ISACA.
ISACA разработала методологию под названием Risk IT для устранения различного рода рисков, связанных с ИТ, в основном связанных, связанных с безопасностью. Он интегрирован с COBIT, общая структурой для управления ИТ. Риск ИТ имеет более широкое понятие ИТ-риск, чем другие методологии, которые могут привести к разрушению или снижению стоимости, но также и выгоды \ ценность. Обеспечение риска, связанного с упущенными возможностями использования технологий для обслуживания таких служб, как перерасход или задержка доставки с неблагоприятным воздействием на бизнес.
Инициатива «Повышение безопасности» Национальной безопасности Департамента США, цитирует FAIR. Инициатива Build Security In - это совместная работа, которая предоставляет методы, руководящие принципы, правила, принципы и другие ресурсы, разработчики программного обеспечения, архитектуры и специалисты по безопасности использовать для обеспечения безопасности программного обеспечения на всех этапах его разработки. Таким образом, в основном это касается безопасного кодирования.
. В 2016 году Threat Sketch запустил сокращенную оценку рисков кибербезопасности специально для небольших организаций. В методологии используются реальные параметры для прогнозирования определения приоритетов фиксированного списка угроз высокого уровня.
RAM CIS - это метод оценки риска информационной безопасности, который помогает организациям разрабатывать и оценивать внедрение CIS Controls ™. Разработанный CIS® (Центр интернет-безопасности) и основанный на стандарте Duty of Care Risk Analysis (DoCRA), CIS RAM помогает моделировать «разумное» использование CIS Controls для выполнения миссии, целей и обязательств каждой среды.
Существует ряд стандартов, используемых ИТ-рисков и управления ИТ-рисками. Описание см. В основной статье.
На Викискладе есть материалы, связанные с ИТ управление рисками. |