SYSTEM ACQUISITION, DEVELOPMENT AND MAINTENANCE POLICY

INSPIRING BUSINESS INNOVATION

October 2020

SYSTEM ACQUISITION, DEVELOPMENT

AND MAINTENANCE POLICY Version: 2.0

Policy Code: DICT-QAP020

سياسة اقتناء الأنظمة وتطويرها وصيانتها

System Acquisition, Develop. & Maintenance Policy

Page 2 of 17

Table of Contents

Property Information ................................................................................... 3

Document Control ........................................................................................ 4

Information .................................................................................................................. 4

Revision History ............................................................................................................ 4

Distribution List ............................................................................................................ 4

Approval ....................................................................................................................... 4

Policy Overview ........................................................................................... 5

Purpose ........................................................................................................................ 5

Scope ........................................................................................................................... 5

Terms and Definitions ................................................................................................... 5

Change, Review and Update ......................................................................................... 7

Enforcement / Compliance ........................................................................................... 7

Waiver .......................................................................................................................... 8

Roles and Responsibilities (RACI Matrix) ....................................................................... 8

Relevant Documents ..................................................................................................... 9

Ownership .................................................................................................................. 10

Policy Statements ...................................................................................... 11

Information Security Requirements Analysis and Specification .................................... 11

Securing Application Services on Public Networks ....................................................... 12

Protecting Application Services Transactions ............................................................... 13

Secure Development Policy ......................................................................................... 13

System Change Control Procedures ............................................................................. 13

Technical Review of Applications after Operating Platform Changes ............................ 14

Restrictions on Changes to Software Packages ............................................................ 14

Secure System Engineering Principles .......................................................................... 15

Secure Development Environment .............................................................................. 15

Outsourced Development ........................................................................................... 16

System Security Testing .............................................................................................. 16

System Acceptance Testing ......................................................................................... 16

Protection of Test Data ............................................................................................... 17



Page 3 of 17

Property Information

This document is the property information of Imam Abdulrahman bin Faisal University - ICT Deanship.

The content of this document is intended only for the valid recipients. This document is not to be

distributed, disclosed, published or copied without ICT Deanship written permission.



Page 4 of 17

Document Control

Information

Title Classification Version Status

SYSTEM ACQUISITION, DEVELOPMENT AND

MAINTENANCE POLICY

Public 2.0 validated

Revision History

Version Author(s) Issue Date Changes

0.1 Alaa Alaiwah - Devoteam November 18, 2014 Creation

0.5 Nabeel Albahbooh - Devoteam December 1, 2014 Update

1.0 Muneeb Ahmad – ICT, IAU 18 May 2017 Update

1.2 Lamia Abdullah Aljafari 6 June 2020 Update

2.0 Dr. Samer Bani Awwad 13 September 2020 Update

Distribution List

# Recipients

1 Legal Affairs

2 Website

3 Quality Assurance Department - DICT

4 System Management Department - DICT

5 Department of Administrative and Finance Affairs - DICT

Approval

Name Title Date Signature

Dr. Khalid Adnan Alissa Dean of DICT 8th October 2020



Page 5 of 17

Policy Overview

This section describes and details the purpose, scope, terms and definitions, change, review and

update, enforcement / compliance, wavier, roles and responsibilities, relevant documents and

ownership.

Purpose

The main purpose of System Acquisition, Development and Maintenance Policy is to:

Ensure that information security is an integral part of information systems across the entire

lifecycle, ensure that information security is designed and implemented within the development

lifecycle of information systems, and ensure the protection of data used for testing.

Scope

The policy statements written in this document are applicable to all IAU’s resources at all levels of

sensitivity; including:

All full-time, part-time and temporary staff employed by, or working for or on behalf of IAU.

Students studying at IAU.

Contractors and consultants working for or on behalf of IAU.

All other individuals and groups who have been granted access to IAU’s ICT systems and

information.

This policy covers all information assets defined in the Risk Assessment Scope Document and will be

used as a foundation for information security management.

Terms and Definitions

Table 1 provides definitions of the common terms used in this document.

Term Definition

Accountability A security principle indicating that individuals shall be able to be identified and

to be held responsible for their actions.

Asset Information that has value to the organization such as forms, media,

networks, hardware, software and information system.

Availability The state of an asset or a service of being accessible and usable upon demand

by an authorized entity.



Page 6 of 17

Confidentiality An asset or a service is not made available or disclosed to unauthorized

individuals, entities or processes.

Control A means of managing risk, including policies, procedures, and guidelines

which can be of administrative, technical, management or legal nature.

Cryptography

The discipline which embodies principles, means and methods for the

transformation of data in order to hide its information content, prevent its

undetected modification, or prevent its unauthorized use.

Guideline A description that clarifies what shall be done and how, to achieve the

objectives set out in policies.

Digital Signature

An attempt to mimic the offline act of a person applying their signature to a

paper. It involves applying a mathematical algorithm, usually stored on and as

part of the user’s private key, to the contents of a body of text.

Information

Security

The preservation of confidentiality, integrity, and availability of information.

Additionally, other properties such as authenticity, accountability, non-

repudiation and reliability can also be involved.

Integrity Maintaining and assuring the accuracy and consistency of asset over its entire

life-cycle.

Owner

A person or group of people who have been identified by Management as

having responsibility for the maintenance of the confidentiality, availability

and integrity of an asset. The Owner may change during the lifecycle of the

asset.

Penetration

Testing

A method of evaluating the security of a computer system or network by

simulating an attack from malicious outsiders (who do not have an authorized

means of accessing the organization's systems) and malicious insiders (who

have some level of authorized access). The process involves an active analysis

of the system for any potential vulnerability that could result from poor or

improper system configuration, both known and unknown

hardware/software flaws and operational weaknesses in process or technical

countermeasures. This analysis is carried out from the position of a potential

attacker and can involve active exploitation of security vulnerabilities.

Policy

A plan of action to guide decisions and actions. The policy process includes the

identification of different alternatives such as programs or spending priorities,

and choosing among them on the basis of the impact they will have.

Privacy The right of an individual to be secure from unauthorized disclosure of

information about oneself that is contained in documents.

Risk A combination of the consequences of an event (including changes in

circumstances) and the associated likelihood of occurrence.



Page 7 of 17

System

An equipment or interconnected system or subsystems of equipment that is

used in the acquisition, storage, manipulation, management, control, display,

switching, interchange, transmission or reception of data and that includes

computer software, firmware and hardware.

Supplier A party that provides equipment or services.

Threat

A potential to cause an unwanted incident which may result in harm to a

system such as unauthorized disclosure, destruction, removal, modification or

interruption of sensitive information, assets or services, or injury to people. A

threat may be deliberate, accidental or of natural origin.

Vulnerability

A weakness in security procedures, processes, or controls that could be

exploited by a threat to gain unauthorized access to information or disrupt

critical processing.

Table 1: Terms and Definitions

Change, Review and Update

This policy shall be reviewed once every year unless the owner considers an earlier review necessary

to ensure that the policy remains current. Changes of this policy shall be exclusively performed by the

Information Security Officer and approved by management. A change log shall be kept current and be

updated as soon as any change has been made.

Enforcement / Compliance

Compliance with this policy is mandatory and it is to be reviewed periodically by the Information

Security Officer. All IAU units (Deanship, Department, College, Section and Center) shall ensure

continuous compliance monitoring within their area.

In case of ignoring or infringing the information security directives, IAU’s environment could be

harmed (e.g., loss of trust and reputation, operational disruptions or legal violations), and the fallible

persons will be made responsible resulting in disciplinary or corrective actions (e.g., dismissal) and

could face legal investigations.

A correct and fair treatment of employees who are under suspicion of violating security directives

(e.g., disciplinary action) has to be ensured. For the treatment of policy violations, Management and

Human Resources Department have to be informed and deal with the handling of policy violations.



Page 8 of 17

Waiver

Information security shall consider exceptions on an individual basis. For an exception to be approved,

a business case outlining the logic behind the request shall accompany the request. Exceptions to the

policy compliance requirement shall be authorized by the Information Security Officer and approved

by the ICT Deanship. Each waiver request shall include justification and benefits attributed to the

waiver.

The policy waiver period has maximum period of 4 months, and shall be reassessed and re-approved,

if necessary for maximum three consecutive terms. No policy shall be provided waiver for more than

three consecutive terms.

Roles and Responsibilities (RACI Matrix)

Roles

Responsibilities

Mgt.

ICT

ISO

Sup

plie

r

Ow

ner

Use

r

Approving new or modifications of systems R,A C C C,I I

Conducting vulnerability assessment and penetration testing.

C R,A C,I

Identifying the applicable security controls to mitigate the risks and threats for IAU’s critical systems.

R,A R,C C,I

Ensuring the protection of information / infrastructure systems, according to the technological mechanisms defined by the system / application design team.

R,A C I

Providing a secure development environment that protects the confidentiality, integrity, and availability of information.

R,A C I

Performing all the necessary system testing (functional, security, etc.) during development lifecycle.

R,A C R,C I

Implementing appropriate controls to protect the confidentiality, integrity and authenticity of sensitive information.

R,A R,C I

Table 2 shows the RACI matrix1 that identifies who is responsible, accountable, consulted or informed

for every task that needs to be performed.

1 The responsibility assignment RACI matrix describes the participation by various roles in completing tasks for a business process. It is especially useful in clarifying roles and responsibilities in cross-functional/departmental processes. R stands for Responsible who performs



Page 9 of 17

There are a few roles involved in this policy respectively: Management, ICT Deanship, Information

Security Officer (ISO), Supplier, Owner and User (Employee and Contract).

Roles

Responsibilities

Mgt.

ICT

ISO

Sup

plier

Ow

ner

Use

r

Approving new or modifications of systems R,A C C C,I I

Conducting vulnerability assessment and penetration testing.

C R,A C,I

Identifying the applicable security controls to mitigate the risks and threats for IAU’s critical systems.

R,A R,C C,I

Ensuring the protection of information / infrastructure systems, according to the technological mechanisms defined by the system / application design team.

R,A C I

Providing a secure development environment that protects the confidentiality, integrity, and availability of information.

R,A C I

Performing all the necessary system testing (functional, security, etc.) during development lifecycle.

R,A C R,C I

Implementing appropriate controls to protect the confidentiality, integrity and authenticity of sensitive information.

R,A R,C I

Table 2: Assigned Roles and Responsibilities based on RACI Matrix

Relevant Documents

The following are all relevant policies and procedures to this policy:

Information Security Policy

Organization of Information Security policy

Access Control Policy

Operations Security Policy

Communications Security Policy

Suppliers Relationships Policy

Compliance Policy

a task, A stands for Accountable (or Approver) who sings off (approves) on a task that a responsible performs, C stands for Consulted (or Consul) who provide opinions, and I stands for Informed who is kept up-to-date on task progress.



Page 10 of 17

Risk Management Policy

Change Management Procedure

Patch Management Procedure

Systems Acquisition, Development and Maintenance Procedure

Ownership

This document is owned and maintained by the ICT Deanship of University of Imam Abdulrahman bin

Faisal.



Page 11 of 17

Policy Statements

The following subsections present the policy statements in 13 main aspects:

Information Security Requirements Analysis and Specification

Securing Application Services on Public Networks

Protecting Application Services Transactions

Secure Development Policy

System Change Control Procedures

Technical Review of Applications after Operating Platform Changes

Restrictions on Changes to Software Packages

Secure System Engineering Principles

Secure Development Environment

Outsourced Development

System Security Testing

System Acceptance Testing

Protection of Test Data

Information Security Requirements Analysis and Specification

1. Information security requirements for new systems or enhancements to existing systems shall

be analyzed and necessary controls shall be introduced through a formal process.

2. As part of software development lifecycle (e.g., design and deployment), ICT Deanship shall

consider the following aspects:

a. Ensure that system development or acquisition activities are performed according to

the documented requirements, standards, procedures, IAU’s business processes and

best practices.

b. Ensure that sufficient controls (e.g., segregation of duties) are in place to mitigate the

risk of information loss, error or misuse from system.



Page 12 of 17

c. Ensure that a system security plan is adequately documented and maintained for each

system.

d. Ensure to define, document, implement and monitor system specific risk based

security controls for all key systems supporting its operations.

3. ICT Deanship in cooperation with Information Security Officer shall conduct a security threat

and risk assessment during the requirements phase when developing, implementing major

changes to, or acquiring a system to:

a. Identify the necessary security requirements (e.g., interfaces to logging, monitoring

and data leakage) to safeguard the system.

b. Assign system security classification.

[ISO/IEC 27001: A.14.1.1]

Securing Application Services on Public Networks

1. All information involved in application services passing over public networks shall be

protected from fraudulent activity, contract dispute, and unauthorized disclosure and

modification. The following security controls shall be considered:

a. Secure authentication method (e.g., public key cryptography or digital signatures).

b. Resilience requirements against attacks (e.g., Denial of Service “DoS”).

c. Documentation agreement with suppliers (if needed).

2. The integrity of information being made available on a publicly available system (e.g., IAU’s

website) shall be protected from unauthorized modification. The following shall be

considered, but not limited to:

a. IAU’s website shall only be developed and maintained by properly qualified and

authorized personnel.

b. All changes to the website shall be documented and processed through IAU’s Change

Management Procedure.

c. Appropriate warning message shall be provided on the website that no information

may be copied and reproduced without elementary copyright notices.

d. Information obtained from Internet sources shall be verified before used for IAU’s

business purposes.



Page 13 of 17

[ISO/IEC 27001: A.14.1.2]

Protecting Application Services Transactions

1. All information involved in online transactions shall be protected in order to prevent

incomplete transmission, misrouting, unauthorized disclosure, unauthorized message

alteration, unauthorized message duplication or replay.

2. For all application service transactions, the followings shall be considered between all parties:

a. Verification of a secure authentication.

b. Encryption of communications path.

c. Preservation of data privacy.

d. Confidentiality of transactions.

[ISO/IEC 27001: A.14.1.3]

Secure Development Policy

1. ICT Deanship shall define and implement rules that govern the development of software

within IAU. These shall include, but not be limited to:

a. Following a secure software development methodology.

b. Implementing secure coding practices (e.g., standards, baselines and code review).

c. Identifying and fixing security issues (e.g., vulnerabilities).

2. ICT Deanship shall assign qualified and trained software developers and programmers that

are competent to design, test and verify software code according to international best

practices.

[ISO/IEC 27001: A.14.2.1]

System Change Control Procedures

1. ICT Deanship shall ensure that formal system change control procedures are adequately

documented and enforced.

2. ICT Deanship shall ensure that all changes to systems are accurately tested, recorded,

updated, and maintained. This shall include, but not be limited to:



Page 14 of 17

a. All changes or installation of new software are tested in a test environment.

b. A testing environment is totally separated from a production environment.

c. Implementation of changes is place at appropriate time and does not affect negatively

on IAU’s business process.

[ISO/IEC 27001: A.14.2.2]

Technical Review of Applications after Operating Platform Changes

1. Prior to installation, new or different versions of the operating platform shall be subjected to

the established change management process as per IAU’s business requirements.

2. A technical review of the applications controls and integrity shall be conducted prior to all

non-emergency deployments into production. The controls shall be consistent with the

information security architecture and approved by Management as part of the formal change

management process.

3. System capacity requirements shall be planned before introduction of a new critical business

application and reviewed during upgrades. Due precautions shall be taken to avoid any

availability issues of existing within applications or systems.

[ISO/IEC 27001: A.14.2.3]

Restrictions on Changes to Software Packages

1. Documenting of change management and impact analysis on an ongoing basis for application

changes shall be part of system development lifecycle as per IAU’s business requirements.

2. Modifications to software packages shall be discouraged. As far as possible and practicable,

vendor software packages shall be used without any modification.

3. A software patch management process shall be implemented to ensure the most up-to-date

approved patches and updated. The followings shall be considered:

a. Software is updated with the latest vendor provided/approved patches and

configuration to manage risks.

b. Vendor configuration hardening procedures are implemented to protect software

from security threats.

[ISO/IEC 27001: A.14.2.4]



Page 15 of 17

Secure System Engineering Principles

1. ICT Deanship shall define, document, maintain and implement principles for engineering

secure systems in all architecture design layers (e.g., business, data, applications and

technology). These principles shall be reviewed and updated in a regular basis.

2. Appropriate validation checks for input and output, and processing controls shall be applied

to applications and database in order to:

a. Validate input and output data.

b. Detect corruption of information whether resulting from processing errors or

deliberate acts.

c. Validate the correct and appropriate processing of stored information.

3. ICT Deanship shall ensure the validity and integrity of data input to systems by:

a. Limiting fields to accept specific ranges of data (e.g., defining out of range values or

upper and lower data volume limits).

b. Checking for invalid characters in data fields.

c. Making key fields mandatory.

d. Verifying the acceptability of input data using business rules.

e. Protecting against common attacks (e.g., buffer overflows, DoS, DDoS);

f. Using control balances to verify complete input and processing.

4. ICT Deanship shall define and documents responsibilities of all technical team (e.g.,

developers, system analysts and system designers) involved in data input and output

processes.

[ISO/IEC 27001: A.14.2.5]

Secure Development Environment

1. ICT Deanship shall establish a secure development environment (including people, processes

and technology) as part of software development lifecycle requirements. The requirements

shall cover the following aspects:

a. Sensitivity of data.



Page 16 of 17

b. Applicability of internal policies and external regulations.

c. Implementation of security measures.

d. Segregation between various development environments.

e. Level of access and authentication methods.

f. Control of change.

g. Data transfer from and to development environment.

[ISO/IEC 27001: A.14.2.6]

Outsourced Development

1. Requirements for outsourced system development shall include, but not be limited to:

a. Compliance with an acceptable system development and maintenance methodology.

b. Proper monitoring and supervising of activities (e.g., testing and user acceptance).

[ISO/IEC 27001: A.14.2.7]

System Security Testing

1. ICT Deanship shall test security features and functions within a system during development

processes such as:

a. Access control and authentication methods.

b. Privilege assignment and management.

c. Backup and data recovery.

d. Data encryption and privacy.

[ISO/IEC 27001: A.14.2.8]

System Acceptance Testing

1. ICT Deanship shall ensure that the requirements and criteria for acceptances of new systems

are clearly defined, agreed, documented and tested. The following criteria shall be

considered, but not be limited to:

a. Performance and system capacity requirements.



Page 17 of 17

b. Error recovery, restart procedures and contingency plans.

c. Preparation and testing of routine operating procedures.

d. Agreed set of security controls in place.

e. Business continuity arrangements.

f. Evidence that installation of the new hardware does not adversely affect existing

control and automation systems, particularly at peak processing times (e.g., in the

daytime).

g. Evidence that consideration has been given that new hardware has no impact on the

overall security of IAU’s systems.

h. Training on the operation or use of new equipment.

i. Warranties and support for maintenance.

[ISO/IEC 27001: A.14.2.9]+

Protection of Test Data

1. All security controls implemented in a production environment shall be applied to a test

environment to ensure a proper protection of test data. The followings shall be considered:

a. In special and pre-approved cases where access to production data is required to

develop or test business applications or systems, only “Read” and “Copy” access

permission is granted and shall be revoked upon the successful completion of the

task.

b. A separate authorization shall be required every time production data is copied to the

development or test environment.

c. Any copies of production information used in a development or testing environment

shall be erased immediately upon completion of such tasks.

-------------------------------------------------------- End of Document ------------------------------------