SWIFT Customer Security Controls Framework v2022

КЗИ.12 Регистрация сбоев (отказов) технических мер защиты информации
3-Н 2-Т 1-Т

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

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

Рекомендуется обеспечить хранение данных о действиях и операциях не менее трех лет, а для данных, полученных в результате выполнения банковского платежного технологического процесса, - не менее пяти лет, если иные сроки хранения не установлены законодательством РФ, нормативными актами Банка России.
Для проведения процедур мониторинга ИБ и анализа данных о действиях и операциях следует использовать специализированные программные и (или) технические средства.
Процедуры мониторинга ИБ и анализа данных о действиях и операциях должны использовать зафиксированные критерии выявления неправомерных или подозрительных действий и операций. Указанные процедуры мониторинга ИБ и анализа должны применяться на регулярной основе, например ежедневно, ко всем выполненным действиям и операциям (транзакциям).

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

МАС.5 Организация мониторинга данных регистрации о событиях защиты информации, формируемых АС и приложениями
3-Т 2-Т 1-Т

РИ.1 Регистрация информации о событиях защиты информации, потенциально связанных с инцидентами защиты информации, в том числе НСД, выявленными в рамках мониторинга и анализа событий защиты информации
3-О 2-Т 1-Т

МАС.6 Организация мониторинга данных регистрации о событиях защиты информации, формируемых контроллерами доменов
3-Т 2-Т 1-Т

УЗП.28 Регистрация событий защиты информации, связанных с действиями, и контроль действий эксплуатационного персонала, обладающего правами по управлению криптографическими ключами
3-Т 2-Т 1-Т

МАС.4 Организация мониторинга данных регистрации о событиях защиты информации, формируемых системным ПО, операционными системами, СУБД
3-Н 2-Т 1-Т

PR.PT-1: В соответствии с политикой определяются, документируются, внедряются и проверяются записи аудита / журналов событий 

DE.AE-2: Обнаруженные события анализируются для определения целей и методов атаки 

RS.AN-1: Исследуются уведомления от систем обнаружения 

DE.CM-1: Сеть контролируется для обнаружения потенциальных событий кибербезопасности 

ВРВ.3 Организация сбора и фиксации технических данных (свидетельств)** о выявленных событиях реализации информационных угроз в рамках процессов защиты информации, реализуемых в соответствии с ГОСТ Р 57580.1., в целях проведения их последующего анализа, а также, в случае необходимости, проведения компьютерной экспертизы.

ВРВ.1 Организация мониторинга и выявления событий реализации информационных угроз в рамках процессов, реализуемых в соответствии с требованиями ГОСТ Р 57580.1., в целях своевременного обнаружения:

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

6.3.2. Информационная инфраструктура организации БС РФ (в настоящем стандарте предполагается, что сбор технических данных реализуется при наличии технической возможности с использованием функциональных возможностей объектов информационной инфраструктуры, эксплуатация которых осуществляется или организована организацией БС РФ): 

10.4.1
Defined Approach Requirements: 
The following audit logs are reviewed at least once daily:

Customized Approach Objective:
Potentially suspicious or anomalous activities are quickly identified to minimize impact. 

Defined Approach Testing Procedures:

Purpose:
Many breaches occur months before being detected. Regular log reviews mean incidents can be quickly identified and proactively addressed. 

Good Practice:
Checking logs daily (7 days a week, 365 days a year, including holidays) minimizes the amount of time and exposure of a potential breach. Log harvesting, parsing, and alerting tools, centralized log management systems, event log analyzers, and security information and event management (SIEM) solutions are examples of automated tools that can be used to meet this requirement. 
Daily review of security events—for example, notifications or alerts that identify suspicious or anomalous activities—as well as logs from critical system components, and logs from systems that perform security functions, such as firewalls, IDS/IPS, file integrity monitoring (FIM) systems, etc., is necessary to identify potential issues. 
The determination of “security event” will vary for each organization and may include consideration for the type of technology, location, and function of the device. Organizations may also wish to maintain a baseline of “normal” traffic to help identify anomalous behavior. 
An entity that uses third-party service providers to perform log review services is responsible to provide context about the entity’s environment to the service providers, so it understands the entity’s environment, has a baseline of “normal” traffic for the entity, and can detect potential security issues and provide accurate exceptions and anomaly notifications. 

10.2.1
Defined Approach Requirements: 
Audit logs are enabled and active for all system components and cardholder data. 

Customized Approach Objective:
Records of all activities affecting system components and cardholder data are captured. 

Defined Approach Testing Procedures:

Purpose:
Audit logs must exist for all system components. Audit logs send alerts the system administrator, provides data to other monitoring mechanisms, such as intrusion-detection systems (IDS) and security information and event monitoring systems (SIEM) tools, and provide a history trail for post-incident investigation. 
Logging and analyzing security-relevant events enable an organization to identify and trace potentially malicious activities. 

Good Practice:
When an entity considers which information to record in their logs, it is important to remember that information stored in audit logs is sensitive and should be protected per requirements in this standard. Care should be taken to only store essential information in the audit logs to minimize risk.

/STRENGTHENED 
As soon as possible, the logging linked to accounts (e.g.: list of successful/ failed connections) must be activated. 

/STANDARD
Having relevant logs is required in order to be able to detect possible malfunctions and illegal access attempts to the components of the information system. 

The first stage consists of determining what the critical components of the information system are. These may be network and security devices, critical servers, sensitive user workstations, etc. 

For each of these, it is advisable to analyse the configuration of logged elements (format, frequency of file rotation, maximum size of log files, event categories recorded, etc.) and to adapt it as a consequence. The critical events for security must be logged and saved for at least one year (or more, depending on the legal requirements of the business area). 

A contextual assessment of the information system must be carried out and the following elements must be logged:

In order to be able to correlate the events between the different components, their time synchronisation source (thanks to NTP protocol) must be identical. 

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

16.1. Участник СБП - банк плательщика должен осуществлять:

16.3. ОПКЦ СБП должен осуществлять:

Процедура принятия решения о наличии признаков осуществления перевода денежных средств без согласия клиента участником СБП на основании индикатора уровня риска операции, поступившего в электронном сообщении от участника СБП, ОПКЦ СБП при осуществлении операции по переводу денежных средств с использованием сервиса быстрых платежей, устанавливается участником СБП в рамках реализуемой им системы управления рисками в соответствии с частью 5.1 статьи 8 Федерального закона от 27 июня 2011 года N 161-ФЗ.

10.2.1
Определенные Требования к Подходу:
Журналы аудита включены и активны для всех компонентов системы и данных о держателях карт.

Цель Индивидуального подхода:
Фиксируются записи всех действий, влияющих на компоненты системы, и данные о держателях карт.

Определенные Процедуры Тестирования Подхода:

Цель:
Журналы аудита должны существовать для всех компонентов системы. Журналы аудита отправляют предупреждения системному администратору, предоставляют данные другим механизмам мониторинга, таким как системы обнаружения вторжений (IDS) и средства защиты информации и систем мониторинга событий (SIEM), а также обеспечивают отслеживание истории для расследования после инцидента.
Ведение журнала и анализ событий, связанных с безопасностью, позволяют организации выявлять и отслеживать потенциально вредоносные действия.

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

10.4.1
Определенные Требования к Подходу:
Следующие журналы аудита просматриваются не реже одного раза в день:

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

Определенные Процедуры Тестирования Подхода:

Цель:
Многие нарушения происходят за месяцы до их обнаружения. Регулярные проверки журналов позволяют быстро выявлять инциденты и оперативно устранять их.

Надлежащая практика:
Ежедневная проверка журналов (7 дней в неделю, 365 дней в году, включая праздничные дни) сводит к минимуму количество времени и вероятность потенциального нарушения. Средства сбора, анализа и оповещения журналов, централизованные системы управления журналами, анализаторы журналов событий и решения для управления информацией о безопасности и событиями (SIEM) являются примерами автоматизированных инструментов, которые можно использовать для удовлетворения этого требования.
Ежедневный просмотр событий безопасности — например, уведомлений или предупреждений, которые идентифицируют подозрительные или аномальные действия, — а также журналов критически важных системных компонентов и журналов систем, выполняющих функции безопасности, таких как брандмауэры, идентификаторы/IP-адреса, системы мониторинга целостности файлов (FIM) и т.д., необходим для выявления потенциальные проблемы.
Определение “события безопасности” будет отличаться для каждой организации и может включать в себя рассмотрение типа технологии, местоположения и функции устройства. Организации могут также пожелать поддерживать базовый уровень “нормального” трафика, чтобы помочь выявить аномальное поведение.
Объект, который использует сторонних поставщиков услуг для выполнения служб просмотра журналов, отвечает за предоставление поставщикам услуг контекста среды объекта, чтобы он понимал среду объекта, имел базовый уровень “нормального” трафика для объекта и мог обнаруживать потенциальные проблемы безопасности и предоставлять точные исключения и уведомления об аномалиях.

Endpoint detection and response software on all computers to centrally log system behaviour and facilitate incident response. Microsoft’s free SysMon tool is an entry level option.
Relative Security Effectiveness:  Very Good | Potential User Resistance:   Low | Upfront Cost:  Medium | Ongoing Maintenance Cost:  Medium

А.8.15 Логирование
Должны создаваться, храниться, защищаться и анализироваться журналы, в которых фиксируются деятельность, исключения, сбои и другие релевантные события.

6.5.2. Средства мониторинга ИБ и контроля защитных мер должны выполнять следующие основные функции: 

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

Журналы событий, где это применимо, должны включать в себя:

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

Журналы событий могут содержать информацию ограниченного доступа. Для обеспечения конфиденциальности должны быть приняты соответствующие меры защиты (см. 18.1.4).

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

А.8.15 Logging
Logs that record activities, exceptions, faults and other relevant events shall be produced, stored, protected and analysed.