Information Security Department

Secure Solutions Delivery Life Cycle

Framework

Developed and written by

Information Security Assurance
Riyad Bank, Olaya Towers, Tower-B, 8th Floor

 +966-11-204 6600 x 3838

Version 1.0
Last Updated 06 December 2017
Documented Information Classification level Internal Use Only
Documented Information Owner ISD – IS Assurance
Next Review Date December 2019
Status Final

© Copyright 2017 Riyad Bank. All rights reserved.

 SECURE SDLC FRAMEWORK

Document created by
Shakeel Shaikh, AVP – Head of Information Security Assurance

Document reviewed by
Aiedh Al-Zahrani, EVP – Head of Business Technology Division
Hosain Al-Malky, SVP – Mgr., Solutions Development & Delivery Dept.
Husam Al-Suliman, SVP – Head of Information Security Department
Hasan Abdullah Al-Amri, SVP – Acting Manager of BT Infrastructure Dept.
Rashed Al-Sheban, VP – Head of BT Change Mgmt. Section
Mohammed A Aziz, AVP - Head of Security Governance and Risk
Rabea J Al-Muzin, AVP – Acting Manager of PMO
Nouf F Bin Tamran, Acting Head of UAT Section

INTERNAL USE ONLY 1

 SECURE SDLC FRAMEWORK

Contents
1. Introduction 3
2. Purpose of the Framework 3
3. Scope 3
4. References 3
5. Assumptions & Constraints 4
6. Roles and responsibilities 5
7. Secure SDLC Process 7
8. Concept 8
9. Acquisition 10
10. Planning 13
11. Design 14
12. Development 16
13. Build 17
14. Testing 20
15. Implementation and Post Implementation 22
16. Operations and Maintenance 23
17. Disposal 24
18. Executive Owner 24
19. Document Custodian 24

INTERNAL USE ONLY 2

 SECURE SDLC FRAMEWORK

1. INTRODUCTION
Riyad Bank is continuously expanding the use of Information Systems to enhance and
expand the services offered to customers, and to optimize the internal business processes.
Introduction of every new system expose the Bank to various security risks. Information
Security risks have to be assessed and mitigated before any system can be used to support
the Bank’s business.

Riyad Bank has established a Solutions Delivery Life Cycle (‘SDLC’) framework for the
acquisition of new systems. Information Security should be addressed in all the stages of
the Bank’s SDLC to effectively address Information Security risks of new systems.
Information Security processes portrayed in this document should be catered in all project
management methodologies and change management processes.

Information Security should be involved at the earliest stage and subsequently in all stages
of the SDLC. The benefits of early and continuous involvement of Information Security
includes:

- It is less expensive to implement security controls in the early stages of projects

and changes.
- Security risks can be discovered in the early stage.
- It helps in delivering solution within the time to market requirements.
- Better security controls can be designed by participating in all stages of SDLC.
- Information Security becomes enabler in the solutions delivery process.

2. PURPOSE OF THE FRAMEWORK

The objectives of the Secure SDLC framework is to depict the involvement of Information
Security in SDLC processes, as outlines below:

- Document interaction of Information Security processes with SDLC processes.

- Provide an overview of activities performed by ISD while participating in projects.
- Describe the activities expected from related parties.
- Document the roles and responsibilities of all related stakeholders.
- Cover all project methodologies from security point of view.

3. SCOPE
The scope of this framework includes all technology-oriented projects in the Bank that are
registered with the Project Management Office. Technology-oriented projects following any
project management methodology will be within the scope of this framework.

4. REFERENCES
• ISP Policy
• Access Management Policy and Framework

• Encryption Policy
• Information Security Classification Policy

• System Development, Acquisition and Maintenance Security Policy

INTERNAL USE ONLY 3

 SECURE SDLC FRAMEWORK

• Application security Requirement Standard

• Secure Code Security Guideline

• System Secure Engineering Standard

• Risk Assessment Process

• ISRA Methodology
• Penetration Testing Methodology

• Change Management Policy

• PCI and ISO Standards

• NIST 800-64

5. ASSUMPTIONS & CONSTRAINTS

This framework document and the processes described herein are based on the Solution
Delivery Life Cycle (SDLC) document, Version 2.22, dated 1st April 2009.

All implementations of technology projects in the Bank follow the above stated SDLC
methodology.

Secure SDLC Framework will operate independent of the Bank’s SDLC; while there will be
close interaction and integration with it.

BTD and BTG will modify their applicable processes to adhere to SDLC and Secure SDLC.

Bank’s SDLC and appropriate processes will incorporate the requirements of this
framework.

ISD will follow risk based approach in performing, not-performing, or expanding the scope
of tasks within the ISD responsibilities.

A new phase called ‘Planning’ has been added in the Secure SDLC, although it does not
exist in the Bank SDLC. Project Manager may execute this phase in the initial stages of
the project, as suitable. In this document, it is assumed that the planning phase will be
executed after the acquisition phase.

A new phase called ‘Development’ has been added in the Secure SDLC, although it does
not exist in the Bank SDLC. This phase is exclusively meant for software development.
This phase is not applicable to the projects wherein off-the-shelf systems are purchased
from the vendors (wherein source code is not created or is not held with the Bank).

While all actions shown in this document are shown as manual activities, some of them are
either automated or could be automated. Even though the activities are automated, the
responsible team will be accountable for the respective activity, in case automated
functions could not be performed by the respective system.

All relevant stakeholders will produce documents that are required to fulfill the
requirements in the SDLC and the Secure SDLC.

INTERNAL USE ONLY 4

 SECURE SDLC FRAMEWORK

6. ROLES AND RESPONSIBILITIES

Roles and responsibilities of ISD:

Building of Operations,
Implementation &
Infrastructure and Testing (SIT & UAT) Maintenance &
Concept Acquisition Planning Design Development Post Implementation
Disposal
Application

ISD Representative Provide security Provide security Security Post Information

Maintain Security
in Steering requirements for architecture and Integration Testing implementation Security policies
Architecture
Committee BRD design review plan (ArcSight, cyber security and standards
Diagrams and PCI
Guardium, controls
Data-flows
Tripwire, LDAP, verification
ISD Representative Provide security Provide security etc.) (SIT) Security
(Includes ISRA
in Project Review requirements in integration testing Configuration
Ensure compliance control validation)
Team RFP plan Baselines
with Security Cyber Security
Architecture Controls testing
Evaluate proposals (UAT) Penetration testing
IS Risk Assessment Provide security (Internal\External Security event
(as applicable in from CIS acceptance testing as applicable) monitoring
case of SAMA perspective plan Penetration testing
requirement) (Internal\External
Provide post as applicable)
Ensure security
implementation (UAT)
requirements in
security activities
Scope of Work
plan
Maintain Security
Architecture
Diagrams and PCI
Threat Profiling Data-flows

IS Risk Assessment

INTERNAL USE ONLY 5

 SECURE SDLC FRAMEWORK

Roles and responsibilities of Non-ISD:

System
Building of Operations,
Integration and Implementation &
Infrastructure and Maintenance &
Concept Acquisition Planning Design Development User Acceptance Post Implementation
Disposal
Application Testing

PMO: Request ISD BA: Notify ISD for PMO: Invite ISD to BTD: Adherence to
PMO: Create BTD: Scan source BTD: Install OS\ CMD: Notify ISD of
for Steering security provide the plans SIT: Notify ISD of the Information
security design code for security Database \ release to
Committee requirements of security SIT initiation Security Policies
document vulnerabilities Application and production
representative activities and Standards
BA: Incorporate configure as per
PMO: Request ISD security BTD: Fix all the baseline
PMO: Incorporate UAT: Notify ISD of
for Project Review requirements in vulnerabilities and UAT initiation BTD: Fix security BTD: Notification of
plans of security
Team BRS\BRD ensure clean issues Change Requests
activities in Master
representative source code scan BTD: Apply security
Project Plan
PMO: Notify ISD for report patches
BTD: Apply security BTD: Notification
RFP review BTD: Notify ISD
configuration (as from relevant team
BTD: Retain clean applicable) upon production
BTD: Perform VM about the disposal
PMO: Incorporate scan report deployment
scan and baseline of production data
security
scans and retain used in UAT
requirements in RFP BTD: Maintain
BTD: Inform ISD clean reports
System Security
PMO: Invite ISD to about clean source
Design BTD: Notification of
evaluate proposals code scan
BTD: Install and disposal of systems
configure security
PMO: Notify ISD tools (ArcSight,
upon Business Case Guardium,
approval Tripwire, etc.)

PMO: Notify ISD for

Scope of Work BTD: Inform ISD
review about completed
hardening process
PMO: Incorporate
security
requirements in
SoW

INTERNAL USE ONLY 6

 SECURE SDLC FRAMEWORK

7. SECURE SDLC PROCESS

Secure SDLC maps to the Bank’s existing SDLC process. However, it has been made more
granular to address specific phases that are more relevant for Information Security.

Although Secure SDLC process applies to all Agile and Non-Agile projects, the Secure SDLC
process will be revised upon availability of Agile Project Management methodology of Riyad
Bank.

Secure SDLC processes applicable to Non-Agile projects have been divided into following
phases:

Implement
User ation & Operations,
Integration Maintenanc
Concept Acquisition Planning Design Development Build Testing Acceptan Post
e, &
ce Testing implement Disposal
ation

Participation and roles of all relevant stakeholders in various phases of Secure SDLC has
been described in the subsequent sections. Each stakeholder should incorporate associated
Secure SDLC requirements into all relevant processes.

Process flowcharts in this document have been illustrated from Secure SDLC perspective.

INTERNAL USE ONLY 7

 SECURE SDLC FRAMEWORK

8. CONCEPT
During the concept phase, a steering committee and a technical review committee are
formed. Formation of the committees depends upon the type and complexity of the
project.

If a steering committee is being formed for a project, then Information Security shall be
invited to participate in the steering committee. If a technical review committee is being
formed for a project, then Information Security shall be invited to participate in the
technical review committee.

Following flow chart illustrates the process of Concept phase:

Project Sponsor
Dept.

Create PCD
Technology
Committee

Approval of PCD NO

YES
Concept Phase

Notify stake holders

Notify all
PMO

for Steering\Technical Form Steering Form Technical

Register Project stakeholders about
Committee Committee Review Committee
the committees
participation
ISD Management

Assign ISD
Assign ISD
representative in
representative in
Technical Review
Steering Committee
Committee
ISD Representative

IS Risk Assessment
Notify all ISD
(Applicable if SAMA
stakeholders about
approval is
the project
required)

Key definitions:

Project Sponsor Dept.: The department who benefits the most from the initiative and
who is responsible to get the PCD approved by technical committee.

Inputs to ISD:

- Notification from PMO about the new project, formation of Steering Committee, and
formation of Project Review Team.
- Project Concept Document

INTERNAL USE ONLY 8

 SECURE SDLC FRAMEWORK

Outputs from ISD:

- Assignment of representative in Steering Committee.

- Assignment of representative in Project Review Team.
- IS Risk Assessment (Risk register - Applicable if SAMA approval is required.)

Artifacts necessary:

No artifacts are requires in this phase.

INTERNAL USE ONLY 9

 SECURE SDLC FRAMEWORK

9. ACQUISITION
Discovery phase, Approval phase, and Acquisition phase from the Bank SDLC have been
combined into a single Acquisition phase in Secure SDLC.

Acquisition phase in Secure SDLC has been divided in three major activities:

 Security requirements
 Security participation in solution selection
 Security review of Scope of Work

Security Requirements, which will be provided during the Requirements Gathering stage,
shall be only high level requirements to be addressed at an overall solution level.

Following flow charts illustrate the process of Acquisition phase. Each activity in the
Acquisition phase has been shown in a separate flow chart.

Security requirements:
Project Sponsor
Dept.
Business Analyst

Notify ISD for Incorporate security

security requirements in
requirements BRS\BRD
Acquisition Phase – Security requirements

PMO
ISD representative

Send and retain

Consolidate security
Inform ISD teams security Approve BRS\BRD
requirements
requirements

Security requirements
for the system
Security Analyst
Information

Assess security
related regulatory
requirements
applicable to the
system
Security Control
Requirements
Standard

Key definitions:

Business Analyst: The person responsible for documenting all the requirements.

Information Security Analyst: The person responsible to provide Information Security

requirements.

INTERNAL USE ONLY 10

 SECURE SDLC FRAMEWORK

Inputs to ISD:

- Notification from Business Analyst (‘BA’) about collection of Business Requirements.

The notification can be automated through a system. BA will be accountable to
ensure that ISD representative receives such notification.
- Business Requirement Document

Outputs from ISD:

- Security requirements to be added into BRD (ISD will define some security
requirements as functional requirements.)
- Approval of Business Requirements Document.

Artifacts necessary:

- Security Control Requirements Standard.

Security participation in solution selection:

Project Sponsor
Dept.

Get the Business

Select solution
Case approved
Acquisition Phase – Security participation in solution selection

Issue RFP and Invite Notify all stake

PMO

Notify ISD for RFP Incorporate security Invite ISD to

proposals from holders about
review requirements in RFP evaluate proposals
vendors selected solution
Technical Review
Committee

Evaluate proposals
for technical
requirements
ISD representative

Share security Notify ISD

Submit evaluation
Inform ISD teams requirements to be stakeholders about
of proposals
added in RFP selected solution
ISD teams

Review RFP to Evaluate proposals

Provide security for compliance with
ensure security Create Threat
requirements\ security IS Risk Assessment
requirements are Profile
comments for RFP requirements
addressed
Security requirements Security requirements
for the system incorporated in RFP

Inputs to ISD:

- Notification from Project Manager about creation of RFP.

- Notification from Project Manager about evaluation of proposals.
- Request for Proposals.
- Technical Proposals.

INTERNAL USE ONLY 11

 SECURE SDLC FRAMEWORK

- Notification upon approval of Business Case

Outputs from ISD:

- Security requirements to be incorporated in the RFP.

- Evaluation of the proposals.

Artifacts necessary:

- Security Control requirements for the system.

Security review of Scope of Work:

Project Sponsor
Dept.
Acquisition Phase – Security review of Scope of Work

Incorporate security
PMO

Notify ISD for Scope requirements in

of Work review SoW
Technical Review
Committee
ISD representative

Send security
Inform ISD teams requirements\
comments for SoW
ISD teams

Review SoW to
Provide security
ensure security
requirements\
requirements are
comments for SoW
addressed
Security requirements
incorporated in RFP

Inputs to ISD:

- Notification from Project Manager to review Scope of Works.

- Scope of Works.

Outputs from ISD:

- Security requirements to be incorporated in Scope of Works.

Artifacts necessary:

- Security Control requirements for the system.

INTERNAL USE ONLY 12

 SECURE SDLC FRAMEWORK

10. PLANNING
Following flow chart illustrates the process of Planning phase:
Project Sponsor
Dept.

Invite ISD to provide Incorporate plans of

PMO

the plans of security security activities in

activities Master Project Plan
Technical Review
Committee
Planning

ISD representative

Consolidate security
Notify ISD teams to
plans & send them
provide their plans
to PMO
ISD teams

Provide post
Provide security Provide security Provide security
implementation
architecture and integration testing acceptance testing
security activities
design review plan plan plan
plan

Inputs to ISD:

- Notification from Project Manager to provide ISD plans

Outputs from ISD:

- Security architecture and design review plan

- Security integration testing plan
- Security acceptance testing plan
- Post implementation security activities plan

Artifacts necessary:

- Master plan of Information Security activities

INTERNAL USE ONLY 13

 SECURE SDLC FRAMEWORK

11. DESIGN
Following flow chart illustrates the process of Design phase:
Application Design team

Create a technical Create security Revise Security

design document design document Design as per the
feedback
System security
design
Architecture team

Review technical
design and share
with ISD
Design

ISD representative

Share technical
design and security
design with the ISD
stake holders

Maintain Security
ISD teams

Ensure compliance Ensure compliance

Architecture Inform any non- Approve security
with Security with Security Not OK
Diagrams and PCI compliance design
Requirements Architecture
Data-flows

OK

Key definitions:

Application Design team: The team responsible for documenting the technical design
document and security design document. This is a logical role which can be fulfilled by any
physical team.

Architecture team: The team responsible for the review and approvals of the technical
design document.

Inputs to ISD:

- Notification from Application Support team or BTD Design team about the starting
of system design.
- Technical Design Document
- Security Design Document

Outputs from ISD:

- Approval of Security Design Document.

INTERNAL USE ONLY 14

 SECURE SDLC FRAMEWORK

- Security network and connectivity

- PCI Data Flows (Applicable if the application is in PCI Scope.)
- Security architecture diagrams
- Applicable standards and allowed services.

Artifacts necessary:

- Security Controls Standard

- Security Architecture Principles

INTERNAL USE ONLY 15

 SECURE SDLC FRAMEWORK

12. DEVELOPMENT
This phase is applicable to only those projects, where software code is either developed
inside the Bank or owned by the Bank. Following flow chart illustrates the process of
Development phase:
Project Sponsor
Dept.

Fix all vulnerabilities

Check in completed Scan source code Inform ISD about
and ensure clean Retain clean scan
Write software code code in the for security clean source code
source code scan report
repository vulnerabilities scan
Developers

report
Development

Source Code
Repository
ISD representative
ISD teams

Secure Coding Security risks

Standard And Controls

Key definitions:

Developer: The person who write source code.

Inputs to ISD:

- Notification from developers about clean source code vulnerability scan

Outputs from ISD:

- No outputs from ISD

Artifacts necessary:

- Secure Coding Standard

- Security risks and controls related to the system

INTERNAL USE ONLY 16

 SECURE SDLC FRAMEWORK

13. BUILD
Build phase in Secure SDLC has been divided in three major activities:

 Operating system installation

 Database installation
 Application installation

Build phase is applicable for each environment being built for the application, e.g.
development environment, testing environment, production environment, etc.

Following flow charts illustrate the process of Build phase. Each activity in the Build phase
has been shown in a separate flow chart.

Operating system installation:

BT SDD team
BT Infrastructure team

Perform VM scan Install and configure

Install OS and Apply patches and Inform ISD about
and baseline scans security control software
Build – Operating System Installation

configure as per the other configurations completed

and retain clean (ArcSight, Guardium,
baseline as applicable hardening process
reports Tripwire, etc.)
ISD representative
ISD teams

Baseline Security
Standards

Inputs to ISD:

- Notification from BT Infrastructure team about completion of hardening process

Outputs from ISD:

- No outputs from ISD.

INTERNAL USE ONLY 17

 SECURE SDLC FRAMEWORK

Artifacts necessary:

- Baseline security standards

Database installation
BT SDD team
BT Infrastructure team

Perform VM scan Install and configure

Install Database and Apply patches and Inform ISD about
Build – Database Installation

and baseline scans security control software

configure as per the other configurations completed
and retain clean (ArcSight, Guardium,
baseline as applicable hardening process
reports Tripwire, etc.)
ISD representative
ISD teams

Baseline Security
Standards

Inputs to ISD:

- Notification from BT Infrastructure team about completion of hardening process.

Outputs from ISD:

- No outputs from ISD

Artifacts necessary:

- Baseline security standards

INTERNAL USE ONLY 18

 SECURE SDLC FRAMEWORK

Application installation
Application deployment
team

Install Application Install and configure Inform ISD about

Apply security
and configure as per security tools (ArcSight, completed
patches
the baseline Guardium, Tripwire, etc.) hardening process
BT Infrastructure team
Build – Application Installation

ISD representative
ISD teams

Security requirements System security

for the system design

Key definitions:

Application Deployment team: The team responsible to install applications in servers.

This is a logical role which can fulfilled by any suitable physical team.

Inputs to ISD:

- Notification from Solution Delivery team about completion of application hardening

process

Outputs from ISD:

- No outputs from ISD.

Artifacts necessary:

- Security requirements for the system.

INTERNAL USE ONLY 19

 SECURE SDLC FRAMEWORK

14. TESTING
Testing phase in Secure SDLC has been divided in two major activities:

 Integration Testing
 User Acceptance Testing

Integration testing
Following flow chart illustrates the process of Integration Testing phase:
SIT Section

Notify ISD of SIT

initiation
deployment team
Application

Apply security Maintain System

Testing - System Integration Testing

configuration Security Design

ISD Representative

Security integration
testing clearance

Notify ISD teams for

OK
integration testing
Consolidate security
Not OK issues to be
addressed
ISD teams

Security Integration Maintain Security

Testing (ArcSight, Architecture
Guardium, Tripwire, Diagrams and PCI
LDAP, etc.) Data-flows

Inputs to ISD:

- Notification from SIT team about the starting of SIT

Outputs from ISD:

- Clearance from Security System Integration Testing stage

Artifacts necessary:

- Security requirements for the system

- System security design

INTERNAL USE ONLY 20

 SECURE SDLC FRAMEWORK

User Acceptance Testing

Following flow chart illustrates the process of User Acceptance Testing phase:
deployment team
Application

Apply security Maintain System

configuration Security Design
UAT Section

Notify ISD of UAT

initiation
Testing – User Acceptance Testing

ISD Representative

Security acceptance
testing clearance

Notify ISD teams for OK

UAT Consolidate security
Not OK issues to be
addressed
ISD teams

Maintain Security
Penetration testing Architecture
Cyber Security
(Internal\External as Diagrams and PCI
Controls testing
applicable) Data-flows

Inputs to ISD:

- Notification from UAT team about the starting of UAT

- Implementer should attain and retain business approval to copy production data in
UAT (if applicable).

Outputs from ISD:

- Clearance from Security Acceptance Testing stage

- Observations on open defects (Defects not closed before releasing from UAT will be
converted into IS observations without requiring explicit approvals.)

Artifacts necessary:

- Security requirements for the system

- System security design

INTERNAL USE ONLY 21

 SECURE SDLC FRAMEWORK

15. IMPLEMENTATION AND POST

IMPLEMENTATION
Following flow chart illustrates the process of Implementation and Post Implementation
phase:
Release Section

Clearance for
Notify ISD of release
production use of
to production
the system
deployment team
Application
Implementation and Post Implementation

Notify ISD upon

Deploy in
Fix security issues production
production
deployment
OK

Consolidated
ISD Representative

Inform ISD teams Security Report of

for production the Project
Not OK
verification
Verify if all security
issues are
OK
addressed
Consolidate security
issues to be
addressed

Not OK
ISD teams

Post implementation cyber

Penetration testing
security controls verification
(Internal\External as Create observations
(Includes ISRA control
applicable)
validation)

Inputs to ISD:

- Notification from Release Management team about the production release of the
system.
- Notification from Application Support team about production deployment of the
application.

Outputs from ISD:

- Clearance for production use of the application

- Observations on unaddressed issues (Issues not addressed will be converted into
IS observations without requiring explicit approvals.)
- Consolidated Security Report of the Project

Artifacts necessary:

- Security requirements for the system

- System security design

INTERNAL USE ONLY 22

 SECURE SDLC FRAMEWORK

16. OPERATIONS AND MAINTENANCE

All applicable teams to define and follow procedures to be in compliant with the Information
Security policies and standards, as relevant to their operational functions.

Inputs to ISD:

- Notification of Change Requests

Outputs from ISD:

- Information Security policies and standards

- Security Configuration Baselines
- Security event monitoring

Artifacts necessary:

- Information Security Regulatory Requirements

- Industry Security standards and best practices

Outputs from BTD:

- Adherence to the Information Security Policies and Standards such as (but not
limited to):
o Vulnerability Patching
o Baseline compliance

INTERNAL USE ONLY 23

 SECURE SDLC FRAMEWORK

17. DISPOSAL
All applicable teams to define and follow procedures to be in compliant with the Information
Security disposal policies and standards, as relevant to their operational functions.

Inputs to ISD:

- Notification from relevant team about the disposal of production data used in UAT
- Notification of disposal of systems

Outputs from ISD:

- Disposal policy

Artifacts necessary:

- Disposal policy

18. EXECUTIVE OWNER

Senior Vice President, Head of Information Security Department

19. DOCUMENT CUSTODIAN

Information Security Assurance,
Olaya Towers, Tower-B, 8th Floor.

INTERNAL USE ONLY 24