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

ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022

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

A.17.1.3

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

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

ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 8. Требования к организации и управлению защитой информации":
КЗИ.6
КЗИ.6 Контроль безотказного функционирования технических средств, обнаружение и локализация отказов функционирования, принятие мер по восстановлению отказавших средств и их тестирование
3-О 2-Т 1-Т
Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения":
Р. 7 п. 3 п.п. 9
7.3.9. На стадии эксплуатации АБС должны быть определены, выполняться и регистрироваться процедуры:
  • контроля работоспособности (функционирования, эффективности) реализованных в АБС защитных мер, в том числе контроль реализации организационных защитных мер, контроль состава и параметров настройки применяемых технических защитных мер;
  • контроля отсутствия уязвимостей в оборудовании и программном обеспечении АБС;
  • контроля внесения изменений в параметры настройки АБС и применяемых технических защитных мер;
  • контроля необходимого обновления программного обеспечения АБС, включая программное обеспечение технических защитных мер.
NIST Cybersecurity Framework (RU):
DE.DP-3
DE.DP-3: Тестируются процессы обнаружения 
ID.SC-5
ID.SC-5: С критичными поставщиками проводится планирование, тестирование реагирования и восстановления 
PR.IP-9
PR.IP-9:  Созданы и управляются планы реагирования (реагирование на инциденты и непрерывность бизнеса) и планы восстановления (восстановление после инцидентов и аварийное  восстановление) 
PR.IP-10
PR.IP-10: Проверены планы реагирования и восстановления
PR.IP-4
PR.IP-4: Резервные копии данных создаются, хранятся и периодически проверяются 
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ОДТ.3 ОДТ.3 Контроль безотказного функционирования технических средств, обнаружение и локализация отказов функционирования, принятие мер по восстановлению отказавших средств и их тестирование
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
ТОН.6.2
ТОН.6.2 Тестирования возможности финансовой организации совместно с причастными сторонами обеспечить эффективное реагирование на инциденты и восстановление после их реализации в соответствии с заданными временными периодами (ЦВВ), в том числе в отношении переданных на аутсорсинг бизнес- и технологических процессов;
ТОН.6.1
ТОН.6.1 Тестирования возможности финансовой организации обеспечить эффективное реагирование на инциденты и восстановление после их реализации в соответствии с заданными временными периодами (ЦВВ);
ТОН.6.3
ТОН.6.3 Тестирования возможностей финансовой организации обеспечить эффективное взаимодействие с причастными сторонами при реализации инцидентов;
ТОН.6.4
ТОН.6.4 Тестирование возможности финансовой организации обеспечить своевременное информирование об инцидентах Банка России, федерального органа исполнительной власти, уполномоченного в области обеспечения функционирования государственной системы обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации, а также причастных сторон.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 1.2.7
1.2.7 
Defined Approach Requirements: 
Configurations of NSCs are reviewed at least once every six months to confirm they are relevant and effective. 

Customized Approach Objective:
NSC configurations that allow or restrict access to trusted networks are verified periodically to ensure that only authorized connections with a current business justification are permitted. 

Defined Approach Testing Procedures:
  • 1.2.7.a Examine documentation to verify procedures are defined for reviewing configurations of NSCs at least once every six months. 
  • 1.2.7.b Examine documentation of reviews of configurations for NSCs and interview responsible personnel to verify that reviews occur at least once every six months. 
  • 1.2.7.c Examine configurations for NSCs to verify that configurations identified as no longer being supported by a business justification are removed or updated. 
Purpose:
Such a review gives the organization an opportunity to clean up any unneeded, outdated, or incorrect rules and configurations which could be utilized by an unauthorized person. Furthermore, it ensures that all rules and configurations allow only authorized services, protocols, and ports that match the documented business justifications. 

Good Practice:
This review, which can be implemented using manual, automated, or system-based methods, is intended to confirm that the settings that manage traffic rules, what is allowed in and out of the network, match the approved configurations. 
The review should provide confirmation that all permitted access has a justified business reason. Any discrepancies or uncertainties about a rule or configuration should be escalated for resolution. 
While this requirement specifies that this review occur at least once every six months, organizations with a high volume of changes to their network configurations may wish to consider performing reviews more frequently to ensure that the configurations continue to meet the needs of the business. 
Guideline for a healthy information system v.2.0 (EN):
38 STANDARD
/STANDARD
Carrying out regular audits (at least once per year) of the information system is essential as this makes it possible to correctly assess the effectiveness of measures implemented and their maintenance over time. These controls and audits are also able to measure the gaps that may remain between the theory and the practice. 

They can be carried out by possible internal audit teams or by specialised external companies. Depending on the scope to test, technical and/or organisational audits will be carried out by the professionals called upon. These audits are especially necessary as the organization must comply with the regulations and legal obligations directly linked to its activities. 

Following these audits, corrective actions must be identified, their application planned and monitoring points organised at regular intervals. For higher efficiency, indicators on the state of progress of the action plan may be integrated into the overview for the management. 

Although security audits participate in the security of the information system by being able to show possible vulnerabilities, they are never proof of their absence and therefore do not negate the need for other control measures. 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 1.2.7
1.2.7
Определенные Требования к Подходу:
Конфигурации NSC пересматриваются не реже одного раза в шесть месяцев для подтвердждения их актуальности и эффективности.

Цель Индивидуального подхода:
Конфигурации NSC, которые разрешают или ограничивают доступ к доверенным сетям, периодически проверяются, чтобы гарантировать, что разрешены только авторизованные подключения с текущим бизнес-обоснованием.

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

Надлежащая практика:
Аудит, который может быть реализован с использованием ручных, автоматизированных или системных методов, предназначен для подтверждения того, что настройки соответствуют утвержденным конфигурациям. 
Проверка должна предоставить подтверждение того, что весь разрешенный доступ имеет обоснованную деловую причину. Любые расхождения или неопределенности в отношении правила или конфигурации должны быть определены для разрешения. 
Хотя в этом требовании указано, что такая проверка должна проводиться не реже одного раза в шесть месяцев, организации с большим объемом изменений в своих сетевых конфигурациях могут рассмотреть возможность проведения проверок чаще, чтобы убедиться, что конфигурации продолжают соответствовать потребностям бизнеса.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
ОДТ.3 ОДТ.3 Контроль безотказного функционирования технических средств, обнаружение и локализация отказов функционирования, принятие мер по восстановлению отказавших средств и их тестирование
Стандарт Банка России № СТО БР ИББС-1.4-2018 от 01.07.2018 "Управление риском нарушения информационной безопасности при аутсорсинге":
Р. 11 п. 5
11.5. Важной частью мониторинга и контроля риска нарушения ИБ при аутсорсинге существенных функций является прохождение поставщиком услуг регулярного аудита. 
Организация БС РФ должна обеспечить анализ результатов проведения периодического аудита с целью:
  • обновления (уточнения) перечня существенных функций, связанных с обработкой защищаемой инфор‑ мации или обеспечением ИБ, передаваемых на аутсорсинг поставщику услуг;
  • контроля надлежащего и своевременного предоставления поставщиком услуг отчетности в части аутсорсинга существенных функций;
  • оценки показателей качества деятельности поставщика услуг, определенных на основе показателей (метрик) управления риском нарушения ИБ;
  • соблюдения поставщиком услуг установленных соглашением параметров уровня и качества предоставления услуг в части обеспечения ИБ и создания условий непрерывности предоставления финансовых услуг (требований к SLA). 
Поставщик услуг должен проходить периодический аудит с целью подтверждения качества предостав‑ ления услуг в части: 
  • защиты информации в соответствии с требованием законодательства РФ; 
  • создания условий непрерывности предоставления финансовых услуг организации БС РФ.
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ОДТ.3 ОДТ.3 Контроль безотказного функционирования средств и систем
Положение Банка России № 757-П от 20.04.2021 "Об установлении обязательных для некредитных финансовых организаций требований к обеспечению защиты информации при осуществлении деятельности в сфере финансовых рынков в целях противодействия осуществлению незаконных финансовых операций":
1.5.3.
1.5.3. Оценка соответствия уровня защиты информации некредитными финансовыми организациями, реализующими усиленный уровень защиты информации, должна осуществляться не реже одного раза в год, некредитными финансовыми организациями, реализующими стандартный уровень защиты информации, - не реже одного раза в три года.
1.4.1.
1.4.1. Определение уровня защиты информации должно осуществляться некредитной финансовой организацией ежегодно не позднее десятого рабочего дня календарного года определения уровня защиты информации (далее - дата определения уровня защиты информации).
NIST Cybersecurity Framework (EN):
DE.DP-3 DE.DP-3: Detection processes are tested
PR.IP-9 PR.IP-9: Response plans (Incident Response and Business Continuity) and recovery plans (Incident Recovery and Disaster Recovery) are in place and managed
PR.IP-4 PR.IP-4: Backups of information are conducted, maintained, and tested
ID.SC-5 ID.SC-5: Response and recovery planning and testing are conducted with suppliers and third-party providers
PR.IP-10 PR.IP-10: Response and recovery plans are tested
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
17.1.3
17.1.3 Проверка, анализ и оценивание непрерывности информационной безопасности

Мера обеспечения ИБ
Организация должна регулярно проверять установленные и реализованные меры по обеспечению непрерывности ИБ, чтобы обеспечить уверенность в их актуальности и эффективности при возникновении неблагоприятных ситуаций.

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

Организации должны проверять непрерывность менеджмента ИБ путем:
  • a) осуществления и тестирования функциональности процессов, процедур и мер непрерывности ИБ для гарантии их соответствия целям обеспечения непрерывности ИБ;
  • b) осуществления и тестирования осведомленности и порядка управления процессами, процедурами и мерами непрерывности ИБ для гарантии того, что их выполнение соответствует целям обеспечения непрерывности ИБ;
  • c) анализа пригодности и эффективности мер непрерывности ИБ при изменении информационных систем, процессов, процедур и мер обеспечения ИБ или процессов и решений менеджмента непрерывности бизнеса/восстановления после аварий.

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

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

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

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