Isms doc a14 2 secure development policy

Secure Development Policy

ISO/IEC 27001 Toolkit Version 7 ©CertiKit 2016

Secure Development Policy [Insert Classification]

Implementation Guidance (The header page and this section must be removed from final version of the document)

Purpose of this document This document describes the organization’s policy with regard to the development of applications and associated components in a secure way.

Areas of the standard addressed The following areas of the ISO/IEC 27001:2013 standard are addressed by this document: Annex A A.14 System acquisition, development and maintenance A.14.2 Security in development and support processes A.14.2.1 Secure development policy A.14.2.7 Outsourced development A.14.2.8 System security testing A.14.3 Test data A.14.3.1 Protection of test data

General Guidance This is an important document because it covers a number of requirements. It sets out how you will ensure that the code you (and your suppliers) produce is as secure as possible. Note that if you have a purely COTS (Commercial Off The Shelf) package approach then many of these requirements will be inapplicable and marked as such in your Statement of Applicability.

Review Frequency We would recommend that this document is reviewed annually.

Toolkit Version Number ISO/IEC 27001 Toolkit Version 7 ŠCertiKit 2016.

Document Fields This document may contain fields which need to be updated with your own information, including a field for Organization Name that is linked to the custom

Version 1

Page 1 of 15

[Insert date]

Secure Development Policy [Insert Classification]

document property “Organization Name”.

To update this field (and any others that may exist in this document): 1. Update the custom document property “Organization Name” by clicking File > Info > Properties > Advanced Properties > Custom > Organization Name 2. Press Ctrl a on the keyboard to select all text in the document (or use Select, Select All on the ribbon) 3. Press F9 on the keyboard to update all fields 4. When prompted, choose the option to just update TOC page numbers If you wish to permanently convert the fields in this document to text i.e. so that they are no longer updateable, then you will need to click into each occurrence of the field and press Ctrl Shift F9.

If you would like to make all fields in the document visible then go to File > Options > Advanced > Show document content > Field shading and set this to “Always”. This can be useful to check that you have updated all fields correctly.

Further detail on the above procedure can be found in the Toolkit Completion Instructions within the Project Resources folder.

Copyright notice Except for any third party works included in this document, as identified in this document, this document has been authored by CertiKit, and is © copyright CertiKit except as stated below.

CertiKit is a trading name of Public I.T. Limited, a company registered in England and Wales with company number 6432088 and registered office at 5 Falcons Rise, Belper, Derbyshire, DE56 0QN.

Licence terms This document is licensed on and subject to the standard licence terms of CertiKit, available on request, or by download from our website. All other rights are reserved. Unless you have purchased this product you only have an evaluation licence. If this product was purchased, a full licence is granted to the person identified as the licensee in the relevant purchase order. The standard licence terms include special terms relating to any third party copyright included in this document.

Disclaimer Please Note: Your use of and reliance on this document template is at your sole risk. Document templates are intended to be used as a starting point only from

Version 1

Page 2 of 15

[Insert date]

Secure Development Policy [Insert Classification]

which you will create your own document and to which you will apply all reasonable quality checks before use. Therefore please note that it is your responsibility to ensure that the content of any document you create that is based on our templates is correct and appropriate for your needs and complies with relevant laws in your country. You should take all reasonable and proper legal and other professional advice before using this document. CertiKit makes no claims, promises, or guarantees about the accuracy, completeness, or adequacy of our document templates, assumes no duty of care to any person with respect its document templates or their contents, and expressly excludes and disclaims liability for any cost, expense, loss or damage suffered or incurred in reliance on our document templates, or in expectation of our document templates meeting your needs, including (without limitation) as a result of misstatements, errors and omissions in their contents.

Version 1

Page 3 of 15

[Insert date]

Secure Development Policy [Insert Classification]

[Replace with your logo]

Secure Development Policy

Document Classification: Document Ref. Version: Dated: Document Author: Document Owner:

Version 1

Page 4 of 15

[Insert Classification] ISMS-DOC-A14-2 1 [Insert date]

[Insert date]

Secure Development Policy [Insert Classification]

Revision History Version Date

Revision Author

Summary of Changes

Distribution Name

Title

Approval Name

Version 1

Position

Signature

Page 5 of 15

Date

[Insert date]

Secure Development Policy [Insert Classification]

Contents 1

INTRODUCTION ....................................................................................................................................... 7

2

SOFTWARE DEVELOPMENT APPROACHES ................................................................................... 8 2.1 2.2

3

SECURITY IN THE SOFTWARE DEVELOPMENT LIFECYCLE ................................................. 10 3.1 3.2 3.3 3.4

4

WATERFALL DEVELOPMENT APPROACH................................................................................................... 8 ITERATIVE DEVELOPMENT APPROACH ...................................................................................................... 9

BUSINESS REQUIREMENTS SPECIFICATION.............................................................................................. 10 SYSTEM DESIGN ...................................................................................................................................... 10 DEVELOPMENT........................................................................................................................................ 11 TESTING .................................................................................................................................................. 11

SECURITY IN OUTSOURCED DEVELOPMENT ............................................................................. 13 4.1 4.2 4.3 4.4 4.5 4.6 4.7

SELECTION OF OUTSOURCED DEVELOPER .............................................................................................. 13 COMMUNICATION OF REQUIREMENTS ..................................................................................................... 13 SUPERVISION AND MONITORING ............................................................................................................. 14 REVIEWS AND ACCEPTANCE ................................................................................................................... 14 AUDIT OF DEVELOPMENT METHODS ....................................................................................................... 14 INTELLECTUAL PROPERTY ...................................................................................................................... 14 ESCROW .................................................................................................................................................. 15

Version 1

Page 6 of 15

[Insert date]

Secure Development Policy [Insert Classification]

1 Introduction The purpose of this document is to set out [Organization Name]’s policy in the development of software applications and components in a way which maximises their inherent security.

Secure development contributes to the reliability of the IT environment by ensuring that as many vulnerabilities as possible are designed and tested out of software before it is transitioned into the live environment.

Many security breaches around the world occur due to the exploitation of such vulnerabilities in system and application software, including the use of data that was not envisaged when the software was designed and tested.

This document sets out the precautions that must be taken during the software development lifecycle to minimise the risk to the organization whilst ensuring that the benefits set out in the original business case for the software are still realised.

As such, this document will represent an initial design for the enhancement of existing development processes and will be updated on at least an annual basis thereafter as [Organization Name] and its needs develop.

This policy should be read in conjunction with the following documents which give more detail in specific areas:   

Change Management Process Secure Development Environment Guidelines Supplier Management Policy

Version 1

Page 7 of 15

[Insert date]

Secure Development Policy [Insert Classification]

2 Software Development Approaches The process of software development fits in with the higher level process of project management of new or enhanced information systems.

This process has the following major stages in a project:     

Proposal Planning Design and Development Transition Project Closure

The software development lifecycle sits mainly within the Design and Development stage and consists of the following sub-stages: 

Design and Development  Business requirements specification  System design  Development  Testing

The way in which the stages of the software development lifecycle are approached will depend upon the development approach used. The two main models of software development used within [Organization Name] are Waterfall and Iterative. The choice of approach will be made on a project by project basis.

2.1

Waterfall Development Approach

The classic Waterfall approach to software development involves the planning and completion of each stage before moving on to the next, in a sequential manner.

Functional requirements are defined in detail and signed off before the design stage may begin. In turn, design must be completed before development starts etc. This has the advantage that it is possible to ensure that adequate planning takes place and to include security checkpoints at the end of each stage. These will ensure the inclusion of adequate security criteria at the requirements stage and correct security controls at the design stage.

The common disadvantage with the Waterfall approach is that it is less flexible as circumstances and requirements change. If the project lasts for an extended period of time there is the danger that what is delivered is no longer what is required.

Similar approaches based on Waterfall include Development, the Spiral Method and Cleanroom.

Version 1

Page 8 of 15

Structured

Programming

[Insert date]

Secure Development Policy [Insert Classification]

2.2

Iterative Development Approach

As an alternative Waterfall, an Iterative approach may be taken. Such approaches include Rapid Application Development (RAD), Prototyping and, more recently, Agile.

The Iterative approach typically involves significant stakeholder involvement throughout the development lifecycle and concentrates on producing frequent new versions of the software that may be evaluated and tested before further functionality is added. The process loops round with each of the stages being carried out many times in small iterations (in the Agile method these are called “Sprints�).

An Iterative approach may be appropriate where exact requirements are less certain and frequent communication between developers and users (and within the development team) is possible.

The inclusion of security requirements and controls within an Iterative development approach needs to be carefully managed to ensure that functionality is not preferred to the exclusion of effective security measures. The speed involved and the potential lack of structured design documentation mean that effective training of developers in security matters and possibly the regular involvement of a security specialist are recommended.

Version 1

Page 9 of 15

[Insert date]

Secure Development Policy [Insert Classification]

3 Security in the Software Development Lifecycle This section describes the way in which information security considerations should be incorporated into the various stages within the software development lifecycle.

3.1

Business Requirements Specification

The focus within the business requirements stage is on the functionality of the new system. This will be expressed in business rather than technical terms and should tie in with the business case that was produced prior to the initiation of the project.

The business is uniquely placed to give a clear understanding to the development team of the security requirements of the information that the new system will hold and process. In particular the business requirements should specify:       

The value of the information involved The sensitivity of the information – will personal data be held?

Who the information owner is or will be The classification of the information according to the scheme used within the organization The environment in which the information will be accessed or processed – will access be available in public areas?

The criticality of the new system and the information it holds – what is the business impact if it is not available?

The legal, regulatory and contractual environment the system must operate within

A risk assessment should be carried out as part of the project to ensure that the implications of the above issues are fully understood by all parties.

3.2

System Design

Based on the risk assessment and the classification of the information that is to be held in and processed by the new system, the design must provide for appropriate security features to be available. These will be largely defined by [Organization Name]’s established security architecture as documented in Principles for Engineering Secure Systems.

This extends not only to the creation and maintenance of user accounts and permissions but also the following areas:     

Data input validation controls Data flow Data output Interfaces with other systems Reporting

Version 1

Page 10 of 15

[Insert date]

Secure Development Policy [Insert Classification]

         

Restart and recovery Time stamps Logging (e.g. of transactions and access) Journaling of before and after images Batch and transaction counters Monitoring facilities How non-repudiation requirements will be met Ongoing patching arrangements Use of cryptography Need for digital certificates and signatures

For systems designed as part of a Waterfall approach these aspects should be included as part of the design documentation. If and Iterative approach is used, the development team will need to ensure that these areas are considered during every iteration and that changes do not invalidate controls implemented during an earlier iteration.

3.3

Development

Before starting to write code, a secure development environment should be established for the project. More detail regarding the creation and management of a secure development environment may be found in the document Secure Development Environment Guidelines.

Depending on the coding environment, languages, databases, tools and other components selected, the appropriate guidelines for secure coding and configuration should be adopted. These should be evaluated to ensure they will provide adequate protection from the various types of potential attack identified in the risk assessment, such as:     

Buffer overflow Time of Check/Time of Use Memory Reuse Malformed input SQL injection

For a lengthy project it will be necessary to obtain regular updates regarding newly identified vulnerabilities and exploits associated with the technology components in use.

3.4

Testing

During the lifecycle of a software application, many different forms of testing will be carried out, including unit, system, integration, performance, user acceptance and operational acceptance testing. Security controls will to some extent be tested as part of these exercises. However it is recommended that a separate exercise of

Version 1

Page 11 of 15

[Insert date]

Secure Development Policy [Insert Classification]

security testing be carried out against the security requirements that were established during the business requirements and design stages.

Initial security testing should be carried out within the development project with the same degree of rigour and formality as other forms with a suitable range of test inputs being specified.

Once this has been completed to the development team’s satisfaction a further phase of security testing should be carried out by an independent party separate to the development team to verify correct operation of controls.

Adequate controls should be put in place to protect test data. Where appropriate (and with prior approval on each occasion), a live to test copy may be made in order to provide representative test data. However if this contains sensitive information such as personally identifiable data this should be removed or obscured before use.

Version 1

Page 12 of 15

[Insert date]

Secure Development Policy [Insert Classification]

4 Security in Outsourced Development Where software development is wholly or partially outsourced to a third party, due care must be taken to ensure that the policies of [Organization Name] are still followed where possible.

[Organization Name] will remain legally responsible for the use of the software created and the information contained within it even though it didn’t write the software. Therefore the same level of rigour must be applied to outsourced software development as that created in-house.

4.1

Selection of Outsourced Developer

Standard procurement procedures should be used in the selection and engagement of an appropriate outsourced developer. Use of these procedures should ensure the developer:    

Is capable of delivering the software to the required standard Can meet the delivery timescales required Represents best value for the organization Can meet the security requirements specified

Use of sub-contractors by the outsourced developer for any aspects of the development should be understood and an assessment of these sub-contractors included.

Please refer to Supplier Information Security Evaluation Process for further detail on the areas that should be covered.

4.2

Communication of Requirements

The contract with the outsourced developer should require compliance with this policy and include a clear statement of the requirements for secure design, coding and testing of the software. The developer should also be required to establish a secure development environment in accordance with [Organization Name] standards. These are documented in Secure Development Environment Guidelines.

Requirements definition should be carried out by [Organization Name] so that a clear definition of the software to be created (including its security features) is agreed with the business and used as a contractual starting point for development. Whilst the outsourced developer may in some circumstances assist in the definition of requirements, the exercise should be led, managed and ideally carried out by internal resources so that there is a clear separation between requirements and design/development.

Version 1

Page 13 of 15

[Insert date]

Secure Development Policy [Insert Classification]

A comprehensive picture of the anticipated threat model faced by the software should be provided to the outsourced developer so that a clear understanding is gained of the types of vulnerabilities that must be avoided if the software is to be secure.

4.3

Supervision and Monitoring

Measures should be put in place to ensure adequate supervision of the activities of the outsourced developer and regular monitoring of progress.

For a large project with significant time gaps between deliverables, an agreed method of verifying interim progress should be in place so that early warning is given of delays.

4.4

Reviews and Acceptance

Review points should be established as part of the project planning process to verify progress and give formal acceptance of the software deliverables created. These will involve appropriate testing activities and code reviews.

The outsourced software developer should be required to provide evidence of the security testing activities carried out during the development, including tests for concealed malware, backdoors and known vulnerabilities.

Where appropriate a security review of developed code may be engaged with a suitable third party with the relevant security expertise.

4.5

Audit of Development Methods

[Organization Name] should have the contractual right to undertake a second party audit of the outsourced development provider. This may be to review whether the development methods used comply to our policies and that all information provided to the supplier is protected by appropriate security controls.

For larger projects it is recommended that an audit be carried out prior to the placing of the order for software development to ensure that assurances given during the sales process are valid.

4.6

Intellectual Property

Unless the software is licensed under a formal agreement, contractual arrangements with an outsourced software developer should state that the ownership of the code produced on our behalf rests with [Organization Name].

Version 1

Page 14 of 15

[Insert date]

Secure Development Policy [Insert Classification]

It is important that any software that is developed under an outsourcing contract is understood to be our intellectual property. Appropriate legal advice should be taken particularly if the outsourcer is based outside of our home country.

4.7

Escrow

Arrangements should be made for [Organization Name] to be able to legally access the source code of any developments undertaken, in the event that the outsourcer ceases trading for any reason. This should be the case during development and if appropriate after the code has been delivered.

Version 1

Page 15 of 15

[Insert date]