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

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

7.6.2. Должны быть определены, выполняться, регистрироваться и контролироваться процедуры подключения и использования ресурсов сети Интернет.

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

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 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 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 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 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 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 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 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 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 Collect Network Traffic Flow Logs
Collect network traffic flow logs and/or network traffic to review and alert upon from network devices. 

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 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 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 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 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 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 Block Unnecessary File Types 
Block unnecessary file types attempting to enter the enterprise’s email gateway. 

13.4 Perform Traffic Filtering Between Network Segments 
Perform traffic filtering between network segments, where appropriate. 

ВСА.4 Контроль отсутствия (выявление) аномальной сетевой активности, связанной с возможным несанкционированным логическим доступом к ресурсам доступа, размещенным в вычислительных сетях финансовой организации, подключенных к сети Интернет

СМЭ.2 Реализация сетевого взаимодействия и сетевой изоляции на уровне не выше третьего (сетевой) по семиуровневой стандартной модели взаимодействия открытых систем, определенной в ГОСТ Р ИСО/МЭК 7498-1, сегментов контуров безопасности и внутренних вычислительных сетей финансовой организации, не предназначенных для размещения информационной инфраструктуры, входящей в контуры безопасности (далее — иные внутренние вычислительные сети финансовой организации)

СМЭ.15 Реализация сетевого взаимодействия и сетевой изоляции на уровне не выше третьего (сетевой) по семиуровневой стандартной модели взаимодействия открытых систем, определенной в ГОСТ Р ИСО/МЭК 7498-1, внутренних вычислительных сетей финансовой организации и сети Интернет

СМЭ.19 Реализация сетевого взаимодействия внутренних вычислительных сетей финансовой организации и сети Интернет через ограниченное количество контролируемых точек доступа

ВСА.6 Контроль отсутствия (выявление) аномальной сетевой активности, связанной с возможным несанкционированным логическим доступом к ресурсам доступа, размещенным во внутренних вычислительных сетях финансовой организации

ВСА.2 Контроль отсутствия (выявление) аномальной сетевой активности, связанной с возможным несанкционированным информационным взаимодействием между вычислительными сетями финансовой организации и сетью Интернет

СМЭ.14 Реализация сетевого взаимодействия и сетевой изоляции на уровне не выше второго (канальный) по семиуровневой стандартной модели взаимодействия открытых систем, определенной в ГОСТ Р ИСО/МЭК 7498-1, внутренних вычислительных сетей финансовой организации и сети Интернет

ЗСВ.4 Разграничение и контроль осуществления одновременного доступа виртуальных машин к системе хранения данных в пределах контура безопасности на уровне не выше третьего (сетевой) по семиуровневой стандартной модели взаимодействия открытых систем, определенной в ГОСТ Р ИСО/МЭК 7498-1

ЗБС.4 Реализация сетевого взаимодействия и сетевой изоляции на уровне не выше второго (канальный) по семиуровневой стандартной модели взаимодействия открытых систем, определенной в ГОСТ Р ИСО/МЭК 7498-1, внутренних вычислительных сетей финансовой организации и сегментов вычисленных сетей, выделенных в соответствии с пунктом ЗБС.3 настоящей таблицы

ВСА.3 Контроль отсутствия (выявление) аномальной сетевой активности, связанной с возможным несанкционированным информационным взаимодействием между сегментами, предназначенными для размещения общедоступных объектов доступа (в том числе банкоматов, платежных терминалов), и сетью Интернет

ВСА.1 Контроль отсутствия (выявление) аномальной сетевой активности, связанной с возможным несанкционированным информационным взаимодействием между сегментами контуров безопасности и иными внутренними вычислительными сетями финансовой организации

PR.DS-5:  Реализована защита от утечки данных

PR.DS-2: Данные при передаче защищаются  

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

PR.PT-4: Защищены сети связи и управления 

PR.AC-3: Управляется процесс предоставления удаленного доступа

PR.AC-5: Защищена целостность сети, включая сегрегацию сети при необходимости

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:

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:

Diagrams should be updated by authorized personnel to ensure diagrams continue to provide an accurate description of the network. 

1.4.2 
Defined Approach Requirements: 
Inbound traffic from untrusted networks to trusted networks is restricted to: 

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:

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. 

1.3.2 
Defined Approach Requirements: 
Outbound traffic from the CDE is restricted as follows:

Customized Approach Objective:
Unauthorized traffic cannot leave the CDE. 

Defined Approach Testing Procedures:

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. 

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:

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:

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:

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. 

1.3.1 
Defined Approach Requirements: 
Inbound traffic to the CDE is restricted as follows:

Customized Approach Objective:
Unauthorized traffic cannot enter the CDE. 

Defined Approach Testing Procedures:

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. 

12.5.2
Определенные Требования к Подходу:
Область применения PCI DSS документируется и подтверждается организацией не реже одного раза в 12 месяцев и при значительных изменениях в среде, относящейся к сфере применения. Как минимум, проверка области действия включает в себя:

Цель Индивидуального подхода:
Область применения PCI DSS периодически проверяется и после внесения существенных изменений путем всестороннего анализа и принятия соответствующих технических мер.
Примечания по применению:
Это ежегодное подтверждение области применения 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 и сегментации сети.

1.4.2
Определенные Требования к Подходу:

Входящий трафик из ненадежных сетей в доверенные сети ограничен:

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

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

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

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

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

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

1.2.3
Определенные Требования к Подходу:
Поддерживается точная сетевая схема (схемы), которая показывает все соединения между CDE и другими сетями, включая любые беспроводные сети.

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

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

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

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

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

Схемы должны обновляться уполномоченным персоналом, чтобы гарантировать, что схемы по-прежнему дают точное описание сети.

1.3.1
Определенные Требования к Подходу:
Входящий трафик в CDE ограничен следующим образом:

Цель Индивидуального подхода:
Несанкционированный трафик не может попасть в CDE.

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

Цель:
Это требование направлено на предотвращение доступа злоумышленников к сети организации через несанкционированные IP-адреса или несанкционированного использования служб, протоколов или портов.

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

Примеры:
Реализация правила, запрещающего весь входящий и исходящий трафик, который специально не требуется — например, с помощью явного “запретить все” или неявного запрета после инструкции allow — помогает предотвратить непреднамеренные ошибки, которые допускают непреднамеренный и потенциально вредоносный трафик.

1.3.2
Определенные Требования к Подходу:

Исходящий трафик из CDE ограничен следующим образом:

Цель Индивидуального подхода:
Несанкционированный трафик не может покинуть CDE.

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

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

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

Примеры:
Реализация правила, запрещающего весь входящий и исходящий трафик, который специально не требуется — например, с помощью явного “запретить все” или неявного запрета после инструкции allow — помогает предотвратить непреднамеренные ошибки, которые допускают непреднамеренный и потенциально вредносный трафик.

А.8.20 Сетевая безопасность
В целях защиты информации в системах и приложениях должны быть защищены, управляться и контролироваться сети и сетевые устройства.

А.8.20 Networks security
Networks and network devices shall be secured, managed and controlled to protect information in systems and applications.