Security Testing and ITHC
Introduction
MOJ systems typically have a range of security testing, covering the application and infrastructure. When applications are hosted on the Modernisation Platform, it’s important to be clear which areas are the responsibility of the platform to test and which are the responsibility of the service team who develop the application. Also, when testing using stress techniques or unusually high load, this page describes how we avoid affecting other tenants of the platform and stay within cloud provider rules.
IT Health Check (ITHC)
An ITHC is an independent security assessment, typically including a penetration test. Service teams likely need an ITHC for their applications. The Modernisation Platform also has its own ITHCs. Service teams should ensure that their ITHC has a scope that does not overlap into areas which are Modernisation Platform’s responsibilities, and equally doesn’t assume Modernisation Platform are responsible for things which are the service team’s responsibilities. During an application’s ITHC, the Modernisation Platform team will not normally provide testers with higher permissions to the AWS account or cluster than what the service team already have access to. So an ITHC for an application hosted on the Modernisation Platform should be: an application test, plus any cloud infrastructure configuration you do as code, including your environment configuration. We’ve written a guide based on one ITHC Scoping form, providing the division of responsibilities between Modernisation Platform and Service Teams:
- ITHC scoping for service teams vs Modernisation Platform This spreadsheet is a work in progress and we invite questions and suggestions to improve it.
ITHC Tester access
Accessing the AWS console
There are 2 ways this can be done:
- 1. The Application team provides the tester with the same access as they have. The tester then accesses via SSO.
- 2. The Modernisation Platform team provides the tester with a ‘collaborator’ account. The tester will then log in directly to the AWS console.
Accessing the application
The tester would be expected to access the application as the user community would. This might mean granting temporary access to the testers’ IP addresses.
Installing testing software
Any testing software would be installed on, and run from, the 3rd Party’s own environment. We would not expect to install any additional software into the Modernisation Platform.
Notifiable testing
AWS requires you to contact them if you do security testing on AWS services outside a small Permitted Services list. This permitted list includes a number of different elements - such as RDS and EC2. However, items not on this list require specific AWS agreement. In any case, in the first instance, please get in touch with the Modernisation Platform team here to coordinate with contacting AWS.
Load / stress testing
A test that sends a sustained high volume of traffic to your service may become an issue for the Platform’s DDOS monitoring, and degrade connectivity to other Modernisation Platform tenants. Please coordinate with the Modernisation Platform when planning these tests. In addition, please note the Amazon EC2 testing policy that forbids network stress testing / load testing, where the traffic is:
in aggregate, for more than 1 minute, over 1 Gbps (1 billion bits per second) or 1 Gpps (1 billion packets per second); generates traffic that appears to be abusive or malicious; or generates traffic that has the potential for impact to entities other than the anticipated target of the testing (such as routing or shared service infrastructure)
Disallowed testing
Some testing is not allowed, because it may affect other tenants on the Modernisation Platform, or due to the underlying cloud provider’s policies. AWS Penetration test policy forbids:
- denial of service (DoS) style attacks
- DNS zone walking
- port/protocol/connection/network flooding