Новые требования распространяются на 4 компонента:
- уровень обмена данными
- локальную инфраструктуру SWIFT заказчика
- пользовательские ПК
- пользователей.
Соединение с SWIFT, ИТ-инфраструктура и бэкофис заказчика в область действия SWIFT CSF не попадают:
При этом, что мне понравилось и чего не хватает в отечественных документах, в визуальной форме показаны типы архитектур, покрываемых требованиями, что облегчает восприятие и реализацию документа. Таких архитектур выделено 4 — от максимально возможной (архитектура А1 — полный стек технологий SWIFT) до минималистичной (архитектура B — отсутствие на стороне заказчика локальной SWIFT-инфраструктуры и наличие только пользователей и их ПК).
Для каждой из 4-х архитектур описаны требования по безопасности, которые, как я уже написал выше, делятся на обязательные и рекомендательные. Документ получился достаточно объемным — 52 страницы, содержание которого показано ниже. Приставка A после номера требования (например, 7.3А — пентесты, 6.5А — обнаружение атак, 2.7А — сканирование уязвимостей) означает рекомендательность требования (от слова «Advisory»).
Описание требований лаконичное, но предельно понятное — никакого растекания мыслью по древу. Вот пример описания защитной меры «защита данных при передаче за пределы контролируемой зоны».
Несмотря на объем, все требования нового документа можно увязать с всего тремя целями:
- защити свое окружение
- знай и ограничь доступ
- обнаруживай и реагируй.
Во втором квартале 2017-го года заказчики SWIFT начнут сообщать в SWIFT о своем соответствии данным требованиям (в обязательной их части), а с января 2018-го года это станет обязательной нормой — все заказчики должны будут проводить собственную оценку соответствия (SWIFT называет это знакомым словом «аттестация») и направлять ее результаты на ежегодной основе. Дополнительно SWIFT планирует случайным образом ежегодно выбирать некоторых заказчиков для проведения более глубокого их аудита внутренними или внешними аудиторами. Данное требование напоминает шаги нашего Банка России, который требует отправлять результаты оценки соответствия 202-й формы, а при необходимости проводит дополнительные надзорные мероприятия в отношении выбранных банков.
Статус соответствия требованиям будет размещаться в публичном реестре (SWIFT KYC Registry), чтобы каждый смог убедиться в надежности своих партнеров и контрагентов. По сути, это идея, которую не довел до финального завершения Банк России, который собирал результаты оценки соответствия СТО БР ИББС и хотел их публиковать на сайте. Сейчас же все ограничилось тем, что ЦБ публикует список тех, кто присоединился к СТО, без указания их уровня соответствия. Я не знаю, насколько это повышает стимулирует заказчиков выбирать более защищенные финансовые организации, но инициатива SWIFT интересная — посмотрим, что из нее получится.
Могу отметить, что документ не содержит каких-то новых требований, неизвестных заказчикам SWIFT, и ранее им невстречавшихся в других нормативных документах (том же PCI DSS или NIST CSF). Поэтому для облегчения внедрения SWIFT Customer Security Framework в конце документа содержит таблицу соответствия своих требований наиболее известным лучшим мировым практикам:
Получить данный документ может любой заказчик SWIFT — он выложен на официальном сайте, в разделе для зарегистрированных пользователей.
