Agile Environment Testing
Code repository reviews
Code repositories are used to store all code for a project. With cloud environment this can include infrastructure as code script and templates as well as functional application code. If a code repository were compromised it may be possible to make changes to the environment that would severely impact on security.
It is common for automated processes to be run when code is committed to the repository and therefore securing this environment is important to maintaining security.
A key feature of code repositories is that previous versions of code are stored to allow rolling back of changes and to act as an audit log. This may introduce risks as if sensitive information is committed then it may be difficult to remove this information from the repository.
When reviewing code repositories, the role-based access controls are first assessed to ensure that no users exist that have overly permissive access to the code base. Authentication mechanisms such as single sign-on, multi factor authentication, and key based access is then reviewed. The configuration of the service is then compared to best practices. The code itself is then checked to identify any sensitive information that may exists in current or previous commits.
The amount of time required for this phase of testing depends on how large the codebase is, how many users have access to the platform, and what extended features may be enabled in the hosting platform.
Build platform review
When code is committed to a code repository it is common for automated processes to be run. This may include compiling code, creating containers, deploying infrastructure, or running tests. These processes are generally run on dedicated servers commonly known as runners. These may be containerised processes, dedicated physical servers, or cloud-based execution environments.
An attacker with access to a single project in a code repository may be able to compromise these processes by submitting custom pipelines to gain code execution on the servers used in the build process. If this is achieved, it may then be possible to gain access to sensitive information such as keys or credentials that may then lead to accessing other projects or resources.
Other services such as artifact storage, key storage, and container registries may be involved in the build process which may also be compromised in a similar manner and should therefore be included in this phase of testing.
An understanding of the build process and the components used is required to create bespoke testing scenarios that are relevant to each client.
Hosting environment review
A cloud test will initial focus on the configuration of the deployed resources and comparing them to best practices from the cloud service provider themselves, as well as advice from other relevant bodies such as CIS.
Any external facing resources such as web services, APIs, load balancers, or storage are prioritised to ensure that no threats are presented externally.
Once the security posture of these resources has been ascertained, the interconnectivity of the components is assessed. This involves reviewing network security groups, routes, and service accounts used by internal systems to communicate with each other. In this phase of testing, the aim is to understand the impact of any resource being compromised and what level of access a compromised component would have to the rest of the environment.
Role based access controls are then reviewed. This included both services accounts and user accounts. This is carried out to identify any routes in which an account may escalate its privileges to access, deploy, or reconfigure resources in an unauthorised manner.
Many companies rely on third party services that connect into their environment to help facilitate asset management, configuration, logging, or security services. These third parties are commonly set up with their own credentials or have permissions to assume roles to access resources. These third-party integrations are assessed to ensure that a supply chain attack cannot be performed and that any external access is sufficiently restricted.
These phases of testing will generally be performed using a read only administrative account with which to query the resources both programmatically through a command line interface, and through the web based administrative portal.
To scope this phase of testing, the size of the environment needs to be understood. Knowing how many deployed resources there are and of what type is key. Documentation should also be provided to create a customised scope of work.
Code reviews
Testing of the infrastructure as code will consist of both manually reading and running static application security testing (SAST) tools against the codebase.
This will be conducted to fully understand the environment and to ensure that resources are deployed in a secure manner.
The code to be reviewed is generally a mixture of infrastructure as code templates and scripts, and functional application code.
Templating files will be assessed to ensure that resources are deployed securely, whereas the functional code will be reviewed to identify any areas in which execution may be altered in a manner that would cause security issues.
To scope this phase of testing, the number of lines of code in each language is required as well as documentation describing the functionality of the code. This can then be compared against the code supplied to identify any deviations from best practices.
