DWP Security Standard - Software Development (SS-003)

OFFICIAL

Security Standard Software Development

(SS-003)

Chief Security Office

Date: March 2020

Version 1.2

Page 1 of 21

1. Revision History

Issue Status

Author

0.0a

0.0b

0.0c

0.0d 0.0e 0.0f 0.0g 0.0h 0.0i 0.0j 0.0k 0.0l 1.0 1.1 1.2

2. Distribution

Issue

Role/Area

Status

OFFICIAL

Description

Date

First Draft

29/07/2016

Draft for peer review

Redraft after TDA Advisory and wider peer review Secure Software Development Lifecycle Security Requirements

Base-lined Document

20/08/2016 01/09/2016 12/09/2016 19/09/2016

Uplifted to the new template.

Added in Policy & Standards Teams controls and statements

Revised to include best practice

Updated with UCFS comments & new template

Address review comments

13/01/2017 23/01/2017 25/01/2017 15/02/2017 11/04/2017

Further amendments

Further amendments following detailed software engineering review

First published version

Multiple revisions in all sections following feedback from SMEs.

Version for external publication

15/04/2017 09/06/2017 26/06/2017 07/10/2017 30/03/2020

Role

Date

3. Approval History

Issue

Approver

Status

1.0

1.0

1.1 1.2

Version 1.2

Role

Chief Security Officer Head of Practice, Software Engineering Digital Design Authority Chief Security Officer

Date

26/06/2017 26/06/2017 07/10/2018 30/03/2020

Page 2 of 21

OFFICIAL

This document will be reviewed for continued completeness, relevancy and accuracy within 1 year of being granted "final" status, and at yearly intervals thereafter.

Contents

1. Revision History......................................................................................2 2. Distribution ..............................................................................................2 3. Approval History .....................................................................................2 4. Introduction .............................................................................................4 5. Purpose....................................................................................................4 6. Exceptions ...............................................................................................4 7. Audience ..................................................................................................5 8. Scope .......................................................................................................5 10. Security in Software Development ........................................................6 11. General Coding Practices.......................................................................6 12. Input Validation .......................................................................................8 13. Output Encoding .....................................................................................9 14. Authentication and Password Management .........................................9 15. Session Management ........................................................................... 10 16. Access Control ...................................................................................... 11 17. Cryptographic Practices.......................................................................12 18. Error Handling and Logging* ............................................................... 13 19. Data Protection......................................................................................14 20. Communication Security ...................................................................... 15 21. System Configuration ........................................................................... 15 22. Database Security ................................................................................. 16 23. File Management ................................................................................... 17 24. Memory Management ........................................................................... 18 25. Development Lifecycle ......................................................................... 18 26. Code Quality .......................................................................................... 18 27. Open Source .......................................................................................... 19 28. Application Security Testing*. ............................................................. 19 29. Compliance............................................................................................20 30. Accessibility .......................................................................................... 20 31. Reference Documents .......................................................................... 20 32. Glossary.................................................................................................20 33. Definition of Terms ............................................................................... 20

Version 1.2

Page 3 of 21

OFFICIAL

4. Introduction

4.1. This document sets out baseline security requirements to include when developing and maintaining software for use within the Authority. These requirements MUST also be considered against code that may not have been developed by the Authority e.g. taken on from Suppliers. This document should be read in conjunction with the Authority's Information Security Policy, Acceptable Use Policy Open Source Security Policy, and the Software Usage Policy.

4.2. There is a risk from threat actors using malicious code to exploit vulnerabilities in the Authority's systems, applications and business practices. This presents a significant risk to the Confidentiality, Integrity and Availability of Authority Systems and the information they process, store and exchange.

All areas of the Authority should assume that, where there is a business requirement to exchange data with Suppliers or business partners or import content from other information sources including open source, information technology systems and information assets are highly likely to be affected by attacks via malicious code of a direct and also indirect nature.

5. Purpose

5.1. The purpose of this document is to enable Suppliers to work to a defined set of security requirements which enable solutions to be developed, deployed and managed to Authority security standards, which are based upon industry best practice for secure software development.

5.2. Secondly, this standard provides a means to conduct compliance based technical security audits.

6. Exceptions

6.1. In this document the term "MUST" in upper case is used to indicate an absolute requirement. Failure to meet these requirements will require a formal exemption as detailed below.

6.2. Any exceptions to the application of this standard or where controls cannot be adhered to MUST be presented to the Authority where appropriate. This MUST be carried out prior to deployment and managed through the design caveats or exception process.

Version 1.2

Page 4 of 21

OFFICIAL

6.3. Such exception requests may invoke the Risk Management process in order to clarify the potential impact of any deviation to the configuration detailed in this standard.

6.4. Exceptions to this standard MUST be maintained on a risk register for accountability, traceability and security governance reporting to the Authority.

The Security Risk Management Process can be accessed via the Authority.

7. Audience

7.1. This Standard applies to all Authority employees, suppliers, partners and service providers developing digital services for the Authority.

8. Scope

8.1. This standard is to cover systems handling data within the OFFICIAL tier of the Government Security Classification Policy (GSCP). All of the organisations falling within this category will be subject to the requirements specified within this security standard. The requirements will be applied to new and existing development practices and products.

8.2. The security control requirements laid out in this standard are agnostic and apply to all development undertaken on behalf or within the Authority, including suppliers who fulfil software development for the Authority.

8.3. Any exceptions to the application of this standard or where controls cannot be adhered to MUST be presented to the Authority where appropriate. This MUST be carried out prior to deployment and managed through the design caveats or exception process.

Version 1.2

Page 5 of 21

 ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download