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

Глава 2.
Внедрение контроля над ИТ

Что-то изменить может только тот, у кого все под контролем.

Рикако Такигава

Что вы узнаете из этой главы

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

2.1. ПРЕДПОЛОЖИМ, ЧТО…

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

• повышение и удержание лояльности клиентов;

• соответствие требованиям различных регуляторных органов;

• надежность и достоверность финансовой отчетности;

• эффективность и своевременность принятия управленческих решений.

Компания динамично развивается, новое ПО, «фичи», отчеты и т. д. появляются, как бургеры в известном ресторане.

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

Данные ИТ-системы делятся на самостоятельно разработанные инструменты и автоматизированные сервисы, а также купленные готовые продукты (out-of-the-box/off-the-shelf), охватывающие все бизнес-процессы внутри компании.

Существующая проблема

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

• ошибки в отчетах или в работе систем;

• некорректный доступ пользователей;

• утечки персональных данных;

• недоступность систем;

• недостаточная производительность систем.

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

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

Перед менеджментом стоят задачи:

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

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

• определить методику, инструменты и объекты для оценки эффективности контрольных процедур над ИТ;

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

С чего можно было бы начать?

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

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

Риски, присущие ИТ, могут приводить к реализации рисков ИБ.

Шаг 1. Понять связь между бизнес-процессами и ИТ-средой – используемыми в компании информационными технологиями

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

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

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

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

• сформированные отчеты не полные и/или не точные;

• данные повреждены или недоступны;

• расчеты ошибочны;

• некоторые интерфейсы с другими системами теряют данные;

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

• ошибки в разработанном ПО либо задержки в его разработке.

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

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

Шаг 2. Понять критичность ИТ-систем и присущие риски

Очевидно, Шаг 1 может дать очень большой перечень систем, технологий, автоматизированных сервисов и т. д. Но все ли они важны и критичны для бизнеса компании? Если да, то какова степень критичности систем и их элементов?

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

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

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

ВАЖНО: необходимо принимать во внимание, что ИТ-система или автоматизированный сервис – это комплекс, который может состоять из различных интегрированных подсистем, например, прикладное ПО + ОС + СУБД + сеть + интерфейсы + промежуточное ПО и т. д.

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

Шаг 3. Определить набор контрольных процедур в области ИТ применительно к типам/вариантам/категориям ИТ-систем и автоматизированных сервисов

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

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

В данном случае при разработке таких документов и контрольных процедур можно воспользоваться одной из лучших практик описания – «5W»1010
  Пять «почему» (или 5 «Why?») – это итеративный метод вопросов, используемый для исследования причинно-следственных связей, лежащих в основе конкретной проблемы.


[Закрыть], исследуя «Кто», «Что», «Где», «Когда» и «Почему».

Данные документы должны формализовать непосредственно процедуры контроля над ИТ, то есть могут описывать:

1. Кто делает?

2. Что делает?

3. Как часто делает?

4. Каков результат?

5. Зачем и какова цель?

То есть, используя «5W», компания может более точно разработать необходимые документы, включая политики и процедуры, тем самым привнеся эффективность исполнения контроля над ИТ и усилив эффективность процесса управления риском ИТ.

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

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

Например, в зависимости от сложности и критичности ИТ-системы, может требоваться меньшее количество контрольных процедур (сравните важность и критичность для бизнеса таких систем, как SAP ERP и BMC Remedy1111
  Система ITSM


[Закрыть]), первая – это ERP система, большинство бизнес-процессов организации могут зависеть от ERP системы, в противовес системе управления услугами, автоматизирующей процесс ITIL, поддерживающей различные формы заявок на обслуживание и запросов пользователей.

Следует обратить внимание, что при разработке и внедрении контроля над ИТ необходимо учитывать все уровни ИТ, включая само прикладное ПО, ОС, СУБД, сеть и т. д.

Шаг 4. Определить «правила» для ИТ, в частности, политики, процедуры, базовые требования к системам и автоматизированным сервисам

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

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

Вот пример, что может пойти не так и что можно сделать, чтобы избежать негативных последствий:

Шаг 5. Коммуникация с владельцами ИТ-систем, автоматизированных сервисов и процессов

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

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

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

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

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

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

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

2.2. КАКОЙ КОНТРОЛЬ МЫ ХОТИМ ВНЕДРИТЬ?

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

Автор считает, что наиболее критичными и первичными к внедрению процедурами контроля над ИТ являются:

Управление административным доступом

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

Управление изменениями

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

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

Управление доступом пользователей

Пользователи могут иметь доступ к ИТ-системе только в соответствии с их должностными обязанностями, при этом уровень доступа должен быть понятен владельцу системы и им же согласован в соответствии с принципом разграничения полномочий1212
  SoD. Segregation of duties или Separation of duties – это концепция, состоящая в том, что пользователь не может совершить транзакцию без содействия других пользователей. Например, пользователь в одиночку не может добавить нового поставщика, выписать счет или заплатить поставщику. Таким образом снижается риск ошибки или мошенничества. https://ru.wikipedia.org/wiki


[Закрыть].

Проверка и прекращение доступа

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

Настройки безопасности

Параметры безопасности всех без исключения ИТ-систем задаются в соответствии с действующей «Политикой информационной безопасности компании».

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

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

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

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

2.3. МОНИТОРИНГ ИТ-РИСКОВ. ОЦЕНКА КОНТРОЛЯ

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

Обратите внимание: всегда должен соблюдаться принцип разграничения полномочий. Помните о трех линиях защиты?

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

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

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

Для примера можно вспомнить, что случилось в недалеком прошлом с компаниями Enron Corp. и Arthur Andersen L LP1313
  Enron Scandal, https://ru.wikipedia.org


[Закрыть]. В частности, подобные события, связанные с этими зарубежными компаниями, послужили первопричиной создания и принятия закона Сарбейнса-Оксли1414
  SOX, https://en.wikipedia.org


[Закрыть], известного еще как «Закон о реформе бухгалтерского учета публичных компаний и защите инвесторов».

Так как же понять, эффективен ли процесс управления ИТ-риском и контроль над ИТ?

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

Вот пример доказательств эффективности/неэффективности контрольной процедуры, которые могут быть собраны для анализа и оценки эффективности:

Административный доступ

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

Управление изменениями

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

Управление доступом

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

Проверка и прекращение доступа

Списки уволенного или переведенного персонала с датами изменения доступа. Политики и процедуры управления доступом.

Настройки безопасности

Данные с настройками безопасности ИТ-систем и автоматизированных сервисов. Политика безопасности или базовые требования к настройкам безопасности для отдельных ИТ-систем.

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

2.4. ПОЧЕМУ ЭТО ВАЖНО?

Вот мы и подошли к самым важным, на мой взгляд, вопросам:

Почему важно управлять ИТ-рисками? Почему необходим контроль над ИТ? Как убедить в этом владельцев ИТ-систем, автоматизированных сервисов и процессов?

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

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

Давайте вместе вспомним:

Первая линия – бизнес

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

Вторая линия – специалисты по управлению рисками

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

Третья линия – служба внутреннего аудита

Независимый орган компании, который проверяет, насколько эффективно первая линия следует правилам, установленными второй линией защиты

Смысл таких усилий?

Так почему же важно управлять ИТ-рисками? Почему важен контроль над ИТ? Зачем это владельцам?

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

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

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

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

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

Но и это еще не всё! Какие преимущества могут быть у компании и руководства от управления ИТ-рисками и эффективности контроля над ИТ?

Помимо роста исполнимости KPI1515
  Key performance indicators, или ключевые показатели производительности и эффективности – это числовые показатели деятельности, которые помогают измерить степень достижения целей или оптимальности процесса, а именно: результативность и эффективность. https://ru.wikipedia.org


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

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

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

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

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

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

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

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

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

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

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

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

• какие цели могут быть у владельцев систем и сервисов?

• какие могут быть препятствия для достижения этих целей?

• как преодолеть препятствия и достичь цели?

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

ПРИЛОЖЕНИЕ 2.1. IUC И IPE

Для разработки эффективного контроля над ИТ, эффективных контрольных процедур в области ИТ, при разработке дизайна контрольных процедур необходимо учесть, формализовать и добавить в дизайн контрольных процедур такую сущность, как IUC1616
  Information Used in the Control – информация, используемая в контрольной процедуре.


[Закрыть], также известную как IPE, называемую внешними аудиторами информацией, предоставленной/произведенной организацией.

Этот момент весьма важен, поскольку владелец контроля (лицо, осуществляющее контроль, исполняющее контрольную процедуру, мероприятие или действие), в зависимости от специфики контрольной процедуры (как правило, целью контрольной процедуры является выявление отклонений) должен проверить следующие факторы:

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

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

• Являются ли данные, используемые при контрольной процедуре, полными и точными. Например, отчет, используемый в контрольной процедуре, имеет все строки, включая все выбранные столбцы с правильной последовательностью информации, соответствующей дизайну контрольной процедуры.

⠀

ПРИЛОЖЕНИЕ 2.2. КЛЮЧЕВЫЕ ФАКТОРЫ ДИЗАЙНА

КОНТРОЛЬНОЙ ПРОЦЕДУРЫ

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


[Закрыть] необходимо учесть, формализовать и включить следующие факторы, присущие дизайну контрольной процедуры:

• Соответствие цели контрольной процедуры и ее взаимосвязь с риском. Это означает, что контрольная процедура точно соответствует своей цели по снижению риска/рисков.

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

• Компетентность и полномочия лица (лиц), осуществляющего контроль, выполняющего контрольное действие, процедуру. Это означает, что исполнитель (в некоторых случаях владелец) контрольной процедуры имеет необходимые навыки и полномочия для осуществления контроля (человек знает «кто делает», «что делает», «как делает» и «зачем делает» и способен осуществлять контроль).

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

• Уровень детализации анализа и предсказуемость выявления отклонения. Это означает, что дизайн контрольной процедуры позволяет идентифицировать отклонение с большой точностью и вероятностью, например, контрольная процедура по анализу доступа исполняется «ежемесячно» вместо «ежегодно» и на «уровне доступа к каждому объекту информационной системы», назначенного пользователю вместо «агрегированной роли без детализации».

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

○ 1 – выявлено отклонение,

○ 2 – создан своевременный запрос на исправление,

○ 3 – своевременно устранено отклонение,

○ 4 – запрос своевременно проверен и закрыт исполнителем контрольной процедуры.

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