security standard - application security testing (ss-027)

OFFICIAL

Version 1.1 of 15

Security Standard - Application Security

Testing (SS-027)

Chief Security Office

Date: March 2020

OFFICIAL

Version 1.1 of 15

1. Revision History

Version Author Description Date

00.a First Draft 15/05/17

00.b Amended to include initial comments 22/05/17

00.c Updated to include internal reviewer comments

12/06/17

00.d Updated to include SME comments 26/06/17

00.e Updated to include external review comments

10/07/17

00.f Updated to include Controls Catalogue Mapping section

10/07/17

1.0 First published version 17/07/17

1.1 Version for external publication 30/03/20

2. Distribution

Version Role/Area Role Date

3. Approval History

Version Approver Title Role Date

1.0 Chief Security Officer 17/07/17

1.1 Chief Security Officer 30/03/20

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

OFFICIAL

Version 1.1 of 15

Contents 1. Revision History ...................................................................................... 2 2. Distribution .............................................................................................. 2

3. Approval History ..................................................................................... 2 4. Introduction ............................................................................................. 4 5. Purpose .................................................................................................... 4 6. Exceptions ............................................................................................... 5 7. Audience .................................................................................................. 5

8. Scope ....................................................................................................... 6 10. Technical Security Control Requirements ............................................ 7

10.1. ASVS: Application Security Verification Standard.................... 7 10.2. IT Health Checks / Penetration Testing ...................................... 8 10.3. Proactive Security Testing Activities and Techniques. ............ 8 10.4. Post Testing Activities. .............................................................. 11

11. Compliance ............................................................................................ 12

12. Accessibility .......................................................................................... 12 13. Security Standards Reference List ...................................................... 12 14. Reference Documents .......................................................................... 13 15. Definition of Terms ............................................................................... 14

16. Glossary ................................................................................................. 14

OFFICIAL

Version 1.1 of 15

4. Introduction

4.1. This Application Security Testing Security Standard provides the minimum

list of controls that are required to secure applications to an Authority

approved level of security. This standard provides a list of security controls

to protect citizen and operational data to be stored in applications. It is to

minimise the risk from known threats both physical and logical to an

acceptable level for operations.

4.2. This area of Information Security has a very mature set of standards from

which to baseline this document on. OWASP, SANS and CESG all give

robust guidance in this area. This standard will seek to summarise and

combine the salient points of each of these organisations advice and

procedure for re-use within the Authority when engaging in the activity of

Application Security Testing.

4.3. Note: the term “the application” may refer to a single discrete item, but it may

also refer to a group of applications and micro-services that seek to provide

a specific business function.

5. Purpose

5.1. The purpose of this document is to enable teams to work to a defined set of

security requirements which enable solutions to be developed, deployed and

managed to Authority security standards. These standards are based upon

international best practice for Application Security Testing deployments and

have been tailored for Authority use.

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

technical security audits.

5.3. The standard provides a well-defined checklist for review when Application

Security Testing is being scoped. The reason for Application Security

Testing is to find any security gaps that may have gone un-noticed as part of

the time sensitive, delivery focused nature of any Software Delivery Lifecycle

(SDLC). This standard will remain agnostic to SDLC approach, be it agile,

waterfall or a combination of the two. The ultimate goal of well scoped and

well executed application security testing approach is that the highest risk

application vulnerabilities are brought to the surface in light of the current

threat model and intelligence information. The inception point of scoping any

Application Security Testing should be consideration of these two items.

5.4. The purpose of Application Security Testing at the high level is to evaluate

the controls within an application and its information process flow. Evaluation

OFFICIAL

Version 1.1 of 15

may include the use by the application of encryption to protect confidentiality

and integrity of information, authentication of users etc. Application Security

Testing will test the flow of information through the application and whether it

can be intercepted or altered. It will also test how the application handles

input data, and then will test for a range of attack scenarios to test the

applications resistance to various levels of sophistication.

5.5. From a high level perspective, security testing techniques are often classified

as:

5.5.1. Black Box Testing vs. White Box Testing (in Black Box Testing no

internal details of the system are used, whereas in White Box Testing the

internal system details such as the source code are taken into account).

5.5.2. Dynamic Testing v Static Testing (Dynamic being that the system

under test is executed and its behaviour observed, whilst Static testing

techniques analyse the system without executing the system under test).

5.5.3. Manual Testing vs. Automated Testing (test scenario is guided by the

application security tester as against by a specialised application).

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.

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.

7. Audience

7.1. This security standard is intended for Suppliers, application security testers

(penetration testers), system administrators, developers, security groups,

OFFICIAL

Version 1.1 of 15

and IT staff involved in securing environments for Authority systems and

applications, also Security Compliance Teams.

8. Scope

8.1. This security standard is to cover systems handling data within the

OFFICIAL tier of the Government Security Classification Policy (GSCP)

including OFFICIAL-SENSITIVE. All of the Supplier’s application

implementations falling within this category will be subject to the

requirements specified within this security standard. The requirements will

be applied to new installations.

8.2. All newly commissioned Application Security Tests MUST (where the context

is applicable) adhere to all checklist items in this standard, or be otherwise

authorized with Authority review. There may be exceptions to not include a

specific testing item checklist item if any of the following are true:

8.2.1. The explicit checklist item was adequately tested within the last 3

months and verification of remediation can be proven;

8.2.2. The explicit checklist item does not apply to this application’s

architecture and that can be clearly illustrated that its non-applicability is

accurate (i.e. you cannot test an element that is not present on your

application).

8.3. It is pragmatically understood that there is a fiscal and operational overhead

for Application Security Testing, and that repeating testing too frequently on

the same elements may provide only marginal value in the knowledge

aggregation of accurate vulnerability information and risk exposure.

8.4. The security control requirements laid out in this standard are product

agnostic and applicable for all systems that are provisioned for Authority use.

8.5. In the event of uncertainty on the controls laid out in this standard please

contact the Authority for guidance and support on items which require

clarification.

9. Security Controls Assurance

9.1. Controls presented in this standard or referred to via this standard may be

subjected to a formalised IT Health Check or Penetration Test to provide

evidence of adequacy and effectiveness.

OFFICIAL

Version 1.1 of 15

10. Technical Security Control Requirements

10.1. ASVS: Application Security Verification Standard

OWASP’s Application Security Verification Standard is already an excellent and highly regarded set of testing criteria. The applicability of the requirements will vary from application to application. This section will cover appropriate assignment of an ASVS level of testing to the application in question. Levels according to OWASP are Level 1, 2 and 3.

Reference Security Control Requirement

10.1.1. Applications MUST be tested against Level X criteria from the OWASP Application Security Verification Standard (the exact value of the level will depend on the application – determined by the following requirements)

10.1.2. Applications which handle data marked as OFFICIAL or above MUST be tested against Level 3 criteria from the OWASP Application Security Verification Standard.

10.1.3. All other applications MUST be tested against Level 2 criteria, unless written agreement is reached with the Authority that testing against Level 1 criteria is appropriate.

10.1.4. Applications MUST be subject to proportionate security testing during the Software Development Lifecycle, and an external IT Health Check before going live.

OFFICIAL

Version 1.1 of 15

10.2. IT Health Checks / Penetration Testing

This section will cover the security requirements for IT Health Checks and Penetration Testing.


10.2.1. Proportionate Security and penetration testing MUST be undertaken as part of a projects overall testing throughout the Software Development Lifecycle, using approved and appropriate testing tools. It's important for projects to do some security testing using test tools, this gives the project the confidence that the service being built is secure.

10.2.2. Projects MUST use professional independent penetration testers to undertake an external IT Health Check before going live and to verify that the service being built is secure. In cases where penetration testing is identified as a requirement, the provider must be registered on the CHECK scheme for ITHC providers run by NCSC. A CHECK Service Provider can analyse the systems or networks projects rely on to carry out business securely and effectively by conducting a number of tests designed to identify any weaknesses utilising publicly known vulnerabilities and common configuration faults.

Companies belonging to CHECK are measured against high standards set by NCSC. Therefore, HMG and CNI customers can be assured that they will receive a high quality service if the work is carried out under the Terms and Conditions of CHECK.

10.2.3. IT Health Check providers MUST conform to the CHECK scheme for assurance purposes.

10.2.4. The CHECK service MUST be carried out in accordance with the NCSC Service Provision Guidelines.

10.2.5. For Authority services two types of penetration testing MUST be considered: Application Penetration Testing (concerned with the security of the applications built or deployed); and Infrastructure Penetration Testing (concerned with the underlying infrastructure, networks, operating systems and platforms).

10.3. Proactive Security Testing Activities and Techniques.

This section will cover security testing activities and approaches, including the use of automated versus manual testing.


10.3.1. An assessment plan MUST be developed by the project, documenting the activities planned for security assessment and training. This plan needs to be shared with the key stakeholders who will be part of the security testing. This will ease the process of execution and analysis.

OFFICIAL

Version 1.1 of 15


10.3.2. Systems engineers and security professionals MUST engage and agree the security test and evaluation strategy and methods with sponsors in support of application development programs / projects

10.3.3. Product owners MUST mandate support for their test strategy and its implementation.

10.3.4. API IT Health Check testing requires specific discipline and therefore care MUST be taken when selecting a CHECK test provider that can demonstrate the required skill set as per the NCSC CHECK Service Provision Guidelines

10.3.5. Application testing MUST confirm the configuration of the security controls implemented and against those with which the application will interface in production. The security controls being selected from applicable security standards (e.g. deployments of cryptography) MUST be security tested against all criteria from SS-007 Security Standard – Use of Cryptography and also SS-003 Secure Software Development.

10.3.6. Application security health and patch status MUST be fully implemented before acceptance into live, and thereafter kept up to date. Patches MUST be acquired, tested, and installed to administered computer systems to fix security vulnerabilities and improve performance.

10.3.7. Security test tools and methods MUST be chosen to best fit requirements for:

Attack Surface

Application Type

Quality of Results and Usability

Supported Technologies

Performance and Resource Utilisation

10.3.8. When operating platforms are changed, business critical applications MUST be reviewed and tested to ensure there is no adverse impact on organisational operations or security.

10.3.9. Application Security Testing techniques MUST be applied as early as possible in a secure software development lifecycle, comply with SS-003 Software Development Security Standard, and not be applied as an afterthought. Fixing bugs and security vulnerabilities late in the software development is usually more costly compared to fixing them as early as possible.

10.3.10. Application Security Testing techniques MUST be applied repeatedly and at regular intervals throughout an Applications lifecycle, as driven by significant application build change or upgrade including any new connection interface. Where sufficient confidence can be realised by application hardening tests, that approach should be used in favour of arbitrary ITHC.

10.3.11. After each Application Security Test Lessons Learned Logs MUST be captured and “baked in” to future sprints or other delivery methods of the SDLC cycle.

OFFICIAL

Version 1.1 of 15


10.3.12. A security review of the applications architecture and threat modelling MUST be undertaken as they are an important prerequisite for subsequent security testing efforts. These help to identify the attack surface and thus the most critical components. This allows a focusing of the security testing activities in order to ensure they are as effective as possible.

10.3.13. The Security practitioner MUST be aware of options available during the applications planning and design stage. The selection of security testing planning techniques is:

Architectural Security Review – a manual review of the product

architecture to ensure that it fulfils the necessary security

requirements.

Threat Modelling – a structured manual analysis of an

application specific business case or usage scenario. This

analysis is guided by a set of precompiled security threats

10.3.14. In the Application Development stages where an application is not sufficiently mature enough to be placed into a test environment, the following Security testing techniques MUST be considered:

Static Source Code Analysis and Manual Code review – this

entails analysis of the application source code for finding

vulnerabilities without actually executing the application.

Static Binary Code Analysis and Manual Binary Review –

analysis of the compiled application binary for finding

vulnerabilities without actually executing the application (similar

to source code analysis but not as precise and fix

recommendations typically cannot be provided).

10.3.15. Once applications can be executed, further security testing approaches MUST be applied, such as:

Manual or Automated Penetration Testing – simulates an

attacker sending data to the application and observes its

behaviour. This helps to identify a range of vulnerabilities in a

deployed application

Automated Vulnerability Scanners – testing an application for

the use of system components or configurations that are known

to be insecure. Pre-defined attack patterns are executed and

system fingerprints analysed. This enables the detection of well-

known vulnerabilities i.e. detection of outdated frameworks and

misconfigurations

Fuzz Testing Tools – send random data, usually in larger

chunks than expected by the application, to the input channel of

an application to provoke a crashing of the application. This

OFFICIAL

Version 1.1 of 15


enables the detection of application crashes (for example

caused by buffer overflows) that might be security critical.

10.3.16. Security techniques MUST have a deployed and configured application on an isolated test system, including back-ends or external services. While dynamic techniques usually do not achieve similar coverage of the analysed application in relation to static approaches, they are well suited for detecting vulnerabilities that involve data flows across system boundaries.

10.3.17. Live data MUST not be used for test and development activities.

10.4. Post Testing Activities.

This section covers those activities that MUST be completed once testing activity is completed.


10.4.1. Following testing, the findings MUST be documented in a written report, and include recommended mitigations. The report must be produced in line with the CHECK Service Provision Guidelines.

10.4.2. The findings / recommendations report MUST be circulated to key stakeholders and in line with the CHECK Service Provision Guidelines.

10.4.3. The findings / recommendations report MUST be appropriately marked and handled/ distributed in line with that marking.

10.4.4. If the findings / recommendations report is marked as OFFICIAL-SENSITIVE (or higher), and is being sent to /from an approved external stakeholder, it MUST be encrypted.

OFFICIAL

Version 1.1 of 15

11. Compliance Compliance with this standard MUST occur as follows:

Compliance Due Date

On-going From the first day of approval

Retrospective When the next ITHC is performed on the application in question.

12. Accessibility No user interfaces are included in this standard and accessibility is not applicable as part of this standard. However, it is deemed that Suppliers implementing this standard are obliged to incorporate accessibility functions where necessary. 13. Security Standards Reference List

Document Name Location Version

SS-003 Software Development Security Standard

SS-012 Protective Monitoring Security Standard.

SS-015 Malware Protection Security Standard

SS-029 Securely Serving Web Content Security Standard

OWASP Automated Threats to Web Applications

https://www.owasp.org/index.php/OWASP_Automated_Threats_to_Web_Applications

V0.8.1

OFFICIAL

Version 1.1 of 15

14. Reference Documents OWASP Application Security Verification Standard https://www.owasp.org/images/3/33/OWASP_Application_Security_Verification_Standard_3.0.1.pdf OWASP Automated Threats to Web Applications https://www.owasp.org/index.php/OWASP_Automated_Threats_to_Web_Applications OWASP Security Knowledge Framework https://www.owasp.org/index.php/OWASP_Security_Knowledge_Framework OWASP Fuzz Testing https://www.owasp.org/index.php/Fuzzing ISO/IEC 27001 Gov.uk Vulnerability & Penetration Testing https://www.gov.uk/service-manual/technology/vulnerability-and-penetration-testing Microsoft Security Development Lifecycle https://www.microsoft.com/en-us/sdl/default.aspx NCSC Penetration Testing https://www.ncsc.gov.uk/scheme/penetration-testing NCSC CHECK Service Provision Guidelines https://www.ncsc.gov.uk/scheme/penetration-testing NCSC Application Development Guidance: Introduction https://www.ncsc.gov.uk/guidance/application-development-guidance-introduction NCSC Cloud Security Principle 7: Secure Development https://www.ncsc.gov.uk/guidance/cloud-security-principle-7-secure-development NCSC Digital Services: Building a Secure Digital Service https://www.ncsc.gov.uk/guidance/digital-services-building-secure-digital-service NCSC 10 Steps to Cyber Security https://www.ncsc.gov.uk/guidance/10-steps-cyber-security NCSC 10 Steps to Secure Configuration https://www.ncsc.gov.uk/guidance/10-steps-secure-configuration NCSC Guidance: Vulnerability Management https://www.ncsc.gov.uk/guidance/vulnerability-management NCSC Patch Management https://www.ncsc.gov.uk/topics/patch-management

OFFICIAL

Version 1.1 of 15

SANS 2015 State of Application Security: Closing the Gap https://uk.sans.org/reading-room/whitepapers/analyst/2015-state-application-security-closing-gap-35942 15. Definition of Terms

OWASP Application Security Verification Standard

The OWASP Application Verification Security Standard is a list of application security requirements or tests that can be used by architects, developers, testers, security professions and consumers to define what a secure application is. The document is Copyright 2008 – 2016 The OWASP Foundation and is released under the Creative Commons Attribution Share Alike 3.0 licence.

Transport Layer Security (TLS)

IETF standardised suite of protocols used to protect the confidentiality and integrity of application-layer communication during transit.

16. Glossary

ASVS Application Security Verification Standard

DA Design Authority (DA)

Authority The Authority refers to the Department for Work and Pensions (DWP)

NCSC National Cyber Security Centre

OWASP Open Web Application Security Project

SDLC Software Delivery Lifecycle

SUPPLIER Is inclusive of Contractor, their employees or any sub-contractors used

TLS Transport Layer Security

OFFICIAL

Version 1.1 of 15