S YSTEM A CQUISITION , D EVELOPMENT AND M AINTENANCE P OLICY
Version 1.0 Policy Number:
Page 2/17
1. Table of Contents
1. Table of Contents ... 2
2. Property Information ... 3
3. Document Control ... 4
3.1. Information ... 4
3.2. Revision History ... 4
3.3. Review, Verification and Approval ... 4
3.4. Distribution List ... 4
4. Policy Overview ... 5
4.1. Purpose ... 5
4.2. Scope ... 5
4.3. Terms and Definitions ... 5
4.4. Change, Review and Update ... 8
4.5. Enforcement / Compliance ... 8
4.6. Waiver ... 8
4.7. Roles and Responsibilities (RACI Matrix) ... 9
4.8. Relevant Documents ... 9
4.9. Ownership ... 10
5. Policy Statements ... 11
5.1. Information Security Requirements Analysis and Specification... 11
5.2. Securing Application Services on Public Networks ... 12
5.3. Protecting Application Services Transactions ... 13
5.4. Secure Development Policy ... 13
5.5. System Change Control Procedures ... 14
5.6. Technical Review of Applications after Operating Platform Changes ... 14
5.7. Restrictions on Changes to Software Packages ... 14
5.8. Secure System Engineering Principles ... 15
5.9. Secure Development Environment ... 16
5.10. Outsourced Development ... 16
5.11. System Security Testing ... 17
5.12. System Acceptance Testing ... 17
5.13. Protection of Test Data ... 18
Page 3/17
2. Property Information
This document is the property information of Imam Abdulrahman bin Faisal University - ICT Deanship. The content of this document is Confidential and intended only for the valid recipients. This document is not to be distributed, disclosed, published or copied without ICT Deanship written permission.
Page 4/17
3. Document Control
3.1. Information
Title Classification Version Status
SYSTEM ACQUISITION, DEVELOPMENT AND MAINTENANCE POLICY
Confidential 1.0 validated
3.2. Revision History
Version Author(s) Issue Date Changes
0.1 Alaa Alaiwah - Devoteam November 18, 2014 Creation
0.2 Nabeel Albahbooh - Devoteam December 1, 2014 Update
1.0 Muneeb Ahmad – ICT, IAU 18 May 2017 Update
3.3. Review, Verification and Approval
Name Title Date
Lamia Abdullah Aljafari Quality Director
Dr. Saad Al-Amri Dean of ICT
3.4. Distribution List
Copy # Recipients Location
Page 5/17
4. 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.
4.1. 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.
4.2. 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 Risk Assessment Scope Document and will be used as foundation for information security management.
4.3. Terms and Definitions
Table 11 provides definitions of the common terms used in this document.
Term Definition
Accountability A security principle indicating that individuals shall be able to be
Page 6/17
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.
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
Page 7/17
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.
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
Page 8/17
4.4. 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.
4.5. 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.
4.6. 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.
Page 9/17
4.7. Roles and Responsibilities (RACI Matrix)
Table 2 shows the RACI matrix1 that identifies who is responsible, accountable, consulted or informed for every task that needs to be performed.
There are a couple of 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 Supplier Owner User
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
4.8. Relevant Documents
The followings are all relevant policies and procedures to this policy:
Information Security Policy
Organization of Information Security policy
Access Control Policy
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 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 stand for Informed who is kept up-to-date on task progress.
Page 10/17
Operations Security Policy
Communications Security Policy
Suppliers Relationships Policy
Compliance Policy
Risk Management Policy
Change Management Procedure
Patch Management Procedure
Systems Acquisition, Development and Maintenance Procedure
4.9. Ownership
This document is owned and maintained by the ICT Deanship of University of Imam Abdulrahman bin Faisal.
Page 11/17
5. 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
5.1. 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.
Page 12/17
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.
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]
5.2. 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.
Page 13/17
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.
[ISO/IEC 27001: A.14.1.2]
5.3. 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]
5.4. 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]
Page 14/17
5.5. 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:
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]
5.6. 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]
5.7. 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.
Page 15/17
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]
5.8. 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);
Page 16/17
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]
5.9. 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.
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]
5.10. 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]
Page 17/17
5.11. 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]
5.12. 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.
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]
Page 18/17
5.13. 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 ---
