Что в сфере информационной безопасности принято считать риском

Анализ угроз информационной безопасности

Защита данных
на базе системы

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

Понятие и источники рисков

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

В процессе анализа угроз информации необходимо оценить:

Анализировать позиции можно качественными и количественными методами.

Источники

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

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

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

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

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

К внутренним относятся:

Для контроля событий в программных и аппаратных источниках удобно использовать SIEM-систему. «СёрчИнформ SIEM» обрабатывает поток событий, выявляет угрозы и собирает результаты в едином интерфейсе, что ускоряет внутренние расследования.

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

Зона риска

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

Классическими «жертвами» злоумышленников становятся признаки доброкачественности информации:

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

При анализе зон риска нужно также принимать во внимание:

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

Классификация нарушителей

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

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

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

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

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

ФСБ классифицирует нарушителей информационной безопасности по возможностям и степени нарастания угроз:

1. Атаки на данные могут проводиться только вне зоны криптозащиты.

2. Атаки организовываются без физического доступа к средствам вычислительной техники (СВТ), но в пределах зоны криптозащиты, например, при передаче данных по каналам связи.

3. Атаки реализуются при доступе к СВТ и в зоне работы криптозащиты.

4. Нарушители обладают перечисленными возможностями и могут прибегать к помощи экспертов, имеющих опыт в области анализа сигналов линейной передачи и ПЭМИН (побочных электромагнитных излучений и наводок).

5. Нарушители также могут привлечь специалистов, способных находить и использовать незадекларированные возможности (НДВ) прикладного ПО.

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

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

Целесообразно опираться на статистику, показывающую вероятность реализации того или иного риска.

Анализ вероятности реализации угрозы и ущерба от ее возникновения

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

Количественные методы анализа помогут в ситуации, когда нужно определить:

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

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

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

Проверить, все ли в порядке с защитой данных в компании, можно во время 30-дневного бесплатного теста «СёрчИнформ КИБ».

Источник

Что в сфере информационной безопасности принято считать риском

Об актуальных изменениях в КС узнаете, став участником программы, разработанной совместно с АО «Сбербанк-АСТ». Слушателям, успешно освоившим программу выдаются удостоверения установленного образца.

Программа разработана совместно с АО «Сбербанк-АСТ». Слушателям, успешно освоившим программу, выдаются удостоверения установленного образца.

Обзор документа

Разъяснения Банка России от 30 сентября 2021 г. N 716-Р-2021/44 “Разъяснения по управлению риском информационной безопасности и риском информационных систем”

Кредитная организация в соответствии с пунктом 6.9 Положения N 716-П вправе вести учет событий риска ИБ и риска ИС как в составе базе событий операционного риска (консолидировано), так и раздельно. В случае если кредитная организация ведет отдельные базы событий по риску ИБ и риску ИС, в данной кредитной организации должен быть разработан порядок интеграции информации, содержащейся в вышеуказанных базах событий, с базой событий операционного риска. В том числе кредитной организацией во внутренних документах должно быть определено следующее:

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

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

сроки и формат передачи данных о событиях риска ИБ и риска ИС в целях регистрации в базе событий операционного риска, с учетом требований пункта 6.10 Положения N 716-П.

В силу специфики процедур управления риском информационной безопасности Банк России рекомендует обратить особое внимание на подходы к дополнительной классификации риска информационной безопасности, указанные в приложении 5 к Положению N 716-П, в разрезе типов событий, категорий источников операционного риска, направлений деятельности, в том числе в разрезе составляющих их процессов. Также в соответствии с приложением 5 к Положению N 716-П кредитная организация обязана использовать дополнительные (специфические) виды прямых и непрямых потерь от реализации риска информационной безопасности для классификации событий риска информационной безопасности в дополнение к установленным в пункте 3.11 Положения N 716-П. Кроме того, дополнительная классификация событий риска ИБ, указанная в приложении 5 Положения N 716-П, не заменяет основную классификацию событий операционного риска, указанную в главе 3 Положения N 716-П. Событие риска ИБ сначала должно быть классифицировано в соответствии с требованиями главы 3 Положения 716-П, в том числе по типам событий операционного риска, перечисленным в пункте 3.6 Положения 716-П, и уже в разрезе элементов классификации дополнительно классифицировано, в соответствии с приложением 5 к Положению N 716-П.

Обращаем внимание, что в случае если для кредитной организации (исходя из вида лицензии и масштаба деятельности) в соответствии с требованиями главы 9 Положения N 716-П процедура регистрации в базе событий операционного риска (в том числе риска ИБ и риска ИС), по которым отсутствуют прямые и непрямые потери, носит рекомендательный характер. Банк России рекомендует кредитной организации как для внутренних целей (например, определений КИР), так и для целей соблюдения иных нормативных актов Банка России самостоятельно определить необходимость регистрации событий операционного риска по отдельным видам операционного риска (например, событий риска информационной безопасности) и (или) типам событий, и (или) отдельным процессам, которые были предотвращены и которые не привели как к прямым, так и непрямым потерям.

При разработке и утверждении перечня контрольных показателей уровня операционного риска в соответствии с требованиями главы 5 Положения N 716-П необходимо учитывать, что данный перечень должен содержать контрольные показатели уровня риска ИБ, указанные в пункте 1.2 приложения 1 к Положению N 716-П. В соответствии с абзацем седьмым подпункта 7.9.2 пункта 7.9 Положения N 716-П служба информационной безопасности обязана осуществлять мониторинг сигнальных и контрольных значений контрольных показателей уровня риска ИБ. Рекомендуем кредитной организации обеспечить организацию информационного обмена между соответствующими подразделениями кредитной организации и информационными системами в целях передачи службой информационной безопасности результатов мониторинга текущих (то есть фактических на расчетную дату), сигнальных и контрольных значений контрольных показателей уровня риска ИБ в службу управления рисками для формирования внутренних отчетов по управлению операционным риском в соответствии с пунктом 4.2 Положения Банка России N 416-П.

Обращаем внимание, что требования пункта 4.2 Положения N 716-П к формированию отчетов по операционному риску распространяются также на отчеты по риску ИБ и риску ИС, в том числе:

требование о необходимости ежедневной передачи информации о крупных событиях риск ИБ и риска ИС в службу управления рисками кредитной организации, в соответствии с подпунктом 4.2.1 пункта 4.2 Положения N 716-П;

требования к формированию ежеквартальных и ежегодных отчетов в соответствии с подпунктами 4.2.2 и 4.2.3 пункта 4.2 Положения N 716-П.

Обзор документа

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

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

— как быть, если для кредитной организации процедура регистрации в базе событий операционного риска (в том числе риска ИБ и риска ИС) носит рекомендательный характер;

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

— какие требования распространяются на отчеты по риску ИБ и риску ИС.

Источник

Управление рисками для ИБ и ИС: разбор требований Банка России

1 октября вступило в силу Положение ЦБ РФ № 716-П «О требованиях к системе управления операционным риском в кредитной организации и банковской группе». Документ вызывает немало вопросов и споров в профессиональном сообществе. Мы поделились своим видением подходов к выполнению требований регулятора и подготовили краткую инструкцию, которая поможет разобраться в управлении операционным риском в целом и рисками для информационной безопасности (ИБ) / информационных систем (ИС) в частности.

Введение

Положение ЦБ РФ № 716-П (далее — «Положение») распространяется на банки и небанковские кредитные организации: депозитарии, страховые и лизинговые компании, платёжные системы и системы денежных переводов, клиринговые организации. В нём описаны требования к порядку управления операционным риском, классификатору рисковых событий, порядку ведения базы этих событий, контрольным показателям уровня риска и их расчёту, к управлению риском для ИБ и ИС и т. д. Все эти требования необходимо закрыть к 1 января 2022 года, и пока вопросов о том, как это сделать, больше, чем ответов.

Специалисты компании «Инфосистемы Джет» обладают богатым экспертным опытом в областях банковского комплаенса (соответствия нормативным и законодательным требованиям. — Прим. ред.), построения систем управления информационной безопасностью и непрерывностью бизнеса, проведения оценки рисков. Поэтому имеется возможность предварительно ответить на некоторые из этих вопросов. Мы разобрались в терминологии, структурировали основные требования и перевели их на понятный для специалистов по ИБ и ИТ язык.

Построение системы управления в соответствии с требованиями регулятора

Само по себе понятие «система управления» не ново и описано в международном стандарте ISO 9000:2015. Напомним: это совокупность взаимосвязанных и взаимодействующих элементов организации, предназначенная для установления политики и целей, а также процессов для достижения этих целей. Проще говоря — подход к управлению, определённые процедуры и выполняющие их люди.

В основе построения всех подобных систем лежит модель PDCA: Plan — Do — Check — Act (Планируйте — Делайте — Проверяйте — Действуйте. — Прим. ред.). На стадии «Plan» необходимо задокументировать процессы и выделить для них ресурсы. Следующая стадия предполагает выполнение процессов в соответствии с документацией. На стадии «Check» следует проводить регулярные проверки этих процессов и оценивать эффективность работы системы управления. Стадия «Act» предполагает постоянное улучшение системы.

Система управления операционным риском, о которой говорится в Положении, функционирует именно по этой модели.

Стадия «Plan»: планирование

На этой стадии мы рекомендуем задокументировать следующие процессы:

Порядок управления риском описан в международном стандарте ISO 31000:2018.

Рисунок 1. Процесс управления риском согласно ISO 31000:2018

В этом смысле Положение солидарно с международным стандартом.

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

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

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

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

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

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

Стадия «Plan»: организация процесса управления риском

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

Рисунок 2. Схема взаимодействия участников процесса управления риском

Примечание: ДЛ — должностное лицо, ДИТ — департамент ИТ, ОР — операционный риск, ВА — внутренний аудит, КО — кредитная организация.

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

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

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

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

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

Стадия «Plan»: классификация событий риска

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

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

Положение также описывает основные типы событий операционных рисков:

нарушение организации и исполнения процессов, управления ими.

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

Стадия «Do»: формирование базы и оценка рисков

На этой стадии организация начинает формировать свою базу событий рисков для ИБ. Она может быть как одной для всей организации, так и распределённой, для каждого подразделения. Базу событий можно вести в удобном для вас формате — SGRC-решения, XLS-файлы или самописные системы: для автоматизации процесса стоит использовать автоматизированную информационную систему.

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

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

О том, как проводить самооценку, не сказано практически ничего, кроме того, что необходимо выделить четыре уровня риска: «очень высокий», «высокий», «средний» и «низкий», принимая в расчёт вероятность реализации риска и возможных последствий. В Положении не сказано, каким подходом при этом руководствоваться и какой методике следовать. Требования к отчётности по результатам оценки тоже отсутствуют, говорится только, что её необходимо предоставлять коллегиальному исполнительному органу.

Это значит, что вы можете самостоятельно выбирать методику расчёта, подходящую к реалиям бизнеса. Мы рекомендуем ориентироваться на международные стандарты ISO 31000:2018 и IEC 31010:2019.

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

Стадия «Check»: мониторинг риска и оценка эффективности системы управления риском

Если вы не хотите допустить риски, вам необходимо их постоянно отслеживать. Положение предлагает несколько способов:

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

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

Если взять рисковый сценарий, а именно тройку «причина риска — рисковое событие — его возможные последствия», то КИР будет показателем, который «вешается» на каждую возможную причину возникновения рискового события для его предотвращения. Например, это может быть количество попыток ввода пароля или время недоступности информационной системы.

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

Например, вам нужно проверить «полноту информации, отражённой в базе событий». Вы открываете базу событий и проверяете заполнение необходимых полей, например, за прошедший месяц. В идеале, предположим, должно быть заполнено 90 % полей от общего количества, но не менее 70 %. Таким образом, 90 % — целевое значение, 70 % — пороговое. Если фактический показатель меньше установленного порогового значения, то, значит, полнота информации в базе «хромает», а это может негативно сказаться на эффективности системы управления риском. Чтобы этого не произошло, следует выяснить, почему не все поля базы заполняются.

Ещё один возможный способ оценки эффективности, помимо введения метрик, — независимые аудиты.

Стадия «Act»: постоянное улучшение системы

Стадия «Act» модели PDCA подразумевает постоянное повышение качества системы управления рисками. Регулятор предлагает улучшать систему управления с помощью мероприятий, направленных на предотвращение и снижение вероятности событий риска, а также на ограничение размера потерь от реализации риска.

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

Система ИБ: что это такое и нужно ли бояться новой сущности

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

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

Особые требования по управлению риском для информационных систем

Этой теме в Положении посвятили целую главу (№ 8), поэтому на ней мы остановимся отдельно. Под «риском информационных систем» в документе понимают риск отказов и нарушения функционирования применяемых кредитной организацией информационных систем или несоответствия их функциональных возможностей и характеристик потребностям кредитной организации.

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

Рисунок 3. Управление риском для ИС

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

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

Выводы

В новом документе неизбежно будут содержаться лакуны или зоны неоднозначной трактовки. Мы выбрали и описали ключевые из таких неопределённостей Положения ЦБ РФ № 716-П. Но этот список — неполный, наверняка при желании вы сможете его продолжить.

Неопределённость № 1: область применения системы управления риском. Система не может существовать сама по себе, она всегда имеет какую-то область применения. Мы рекомендуем начинать с критически важных для бизнеса процессов организации — в первую очередь тех, что связаны с финансовыми операциями.

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

Неопределённость № 3: автоматизация системы управления риском. В Положении говорится об этом, но возникает вопрос: обязательна ли автоматизация системы? Мы считаем, что нет. У разных организаций — разный масштаб, по-разному выстроены процессы, разный уровень зрелости и неодинаковые финансовые возможности. Исходите из своих бизнес-приоритетов и принципа экономической целесообразности.

Неопределённость № 4: как вести базы событий риска? Каждая служба (ИТ, ИБ, управления рисками) может вести свою собственную базу. Однако мы рекомендуем собирать все события в единую базу.

Неопределённость № 5: ключевые индикаторы и контрольные показатели уровня риска. Здесь мы можем видеть терминологические нестыковки Положения, поскольку по сути своей это — одно и то же. Не пугайтесь разных терминов в разных главах документа.

Неопределённость № 6: принципы оценки риска. Как мы уже говорили, эти принципы не определены, поэтому каждая организация может выбирать свой подход к оценке.

Выполнение требований Положения ЦБ РФ № 716-П — настолько обширная тема, что мы посвятили ей отдельный вебинар. Предлагаем его посмотреть, если у вас всё ещё остались вопросы: в нём мы постарались прояснить все нюансы, о которых чаще всего спрашивают клиенты.

Авторы:

Татьяна Страмоус, эксперт Центра информационной безопасности «Инфосистемы Джет».

Ирина Павлова, старший консультант Центра информационной безопасности «Инфосистемы Джет».

Григорий Артемов, консультант по непрерывности «Инфосистемы Джет».

Источник