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

CIS Critical Security Controls v8 (The 18 CIS CSC)

Framework

13.9 

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

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

NIST Cybersecurity Framework (RU):
PR.AC-1
PR.AC-1: Для авторизованных устройств, пользователей и процессов выдаются, управляются, верифицируются, аннулируются и проверяются идентификационные и учетные данные
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 1.3.2
1.3.2 
Defined Approach Requirements: 
Outbound traffic from the CDE is restricted as follows:
  • To only traffic that is necessary.
  • All other traffic is specifically denied. 
Customized Approach Objective:
Unauthorized traffic cannot leave the CDE. 

Defined Approach Testing Procedures:
  • 1.3.2.a Examine configuration standards for NSCs to verify that they define restricting outbound traffic from the CDE in accordance with all elements specified in this requirement.
  • 1.3.2.b Examine configurations of NSCs to verify that outbound traffic from the CDE is restricted in accordance with all elements specified in this requirement. 
Purpose:
This requirement aims to prevent malicious individuals and compromised system components within the entity’s network from communicating with an untrusted external host. 

Good Practice:
All traffic outbound from the CDE, regardless of the destination, should be evaluated to ensure it follows established, authorized rules. Connections should be inspected to restrict traffic to only authorized communications—for example, by restricting source/destination addresses and ports, and blocking of content. 

Examples:
Implementing a rule that denies all inbound and outbound traffic that is not specifically needed— for example, by using an explicit “deny all” or implicit deny after allow statement—helps to prevent inadvertent holes that would allow unintended and potentially harmful traffic. 
Requirement 1.3.1
1.3.1 
Defined Approach Requirements: 
Inbound traffic to the CDE is restricted as follows:
  • To only traffic that is necessary.
  • All other traffic is specifically denied. 
Customized Approach Objective:
Unauthorized traffic cannot enter the CDE. 

Defined Approach Testing Procedures:
  • 1.3.1.a Examine configuration standards for NSCs to verify that they define restricting inbound traffic to the CDE is in accordance with all elements specified in this requirement. 
  • 1.3.1.b Examine configurations of NSCs to verify that inbound traffic to the CDE is restricted in accordance with all elements specified in this requirement. 
Purpose:
This requirement aims to prevent malicious individuals from accessing the entity’s network via unauthorized IP addresses or from using services, protocols, or ports in an unauthorized manner. 

Good Practice:
All traffic inbound to the CDE, regardless of where it originates, should be evaluated to ensure it follows established, authorized rules. Connections should be inspected to ensure traffic is restricted to only authorized communications—for example, by restricting source/destination addresses and ports, and blocking of content.

Examples: 
Implementing a rule that denies all inbound and outbound traffic that is not specifically needed— for example, by using an explicit “deny all” or implicit deny after allow statement—helps to prevent inadvertent holes that would allow unintended and potentially harmful traffic. 
Guideline for a healthy information system v.2.0 (EN):
7 STRENGTHENED
/STRENGTHENED
These developments can be supplemented by technical measures such as the authentication of devices on the network (for example thanks to 802.1X standard or an equivalent). 
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.13.1.1
A.13.1.1 Меры обеспечения информационной безопасности для сетей 
Мера обеспечения информационной безопасности: Сети должны управляться и контролироваться для обеспечения защиты информации систем и приложений 
A.9.1.2
А.9.1.2 Доступ к сетям и сетевым сервисам 
Мера обеспечения информационной безопасности: Пользователям следует предоставлять доступ только к тем сетям и сетевым сервисам, на использование которых они получили конкретное разрешение 
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 1.7 CSC 1.7 Deploy Port Level Access Control
Utilize port level access control, following 802.1x standards, to control which devices can authenticate to the network. The authentication system shall be tied into the hardware asset inventory data to ensure only authorized devices can connect to the network.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 1.3.1
1.3.1
Определенные Требования к Подходу:
Входящий трафик в CDE ограничен следующим образом:
  • Только к тому трафику, который необходим.
  • Весь остальной трафик специально запрещен.
Цель Индивидуального подхода:
Несанкционированный трафик не может попасть в CDE.

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

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

Примеры:
Реализация правила, запрещающего весь входящий и исходящий трафик, который специально не требуется — например, с помощью явного “запретить все” или неявного запрета после инструкции allow — помогает предотвратить непреднамеренные ошибки, которые допускают непреднамеренный и потенциально вредоносный трафик.
Requirement 1.3.2
1.3.2
Определенные Требования к Подходу:
Исходящий трафик из CDE ограничен следующим образом:
  • Только к тому трафику, который необходим.
  • Весь остальной трафик специально запрещен.
Цель Индивидуального подхода:
Несанкционированный трафик не может покинуть CDE.

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

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

Примеры:
Реализация правила, запрещающего весь входящий и исходящий трафик, который специально не требуется — например, с помощью явного “запретить все” или неявного запрета после инструкции allow — помогает предотвратить непреднамеренные ошибки, которые допускают непреднамеренный и потенциально вредносный трафик.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.20
А.8.20 Сетевая безопасность
В целях защиты информации в системах и приложениях должны быть защищены, управляться и контролироваться сети и сетевые устройства.
NIST Cybersecurity Framework (EN):
PR.AC-1 PR.AC-1: Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users and processes
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.8.20
А.8.20 Networks security
Networks and network devices shall be secured, managed and controlled to protect information in systems and applications.

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

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

Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.