Куда я попал?
SECURITM это SGRC система, ? автоматизирующая процессы в службах информационной безопасности. SECURITM помогает построить и управлять ИСПДн, КИИ, ГИС, СМИБ/СУИБ, банковскими системами защиты.
А еще SECURITM это место для обмена опытом и наработками для служб безопасности.

CIS Critical Security Controls v8 (The 18 CIS CSC)

Framework

17.4

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

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

ГОСТ Р № 57580.3-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Управление риском реализации информационных угроз и обеспечение операционной надежности. Общие положения.":
РМ.2
РМ.2 Разработка плана реагирования на риск реализации информационных угроз, обеспечивающего достижение и поддержание допустимого уровня такого риска (риск-аппетита финансовой организации).
NIST Cybersecurity Framework (RU):
PR.IP-9
PR.IP-9:  Созданы и управляются планы реагирования (реагирование на инциденты и непрерывность бизнеса) и планы восстановления (восстановление после инцидентов и аварийное  восстановление) 
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
ВПУ.2
ВПУ.2 Разработка и применение процедур реагирования в случае реализации информационных угроз, в том числе компьютерных атак со стороны поставщиков услуг, а также в случае идентификации риска распространения вредоносного кода на вычислительные сети финансовой организации*.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 10.4.3
10.4.3
Defined Approach Requirements: 
Exceptions and anomalies identified during the review process are addressed. 

Customized Approach Objective:
Suspicious or anomalous activities are addressed. 

Defined Approach Testing Procedures:
  • 10.4.3.a Examine security policies and procedures to verify that processes are defined for addressing exceptions and anomalies identified during the review process. 
  • 10.4.3.b Observe processes and interview personnel to verify that, when exceptions and anomalies are identified, they are addressed. 
Purpose:
If exceptions and anomalies identified during the log-review process are not investigated, the entity may be unaware of unauthorized and potentially malicious activities occurring within their network. 

Good Practice:
Entities should consider how to address the following when developing their processes for defining and managing exceptions and anomalies:
  • How log review activities are recorded, • How to rank and prioritize exceptions and anomalies,
  • What procedures should be in place to report and escalate exceptions and anomalies, and 
  • Who is responsible for investigating and for any remediation tasks. 
Requirement 10.7.2
10.7.2
Defined Approach Requirements: 
Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems:
  • Network security controls.
  • IDS/IPS.
  • Change-detection mechanisms.
  • Anti-malware solutions.
  • Physical access controls.
  • Logical access controls.
  • Audit logging mechanisms.
  • Segmentation controls (if used).
  • Audit log review mechanisms.
  • Automated security testing tools (if used). 
Customized Approach Objective:
Failures in critical security control systems are promptly identified and addressed. 

Applicability Notes:
This requirement applies to all entities, including service providers, and will supersede Requirement 10.7.1 as of 31 March 2025. It includes two additional critical security control systems not in Requirement 10.7.1. 
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:
  • 10.7.2.a Examine documentation to verify that processes are defined for the prompt detection and addressing of failures of critical security control systems, including but not limited to failure of all elements specified in this requirement. 
  • 10.7.2.b Observe detection and alerting processes and interview personnel to verify that failures of critical security control systems are detected and reported, and that failure of a critical security control results in the generation of an alert. 
Purpose:
Without formal processes to detect and alert when critical security controls fail, failures may go undetected for extended periods and provide attackers ample time to compromise system components and steal account data from the CDE. 

Good Practice:
The specific types of failures may vary, depending on the function of the device system component and technology in use. However, typical failures include a system no longer performing its security function or not functioning in its intended manner—for example, a firewall erasing its rules or going offline. 
Guideline for a healthy information system v.2.0 (EN):
40 STANDARD
/STANDARD
Noticing unusual behaviour from a workstation or a server (impossible connection, significant activity, unusual activity, unauthorised open services, files created, modified or deleted without authorisation, multiple anti-virus warnings, etc.) may be a warning of a possible intrusion. 

A bad reaction in the event of a security incident can make the situation worse and prevent the problem from being dealt properly. The right reaction is to disconnect the device from the network, to stop the attack. However, you must keep it powered and not restart it, so as to not lose useful information for analysing the attack. You must then alert the management, as well as the information system security point of contact. 

He or she may get in contact with the security incident response service providers (PRIS) in order to carry out the necessary technical operations (physically copying the disk, analysing the memory, logs and possible malware, etc.) and determine if other elements of the information system have been compromised. This will also concern coming up with a response to provide, in order to remove possible malware and the access that the hacker may have and to change compromised passwords. Any incident must be recorded in a centralised register. Charges may also be pressed with the competent legal service. 
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.16.1.1
A.16.1.1 Обязанности и процедуры 
Мера обеспечения информационной безопасности: Должны быть установлены обязанности и процедуры менеджмента для обеспечения уверенности в быстром, эффективном и надлежащем реагировании на инциденты информационной безопасности 
A.16.1.5
A.16.1.5 Реагирование на инциденты информационной безопасности 
Мера обеспечения информационной безопасности: Реагирование на инциденты информационной безопасности должно осуществляться в соответствии с документально оформленными процедурами 
A.16.1.7
A.16.1.7 Сбор свидетельств 
Мера обеспечения информационной безопасности: В организациях должны быть определены и применяться процедуры для идентификации, сбора, получения и сохранения информации, которая может использоваться в качестве свидетельств 
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 19.1 CSC 19.1 Document Incident Response Procedures
Ensure that there are written incident response plans that define roles of personnel as well as phases of incident handling/management.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 10.4.3
10.4.3
Определенные Требования к Подходу:
Исключения и аномалии, выявленные в ходе процесса проверки, устраняются.

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

Определенные Процедуры Тестирования Подхода:
  • 10.4.3.a Изучите политики и процедуры безопасности, чтобы убедиться, что определены процессы для устранения исключений и аномалий, выявленных в процессе проверки.
  • 10.4.3.b Наблюдайте за процессами и проводите собеседования с персоналом, чтобы убедиться, что при выявлении исключений и аномалий они устраняются.
Цель:
Если исключения и аномалии, выявленные в процессе просмотра журнала, не исследуются, организация может не знать о несанкционированных и потенциально вредоносных действиях, происходящих в ее сети.

Надлежащая практика:
Организациям следует рассмотреть вопрос о том, как учитывать следующее при разработке своих процессов определения и управления исключениями и аномалиями:
  • Как записываются действия по проверке журнала, • Как ранжировать и расставлять приоритеты исключений и аномалий,
  • Какие процедуры должны быть предусмотрены для сообщения об исключениях и аномалиях и их эскалации, а также
  • Кто отвечает за расследование и за любые задачи по исправлению положения.
Requirement 10.7.2
10.7.2
Определенные Требования к Подходу:
Сбои критических систем контроля безопасности обнаруживаются, предупреждаются и оперативно устраняются, включая, но не ограничиваясь, отказ следующих критических систем контроля безопасности:
  • Средства управления сетевой безопасностью.
  • IDS/IPS.
  • Механизмы обнаружения изменений.
  • Решения для защиты от вредоносных программ.
  • Контроль физического доступа.
  • Логический контроль доступа.
  • Механизмы ведения журнала аудита.
  • Элементы управления сегментацией (если они используются).
  • Механизмы проверки журналов аудита.
  • Автоматизированные средства тестирования безопасности (если они используются).
Цель Индивидуального подхода:
Сбои в критически важных системах контроля безопасности оперативно выявляются и устраняются.

Примечания по применению:
Это требование распространяется на все организации, включая поставщиков услуг, и заменит требование 10.7.1 с 31 марта 2025 года. Он включает в себя две дополнительные критически важные системы контроля безопасности, не указанные в требовании 10.7.1.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

Определенные Процедуры Тестирования Подхода:
  • 10.7.2.a Изучите документацию, чтобы убедиться, что определены процессы для оперативного обнаружения и устранения сбоев критических систем управления безопасностью, включая, но не ограничиваясь отказом всех элементов, указанных в этом требовании.
  • 10.7.2.b Наблюдайте за процессами обнаружения и оповещения и опрашивайте персонал, чтобы убедиться, что сбои критических систем контроля безопасности обнаружены и сообщены, и что сбой критического контроля безопасности приводит к генерации предупреждения.
Цель:
Без формальных процессов обнаружения и оповещения о сбое критических средств защиты сбои могут оставаться незамеченными в течение длительного времени и предоставлять злоумышленникам достаточно времени для компрометации системных компонентов и кражи данных учетной записи из CDE.

Надлежащая практика:
Конкретные типы отказов могут варьироваться в зависимости от функции системного компонента устройства и используемой технологии. Однако типичные сбои включают в себя то, что система больше не выполняет свою функцию безопасности или не функционирует должным образом — например, брандмауэр стирает свои правила или переходит в автономный режим.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.5.28
А.5.28 Сбор свидетельств
Организация должна установить и внедрить процедуры идентификации, сбора, получения и сохранения свидетельств, связанных с событиями ИБ.
А.5.26
А.5.26 Реагирование на инциденты ИБ
Реагирование на инциденты ИБ должно осуществляться в соответствии с документированными процедурами.
А.5.24
А.5.24 Планирование и подготовка в отношении инцидентов ИБ
Организация должна организовать процесс управления инцидентами ИБ путем определения, установления и коммуникации процессов управления инцидентами ИБ, ролей и обязанностей.
SWIFT Customer Security Controls Framework v2022:
7 - 7.1 Cyber Incident Response Planning
7.1 Cyber Incident Response Planning
NIST Cybersecurity Framework (EN):
PR.IP-9 PR.IP-9: Response plans (Incident Response and Business Continuity) and recovery plans (Incident Recovery and Disaster Recovery) are in place and managed
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.5.24
А.5.24 Information security incident management planning and preparation
The organization shall plan and prepare for managing information security incidents by defining, establishing and communicating information security incident management processes, roles and responsibilities.
А.5.28
А.5.28 Collection of evidence
The organization shall establish and implement procedures for the identification, collection, acquisition and preservation of evidence related to information security events.
А.5.26
А.5.26 Response to information security incidents
Information security incidents shall be responded to in accordance with the documented procedures.

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