Куда я попал?
Вы попали в сервис, который помогает корпоративным службам безопасности строить свои рабочие процессы: управление рисками, контроль соответствия требованиям, учет активов, планирование и сопровождение защитных мер на всем их жизненном цикле, распределение задач и т.д.
Еще SECURITM является платформой для обмена опытом и наработками между участниками сообщества служб безопасности.
Подробнее

SWIFT Customer Security Controls Framework v2022

Framework

7 - 7.4A Scenario Risk Assessment

Для проведения оценки соответствия по документу войдите в систему.
7.4A Scenario Risk Assessment
Обязательно для architecture type A1 A2 A3 A4 B
Control Definition 

Control Objective: Evaluate the risk and readiness of the organisation based on plausible cyber-attack scenarios. 

In-scope components: 
  • Organisational control (people, processes, and infrastructure) to be also met by a third party operating a remote virtualisation platform (also known as hypervisor) that hosts SWIFT-related VMs. 
Risk Drivers: 
  • excess harm from deficient cyber readiness 
  • unidentified sensitivity to cyber exposure 
Implementation Guidance 

Control Statement: 
Scenario-based risk assessments are conducted regularly to improve incident response preparedness and to increase the maturity of the organisation’s security programme. 

Control Context: 
Scenario-based risk assessments, including cyber wargames, test attacks on existing systems and processes targeting the hosted SWIFT infrastructure. Scenario-based risk assessments include technical and business driven exercises performed as part of institution risk management. 
These assessments include the following threats: end-user impersonation, message tampering, message eavesdropping, third-party software weaknesses, compromising systems or Denial of Service (DoS) attacks affecting service availability. Results of the assessment and existing mitigations help identify areas of risks that may require future actions, risk mitigations or an update of the cyber-incident response plan. 
Identified actions, mitigations, or updates must be reported and closed according to their criticality as per the Information Security Risk Management (ISRM) process. 
Several ISRM frameworks exist and can be consulted41 to define the user's proper ISRM and resources (such as CIS-Critical Security Controls). These frameworks can be used to start implementing a basic risk management process to be further enhanced to address user's specific risks. 

Implementation Guidelines: 
The implementation guidelines are common methods to apply the relevant control. The guidelines are a helpful way to begin an assessment, but should never be considered as an "audit checklist" as each user’s implementation may vary. Therefore, in cases where some implementation guidelines elements are not present or partially covered, mitigations as well as particular environment specificities must be considered to properly assess the overall compliance adherence level (as per the suggested guidelines 
or as per the alternatives). 
  • A scenario-based risk assessment and planning activity is conducted to: 
    • identify possible methods for adversaries to gain unauthorised access to local SWIFT infrastructure based upon observed adversary techniques or plausible adversary techniques inferred from adversaries' motivations and capabilities 
    • analyse the effectiveness of existing prevention and detection controls to mitigate anticipated adversary techniques to gain unauthorised access to the environment 
    • analyse the probability and impact of significant and plausible attack vectors given existing controls
    • analyse the effectiveness of existing response controls to limit impact of significant and plausible attack vectors given existing controls 
    • Identify the need for additional preventive or detective controls 
  • Assessment and planning activity is conducted at least annually, and updated through ongoing risk management activities, when significant technology changes occur, or when threat intelligence indicates relevant changes in an applicable adversary’s capabilities or motivations. 
  • Current threat intelligence and observed or likely attacks (vectors, techniques, actors,) are used as the basis for scenarios. 
  • Each asset class (end-user devices, servers, network devices) is assessed against threats on a regular basis and when changes are introduced or when new threats are identified.

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

ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 8. Требования к организации и управлению защитой информации":
СЗИ.2
СЗИ.2 Проведение и фиксация результатов (свидетельств) анализа необходимости совершенствования процесса системы защиты информации в случаях изменения политики финансовой организации в отношении: 
- области применения процесса системы защиты информации; - основных принципов и приоритетов в реализации процесса системы защиты информации; 
- целевых показателей величины допустимого остаточного операционного риска (риск-аппетита), связанного с обеспечением безопасности информации
Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения":
Р. 8 п. 4 п.п. 4
8.4.4. Оценка рисков нарушения ИБ проводится для свойств ИБ всех информационных активов (типов информационных активов) области действия СОИБ. 
Р. 8 п. 4 п.п. 7
8.4.7. В организации БС РФ должны быть определены роли по оценке рисков нарушения ИБ и назначены ответственные за выполнение указанных ролей. 
Р. 8 п. 4 п.п. 5
8.4.5. Полученные в результате оценивания рисков нарушения ИБ величины рисков должны быть соотнесены с уровнем допустимого риска, принятого в организации БС РФ. Результатом выполнения указанной процедуры является зафиксированный перечень недопустимых рисков нарушения ИБ. 
NIST Cybersecurity Framework (RU):
ID.RA-4
ID.RA-4: Определены потенциальные последствия и их вероятности для бизнеса  
ID.RA-1
ID.RA-1: Идентифицированы и задокументированы уязвимости активов 
ID.RA-5
ID.RA-5: Угрозы, уязвимости, вероятности и воздействия используются для определения риска 
ID.RA-6
ID.RA-6: Для рисков определены и расставлены по приоритетам ответные меры
ID.RA-3
ID.RA-3: Идентифицированы и задокументированык внутренние и внешние угрозы
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования":
8.2
 8.2 Оценка рисков информационной безопасности 
Организация должна проводить оценку рисков информационной безопасности через запланированные интервалы времени или в случае предполагаемых или произошедших существенных изменений, учитывая критерии рисков информационной безопасности, установленные в соответствии с 6.1.2 а). 
Организация должна хранить документированную информацию о результатах проведенных оценок рисков информационной безопасности. 
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
АУД.10 АУД.10 Проведение внутренних аудитов
АУД.11 АУД.11 Проведение внешних аудитов
NIST Cybersecurity Framework (EN):
ID.RA-3 ID.RA-3: Threats, both internal and external, are identified and documented
ID.RA-5 ID.RA-5: Threats, vulnerabilities, likelihoods, and impacts are used to determine risk
ID.RA-4 ID.RA-4: Potential business impacts and likelihoods are identified
ID.RA-6 ID.RA-6: Risk responses are identified and prioritized
ID.RA-1 ID.RA-1: Asset vulnerabilities are identified and documented
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
АУД.11 АУД.11 Проведение внешних аудитов
АУД.10 АУД.10 Проведение внутренних аудитов

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

Название Дата Влияние
Community
37 / 27
Управление рисками информационной безопасности
Ежеквартально Вручную Организационная Детективная
08.05.2022
08.05.2022 37 / 27
Цель: выявление и устранение актуальных проблем информационной безопасности.

Общий процесс управления рисками включает следующие подпроцессы:
  1. Оценивание / Risk Assessment
    1. Идентификация / Risk Identification
      Результат: Реестр рисков
    2. Анализ / Risk Analysis
      Результат: оценка параметров рисков (ущерб, вероятность)
    3. Оценка / Risk Evaluation
      Результат: рассчет величины для каждого риска, соотнесение рисков с допустимым уровнем
  2. Обработка / Risk Treatment
    Результат: План обработки рисков
Реализация меры означает выполнение в организации всех подпроцессов управления рисками.
Варианты реализации:
Для обеспечения процесса должны быть определены:
  • область оценки рисков (активы или типы активов, для которых оцениваются риски);
  • ценность (приоритет) активов (типов активов), для которых проводится оценка рисков;
  • периодичность оценивания (ежегодно, ежеквартально, непрерывно/динамически); 
  • методика оценки, включая:
    • формулы расчета величины риска;
    • критерии для оценки рисков;
    • критерии принятия рисков ( = критерии приемлемости риска);
    • риск-аппетит ( = уровень допустимого риска, допустимый остаточный риск);
  • ответственные и роли в процессе;
  • владельцы рисков;
Результатами процесса являются:
  • Реестр рисков, в т.ч.: 
    • реестр недопустимых рисков;
    • реестр принятых рисков;
  • План обработки рисков
    • включает перечень влияющих на риски защитных мер ( = средств управления, контролей).
Рекомендации к заполнению карточки:
  • Создать шаблон регулярной задачи по актуализации реестра рисков, переоценке рисков, проверке полноты и исполнения плана обработки рисков.
Community
1 26 / 34
Сканирование внешнего сетевого периметра на наличие уязвимостей
Еженедельно Автоматически Техническая Детективная
11.02.2022
11.02.2022 1 26 / 34
Цель: управление техническими уязвимостями
Регулярное сканирование всех публичных IP адресов компании сканером уязвимостей. Сканирование проводится из Интернета (из вне инфраструктуры).
Варианты реализации
  1. Купить соответствующую услугу у компании, занимающейся информационной безопасностью
  2. Развернуть собственный экземпляр сканера уязвимостей (или его агент) на внешних, облачных серверах
  3. Купить подписку на облачный сканер уязвимостей
  4. Воспользоваться бесплатными инструментами
    Например: Сканер уязвимостей Qualys Community Edition позволяет проводить регулярное полноценное сканирование ограниченного количества публичных IP адресов
Результаты сканирования могут загружаться в SECURITM (модуль VM) и обрабатываться в рамках процесса управления техническими уязвимостями.

Рекомендации к заполнению карточки:
  • Указать название сканера, область и периодичность сканирования.
  • Сканер (актив) привязать к карточке как инструмент
  • Если ведётся реестр публичных адресов - привязать адреса к карточке как инструмент.
  • Если сканирование запускается вручную - создать в карточке шаблон задачи на проведение регулярного сканирования
Community
9 / 32
Проведение тестирования на проникновение
Ежеквартально Вручную Техническая Детективная
02.06.2021
02.06.2021 9 / 32
Цель: определение возможностей злоумышленника по компрометации инфраструктуры организации. 

Тестирование на проникновение (пентест, pentest).
Способы проведения: white box, gray box, black box
Области тестирования:
  1. Внешний пентест (тестирование внешнего периметра)
  2. Внутренний пентест (тестирование локальной сети)
  3. Тестирование сетей WiFi
  4. Тестирование методами социальной инженерии
  5. Тестирование web приложений
Пентесты проводятся преимущественно внешними подрядчиками, которых рекомендуется менять на регулярной основе для исключения эффекта замыливания.

Рекомендации к заполнению карточки:
  • Создать шаблон регулярной задачи по проведению тестирования на проникновение (периодичность ежеквартально или ежегодно);
  • В отчете о выполнении задачи приводить краткие результаты тестирования или ссылку на отчет;