Соответствие требованиям

Куда я попал?

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

Подробнее

SWIFT Customer Security Controls Framework v2022

Framework

6 - 6.4 Logging and Monitoring

Для проведения оценки соответствия по документу войдите в систему.

Показывать только требования

6.4 Logging and Monitoring

Обязательно для architecture type A1 A2 A3 A4 B

Control Definition

Control Objective: Record security events and detect anomalous actions and operations within the local SWIFT environment.

In-scope components:

Data exchange layer: network
Operating system of a dedicated and general-purpose operator PC
jump server
SWIFT-related components (including interfaces, GUI, SWIFT and customer connectors)
systems or virtual machines hosting SWIFT-related components
network devices protecting the secure zone and HSM
database linked to a messaging interface or a customer connector
authentication or authorisation servers, or both, controlling accesses to the secure zone
Local or remote (hosted or operated by a third party, or both) Virtualisation platform (also referred to as the hypervisor) hosting SWIFT-related VMs
[Advisory A1/A2/A3: Middleware server (such as IBM® MQ server or similar) used for data exchange between back-office and SWIFT-related components]
[Advisory A4: other Middleware server (such as an IBM® MQ server or similar) than customer connector used for data exchange between back-office and SWIFT-related components]

Risk Drivers:

lack of traceability
undetected anomalies or suspicious activity

Implementation Guidance

Control Statement:

Capabilities to detect anomalous activity are implemented, and a process or tool is in place to keep and review logs.

Control Context:

Developing a logging and monitoring plan is the basis for effectively detecting abnormal behaviour and potential attacks and support further investigations. As the operational environment becomes more complex, so will the logging and monitoring capability needed to perform adequate detection. Simplifying the operational environment will enable simpler logging and monitoring.

Implementation Guidelines:

The implementation guidelines are common methods to apply the relevant control. The guidelines are a helpful way to begin an assessment, but should never be considered as an "audit checklist" as each user’s implementation may vary. Therefore, in cases where some implementation guidelines elements are not present or partially covered, mitigations as well as particular environment specificities must be considered to properly assess the overall compliance adherence level (as per the suggested guidelines

or as per the alternatives).

Overall goals for logging and monitoring:
- Implement a plan to log security-relevant activities and configure alarms for suspicious security events (when supported by the application).
- Implement a plan to monitor security events in logs and to monitor other data (for example, real-time business activities through the GUI), and establish a plan to treat reported alarms.
- Support investigations and forensics in case of potential breach through log retention, in line with applicable laws and regulations.
• Logging:
- Logging capabilities are implemented to detect and support analysis of abnormal usage within the secure zone and any attempts to undermine the effectiveness of controls within the secure zone.
- Logs provide traceability of account usage to the appropriate individual.
- Minimum logs to be recorded include:
  - Command-line history for privileged operating system accounts on servers
  - Messaging and communication interface application and operating system logs which detail abnormal system behaviour (for example, activity outside normal business hours, multiple failed login attempts, authentication errors, changes to user groups)
  - Firewall logs
  - Database logs (if available, and as a minimum in the case of hosted database solutions).
Monitoring:
- Procedures are in place to identify suspicious login activities into any privileged operating system or application accounts within the secure zone.
- Monitoring processes are in place to review server, application, and database monitoring data of the secure zone either daily through human review or through automated monitoring with alerting.
- Monitoring processes are in place to review network-monitoring data on a regular basis.
- Unusual or suspicious activity is reported for further investigation to the appropriate security team.
Log retention:
- All logging and monitoring activities comply with applicable laws, regulations, and employment contracts which supersede other implementation guidance.
- Messaging and communication interface application audit logs are retained for no less than 12 months and are sufficiently protected from an enterprise administrator-level compromise (for example, log files are transferred to a separate system with different system administrator credentials).
- Operator PC, firewall, and database audit logs are retained for no less than 31 days (it is recommended to extend firewall and database audit logs retention to three months and possibly 12 months to support longer investigations).
- Audit logs captured on other identified in-scope components, at application level or system level, are retained for no less than 12 months.
- Prevent audit log loss by considering a range of configurable choices when log storage is to be exhausted. As examples, such choices can include log rotation, degraded mode or ignoring some events.

Optional Enhancements:

A centralised logging capability is implemented, minimising the number of log locations to be inspected.
Session recording is implemented to record all activity conducted by privileged accounts on SWIFT secure zone servers.

Похожие требования

ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 8. Требования к организации и управлению защитой информации":

КЗИ.12

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

Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения":

Р. 7 п. 4 п.п. 4

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

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

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

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

Р. 8 п. 12 п.п. 2

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

ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":

МАС.6

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

МАС.5

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

УЗП.28

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

РИ.1

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

МАС.4

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

NIST Cybersecurity Framework (RU):

RS.AN-1

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

PR.PT-1

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

DE.CM-1

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

DE.AE-2

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

Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":

ЗСВ.3 ЗСВ.3 Регистрация событий безопасности в виртуальной инфраструктуре

РСБ.5 РСБ.5 Мониторинг (просмотр, анализ) результатов регистрации событий безопасности и реагирование на них

РСБ.3 РСБ.3 Сбор, запись и хранение информации о событиях безопасности в течение установленного времени хранения

ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":

A.12.4.1

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

CIS Critical Security Controls v7.1 (SANS Top 20):

CSC 6.7 CSC 6.7 Regularly Review Logs
On a regular basis, review logs to identify anomalies or abnormal events.

Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":

ЗСВ.3 ЗСВ.3 Регистрация событий безопасности в виртуальной инфраструктуре

РСБ.3 РСБ.3 Сбор, запись и хранение информации о событиях безопасности в течении установленного времени хранения

РСБ.5 РСБ.5 Мониторинг (просмотр, анализ) результатов регистрации событий безопасности и реагирование на них

Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":

АУД.7 АУД.7 Мониторинг безопасности

АУД.4 АУД.4 Регистрация событий безопасности

NIST Cybersecurity Framework (EN):

DE.AE-2 DE.AE-2: Detected events are analyzed to understand attack targets and methods

PR.PT-1 PR.PT-1: Audit/log records are determined, documented, implemented, and reviewed in accordance with policy

RS.AN-1 RS.AN-1: Notifications from detection systems are investigated

Стандарт Банка России № РС БР ИББС-2.5-2014 от 01.06.2014 "Менеджмент инцидентов информационной безопасности":

Р. 6 п. 5 п.п. 2

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

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

Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":

АУД.7 АУД.7 Мониторинг безопасности

АУД.4 АУД.4 Регистрация событий безопасности

Связанные защитные меры

Ничего не найдено