Идентификация рисков третьих лиц в финансовой организации

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

Рекомендации по управлению рисками третьих лиц в части аутсорсинга Банк России выпустил еще в 2018 году (РС БР ИББС 1.4-2018), дополнив в рамках положений о требованиях к операционной надежности (№787-П от 12.01.2022 и 779-П от 15.11.2021). К сожалению, все эти документы формировались в иных условиях. Мало кто предполагал, что многолетние партнерские отношения могут быть расторгнуты в одностороннем порядке без соблюдения условий, предполагающих серьезные финансовые последствия за нарушение.

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

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

1. Проведите инвентаризацию всех действующих договоров и соглашений. Не ограничивайте выборку договорами ИТ и ИБ. Может оказаться, что от действий подрядчика, договор с которым, например, курирует АХО или маркетинг, может зависеть качество и непрерывность основных бизнес-процессов. Примеров тому масса: хостинг сайта, услуги колл-центра, поставка электроэнергии, обслуживание кондиционеров, аренда помещений и т.д.
2. Актуализируйте реестр на основе информации от бизнес-владельцев и дополните его данными из лицензионных соглашений, в том числе свободно распространяемого ПО.
3. Дополните реестр информацией о критичной архитектуре, собранной в рамках приведения в соответствие Положению Банка России от 12 января 2022 года №787-П «Об обязательных для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг».

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

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

• Связанные с предоставлением информации компании (котировки, индикаторы, аналитические данные, сигнатуры, стоп-листы, сведения о банкротстве, залоги и иные)
• Связанные с предоставлением вычислительных ресурсов и сервисов, поставкой и поддержкой оборудования и ПО, арендой помещений и сопутствующих услуг.
• Связанные с получением информации от компании. Сюда можно отнести договоры с:
  1. платежными системами, платежными агентами, операторами услуг информационного обмена, операторами электронных платформ и иными организациями, неполный или несвоевременный обмен данных с которыми может привести к деградации или невозможности выполнения бизнес-процессов;
  2. различными регуляторами (ЦБ, Росфинмониторинг, таможня, налоговые органы, ФССП и иные), неполный или несвоевременный обмен данных с которыми может привести к нарушениям лицензионных требований и соответствующим последствиям.

С точки зрения предмета договора риски также могут различаться.

• Для договоров на поставку оборудования, лицензионных соглашений и соглашений об услугах технической поддержки по возможности проверяйте всю цепочку поставщиков.
• Для договоров на поставку оборудования включите информацию о логистической компании.
• Для программного обеспечения учтите, если это возможно, не только сведения о конечном лицензиате, сублицензиатах, дистрибьюторах и реселлерах, но и правообладателях отдельных компонентов (встроенных библиотек, драйверов и даже утвержденных в вашей компании официальных шрифтов).
• Для средств защиты информации стоит отдельно упомянуть о поставщиках сигнатур, решающих правил, TI-фидов и т.п. Помните, что для корректной работы средств криптографической защиты необходимо взаимодействие со всеми промежуточными центрами сертификации, которые указаны в сертификате ключа проверки электронной подписи, а также поставщиками серверов штампа времени.
• Для услуг технической поддержки проработать вопрос дистанционного подключения или возможности выезда подрядчика.
• Отдельно проработайте сведения о договорах, связанных с арендой оборудования и вычислительных мощностей. Дополните информацией о поставщиках IP-адресов, DNS-сервисах, применяемых внешних NTP.
• При анализе договоров с операторами связи включите информацию о магистральных операторах, на базе которых они функционируют.

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

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

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

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

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

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

Автор: Алена Игнатьева, старший консультант по консалтингу и аудиту информационной безопасности STEP LOGIC