Бесплатный фрагмент - Управление риском ИТ. Основы
В память о моих бабушке и дедушке
Предисловие
⠀
Недоступность ИТ-сервисов и систем, ошибки и медленная работа отдельных алгоритмов и систем в целом, потеря важных данных и информации, нарушение целостности отчетов и многие другие проблемы, присущие ИТ, влияют на эффективность, устойчивость и репутацию организации, ведут организацию к непредвиденным, а иногда и чувствительным финансовым издержкам. Очень часто, пренебрегая вопросами управления рисками, присущими ИТ, организации могут столкнуться с одной или несколькими из перечисленных выше проблем.
Однако, пытаясь предотвратить подобные проблемы, большинство руководителей вводят все новые и новые меры, принуждая сотрудников их выполнять, что зачастую превращается в хаотичные мероприятия и малоэффективные действия с созданием большого количества трудночитаемых документов.
Неконсистентный и нерегулярный подход в применении таких мер, недооценка или непонимание различных рисков, присущих ИТ, приводит к невозможности предусмотреть скрытые угрозы, и, как следствие, многие организации нерационально, зачастую напрасно расходуют ресурсы, при этом не снижая сами риски ИТ, что в свою очередь может нанести серьезный и в отдельных случаях непоправимый ущерб бизнесу.
Книга знакомит читателя с основами в области управления рисками и непосредственно рисками, присущими информационным технологиям, влияющими на достижение различных целей организаций.
Прочитав эту книгу, читатель узнает, что такое риск информационных технологий, какие категории и группы ИТ-рисков существуют, как они взаимосвязаны с бизнес-процессами, какие процессы и процедуры необходимо внедрить для эффективного управления подобными рисками, тем самым повысив надежность и эффективность ИТ-систем, процессов и процедур организации. Читатель сможет более осознанно принимать решения или выполнять поставленные задачи, связанные или зависимые от ИТ, сможет избежать распространенных ошибок и негативных сценариев при управлении ИТ или непосредственно при использовании ИТ в бизнес-процессах организации.
Книга состоит из четырех глав. В первой главе излагаются основы управления рисками и описаны наиболее часто встречающиеся риски ИТ. Вторая глава дает рекомендации по внедрению контроля над ИТ, управлению рисками ИТ. В третье главе на примере разработки программного обеспечения предлагается подход, учитывающий рекомендации из первых двух глав применительно к выпуску или внедрению программного обеспечения, закладывая механизмы, позволяющие снизить вероятность негативных для бизнеса ситуаций, связанных с ИТ. Четвертая глава помогает задуматься о будущем развитии ИТ и подтолкнуть читателя к попытке управления рисками, присущими искусственному интеллекту.
От автора
Меня зовут Максим Торнов, и я работаю в области управления рисками, внутреннего контроля и аудита, специализируясь на рисках, присущих информационным технологиям. Продолжительное время работал в различных областях информационных технологий (далее ИТ), занимался проектами по оценке рисков, эффективности и внедрению систем внутреннего контроля работая в одной из консалтинговых компаний «Большой четверки» и в различных организациях из разных индустрий.
Уверен, в настоящее время тема управления рисками, присущими информационным технологиям, не перестает быть актуальной. От того, насколько организация эффективно управляет рисками, присущими именно ИТ, зависит достижение многих целей организации, например, таких как надежность и эффективность работы бизнес-процессов, соответствие организации требованиям регуляторных органов, достоверность финансовой отчетности и многие другие цели.
Прочитав эту книгу, читатель узнает, что такое риск информационных технологий, какие категории и группы ИТ рисков существуют, как они взаимосвязаны с бизнес-процессами, какие процессы и процедуры необходимо внедрить для эффективного управления подобными рисками, тем самым повышая надежность и эффективность ИТ систем, процессов и процедур организации. Читатель сможет более осознанно принимать решения или выполнять поставленные задачи связанные или зависимые от ИТ, сможет избежать распространенных ошибок и негативных сценариев при управлении ИТ или непосредственно использовании ИТ в бизнес-процессах организации.
В этой книге мне хотелось бы рассказать вам о собственном видении основ управления риском ИТ. Я искренне надеюсь, что книга станет вам полезна и, возможно, натолкнет вас на новые идеи, которые вы сможете направить на благо вашего личного развития и развития вашей организации. Но для начала давайте вспомним, что такое ИТ и информационная безопасность (далее ИБ).
Википедия дает такое определение: Информацио́нные техноло́гии (ИТ, также — информационно-коммуникационные технологии) — процессы, использующие совокупность средств и методов сбора, обработки, накопления и передачи данных (первичной информации) для получения информации нового качества о состоянии объекта, процесса, явления, информационного продукта, а также распространения информации и способы осуществления таких процессов и методов (ФЗ №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». Это определение дано Комитетом организаций-спонсоров Комиссии Тредвея. Для себя я сформулировал такое: «По причине действия/бездействия результат не будет соответствовать ожиданиям или планам». Ниже мы более детально разберем виды рисков/рисковых событий.
Риск можно рассматривать с качественной и/или количественной точек зрения, при этом определение риска может различаться в зависимости от используемого источника информации. Однако фундаментальная суть риска состоит в том, что риск определяет вероятность или возможность того, что некое событие произойдет и какие в этом будут последствия для организации.
Категории рисков
Существует множество категорий и типов рисков. Для наглядности следует отметить наиболее, на мой взгляд, важные и привести примеры того, что может пойти не так.
Финансовый — ошибки в бухгалтерском учете, финансовая отчетность организации содержит ошибки, неточности либо не содержит важной информации для заинтересованных сторон.
Кредитный — невозврат кредита заемщиком.
Рыночный — цена инвестиционного инструмента упала ниже, чем ожидалось.
Операционный — отклонения, неэффективность в операционной деятельности организации. При этом, например, в категорию операционных рисков можно отнести внутреннее и/или внешнее мошенничество, риск подрядчика/контрактный/санкционный — подрядчик выполнил проект ниже качеством либо не выполнил вовсе, отказался от поддержки ИТ системы, отозвал лицензию и другие подобные варианты. Также очень часто к категории операционных рисков относят риск ИТ/ИБ — ключевая ИТ-система работает с ошибками, произошла утечка персональных данных и т. д. Как правило, риск ИТ — это подгруппа рисков бизнеса.
⠀
Взаимосвязь ИТ и бизнес-функций организации
Основная цель ИТ — помощь бизнесу в достижении миссии и целей организации. Каждое направление бизнеса создает ИТ-систему, поддерживающую его бизнес-функцию. Тем самым чем выше автоматизация процессов организации, тем выше вероятность того, что что-то пойдет не так в средствах автоматизации, то есть информационных технологиях.
⠀
1.2. ЧТО ТАКОЕ РИСК ИТ?
EBA — Европейский Банковский регулятор дает, на мой взгляд, наиболее точное определение:
Риск ИТ — это риск потерь организации, вызванный:
• нарушением конфиденциальности;
• сбоем целостности систем и данных;
• некорректной работой либо недоступностью систем и данных;
• невозможностью изменить ИТ-систему за разумное время и стоимость, в то время как среда функционирования и/или требования бизнеса меняются (то есть быстрота изменений).
Риск ИТ включает еще и риск безопасности (ИБ), проистекающий от:
• неадекватных либо некорректных внутренних процессов, организации, либо внешних событий, включая кибератаки, либо неадекватную систему физической безопасности.
Взаимосвязь риска ИТ и других категорий рисков
В случае реализации риска ИТ, рискового события, связанного с ИТ, потенциально, подобно карточному домику, такое событие запускает реализацию рисков из других категорий рисков бизнеса. Более наглядный пример приведен на изображении ниже.
О том, что можно сделать в каждом конкретном случае, мы более подробно поговорим и разберем в нескольких примерах, размещенных ниже, в Приложении 1.1. к первой главе.
Допустимая величина риска, риск-аппетит
и уровень терпимости к риску
Риск можно измерить, риском можно управлять. Для этого существуют различные инструменты. На мой взгляд, наиболее важные — это:
• допустимая величина риска (RISK CAPACITY), то есть целевая сумма потерь, которую организация может выдержать до того, как под угрозой окажется возможность ее дальнейшего успешного функционирования, с учетом допустимой величины риска владельцы или совет директоров организации устанавливают риск-аппетит (RISK APPETITE). Риск-аппетит определяется как величина риска, которую организация готова принять с целью достижения своей миссии;
• уровень терпимости к риску (RISK TOLERANCE), это отклонение от риск-аппетита, подобные отклонения не желательны, но известно, что они достаточно ниже допустимой величины риска.
Для наглядности приведу примеры:
• допустимая величина риска (RISK CAPACITY): вследствие сбоя ИТ-системы часть сервисов организации недоступна для клиентов. Организация сможет выдержать убытки, понесенные в результате данного сбоя ИТ-системы и недоступности ИТ-системы на протяжении семи дней при сумме финансовых потерь до 10 млн рублей в совокупности за одну неделю.
• риск-аппетит (RISK APPETITE):
допустимое количество времени простоя ИТ-системы в год — общее количество времени недоступности ИТ-системы не превышает 100 минут в год. ИТ-система доступна 99,99% времени в год, допустимая сумма денежных потерь от простоя/сбоя ИТ-системы в год — не более 0,00001% от генерируемого данной системой потока выручки, допустимое количество установленного типа сбоев/ошибок ИТ-системы в год — не более двух сбоев/ошибок в неделю при работе ИТ-системы/отчетов.
Риск ИТ можно измерить
Риск можно измерить как в количественном эквиваленте, так и в качественном. Для этого используют различные метрики. Приведу для примера несколько метрик, рекомендуемых организацией ISC.
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 CRISC дает следующее определение: «Управление риском — это скоординированные действия по управлению и контролю за деятельностью организации с учетом возможного риска».
Риск можно рассматривать в контексте вероятности того, что цели организации не будут достигнуты. И управление риском — это способ предсказания подобной вероятности, снижения шансов на возникновение, снижения последствий возникновения. При этом эффективное управление риском может позволить организации максимизировать свои возможности.
Три линии защиты.
Участники процесса управления риском
Существует общепризнанный подход к организации управления рисками, основная его цель — повысить эффективность процесса управления и снизить вероятность нарушения принципа разграничения полномочий. Подход подразумевает разделение функционала участников процесса управления рисками и их логическое разделение на три линии защиты. Поговорим о них более подробно.
Первая линия — это бизнес-подразделения организации, все те, кто участвует в ее повседневной деятельности. Например, менеджеры по продажам/закупкам, по работе с клиентами, ИТ-подразделения, финансовый, налоговый департаменты и т. д.
Вторая линия — это эксперты в области управления рисками. Например, функция внутреннего контроля, функция управления рисками.
Третья линия — это функция внутреннего аудита. Независимое подразделение организации, проверяющее, эффективное выполнение и соблюдение первой линией правил, установленных второй линией и других требований, предъявляемых к организации.
При этом может быть еще четвертая линия — это регулирующие органы, независимый внешний аудитор и другие внешние заинтересованные участники.
Этапы управления риском ИТ
Управление ИТ-риском — это цикличный процесс. Давайте разберем каждый шаг.
1.5. ИДЕНТИФИКАЦИЯ РИСКА ИТ И ОПРЕДЕЛЕНИЕ
АППЕТИТА К РИСКУ
Идентификация риска ИТ — это процесс обнаружения, распознавания и документирования риска, которому подвержена организация.
Оценка и приоритезация идентифицированных
риска ИТ
Оценка риска ИТ — это анализ рисковых сценариев, их приоритезация и оценка. Оценка может быть как качественной (высокий/средний/низкий), так и количественной (недоступность ИТ-системы в минутах / денежные потери от недоступности ИТ-системы, потери данных).
Снижение риска ИТ
Снижение риска ИТ — это выработка мер, способствующих уменьшению вероятности реализации рисковых сценариев, обнаруженных на шаге идентификации рисков. Мерами могут быть различные управленческие документы, включая политики организации, приказы, а также меры, предпринимаемые организацией, такие как различные формализованные процедуры и мероприятия, например, ограничение доступа и мониторинг действий пользователей ИТ-систем, настройки безопасности ИТ-систем, резервное копирование и другие.
Мониторинг и контроль риска ИТ,
формирование отчетности по риску
Мониторинг риска ИТ — это выработка ключевых индикаторов риска, наблюдение и оценка эффективности процессов и процедур, направленных на снижение риска, актуализация и обновление профиля рисков (перечня рисков, присущих ИТ).
Это финальный этап управления. Как правило, весь цикл повторяется ежегодно, а иногда и чаще.
Ценность управления риском ИТ
Что это нам дает? Что именно дает процесс управления риском ИТ организации в обмен на существенные инвестиции? Эффективное и регулярное управление риском ИТ сулит для организации значительные материальные и нематериальные выгоды. Приведу несколько примеров:
• создание риск-ориентированной культуры и среды с меньшей зависимостью от отдельных специалистов повышает вероятность успешного завершения проектов;
• приоретизация усилий по реакции на риск в соответствии с целями и приоритетами организации увеличивает способности организации к достижению целей и созданию ценности;
• проактивная идентификация угроз, уязвимостей и оценка последствий повышает надежность контроля над активами организации, снижает величину потенциальных потерь и систематизирует подход в усилиях по соответствию требованиям регуляторов;
• улучшение производительности систем, процессов инцидент-менеджмента и непрерывности бизнеса повышает предсказуемость и надежность процессов организации, то есть устойчивость и выживаемость организации.;
• улучшение процессов контроля, мониторинга и отчетности, доступ к более точной, полной и своевременной информации, что упрощает процесс принятия решений и, как следствие, повышает уверенность в надежности и эффективности организации всех заинтересованных сторон.
1.6. ПОДВОДЯ ИТОГИ
Надеюсь, прочтя эту главу, вы узнали для себя что-то новое и полезное об управлении риском информационных технологий, а также теперь понимаете необходимость и пользу регулярного и эффективного управления риском ИТ. В следующей главе мы поговорим о методах контроля над риском ИТ.
ПРИЛОЖЕНИЕ 1.1. ПРИМЕРЫ НЕДОСТАТОЧНОГО
ВНИМАНИЯ К УПРАВЛЕНИЮ РИСКОМ ИТ
Обсудив эту главу с коллегами, я решил добавить немного реальных, но по понятным причинам обезличенных и несколько упрощенных примеров из практики, когда риски ИТ реализовались либо могли с достаточной легкостью быть реализованы из-за недостатка контроля и в той или иной мере привели или могли привести к реальным потерям. Надеюсь, примеры буду полезны.
Пример 1
Россия. Компания — разработчик технического и промышленного оборудования. В компании проводился регулярный аудит финансовой отчетности, в рамках которого независимый аудитор должен оценить влияние ряда рисков, присущих ИТ, на надежность процесса формирования финансовой отчетности и на достоверность самой отчетности. В какой-то момент на протяжении финансового года возникла угроза заражения систем компании вирусом-шифровальщиком PETYA (если интересно, в сети Интернет вы можете найти более детальную информацию о «вирусе»). При этом менеджмент компании регулярно игнорировал отчеты аудитора о недостатках в области управления рисками ИТ. Вирус проник в системы компании и заразил (зашифровал) больше половины всех систем компании, в том числе системы резервного копирования и часть ключевых систем, участвующих в процессе формирования финансовой отчетности.
Компания справилась с ситуацией, однако понесла существенные операционные издержки. Также часть данных бухгалтерского учета за потерянный период восстанавливалась несколько недель различными специалистами вручную, на основе доступной первичной информации. Этого можно было бы избежать при наличии эффективного контроля над риском ИТ, например:
• наличие антивирусного ПО и его своевременное и регулярное обновление;
• наличие своевременного и регулярного процесса установки обновлений и критических «заплаток» для систем компании;
• наличие процесса информирования и обучения пользователей основам информационной безопасности;
• наличие эффективно защищенного хранилища резервных копий с ключевой, значимой для компании информацией.
Пример 2
США. Крупная розничная торговая сеть.
На момент описываемого события компания обладала сетью из порядка 800 магазинов в разных штатах США. В каждом магазине были установлены POS-терминалы и два POS-сервера, ежедневно собирающие информацию о продажах магазинов. Так как магазинов много, то система POS как для терминалов, так и для серверов настраивалась централизованно в главном офисе. После того как новая версия системы была готова, специалисты устанавливали ее во все магазины либо удаленно, либо с физического носителя.
Потенциальная проблема возникла в момент, когда в результате аудита выяснилось, что в образе (образ — готовая, настроенная для установки POS-система на диске) обнаружились учетные записи администраторов, уволенных либо переведенных на другие должности несколько лет назад, еще до аудита.
Таким образом, на протяжении нескольких лет уволенные либо переведенные администраторы имели полный доступ к POS-терминалам и серверам во всех восьмистах магазинах в разных штатах.
В данном конкретном случае ущерб не был обнаружен, такой задачи просто не стояло, однако в случае, например, обиды со стороны уволенного администратора при наличии доступа к сети компании у уволенных/переведенных на другую должность такого рода сотрудников торговая сеть могла лишиться части или полностью своих ключевых систем в магазинах и, как следствие, понести финансовые и/или репутационные потери, а также пострадать от санкций со стороны регуляторов.
Подобный риск можно было бы снизить при наличии эффективного контроля над риском ИТ, например:
• сократить количество предустановленных учетных записей до необходимого минимума и регулярно проверять их актуальность каждый раз, когда проводилась установка новых или обновление существующих систем;
• внедрить регулярную проверку систем на наличие незаблокированных учетных записей уволенных либо переведенных на другую должность сотрудников.
Пример 3
Европа. Крупнейший производитель пива.
В одной из крупнейших пивоваренных компаний в мире для автоматизации большинства процессов была внедрена система SAP ERP. В ходе одного из аудитов были обнаружены существенные расхождения в бухгалтерском учете и статьях отчетности, например, по выручке от реализации пива на счетах компании, неизвестные контрагенты в справочниках, установленные скидки для ряда контрагентов, при этом никем не санкционированные.
После анализа собранной информации оказалось, что у команды подрядчика, который осуществлял настройку системы SAP ERP, были неограниченные полномочия (SAP_ALL, DEBUG), при этом анализ действий пользователей с подобными полномочиями не проводился на регулярной основе. После внутреннего расследования и выяснения деталей компания прекратила контрактные отношения с подрядчиком, а также существенно обновила команду сотрудников ИТ и менеджмента, отвечающих за реализацию продукции и управление мастер-данными, нормативно-справочной информацией.
Этой ситуации можно было бы избежать, снизив риски нарушения принципов разграничения полномочий и несогласованных изменений, например:
• запретить или максимально ограничить доступ к таким полномочиям, как SAP_ALL, DEBUG.
• реализовать процедуру формализованного предоставления/блокировки доступа пользователей, сотрудников подрядных организаций к подобным полномочиям.
• внедрить регулярный мониторинг активности пользователей с подобными полномочиями;
• реализовать механизм, позволяющий осуществлять контроль, с тем чтобы любые произведенные в системе и согласованные заказчиком изменения затем оставались неизменными либо в дальнейшем изменялись только по согласованию с заказчиком или непосредственно владельцем системы;
• журналировать, то есть производить периодическую фиксацию критических действий в отдельном хранилище, недоступном для пользователей с доступом SAP_ALL, DEBUG;
• ограничить доступ подрядчику определенным промежутком времени либо продолжительностью контракта.
Пример 4
Напоследок — немного комичная история, рассказанная моим коллегой Петром М. На одном из проектов по аудиту выяснилось, что в компании нет документа, регламентирующего процедуру резервного копирования, в частности, что копировать, когда и где хранить. В результате у владельцев систем и данных было одно видение того, что необходимо беречь и сохранять, а также приоритетности и глубины сохраняемой информации, а у команды ИТ было свое видение того, что важно и требует создания и хранения резервных копий. В результате, когда что-то пошло не так, компания просто не смогла восстановить необходимую информацию — ее просто никто не сохранил. Вывод — формализуйте приоритеты и задачи, согласуйте требования и пожелания со всеми участниками процесса.
И небольшая вишенка на торте для тех, кто дочитал примеры до конца: рекомендую посмотреть фильм Office Space (просто погуглите). В фильме приведен пример реализации риска ИТ. Раскрывать детали не буду, наслаждайтесь отличным фильмом!
Глава 2.
Внедрение контроля над ИТ
Что-то изменить может только тот, у кого все под контролем.
Рикако Такигава
Что вы узнаете из этой главы
В этой главе хочу поделиться с вами своими знаниями и опытом по внедрению контроля над ИТ, а главное, рассказать о том, как можно убедить владельцев ИТ-систем, автоматизированных сервисов и процессов в необходимости управления рисками, присущими ИТ (включая риски ИБ), и какие выгоды это может принести как им, так и компании.
2.1. ПРЕДПОЛОЖИМ, ЧТО…
Существует некая высокотехнологичная компания, существенно зависящая от ИТ и различных автоматизированных сервисов и процессов. Так же, как и у любой компании, у нее есть различные цели, например, такие, как:
• повышение и удержание лояльности клиентов;
• соответствие требованиям различных регуляторных органов;
• надежность и достоверность финансовой отчетности;
• эффективность и своевременность принятия управленческих решений.
Компания динамично развивается, новое ПО, «фичи», отчеты и т. д. появляются, как бургеры в известном ресторане.
ИТ-ландшафт компании представляет собой среду, состоящую из более чем 70 работающих автоматизированных систем, совместно взаимодействующих в интегрированной и децентрализованной инфраструктуре.
Данные ИТ-системы делятся на самостоятельно разработанные инструменты и автоматизированные сервисы, а также купленные готовые продукты (out-of-the-box/off-the-shelf), охватывающие все бизнес-процессы внутри компании.
Существующая проблема
При всей ее инновационности и технологичности, в компании весьма посредственно развит подход к управлению риском, присущим ИТ, и, как следствие, отсутствует эффективный контроль над ИТ, что в свою очередь часто приводит к различным проблемам и инцидентам, например:
• ошибки в отчетах или в работе систем;
• некорректный доступ пользователей;
• утечки персональных данных;
• недоступность систем;
• недостаточная производительность систем.
Все это в свою очередь снижает эффективность процессов компании, лояльность клиентов, вызывает недовольство у регуляторных органов. Репутация компании страдает, а стратегические цели потенциально могут быть не достигнуты, компания несет незапланированные операционные и финансовые издержки.
При этом владельцы автоматизированных систем и сервисов видят главной целью их быстрое развитие, любые посторонние процессы и контроль над ИТ воспринимаются негативно и, по их мнению, вредят, снижают эффективность разработки новых «фичей», замедляют скорость реализации и эволюции технологических решений, проще говоря — тормозит ⠀развитие ⠀систем ⠀и ⠀сервисов, ⠀«убивает дух стартапа».
Перед менеджментом стоят задачи:
• определить наилучшую стратегию, позволяющую охватить всю совокупность технологических решений, используемых компанией, и убедиться, что в представленной ИТ-среде есть эффективный процесс управления ИТ-рисками, а также действенный контроль над ИТ (в данном контексте слово «контроль» означает «контроль целого, общего», не путайте с термином «контрольная процедура»);
• определить ключевой набор контрольных процедур, которые должны быть внедрены для каждой автоматизированной системы;
• определить методику, инструменты и объекты для оценки эффективности контрольных процедур над ИТ;
• и самое главное: наилучшим образом объяснить владельцам автоматизированных систем и сервисов важность внедрения процессов управления ИТ-рисками, контроля над ИТ и тем самым убедить, а главное, мотивировать их использовать при развитии автоматизированных систем и сервисов методы управления рисками и контроля над ИТ.
С чего можно было бы начать?
Какой могла бы быть наилучшая стратегия, позволяющая менеджменту охватить весь спектр используемых компанией технологий и убедиться, что в представленной среде есть эффективный процесс управления рисками, присущими ИТ, а также эффективный контроль над ИТ?
Учитывая разнообразный характер используемых технологий, на пути достижения целей компании и ИТ потенциально могут возникнуть различные риски, присущие информационным технологиям. Чтобы более эффективно спланировать развитие систем и сервисов, необходимо понимать эти риски.
Риски, присущие ИТ, могут приводить к реализации рисков ИБ.
Шаг 1. Понять связь между бизнес-процессами и ИТ-средой — используемыми в компании информационными технологиями
Пример: Финансы (бухгалтерский учет) обычно используют набор ИТ-систем и инструментов, автоматизирующих различные процессы, подпроцессы и процедуры, ведения бухгалтерского учета и управления финансами компании.
Таким образом, зная, какие инструменты и системы использует бухгалтерия, финансы, какие данные куда, для чего и с помощью чего передаются, можно определить связь и зависимость бизнес-процессов и ИТ-системы (например, системы бухгалтерского учета).
Далее можно попытаться предположить, что может пойти не так, если данные ИТ-системы не будут функционировать так, как ожидалось заинтересованными потребителями и поставщиками информации.
Очевидно, существует некая вероятность, что цели бизнес-процессов могут быть не достигнуты, достигнуты частично либо достигнуты несвоевременно, например, в силу причин, подобных следующим:
• сформированные отчеты не полные и/или не точные;
• данные повреждены или недоступны;
• расчеты ошибочны;
• некоторые интерфейсы с другими системами теряют данные;
• производительность системы низкая;
• ошибки в разработанном ПО либо задержки в его разработке.
Таким образом, в результате подобных событий компания может быть подвержена различным рискам, которые могут помешать ей достичь своих целей. В данном случае, например, таким, как «Достоверность финансовой отчетности» и «Соответствие регуляторным требованиям», которые могут быть не достигнуты или достигнуты частично с финансовыми и/или репутационными издержками.
Понимая связь ИТ–систем, автоматизированных сервисов и процессов бизнеса, можно сформировать перечень используемых технологий, оценить степень их критичности для бизнеса, подверженность таких технологий рискам ИТ и определить уровень необходимого контроля над данными технологиями.
Шаг 2. Понять критичность ИТ-систем и присущие риски
Очевидно, Шаг 1 может дать очень большой перечень систем, технологий, автоматизированных сервисов и т. д. Но все ли они важны и критичны для бизнеса компании? Если да, то какова степень критичности систем и их элементов?
Исходя из критичности каждой ИТ-системы, менеджмент, владельцы систем и сервисов должны понимать риски, которыми обладает каждая уникальная ИТ-система или автоматизированный сервис.
В связи с большим количеством ИТ-систем в нашем случае (более 70) и учитывая сложность и высокий уровень интеграции с бизнес-процессами, менеджмент компании также должен понимать взаимную зависимость и критичность каждой ИТ-системы, сервиса, чтобы расставить приоритеты по внедрению контроля над ИТ.
То есть, проделав подобный анализ, на выходе мы получаем список систем и их критичность, определяющую приоритетность наших дальнейших действий.
ВАЖНО: необходимо принимать во внимание, что ИТ-система или автоматизированный сервис — это комплекс, который может состоять из различных интегрированных подсистем, например, прикладное ПО + ОС + СУБД + сеть + интерфейсы + промежуточное ПО и т. д.
Каждая система или автоматизированный сервис могут быть по-своему уникальными, и это важно учитывать при анализе совокупности присущих подобной системе или сервису рисков, определении критичности, расстановке приоритетов и внедрении контроля над ИТ. Например, различные риски могут быть присущи категории ИТ-систем в целом либо быть специфичными и присущи исключительно для отдельной, уникальной системы или автоматизированного сервиса.
Шаг 3. Определить набор контрольных процедур в области ИТ применительно к типам/вариантам/категориям ИТ-систем и автоматизированных сервисов
Когда специфика и критичность систем определена, а риски, присущие ИТ, понятны, компании необходимо внедрить общий контроль над всей ИТ-средой. Контроль, представляющий из себя набор мероприятий, действий, политик и процедур, направленных на снижение рисков, присущих как ИТ в целом, так и системам и автоматизированным сервисам в отдельности.
Понимая специфику технологий, а также присущие данным технологиям риски, мы можем уйти на уровень ниже и разработать так называемые процедуры контроля (контрольные процедуры, меры по снижению рисков), описанные в политиках и иных процедурных документах, базовых требованиях к ИТ-системам.
В данном случае при разработке таких документов и контрольных процедур можно воспользоваться одной из лучших практик описания — «5W», исследуя «Кто», «Что», «Где», «Когда» и «Почему».
Данные документы должны формализовать непосредственно процедуры контроля над ИТ, то есть могут описывать:
1. Кто делает?
2. Что делает?
3. Как часто делает?
4. Каков результат?
5. Зачем и какова цель?
То есть, используя «5W», компания может более точно разработать необходимые документы, включая политики и процедуры, тем самым привнеся эффективность исполнения контроля над ИТ и усилив эффективность процесса управления риском ИТ.
Описанные и внедряемые контрольные процедуры могут быть как общего характера (General IT Controls), так и более специфичными, характерными для отдельной системы или автоматизированного сервиса/процесса. Более подробно о контрольных процедурах мы поговорим ниже.
Внедрение контроля над ИТ должно применяться в первую очередь к наиболее важным ИТ-системам, а затем к системам и сервисам с более низким приоритетом/критичностью для достижения целей организации.
Например, в зависимости от сложности и критичности ИТ-системы, может требоваться меньшее количество контрольных процедур (сравните важность и критичность для бизнеса таких систем, как SAP ERP и BMC Remedy), первая — это ERP система, большинство бизнес-процессов организации могут зависеть от ERP системы, в противовес системе управления услугами, автоматизирующей процесс ITIL, поддерживающей различные формы заявок на обслуживание и запросов пользователей.
Следует обратить внимание, что при разработке и внедрении контроля над ИТ необходимо учитывать все уровни ИТ, включая само прикладное ПО, ОС, СУБД, сеть и т. д.
Шаг 4. Определить «правила» для ИТ, в частности, политики, процедуры, базовые требования к системам и автоматизированным сервисам
Как уже было сказано выше, разрабатываемые контрольные процедуры необходимо оформить документально с целью фиксации обязательности и точности их исполнения.
В рамках ИТ-процессов компания должна разработать и применять политики, процедуры, базовые требования и т. д., которые могли бы устанавливать правила выполнения процедур и контроля, направленные на снижение рисков, присущих ИТ-системам и автоматизированным сервисам.
Вот пример, что может пойти не так и что можно сделать, чтобы избежать негативных последствий:
Бесплатный фрагмент закончился.
Купите книгу, чтобы продолжить чтение.