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

Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А

ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022

A.13.1.1

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

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

Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения":
Р. 7 п. 6 п.п. 4
7.6.4. В организациях БС РФ в связи с повышенными рисками нарушения ИБ при взаимодействии с сетью Интернет должны применяться защитные меры, в том числе межсетевые экраны, антивирусные средства, средства обнаружения вторжений, средства криптографической защиты информации, обеспечивающие, среди прочего, прием и передачу информации только в установленном формате и только для конкретной технологии.
Должны быть разработаны и введены в действие инструкции и рекомендации по использованию сети Интернет, учитывающие особенности банковских технологических процессов.
Должны быть определены и выполняться процедуры протоколирования посещения ресурсов сети Интернет работниками организации БС РФ. Данные о посещенных работниками организации БС РФ ресурсов сети Интернет должны быть доступны работникам службы ИБ.
Р. 7 п. 6 п.п. 2
7.6.2. Должны быть определены, выполняться, регистрироваться и контролироваться процедуры подключения и использования ресурсов сети Интернет.
Р. 7 п. 11 п.п. 7
7.11.7. В организации БС РФ должны быть реализованы защита периметров сегментов вычислительной сети, в которых расположены ИСПДн, и контроль информационного взаимодействия между сегментами вычислительных сетей.
В организации БС РФ должны быть определены и контролироваться правила информационного взаимодействия ИСПДн с иными АБС. 
CIS Critical Security Controls v8 (The 18 CIS CSC):
13.9 
13.9 Deploy Port-Level Access Control
Deploy port-level access control. Port-level access control utilizes 802.1x, or similar network access control protocols, such as certificates, and may incorporate user and/or device authentication. 
12.1
12.1 Ensure Network Infrastructure is Up-to-Date
Ensure network infrastructure is kept up-to-date. Example implementations include running the latest stable release of software and/or using currently supported network-as-a-service (NaaS) offerings. Review software versions monthly, or more frequently, to verify software support. 
4.2 
4.2 Establish and Maintain a Secure Configuration Process for Network Infrastructure
Establish and maintain a secure configuration process for network devices. Review and update documentation annually, or when significant enterprise changes occur that could impact this Safeguard. 
13.3 
13.3 Deploy a Network Intrusion Detection Solution
Deploy a network intrusion detection solution on enterprise assets, where appropriate. Example implementations include the use of a Network Intrusion Detection System (NIDS) or equivalent cloud service provider (CSP) service. 
4.1
4.1 Establish and Maintain a Secure Configuration Process 
Establish and maintain a secure configuration process for enterprise assets (end-user devices, including portable and mobile; non-computing/IoT devices; and servers) and software (operating systems and applications). Review and update documentation annually, or when significant enterprise changes occur that could impact this Safeguard 
4.4
4.4 Implement and Manage a Firewall on Servers 
Implement and manage a firewall on servers, where supported. Example implementations include a virtual firewall, operating system firewall, or a third-party firewall agent. 
1.2
1.2 Address Unauthorized Assets 
Ensure that a process exists to address unauthorized assets on a weekly basis. The enterprise may choose to remove the asset from the network, deny the asset from connecting remotely to the network, or quarantine the asset. 
3.8
3.8 Document Data Flows 
Document data flows. Data flow documentation includes service provider data flows and should be based on the enterprise’s data management process. Review and update documentation annually, or when significant enterprise changes occur that could impact this Safeguard. 
12.3
12.3 Securely Manage Network Infrastructure 
Securely manage network infrastructure. Example implementations include version-controlled-infrastructure-ascode, and the use of secure network protocols, such as SSH and HTTPS. 
13.6
13.6 Collect Network Traffic Flow Logs
Collect network traffic flow logs and/or network traffic to review and alert upon from network devices. 
12.2
12.2 Establish and Maintain a Secure Network Architecture 
Establish and maintain a secure network architecture. A secure network architecture must address segmentation, least privilege, and availability, at a minimum. 
13.8 
13.8 Deploy a Network Intrusion Prevention Solution Network
Deploy a network intrusion prevention solution, where appropriate. Example implementations include the use of a Network Intrusion Prevention System (NIPS) or equivalent CSP service. 
4.8
4.8 Uninstall or Disable Unnecessary Services on Enterprise Assets and Software 
Uninstall or disable unnecessary services on enterprise assets and software, such as an unused file sharing service, web application module, or service function. 
9.3
9.3 Maintain and Enforce Network-Based URL Filters 
Enforce and update network-based URL filters to limit an enterprise asset from connecting to potentially malicious or unapproved websites. Example implementations include category-based filtering, reputation-based filtering, or through the use of block lists. Enforce filters for all enterprise assets. 
4.5
4.5 Implement and Manage a Firewall on End-User Devices 
Implement and manage a host-based firewall or port-filtering tool on end-user devices, with a default-deny rule that drops all traffic except those services and ports that are explicitly allowed. 
3.10
3.10 Encrypt Sensitive Data in Transit 
Encrypt sensitive data in transit. Example implementations can include: Transport Layer Security (TLS) and Open Secure Shell (OpenSSH). 
9.6
9.6 Block Unnecessary File Types 
Block unnecessary file types attempting to enter the enterprise’s email gateway. 
13.4
13.4 Perform Traffic Filtering Between Network Segments 
Perform traffic filtering between network segments, where appropriate. 
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
ВСА.4
ВСА.4 Контроль отсутствия (выявление) аномальной сетевой активности, связанной с возможным несанкционированным логическим доступом к ресурсам доступа, размещенным в вычислительных сетях финансовой организации, подключенных к сети Интернет
СМЭ.2
СМЭ.2 Реализация сетевого взаимодействия и сетевой изоляции на уровне не выше третьего (сетевой) по семиуровневой стандартной модели взаимодействия открытых систем, определенной в ГОСТ Р ИСО/МЭК 7498-1, сегментов контуров безопасности и внутренних вычислительных сетей финансовой организации, не предназначенных для размещения информационной инфраструктуры, входящей в контуры безопасности (далее — иные внутренние вычислительные сети финансовой организации)
СМЭ.15
СМЭ.15 Реализация сетевого взаимодействия и сетевой изоляции на уровне не выше третьего (сетевой) по семиуровневой стандартной модели взаимодействия открытых систем, определенной в ГОСТ Р ИСО/МЭК 7498-1, внутренних вычислительных сетей финансовой организации и сети Интернет
СМЭ.19
СМЭ.19 Реализация сетевого взаимодействия внутренних вычислительных сетей финансовой организации и сети Интернет через ограниченное количество контролируемых точек доступа
ВСА.6
ВСА.6 Контроль отсутствия (выявление) аномальной сетевой активности, связанной с возможным несанкционированным логическим доступом к ресурсам доступа, размещенным во внутренних вычислительных сетях финансовой организации
ВСА.2
ВСА.2 Контроль отсутствия (выявление) аномальной сетевой активности, связанной с возможным несанкционированным информационным взаимодействием между вычислительными сетями финансовой организации и сетью Интернет
СМЭ.14
СМЭ.14 Реализация сетевого взаимодействия и сетевой изоляции на уровне не выше второго (канальный) по семиуровневой стандартной модели взаимодействия открытых систем, определенной в ГОСТ Р ИСО/МЭК 7498-1, внутренних вычислительных сетей финансовой организации и сети Интернет
ЗСВ.4
ЗСВ.4 Разграничение и контроль осуществления одновременного доступа виртуальных машин к системе хранения данных в пределах контура безопасности на уровне не выше третьего (сетевой) по семиуровневой стандартной модели взаимодействия открытых систем, определенной в ГОСТ Р ИСО/МЭК 7498-1
ЗБС.4
ЗБС.4 Реализация сетевого взаимодействия и сетевой изоляции на уровне не выше второго (канальный) по семиуровневой стандартной модели взаимодействия открытых систем, определенной в ГОСТ Р ИСО/МЭК 7498-1, внутренних вычислительных сетей финансовой организации и сегментов вычисленных сетей, выделенных в соответствии с пунктом ЗБС.3 настоящей таблицы
ВСА.3
ВСА.3 Контроль отсутствия (выявление) аномальной сетевой активности, связанной с возможным несанкционированным информационным взаимодействием между сегментами, предназначенными для размещения общедоступных объектов доступа (в том числе банкоматов, платежных терминалов), и сетью Интернет
ВСА.1
ВСА.1 Контроль отсутствия (выявление) аномальной сетевой активности, связанной с возможным несанкционированным информационным взаимодействием между сегментами контуров безопасности и иными внутренними вычислительными сетями финансовой организации
NIST Cybersecurity Framework (RU):
PR.DS-5
PR.DS-5:  Реализована защита от утечки данных
PR.DS-2
PR.DS-2: Данные при передаче защищаются  
DE.AE-1
DE.AE-1: Для пользователей и систем устанавливается и управляется базовый уровень сетевых операций и ожидаемых потоков данных  
PR.PT-4
PR.PT-4: Защищены сети связи и управления 
PR.AC-3
PR.AC-3: Управляется процесс предоставления удаленного доступа
PR.AC-5
PR.AC-5: Защищена целостность сети, включая сегрегацию сети при необходимости
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 1.2.3
1.2.3 
Defined Approach Requirements: 
An accurate network diagram(s) is maintained that shows all connections between the CDE and other networks, including any wireless networks. 

Customized Approach Objective:
A representation of the boundaries between the CDE, all trusted networks, and all untrusted networks, is maintained and available. 

Applicability Notes:
A current network diagram(s) or other technical or topological solution that identifies network connections and devices can be used to meet this requirement. 

Defined Approach Testing Procedures:
  • 1.2.3.a Examine diagram(s) and network configurations to verify that an accurate network diagram(s) exists in accordance with all elements specified in this requirement. 
  • 1.2.3.b Examine documentation and interview responsible personnel to verify that the network diagram(s) is accurate and updated when there are changes to the environment. 
Purpose:
Maintaining an accurate and up-to-date network diagram(s) prevents network connections and devices from being overlooked and unknowingly left unsecured and vulnerable to compromise. 
A properly maintained network diagram(s) helps an organization verify its PCI DSS scope by identifying systems connecting to and from the CDE. 

Good Practice:
All connections to and from the CDE should be identified, including systems providing security, management, or maintenance services to CDE system components. Entities should consider including the following in their network diagrams:
  • All locations, including retail locations, data centers, corporate locations, cloud providers, etc.
  • Clear labeling of all network segments.
  • All security controls providing segmentation, including unique identifiers for each control (for example, name of control, make, model, and version).
  • All in-scope system components, including NSCs, web app firewalls, anti-malware solutions, change management solutions, IDS/IPS, log aggregation systems, payment terminals, payment applications, HSMs, etc.
  • Clear labeling of any out-of-scope areas on the diagram via a shaded box or other mechanism.
  • Date of last update, and names of people that made and approved the updates.
  • A legend or key to explain the diagram. 
Diagrams should be updated by authorized personnel to ensure diagrams continue to provide an accurate description of the network. 
Requirement 1.4.2
1.4.2 
Defined Approach Requirements: 
Inbound traffic from untrusted networks to trusted networks is restricted to: 
  • Communications with system components that are authorized to provide publicly accessible services, protocols, and ports. 
  • Stateful responses to communications initiated by system components in a trusted network. 
  • All other traffic is denied. 
Customized Approach Objective:
Only traffic that is authorized or that is a response to a system component in the trusted network can enter a trusted network from an untrusted network. 

Applicability Notes:
The intent of this requirement is to address communication sessions between trusted and untrusted networks, rather than the specifics of protocols. This requirement does not limit the use of UDP or other connectionless network protocols if state is maintained by the NSC. 

Defined Approach Testing Procedures:
  • 1.4.2 Examine vendor documentation and configurations of NSCs to verify that inbound traffic from untrusted networks to trusted networks is restricted in accordance with all elements specified in this requirement. 
Purpose:
Ensuring that public access to a system component is specifically authorized reduces the risk of system components being unnecessarily exposed to untrusted networks. 

Good Practice:
System components that provide publicly accessible services, such as email, web, and DNS servers, are the most vulnerable to threats originating from untrusted networks. 
Ideally, such systems are placed within a dedicated trusted network that is public facing (for example, a DMZ) but that is separated via NSCs from more sensitive internal systems, which helps protect the rest of the network in the event these externally accessible systems are compromised. This functionality is intended to prevent malicious actors from accessing the organization's internal network from the Internet, or from using services, protocols, or ports in an unauthorized manner. 
Where this functionality is provided as a built-in feature of an NSC, the entity should ensure that its configurations do not result in the functionality being disabled or bypassed. 

Definitions:
Maintaining the "state" (or status) for each connection into a network means the NSC “knows” whether an apparent response to a previous connection is a valid, authorized response (since the NSC retains each connection’s status) or whether it is malicious traffic trying to fool the NSC into allowing the connection. 
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 12.5.2
12.5.2
Defined Approach Requirements: 
PCI DSS scope is documented and confirmed by the entity at least once every 12 months and upon significant change to the in-scope environment. At a minimum, the scoping validation includes:
  • Identifying all data flows for the various payment stages (for example, authorization, capture settlement, chargebacks, and refunds) and acceptance channels (for example, card-present, card-not-present, and e-commerce).
  • Updating all data-flow diagrams per Requirement 1.2.4.
  • Identifying all locations where account data is stored, processed, and transmitted, including but not limited to: 1) any locations outside of the currently defined CDE, 2) applications that process CHD, 3) transmissions between systems and networks, and 4) file backups.
  • Identifying all system components in the CDE, connected to the CDE, or that could impact security of the CDE. 
  • Identifying all segmentation controls in use and the environment(s) from which the CDE is segmented, including justification for environments being out of scope.
  • Identifying all connections from third-party entities with access to the CDE.
  • Confirming that all identified data flows, account data, system components, segmentation controls, and connections from third parties with access to the CDE are included in scope. 
Customized Approach Objective:
 PCI DSS scope is verified periodically, and after significant changes, by comprehensive analysis and appropriate technical measures. 
Applicability Notes:
 This annual confirmation of PCI DSS scope is an activity expected to be performed by the entity under assessment, and is not the same, nor is it intended to be replaced by, the scoping confirmation performed by the entity’s assessor during the annual assessment. 
Defined Approach Testing Procedures:
  • 12.5.2.a Examine documented results of scope reviews and interview personnel to verify that the reviews are performed: 
    • At least once every 12 months.
    • After significant changes to the in-scope environment. 
  • 12.5.2.b Examine documented results of scope reviews performed by the entity to verify that PCI DSS scoping confirmation activity includes all elements specified in this requirement. 
Purpose:
Frequent validation of PCI DSS scope helps to ensure PCI DSS scope remains up to date and aligned with changing business objectives, and therefore that security controls are protecting all appropriate system components. 

Good Practice:
Accurate scoping involves critically evaluating the CDE and all connected system components to determine the necessary coverage for PCI DSS requirements. Scoping activities, including careful analysis and ongoing monitoring, help to ensure that in-scope systems are appropriately secured. When documenting account data locations, the entity can consider creating a table or spreadsheet that includes the following information:
  • Data stores (databases, files, cloud, etc.), including the purpose of data storage and the retention period,
  • Which CHD elements are stored (PAN, expiry date, cardholder name, and/or any elements of SAD prior to completion of authorization), 
  • How data is secured (type of encryption and strength, hashing algorithm and strength, truncation, tokenization), 
  • How access to data stores is logged, including a description of logging mechanism(s) in use (enterprise solution, application level, operating system level, etc.). 
In addition to internal systems and networks, all connections from third-party entities—for example, business partners, entities providing remote support services, and other service providers—need to be identified to determine inclusion for PCI DSS scope. Once the in-scope connections have been identified, the applicable PCI DSS controls can be implemented to reduce the risk of a third-party connection being used to compromise an entity’s CDE. 
A data discovery tool or methodology can be used to facilitate identifying all sources and locations of PAN, and to look for PAN that resides on systems and networks outside the currently defined CDE or in unexpected places within the defined CDE— for example, in an error log or memory dump file. This approach can help ensure that previously unknown locations of PAN are detected and that the PAN is either eliminated or properly secured 

Further Information:
For additional guidance, refer to Information Supplement: Guidance for PCI DSS Scoping and Network Segmentation. 
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. 
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 12.10 CSC 12.10 Decrypt Network Traffic at Proxy
Decrypt all encrypted network traffic at the boundary proxy prior to analyzing the content. However, the organization may use whitelists of allowed sites that can be accessed through the proxy without decrypting the traffic.
CSC 13.3 CSC 13.3 Monitor and Block Unauthorized Network Traffic
Deploy an automated tool on network perimeters that monitors for unauthorized transfer of sensitive information and blocks such transfers while alerting information security professionals.
CSC 15.2 CSC 15.2 Detect Wireless Access Points Connected to the Wired Network
Configure network vulnerability scanning tools to detect and alert on unauthorized wireless access points connected to the wired network.
CSC 12.8 CSC 12.8 Deploy NetFlow Collection on Networking Boundary Devices
Enable the collection of NetFlow and logging data on all network boundary devices.
CSC 12.6 CSC 12.6 Deploy Network-Based IDS Sensors
Deploy network-based Intrusion Detection Systems (IDS) sensors to look for unusual attack mechanisms and detect compromise of these systems at each of the organization's network boundaries.
CSC 15.10 CSC 15.10 Create Separate Wireless Network for Personal and Untrusted Devices
Create a separate wireless network for personal or untrusted devices. Enterprise access from this network should be treated as untrusted and filtered and audited accordingly.
CSC 12.1 CSC 12.1 Maintain an Inventory of Network Boundaries
Maintain an up-to-date inventory of all of the organization's network boundaries.
CSC 9.4 CSC 9.4 Apply Host-Based Firewalls or Port-Filtering
Apply host-based firewalls or port-filtering tools on end systems, with a default-deny rule that drops all traffic except those services and ports that are explicitly allowed.
CSC 11.2 CSC 11.2 Document Traffic Configuration Rules
All configuration rules that allow traffic to flow through network devices should be documented in a configuration management system with a specific business reason for each rule, a specific individual’s name responsible for that business need, and an expected duration of the need.
CSC 14.2 CSC 14.2 Enable Firewall Filtering Between VLANs
Enable firewall filtering between VLANs to ensure that only authorized systems are able to communicate with other systems necessary to fulfill their specific responsibilities.
CSC 12.5 CSC 12.5 Configure Monitoring Systems to Record Network Packets
Configure monitoring systems to record network packets passing through the boundary at each of the organization's network boundaries.
CSC 12.9 CSC 12.9 Deploy Application Layer Filtering Proxy Server
Ensure that all network traffic to or from the Internet passes through an authenticated application layer proxy that is configured to filter unauthorized connections.
CSC 9.5 CSC 9.5 Implement Application Firewalls
Place application firewalls in front of any critical servers to verify and validate the traffic going to the server. Any unauthorized traffic should be blocked and logged.
CSC 11.5 CSC 11.5 Manage Network Devices Using Multi-Factor Authentication and Encrypted Sessions
Manage all network devices using multi-factor authentication and encrypted sessions.
CSC 15.7 CSC 15.7 Leverage the Advanced Encryption Standard (AES) to Encrypt Wireless Data
Leverage the Advanced Encryption Standard (AES) to encrypt wireless data in transit.
CSC 16.5 CSC 16.5 Encrypt Transmittal of Username and Authentication Credentials
Ensure that all account usernames and authentication credentials are transmitted across networks using encrypted channels.
CSC 15.8 CSC 15.8 Use Wireless Authentication Protocols That Require Mutual, Multi-Factor Authentication
Ensure that wireless networks use authentication protocols such as Extensible Authentication Protocol-Transport Layer Security (EAP/TLS), which requires mutual, multi-factor authentication.
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.
CSC 12.7 CSC 12.7 Deploy Network-Based Intrusion Prevention Systems
Deploy network-based Intrusion Prevention Systems (IPS) to block malicious network traffic at each of the organization's network boundaries.
CSC 14.3 CSC 14.3 Disable Workstation to Workstation Communication
Disable all workstation-to-workstation communication to limit an attacker's ability to move laterally and compromise neighboring systems, through technologies such as Private VLANs or micro segmentation.
CSC 12.4 CSC 12.4 Deny Communication Over Unauthorized Ports
Deny communication over unauthorized TCP or UDP ports or application traffic to ensure that only authorized protocols are allowed to cross the network boundary in or out of the network at each of the organization's network boundaries.
CSC 12.3 CSC 12.3 Deny Communications With Known Malicious IP Addresses
Deny communications with known malicious or unused Internet IP addresses and limit access only to trusted and necessary IP address ranges at each of the organization's network boundaries,.
CSC 9.2 CSC 9.2 Ensure Only Approved Ports, Protocols, and Services Are Running
Ensure that only network ports, protocols, and services listening on a system with validated business needs are running on each system.
CSC 11.4 CSC 11.4 Install the Latest Stable Version of Any Security-Related Updates on All Network Devices
Install the latest stable version of any security-related updates on all network devices.
CSC 12.2 CSC 12.2 Scan for Unauthorized Connections Across Trusted Network Boundaries
Perform regular scans from outside each trusted network boundary to detect any unauthorized connections which are accessible across the boundary.
CSC 15.3 CSC 15.3 Use a Wireless Intrusion Detection System
Use a wireless intrusion detection system (WIDS) to detect and alert on unauthorized wireless access points connected to the network.
CSC 11.1 CSC 11.1 Maintain Standard Security Configurations for Network Devices
Maintain documented security configuration standards for all authorized network devices.
CSC 1.6 CSC 1.6 Address Unauthorized Assets
Ensure that unauthorized assets are either removed from the network, quarantined, or the inventory is updated in a timely manner.
CSC 7.4 CSC 7.4 Maintain and Enforce Network-Based URL Filters
Enforce network-based URL filters that limit a system's ability to connect to websites not approved by the organization. This filtering shall be enforced for each of the organization's systems, whether they are physically at an organization's facilities or not.
CSC 9.3 CSC 9.3 Perform Regular Automated Port Scans
Perform automated port scans on a regular basis against all systems and alert if unauthorized ports are detected on a system.
CSC 13.5 CSC 13.5 Monitor and Detect Any Unauthorized Use of Encryption
Monitor all traffic leaving the organization and detect any unauthorized use of encryption.
CSC 14.4 CSC 14.4 Encrypt All Sensitive Information in Transit
Encrypt all sensitive information in transit.
CSC 7.9 CSC 7.9 Block Unnecessary File Types
Block all email attachments entering the organization's email gateway if the file types are unnecessary for the organization's business.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 12.5.2
12.5.2
Определенные Требования к Подходу:
Область применения PCI DSS документируется и подтверждается организацией не реже одного раза в 12 месяцев и при значительных изменениях в среде, относящейся к сфере применения. Как минимум, проверка области действия включает в себя:
  • Идентификация всех потоков данных для различных этапов оплаты (например, авторизация, фиксированный расчет, возврат средств и возврат средств) и каналов приема (например, предъявление карты, отсутствие карты и электронная коммерция).
  • Обновление всех схем потоков данных в соответствии с требованием 1.2.4.
  • Определение всех местоположений, в которых хранятся, обрабатываются и передаются данные учетной записи, включая, но не ограничиваясь: 1) любые местоположения за пределами определенного в настоящее время CDE, 2) приложения, обрабатывающие CHD, 3) передачи между системами и сетями и 4) резервные копии файлов.
  • Идентификация всех системных компонентов в CDE, подключенных к CDE или которые могут повлиять на безопасность CDE.
  • Определение всех используемых элементов управления сегментацией и инфраструктуры (сред), из которых сегментируется CDE, включая обоснование того, что инфраструктура выходит за рамки области применения.
  • Идентификация всех подключений от сторонних организаций, имеющих доступ к CDE.
  • Подтверждение того, что все идентифицированные потоки данных, данные учетной записи, системные компоненты, элементы управления сегментацией и соединения от третьих сторон, имеющих доступ к CDE, включены в область действия.
Цель Индивидуального подхода:
Область применения PCI DSS периодически проверяется и после внесения существенных изменений путем всестороннего анализа и принятия соответствующих технических мер.
Примечания по применению:
Это ежегодное подтверждение области применения PCI DSS является деятельностью, которую, как ожидается, будет выполнять оцениваемый субъект, и не является тем же самым и не предназначено для замены подтверждения области применения, выполняемого оценщиком субъекта во время ежегодной оценки.

Определенные Процедуры Тестирования Подхода:
  • 12.5.2.а Изучить документированные результаты проверок сферы охвата и опросить персонал, чтобы убедиться, что проверки выполнены:
    • Не реже одного раза в 12 месяцев.
    • После значительных изменений в среде in-scope.
  • 12.5.2.b Изучите документированные результаты проверок сферы охвата, выполненных организацией, чтобы убедиться, что деятельность по подтверждению области охвата PCI DSS включает все элементы, указанные в этом требовании.
Цель:
Частая проверка области применения PCI DSS помогает гарантировать, что область применения PCI DSS остается актуальной и соответствует меняющимся бизнес-целям, и, следовательно, что средства контроля безопасности защищают все соответствующие компоненты системы.

Надлежащая практика:
Точное определение области включает в себя критическую оценку CDE и всех подключенных компонентов системы для определения необходимого покрытия требований PCI DSS. Мероприятия по определению области охвата, включая тщательный анализ и постоянный мониторинг, помогают обеспечить надлежащую защиту систем в области охвата. При документировании местоположений данных учетной записи организация может рассмотреть возможность создания таблицы или электронной таблицы, включающей следующую информацию:
Хранилища данных (базы данных, файлы, облако и т.д.), Включая цель хранения данных и срок хранения,
Какие элементы CHD сохраняются (PAN, дата истечения срока действия, имя владельца карты и/или любые элементы SAD до завершения авторизации),
Как защищаются данные (тип шифрования и надежность, алгоритм хеширования и надежность, усечение, токенизация),
Как регистрируется доступ к хранилищам данных, включая описание используемого механизма (механизмов) ведения журнала (корпоративное решение, уровень приложения, уровень операционной системы и т.д.).
В дополнение к внутренним системам и сетям, все подключения от сторонних организаций - например, деловых партнеров, организаций, предоставляющих услуги удаленной поддержки, и других поставщиков услуг — должны быть идентифицированы для определения включения в сферу действия PCI DSS. Как только соединения в рамках области будут идентифицированы, могут быть реализованы соответствующие средства контроля PCI DSS, чтобы снизить риск использования стороннего подключения для компрометации CDE организации.
Инструмент или методология обнаружения данных могут быть использованы для облегчения идентификации всех источников и местоположений PAN, а также для поиска PAN, который находится в системах и сетях за пределами текущего определенного CDE или в неожиданных местах в пределах определенного CDE — например, в журнале ошибок или файле дампа памяти. Этот подход может помочь гарантировать, что ранее неизвестные местоположения PAN будут обнаружены и что PAN будет либо удален, либо должным образом закреплен

Дополнительная информация:
Дополнительные рекомендации см. в Информационном дополнении: Руководство по определению области действия PCI DSS и сегментации сети.
Requirement 1.4.2
1.4.2
Определенные Требования к Подходу:
Входящий трафик из ненадежных сетей в доверенные сети ограничен:
  • Связь с компонентами системы, которые уполномочены предоставлять общедоступные службы, протоколы и порты.
  • Ответы с отслеживанием состояния на сообщения, инициированные системными компонентами в доверенной сети.
  • Весь остальной трафик запрещен.
Цель Индивидуального подхода:
Только авторизованный трафик или трафик, являющийся ответом на системный компонент в доверенной сети, может поступать в доверенную сеть из ненадежной сети.

Примечания по применению:
Целью этого требования является рассмотрение сеансов связи между доверенными и ненадежными сетями, а не специфики протоколов. Это требование не ограничивает использование UDP или других сетевых протоколов без установления соединения, если состояние поддерживается NSC.

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

Надлежащая практика:
Системные компоненты, предоставляющие общедоступные службы, такие как электронная почта, веб-серверы и DNS-серверы, наиболее уязвимы для угроз, исходящих из ненадежных сетей.
В идеале такие системы размещаются в выделенной доверенной сети, которая является общедоступной (например, DMZ), но которая отделена через NSCS от более критичных внутренних систем, что помогает защитить остальную часть сети в случае взлома систем, доступных извне. Эта функция предназначена для предотвращения доступа злоумышленников к внутренней сети организации из Интернета или несанкционированного использования служб, протоколов или портов.
Если эта функциональность предоставляется как встроенная функция NSC, организация должна убедиться, что ее конфигурации не приводят к отключению или обходу функциональности.

Определения:
Поддержание "состояния" (или статуса) для каждого подключения к сети означает, что NSC “знает”, является ли очевидный ответ на предыдущее соединение действительным, авторизованным ответом (поскольку NSC сохраняет статус каждого соединения) или это вредоносный трафик, пытающийся обмануть NSC, чтобы разрешить соединение.
Requirement 1.2.3
1.2.3
Определенные Требования к Подходу:
Поддерживается точная сетевая схема (схемы), которая показывает все соединения между CDE и другими сетями, включая любые беспроводные сети.

Цель Индивидуального подхода:
Осуществляется и выполнимо определение границ между CDE, всеми доверенными сетями и всеми ненадежными сетями.

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

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

Надлежащая практика:
Должны быть идентифицированы все подключения к CDE и из него, включая системы, обеспечивающие безопасность, управление или обслуживание компонентов системы CDE. Организациям следует рассмотреть возможность включения в свои сетевые схемы:
  • Все местоположения, включая торговые точки, центры обработки данных, корпоративные местоположения, облачных провайдеров и т.д.
  • Четкая маркировка всех сегментов сети.
  • Все элементы управления безопасностью, обеспечивающие сегментацию, включая уникальные идентификаторы для каждого элемента управления (например, имя элемента управления, марка, модель и версия).
  • Все системные компоненты, включая NSCS, брандмауэры веб-приложений, решения для защиты от вредоносных программ, решения для управления изменениями, идентификаторы /IP-адреса, системы агрегирования журналов, платежные терминалы, платежные приложения, HSM и т.д.
  • Очистите маркировку любых областей, выходящих за рамки, на схеме с помощью заштрихованной рамки или другого механизма.
  • Дата последнего обновления и инициалы людей, которые внесли и одобрили обновления.
  • Легенда для объяснения схемы.
Схемы должны обновляться уполномоченным персоналом, чтобы гарантировать, что схемы по-прежнему дают точное описание сети.
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 Сетевая безопасность
В целях защиты информации в системах и приложениях должны быть защищены, управляться и контролироваться сети и сетевые устройства.
SWIFT Customer Security Controls Framework v2022:
6 - 6.5A Intrusion Detection
6.5A Intrusion Detection
NIST Cybersecurity Framework (EN):
DE.AE-1 DE.AE-1: A baseline of network operations and expected data flows for users and systems is established and managed
PR.DS-5 PR.DS-5: Protections against data leaks are implemented
PR.DS-2 PR.DS-2: Data-in-transit is protected
PR.PT-4 PR.PT-4: Communications and control networks are protected
PR.AC-3 PR.AC-3: Remote access is managed
PR.AC-5 PR.AC-5: Network integrity is protected (e.g., network segregation, network segmentation)
Стандарт № 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.

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

Название Дата Влияние
Community
1 5 / 70
Нанесение грифа конфиденциальности на файлы (маркировка)
По событию Вручную Организационная Техническая Удерживающая
24.05.2022
24.05.2022 1 5 / 70
Community
1 15 / 68
Централизованная установка обновлений для ОС Windows через WSUS сервер
Ежедневно Автоматически Техническая Превентивная Компенсирующая
04.05.2022
04.05.2022 1 15 / 68
Community
9 25 / 72
Выделение ключевых систем в отдельную сеть (сегментация сети)
Разово Вручную Техническая Превентивная
03.05.2022
03.05.2022 9 25 / 72
Community
1 21 / 89
Антивирусная защита рабочих станций
Постоянно Автоматически Техническая Превентивная
11.02.2022
11.02.2022 1 21 / 89
Community
1 9 / 82
Блокировка доступа к несанкционированным сетевым папкам в локальной сети
Постоянно Автоматически Техническая Превентивная
12.11.2021
12.11.2021 1 9 / 82
Community
1 3 / 40
Ограничение (блокировка) доступа к некорпоративным облачным сервисам
Постоянно Автоматически Техническая Превентивная
09.11.2021
09.11.2021 1 3 / 40
Community
1 3 / 40
Обнаружение записи рабочей информации в некорпоративные облачные сервисы
По событию Автоматически Техническая
09.11.2021
09.11.2021 1 3 / 40
Community
1 3 / 12
Определение области (scope) действия систем и применения стандартов по информационной безопасности
Ежегодно Вручную Организационная
07.08.2021
07.08.2021 1 3 / 12
Community
3 11 / 76
Выделение периферийного оборудования и IP телефонов в отдельную сеть (сегментация сети)
Разово Вручную Техническая
29.07.2021
29.07.2021 3 11 / 76
Community
11 / 60
Проведение тестирования на проникновение
Ежеквартально Вручную Техническая Детективная
02.06.2021
02.06.2021 11 / 60