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

CIS Critical Security Controls v7.1 (SANS Top 20)

Framework

CSC 11.2

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

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

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. 
NIST Cybersecurity Framework (RU):
ID.AM-3
ID.AM-3: В организации отображены коммуникации и потоки данных  
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
УКФ.1 УКФ.1 Определение лиц, которым разрешены действия по внесению изменений в конфигурацию информационной системы и системы защиты персональных данных
УКФ.2 УКФ.2 Управление изменениями конфигурации информационной системы и системы защиты персональных данных
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 1.2.5
1.2.5 
Defined Approach Requirements: 
 All services, protocols, and ports allowed are identified, approved, and have a defined business need. 

Customized Approach Objective:
 Unauthorized network traffic (services, protocols, or packets destined for specific ports) cannot enter or leave the network. 

Defined Approach Testing Procedures:
  • 1.2.5.a Examine documentation to verify that a list exists of all allowed services, protocols, and ports, including business justification and approval for each. 
  • 1.2.5.b Examine configuration settings for NSCs to verify that only approved services, protocols, and ports are in use. 
Purpose:
Compromises often happen due to unused or insecure services (for example, telnet and FTP), protocols, and ports, since these can lead to unnecessary points of access being opened into the CDE. Additionally, services, protocols, and ports that are enabled but not in use are often overlooked and left unsecured and unpatched. By identifying the services, protocols, and ports necessary for business, entities can ensure that all other services, protocols, and ports are disabled or removed. 

Good Practice:
The security risk associated with each service, protocol, and port allowed should be understood. Approvals should be granted by personnel independent of those managing the configuration. Approving personnel should possess knowledge and accountability appropriate for making approval decisions. 
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.13.1.1
A.13.1.1 Меры обеспечения информационной безопасности для сетей 
Мера обеспечения информационной безопасности: Сети должны управляться и контролироваться для обеспечения защиты информации систем и приложений 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 1.2.4
1.2.4
Определенные Требования к Подходу:
Поддерживается точная схема (схемы) потока (потоков) данных, отвечающая следующим требованиям:
  • Показывает все потоки данных учетной записи по системам и сетям.
  • Обновляется по мере необходимости при изменении окружения.
Цель Индивидуального подхода:
Осуществляется и выполнимо представление информации о любом обмене учетных данных между компонентами системы и между сегментами сети.

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

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

Надлежащая практика:
Схема потока данных должна включать все точки подключения, в которых данные учетной записи поступают в сеть и отправляются из нее, включая подключения к открытым, общедоступным сетям, потоки обработки приложений, хранение, передачи между системами и сетями и резервные копии файлов. 
Схема потока данных предназначена в дополнение к сетевой схеме и должна согласовываться с сетевой схемой и дополнять ее. В качестве наилучшей практики организации могут рассмотреть возможность включения в свои схемы потоков данных следующего:
  • Все потоки обработки данных учетной записи, включая авторизацию, сбор, расчеты, возврат средств и возврат средств.
  • Все различные каналы приема, включая предъявление карты, отсутствие карты и электронную коммерцию. * Все виды получения или передачи данных, включая любые, связанные с печатными копиями/бумажными носителями.
  • Поток данных учетной записи от момента, когда они попадают в среду, до их окончательного удаления.
  • Где передаются и обрабатываются данные учетной записи, где они хранятся и является ли хранение краткосрочным или долгосрочным.
  • Источник всех полученных данных учетной записи (например, клиенты, третья сторона и т.д.), а также любые организации, которым передаются данные учетной записи.
  • Дата последнего обновления и имена людей, которые внесли и одобрили обновления.
Requirement 1.2.5
1.2.5
Определенные Требования к Подходу:
Все разрешенные службы, протоколы и порты идентифицированы, одобрены и соответствуют определенным бизнес-потребностям.

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

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

Надлежащая практика:
Следует понимать риск связанный с каждой разрешенной службой, протоколом и портом. Подтверждения о разрешении должны предоставляться персоналом, независимым от тех, кто управляет конфигурацией. Подтверждающий персонал должен обладать знаниями и ответственностью, необходимыми для принятия решений об утверждении.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.20
А.8.20 Сетевая безопасность
В целях защиты информации в системах и приложениях должны быть защищены, управляться и контролироваться сети и сетевые устройства.
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
УКФ.2 УКФ.2 Управление изменениями
NIST Cybersecurity Framework (EN):
ID.AM-3 ID.AM-3: Organizational communication and data flows are mapped
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
УКФ.2 УКФ.2 Управление изменениями
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
13.1.1
13.1.1 Меры обеспечения информационной безопасности сетей

Мера обеспечения ИБ
Сети должны управляться и контролироваться для обеспечения защиты информации в системах и приложениях.

Руководство по применению
Должны быть реализованы меры для обеспечения безопасности информации в сетях и защиты подключенных сервисов от несанкционированного доступа. В частности, следует учитывать следующее:
  • a) должны быть установлены обязанности и процедуры для управления сетевым оборудованием;
  • b) там, где это применимо, обязанности по эксплуатации сетей должны быть отделены от обязанностей по эксплуатации компьютеров (см. 6.1.2);
  • c) должны быть установлены специальные меры обеспечения ИБ для защиты конфиденциальности и целостности данных, передаваемых по сетям общего пользования или беспроводным сетям, и для защиты подключенных систем и приложений (раздел 10 и 13.2); могут потребоваться специальные меры для обеспечения доступности сетевых сервисов и подключенных компьютеров;
  • d) должна вестись соответствующая регистрация и мониторинг с целью фиксации и обнаружения действий, которые могут повлиять на ИБ или имеют отношение к ней;
  • e) действия по управлению должны быть тесно координированы как для того, чтобы оптимизировать обслуживание организации, так и для обеспечения того, чтобы меры обеспечения безопасности применялись согласованно в рамках всей инфраструктуры обработки информации;
  • f) системы в сетях должны проходить процедуру аутентификации;
  • g) подключение систем к сети должно быть ограничено.

Дополнительная информация
Дополнительную информацию о сетевой безопасности можно найти в ИСО/МЭК 27033 [15], [16], [17], [18], [19].
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.8.20
А.8.20 Networks security
Networks and network devices shall be secured, managed and controlled to protect information in systems and applications.

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

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

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