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

Guideline for a healthy information system v.2.0 (EN)

Framework

40 STANDARD

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

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

Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения":
Р. 8 п. 11 п.п. 3
8.11.3. Должен быть определен план обеспечения непрерывности бизнеса и его восстановления после возможного прерывания. План должен содержать инструкции и порядок действий работников организации БС РФ по восстановлению бизнеса. В частности, в состав плана должны быть включены:
  • условия активации плана;
  • действия, которые должны быть предприняты после инцидента ИБ;
  • процедуры восстановления;
  • процедуры тестирования и проверки плана;
  • план обучения и повышения осведомленности работников организации БС РФ;
  • обязанности работников организации с указанием ответственных за выполнение каждого из положений плана. 
Р. 7 п. 4 п.п. 4
7.4.4. В организации БС РФ должны быть определены, выполняться, регистрироваться и контролироваться правила и процедуры мониторинга ИБ, анализа и хранения данных о действиях и операциях, позволяющие выявлять неправомерные или подозрительные операции и транзакции, для чего, среди прочего, следует:
  • определить действия и операции, подлежащие регистрации;
  • определить состав и содержание данных о действиях и операциях, подлежащих регистрации, сроки их хранения;
  • обеспечить резервирование необходимого объема памяти для записи данных;
  • обеспечить реагирование на сбои при регистрации действий и операций, в том числе аппаратные и программные ошибки, сбои в технических средствах сбора данных;
  • обеспечить генерацию временных меток для регистрируемых действий и операций и синхронизацию системного времени на технических средствах, используемых для целей мониторинга ИБ, анализа и хранения данных.
В организации БС РФ должно быть реализовано ведение журналов действия и операций автоматизированных рабочих мест, серверного и сетевого оборудования, межсетевых экранов и АБС с целью их использования при реагировании на инциденты ИБ.
Рекомендуется обеспечить хранение данных о действиях и операциях не менее трех лет, а для данных, полученных в результате выполнения банковского платежного технологического процесса, - не менее пяти лет, если иные сроки хранения не установлены законодательством РФ, нормативными актами Банка России.
Для проведения процедур мониторинга ИБ и анализа данных о действиях и операциях следует использовать специализированные программные и (или) технические средства.
Процедуры мониторинга ИБ и анализа данных о действиях и операциях должны использовать зафиксированные критерии выявления неправомерных или подозрительных действий и операций. Указанные процедуры мониторинга ИБ и анализа должны применяться на регулярной основе, например ежедневно, ко всем выполненным действиям и операциям (транзакциям).
Р. 8 п. 10 п.п. 2
8.10.2. Должны быть определены, выполняться, регистрироваться и контролироваться процедуры хранения и распространения информации об инцидентах ИБ, практиках анализа инцидентов ИБ и результатах реагирования на инциденты ИБ. 
Р. 8 п. 10 п.п. 1
8.10.1. Должны быть определены, выполняться, регистрироваться и контролироваться процедуры обработки инцидентов, включающие:
  • процедуры обнаружения инцидентов ИБ;
  • процедуры информирования об инцидентах, в том числе информирования службы ИБ;
  • процедуры классификации инцидентов и оценки ущерба, нанесенного инцидентом ИБ;
  •  — процедуры реагирования на инцидент;
  •  — процедуры анализа причин инцидентов ИБ и оценки результатов реагирования на инциденты ИБ (при необходимости с участием внешних экспертов в области ИБ). 
Р. 8 п. 12 п.п. 4
8.12.4. Процедуры мониторинга ИБ и контроля защитных мер должны подвергаться регулярным, регистрируемым пересмотрам в связи с изменениями в составе и способах использования защитных мер, выявлением новых угроз и уязвимостей ИБ, а также на основе данных об инцидентах ИБ. 
Р. 8 п. 10 п.п. 5
8.10.5. В организациях БС РФ должны приниматься, фиксироваться и выполняться решения по всем выявленным инцидентам ИБ. 
Р. 8 п. 10 п.п. 4
8.10.4. Процедуры расследования инцидентов ИБ должны учитывать законодательство РФ, положения нормативных актов Банка России, а также внутренних документов организации БС РФ в области ИБ. 
Р. 8 п. 10 п.п. 6
8.10.6. В организации БС РФ должны быть определены роли по обнаружению, классификации, реагированию, анализу и расследованию инцидентов ИБ и назначены ответственные за выполнение указанных ролей. 
Р. 8 п. 12 п.п. 3
8.12.3. Информация обо всех инцидентах, выявленных в процессе мониторинга ИБ и контроля защитных мер, должна быть учтена в рамках выполнения процедур хранения информации об инцидентах ИБ. 
CIS Critical Security Controls v8 (The 18 CIS CSC):
14.6
14.6 Train Workforce Members on Recognizing and Reporting Security Incidents
Train workforce members to be able to recognize a potential incident and be able to report such an incident. 
17.2
17.2 Establish and Maintain Contact Information for Reporting Security Incidents
Establish and maintain contact information for parties that need to be informed of security incidents. Contacts may include internal staff, third-party vendors, law enforcement, cyber insurance providers, relevant government agencies, Information Sharing and Analy 
17.1
17.1 Designate Personnel to Manage Incident Handling
Designate one key person, and at least one backup, who will manage the enterprise’s incident handling process. Management personnel are responsible for the coordination and documentation of incident response and recovery efforts and can consist of employees internal to the enterprise, third-party vendors, or a hybrid approach. If using a third-party vendor, designate at least one person internal to the enterprise to oversee any third-party work. Review annually, or when significant enterprise changes occur that could impact this Safeguard. 
17.6
17.6 Define Mechanisms for Communicating During Incident Response
Determine which primary and secondary mechanisms will be used to communicate and report during a security incident. Mechanisms can include phone calls, emails, or letters. Keep in mind that certain mechanisms, such as emails, can be affected during a security incident. Review annually, or when significant enterprise changes occur that could impact this Safeguard.
17.4
17.4 Establish and Maintain an Incident Response Process
Establish and maintain an incident response process that addresses roles and responsibilities, compliance requirements, and a communication plan. Review annually, or when significant enterprise changes occur that could impact this Safeguard. 
17.3
17.3 Establish and Maintain an Enterprise Process for Reporting Incidents
Establish and maintain an enterprise process for the workforce to report security incidents. The process includes reporting timeframe, personnel to report to, mechanism for reporting, and the minimum information to be reported. Ensure the process is publicly available to all of the workforce. Review annually, or when significant enterprise changes occur that could impact this Safeguard. 
Стандарт № GMP Annex 11: Computerised Systems (EN) от 30.11.2011 "Good Manufacturing Practice. Annex 11: Computerised Systems":
Р. 4 п. 13 п.п. 1
All incidents, not only system failures and data errors, should be reported and assessed. The root cause of a critical incident should be identified and should form the basis of corrective and preventive actions. 
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
MAC.18
MAC.18 Обеспечение возможности выявления и анализа событий защиты информации, потенциально связанных с инцидентами защиты информации, в том числе НСД
РИ.10
РИ.10 Своевременное (оперативное) оповещение членов ГРИЗИ о выявленных инцидентах защиты информации
РИ.7
РИ.7 Определение и назначение ролей, связанных с реагированием на инциденты защиты информации
РИ.14
РИ.14 Установление и применение единых правил закрытия инцидентов защиты информации
РИ.5
РИ.5 Установление и применение единых правил регистрации и классификации инцидентов защиты информации в части состава и содержания атрибутов, описывающих инцидент защиты информации, и их возможных значений
РИ.6
РИ.6 Установление и применение единых правил реагирования на инциденты защиты информации
РИ.3
РИ.3 Классификация инцидентов защиты информации с учетом степени их влияния (критичности) на предоставление финансовых услуг, реализацию бизнес-процессов и (или) технологических процессов финансовой организации
NIST Cybersecurity Framework (RU):
RS.MI-1
RS.MI-1: Инциденты локализируются 
RS.AN-2
RS.AN-2: Понимается влияние инцидента
RS.MI-2
RS.MI-2: Смягчаются последствия от инцидента 
DE.AE-5
DE.AE-5: Установлены пороги оповещения об инциденте 
RS.AN-4
RS.AN-4: Инциденты классифицируются в соответствии с планами реагирования 
PR.IP-9
PR.IP-9:  Созданы и управляются планы реагирования (реагирование на инциденты и непрерывность бизнеса) и планы восстановления (восстановление после инцидентов и аварийное  восстановление) 
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ИНЦ.3 ИНЦ.3 Своевременное информирование лиц, ответственных за выявление инцидентов и реагирование на них, о возникновении инцидентов в информационной системе пользователями и администраторами
ИНЦ.1 ИНЦ.1 Определение лиц, ответственных за выявление инцидентов и реагирование на них
ИНЦ.2 ИНЦ.2 Обнаружение, идентификация и регистрация инцидентов
ИНЦ.5 ИНЦ.5 Принятие мер по устранению последствий инцидентов
ИНЦ.6 ИНЦ.6 Планирование и принятие мер по предотвращению повторного возникновения инцидентов
ИНЦ.4 ИНЦ.4 Анализ инцидентов, в том числе определение источников и причин возникновения инцидентов, а также оценка их последствий
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 19.1 CSC 19.1 Document Incident Response Procedures
Ensure that there are written incident response plans that define roles of personnel as well as phases of incident handling/management.
CSC 19.6 CSC 19.6 Publish Information Regarding Reporting Computer Anomalies and Incidents
Publish information for all workforce members, regarding reporting computer anomalies and incidents, to the incident handling team. Such information should be included in routine employee awareness activities.
CSC 19.3 CSC 19.3 Designate Management Personnel to Support Incident Handling
Designate management personnel, as well as backups, who will support the incident handling process by acting in key decision-making roles.
Strategies to Mitigate Cyber Security Incidents (EN):
3.1.
Continuous incident detection and response with automated immediate analysis of centralised time-synchronised logs of allowed and denied computer events, authentication, file access and network activity.
Relative Security Effectiveness:  Excellent | Potential User Resistance:  Low | Upfront Cost:  Very High | Ongoing Maintenance Cost: Very High 
SWIFT Customer Security Controls Framework v2022:
7 - 7.1 Cyber Incident Response Planning
7.1 Cyber Incident Response Planning
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ИНЦ.3 ИНЦ.3 Анализ компьютерных инцидентов
ИНЦ.1 ИНЦ.1 Выявление компьютерных инцидентов
ИНЦ.2 ИНЦ.2 Информирование о компьютерных инцидентах
ИНЦ.5 ИНЦ.5 Принятие мер по предотвращению повторного возникновения компьютерных инцидентов
ИНЦ.6 ИНЦ.6 Хранение и защита информации о компьютерных инцидентах
ИНЦ.4 ИНЦ.4 Устранение последствий компьютерных инцидентов
NIST Cybersecurity Framework (EN):
RS.MI-1 RS.MI-1: Incidents are contained
RS.AN-2 RS.AN-2: The impact of the incident is understood
RS.MI-2 RS.MI-2: Incidents are mitigated
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
DE.AE-5 DE.AE-5: Incident alert thresholds are established
RS.AN-4 RS.AN-4: Incidents are categorized consistent with response plans
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
ИНЦ.3 ИНЦ.3 Анализ компьютерных инцидентов
ИНЦ.1 ИНЦ.1 Выявление компьютерных инцидентов
ИНЦ.2 ИНЦ.2 Информирование о компьютерных инцидентах
ИНЦ.5 ИНЦ.5 Принятие мер по предотвращению повторного возникновения компьютерных инцидентов
ИНЦ.6 ИНЦ.6 Хранение и защита информации о компьютерных инцидентах
ИНЦ.4 ИНЦ.4 Устранение последствий компьютерных инцидентов

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