Omegapoint security review questionnaire

6 October 2023

This post defines a set of questions Omegapoint uses for security reviews. The purpose is to be able to cover many aspects of security for a cloud-native DevOps team, during a two-hour interview with the team.

The questions are based on experience from both building and reviewing systems using CIS Controls v8. Each main question has a set of sub-questions with mappings to verifications in Omegapoints verifications of CIS Controls v8 for cloud-native DevOps teams. But it can, of course, be adapted to other kinds of teams as well.

The goal is that with these questions the team should be focused on building secure systems, not compliance. Note that we do not devalue compliance requirements. The point we are making is that the primary focus for the team should be on building secure high-quality systems, not meeting the minimal set of compliance requirements.

Before using the set of questions below it is important to first do a threat model exercise which, for the given scope (team and system, not all systems for a customer), will help the team:

Understand the system and its boundaries from a security perspective.
Identify data information classes and zones (trust boundaries).
Understand and define access control models, e g multi-tenancy.
Identify concerns, weaknesses, and mitigations of security characteristics.
Understand threat actors, impacts, and the team’s threat priorities.

Such a threat model, together with system documentation, should answer the following questions:

How does the architecture address Zero trust, Least Privilege and Defense in depth strategies? In example network segmentation, encryption at rest, transport layer security, authentication and authorization at the application layer.
How does the architecture address requirements from relevant reference architectures and compliance? In example GDPR, DORA, NIS2 etc.

The threat model will cover parts of CIS v8 Control 12, and 16. If no threat model exercise has been performed, you will need to ask these questions as well.

The following sections will provide details for each of the main questions:

How do you go from commit to deployed code in production?
How do you work with threat modeling and penetration tests?
How do you maintain a shared understanding of the system?
How do you work with maintaining your system?
How do you work with infrastructure and configuration?
How do you work with monitoring and logs?
How do you work when there is an incident?
How do you work with disaster recovery, data restoration, purge, and retention?
How do you manage accounts and access control?
How do you work with the management of devices in development and operations?

Note that the order is not a priority, just a way to structure an interview to cover most CIS Controls Safeguards during an interview.

How do you go from commit to deployed code in production?

There are many ways a team can design a deployment pipeline. Team size and composition, combined with architecture, source code organization and system size place different requirements on branch models and deployment. There is no one-size-fits-all.

We are looking for a structured approach where everyone in the team works and agrees on a model. A lightweight approach to documentation can be a README file in the source code repository that outlines how the team works in combination with a backlog (in a typical open-source fashion.)

Are the commits reviewed by more than the author? Is the review enforced?: Verifications: V1.B, V2.B
Does a pull request link to a work item? Is it required?: Verifications: V1.C, V2.C
Do you run automated tests as part of the CD/CI pipeline?: Verifications: V16.E
What kind of scanners do you run?: Verifications: V2.E, V7.B, V7.C
How are changes build and deployed to the different environments?: Verifications: V1.D, V2.D, V16.E
Are the artifacts unchanged between test and deploy: Verifications: V16.E
Are commit messages descriptive, or optional?: Verifications: V1.C, V2.C
How do you test your application?: Verifications: V16.E, V18.A
How quickly can you change the system while maintaining low risk?: Verifications: V7.D
Are all software components under version control?: Verifications: V1.A, V2.A

How do you work with threat modeling and penetration tests?

Continuously using threat modeling and penetration test is vitaly important for maintaining a high-security posture.

Threat modeling can be performed on different levels, in example for the entire organization or technically detailed for a given system scope together with penetration testing. Preferably it is also a part of the team´s way of working, where the team has a lightweigth risk-based approach to changes in the system, asking the following questions (from e g https://owasp.org/www-community/Threat_Modeling):

What are we working on?
What can go wrong?
What are we going to do about it?
Did we do a good enough job?

Note that threat modeling is closely related to the verifications V3.A and V12.A, as it should have affect on system design and implementation.

Also note that even if a recurring, structured approach to penetration testing is rarely handled by the team itself, it is important that the team understands strategies for penetration testing, how results concerns them, and how these activities relates to threat modeling.