The framework “Fundamental Requirements” applies to entities intending to qualify for SAMA Regulatory Sandbox environment and/or entities seeking license to operate in the kingdom of Saudi Arabia. The “Fundamental Requirements” serves as a catalyst to enable entities to comply with minimum SAMA’s cyber resilience licensing requirements. The “Fundamental Requirements” should not be treated as a replacement of SAMA’s Cyber Security and Business Continuity Management regulatory frameworks where the entities are required to comply with other relevant SAMA regulatory requirements post licensing decision. Additionally, this framework should also be read in conjunction with the requirements mandated in SAMA’s Regulatory Sandbox Framework.

The framework is mandated by SAMA. SAMA is the owner and is responsible for periodically updating the Framework.

In the event that an entity is not able to demonstrate compliance with the Fundamental Requirements, SAMA reserves the right to prohibit the sandboxing graduation/license request of the entity.

SAMA, as the owner of the Fundamental Requirements, is solely responsible for providing interpretations of the principles and control requirements, if required.

The Fundamental Requirements is intended for senior and executive management, business owners, owners of information assets, Heads of Cyber Security and those who are accountable for and involved in defining, implementing and reviewing cyber security and resilience controls within the Entities.

SAMA will review the Fundamental Requirements periodically to evaluate its applicability to the context of the KSA financial sector and its intended Entities. If deemed necessary, SAMA will update the fundamental Requirements based on the outcome of the review.

SAMA will implement version control for maintaining the Fundamental Requirements. Whenever making any changes, SAMA will retire the preceding version, as well as release and communicate the new version to all Entities. For the convenience of the Entities, SAMA will clearly indicate any changes to the revised Fundamental Requirements.

The domains and control requirements included in the fundamental requirements are risk-based and intended to provide participants with essential direction on how to mitigate the most common risks they face, without placing undue burden on them that could stifle innovation and business growth.

From this perspective, the fundamental requirements sets the essential cyber security and resilience mandatory requirements for entities that are within the scope of applicability. In addition, SAMA expects entities to conduct their own internal risk assessments to monitor the development of the cyber security and resilience threat landscape, to identify new and evolving risks, to evaluate the potential impact of these risks, and where deemed necessary to implement additional or enhanced security and resilience control requirements beyond the fundamental requirements to mitigate these risks in line with the entities risk appetite.

The implementation of the fundamental requirements at the participants will be subject to periodic self-assessment. The self-assessment will be performed by the entities based on a questionnaire. The entities will send a copy of its self-assessment to SAMA, and SAMA reserves the right to review the self-assessment for demonstration of compliance with the fundamental requirements at its discretion. SAMA also reserves the right to audit the compliance with the fundamental requirements of the entities at any time.

The current digital society has high expectations of flawless customer experience, continuous availability of services and effective protection of sensitive data. Information assets and online services are now strategically important to all public and private organizations, as well as to broader society. These services are vital to the creation of a vibrant digital economy. They are also becoming systemically important to the economy and to broader national security. All of which underlines the need to safeguard sensitive data and transactions, and thereby ensure confidence in the overall Saudi Financial Sector. 
 The stakes are high when it comes to the confidentiality, integrity and availability of information assets, and applying new online services and new developments (e.g. Fintech, block chain); while improving resilience against cyber threats. Not only is the dependency on these services growing, but the threat landscape is rapidly changing. The Financial Sector recognizes the rate at which the cyber threats and risks are evolving, as well as the changing technology and business landscape. 
 SAMA established a Cyber Security Framework (“the Framework”) to enable Financial Institutions regulated by SAMA (“the Member Organizations”) to effectively identify and address risks related to cyber security. To maintain the protection of information assets and online services, the Member Organizations must adopt the Framework. 
 The objective of the Framework is as follows: 

1. To create a common approach for addressing cyber security within the Member Organizations.
2. To achieve an appropriate maturity level of cyber security controls within the Member Organizations.
3. To ensure cyber security risks are properly managed throughout the Member Organizations.
    

The Framework will be used to periodically assess the maturity level and evaluate the effectiveness of the cyber security controls at Member Organizations, and to compare these with other Member Organizations. 

The Framework is based on the SAMA requirements and industry cyber security standards, such as NIST, ISF, ISO, BASEL and PCI. 

The Framework supersedes all previous issued by SAMA circulars with regard to cyber security. Please refer to ‘Appendix A - Overview previous issued by SAMA circulars' for more details. 
 

Cyber security is defined as the collection of tools, policies, security concepts, security safeguards, guidelines, risk management approaches, actions, training, best practices, assurance, and technologies that can be used to protect the member organization's information assets against internal and external threats. 

The general security objectives comprise the following:

• Confidentiality - Information assets are accessible only to those authorized to have access (i.e., protected from unauthorized disclosure or (un)intended leakage of sensitive data).
• Integrity - Information assets are accurate, complete and processed correctly (i.e., protected from unauthorized modification, which may include authenticity and non-repudiation).
• Availability - Information assets are resilient and accessible when required (i.e., protected from unauthorized disruption).
   

The Framework defines principles and objectives for initiating, implementing, maintaining, monitoring and improving cyber security controls in Member Organizations.

The Framework provides cyber security controls which are applicable to the information assets of the Member Organization, including:

• Electronic information.
• Physical information (hardcopy).
• Applications, software, electronic services and databases.
• Computers and electronic machines (e.g., ATM).
• Information storage devices (e.g., hard disk, USB stick).
• Premises, equipment and communication networks (technical infrastructure).

The Framework provides direction for cyber security requirements for Member Organizations and its subsidiaries, staff, third parties and customers.

For business continuity related requirements please refer to the SAMA Business Continuity Minimum Requirements.

The Framework has an interrelationship with other corporate policies for related areas, such as physical security and fraud management. This framework does not address the non-cyber security requirements for those areas. 

The Framework is applicable to all Member Organizations regulated by SAMA, which include the following:

• All Banks operating in Saudi Arabia;
• All Insurance and/or Reinsurance Companies operating in Saudi Arabia;
• All Financing Companies operating in Saudi Arabia;
• All Credit Bureaus operating In Saudi Arabia;
• The Financial Market Infrastructure

All domains are applicable for the banking sector. However, for other financial institutions the following exceptions apply:

• Sub-domain (3.1.2) the alignment with cyber security strategy of banking sector is mandatory when applicable.
• Exclude sub-domain (3.2.3). However, if the organization store, process or transmit cardholder data or deal with SWIFT services, then PCI standard and/or SWIFT Customer Security Controls Framework should be implemented.
• Exclude sub-domain (3.3.12).
• Exclude sub-domain (3.3.13). However, if the organization provides online services for customers, a Multi Factor Authentication capability should be implemented.

The framework is mandated by SAMA. SAMA is the owner and is responsible for periodically updating the Framework.

The Member Organizations are responsible for adopting and implementing the Framework.

Saudi Central Bank, as the owner of the Framework, is solely responsible for providing interpretations of the principles, objectives and control considerations, if required.

The Framework is intended for senior and executive management, business owners, owners of information assets, CISOs and those who are responsible for and involved in defining, implementing and reviewing cyber security controls within the Member Organizations.

The Framework will be reviewed and maintained by SAMA.

SAMA will review the Framework periodically to determine the Framework's effectiveness, including the effectiveness of the Framework to address emerging cyber security threats and risks. If applicable, SAMA will update the Framework based on the outcome of the review.

If a Member Organization considers that an update to the Framework is required, the Member Organization should formally submit the requested update to SAMA. SAMA will review the requested update, and when approved, the Framework will be adjusted.

The Member Organization will remain responsible to be compliant with the Framework pending the requested update.

Please refer to ‘Appendix B - How to request an Update to the Framework’ for the process of requesting an update to the Framework.

Version control will be implemented for maintaining the Framework. Whenever any changes are made, the preceding version shall be retired and the new version shall be published and communicated to all Member Organizations. For the convenience of the Member Organizations, changes to the Framework shall be clearly indicated.

The Framework is structured as follows. Chapter 2 elaborates on the structure of the Framework, and provides instructions on how to apply the Framework. Chapter 3 presents the actual Framework, including the cyber security domains and subdomains, principles, objectives and control considerations.

The Framework is structured around four main domains, namely:

• Cyber Security Leadership and Governance.
• Cyber Security Risk Management and Compliance.
• Cyber Security Operations and Technology.
• Third Party Cyber Security.

For each domain, several subdomains are defined. A subdomain focusses on a specific cyber security topic. Per subdomain, the Framework states a principle, objective and control considerations.

• A principle summarizes the main set of required cyber security controls related to the subdomain.
• The objective describes the purpose of the principle and what the set of required cyber security controls are expected to achieve.
• The control considerations reflects the mandated cyber security controls that should be considered.

Control considerations have been uniquely numbered throughout the Framework. Where applicable, a control consideration can consist of up to 4 levels.

The control considerations are numbered according to the following numbering system:

Figure 1 - Control consideration numbering system

The figure below illustrates the overall structure of the Framework and indicates the cyber security domains and subdomains, including a reference to the applicable section of the Framework.

Figure 2 - Cyber Security Framework

The Framework is principle based, also referred to as risk based. This means that it prescribes key cyber security principles and objectives to be embedded and achieved by the Member Organization. The list of mandated control considerations provides additional direction and should be considered by the Member Organization in achieving the objectives. When a certain control consideration cannot be tailored or implemented, the Member Organization should consider applying compensating controls, pursuing an internal risk acceptance and requesting a formal waiver from SAMA.

Please refer to Appendix D for details for the - How to request a Waiver from the Framework - process.

The implementation of the Framework at the Member Organization will be subject to a periodic self-assessment. The self-assessment will be performed by the Member Organization based on a questionnaire. The self-assessments will be reviewed and audited by SAMA to determine the level of compliance with the Framework and the cyber security maturity level of the Member Organization.

Please refer to ’2.4 Cyber Security Maturity Model’ for more details about the cyber security maturity model.

The cyber security maturity level will be measured with the help of a predefined cyber security maturity model. The cyber security maturity model distinguishes 6 maturity levels (0, 1, 2, 3, 4 and 5), which are summarized in the table below. In order to achieve levels 3, 4 or 5, a Member Organization must first meet all criteria of the preceding maturity levels.

Table 1 - Cyber Security Maturity Model

The objective of the Framework is to create an effective approach for addressing cyber security and managing cyber security risks within the Financial Sector. To achieve an appropriate cyber security maturity level, the Member Organizations should at least operate at maturity level 3 or higher as explained below.

The ultimate responsibility for cyber security rests with the board of the Member Organization. The board of the Member Organization can delegate its cyber security responsibilities to a cyber security committee (or a senior manager from a control function). The cyber security committee could be responsible for defining the cyber security governance and setting the Member Organization's cyber security strategy. The cyber security committee can also be responsible for defining a cyber security policy and ensuring the operational effectiveness of this cyber security policy.

To develop and maintain the cyber security policy and to execute the cyber security activities across the Member Organization, an independent cyber security function should be established.

Risk management is the ongoing process of identifying, analyzing, responding and monitoring and reviewing risks. The cyber security risk management process focusses specifically on managing risks related to cyber security. In order to manage cyber security risks, Member Organizations should:

• identify their cyber security risks - cyber security risk identification;
• determine the likelihood that cyber security risks will occur and the resulting impact - cyber security risk analysis;
• determine the appropriate response to cyber security risks and select relevant controls - cyber security risk response;
• monitor the cyber security risk treatment and review control effectiveness - cyber security risk monitoring and review.

The compliance with the cyber security controls should be subject to periodic review and audit.

In order to safeguard the protection of the operations and technology of the Member Organization’s information assets and its staff, third parties and customers, the Member Organizations have to ensure that security requirements for their information assets and the supporting processes are defined, approved and implemented.

The compliance with these cyber security requirements should be monitored and the effectiveness of the cyber security controls should be periodically measured and evaluated in order to identify potential revisions of the controls or measurements.

When Member Organizations do rely on, or have to deal with third party services, it is key to ensure the same level of cyber security protection is implemented at the third party, as within the Member Organization.

This paragraph describes how the cyber security requirements between the Member Organization and Third Parties should be organized, implemented and monitored. Third Parties in this Framework are defined as, information services providers, outsourcing providers, cloud computing providers, vendors, suppliers, governmental agencies, etc.

Request to Update SAMA Cyber Security Framework

A submission to the deputy governor of SAMA IT Risk Supervision

The Saudi Arabian Monetary Authority (SAMA) will consider requests from a member organization (MO) to update its Cyber Security Framework based on the information submitted using the form below. A separate form must be completed for each requested update. Please note that all required fields must be properly filled in before SAMA will begin the review process

Requestor Information

Approvals

* Denotes required fields

Request for Waiver from the SAMA Cyber Security Framework

A submission to the deputy governor of SAMA IT Risk Supervision

The Saudi Arabian Monetary Authority (SAMA) will consider requests for waiver from a member organization (MO) from its Cyber Security Framework based on the information submitted using the form below. A separate form must be completed for each requested waiver. Please note that all required fields must be properly filled in before SAMA will begin the review process.

Requestor Information

Approvals

* Denotes required fields

This document is mandatory for all Member Organizations regulated by SAMA.

This document is intended for senior and executive management, business owners, owners of information assets, Chief Information Security Officers (CISO), and individuals accountable for and involved in defining, implementing, and reviewing Cyber Threat Intelligence within Member Organizations.

This document is mandated by SAMA, who is the owner of the document and is responsible for its periodic updates. Member Organizations are responsible for adopting and implementing the principles contained in this document.

SAMA will review the document periodically to evaluate its applicability to the context of the KSA financial sector and its Member Organizations. If deemed necessary, SAMA will update the document based on the outcome of the review. Once changes are applied, SAMA will retire the previous version, and release and communicate the new version to all Member Organizations.

Core Cyber Threat Intelligence Principles establish a baseline for the planning, collection, processing, analysis, and dissemination of threat intelligence based around the intelligence lifecycle framework.

The Core Threat Intelligence Principles section is based on the main phases of the intelligence lifecycle, including the dissemination of threat intelligence and continuously improving the CTI capability and performance of Member Organizations.

The intelligence lifecycle allows security teams to analyze and understand the information, prevent, and defend their networks from cyber attacks. It is the process by which raw data and information is identified, collected, and analyzed. Subsequently, raw data and information is transformed into intelligence to be used and actioned by Member Organizations. The intelligence lifecycle is fully represented by the following Core Principles.

Considering the changing nature of the threat landscape, Strategic CTI allows to continuously monitor the cyber ecosystem and to prevent threats.

Strategic CTI specifically helps at identifying and understanding the threats to the financial sector. It provides the level of threat intelligence focused on objectives, motivations, and intent of cyber threat actors, strategic CTI aims at examining attribution, investigating real motivations and links between cyber events, and understanding the financial sector's ecosystem.

The threat landscape includes information on the threat actors that are most relevant to the Member Organizations, their main characteristics, and the main cyber trends within the financial sector worldwide.

This information is addressed to relevant executive management (e.g. chief Information Security officer) who will relay the information to other relevant parties (e.g. IT management, business leaders, etc.). Strategic CTI aids in the organization's understanding of current cyber threats, unknown future threats, threat actors, and attribution of attacks. Such understanding is key to having a pro-active approach to cybersecurity in order to build the resilience of the financial sector in the KSA.

Operational CTI helps the Member Organizations to understand the nature, intent, and timing of a specific attack, and provides insight into the behavior of a threat actor on a network.

Operational CTI provides detailed information on the behavior and modus operandi of threat actors used to carry out cyber attacks. Generally, this information is commonly taxonomized in Tactics, Techniques, and Procedures (TTPs).

Technical and tactical threat intelligence provide technical information regarding specific attacks performed by threat actors such as loCs, Yara Rules, etc.

The indicators of technical threat intelligence are collected from active and past campaigns obtained from public sources, technical indicators collected within the organization, and/or data feeds provided by external third-parties.

The following list contains a definition of the main terms used in this document.

The following tables contain examples of internal and external sources.

Table 1. External sources

Table 2 Internal sources

Below is represented a high-level graph of the CTI principles. The graph is aimed at representing the high-level structure of the document. 

Below is represented a mind map of the structure of the CTI principles. The graph is aimed to clearly represent the different domains of the document and how the principles are related to each other. 

Considering the need of 24 x 7 availability of the business operations by financial institutions in the Kingdom of Saudi Arabia, SAMA has developed a Business Continuity Management (BCM) framework for member organizations that would enhance the organizational resilience capability to ensure continuity and availability of their operations and services. The requirements are based on SAMA requirements, industry practices and international standards, such as ISO 22301, ISO 27001, Good practice guidelines from BCI, and Professional practice guidelines from DRII. All Member Organizations are required to comply with these requirements and integrate it formally in their BCM program.

• BCM is a holistic management process that identifies potential threats to an organization and the impacts to business operations those threats, if realized, might cause. It provides a framework for building organizational resilience with the capability for an effective response that safeguards the interests of its key stakeholders, reputation, brand and value-creating activities.
• BCM is part of the overall management system, which includes organizational structure, policies, planning activities, responsibilities, procedures, processes and resources that establishes, implements, operates, monitors, reviews, maintains and improves business continuity.
• IT Disaster recovery (IT DR) is part of BCM which includes policies, standards, procedures and processes pertaining to resilience, recovery or continuation of technology infrastructure supporting critical business processes.
• Maximum Acceptable Outage (MAO) is defined as the time that would take for adverse impacts which might arise because of not providing a product/service or performing an activity, to become unacceptable.
• Recovery Time Objective (RTO) is defined as the period following an incident within which, products or services must be resumed, activity must be resumed, or resources must be recovered.
• Recovery Point Objective (RPO) is defined as the point to which, information used by an activity must be restored to enable the activity to operate on resumption. This can also be termed as "Maximum Data Loss".

The BCM framework document defines principles, objectives and control considerations for initiating, implementing, maintaining, monitoring and improving business continuity controls in member organizations.

The BCM framework document is applicable to the full scope of the Member Organization, including subsidiaries, employees, subcontractors, third-parties and customers.

The BCM framework document has an interrelationship with other corporate policies for related areas, such as enterprise risk management, health, safety and environment (HSE), physical security, cybersecurity (including cyber resilience and incident management).

The BCM Framework document is applicable to following:

• All organizations affiliated with SAMA ("the Member Organizations")
• All banks operating in Saudi Arabia
• All banking subsidiaries of Saudi banks
• Subsidiaries of foreign banks situated in Saudi Arabia

SAMA mandates the BCM framework requirements document to Member Organizations. This document outlines the BCM requirements to be implemented by the Member Organizations. SAMA is the owner and is responsible for periodically updating the BCM Framework document. The Member Organizations are responsible for adopting and implementing the requirements stated in this framework document.

SAMA, as the owner of the BCM framework requirements document, will provide interpretations of the principles, objectives and control considerations, if required.

This document is intended for board of directors, CEOs, chief risk officer, senior and executive management, business owners, owners of information assets, CIOs, CISOs, business continuity managers, internal auditors and for those, who are responsible for and involved in defining, implementing and reviewing business continuity controls.

This document will be reviewed and maintained by SAMA. SAMA will review this document periodically to determine its effectiveness, including the effectiveness of the framework to address emerging business continuity threats and risks. If applicable, SAMA will update this document based on the outcome of the review.

If a Member Organization considers that an update to this document is required, the Member Organization should formally submit the requested update to SAMA after obtaining approval from the business continuity manager and business continuity steering committee within the Member Organization. SAMA will review the requested update, and when approved, this document will be updated.

Version control will be implemented for maintaining this document. Whenever any changes are made, the preceding version should be retired and the new version should be published and communicated to all Member Organizations.

The BCM Framework represents the actual BCM domains and subdomains, principles, objectives, and control considerations.

1. The Member Organization should report all disruptive incidents classified as "Medium" or "High" to SAMA "Banking IT Risk Supervision" immediately. A post-incident report should be communicated to SAMA after the Member Organization resumes to normal operations.
2. The Member Organization should coordinate with SAMA Supervision when communicating with the media in case of incidents.
3. Member Organizations should seek SAMA's approval when selecting a new site for its main or alternative data center, or when relocating the current main or alternative data center.
4. The Member Organization should communicate the approved program for executing business continuity and disaster recovery tests, for the upcoming year, with SAMA "Banking IT Risk Supervision" by end of January of every year.
5. Test results of business continuity and disaster recovery should be shared with SAMA within four weeks after the test The Member Organization should identify the improvements based on the test performed and provide an action plan to SAMA within two months after the submission of the test results.

1. Member Organizations should establish a process for document review/update to ensure the BC documents are up-to-date, reviewed and approved.
2. All documents should clearly identify the last date in which the document was reviewed and approved.

1. Member organization should conduct review / audit of BCM by qualified independent internal/ external party.
2. the Member Organization should identify the gaps and provide a road map to enhance the BCM within the organization.
3. The identified gaps along with road map should be reported to senior management and BCM committee.

It is crucial that the Member Organizations within the Financial Sector are resilient against the newest and most advanced cyber-attacks.

The Financial Entities Ethical Red Teaming Framework (F.E.E.R.) is intended as a guide for Member Organizations within Saudi Arabia in preparing and executing controlled attacks (i.e. threat intelligence based red teaming tests) against their (live) production environment without exposing sensitive information with the help of certified and experienced Red Teaming Providers.

The Saudi Central Bank* (SAMA) has a leading role in the implementation of this Framework. This Framework and associated processes will be continuously improved using the feedback and lessons learned from each red teaming exercise. This framework aims for sharing of intelligence and information obtained during such testing in order to further improve the cyber resilience of the Saudi Arabian Financial Sector.

Red Teaming should not be regarded as an Audit. It is a simulation test, which seeks to provide insight into the level of resilience and effectiveness of the implemented cyber security controls and relevant processes (i.e. detection and response).

Red Teaming is not a penetration test. In contrast to a penetration test (in which one or more specific information assets are tested and assessed), it focuses on replicating a targeted and realistic attack against the entire Member Organization performed in a controlled manner.

The Red Teaming Provider will use the latest attack tactics, techniques and procedures (i.e. TTPs) in an attempt to compromise the Member Organization, aiming to reach the member organizations most important and valuable information assets and to test the detection and response capabilities of the Member Organization. The Red Team consists of certified and experienced ethical hackers with in-depth knowledge of all security domains.

* The "Saudi Arabian Monetary Agency" was replaced By the "Saudi Central Bank" in accordance with The Saudi Central Bank Law No. (M/36), dated 11/04/1442H, corresponding to 26/11/2020G.

The principal objective of the framework is to provide guidance on how to conduct the red teaming activities and how to test the detection and response capabilities of the Member Organization against real sophisticated and advanced attacks and enhance the knowledge of the involved stakeholders. Likewise, the Framework aims to support the sharing of threat intelligence and lessons learned with the Member Organizations that will contribute to the cyber resilience of the Saudi Arabian Financial Sector.

The Framework will ensure that the red teaming exercise is executed in a controlled manner. This is important given the nature of the targets during the testing, namely business critical and (live) production systems (i.e. critical information assets).

The Framework applies to all Member Organizations in the Financial Sector, which are regulated by SAMA. SAMA has the authority to select any Member Organization and request the organization to perform a red teaming test considering the emerging threat landscape or based on the latest threat intelligence. In addition, member organization can rightfully conduct red teaming tests in order to ensure security resilience.

The framework is mandated by SAMA. SAMA is the owner and is responsible for periodically updating the Framework.

SAMA, as the owner of the Framework, is solely responsible for providing advice on the interpretation of the principles, objectives and considerations, if required.

Each Member Organization within the Financial Sector of Saudi Arabia and are regulated by SAMA should be tested, as a minimum once every three (3) years, in line with this framework.

The Framework is intended for Senior and Executive Management, business owners, owners of information assets, CISOs and those who are responsible for (or involved in) defining, implementing and reviewing cyber security controls within the Financial Sector and tasked with the improvement of the cyber resilience of the Member Organization.

The framework will be maintained by SAMA and reviewed periodically to determine the framework's effectiveness, including the extent to which it addresses emerging cybersecurity threats and risks. If applicable, SAMA will update the Framework based on the outcome of the review and lessons learned.

For any further information or enquiries about the Saudi Arabian Financial Entities Ethical Red Teaming Framework, please contact IT Risk of Financial Sector Supervision Department.

The stakeholders within the red teaming exercises have different roles and corresponding responsibilities. Irrespective of role, it is important that everyone is aware that any form of testing is performed in a controlled manner, and that a communication protocol is agreed regarding the sharing of information among the stakeholders. The relevant stakeholders are: 

1. SAMA IT Risk of Financial Sector Supervision department - The authority that has primary responsibility for overseeing the Red Teaming exercise.
2. The Member Organization - Each Financial Organization within the Financial Sector of Saudi Arabia and regulated by SAMA.
3. The Security Operations Centre - The SOC positioned within the Member Organization, which will be subject to the red teaming test.
4. The Red Teaming Provider - An external certified party, which has been selected to perform the red teaming exercise and provide required national or sector threat intelligence to define scenarios.
5. Available Member Organization committees (e.g. Banking Committee for Information Security - BCIS) - Relevant results of executed red teaming tests, lessons learned, and threat Intelligence might be shared within this committee, in an appropriately sanitized form using the agreed communication protocol, to support the increase of the overall cyber resilience of the (financial) sector.

For the execution of the red teaming exercise, the following teams should be established:

Green Team

SAMA IT Risk of Financial Sector Supervision department provides the Green Team. The Green Team appoints the Test Manager for each red teaming test. The Test Manager is responsible for guiding and supporting the White Team through the red teaming exercise. The Green Team approves the selection of Red Teaming Provider and provides - when applicable - additional or specific threat intelligence for the Financial Sector.

White Team

Within the Member Organization, the White Team should be appointed (including a White Team Leader), who will be responsible for the controlled execution of the red teaming exercise. The White Team consist of a limited number of security and business experts which are the only staff members that are aware of the red teaming test and who are the single-point-of-contacts (SPOCs), e.g. CISO. They will monitor the test and intervene when needed, e.g. when the test or results of the test are likely to, or have, caused a critical impact, compromise or service disruption.

The overall number of staff members that should be involved in the engagement, should be limited to maximum five (5) people, to avoid a too wide disclosure of the intended cyber-attack simulation and - as a result - that the effectiveness of the exercise is limited or flawed.

Blue Team

The cyber security monitoring team of the Member Organization (e.g. SOC) which monitors and analyses the generated security alerts and events to identify security breaches or flaws. It is the task of the Blue Team to detect the malicious activities (of the Red Team) and to follow the agreed incident response procedures the moment an incident is detected. The Blue Team should never be informed about the test and are expected to follow their standard operating procedures, in order to simulate a realistic attack.

Red Team

The Red Team, a selected third party that executes the attack scenarios and consists of certified and experienced specialists. The Red Team will work with the Green Team and White Team to develop the potential threats and attack scenarios. The Red Teaming Provider is also responsible for providing the latest threat intelligence related to the Financial Sector in order to achieve a certain level of assurance that the Member Organization is tested against the latest known (sophisticated) cyber-attacks.

Please refer to Appendix A-Requirements for Red Teaming provider, for more details on Red Teaming provider requirements.

 
 

1. Reconnaissance: 
    The first stage is about selecting a target and gathering information about the target to determine attack methods. This happens before the attack is executed. Examples of useful information can be: names, phone numbers, email addresses, functions, private or professional areas of interest of employees on the internet and published information about the software that an organization is using. 
    
2. Weaponize: 
    The attacker creates the malicious payload/file for a specific target based upon information retrieved during the reconnaissance stage. The attack can come in many different formats and is based upon the creativity of the attacker, the available set of defenses and the possible vulnerabilities. 
    
3. Delivery: 
    The transmission of the crafted attack to the victims by the use of different means, such as: email (attachments), phishing, websites, physical devices or social engineering. 
    
4. Exploitation: 
    Triggering or activating the malicious payload/file (i.e. malware) will result in a successful penetration of the target's system and network. A staged malware attack limits the possibility of detection. The malware will communicate back to the malicious attacker over a secure channel, which limits the chance of detection. Attackers usually use popular methods and file formats to deliver the malware executables (e.g. Microsoft office files, pdf files, malicious websites, phishing emails and removable media). 
    
5. Installation: 
    The actual installation of malicious payload/file or software that supports the malicious attacker. In order to make the malware and backdoor(s) persistent, the attackers could install additional malware or malicious software tools to ensure that the attack can continue if the initial compromised system or active malware is disabled. 
    
6. Command and Control: 
    A compromised system will usually connect back to the attacker, to establish a so-called command-and- control channel, which allows remote control of the malware. Especially in advanced persistent threat (APT) malware, the attacker will control the malware and explore the network by using this type of remote access. 
    
7. Actions on Objective: 
    After the attacker completed his malicious actions or achieved his goals, the attacker will try to cover his digital tracks and traces by using different techniques, like data exfiltration, or will use the compromised system as starting point to ‘hop on' to other systems in the network (i.e. lateral movement), to search for other high value assets or targets. 
    

The Red Teaming Provider(s) will maintain and deliver the threat intelligence landscape relevant for Saudi Arabian Financial Sector or specific Member Organization. This can be enriched using the provided input from SAMA (i.e. the IT Risk of Financial Sector Supervision department, or the Green Team), the White Team and, various governmental agencies. The Red Teaming Providers should provide the latest threat intelligence related to the Financial Sector in order to achieve a certain level of assurance that the Member Organization is tested against the latest known (sophisticated) cyber-attacks.

The Green Team initiates the preparation phase of the red teaming exercise by appointing a Test Manager. A Backup Test Manager should also be nominated given the importance of this role.

The Test Manager is responsible for contacting the Member Organization to explain the red teaming concept and processes. The Test Manager will invite the Member Organization to appoint and formalize their White Team and start contracting the Red Teaming Provider.

The White Team Leader initiates a kick-off session, where all relevant stakeholders (i.e. Green, White and Red Team) are invited to align the ambition and objectives of the red teaming exercise.

The Test Manager is a crucial person during the Red Teaming exercise. This person should have extensive experience in project management and in-depth understanding of the banking and cyber security sector.

The Test Manager of the Green Team should invite the Member Organization to appoint a White Team. During the entire red teaming exercise, the White Team will keep close contact with the Test Manager.

The Test Manager will oversee the Red Teaming exercise and will provide support, guidance and reflections to ensure that the entire Red Teaming exercise performed by the White Team and Red Teaming Provider is in line with the Framework. As the Test Manager is not a formal part of the White Team, he cannot be held accountable for any actions or consequences.

The Green Team will appoint the red team provider, who are pre-selected to execute the Red Teaming tests, based on their experiences and skilled staff. Given the fact, that these ethical hacking tests are carried out on the live production systems, it is crucial that the Red Teaming Provider has a proven track record and has the required skills, expertise, certifications and experienced staff to perform the red teaming test.

Please refer to Appendix A- Requirements for Red Teaming provider, for more details on Red Teaming provider requirements

The Member Organization should carefully establish a White Team and nominate a White Team Leader in order to facilitate, oversee and lead the red teaming exercises during all phases. The White Team Leader's role is to make sure that the entire Red Teaming exercise is performed in a controlled manner, on behalf of the Member Organization. After establishing the White Team, the White Team Leader needs to coordinate with the appointed Red Teaming Provider for contract and invite the Red Teaming Provider to the kick-off meeting.

During a kick-off session with all relevant stakeholders (Green, White and Red Team), the scope and the target critical information assets (i.e. ‘red flags') should be defined for the attack scenarios. Moreover, the planning of the project is discussed in detail along with the responsibilities for each team. Deliverables and contractual considerations should be discussed during the session. The White Team should determine the flags that should be targeted or attacked.

The Red Teaming Provider will share their advice and recommendations to the White and Green Team based on their (previous) experience in order to support the scoping discussion.

Boundaries, limitations and escalation procedure for the red teaming test should be discussed and defined by the White Team with mutual understanding with the Green Team. Another important step is to agree on the liability for the actions of the Red Teaming Provider (see also 3.5).

The White Team should create a Scoping document. This document should contain contact details of the White Team members and the identified flags (i.e. defined goals or target systems) during the red teaming exercise. This document also contains the overall plan for the exercise, predefined escalation procedures and communication protocols (including the code-name for the test).

Once the scope is defined by the White Team, the Scoping document should be submitted to the Green Team for approval.

Each of the teams provides their collated threat Intelligence independently. The Green Team will provide (when available) their sector-wide threat intelligence which is known and available via the Member Organizations or incidents. This may include threat intelligence from governmental agencies, which could be relevant to the Member Organization. The White Team should provide the Member Organization's input including specific threat intelligence considered relevant for their business and linked to the internal or external trends or incidents, they identified.

The Red Teaming Provider will combine the received threat intelligence with their external threat intelligence (including and using their own ‘open' sources), and the intelligence gathered during various red teaming engagements.

Based on all received threat intelligence, the Red Team should analyze, outline and create realistic attack scenarios and prepare a test strategy document. Once the scenarios are determined, the attack scenarios and test strategy should be agreed upon before the Red Teaming Provider starts with the creation of the specific attack scenarios.

The detailed attack scenarios should be mapped to one or more critical information assets combining the external, internal (i.e. Member Organization specific) and sector-wide threat intelligence. Each attack scenario should include a written description of the kill chain from the attacker's point of view. The Red Teaming Provider should indicate various attack options, based on various tactics, techniques and procedures (TTPs) used by experienced testers and attackers. As with the high-level attack scenarios and test strategy, the detailed scenarios have to be agreed with the Green Team.

The final red teaming plan should not only consist of the different attack scenarios that the Red Teaming Provider will perform, but also define the agreed escalation procedures and communication protocols. Given the fact that critical production systems are in scope for the red teaming test, the Red Teaming Provider should be aware and consider how to react in case of any unexpected issues or disruptions. After finalizing the red teaming plan, final approval by the White and Green Team is required before Red Teaming Provider can proceed with executing the attack scenarios.

The Red Teaming Provider should start the execution of the red teaming exercise following the agreed scenarios and against the identified critical (information) assets or functions. It should be noted that the agreed scenarios do not have to be followed precisely as these are outline and may not reflect the precise operational environment encountered during the execution phase. Nevertheless, the Red Teaming Provider should inform the White Team Leader and Green Team about the suggested adjustments in the scenarios. Deviation from the initial scenarios should be allowed and is desirable if obstacles are encountered.

Red Teaming Provider should apply their expertise and ‘creativity' to develop alternative ways or workarounds in order to reach the identified critical (information) assets or functions. It is crucial that the Red Teaming Provider remains in close contact with both the Green and the White Team and does provide periodic updates on the progress made during the red teaming test - in line with the frequency which was agreed during the kick-off, or in case of escalations or severe incidents or occurrences - immediately.

If the Blue Team detects any events triggered by the Red Team while performing their actions, the Red Teaming Provider should decide in conjunction with the White Team Leader if the red teaming test can be continued in line with the initial plan or whether the initial attack plan can be adjusted.

The White Team Leader should consider the following options when the actions of the Red Teaming Provider are detected:

1. Stop or postpone the test in case there is a significant risk of a business disruption;
2. Carefully monitor and direct the Blue Team or response activities, in case extreme actions are about to be taken (i.e. reporting the incident to law enforcement, shutting down critical services to avoid to avoid further impact from the incident, ..Etc.);
3. Inform the Red Teaming Provider to continue with the initial attack scenarios;
4. Inform the Red Teaming Provider to revise the (detected) attack or to create a workaround for the specific critical information asset and continue with the revised attack scenario after approval from the White Team Leader;
5. Inform Green Team on the detection of events and decision on the exercise.
6. Request the Red Teaming Provider to re-engineer an alternate attack scenario for an adjusted critical information assets (e.g. change in scope).

The Red Teaming Provider finalizes the red teaming report and presents the output to all the White and Blue Team. Simultaneously, the Blue Team should create a blue team report. The blue team report should provide the observations from the perspective of the Blue Team and should include the alert and events detected; the actions initiated and the result of these actions. The blue team reports should also provide the Blue Team's recommendations for improvements.

It is important that all teams (i.e. Green, White and Red) that were directly involved in the red teaming test provide their (360 degrees) feedback on the executed red teaming test. The White Team should initiate and schedule a joint replay session with all the teams.

The White Team should create a remediation plan based on the recommendations provided by the Red Team and Blue Team. The White Team should:

• analyze the observations and recommendations;
• determine the improvements regarding the detection and response capabilities;
• determine the associated risks and priorities.

The White Team shares the internally agreed and approved remediation plan with the Green Team and periodically track the remediation progress to ensure that the vulnerabilities identified are monitored and mitigated.

Shortly after finishing the red teaming exercise, the Member Organization, i.e. the White Team should start executing the agreed remediation activities and address the identified vulnerabilities.

The Member Organization should be tracking the actual remediation progress to ensure the timely execution and delivery of the improved capabilities. The Member Organization should ensure that the Cyber Security Committee (and if required the Senior Management) is periodically updated on the progress of the planned remediation actions, and should request support when remediation activities do not progress as expected.