Взгляд на управление рисками информационных систем

Качественная оценка

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

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

Высокая/ Higher (Красный)
Средняя/ Medium (Желтый)
Низкая/ Low (Зеленый)

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

NIST SP 800-137

«Information Security Continuous Monitoring for Federal information Systems and Organizations»

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

поддержка ими большого количества источников данных;
использование открытых и общедоступных спецификаций (например, SCAP — Security Content Automation Protocol);
интеграция с другим ПО, таким как системы Help Desk, системы управления инвентаризацией и конфигурациями, системами реагирования на инциденты;
поддержка процесса анализа соответствия применимым законодательным нормам;
гибкий процесс создания отчетов, возможность «проваливаться» (англ. drill-down) в глубину рассматриваемых данных;
поддержка систем Security Information and Event Management (SIEM) и систем визуализации данных.

тут

Примеры рисков ИТ

На мой взгляд наиболее полно и точно риски присущие ИТ сформулированы в международном стандарте по аудиту №315 (ISA 315). Все остальные версии рисков ИТ и ИБ проистекают от этих категорий/общих формулировок. Приведу их в оригинале, без перевода:

Reliance on systems or programs that are inaccurately processing data, processing inaccurate data, or both
Unauthorized access to data that may result in destruction of data or improper changes to data, including the recording of unauthorized or nonexistent transactions, or inaccurate recording of transactions. Particular risks may arise where multiple users access a common database.
The possibility of IT personnel gaining access privileges beyond those necessary to perform their assigned duties thereby breaking down segregation of duties
Unauthorized changes to data in master files
Unauthorized changes to systems or programs
Failure to make necessary changes to systems or programs
Inappropriate manual intervention
Potential loss of data or inability to access data as required

Общая концепция управления рисками ИБ

ВеличинаРиска=ВероятностьСобытия*РазмерУщербаВероятностьСобытия=ВероятностьУгрозы*ВеличинаУязвимости

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

прямымнепрямымПрямойНепрямойкачественныекосвенныеКачественнымиКосвенныетотальный рискостаточный рискколичественнымкачественнымколичественногоSLE=AssetValue*EFALE=SLE*ARO(Ценность мер защиты для компании) = (ALE до внедрения мер защиты) — (ALE после внедрения мер защиты) — (Ежегодные затраты на реализацию мер защиты)качественногосписок различных методологий риск-менеджмента

NIST SP 800-30

«Guide for Conducting Risk Assessments»

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

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

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

угрозы;
уязвимости;
негативное влияние;
вероятность;
предварительные условия.

Угроза

враждебные кибератаки или физические атаки;
человеческие ошибки;
структурные ошибки в активах, подконтрольных организации;
природные или техногенные аварии или катастрофы.

ранеесмещение угрозыУязвимостьПредварительное условиеВероятность возникновения

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

Уровень негативного влияния

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

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

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

1. Подготовка к оценке рисков. 2. Проведение оценки рисков. 3. Коммуницирование результатов оценки рисков и передача информации. 4. Поддержание достигнутых результатов.

Что такое риск ИТ?

Европейский Банковский регулятор (Europen Banking Authority) дает на мой взгляд наиболее точное определение.

Риск ИТ это риск потерь организации, вызванный:

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

Также риск ИТ включает риск безопасности (ИБ), проистекающий от:

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

Взаимосвязь риска ИТ и других категорий рисков

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

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

Планы реагирования на риски

В случаях когда рисковое событие все-таки произошло, существует несколько способов реагирования на риски:

избегание риска,
передача части или всего риска третьим лицам,
снижение риска.

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

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

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

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

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

Елена Нижникова,
старший менеджер департамента управленческих и информационных технологий компании «АКГ “РБС”»; [email protected]
Игорь Белов,
старший консультант департамента управленческих и информационных технологий компании «АКГ “РБС”»; [email protected]

Опубликовано в журнале «Директор информационной службы», №7 за 2010 год

Просмотры: 6 175

Коллизия fixed price contract

Fixed price contract – это контракт, в котором размер вознаграждения не зависит от количества затраченного времени или ресурсов для достижения бизнес-цели и жёстко фиксируется в суммовом выражении. Возможно разбиение суммы такого контракта на этапы и поэтапный расчёт.

Договор fix price имеет ряд, казалось бы, очевидных преимуществ, например:

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

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

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

Ключевые причины этого риска:

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

Проекты fix price большую часть ответственности за сроки возлагают на Подрядчика. Поэтому Заказчик не уделяет проектным задачам должного внимания и может затягивать согласование документов, отвлекаясь на другие задачи. Если при этом не было формализованного выделения достаточных ресурсов Заказчика на проект, то скорость согласования проектных задач может катастрофически упасть.

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

Компоненты коммуникации ИТ-риска

Основные потоки коммуникации ИТ-риска:

Ожидание: чего организация ожидает в качестве конечного результата и каково ожидаемое поведение сотрудников и руководства; Он включает в себя стратегию, политики, процедуры, обучение осведомленности
Возможности: он показывает, как организация способна управлять риском
Статус: информация о фактическом статусе ИТ-риска; Он включает профиль риска организации, ключевой индикатор риска (KRI), события, основную причину событий убытков.

Действующая информация должна быть:

Ясная
Краткая
Полезно
Своевременно
Нацелено на правильную целевую аудиторию
Доступно при необходимости знать

Взаимосвязь с другие структуры ISACA

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

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

Мониторинг, отчетность, контроль

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

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

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

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

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

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

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

Особенности управления рисками в ИТ-проектах

Задача управления рисками остаётся самой противоречивой областью в методологии управления большими ИТ-проектами. Особенно это касается проектов внедрения сложного программного обеспечения, например ERP-систем.

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

Рассмотрим это на примере нескольких наиболее существенных проектных рисков:

Риск недооценки необходимого количества ресурсов Подрядчика.
Риск недооценки необходимого количества ресурсов Заказчика.
Риск медленного согласования проектных документов.
Риск значительного изменения объёма в ходе проекта.
Риск возникновения необходимости в значительной кастомизации внедряемой стандартной ИТ-системы.

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

Гибкое управление ресурсами Подрядчика, обеспечивающее возможность быстрого наращивания команды при необходимости.
Выделение достаточного количества ресурсов Заказчика на проект.
Создание системы мотивации для участников проекта со стороны Заказчика.
Чёткое управление объёмом проекта.
Управление продуктом проекта.

Но часто в реальных проектах эти мероприятия либо игнорируются, либо не работают. Одна из коренных причин этого – использование договора fix price для проектов.

Количественная оценка

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

AV = $200 000
EF = 45%
ARO = 2 раза
SLE = AV * EF
ALE = SLE * ARO

Таким образом:

SLE = $200 000 * 45% = $90 000 в случае реализации риска в отношении актива ожидается потеря организацией $90 000
ALE = $90 000 * 2 = $180 000 в случае реализации риска 2 раза организация потеряет в два раза больше

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

Категории рисков

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

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

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

Три линии защиты. Участники процесса управления риском

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

Первая линия — это бизнес. Все кто участвует в повседневной деятельности организации. Например менеджер по продажам/закупкам, менеджеры по работе с клиентами, ИТ подразделения, финансовый департамент и т.д.

Вторая линия — это эксперты в области управления рисками. Например функция внутреннего контроля, функция управления рисками.

Третья линия — это функция аудита. Независимый проверяющий орган организации проверяющий что первая линия эффективно выполняет правила установленные второй линией.

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

Общая концепция управления рисками ИБ

ВеличинаРиска=ВероятностьСобытия*РазмерУщербаВероятностьСобытия=ВероятностьУгрозы*ВеличинаУязвимости

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

NIST SP 800-39

«Managing Information Security Risk: Organization, Mission, and Information System View»

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

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

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

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

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

На уровне организацииНа уровне бизнес-процессовНа уровне информационных систем

принятие (acceptance) риска не должно противоречить выбранной стратегии риск-толерантности организации и её возможности нести ответственность за возможные последствия принятого риска;
избегание (avoidance) риска является зачастую самым надежным способом обработки рисков, однако может идти вразрез с желанием компании широко применять ИТ-системы и технологии, поэтому рекомендованным подходом является целесообразный и всесторонне взвешенный выбор конкретных технологий и ИТ-сервисов;
разделение (share) и передача (transfer) рисков — это соответственно частичное или полное разделение ответственности за последствия реализованного риска с внутренним или внешним партнером в соответствии с принятой стратегией, конечная цель которой — успешность бизнес-процессов и миссии организации;
минимизация (или смягчение) (mitigation) рисков подразумевает применение стратегии минимизации рисков ИБ на всех трех уровнях организации и непосредственное задействование систем ИБ для смягчения возможных последствий реализации рисков. Организации следует выстраивать бизнес-процессы в соответствии с принципами защиты информации, архитектурные решения должны поддерживать возможность эффективной минимизации рисков, минимизация рисков в конкретных системах должна быть реализована с применением средств и систем защиты информации, а политики, процессы и средства ИБ должны быть достаточно универсальными и гибкими для применения их в динамичной и разнородной среде организации, с учетом непрерывно меняющегося ландшафта угроз ИБ.

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

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

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

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

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

Риск недооценки необходимого количества ресурсов Заказчика

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

Проект fix price создаёт опасную иллюзию: Заказчик платит и ждёт результата от Подрядчика, выполняя только контрольно-приёмочные функции. Конечно, в жизни это не так, и представители Заказчика вынуждены серьёзно вовлекаться в проектные работы. Но на старте проекта почему-то про это Заказчик забывает, часто умышленно, экономя свои деньги и надеясь «выкрутить как тряпку» Подрядчика.

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

Изменение бизнеса Заказчика (реорганизация, кризисы и т. п.) не повлияло на объём проекта, но изменило приоритеты Заказчика, отвлекло значительные ресурсы Заказчика на другие, непроектные задачи.

Даже если сотрудники Заказчика в обычном режиме успевают заниматься и линейной работой, и проектной, то в случае серьёзных изменений в бизнесе такие сотрудники полностью поглощаются задачами, связанными с этими изменениями. Часто в таких случаях приоритеты Заказчика меняются. На проект сил и времени не остаётся. Привлечь дополнительные ресурсы на проект fix price или изменить его сроки часто не получается.

NIST SP 800-137

«Information Security Continuous Monitoring for Federal information Systems and Organizations»

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

поддержка ими большого количества источников данных;
использование открытых и общедоступных спецификаций (например, SCAP — Security Content Automation Protocol);
интеграция с другим ПО, таким как системы Help Desk, системы управления инвентаризацией и конфигурациями, системами реагирования на инциденты;
поддержка процесса анализа соответствия применимым законодательным нормам;
гибкий процесс создания отчетов, возможность «проваливаться» (англ. drill-down) в глубину рассматриваемых данных;
поддержка систем Security Information and Event Management (SIEM) и систем визуализации данных.

тут

Риск недооценки необходимого количества ресурсов Подрядчика

Ключевые причины возникновения этого риска, на мой взгляд, следующие:

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

Для победы в конкурсе Подрядчик может пойти на существенное снижение стоимости контракта.

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

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

Подрядчик не удержал проект в первоначальных функциональных рамках.

Объём, описанный в первоначальном ТЗ, как правило, имеет много неопределённостей, которые в дальнейшем трактуются в пользу Заказчика. В результате в объём «добрасываются» дополнительные задачи, при этом изменить бюджет fix price очень трудно. Запросы на изменения не всегда помогают, как было сказано выше.

Определение

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

Управление бизнес-рисками является важным компонентом ответственного администрирования любой организации

Ввиду важности ИТ для бизнеса в целом, ИТ-риски следует рассматривать как другие ключевые бизнес-риски

ИТ-структура рисков объясняет ИТ-риски и позволяет пользователям:

интегрировать управление ИТ-рисками с общим ERM
сравнивать оцененный ИТ-риск с аппетитом к риску и толерантность к риску организации
Понимание того, как управлять риском

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

ИТ-риски можно классифицировать по-разному:

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

ИТ-структура рисков основана на принципы стандартов / структур управления рисками предприятия, такие как Комитет спонсорских организаций Комиссии Тредуэя ERM и ISO 31000.

. Таким образом, ИТ-риск может быть понят высшим руководством.

Риск — что может пойти не так?

Определение риска.

У риска есть множество определений*, на мой взгляд наиболее точное определение риска это: «Risk is defined by COSO as the possibility that events will occur and affect the achievement of strategy and business objectives». Данное определение дано Комитетом организаций-спонсоров Комиссии Тредвея (The Committee of Sponsoring Organizations of the Treadway Commission, COSO).

*Для себя я сформулировал такое определение риска — «По причине действия/бездействия результат не будет соответствовать ожиданиям или планам». Чуть дальше мы более детально разберем вариации рисков/рисковых событий.

Риск можно обсуждать с качественной и/или количественной точек зрения, при этом определение риска может различаться в зависимости от используемого источника информации. Однако фундаментальная суть риска состоит в том, что риск определяет вероятность или возможность того, что некое событие произойдет и какие в этом будут последствия для организации.