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

ИТ-риски рассматриваются как бизнес-риски, связанные с использованием, функционированием и влиянием информационных технологий в деятельности организации. Как и любой риск, их появление и масштаб заранее неизвестны, что формирует задачу по прогнозированию и оценке для дальнейшего смягчения последствий. Согласно фреймворку, предложенному Ассоциацией аудита и контроля информационных систем (ISACA, англ. Information Systems Audit and Control Association) в дополнение к COBIT, ИТ-риски делятся на три основные категории^[4]:

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

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

• Масштаб проекта: риски прямо пропорциональны масштабу — с ростом бюджета, численности команды, сроков внедрения и количества вовлечённых подразделений увеличивается и риск.
• Структурированность проекта: более чёткая постановка целей, прозрачность процессов и определённость ролей в проектах со строгой структурой позволяют уменьшить риски за счёт осознанности участников и эффективного обмена информацией.
• Технологический опыт: риски тем ниже, чем больше команда знакома с применяемыми технологиями, оборудованием, ПО, архитектурами и СУБД; при внедрении новых или недостаточно изученных решений число проблем при реализации проектов обычно растёт — требуется больше времени на освоение и получение специфических компетенций.

Не существует строго унифицированных методов управления ИТ-рисками, однако распространены типовые процессы, которые рекомендуется соблюдать для повышения эффективности. Документы NIST 800-30^[6] и стандарт ISO 27005:2018^[7] описывают цикл операций, которые должны быть интегрированы в любой процесс управления рисками, при этом порядок их выполнения может варьироваться. Ключевые процессы включают:

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

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

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

Согласно Агентству Европейского союза по кибербезопасности (ENISA), принятие остаточного риска — это результат управленческих решений на высшем уровне^[8]. Принятые риски считаются находящимися под ответственностью организации и, как правило, имеют обратно пропорциональную связь с уровнем управления (чем больше принимается, тем меньше затрачивается ресурсов на активное управление). Принятие рисков может быть выделено как отдельная процедура и позволяет привлечь особое внимание управленцев к вопросам, требующим повышенной осторожности.

Риски, связанные с объёмом проекта, включают следующие аспекты^[9]:

• Цели, задачи
• Фазы и подэтапы
• Отдельные виды работ (таски)
• Ресурсы
• Бюджет
• Сроки

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

Для идентификации рисков скоупа используются следующие техники:

• Интервью
• Мозговой штурм
• Анализ предпосылок проекта
• Диаграмма причин и следствий
• Техника номинальной группы
• Диаграмма аффинности (выделения связей)
• Иерархическая структура работ (WBS)

Анализ рисков предусматривает выявление угроз и оценку их воздействия на проект — как качественными, так и количественными методами^[10]. Итог этого этапа позволяет выбрать оптимальные способы управления угрозами. Комплексный анализ требует учёта многих переменных и из-за масштаба зачастую не может быть реализован одним человеком; современные ИТ-решения позволяют автоматизировать значительную часть этой работы^[11]. Автоматизация анализа стала возможна благодаря развитию сложных алгоритмов и широкому распространению искусственного интеллекта в корпоративной среде.

Эти и прочие механизмы управления ИТ-рисками приобретают всё большее значение на фоне возрастающей зависимости бизнеса от цифровых инструментов. Управление реализуется методологиями, среди которых традиционные (PMBOK, PRINCE2, P2M) и гибкие (SCRUM, Agile Project Management, DSDM)^[12].

Оценка рисков информационной безопасности состоит из трёх фаз: идентификация, анализ, оценка. Идентификация направлена на определение возможных причин убытков (активы, угрозы, существующие контроли, уязвимости и их последствия). Анализ — качественная и количественная оценка организационных рисков и их последствий через стоимость активов, вероятность инцидентов (через оценку уязвимостей) и определение уровня риска как произведения вероятности и последствий. На этапе оценки происходит сравнение рассчитанных уровней риска с критериями принятия и определяется приоритет мер по их снижению.

Идентификация угроз — это определение критичных для организации компонентов и активов, а затем установление возможных для них угроз и уязвимостей. Угрозы разделяются по происхождению^[13]:

Природные угрозы:

• Климатические воздействия;
• Наводнения;
• Цунами;
• Пожары;
• Грозы, молнии;
• Пыль;
• Дым;
• Вода (протечки, крыши, конденсат, срабатывание спринклеров);
• Вибрации;
• Электромагнитные помехи.

Физические угрозы:

• Несанкционированный доступ;
• Кража;
• Вандализм;
• Саботаж;
• Терроризм;
• Война;
• Неправильная транспортировка;
• Внешние физические воздействия (дождь, рентген-устройства);
• Столкновения;
• Падения.

Инфраструктурные угрозы:

• Отключения энергоснабжения;
• Сбои регулирования температуры;
• Сбои в системах увлажнения;
• Некорректное обслуживание;
• Недостаток персонала;
• Нарушения утилизации материалов.

Технические угрозы:

• Неправильные процедуры;
• Ошибочные операции;
• Некорректные настройки оборудования/ПО;
• Несогласованные изменения аппаратуры или программ;
• Несанкционированное копирование программ/данных;
• Перегрузка доступа;
• Ошибки классификации по требованиям безопасности;
• Аппаратные, программные, сетевые сбои;
• Вторичное использование устройств хранения данных;
• Случайная модификация информации (редактирование, удаление, добавление).

Применение внешних или внутренних вредоносных программ трактуется как отдельная форма технической угрозы с криминальной подоплёкой^[14]. К ним относятся вредоносные программы, компьютерные вирусы, черви, кейлоггеры, шпионское ПО, трояны, ботнеты, DDoS-атаки, а также мошеннические попытки спам, скам, фишинг.

В системах обработки информации уязвимости — это ошибки в процессах, дизайне, реализации либо внутреннем контроле, которые случайно или намеренно приводят к появлению бреши или нарушению принятых политик безопасности^[6][15].

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

Специалисты по ИБ выявляют уязвимости по результатам специализированных bulletins, инструментов тестирования и контрольных списков безопасности.

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

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

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

Вероятность наступления события

Управленцы по рискам должны оценить, насколько вероятна реализация каждой угрозы^[16]:

• Высокая вероятность — событие с большой долей вероятности произойдёт в течение ближайшего года;
• Средняя вероятность — возможно произойдёт в течение года;
• Низкая вероятность — крайне маловероятно, что событие произойдёт в течение следующего года.

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

Уровень ущерба

Для корректной оценки степени риска требуется установить шкалу оценки ущерба^[16]:

• Ущерб — количественная оценка потерь или вреда ценности актива;
• Высокий ущерб — остановка критически важного бизнеса с серьёзными потерями, подрывом репутации компании или убытками;
• Средний ущерб — кратковременное прекращение работы важного процесса/системы, влекущее ограниченные убытки для одного подразделения;
• Низкий ущерб — простой без финансовых потерь.

Мониторинг и пересмотр рисков

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