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

NIST Cybersecurity Framework (EN)

Framework

RS.AN-5

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

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

Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 6. п.п. 2
6.2. Кредитные организации должны обеспечивать выполнение следующих требований к управлению изменениями критичной архитектуры:
  • управление уязвимостями в критичной архитектуре, из-за которых могут реализоваться информационные угрозы и которые могут повлечь превышение значений целевых показателей операционной надежности;
  • планирование и внедрение изменений в критичной архитектуре, направленных на обеспечение недопустимости неоказания или ненадлежащего оказания банковских услуг;
  • управление конфигурациями (настраиваемыми параметрами) объектов информационной инфраструктуры;
  • управление уязвимостями и обновлениями (исправлениями) объектов информационной инфраструктуры.
ГОСТ Р № 22301 от 01.01.2022 "Надежность в технике. Системы менеджмента непрерывности деятельности. Требования":
Р. 8 п. 3 пп. 3
 8.3.3 Выбор стратегий и решений 
Выбор стратегий и решений должен быть основан на уровне их полезности: 
  • а) при выполнении требований к продолжению и восстановлению приоритетных видов деятельности в установленные сроки и на уровне согласованного объема производства; 
  • b) проведении анализа величины и вида риска, который организация может или не может принять; 
  • с) рассмотрении связанных с этим затрат и преимуществ. 
Р. 8 п. 3 пп. 1
 8.3.1 Общие положения 
На основе результатов анализа воздействий на деятельность и оценки риска организация должна идентифицировать и выбрать стратегии обеспечения непрерывности деятельности, позволяющие рассматривать варианты стратегий до, во время и после нарушения деятельности организации. Стратегии обеспечения непрерывности деятельности могут охватывать одно или несколько решений. 
Р. 7 п. 5 пп. 2
 7.5.2 Создание и актуализация 
При создании и обновлении документированной информации организация должна обеспечить соответствующие: 
  • а) идентификацию и описание (например, наименование, дата, разработчик или номер для ссылки); 
  • b) формат (например, язык, версия программного обеспечения, графика) и носитель (например, бумажный, электронный); 
  • с) рассмотрение и утверждение пригодности и адекватности. 
Р. 4 п. 3 пп. 1
 4.3.1 Общие положения 
Организация должна определить границы и применимость СМНД для установления ее области применения. 
При установлении области определения СМНД организация должна учитывать: 
  • а) внешние и внутренние проблемы, указанные в 4.1; 
  • b) требования, указанные в 4.2; 
  • с) назначение, цели, а также внутренние и внешние обязательства организации. 
Область применения СМНД организации должна быть документирована и доступна. 
Р. 8 п. 5
 8.5 Программа учений 
Организация должна разработать и поддерживать программу обучения и тестирования, чтобы со временем подтвердить результативность своих стратегий и решений по обеспечению непрерывности деятельности. Организации необходимо проводить обучение и тестирование, которые должны: 
  • а) соответствовать целям обеспечения непрерывности деятельности; 
  • b) основываться на соответствующих сценариях, согласованных с установленными целями и задачами; 
  • с) развивать командную работу, компетентность, уверенность и знания сотрудников, выполняющих функции, связанные с нарушениями деятельности организации; 
  • d) (вместе взятые) проверять стратегии и решения организации по обеспечению непрерывности деятельности; 
  • е) готовить официальные отчеты об учениях, содержащие результаты, рекомендации и действия по реализации улучшений; 
  • f) обеспечивать анализ со стороны руководства для содействия постоянному улучшению; 
  • g) выполнять через запланированные интервалы времени и при значительных изменениях в организации или области применения, в которой она работает. 
 Организация должна действовать исходя из результатов проверок и тестирования для внесения изменений и улучшений. 
Р. 8 п. 2 пп. 2
 8.2.2 Анализ воздействий на деятельность 
Организация должна использовать процесс анализа воздействий на деятельность для определения приоритетов и требований к обеспечению непрерывности деятельности. 
Процесс должен: 
  • а) определить виды воздействий и критерии, соответствующие области применения и специфике организации; 
  • b) определить виды деятельности, которые поддерживают производство продукции и оказание услуг; 
  • с) использовать типы и критерии воздействий для оценки воздействий, происходящих в результате нарушения деятельности организации в этих видах деятельности; 
  • d) определить продолжительность времени, в течение которого невозобновление деятельности становится неприемлемым для организации; 
Примечание 1 — Данный период времени можно назвать «максимально допустимым периодом прерывания деятельности».
 
  • е) установить предпочтительную продолжительность времени, указанного в d), для возобновления прерванной деятельности, установленным минимально приемлемым объемом производства продукции; 
Примечание 2 — Такой временной интервал можно назвать «целевой продолжительностью восстановления».
 
  • f) использовать данный анализ для определения приоритетных видов деятельности; 
  • д) определить ресурсы, необходимы для поддержки приоритетных видов деятельности; 
  • h) определить виды зависимости, в том числе от партнеров и поставщиков, а также взаимозависимости. связанные с приоритетными видами деятельности. 
Р. 8 п. 1
 8.1 Оперативное планирование и управление 
Организация должна планировать, выполнять и контролировать процессы, необходимые для выполнения требований и осуществления действий, определенных в 6.1: 
  • а) путем установления критериев состояния процессов;
  • b) осуществления контроля и управления процессами в соответствии с критериями; 
  • с) хранения документированной информации в объеме, необходимом для уверенности в том. что процессы выполнены в соответствии с планом. 
Организация должна управлять запланированными изменениями и анализировать последствия непреднамеренных изменений, принимая меры для смягчения всех неблагоприятных последствий, при необходимости. Организация должна обеспечить управление процессами аутсорсинга и цепочкой поставок. 
NIST Cybersecurity Framework (RU):
RS.AN-5
RS.AN-5: Установлены процессы для получения, анализа и реагирования на уязвимости организации обнаруженные с помощью анализа внутренних и внешних источников (например, внутреннее тестирование, бюллетени по безопасности или исследователи безопасности).
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
УИ.22.1
УИ.22.1 Реализации бизнес- и технологических процессов;
УИ.31
УИ.31 Проведение анализа системных журналов для выявления фактов эксплуатации в прошлом уязвимостей, аналогичных вновь выявленным.
УИ.22.3
УИ.22.3 Объектам информатизации инфраструктурного уровня.
УИ.22.2
УИ.22.2 Объектам информатизации прикладного уровня;
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 11.3.1
11.3.1
Defined Approach Requirements: 
Internal vulnerability scans are performed as follows:
  • At least once every three months. 
  • High-risk and critical vulnerabilities (per the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved. 
  • Rescans are performed that confirm all highrisk and critical vulnerabilities (as noted above) have been resolved. 
  • Scan tool is kept up to date with latest vulnerability information. 
  • Scans are performed by qualified personnel and organizational independence of the tester exists. 
Customized Approach Objective:
The security posture of all system components is verified periodically using automated tools designed to detect vulnerabilities operating inside the network. Detected vulnerabilities are assessed and rectified based on a formal risk assessment framework 

Applicability Notes:
It is not required to use a QSA or ASV to conduct internal vulnerability scans. 
Internal vulnerability scans can be performed by qualified, internal staff that are reasonably independent of the system component(s) being scanned (for example, a network administrator should not be responsible for scanning the network), or an entity may choose to have internal vulnerability scans performed by a firm specializing in vulnerability scanning. 

Defined Approach Testing Procedures:
  • 11.3.1.a Examine internal scan report results from the last 12 months to verify that internal scans occurred at least once every three months in the most recent 12-month period. 
  • 11.3.1.b Examine internal scan report results from each scan and rescan run in the last 12 months to verify that all high-risk and critical vulnerabilities (identified in PCI DSS Requirement 6.3.1) are resolved. 
  • 11.3.1.c Examine scan tool configurations and interview personnel to verify that the scan tool is kept up to date with the latest vulnerability information. 
  • 11.3.1.d Interview responsible personnel to verify that the scan was performed by a qualified internal resource(s) or qualified external third party and that organizational independence of the tester exists. 
Purpose:
Identifying and addressing vulnerabilities promptly reduces the likelihood of a vulnerability being exploited and the potential compromise of a system component or cardholder data. Vulnerability scans conducted at least every three months provide this detection and identification. 

Good Practice:
Vulnerabilities posing the greatest risk to the environment (for example, ranked high or critical per Requirement 6.3.1) should be resolved with the highest priority. 
Multiple scan reports can be combined for the quarterly scan process to show that all systems were scanned and all applicable vulnerabilities were resolved as part of the three-month vulnerability scan cycle. However, additional, documentation may be required to verify nonremediated vulnerabilities are in the process of being resolved. 
While scans are required at least once every three months, more frequent scans are recommended depending on the network complexity, frequency of change, and types of devices, software, and operating systems used. 

Definitions: 
A vulnerability scan is a combination of automated tools, techniques, and/or methods run against external and internal devices and servers, designed to expose potential vulnerabilities in applications, operating systems, and network devices that could be found and exploited by malicious individuals. 
Requirement 2.2.1
2.2.1 
Defined Approach Requirements: 
Configuration standards are developed, implemented, and maintained to:
  • Cover all system components.
  • Address all known security vulnerabilities.
  • Be consistent with industry-accepted system hardening standards or vendor hardening recommendations.
  • Be updated as new vulnerability issues are identified, as defined in Requirement 6.3.1.
  • Be applied when new systems are configured and verified as in place before or immediately after a system component is connected to a production environment. 
Customized Approach Objective:
All system components are configured securely and consistently and in accordance with industryaccepted hardening standards or vendor recommendations. 

Defined Approach Testing Procedures:
  •  2.2.1.a Examine system configuration standards to verify they define processes that include all elements specified in this requirement. 
  • 2.2.1.b Examine policies and procedures and interview personnel to verify that system configuration standards are updated as new vulnerability issues are identified, as defined in Requirement 6.3.1. 
  • 2.2.1.c Examine configuration settings and interview personnel to verify that system configuration standards are applied when new systems are configured and verified as being in place before or immediately after a system component is connected to a production environment. 
Purpose:
There are known weaknesses with many operating systems, databases, network devices, software, applications, container images, and other devices used by an entity or within an entity’s environment. There are also known ways to configure these system components to fix security vulnerabilities. Fixing security vulnerabilities reduces the opportunities available to an attacker. 
By developing standards, entities ensure their system components will be configured consistently and securely, and address the protection of devices for which full hardening may be more difficult. 

Good Practice:
Keeping up to date with current industry guidance will help the entity maintain secure configurations. 
The specific controls to be applied to a system will vary and should be appropriate for the type and function of the system. 
Numerous security organizations have established system-hardening guidelines and recommendations, which advise how to correct common, known weaknesses. 

Further:
Information Sources for guidance on configuration standards include but are not limited to: Center for Internet Security (CIS), International Organization for Standardization (ISO), National Institute of Standards and Technology (NIST), Cloud Security Alliance, and product vendors. 

ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.18.2.2
A.18.2.2 Соответствие политикам и стандартам безопасности 
Мера обеспечения информационной безопасности: Руководители, в пределах своей зоны ответственности, должны регулярно проверять соответствие процессов и процедур обработки информации соответствующим политикам безопасности, стандартам и другим требованиям безопасности 
A.18.2.3
A.18.2.3 Анализ технического соответствия 
Мера обеспечения информационной безопасности: Информационные системы должны регулярно проверяться на предмет соответствия стандартам и политикам информационной безопасности организации 
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 3.6 CSC 3.6 Compare Back-to-Back Vulnerability Scans
Regularly compare the results from consecutive vulnerability scans to verify that vulnerabilities have been remediated in a timely manner.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 2.2.1
2.2.1
Определенные Требования к Подходу:
Стандарты конфигурации разрабатываются, внедряются и поддерживаются в соответствии с рекомендациями:
  • Охватите все компоненты системы.
  • Устраните все известные уязвимости в системе безопасности.
  • Должны соответствовать принятым в отрасли стандартам упрочнения систем или рекомендациям поставщиков по настройке.
  • Обновляться по мере выявления новых уязвимостей, как определено в требовании 6.3.1.
  • Может применяться при настройке и проверке работоспособности новых систем до или сразу после подключения системного компонента к производственной среде.
Цель Индивидуального подхода:
Все компоненты системы сконфигурированы надежно и последовательно в соответствии с принятыми в отрасли стандартами безопасности или рекомендациями поставщиков.

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

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

Дополнительная информация:
Источники информации для руководства по стандартам конфигурации включают, но не ограничиваются ими: Центр безопасности Интернета (CIS), Международная организация по стандартизации (ISO), Национальный институт стандартов и технологий (NIST), Альянс облачной безопасности и поставщики продуктов.
Strategies to Mitigate Cyber Security Incidents (EN):
3.4.
Hunt to discover incidents based on knowledge of adversary tradecraft. Leverage threat intelligence consisting of analysed threat data with context enabling mitigating action, not just indicators of compromise.
Relative Security Effectiveness:  Very Good | Potential User Resistance:  Low | Upfront Cost:  Very High | Ongoing Maintenance Cost: Very High
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.5.36
А.5.36 Соответствие политикам, правилам и стандартам по ИБ
Должно регулярно проверяться соответствие принятым в организации Политике ИБ, специфическим тематическим политикам, правилам и стандартам в области ИБ.
SWIFT Customer Security Controls Framework v2022:
2 - 2.2 Security Updates
2.2 Security Updates
2 - 2.7 Vulnerability Scanning
2.7 Vulnerability Scanning 
7 - 7.3A Penetration Testing
7.3A Penetration Testing
Положение Банка России № 808-П от 17.10.2022 "О требованиях к обеспечению защиты информации при осуществлении деятельности в сфере оказания профессиональных услуг на финансовом рынке в целях противодействия осуществлению незаконных финансовых операций":
Глава 2 Пункт 3
2.3. Бюро кредитных историй должны осуществлять ежегодное тестирование объектов информационной инфраструктуры, обрабатывающих защищаемую информацию при приеме электронных сообщений, содержащих защищаемую информацию (далее - электронные сообщения), субъектов кредитных историй, в автоматизированных системах и приложениях с использованием информационно-телекоммуникационной сети "Интернет" (далее - сеть "Интернет"), а также на официальном сайте бюро кредитных историй в сети "Интернет" на предмет проникновений и анализ уязвимостей информационной безопасности объектов информационной инфраструктуры.

Бюро кредитных историй вправе установить во внутренних документах форму результатов ежегодного тестирования объектов информационной инфраструктуры.
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
АУД.11 АУД.11 Проведение внешних аудитов
АУД.10 АУД.10 Проведение внутренних аудитов
Положение Банка России № 779-П от 15.11.2021 "Обязательные для некредитных финансовых организаций требований к операционной надежности при осуществлении видов деятельности, предусмотренных частью первой статьи 76.1 Федерального закона от 10 июля 2002 года N 86-ФЗ "О Центральном банке"":
п. 1.5.
1.5. Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, в рамках обеспечения операционной надежности должны обеспечивать выполнение следующих требований в отношении управления изменениями критичной архитектуры:
  • управление уязвимостями в критичной архитектуре, с использованием которых могут реализоваться информационные угрозы и которые могут повлечь отклонение от значений целевых показателей операционной надежности, указанных в пункте 1.3 настоящего Положения;
  • планирование и внедрение изменений в критичной архитектуре, направленных на обеспечение непрерывного оказания финансовых услуг;
  • управление конфигурациями объектов информационной инфраструктуры некредитных финансовых организаций;
  • управление уязвимостями и обновлениями (исправлениями) объектов информационной инфраструктуры некредитных финансовых организаций.
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
АУД.11 АУД.11 Проведение внешних аудитов
АУД.10 АУД.10 Проведение внутренних аудитов
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.5.36
А.5.36 Compliance with policies, rules and standards for information security
Compliance with the organization’s information security policy, topic-specific policies, rules and standards shall be regularly reviewed.

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

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