Текст книги "Управление риском ИТ. Основы"

Управление риском ИТ. Основы
Максим Торнов

В память о моих бабушке и дедушке

Главный редактор Юрий Иванов

Редактор Алина Тимофеева

Корректор Юрий Иванов

© Максим Торнов, 2024

ISBN 978-5-0064-4929-9

Создано в интеллектуальной издательской системе Ridero

Предисловие

⠀

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

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

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

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

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

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

От автора

Меня зовут Максим Торнов, и я работаю в области управления рисками, внутреннего контроля и аудита, специализируясь на рисках, присущих информационным технологиям. Продолжительное время работал в различных областях информационных технологий (далее ИТ), занимался проектами по оценке рисков, эффективности и внедрению систем внутреннего контроля работая в одной из консалтинговых компаний «Большой четверки»11
  «Большая четверка» – четыре крупнейших в мире сети компаний, предоставляющих аудиторские и консалтинговые услуги: Deloitte, Pricewaterhouse Coopers, Ernst & Young и KPMG.


[Закрыть] и в различных организациях из разных индустрий.

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

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

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


[Закрыть].

Википедия дает такое определение: Информацио́нные техноло́гии (ИТ, также – информационно-коммуникационные технологии) – процессы, использующие совокупность средств и методов сбора, обработки, накопления и передачи данных (первичной информации) для получения информации нового качества о состоянии объекта, процесса, явления, информационного продукта, а также распространения информации и способы осуществления таких процессов и методов (ФЗ №149-ФЗ). Этого нам хватит для понимания, что такое ИТ.

В отношении ИБ Википедия дает следующее определение: Информационная безопасность (англ. Information Security, а также – англ. InfoSec) – практика предотвращения несанкционированного доступа, использования, раскрытия, искажения, изменения, исследования, записи или уничтожения информации. Теперь мы готовы к погружению в область управления риском ИТ.

Глава 1.
Управление риском ИТ

Все, что может пойти не так, пойдет не так.

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

Если что-то просто не может пойти не так, оно все равно произойдет.

Эдвард Мерфи «Законы Мерфи»

1.1. РИСК – ЧТО МОЖЕТ ПОЙТИ НЕ ТАК?

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

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


[Закрыть]. Для себя я сформулировал такое: «По причине действия/бездействия результат не будет соответствовать ожиданиям или планам». Ниже мы более детально разберем виды рисков/рисковых событий.

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

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

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

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

Кредитный – невозврат кредита заемщиком.

Рыночный – цена инвестиционного инструмента упала ниже, чем ожидалось.

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

⠀

Взаимосвязь ИТ и бизнес-функций организации

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

⠀

1.2. ЧТО ТАКОЕ РИСК ИТ?

EBA – Европейский Банковский регулятор44
  Europen Banking Authority.


[Закрыть] дает, на мой взгляд, наиболее точное определение:

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

• нарушением конфиденциальности;

• сбоем целостности систем и данных;

• некорректной работой либо недоступностью систем и данных;

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

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

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

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

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

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

Допустимая величина риска, риск-аппетит

и уровень терпимости к риску

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

• допустимая величина риска (RISK CAPACITY), то есть целевая сумма потерь, которую организация может выдержать до того, как под угрозой окажется возможность ее дальнейшего успешного функционирования, с учетом допустимой величины риска владельцы или совет директоров организации устанавливают риск-аппетит (RISK APPETITE). Риск-аппетит определяется как величина риска, которую организация готова принять с целью достижения своей миссии;

• уровень терпимости к риску (RISK TOLERANCE), это отклонение от риск-аппетита, подобные отклонения не желательны, но известно, что они достаточно ниже допустимой величины риска.

Для наглядности приведу примеры:

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

• риск-аппетит (RISK APPETITE):

допустимое количество времени простоя ИТ-системы в год – общее количество времени недоступности ИТ-системы не превышает 100 минут в год. ИТ-система доступна 99,99% времени в год, допустимая сумма денежных потерь от простоя/сбоя ИТ-системы в год – не более 0,00001% от генерируемого данной системой потока выручки, допустимое количество установленного типа сбоев/ошибок ИТ-системы в год – не более двух сбоев/ошибок в неделю при работе ИТ-системы/отчетов.

Риск ИТ можно измерить

Риск можно измерить как в количественном эквиваленте, так и в качественном. Для этого используют различные метрики. Приведу для примера несколько метрик, рекомендуемых организацией ISC55
  ISC – Cybersecurity Certifications and Continuing Education.


[Закрыть].

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 (Зеленый).

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

1.3. ПРИМЕРЫ РИСКОВ ИТ

На мой взгляд, наиболее полно и точно риски, присущие ИТ, сформулированы в Международном стандарте по аудиту №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.

Примеры реализации ИТ-рисков

(рисковых событий)

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

1.4. УПРАВЛЕНИЕ РИСКОМ-ИТ

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

Давайте внесем ясность в термин «Управление риском». ISACA CRISC66
  ISACA: CRISC – Certified in Risk and Information Systems Control.


[Закрыть] дает следующее определение: «Управление риском – это скоординированные действия по управлению и контролю за деятельностью организации с учетом возможного риска».

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

Три линии защиты.

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

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

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

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

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

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

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

Управление ИТ-риском – это цикличный процесс. Давайте разберем каждый шаг.

1.5. ИДЕНТИФИКАЦИЯ РИСКА ИТ И ОПРЕДЕЛЕНИЕ

АППЕТИТА К РИСКУ

Идентификация риска ИТ – это процесс обнаружения, распознавания и документирования риска, которому подвержена организация.

Оценка и приоритезация идентифицированных

риска ИТ

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

Снижение риска ИТ

Снижение риска ИТ – это выработка мер, способствующих уменьшению вероятности реализации рисковых сценариев, обнаруженных на шаге идентификации рисков. Мерами могут быть различные управленческие документы, включая политики77
  Политика организации – заявление о намерениях, которые реализуются через процедуры или протокол. Политика, изложенная в виде руководящего документа, как правило, принимается высшим руководящим органом организации, в то время как процедуры или протоколы разрабатываются и принимаются ее старшими руководителями. https://ru.wikipedia.org


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

Мониторинг и контроль риска ИТ,

формирование отчетности по риску

Мониторинг риска ИТ – это выработка ключевых индикаторов риска, наблюдение и оценка эффективности процессов и процедур, направленных на снижение риска, актуализация и обновление профиля рисков (перечня рисков, присущих ИТ).

Это финальный этап управления. Как правило, весь цикл повторяется ежегодно, а иногда и чаще.

Ценность управления риском ИТ

Что это нам дает? Что именно дает процесс управления риском ИТ организации в обмен на существенные инвестиции? Эффективное и регулярное управление риском ИТ сулит для организации значительные материальные и нематериальные выгоды. Приведу несколько примеров:

• создание риск-ориентированной культуры и среды с меньшей зависимостью от отдельных специалистов повышает вероятность успешного завершения проектов;

• приоретизация усилий по реакции на риск в соответствии с целями и приоритетами организации увеличивает способности организации к достижению целей и созданию ценности;

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

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

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

1.6. ПОДВОДЯ ИТОГИ

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

ПРИЛОЖЕНИЕ 1.1. ПРИМЕРЫ НЕДОСТАТОЧНОГО

ВНИМАНИЯ К УПРАВЛЕНИЮ РИСКОМ ИТ

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

Пример 1

Россия. Компания – разработчик технического и промышленного оборудования. В компании проводился регулярный аудит финансовой отчетности, в рамках которого независимый аудитор должен оценить влияние ряда рисков, присущих ИТ, на надежность процесса формирования финансовой отчетности и на достоверность самой отчетности88
  ISA 315, PCAOB 2110 – AS 2110: Identifying and Assessing Risks of Material Misstatement.


[Закрыть]. В какой-то момент на протяжении финансового года возникла угроза заражения систем компании вирусом-шифровальщиком PETYA (если интересно, в сети Интернет вы можете найти более детальную информацию о «вирусе»). При этом менеджмент компании регулярно игнорировал отчеты аудитора о недостатках в области управления рисками ИТ. Вирус проник в системы компании и заразил (зашифровал) больше половины всех систем компании, в том числе системы резервного копирования и часть ключевых систем, участвующих в процессе формирования финансовой отчетности.

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

• наличие антивирусного ПО и его своевременное и регулярное обновление;

• наличие своевременного и регулярного процесса установки обновлений и критических «заплаток» для систем компании;

• наличие процесса информирования и обучения пользователей основам информационной безопасности;

• наличие эффективно защищенного хранилища резервных копий с ключевой, значимой для компании информацией.

Пример 2

США. Крупная розничная торговая сеть.

На момент описываемого события компания обладала сетью из порядка 800 магазинов в разных штатах США. В каждом магазине были установлены POS99
  POS-терминал (от англ. point of sale – точка продажи, и от англ. terminal – окончание) – это электронное программно-техническое устройство для приема оплаты, т. е. «кассы», где осуществляется оплата товара, различными способами и средствами. После оплаты информация поступает на серверы POS-системы, агрегируется и в режиме онлайн или с иной периодичностью передается в головной офис торговой сети для дальнейшего учета деятельности организации. https://ru.wikipedia.org


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

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

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

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

Подобный риск можно было бы снизить при наличии эффективного контроля над риском ИТ, например:

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

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

Пример 3

Европа. Крупнейший производитель пива.

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

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

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

• запретить или максимально ограничить доступ к таким полномочиям, как SAP_ALL, DEBUG.

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

• внедрить регулярный мониторинг активности пользователей с подобными полномочиями;

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

• журналировать, то есть производить периодическую фиксацию критических действий в отдельном хранилище, недоступном для пользователей с доступом SAP_ALL, DEBUG;

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

Пример 4

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

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