3.3 Operations Management
IT Operations Management can be defined as the function responsible for continues management and maintenance of the Members Organization's IT applications and infrastructure to ensure delivery of the agreed level of IT services to the business. Thus, IT operations risk factors should be addressed by the Member Organizations through effective management and control.
3.3.1 Manage Assets
Principle
Asset Management process should be established to provide visibility of the Member Organization's information assets by maintaining an accurate and up-to-date inventory.
Control Requirements
1. The asset management process should be defined, approved, implemented and communicated.
2. The effectiveness of the asset management process should be monitored, measured and periodically evaluated.
3. The asset management process should include but not limited to:
a. asset onboarding;
b. asset identification, classification, labeling and handling;
c. asset disposal; and
d. asset decommissioning.
4. Asset register should provide with the level of details, including (but not limited):
a. asset name;
b. asset owner;
c. asset custodian; asset criticality;
d. asset physical location;
e. asset logical location (network zone);
f. asset identified as direct in-scope of PCI;
g. asset identified as indirect in-scope of PCI;
h. availability or backup information;
i. service contract or license information;
j. technical contacts (OS, Application, Database and Network);
k. primary and secondary processes supported by the asset;
l. acceptable downtime aligned with BCM - Business Impact Analysis where applicable;
m. financial impact per hour in the event of downtime;
n. vendor engagement contract number;
o. vendor point of contact details;
p. vendor SLA details; and
q. vendor classification details.
5. Asset register should be maintained and updated on yearly basis, or whenever any asset introduced or removed from inventory.
6. Member organizations should:
a. define criteria for the identification of critical assets;
b. identify, maintain and periodically update comprehensive list of critical assets;
c. proactively monitor performance of critical assets; and
d. ensure adequate resilience measures in place for critical assets to maintain availability of the required critical services.
7. Asset owner should be responsible for, but not limited to:
a. classification and labeling of asset;
b. defining and reviewing access rights, restrictions, and taking into account applicable access control policies of the Member Organizations;
c. authorizing changes related to assets; and
d. ensure alignment with cyber security controls.
8. Assets should be disposed of in a controlled and secure manner upon completion of its useful life and when other relevant obligations are met.
3.3.2 Interdependencies
Principle
Interdependencies for critical information assets should be identified and managed through governance model to ensure availability of business operations.
Control Requirements
1. Member Organizations should define and implement robust governance model in light of their interdependencies with relevant stakeholders (e.g. service providers, government institutions, etc.)
2. Member Organizations should identify its critical information assets interdependencies.
3. As part of the 89 testing, the Member Organizations should take into consideration the interdependencies of critical information assets scenarios within its infrastructure.
Note: For more Control Requirements to improve the overall resilience, please refer to the SAMA - BCM Framework.
3.3.3 Manage Service Level Agreements
Principle
Contractual terms and conditions governing the roles, relationships, obligations and responsibilities of internal stakeholder and third parties should be formally agreed, developed and adequately controlled.
Control Requirements
1. Internal IT Service Level Agreement (SIA) should be formally defined, approved, and communicated to the relevant business department of the Member Organizations.
2. The effectiveness of the internal IT SLA should be monitored, measured, and periodically evaluated.
3. Internal IT SLA should include the following, but not limited to:
a. service level agreed between the business functions and the IT department;
b. specific and measurable targets for IT services against the defined KPI's; and
c. roles and responsibilities of the business and IT stakeholders.
4. The third party relationship process should be defined, approved, implemented, and communicated.
5. The effectiveness of the third party relationship process should be monitored, measured, and periodically evaluated.
6. Formal SLA should be defined and signed with the third party.
7. The third party relationship process should cover following requirements, but not limited to:
a. outsourcing service providers should have adequate process in place to ensure availability, protection of data and applications outsourced;
b. periodic reporting, reviewing and evaluating the contractually agreed requirements (in SLAs);
c. changes to the provision of provided services;
d. execution of a risk assessment as part of the procurement process;
e. escalation process in case of SLA breached;
f. administrative, physical, and technical safeguards that reasonably and appropriately protect the confidentiality, integrity, and availability of information;
g. legal assurance from the third party to provide onsite support that mandates onsite presence of certified and experienced relevant support engineer within a defined timeline to support the Member Organizations in adverse situations;
h. exiting, terminating, or renewing the contract (including escrow agreements if applicable);
i. compliance with applicable frameworks including but not limited to SAMA Cyber Security, Business Continuity Management and IT Governance Frameworks-and applicable Laws and Regulations;
j. right to audit (Member Organizations or independent party); and
k. Non-Disclosure Agreement ('NDA').
3.3.4 IT Availability and Capacity Management
Principle
Service availability should be maintained to support member organizations business functions and to avoid disruption and slowness of systems performance through monitoring current system thresholds and prediction of future performance and capacity requirements.
Control Requirements
1. The IT availability and capacity management process should be defined, approved and implemented.
2. The effectiveness of the IT availability and capacity management process should be monitored, measured and periodically evaluated.
3. IT availability and capacity plan should be developed, approved and periodically evaluated.
4. IT availability and capacity plan should be defined to address the following, but not limited to:
a. existing capacity of systems and resources;
b. alignment with the current and future business needs;
c. high availability requirements (including disruption and slowness for customer channels);
d. roles and responsibilities to maintain the plan; and
e. identification of dependencies over service providers as part of capacity planning to address BCM requirements.
5. System performance thresholds should be defined and implemented.
6. System performance should be monitored considering the following, but not limited to:
a. current and future business requirement;
b. the agreed upon SLA with the business;
c. critical IT infrastructures;
d. disruption and slowness in the underlying system(s) supporting customer channels; and
e. lessons learned from previous system performance issues.
7. Deviations from established capacity and performance baselines/thresholds should be identified, documented, followed-up, and reported to the management and ITSC.
3.3.5 Manage Data Center
Principle
Adequate physical controls are designed and implemented to protect IT facilities and equipment from damage and unauthorized access.
Control Requirements
1. Physical and environmental controls for managing the data center should be defined, approved and implemented.
2. Physical and environmental controls should be monitored and periodically evaluated.
3. Necessary physical and environmental controls should be implemented such as but not limited to:
a. access to the data center should be strictly controlled and provided on need to know basis;
b. visitors entry to data center should be logged and escorted by an authorized person;
c. smoke detectors;
d. fire alarms;
e. fire extinguishers;
f. humidity control;
g. temperature monitoring; and
h. CCTV.
4. The outsourcing of data center should comply with the requirements published in SAMA circulars on the Rules of The Outsourcing and Cybersecurity Framework.
5. Member Organizations should ensure that appropriate control measures are built into contracts with the service providers to whom they plan to outsource data center such as but not limited to:
a. have documented business case for outsourcing data center services; and
b. nature and type of access to data center by the service provider.
3.3.6 Network Architecture and Monitoring
Principle
IT event management and network architecture controls should be designed and implemented to continuously monitor IT operations in order to protect member organizations network from unauthorized access.
Control Requirements
1. Member Organizations should define, approve and implement network architecture policy considering the following:
a. organization's stance with respect to acceptable network usage;
b. explicit rules for the secure use of specific network resources, services and applications;
c. consequences of failure to comply with security rules;
d. organization's attitude towards network abuse; and
e. rationale(s) for the policy, and for any specific security rules.
2. Member Organizations should ensure the implementation of following network architecture controls, but not limited to:
a. network diagram showing the complete current infrastructure;
b. segmentation of network into multiple separate network domains based on the required trust levels (6.8. public domain, desktop domain, server domain) and in line with relevant architectural principles;
c. perimeter of each network domain should be well protected by a security gateway (e.g. firewall, filtering router). For each security gateway a separate service access (security) rules should be developed and implemented to ensure that only the authorized traffic is allowed to pass;
d. all internal traffic (head office users, branch users, third party users, etc.) passing to DMZ or internal servers should pass via 2 security gateway (firewall);
e. all outbound internet access from internal networks are routed via proxy server such that access is allowed only to approved authenticated users;
f. visitor network (wired/wireless network) should be isolated and segregated from the internal network;
g. the perimeter firewall to the DMZ should raise an alert and block active scanning;
h. web application firewall (WAF) should be implemented against customer facing applications;
i. ensure non-existence of single node of failure that affects the critical service availability;
j. centralized authentication server (AAA, TACACS or RADIUS, etc.) should be deployed for managing authentication and authorization of network devices;
k. centralized log server (e.g. syslog server) should be deployed to collect and store logs from all network devices;
l. retention period for logs should be 12 months minimum;
m. all network devices should synchronize their clock timings from a centralized NTP server;
n. all network communication over extranet (WLAN) and internet should be through an encrypted channel;
o. remote access should be restricted only to certain group of IP addresses;
p. remote administration should be over an encrypted channel (like SSL VPN, SSH);
q. remote administration access for vendors should be time-bound and granted on a need basis with approval;
r. scan for Member Organization's devices before accessing the network to ensure enforcement of security policies on devices before they access organization's network; and
s. segregation of duties within the infrastructure component (supported with a documented authorization profile matrix).
3. Member Organizations should ensure that network monitoring is performed considering the following, but not limited to:
a. administrative trails including login and activity trails (like configuration change, rule change, etc.);
b. resource utilization (processor and memory); and
c. network connectivity to all branches and ATMs.
3.3.7 Batch Processing
Principle
Batch management process should be defined, approved and implemented in order to manage the bulk processing of automated tasks in an efficient and controlled manner.
Control Requirements
1. Batch management process should be defined, approved, implemented and communicated.
2. The effectiveness of the Batch management process should be measured and periodically evaluated.
3. Batch Management process should include the following, but not limited to:
a. start and end of day schedules;
b. roles and responsibilities;
c. monitoring of batches; and
d. error or exception handling.
4. Changes in the batch schedules should be approved by the relevant stakeholder(s).
5. Member organizations should maintain log containing information about start and end of the day batch operations along with its status 6.8. (successful or unsuccessful).
3.3.8 IT Incident Management
Principle
IT incident Management process should be established to timely identify, respond and handle IT incidents impacting the Member Organization's information assets and to report relevant incidents to SAMA, according to a defined communication protocol.
Control Requirements
1. IT incident management process should be defined, approved, implemented and communicated.
2. The effectiveness of the IT incident management process should be measured and periodically evaluated.
3. IT incident management process should include the following requirements, but not limited to:
a. the establishment of a designated team responsible for incident management;
b. communication plan;
c. details of key staff who need to be notified;
d. skilled and (continuously) trained staff;
e. the prioritization and classification of incidents;
f. the timely handling of incidents, recording and monitoring progress;
g. the protection of relevant evidence and loggings;
h. post-incident activities such as root-cause analysis of the incidents; and
i. lessons learned.
4. IT incident management process should be automated such as through IT service desk.
5. ٨ process should be established for documenting the details of incident, steps taken which were successful and which were not successful, should be communicated to the relevant IT staff for hands on experience and also for future reference to enhance efficiency.
6. All user requests and IT incident should be logged with the following information but not limited to:
a. unique reference number;
b. date and time;
c. name of the impacted services and systems;
d. update the relevant owner; and
e. categorization and prioritization based on the urgency and impact.
7. All IT incident should be tracked and resolved as per agreed service level.
8. Member organizations relevant teams should be involved (when applicable) to ensure adequate handling of the incident.
9. The Member Organizations should inform 'General Department of Cyber Risk Control' immediately upon identification of 'Medium' or above classified incident that have impact on customers, as per SAMA BCM Framework.
10. The Member Organizations should inform 'General Department of Cyber Risk Control' immediately upon identification of disruption and slowness in the critical and/or application(s) impacting customer.
11. Member Organizations should notify 'General Department of Cyber Risk Control' before disclosing any information about the incident to the media.
12. The Member Organizations should submit a detail incident report within five (5) days to 'General Department of Cyber Risk Control', including the following details as a minimum:
a. title of the incident;
b. identification, classification and prioritization of incident;
c. logging and monitoring of incident;
d. resolution and closure of incident;
e. impact assessment such as financial, data, customer and/or reputational;
f. date and time of the incident;
g. name of the impacted services and systems;
h. root-cause analysis; and
i. corrective actions with target dates.
3.3.9 Problem Management
Principle
Criteria and procedures to report problems should be defined to limit recurring incidents and to minimize the impact of incidents on the Member Organizations.
Control Requirements
1. The problem management process should be defined, approved, implemented and communicated.
2. The effectiveness of the problem management process should be measured and periodically evaluated.
3. The problem management process should include the following requirements but not limited to:
a. identification, classification and prioritization of problem;
b. logging and monitoring of problem;
c. resolution and closure of problem;
d. the protection of relevant evidence and loggings;
e. impact assessment such as financial, data, customer and/or reputational;
f. date and time of the problem;
g. name of the impacted services and systems;
h. root-cause analysis; and
i. corrective actions.
4. The Member Organizations should maintain a database for known error records.
3.3.10 Data Backup and Recoverability
Principle
Data backup management strategy along with backup and restoration procedures should be defined, approved and implemented to ensure reliability, availability, and recoverability of data of the Member Organizations.
Control Requirements
1. Data backup management strategy should be defined, approved and implemented.
2. The data backup management policy should consider the following, but not limited to:
a. alignment with SAMA Business Continuity Management Framework;
b. implementation of replication, backup and recovery capabilities;
c. data storage;
d. data retrieval; and
e. data retention as per the legal, regulatory and business requirements.
3. Backup and restoration procedures should be defined, approved and implemented.
4. The effectiveness of the backup and restoration procedure should be measured and periodically evaluated.
5. Member Organizations should define its backup and restoration requirements considering the following, but not limited to:
a. legal and regulatory requirements;
b. business requirements in line with agreed RPO (Recover Point Objective);
c. type of backups (offline, online, full, incremental, etc.); and
d. schedule of the backup (daily, weekly, monthly, etc.).
6. Member Organizations should ensure the following information are backed up at minimum:
a. applications;
b. operating systems software;
c. databases; and
d. device configurations.
7. In case of replication of data between primary and disaster recovery site, Member Organizations should ensure that all replication issues are timely resolved such that data at the disaster recovery site are in sync with the primary site as per the agreed recovery point objective (RPO) and recovery time objective (RTO).
8. Member Organizations should ensure that RTOs for critical services such as payment systems, customer related services, etc. are adequately defined considering the high availability of the supporting operations and minimum disruption in the event of disaster.
9. Member Organization should ensure sufficient investment are made from people, process and technology perspective to achieve the targeted RTOs.
10. Member Organizations should implement alternate mechanism for backup redundancy (e.g. transaction dumps in addition to full database backup).
11. Member Organizations should conduct periodic testing and validation of the recovery capability of backup media.
12. Backup media should be appropriately labelled.
13. Backup media including USB disks, containing sensitive or confidential information should be encrypted before transportation to offsite for storage.
3.3.11 Virtualization
Principle
Formal process for creation, distribution, storage, use and retirement of virtualized images, snapshots or containerization should be defined and managed in a controlled and secured manner.
Control Requirements
1. A process should be defined, approved, implemented and communicated by the Member Organizations to setup, deploy and configure a virtual environment.
2. The process should be governed with well-defined policies, procedures and standards.
3. The effectiveness of the virtualization or containerization process should be measured and periodically evaluated.
4. All virtual components deployed in the Member Organizations should be provided with the same level of security as of non-virtualized environment.
5. All virtual components should be adequately configured using defined and approved minimum baseline security standards (MBSS) specific to virtualization or containerization.
6. Strong authentication mechanism should be implemented and access should be granted on need to know or least privileged basis for all virtual environments including host operating system, hypervisor, guest operating systems and any other related components.
7. The creation, distribution, storage, use, retirement and destruction of the virtual images and snapshots should be handle in a controlled and secured manner.
8. The following should be considered as part of virtualization/containerization but not limited to:
a. administrative access should be tightly controlled where access via local admin should be restricted;
b. management of hypervisors should be restricted to administrators only;
c. virtual test environment should be physically and/or logically segregated from the production environment and even should not operate on the same host;
d. unnecessary program and services should be disabled on virtual machines unless authorized by the business;
e. audit logging should be enabled and monitored for all virtual machines that should include but not limited to:
1. creation, deployment and removal;
2. root and administrative activities; and
3. creation, modification and deletion of system level objects.
f. appropriate controls should be in place to protect sensitive and critical data being used and managed through virtual images or snapshots; and
g. all virtual drives used by the guest operating systems should be backed-up and tested on regular basis, using the same policy for backup management as is used for non-virtualized systems.