Новые требования по безопасности SWIFT
Новые требования распространяются на 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 планирует случайным образом ежегодно выбирать некоторых заказчиков для проведения более глубокого их аудита внутренними или внешними аудиторами.
Статус соответствия требованиям будет размещаться в публичном реестре (SWIFT KYC Registry), чтобы каждый смог убедиться в надежности своих партнеров и контрагентов. Я не знаю, насколько это стимулирует заказчиков выбирать более защищенные финансовые организации, но инициатива SWIFT интересная - посмотрим, что из нее получится.
Могу отметить, что документ не содержит каких-то новых требований, неизвестных заказчикам SWIFT, и ранее им невстречавшихся в других нормативных документах (том же PCI DSS или NIST CSF). Поэтому для облегчения внедрения SWIFT Customer Security Framework в конце документа содержит таблицу соответствия своих требований наиболее известным лучшим мировым практикам:
Получить данный документ может любой заказчик SWIFT - он выложен на официальном сайте, в разделе для зарегистрированных пользователей.
Публикуется с разрешения автора.