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

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

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

A.17.1.3

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

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

ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 8. Требования к организации и управлению защитой информации":
КЗИ.6
КЗИ.6 Контроль безотказного функционирования технических средств, обнаружение и локализация отказов функционирования, принятие мер по восстановлению отказавших средств и их тестирование
Стандарт Банка России № СТО БР ИББС-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 Контроль безотказного функционирования технических средств, обнаружение и локализация отказов функционирования, принятие мер по восстановлению отказавших средств и их тестирование
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 Контроль безотказного функционирования технических средств, обнаружение и локализация отказов функционирования, принятие мер по восстановлению отказавших средств и их тестирование
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ОДТ.3 ОДТ.3 Контроль безотказного функционирования средств и систем
Положение Банка России № N 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

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

3
Название Дата Влияние
Community
1 13 / 29
Резервное копирование документов с ПК
Ежедневно Автоматически Техническая Восстановительная Компенсирующая
20.06.2022
20.06.2022 1 13 / 29
Цель: сохранение документов в случае их уничтожения на ПК.
Например, в результате кражи ПК, случайного или умышленного уничтожения файлов пользователем, запуска вируса-шифровальщика.

Документы определенных форматов (doc, xls и т.п.) со всех доменных ПК регулярно копируются на сервер резервных копий.

Варианты реализации:
  • ПО для резервного копирования;
  • DCAP системы защиты;
  • Скрипты.
В заметке к защитной мере приведен скрипт для создания системы резервного копирования документов с пользовательских ПК, на базе Групповой политики домена + Планировщика заданий + Скриптов на vbs/bat + Robocopy
Community
2 18 / 36
Дополнительное автономное (оффлайн) хранилище резервных копий
Ежеквартально Вручную Техническая Физическая Восстановительная
23.08.2021
23.08.2021 2 18 / 36
Цель: уменьшить вероятность потери данных при уничтожении инфраструктуры. 

Отдельное хранилище с копией основной системы резервного копирования - образов серверов, данных с файловых серверов, баз данных и иных активов по которым в компании осуществляется резервное копирование.
Дополняет основную систему резервного копирования в случае ее поломки или уничтожения.
Варианты реализации:
  • НЖМД, подключаемые к ПК, в том числе usb flash drive; 
  • сетевой СХД; 
  • ленточная система резервного копирования.
Инструкция к регулярной задаче:
  1. Включить/подключить автономную систему резервного копирования
  2. Провести резервное копирование
    Допускается копирование уже созданных основной системой резервного копирования данных
  3. Выключить автономную систему резервного копирования
  4. Опционально: поместить носители в сейф, зафиксировать операцию в журнале резервного копирования 
  5. В результатах выполнения задачи указать перечень скопированных объектов
Рекомендации к заполнению карточки:
  • Описать политику (методологию) автономного хранения резервных копий;
  • Добавить автономное хранилище в реестр активов и связать с карточкой как инструмент.
  • Добавить шаблон регулярной задачи на выполнение (ежемесячного, ежеквартального) и контроль дополнительного автономного хранения резервных копий.
Community
1 9 / 53
Резервное копирование и архивирование конфигураций сетевого оборудования
Еженедельно Автоматически Восстановительная
26.07.2021
26.07.2021 1 9 / 53
Цель: сохранение возможности быстрого восстановления конфигурации сетевого оборудования (при сбросе, сбое или замене оборудования).

С заданной периодичностью со всего сетевого оборудования (коммутаторов и маршрутизаторов) собирается текущая конфигурация.
Пример реализации для оборудования Cisco - в заметке.
Собираются:
  1. Конфигурация (show running-config view full)
  2. Таблицы соединений с другим коммутационным оборудованием (show cdp neighbors detail)
  3. Таблицы розданных IP по DHCP (show ip dhcp binding)
  4. Таблицы подключенных MAC адресов (show mac address-table)
Глубина хранения архивных версий: N лет.
Место хранения резервных копий: XXX.
Примечание: доступ к месту хранения скрипта и резервных копий должен быть ограничен.

Проверка работоспособности защитной меры:
  1. Проверить, что список проверяемых коммутаторов соответствует актуальному
  2. Проверить, что подключения проходят успешно (смотреть логи отработки скрипта);
  3. Проверить, что конфигурации собираются успешно (проверить каталог с результатами).
Рекомендации к заполнению карточки:
  • Описать методологию выполнения, хранения и проверки резервных копий конфигураций;
  • Добавить шаблон регулярной задачи на выполнение и проверку резервных копий конфигураций;
  • Если ведется реестр скриптов - привязать соответствующий скрипт к карточке как инструмент.