Upload
others
View
10
Download
1
Embed Size (px)
Citation preview
OFFICIAL
Version 1.1 Page 1 of 15
Security Standard - Application Security
Testing (SS-027)
Chief Security Office
Date: March 2020
OFFICIAL
Version 1.1 Page 2 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 Page 3 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 Page 4 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 Page 5 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 Page 6 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 Page 7 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 Page 8 of 15
10.2. IT Health Checks / Penetration Testing
This section will cover the security requirements for IT Health Checks and Penetration Testing.
Reference Security Control Requirement
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.
Reference Security Control Requirement
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 Page 9 of 15
Reference Security Control Requirement
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 Page 10 of 15
Reference Security Control Requirement
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 Page 11 of 15
Reference Security Control Requirement
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.
Reference Security Control Requirement
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 Page 12 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 Page 13 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 Page 14 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 Page 15 of 15