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

Приказ ФСТЭК России № 31 от 14.03.2014

Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления

ЗИС.6

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

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

ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
СМЭ.3
СМЭ.3 Межсетевое экранирование вычислительных сетей сегментов контуров безопасности, включая фильтрацию данных на сетевом и прикладном уровнях семиуровневой стандартной модели взаимодействия открытых систем, определенной в ГОСТ Р ИСО/МЭК 7498-1
3-Н 2-Т 1-Т
ЗСВ.15
ЗСВ.15 Организация информационного обмена между сегментами (группами сегментов) вычислительных сетей, определенных мерами ЗСВ.13 и ЗСВ.14 настоящей таблицы, физическим оборудованием (программно-аппаратным комплексом) и (или) программными средствами межсетевого экранирования, функционирующими на уровне гипервизора среды виртуализации
3-Н 2-Н 1-Т
NIST Cybersecurity Framework (RU):
ID.AM-3
ID.AM-3: В организации отображены коммуникации и потоки данных  
PR.PT-4
PR.PT-4: Защищены сети связи и управления 
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. 
CIS Critical Security Controls v7.1 (SANS Top 20):
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.
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 Сетевая безопасность
В целях защиты информации в системах и приложениях должны быть защищены, управляться и контролироваться сети и сетевые устройства.
NIST Cybersecurity Framework (EN):
PR.PT-4 PR.PT-4: Communications and control networks are protected
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":
А.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-файлов и соглашаетесь с Политикой обработки персональных данных.