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

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

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

A.17.1.2

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

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

ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 8":
ПОН.1
ПОН.1 Документарное определение области применения процесса системы обеспечения операционной надежности в отношении идентифицированных элементов критичной архитектуры.
Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения":
Р. 8 п. 11 п.п. 3
8.11.3. Должен быть определен план обеспечения непрерывности бизнеса и его восстановления после возможного прерывания. План должен содержать инструкции и порядок действий работников организации БС РФ по восстановлению бизнеса. В частности, в состав плана должны быть включены:
  • условия активации плана;
  • действия, которые должны быть предприняты после инцидента ИБ;
  • процедуры восстановления;
  • процедуры тестирования и проверки плана;
  • план обучения и повышения осведомленности работников организации БС РФ;
  • обязанности работников организации с указанием ответственных за выполнение каждого из положений плана. 
Р. 8 п. 11 п.п. 6
8.11.6. План обеспечения непрерывности бизнеса и его восстановления после прерывания должен быть согласован с существующими в организации процедурами обработки инцидентов ИБ. 
Р. 8 п. 11 п.п. 1
8.11.1. Должны быть определены, выполняться, регистрироваться и контролироваться процедуры учета информационных активов или типов информационных активов, существенных для обеспечения непрерывности бизнеса организации БС РФ. 
Р. 8 п. 11 п.п. 8
8.11.8. В организации БС РФ должна быть реализована программа обучения и повышения осведомленности работников в области обеспечения непрерывности бизнеса и его восстановления после прерываний. 
Р. 8 п. 11 п.п. 5
8.11.5. В организации БС РФ должны применяться защитные меры обеспечения непрерывности бизнеса применительно к информационным активам, существенным для обеспечения непрерывности бизнеса и его восстановления после прерывания. 
Применение защитных мер обеспечения непрерывности бизнеса и его восстановления после прерывания должно основываться на соответствующих требованиях по обеспечению ИБ. 
ГОСТ Р № 57580.3-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Управление риском реализации информационных угроз и обеспечение операционной надежности. Общие положения.":
ОПР.1.5
ОПР.1.5 Порядок утверждения и условия пересмотра структуры и организации систем управления риском реализации информационных угроз, операционной надежности и защиты информации.
Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 2
2. Кредитные организации в рамках обеспечения операционной надежности должны обеспечить непревышение значения порогового уровня допустимого времени простоя и (или) нарушения технологических процессов, обеспечивающих выполнение критически важных процессов и указанных в приложении к настоящему Положению (далее - технологические процессы), приводящих к неоказанию или ненадлежащему оказанию банковских услуг (далее - пороговый уровень допустимого времени простоя и (или) деградации технологических процессов кредитных организаций), предусмотренного приложением к настоящему Положению.
NIST Cybersecurity Framework (RU):
ID.BE-5
ID.BE-5: Установлены требования к устойчивости для поддержки предоставления критически важных услуг для всех состояний функционирования (например, при атаке, во время восстановления, во время нормального функционирования) 
PR.PT-5
PR.PT-5:  Для достижения доступности системы работают в заранее определенных функциональных состояниях (например, под нагрузкой, под атакой, во время восстановления, в нормальных условиях). 
PR.IP-9
PR.IP-9:  Созданы и управляются планы реагирования (реагирование на инциденты и непрерывность бизнеса) и планы восстановления (восстановление после инцидентов и аварийное  восстановление) 
PR.IP-4
PR.IP-4: Резервные копии данных создаются, хранятся и периодически проверяются 
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
ВПУ.2
ВПУ.2 Разработка и применение процедур реагирования в случае реализации информационных угроз, в том числе компьютерных атак со стороны поставщиков услуг, а также в случае идентификации риска распространения вредоносного кода на вычислительные сети финансовой организации*.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 12.10.2
12.10.2
Defined Approach Requirements: 
At least once every 12 months, the security incident response plan is:
  • Reviewed and the content is updated as needed.
  • Tested, including all elements listed in Requirement 12.10.1. 
Customized Approach Objective:
The incident response plan is kept current and tested periodically. 

Defined Approach Testing Procedures:
  • 12.10.2 Interview personnel and review documentation to verify that, at least once every 12 months, the security incident response plan is:
    • Reviewed and updated as needed. 
    • Tested, including all elements listed in Requirement 12.10.1. 
Purpose:
Proper testing of the security incident response plan can identify broken business processes and ensure key steps are not missed, which could result in increased exposure during an incident. Periodic testing of the plan ensures that the processes remain viable, as well as ensuring that all relevant personnel in the organization are familiar with the plan. 

Good Practice:
The test of the incident response plan can include simulated incidents and the corresponding responses in the form of a “table-top exercise”, that include participation by relevant personnel. A review of the incident and the quality of the response can provide entities with the assurance that all required elements are included in the plan. 
Стандарт № GMP Annex 11: Computerised Systems (RU) от 30.11.2011 "Правила надлежащей производственной практики. Приложение 11: Компьютеризированные системы":
Р. 4 п. 16 п.п. 1
С целью обеспечения работоспособности компьютеризированных систем, сопровождающих критические процессы, следует принять меры предосторожности для гарантии непрерывности поддержки этих процессов в случае выхода системы из строя (например, с использованием ручной или альтернативной системы). Время, необходимое для введения в действие альтернативных средств, должно учитывать риски и соответствовать конкретной компьютеризированной системе и сопровождаемому рабочему процессу. Эти меры должны быть надлежащим образом оформлены документально и проверены. 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 12.10.2
12.10.2
Определенные Требования к Подходу:
Не реже одного раза в 12 месяцев план реагирования на инциденты безопасности:
  • Проверяется, и содержание обновляется по мере необходимости.
  • Испытан, включая все элементы, перечисленные в требовании 12.10.1.
Цель Индивидуального подхода:
План реагирования на инциденты поддерживается в актуальном состоянии и периодически проверяется.

Определенные Процедуры Тестирования Подхода:
  • 12.10.2 Опрашивайте персонал и просматривайте документацию, чтобы убедиться, что по крайней мере раз в 12 месяцев план реагирования на инциденты безопасности:
    • Пересматривается и обновляется по мере необходимости. 
    • Испытано, включая все элементы, перечисленные в требовании 12.10.1.
Цель:
Надлежащее тестирование плана реагирования на инциденты безопасности может выявить нарушенные бизнес-процессы и гарантировать, что ключевые шаги не будут пропущены, что может привести к увеличению риска во время инцидента. Периодическое тестирование плана гарантирует, что процессы остаются жизнеспособными, а также гарантирует, что весь соответствующий персонал в организации знаком с планом.

Надлежащая практика:
Проверка плана реагирования на инциденты может включать имитацию инцидентов и соответствующие меры реагирования в форме “настольных упражнений”, которые включают участие соответствующего персонала. Анализ инцидента и качества реагирования может дать организациям уверенность в том, что все необходимые элементы включены в план.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
ЗИС.22 ЗИС.22 Защита информационной системы от угроз безопасности информации, направленных на отказ в обслуживании информационной системы
ЗИС.29 ЗИС.29 Перевод информационной системы или ее устройств (компонентов) в заранее определенную конфигурацию, обеспечивающую защиту информации, в случае возникновении отказов (сбоев) в системе защиты информации информационной системы
Стандарт Банка России № СТО БР ИББС-1.4-2018 от 01.07.2018 "Управление риском нарушения информационной безопасности при аутсорсинге":
Р. 12 п. 7
12.7. Контрольные ключевые параметры качества сервиса ИБ, вносимые в соглашение, должны быть измеримыми и представляться в виде числовых показателей (метрик). Состав ключевых показателей (ме‑ трик) качества определяется в зависимости от состава предоставляемых сервисов ИБ. Ключевыми пока‑ зателями (метриками) качества сервиса ИБ могут выступать среди прочих:
  • временные показатели (метрики):
    • время реакции на обращение организации БС РФ
  • время, прошедшее с момента поступления и регистрации запроса на обслуживание (сообщение организации БС РФ об инциденте) до фактического начала работ по факту обращения;
    • время закрытия инцидента SLA – время, прошедшее с момента фактического начала работ над инцидентом SLA до его фактического закрытия;
    • время решения инцидента SLA – суммарное время, прошедшее с момента поступления и регистрации обращения до закрытия заявки на обслуживание;
    • максимальное время реакции поставщика услуг – максимальное время, необходимое поставщику услуг при аварийных ситуациях для устранения их последствий;
    • время устранения уязвимости – время, прошедшее с момента обнаружения уязвимости до ее устранения;
  • качественные характеристики:
    • число предотвращенных утечек информации по отношению к общему числу реализованных и предотвращенных утечек информации; 
    • число предотвращенных фишинговых атак по отношению к общему числу реализованных и предотвращенных фишинговых атак;
    • соотношение числа запросов на обслуживание (сообщение организации БС РФ об инциденте) к числу инцидентов SLA; 
    • число повторных инцидентов SLA определенного типа;
    • соотношение найденных и устраненных уязвимостей;
  • качественные метрики:
    • уровень брака – это количественное или процентное выражение количества инцидентов SLA за определенный (отчетный) период времени; 
    • техническое качество – уровень технического качества программно-аппаратного комплекса, используемого для предоставления сервисов ИБ и обеспечивающего гарантию непрерывности предоставления финансовых услуг;
    • удовлетворенность качеством обслуживания – степень соответствия реализации сервиса ИБ потребности организации БС РФ, определяемой на основании опросов, проводимых самостоятельно организацией БС РФ и (или) с привлечением независимой организации;
  • метрики доступности и непрерывности сервисов ИБ:
    • доступность сервисов ИБ организации БС РФ – количество времени или временной промежуток, в котором сервисы ИБ, выполняемые поставщиком услуг, остаются доступными;
    • время восстановления сервисов ИБ в случае прерывания (RTO, Recovery time objective). 
Количество метрик, включаемых в SLA, должно быть достаточным для проведения объективной оценки качества предоставления сервисов ИБ поставщиком услуг. 
Приказ ФСБ России № 196 от 06.05.2019 "Требования к средствам, предназначенным для обнаружения, предупреждения и ликвидации последствий компьютерных атак и реагирования на компьютерные инциденты":
VIII п.21.5
21.5. При осуществлении резервирования и восстановления своей работоспособности средства ГосСОПКА должны обеспечивать:
  • возможность создания резервной копии конфигурационных данных на внешнем носителе;
  • возможность создания резервной копии ПО на внешнем носителе;
  • возможность самовосстановления работоспособности при обнаружении критических ошибок в процессе функционирования (только для средств ППКА).
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ЗИС.34 ЗИС.34 Защита от угроз отказа в обслуживании (DOS, DDOS-атак)
ЗИС.37 ЗИС.37 Перевод информационной (автоматизированной) системы в безопасное состояние при возникновении отказов (сбоев)
Положение Банка России № 779-П от 15.11.2021 "Обязательные для некредитных финансовых организаций требований к операционной надежности при осуществлении видов деятельности, предусмотренных частью первой статьи 76.1 Федерального закона от 10 июля 2002 года N 86-ФЗ "О Центральном банке"":
п. 1.2.
1.2. Некредитные финансовые организации, осуществляющие деятельность профессиональных участников рынка ценных бумаг, центрального депозитария, регистраторов финансовых транзакций, управляющих компаний инвестиционного фонда, паевого инвестиционного фонда и негосударственного пенсионного фонда, специализированных депозитариев инвестиционного фонда, паевого инвестиционного фонда и негосударственного пенсионного фонда, центрального контрагента, организатора торговли, субъектов страхового дела, негосударственных пенсионных фондов, операторов инвестиционных платформ, операторов финансовых платформ, операторов информационных систем, в которых осуществляется выпуск цифровых финансовых активов, операторов обмена цифровых финансовых активов, клиринговую деятельность, репозитарную деятельность, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации в соответствии с подпунктами 1.4.2 - 1.4.4 пункта 1.4 Положения Банка России от 20 апреля 2021 года N 757-П "Об установлении обязательных для некредитных финансовых организаций требований к обеспечению защиты информации при осуществлении деятельности в сфере финансовых рынков в целях противодействия осуществлению незаконных финансовых операций", зарегистрированного Министерством юстиции Российской Федерации 15 июня 2021 года N 63880 (далее соответственно - Положение Банка России от 20 апреля 2021 года N 757-П, некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации), в рамках обеспечения операционной надежности должны в соответствии с приложением к настоящему Положению обеспечить непревышение:
  • порогового уровня допустимого времени простоя технологических процессов, обеспечивающих осуществление деятельности в сфере финансовых рынков (далее - технологические процессы);
  • порогового уровня допустимого времени нарушения технологических процессов, приводящего к неоказанию или ненадлежащему оказанию финансовых услуг (далее - деградация технологических процессов).
NIST Cybersecurity Framework (EN):
ID.BE-5 ID.BE-5: Resilience requirements to support delivery of critical services are established for all operating states (e.g. under duress/attack, during recovery, normal operations)
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
PR.PT-5 PR.PT-5: Mechanisms (e.g., failsafe, load balancing, hot swap) are implemented to achieve resilience requirements in normal and adverse situations
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
ЗИС.34 ЗИС.34 Защита от угроз отказа в обслуживании (DOS, DDOS-атак)
ЗИС.37 ЗИС.37 Перевод информационной (автоматизированной) системы в безопасное состояние при возникновении отказов (сбоев)

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

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

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