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

NIST Cybersecurity Framework (RU)

Framework

ID.AM-3

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

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

CIS Critical Security Controls v8 (The 18 CIS CSC):
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. 
ГОСТ Р № 57580.3-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Управление риском реализации информационных угроз и обеспечение операционной надежности. Общие положения.":
ОПР.2
ОПР.2 Реализация механизмов взаимодействия и координации деятельности* вовлеченных подразделений, формирующих «три линии защиты», а также причастных сторон (за исключением клиентов финансовой организации) в целях подготовки и реализации политики управления риском реализации информационных угроз.
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
ИКА.1.8
ИКА.1.8 Каналов передачи (информационных потоков) защищаемой информации***, обрабатываемой и передаваемой в рамках бизнес- и технологических процессов.
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC):
3.8
3.8 Документированы потоки информации
Документация также фиксирует процесс обмена информацией с сервис-провайдерами. 
Процесс пересматривается раз в год или чаще.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 1.2.4
1.2.4
Defined Approach Requirements: 
An accurate data-flow diagram(s) is maintained that meets the following: 
  • Shows all account data flows across systems and networks.
  • Updated as needed upon changes to the environment. 
Customized Approach Objective:
A representation of all transmissions of account data between system components and across network segments is maintained and available. 

Applicability Notes:
A data-flow diagram(s) or other technical or topological solution that identifies flows of account data across systems and networks can be used to meet this requirement. 

Defined Approach Testing Procedures:
  • 1.2.4.a Examine data-flow diagram(s) and interview personnel to verify the diagram(s) show all account data flows in accordance with all elements specified in this requirement. 1.2.4.b Examine documentation and interview responsible personnel to verify that the data-flow diagram(s) is accurate and updated when there are changes to the environment. 
Purpose:
An up-to-date, readily available data-flow diagram helps an organization understand and keep track of the scope of its environment by showing how account data flows across networks and between individual systems and devices. 
Maintaining an up-to-date data-flow diagram(s) prevents account data from being overlooked and unknowingly left unsecured. 

Good Practice:
The data-flow diagram should include all connection points where account data is received into and sent out of the network, including connections to open, public networks, application processing flows, storage, transmissions between systems and networks, and file backups. 
The data-flow diagram is meant to be in addition to the network diagram and should reconcile with and augment the network diagram. As a best practice, entities can consider including the following in their data-flow diagrams:
  • All processing flows of account data, including authorization, capture, settlement, chargeback, and refunds.
  • All distinct acceptance channels, including card-present, card-not-present, and ecommerce. • All types of data receipt or transmission, including any involving hard copy/paper media.
  • The flow of account data from the point where it enters the environment, to its final disposition.
  • Where account data is transmitted and processed, where it is stored, and whether storage is short term or long term. 
  • The source of all account data received (for example, customers, third party, etc.), and any entities with which account data is shared.
  • Date of last update, and names of people that made and approved the updates. 
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. 
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.13.2.2
A.13.2.2 Соглашения о передаче информации 
Мера обеспечения информационной безопасности: Безопасная передача деловой информации между организацией и внешними сторонами должна быть определена соглашениями 
A.13.2.1
A.13.2.1 Политики и процедуры передачи информации 
Мера обеспечения информационной безопасности: Должны существовать формализованные политики и процедуры передачи информации, а также соответствующие меры обеспечения информационной безопасности, обеспечивающие защиту информации, передаваемой с использованием всех видов средств связи 
CIS Critical Security Controls v7.1 (SANS Top 20):
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.
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.2.4
1.2.4
Определенные Требования к Подходу:
Поддерживается точная схема (схемы) потока (потоков) данных, отвечающая следующим требованиям:
  • Показывает все потоки данных учетной записи по системам и сетям.
  • Обновляется по мере необходимости при изменении окружения.
Цель Индивидуального подхода:
Осуществляется и выполнимо представление информации о любом обмене учетных данных между компонентами системы и между сегментами сети.

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

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

Надлежащая практика:
Схема потока данных должна включать все точки подключения, в которых данные учетной записи поступают в сеть и отправляются из нее, включая подключения к открытым, общедоступным сетям, потоки обработки приложений, хранение, передачи между системами и сетями и резервные копии файлов. 
Схема потока данных предназначена в дополнение к сетевой схеме и должна согласовываться с сетевой схемой и дополнять ее. В качестве наилучшей практики организации могут рассмотреть возможность включения в свои схемы потоков данных следующего:
  • Все потоки обработки данных учетной записи, включая авторизацию, сбор, расчеты, возврат средств и возврат средств.
  • Все различные каналы приема, включая предъявление карты, отсутствие карты и электронную коммерцию. * Все виды получения или передачи данных, включая любые, связанные с печатными копиями/бумажными носителями.
  • Поток данных учетной записи от момента, когда они попадают в среду, до их окончательного удаления.
  • Где передаются и обрабатываются данные учетной записи, где они хранятся и является ли хранение краткосрочным или долгосрочным.
  • Источник всех полученных данных учетной записи (например, клиенты, третья сторона и т.д.), а также любые организации, которым передаются данные учетной записи.
  • Дата последнего обновления и имена людей, которые внесли и одобрили обновления.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.5.14
А.5.14 Передача информации
Для всех видов средств передачи информации внутри организации и между организацией и другими сторонами должны действовать правила, процедуры или соглашения по передаче информации.
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ЗИС.6 ЗИС.6 Управление сетевыми потоками
NIST Cybersecurity Framework (EN):
ID.AM-3 ID.AM-3: Organizational communication and data flows are mapped
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
ЗИС.6 ЗИС.6 Управление сетевыми потоками
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.5.14
А.5.14 Information transfer
Information transfer rules, procedures, or agreements shall be in place for all types of transfer facilities within the organization and between the organization and other parties.
Положение Банка России № 716-П от 08.04.2022 "О требованиях к системе управления операционным риском в кредитной организации и банковской группе":
Глава 8. Пункт 5.
8.5. Кредитная организация (головная кредитная организация банковской группы) описывает во внутренних документах архитектуру информационных систем и состав ее элементов, в том числе с учетом оценки влияния на них третьих лиц (внешних подрядчиков, контрагентов, участников банковской группы):
  • информационных систем кредитной организации (головной кредитной организации банковской группы) с соотнесением их элементов с процессами в соответствии с подпунктом 4.1.1 пункта 4.1 настоящего Положения, выполнение которых они обеспечивают;
  • структуры информационного обмена между элементами информационных систем, используемых при обеспечении процессов кредитной организации (головной кредитной организации банковской группы);
  • информационных систем третьих лиц (внешних подрядчиков, контрагентов, участников банковской группы) и их элементов, обеспечивающих процессы кредитной организации (головной кредитной организации банковской группы), и структуры информационного обмена между их элементами и элементами других информационных систем кредитной организации (головной кредитной организации банковской группы). Кредитная организация (головная кредитная организация банковской группы) в случае отсутствия информации об информационных системах третьих лиц (внешних подрядчиков, контрагентов, участников банковской группы) документирует причины и учитывает отсутствие указанной информации при оценке уровня риска информационных систем, в том числе в соответствии с абзацами седьмым и восьмым подпункта 8.7.2 пункта 8.7 настоящего Положения;
  • подразделений и работников подразделений кредитной организации (головной кредитной организации банковской группы) и (или) третьих лиц (внешних подрядчиков, контрагентов, участников банковской группы), являющихся пользователями и (или) обеспечивающих функционирование информационных систем. (Пункт в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)

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

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