software security and quality assurance (ssqa) …...this software security standard defines the...

of 17 Title: Software Security and Quality Assurance (SSQA) Level 1 Security Standard Version: 1.0 Classification: PUBLIC

Software Security and Quality Assurance

(SSQA) Level 1 Security Standard

Achieving the Minimum Standards Expected for

Software Security and Quality Assurance


Document Control Approval

Name Role Date of Approval Version Number

Ashraf Ali-Ismael NISCF Compliance

Manager 08/10/2018 1.0

The standard is owned by the Ministry of Transport and Communications (MOTC) who shall update as

necessary.

DISCLAIMER: The implementation of the Software Security and Quality Assurance (SSQA) Controls are

required as part of the State of Qatar’s strategy to enhance cyber security.

Risk, particularly in information systems, cannot be completely removed through the implementation of

controls. It is for this reason that the implementation of the controls identified within this standard,

while required to improve the quality and security of software development activities, cannot substitute

effective risk analysis and risk management practices which should continue to be practiced by all

Agencies.


Table of Contents

Legal Mandate(s) .......................................................................................................................................... 4

Introduction .................................................................................................................................................. 6

Scope ............................................................................................................................................................ 7

Purpose ......................................................................................................................................................... 7

Deviation process ......................................................................................................................................... 7

Throughout-Lifecycle Controls ..................................................................................................................... 8

Inception and Design Phase Controls .........................................................................................................12

Construction and Development Phase Controls ........................................................................................14

Transition and Testing Phase Controls .......................................................................................................15

Production and Operations Phase Controls ...............................................................................................17


Legal Mandate(s) Emiri decision No. (8) for the year 2016 sets the mandate for the Ministry of Transport and

Communication (hereinafter referred to as “MOTC”) provides that MOTC has the authority to

supervise, regulate and develop the sectors of Information and Communications Technology (hereinafter

“ICT”) in the State of Qatar in a manner consistent with the requirements of national development goals,

with the objectives to create an environment suitable for fair competition, support the development and

stimulate investment in these sectors; to secure and raise efficiency of information and technological

infrastructure; to implement and supervise e-government programs; and to promote community

awareness of the importance of ICT to improve individual’s life and community and build knowledge-

based society and digital economy.

Article (22) of Emiri Decision No. 8 of 2016 stipulated the role of the Ministry in protecting the security of

the National Critical Information Infrastructure by proposing and issuing policies and standards and

ensuring compliance.

This guideline has been prepared taking into consideration current applicable laws of the State of Qatar.

In the event that a conflict arises between this document and the laws of Qatar, the latter, shall take

precedence. Any such term shall, to that extent be omitted from this Document, and the rest of the

document shall stand without affecting the remaining provisions. Amendments in that case shall then be

required to ensure compliance with the relevant applicable laws of the State of Qatar.


References • [IAP-NAT-IAFW] Information Assurance Framework

• National Information Assurance Policy

A glossary of terms is defined within the Information Assurance Framework, [IAP-NAT-IAFW].


Introduction An ever-increasing reliance upon digital services and technology coupled with the ongoing discovery of

weaknesses which threaten the confidentiality, integrity and availability of digital services and data

presents an ongoing challenge for organizations and governments worldwide.

It is therefore important to make sure that the software applications used by these entities are as

secure as possible, by ensuring that security has been considered within development or procurement

efforts and by also ensuring that such concerns are considered as part of outsourced development

efforts by third-parties.

Secure development is a practice to ensure that the code and processes that go into developing

applications are as secure as possible.

Secure development practices consider security during each development phase or stage, regardless of

chosen development methodology.

Within the context of software security, secure development considers the application of secure coding

practices to transform the traditional Software Development Lifecycle (SDL) into a Secure Software

Development Lifecycle (SSDL).

This software security standard defines the mandatory controls that form the foundations upon a

software security programme can be achieved and represents the minimum requirement of all Agencies

within the State of Qatar.


Scope This standard applies to all Agencies, engaged in the development or implementation of software

solutions, including those which outsource or procure software or digital services.

Purpose The Software Security and Quality Assurance (SSQA) standards, forming part of the SSQA framework

and a subsection of the National Information Assurance Framework (NIAF), are intended to direct

Agencies to compliance with statements concerning the security of software and software development

processes outlined within the National Information Assurance Policy (NIAP).

This standard defines the baseline controls, or minimum measures, that the Ministry of Transport and

Communications (MOTC) expects to be implemented by Agencies, developing or sourcing software

solutions.

Deviation process It is acceptable that an organisation may be forced to deviate from implementing specific security

controls required by the standard on the following grounds:

• The threat is already suitably mitigated to ensure that residual risk is within the

organisation’s risk tolerance

Following completion of a risk assessment it is determined that risk has been reduced to an

acceptable level, or that the resources required for the implementation of controls to reduce

risk further would be of greater cost than the impact of the risk occurrence itself.

• Technical constraints prevent the Implementation of controls – the technology environment

does not allow for the specific control to be applied or the resource requirement to implement

the required control would be of greater cost than the impact of the risk occurrence itself.

In the above cases, the organisation should record alternative or compensating controls that have been

implemented to mitigate risk to an acceptable level. If alternative or compensating controls are not

possible, the organisation should record the residual risk and document management acceptance of the

risk.


Throughout-Lifecycle Controls Many organizations implement controls that either exist outside of the phases of the development

lifecycle, or that permeate through each lifecycle phase.

Such controls can often be thought of as common requirements that impact all software development

projects irrespective of their objective or unique characteristics.

The controls below are to be implemented to enable a consistent baseline upon which project teams

can leverage to inform software security requirements.

Audit and Certification

Control

Code

Control and

Control Objective

Control

Category

SSQA-G-CP1.1

Unify regulatory pressures

Management Appoint the Software Security Group (SSG) as a focal point for understanding the constraints that regulatory requirements impose

upon software and identify overlaps between regulations to remove redundancy and conflict.

Documentation

Control Code

Control and Control Objective

Control Category

SSQA-G-CP1.3

Create policy

Management Utilize the Software Security Group (SSG) to develop or contribute to Software Security Policy that guides the organization by addressing regulatory and customer-driven requirements.

SSQA-I-SR1.1

Create security standards

Management Develop standards, procedures and guidance to support adherence to organizational policy.


Governance

Control Code


Control Category

SSQA-I-SR1.2

Create a security portal

Management Develop a central repository maintained by the Software Security Group (SSG) that contains relevant documentation and resources.

Incident Management

Control Code


Control Category

SSQA-D-

CMVM1.1

Create or interface with incident response

Management

Integrate with the organizations incident response process.

Risk Management

Control Code


Control Category

SSQA-I-AM1.3

Identify potential attackers

Management Develop a record of potential attacker's, categorizing levels of motivation and capability.

SSQA-

SSDLT-AA1.4

Use risk questionnaire to rank applications

Operational

Provide a risk-based categorization of applications and enable prioritization.


Software Security

Control Code


Control Category

SSQA-I-AM1.5

Gather and use attack intelligence

Operational Continually increase knowledge of current attack types and vulnerabilities in the wild.

SSQA-I-SFD1.1

Build and publish security features

Operational Guide project teams by publishing and promoting solutions, pre-approved by the Security Group that can be implemented to prevent developing multiple implementations of similar functionality.

Training and Awareness

Control Code


Control Category

SSQA-G-

SM1.2

Create evangelism role and perform internal marketing

Management

Build support Software Security throughout the organization.

SSQA-G-SM1.3

Educate executives

Operational

Raise awareness of Software Security amongst Senior Management.

SSQA-G-T1.1

Provide awareness training

Operational Promote culture of security across the organization through awareness training.



Control Code


Control Category

SSQA-G-

T1.5

Deliver role-specific advanced curriculum (tools, technology stacks, bug parade)

Operational Build capabilities beyond awareness through tailored role specific training.

SSQA-G-T1.6

Create and use material specific to company history

Operational Tailor training materials to incorporate relevance to the organization using historical references related to the organization.

SSQA-G-T2.5

Deliver on-demand individual training

Operational Reduce training delivery costs and make training more accessible to the organization using on-demand training.


Inception and Design Phase Controls The objective of this phase is to outline business requirements for the solution and development

project as well as develop a solution architecture which is feasible, robust and brings value to

the organization.

The controls documented below shall be implemented to ensure that security and risk management are

core themes addressed during the design of all solutions.

Governance

Control Code


Control Category

SSQA-G-SM1.1

Publish process (roles, responsibilities, plan), evolve as

necessary

Management Establish a suitable Software Security Development Lifecycle (SSDL) methodology and tailor this to the requirements of the development process.

SSQA-G-

SM1.4

Identify gate locations, gather necessary artefacts

Management Determine the location for specific security gates within development processes and identify evidence required for go/no go decisions.

SSQA-I-SFD1.2

Engage SSG with architecture

Management Ensure appropriate integration between the Software Security Group

(SSG) and the Architecture team.

SSQA-

SSDLT-AA1.3

Have SSG lead review efforts

Operational Enhance security design review expertise within the Software Security Group (SSG) and impart knowledge to the architects.


Risk Management

Control Code


Control Category

SSQA-SSDLT-AA1.1

Perform security feature review

Management

Identify weaknesses in the design of application security features.

SSQA-SSDLT-AA1.2

Perform design review for high-risk applications

Management Develop mitigation plans for architectural flaws observed within high-risk applications.

Software Security

Control Code


Control Category

SSQA-G-CP1.2

Identify PII obligations

Management Utilize the Software Security Group (SSG) to promote best practice related to privacy arising from regulation and customer expectations.

SSQA-I-AM1.2

Create data classification scheme and inventory

Management Develop a Data Classification Scheme and inventory software

according to the data processed.

SSQA-I-SR1.3

Translate compliance constraints to requirements

Management Develop a collection of security requirements derived from regulatory constraints.


Construction and Development Phase Controls The objective of this phase is to transform approved architecture(s) and design(s) into a working system

that is consistent with functional and technical requirements identified during the design phase.

The controls documented below are to be implemented to ensure the continuing consideration of

security throughout development.

Risk Management

Control Code


Control Category

SSQA-

SSDLT-CR1.2

Have SSG perform ad hoc review

Operational

Conduct code review of High-Risk Projects.

Software Security

Control Code


Control Category

SSQA-D-PT1.3

Use penetration testing tools internally

Operational

Develop capability to improve testing efficiency and repeatability.


Transition and Testing Phase Controls The objective of this phase is to perform system integration testing of the developed system, to ensure

that the developed systems (and sub-systems or components) meet technical requirements.

Testing may require any number of additional tests depending on the scope and complexity of the

requirements; example tests include: security, accessibility, performance and regression tests.

The controls documented below are to be implemented to support the verification of solution security

prior to deployment into production.

Governance

Control

Code

Control and

Control Objective

Control

Category

SSQA-SSDLT-CR1.5

Make code review mandatory for all projects

Management Establish code review as a mandatory check within the development lifecycle to enhance assurance levels.

Software Security

Control

Code

Control and

Control Objective

Control

Category

SSQA-SSDLT-ST1.1

Ensure Quality Assurance (QA) supports edge and boundary value condition testing

Management Progress beyond functional testing to Performa basic adversarial tests.

SSQA-

SSDLT-ST1.3

Drive tests with security requirements and security features

Management Target testing against security mechanisms derived from requirements and security features.

SSQA-D-PT1.1

Use external penetration testers to find problems

Management

Obtain additional assurance and identify overlooked weaknesses.


Software Security

Control Code


Control Category

SSQA-D-

SE1.2

Ensure host and network security basics in place

Management

Protect infrastructure supporting solutions.

SSQA-D-PT1.2

Feed results to defect management and mitigation system

Operational Integrate results with the organizational defect management process.

SSQA-

SSDLT-CR1.4

Use automated tools along with manual review

Technical

Increase efficiency and consistency within code review processes.


Control Code


Control Category

SSQA-SSDLT-CR1.6

Use centralized reporting to close knowledge loop and drive training

Operational Track code review findings and leverage results to enhance training and awareness activities.


Production and Operations Phase Controls The objective of this Phase is to ensure that appropriate controls are in place to support the security

of the system during operations and to ensure that weaknesses or defects are communicated back

to development teams, testers and are integrated into the development lifecycle to prevent

reintroduction and support remediation.

The controls documented below are to be implemented to support operational security and improve

development activities through applying operational intelligence.

Logging and Security Monitoring

Control

Code

Control and

Control Objective

Control

Category

SSQA-D-SE1.1

Use application input monitoring

Technical To monitor software inputs for signs of misbehavior that may indicate attack or exploitation.

Software Security

Control Code


Control Category

SSQA-D-CMVM1.

2

Identify software defects found in operations monitoring and feed them back to development

Management

Support development activities with operational data.

software security and quality assurance (ssqa) …...this software security standard defines the...

Documents