Pocket Guide: Security Assurance

Idea

Cyber security assurance is a set of activities to understand the system security posture and ensure compliance with the security requirements.

It may include:

• Security design review of the product documentation for design weaknesses and compliance with the security standards. Rated risks and recommended security controls are the outcome of such a review. This is usually a manual, one-off process.
• Vendor review is an evaluation of a 3rd party security practices and controls to ensure their services or products do not introduce risk to our organisation. This manual process is usually done before entering into a contract.
• Penetration testing identifies vulnerabilities in the running system via simulated realistic attacks. It is close to malicious reconnaissance, but does not include intentional harm. The testing is especially valuable on the exposed systems, where malicious activity is likely, and it is a good idea to perform it regularly. Penetration testing can be automated to some extent, but still requires manual input.
• Vulnerability scanning for known vulnerabilities in the packaged software. Contrary to the penetration testing, it does not simulate the attacks. Therefore, it can be easily automated and run frequently. It works hand-in-hand with software composition analysis (SCA) which identifies implicitly included external libraries and components in the software to scan for vulnerabilities.
• Static Application Security Testing (SAST) of the application source code to identify security weaknesses before the application is deployed into productions. This testing can be fully automated and integrated into the development environment.

Each of these activities have their place in the Software Development Lifecycle. Well-integrated security assurance forms continuous compliance loop, where every change in contract, design, code or binary artifact triggers assurance activity.

Application examples

Daily scanning of the deployed containers for known vulnerabilities and configuration drift with alerting on High or Critical findings.

In addition to the periodic assurance, here is how it could also be integrated into the release cycle:

1. A staff developer commits code to Git (version control system).
2. Code security scanning (Static Application Security Testing – SAST) is triggered.
3. If no security issues are found, pipeline compiles the code into a binary artifact.
4. Unit tests are invoked at this stage to verify the application functionality.
5. Container build is initiated.
6. The container is tested for composition (Software Composition Analysis – SCA) and known vulnerabilities, along with other non-security testing.
7. If Infrastructure-as-code is involved, it is scanned for misconfiguration and hardening.
8. The container is moved into a staging environment. Further validation and testing are performed.
9. Human approval is requested for the production deployment.
10. If approved, container is deployed into the production to serve live requests.

Risks

Penetration testing reports contain sensitive information about system weaknesses, which could be exploited by malicious actors. Therefore, we want to ensure the report is available only to the intended recipients. On the other hand, it is far too often the engineer responsible for fixing the security weakness has no access to the penetration testing findings, so that may lead to delayed (or abandoned) remediation. Between these two sides, I would lean on transparency.

Quirks

The high rate of changes in IT environments is hard to flow through the bottleneck of the manual review process. Therefore, it is important to fine-tune the security review engagement criteria to balance between delivery speed and security robustness.

Security staff often don’t have developer experience to fully understand SAST findings, which is why collaboration with the software engineers is required.

Further reading

Pocket Guide: DevOps Security

Please check out the map of cyber security controls below. It is simple yet awesome.