Привет, Хабр!
Законы Мерфи гласят:
- Все, что может пойти не так, пойдет не так.
- Если есть вероятность того, что несколько вещей пойдут не так, то пойдет не так та, которая нанесет наибольший ущерб. Следствие: если есть худшее время для того, чтобы что-то пошло не так, это произойдет именно тогда.
- Если что-то просто не может пойти не так, оно все равно произойдет.
Меня зовут Максим Торнов и я продолжительное время занимаюсь проектами в области управления рисками и аудитом ИТ и ИБ. Помимо этого, я долгое время работал в различных областях ИТ, а также занимался проектами по оценке эффективности и внедрению систем внутреннего контроля, в одной из консалтинговых компаний «Большой четверки».
В данном материале мне бы хотелось рассказать Вам об основах управления риском ИТ.
Уверен, в настоящее время тема управления рисками присущими информационным технологиям не перестает быть актуальной. От того насколько организация эффективно управляет риском ИТ зависит достижение многих целей организации, например таких как надежность и эффективность работы бизнес-процессов, соответствие организации требованиям регуляторных органов, достоверность финансовой отчетности и многие другие.
Я искренне надеюсь, что данный материал будет Вам полезен и возможно натолкнет Вас на какие-то новые идеи, которые Вы сможете направить на благо Вашего личного развития и развития Вашей организации.
Что вы узнаете из этой статьи?
Что такое риск и категории рисков
Что такое риск ИТ
Как риск ИТ взаимосвязан с функциями бизнеса
Разница между «RISK CAPACITY» и «RISK APPETITE»
Управление риском ИТ
Кто участники процесса управления рисками
Этапы управления риском ИТ
Ценность эффективного управление риском ИТ
Риск - что может пойти не так?
Определение риска.
У риска есть множество определений*, на мой взгляд наиболее точное определение риска это: "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).
*Для себя я сформулировал такое определение риска - "По причине действия/бездействия результат не будет соответствовать ожиданиям или планам". Чуть дальше мы более детально разберем вариации рисков/рисковых событий.
Риск можно обсуждать с качественной и/или количественной точек зрения, при этом определение риска может различаться в зависимости от используемого источника информации. Однако фундаментальная суть риска состоит в том, что риск определяет
вероятность или возможность того, что некое событие произойдет и какие в этом будут последствия для организации.
Категории рисков
Существует большое множество категорий и типов рисков. Для наглядности я отмечу наиболее, на мой взгляд, важные и приведу примеры того, что может пойти не так:
Финансовый - ошибки в бухгалтерском учете, финансовая отчетность организации содержит ошибки, неточности, либо не содержит важной информации для заинтересованных сторон
Кредитный - невозврат кредита заемщиком
Рыночный - цена инвестиционного инструмента упала ниже чем ожидалось
Операционный - отклонения, неэффективность в операционной деятельности организации. При этом, например, в категорию операционных рисков можно отнести Риск подрядчика/Контрактный - подрядчик выполнил проект ниже качеством, либо не выполнил вовсе. Также, очень часто, к категории операционных рисков относят риск ИТ/ИБ - ключевая ИТ система работает с ошибками, произошла утечка персональных данных т.д. Как правило риск ИТ это подгруппа рисков бизнеса.
Взаимосвязь ИТ и бизнес-функций организации
Основная цель ИТ - помощь бизнесу в достижении миссии и целей организации. Каждое направление бизнеса создает ИТ систему, поддерживающую его бизнес-функцию. Тем самым чем выше автоматизация процессов организации, тем выше вероятность того, что что-то пойдет не так в средствах автоматизации, т.е. информационных технологиях.
Что такое риск ИТ?
Европейский Банковский регулятор (Europen Banking Authority) дает на мой взгляд наиболее точное определение.
Риск ИТ это риск потерь организации, вызванный:
нарушением конфиденциальности,
сбоем целостности систем и данных,
некорректной работой, либо недоступностью систем и данных,
либо невозможностью изменить ИТ систему, за разумное время и стоимость, в то время как среда функционирования и/или требования бизнеса меняются (т.е. быстрота изменений)
Также риск ИТ включает риск безопасности (ИБ), проистекающий от:
неадекватных либо некорректных внутренних процессов организации, либо внешних событий, включая кибер атаки либо неадекватную систему физической безопасности
Взаимосвязь риска ИТ и других категорий рисков
В случае реализации риска ИТ, рискового события связанного с ИТ, потенциально, подобно карточному домику, такое событие запускает реализацию рисков из других категорий рисков бизнеса, более наглядный пример приведен на картинке ниже.
*О том, что можно делать в каждом конкретном случае мы поговорим более подробно в нескольких примерах размещенных ниже, в Приложении к данной статье.
Допустимая величина риска, риск аппетит и уровень терпимости к риску
Риск можно измерить и риском можно управлять. Для этого существуют различные инструменты. На мой взгляд наиболее важные это:
Допустимая величина риска ( RISK CAPACITY ) это целевая сумма потерь, которую организация может выдержать, до того, как успешное функционирование бизнеса организации будет поставлено под вопрос.
С учетом допустимой величины риска, владельцы или совет директоров организации устанавливают риск аппетит ( RISK APPETITE ). Риск аппетит определяется как величина риска, которую организация готова принять с целью достижения своей миссии.
Уровень терпимости к риску это отклонение от риск аппетита. Подобные отклонения не желательны, но известно, что они достаточно ниже Допустимой величины риска.
Для наглядности приведу примеры:
Допустимая величина риска (RISK CAPACITY): В следствии сбоя ИТ системы, часть сервисов Организации недоступна для клиентов. Организация сможет выдержать убытки понесенные в следствии данного сбоя ИТ системы и недоступности ИТ системы на протяжении 7 дней, при сумме финансовых потерь до 10 млн. рублей в совокупности за 1 неделю.
Риск аппетит (RISK APPETITE):
Допустимое количество времени простоя ИТ системы в год: Общее количество времени недоступности ИТ системы не превышает 100 минут в год. ИТ система доступна 99,99 % времени в год.
Допустимая сумма денежных потерь от простоя/сбоя ИТ системы в год: Не более 0,00001% от генерируемого данной системой потока выручки.
Допустимое количество установленного типа сбоев/ошибок ИТ системы в год: Не более 2 сбоев/ошибок в неделю при работе ИТ системы/отчетов
Риск ИТ можно измерить
Как говорилось ранее, риск можно измерить как в количественном эквивалетнте так и качественном. Для этого используют различные метрики, приведу пример нескольких метрик рекомендуемых организацией ISC2.
Exposure Factor
SF - Фактор воздействия - % потерь, которые организация может понести в случае если актив будет подвержен реализации риска
Single Loss Expectancy
SLE - Единовременный ожидаемый убыток, стоимость присущая единовременной реализации риска в отношении актива
Asset Value
AV - стоимость актива
Annualized Rate of Occurrence
ARO - Частота реализации риска в год
Annualized Loss Expectancy
ALE - ожидаемые годовые убытки от реализации риска
Количественная оценка
Используя метрики приведенные выше, можно сделать количественную оценку потенциальных потерь в случае реализации риска присущего ИТ, например:
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 раза организация потеряет в два раза больше
Ну и что это дает? Зная о потенциальных потерях, даже приблизительно, менеджмент организации сможет более точно распределить расходы, сфокусировать необходимые силы, экспертизу и усилия и принять более осознанные управленческие решения.
Качественная оценка
Качественная оценка, это более простой способ оценки вероятности возникновения, реализации риска. Однако требующий больше экспертизы и привлечения экспертов из различных областей, включая представителей бизнеса, ИТ, ИБ, внешних консультантов.
Качественная оценка как правило выполняется присвоением риску уровня его вероятности, либо влияния на ту или иную цель организации.
Высокая/ Higher (Красный)
Средняя/ Medium (Желтый)
Низкая/ Low (Зеленый)
Наиболее точная оценка риска достигается при использовании одновременно, как количественной оценки риска, так и качественной.
Примеры рисков ИТ
На мой взгляд наиболее полно и точно риски присущие ИТ сформулированы в международном стандарте по аудиту №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
Примеры реализации рисков ИТ (рисковых событий)
Приведу наиболее свежие выдержки из общедоступных источников информации. Как я говорил в самом начале статьи "По причине действия/бездействия результат не будет соответствовать ожиданиям или планам". Данная фраза применима к каждому событию приведенному ниже:
Управление риском ИТ
Так что же делать? Как я говорил ранее, риском ИТ можно и нужно управлять. Подход в целом мало отличается от обычного подхода к управлению любой другой категорией рисков.
Давайте внесем ясность в термин "Управление риском". ISACA (CRISC) дает следующее определение - «Управление Риском» - это скоординированные действия по управлению и контролю за деятельностью организации с учетом возможного риска.
Риск можно рассматривать в контексте вероятности того, что цели организации не будут достигнуты. Таким образом «Управление Риском» это способ предсказания подобной вероятности, и/или снижения шансов на возникновение и/или снижения последствий возникновения. При этом - Эффективное управление риском может позволить максимизировать возможности организации.
Три линии защиты. Участники процесса управления риском
Существует общепризнанный подход к организации управления рисками. основная его цель повысить эффективность процесса управления и снизить вероятность нарушения принципа разграничения полномочий. Подход подразумевает разделение функционала участников процесса управления рисками и их логическое разделение на "Три линии защиты". Поговорим о них чуть более подробно:
Первая линия - это бизнес. Все кто участвует в повседневной деятельности организации. Например менеджер по продажам/закупкам, менеджеры по работе с клиентами, ИТ подразделения, финансовый департамент и т.д.
Вторая линия - это эксперты в области управления рисками. Например функция внутреннего контроля, функция управления рисками.
Третья линия - это функция аудита. Независимый проверяющий орган организации проверяющий что первая линия эффективно выполняет правила установленные второй линией.
При этом, может быть еще четвертая линия - это регулирующие органы, внешний аудитор и другие внешние заинтересованные участники.
Этапы управления риском ИТ
Управление риском ИТ является цикличным процессом. Далее, мы разберем каждый шаг чуть более подробно.
Идентификация риска ИТ и определение аппетита к риску
Идентификация риска ИТ - это процесс обнаружения, распознавания и документирования риска, которому подвержена организация.
Оценка и приоритезация идентифицированных риска ИТ
Оценка риска ИТ - это анализ рисковых сценариев, их приоритезация и оценка. Оценка может быть, как качественной (высокий/средний/низкий) так и количественной недоступность ИТ системы в минутах/денежные потери от недоступности ИТ системы, потери данных).
Снижение риска ИТ
Снижение риска ИТ - это выработка мер способствующих снижению вероятности реализации рисковых сценариев обнаруженных на шаге «Идентификации рисков». Мерами могут быть политики и процедуры, ограничение доступа и мониторинг действий пользователей ИТ систем, настройки безопасности ИТ систем, резервной копирование и другие.
Мониторинг и контроль риска ИТ, формирование отчетности по риску
Мониторинг риска ИТ - это выработка ключевых индикаторов риска, наблюдение и оценка эффективности процессов и процедур направленных на снижение риска и актуализация, обновление профиля рисков (перечня рисков присущих ИТ).
Это финальный этап управления, как правило весь цикл повторяется ежегодно, в каких-то ситуациях чаще.
Ценность управления риском ИТ
Так что-же это нам дает? Что дает процесс управления риском ИТ организации в обмен на существенные инвестиции? Эффективное и регулярное управление риском ИТ важно для организации материальными выгодами, которые оно приносит. Приведу несколько примеров:
Создание риск ориентированной культуры с меньшей зависимостью от отдельных специалистов повышает вероятность успешного завершения проектов
Приоретизация усилий по реакции на риск в соответствии с целями и приоритетами организации увеличивает способности организации к достижению целей и созданию ценности
Проактивная идентификация угроз, уязвимостей и последствий повышает надежность контроля за активами, снижает величину потенциальных потерь и систематизирует подход в усилиях по соответствию требованиям регуляторов
Улучшение производительности систем, процессов инцидент менеджмента и непрерывности бизнеса повышает предсказуемость и надежность процессов организации
Улучшение процессов контроля, мониторинга и отчетности, а также доступ к более точной и своевременной информации, упрощает процесс принятия решений и как следствие повышает уверенность акционеров
Подводя итоги
Риском ИТ и ИБ необходимо управлять. Управлять регулярно и по возможности эффективно. Это дает свои плюсы для бизнеса.
Благодраю Вас за то, что прочитали данный материал до конца и искренне надеюсь, что Вы узнали для себя что-то новое и полученная информация будет для Вас полезна!
Приложение. Примеры недостаточного внимания к управлению риском ИТ.
Обсудив с читателями и коллегами, я решил добавить немного реальных, но обезличенных и несколько упрощенных примеров из практики, когда риски ИТ реализовались, либо могли с достаточной легкостью быть реализованы, в силу недостатка контроля, и в той или иной мере привели или могли привести к реальным потерям организаций. Надеюсь, примеры буду полезны.
Пример 1
Россия. Компания разработчик технического, промышленного оборудования. В компании проводился регулярный аудит финансовой отчетности. В рамках аудита финансовой отчетности, независимый аудитор должен оценить влияние ряда рисков присущих ИТ на надежность процесса формирования фин. отчетности и на достоверность самой отчетности (ISA 315, PCAOB 2110). В какой-то момент, на протяжении финансового года, возникла угроза заражения систем компании вирусом-шифровальщиком PETYA (если интересно, то можно найти более детальную информацию в WWW). В силу того, что менеджмент компании регулярно игнорировал отчеты аудитора о недостатках в области управления рисками ИТ, вирус проник в системы компании и заразил (зашифровал) приблизительно чуть больше 50% всех систем компании. В перечень систем также вошли системы резервного копирования и часть ключевых систем участвующих в процессе формирования финансовой отчетности.
Компания пережила данную ситуацию, однако понесла операционные издержки. Также часть данных бухгалтерского учета восстанавливалась несколько недель специалистами вручную, на основе доступной первичной информации. Этого можно было бы избежать при наличии эффективного контроля над риском ИТ, например:
Наличие антивирусного ПО и его своевременного и регулярного обновления
Наличие своевременного и регулярного процесса установки обновлений и критических заплаток для систем компании
Наличие процесса информирования и обучения пользователей базовым основам информационной безопасности
Наличие эффективно-защищенного хранилища резервных копий с ключевой, значимой информации для компании
Пример 2
США. Крупная розничная торговая сеть.
На момент описываемого наблюдения компания обладала сетью из порядка 800 магазинов в разных штатах США. В каждом магазине были установлены POS терминалы и 2а POS сервера, собирающие информацию о продажах. Так как магазинов много, то система POS как для терминалов, так и для серверов настраивалась централизованно в центральном офисе. После того, как новая версия системы была готова, специалисты ее устанавливали во все магазины удаленно, либо с физического носителя.
Потенциальная проблема возникла в момент, когда в результате аудита выяснилось, что в образе (образ – готовая, настроенная для установки POS система на диске) обнаружились учетные записи администраторов, уволенных, либо переведенных на другие должности несколько лет назад, до момента проведения аудита.
Таким образом, на протяжении нескольких лет, уволенные/переведенные администраторы имели полный доступ к POS терминалам и серверам во всех 800 магазинах в разных штатах.
В данном конкретном случае ущерб не был обнаружен, однако в случае, например, обиды со стороны уволенного администратора, при наличии доступа к сети компании у уволенных/переведённых на другую должность сотрудников, торговая сеть могла лишиться части своих ключевых систем в магазинах и как следствие понести финансовые, репутационные потери, а также пострадать от санкций со стороны регуляторов.
Подобный риск можно было бы снизить при наличии эффективного контроля над риском ИТ, например:
Сократить количество предустановленных учетных записей до необходимого минимума и регулярно проверять их актуальность, каждый раз, когда новая система была готова к установке обновления
Внедрить регулярную проверку систем на наличие незаблокированных учетных записей уволенных, либо переведенных на другую должность сотрудников
Пример 3
Европа. Крупнейший производитель пива.
В одной из крупнейших пивоваренных компаний в мире для автоматизации большинства процессов была внедрена система SAP ERP. В ходе одного из аудитов были обнаружены расхождения в бухгалтерском учете и статьях отчетности, например, были обнаружены существенные расхождения в выручке от реализации пива на счетах компании, неизвестные контрагенты в справочниках, установленные скидки для ряда контрагентов, при этом никем не санкционированные.
После анализа собранной информации оказалось, что у команды подрядчика, который осуществлял настройку SAP ERP были неограниченные полномочия (SAP_ALL, DEBUG), при этом анализ действий пользователей с подобными полномочиями не проводился на регулярной основе. После внутреннего расследования и выяснения деталей, компания прекратила контрактные отношения с подрядчиком, а также существенно обновила команду сотрудников ИТ и менеджмента, отвечающих за реализацию продукции и управление мастерданными (НСИ).
Этой ситуации можно было бы избежать, снизив риски нарушения принципов разграничения полномочий и несогласованных изменений, например:
Убрать или максимально ограничить доступ к таким полномочиям, как SAP_ALL, DEBUG
Реализовать процедуру формализованного предоставления/блокировки доступа пользователей к подобным полномочиям
Внедрить регулярный мониторинг активности пользователей с подобными полномочиями
Реализовать механизм позволяющий осуществлять контроль над неизменностью согласованных изменений в системе
Журналировать критические действия в отдельном хранилище, недоступном для пользователей с доступом SAP_ALL, DEBUG
Лимитировать доступ подрядчика ограниченным промежутком времени, либо продолжительностью контракта
Пример 4
Напоследок немного комичная история, рассказанная моим коллегой Петром М. На одном из проектов по аудиту, выяснилось, что в компании нет документа регламентирующего процедуру резервного копирования, в частности, что копировать, когда и где хранить. В результате у владельцев систем и данных было одно видение того, что необходимо беречь, сохранять, а также приоритетности и глубины сохраняемой информации, а у команды ИТ было свое видение того, что важно и требует создания и хранения резервных копий, в результате в момент, когда что-то пошло не так, компания просто не смогла восстановить необходимую информацию в силу того, что ее просто никто не сохранил. Вывод – формализуйте приоритеты и задачи, согласуйте требования и пожелания со всеми участниками процесса.
И небольшая вишенка на торте для тех, кто дочитал приложение с примерами до конца: рекомендую посмотреть фильм Office Space (просто погуглите). В фильме приведен пример реализации риска ИТ, раскрывать детали не буду, наслаждайтесь отличным фильмом😊
