Omegapoint CIS Control Verifications for Cloud Native Applications

Overview

Preferable, systems are secure by design. Following basic industry-standard principles like zero trust, least privilege and defense in depth. They also should keep a good balance concerning confidentiality, integrity and availability security aspects (CIA.) When systems are based on these principles, compliance is a byproduct of secure systems, not the other way around. The focus for the team should be on building secure, high-quality systems, not just meeting the minimal set of requirements to be compliant. However, we do not devalue compliance requirements, which should typically be prioritized.

This document follows the organization of CIS Controls v8. Each chapter starts with describing our view of what is needed to meet the corresponding CIS control. The chapter then contains a set of verifications that aim to be actionable and straightforward to measure. When relevant, e g for more details on web application security, references to other frameworks are included. In particular OWASP ASVS v4.0.3 (https://owasp.org/www-project-application-security-verification-standard/), and OIDC FAPI 2.0 (https://openid.net/wg/fapi/specifications/) are referenced.

The context for the verifications in this document is a system and the team that builds, operates, and defends it. Given an entire organization, security frameworks can become abstract for DevOps teams. We can be very specific and actionable by narrowing the context to a specific system and team.

Control 01 – Inventory and control of enterprise assets

Infrastructure as Code (IaC), combined with version control and code reviews, provides enterprise asset inventory and control as a side effect. For a given cloud-native DevOps team there should be traceability of changes in the system, as well as quality control.

This control requires all assets for all environments to be defined as code, as far as practicable. Assets not defined as code need a documented process. The team needs to adjust the balance between code and documented process as cloud vendors add features to the APIs for managing resources.

Even if the team has good practices using code, version control and reviews, detecting drift between IaC and the configured resources in all environments can be challenging over time. It is preferable to use active automated scanning to find any unauthorized resources (not version controlled) but this might not always practical to implement.

Finding unauthorized resources in a fully cloud-native system can be as simple as manually listing all resources and inspecting audit logs for resource creation. VMs and on-prem parts require CIS Safeguards 1.3—5 in full.

V1.A

Verify that all IaC is under version control.

V1.B

Verify that all changes are reviewed before being deployed to production.

V1.C

Verify that all changes can be traced to an individual, time, and motivation for change.

V1.D

Verify that all resources are deployed using IaC as far as practicable.

V1.E

Verify that ownership is clear and what environment resources are part of (dev, QA, prod, etc.)

V1.F

Verify that there is a process to find and address unauthorized resources.

Note that we do not require IaC to run in a build pipeline. Changes to IaC can, in some cases, cause service disruptions that can be complex to avoid in an automated pipeline.

Also note that we are not expecting to be able to trace all changes in infrastructure code and configuration to backlog items (tickets) and linked business requirements. Documented requirements are simply not available for much of the work in a modern agile environment. However, the motivation for change is important to trace.

In addition to the verifications listed above, OWASP ASVS sections 1.14 and 14.1 provide relevant guidelines for this control.

Control 02 – Inventory and control of software assets

Like Control 1, there should be traceability of changes in all software assets owned by the team, including application source code, scripts, libraries and CI/CD pipelines. Compared to IaC, we strengthen the deployment step in V2.D to require automation through a CI/CD pipeline.

For a cloud-native DevOps team this control will typically cover CIS Controls Safeguard 2.5, 2.6, and 2.7 without the need of an explicit allowlists. But it is important to note that if not applied from the very start, an initial inventory of existing software is needed (e g of all libraries or scripts which are part of the systems in scope.) An explicit allow lists may still be of value to the team, in example to provide a quick overview of used components (which otherwise might be hidden in version control history.)

V2.A

Verify that all software components are under version control.

V2.B

Verify that all changes are reviewed before being deployed to production.

V2.C

Verify that all changes can be traced to an individual, time, and motivation for change.

V2.D

Verify that all changes are deployed from a CI/CD pipeline for all environments.

V2.E

Verify that the CI/CD pipeline includes a step for scanning for vulnerable or outdated packages.

V2.F

Verify that a process exits for selecting dependencies, frameworks, and other assets for the system.

V2.G

Verify that the team has a clear overview of all software, libraries or scripts etc. and why they are used for the system. This should also include applicable licensing.

In addition to the verifications listed above, OWASP ASVS sections 1.14, 10.1, 10.2 and 14.1 provide relevant guidelines for this control.

Control 03 – Data protection

The foundation of data protection in an application is that the team has a clear, shared understanding of the system they are building and operating and what data it contains. Architectural documentation, including information classification and an identity and access control model should be kept up to date and accessible for the team.

Data encryption at rest and in transit is essential, which typically means strong, enforced TLS for all network traffic and storage services with encryption enabled.

A good way to share an understanding of how data is protected is to perform a technically detailed threat modelling exercise for the team. This is part of control 16, see V16.D.

V3.A

Verify that an established, documented, and updated system design, data classification, and model for access control exists.

V3.B

Verify that a documented (and preferably automated) process for purge according to GDPR or any other data privacy regulations that may apply exists.

V3.C

Verify that disk encryption is enabled on all devices containing application data (including developer laptops and removable media).

V3.D

Verify that strong transport layer encryption is used for all network traffic and protocols (TLS, HTTPS, SSH, SFTP, etc.)

V3.E

Verify that all data at rest is encrypted, with support from the service provider or using application-level encryption (in use).

V3.F

Verify that all API requests are logged to a central service, that business events are correlated to API requests, and automated alarms are enabled for errors and anomalies.

V3.G

Verify that the production environment is separated from all other environments according to best practices from the cloud provider (for example, by separate Azure Subscriptions).

V3.H

Verify that all environments and devices that contain production data are treated as production environments with the same level of protection and monitoring.

V3.I

Verify that the model for access control is based on the least privilege principle.

V3.J

Verify that data exfiltration is monitored and automated alarms are enabled for anomalies (IG3).

In addition to the verifications listed above, OWASP ASVS, sections 1.6, 1.7, 1.8, 6.1, 6.2, chapters 8, and 9 provide relevant guidelines for this control. For V3.D, FAPI 2.0 section 4.2 is also relevant.

Control 04 – Secure configuration of enterprise assets and software

The cloud vendors aim to deliver services that are secure by default. However, sometimes ease of use takes precedence. A good example is that most services are public by default and need configuration for network segmentation. Hardening is still essential to many cloud services.

Note that a secure process for configuring infrastructure (safeguard 4.2) to a large extent is covered by Control 1, since IaC normally includes configuration.

Use a secret management service that is purpose-built and preferably provided by the cloud vendor. There are typically many ways to implement application configuration, but our focus is clarity and separation between environments.

V4.A

Verify that managed identity (from the cloud provider) is used as much as possible (minimizing the use of shared secrets).

V4.B

Verify that all secrets are stored in a service built for that purpose.

V4.C

Verify that application configuration is separate for the production environment.

V4.D

Verify that services are hardened by following security best practices from the cloud provider.

V4.E

Verify that all VMs have automatic screen locks after 15 minutes of inactivity.

V4.F

Verify that all VMs have a firewall enabled.

There are guidelines for hardening cloud services. For example, there are CIS Foundations Benchmark for Azure, AWS, and GCP. The cloud vendors provide documented guidance and best practices. Some services like Azure Defender for Cloud let the team manage these practices and set up alerts for violations and security events.

For a cloud-native DevOps team, the following safeguards are typically out of scope since they are normally managed by a separate part of the organization:

• 4.5, 4.9–12 – We assume managed clients

If clients are not managed and are the responsibility of individuals, we need to verify these Safeguards manually (normally against an IT policy or similar.)

In addition to the verifications listed above, OWASP ASVS sections 1.14.1, 14.1.3, 14.2, and 6.4 provide relevant guidelines for this control.

Control 05 – Account management

At the core of account management is a model of identity for the system and team. This model is an inventory of all user groups, clients, and resources. It provides an overview of how they interact.

Tasks requiring high privilege should be done using an account separate from daily use, like developing and reading emails. The benefit is that the effect of a compromised account is limited. Consider using time- and approval-based role activation.

The software system should use an architectural pattern with a central Identity Provider (IdP) that manages user and client authentication.

Compared to implementing your own account management, it is typically a stronger design to delegate user authentication and account management to a service built for that purpose. If you implement your own, OWASP ASVS is a good test reference.

For our context, the term “account” includes machine integrations. Note that integrations with cloud resources (like databases) should prefer managed identities, minimizing the use of shared secrets. See also V4.A.

V5.A

Verify that all accounts are unique for each user and integration and are centrally managed.

V5.B

Verify that user accounts have a password policy according to industry best practices and that system accounts for integrations are given strong shared secrets.

V5.C

Verify that high-privilege tasks are performed using a separate account.

V5.D

Verify that the system uses a central Identity Provider (IdP).

V5.E

Verify that the system uses a service built for the purpose of authentication and account management or follows OWASP ASVS for a local implementation.

V5.F

Verify that shared secrets are rotated on a schedule (please note that we do not enforce rotation for personal user accounts according to NIST directives).

In addition to the verifications listed above, OWASP ASVS section 1.2 and chapter 2 as well as FAPI 2.0 section 4.4 provide relevant guidelines for this control.

Control 06 – Access control management

Principles of least privilege are the base for creating and managing all accounts, both for user and machine integrations. We note that machine-to-machine integration is often neglected from an access control perspective. Since the client typically uses a shared secret, it also represents a powerful attack vector.

Any service that lets you control the function of the system needs to have MFA enabled for user accounts. This includes personal accounts, accounts for version control, build systems, task boards, cloud environments, etc. A strong approach is to integrate these systems with your IdP.

V6.A

Verify that access to the production environment is granted based on the least privilege principle.

V6.B

Verify that there is a documented onboarding process for team members.

V6.C

Verify that there is a documented off-boarding process for team members.

V6.D

Verify that there is a documented onboarding process for integration clients.

V6.E

Verify that there is a documented off-boarding process for integration clients.

V6.F

Verify that all services have MFA enabled for user accounts where possible.

V6.G

Verify that all services used to build, operate, and defend the system are known, listed, and part of the off-boarding process.

V6.H

Verify that all privileges are authorized, accurate, and well understood (review yearly).

V6.I

Verify that there is a documented model of identity and access control for the system (review yearly).

V6.J

Verify that any change that affects access control can be traced to an individual and time.

Please note that this control is typically applied only to services used to build, operate, and defend the system. Access control for the application being built is covered by chapter 8.16.

In addition to the verifications listed above, OWASP ASVS section 1.4 provides relevant guidelines for this control.

Control 07 – Continuous vulnerability management

Packages and dependencies need to be updated on a recurring schedule. Vulnerabilities in the operating system or a package might mean that your system is vulnerable too. While tools help keep track of known vulnerabilities, you need to keep all your systems updated since the tools do not catch everything, have problems with false positives, and the time from reported vulnerability to public exploits can be short, down to zero days.

Consider the maintenance phase of the system that you create and think about what your selection of packages and dependencies means for the ability and cost of maintaining the system when there is no project investment.

To minimize this daunting task, you must be careful when picking a package or dependency. Try to select well-known software that is actively and well maintained. Consider the security implications a breach in the software has on your system and try to judge if the maintainers pay proportional attention to security.

V7.A

Verify that there is a documented process for keeping operating systems, packages, and dependencies updated.

V7.B

Verify that vulnerability scans are performed, investigated, and problems remediated. Scanning should be performed on every change (or on a daily schedule).

V7.C

Verify that the production environment infrastructure is continuously scanned by a tool recommended by the cloud provider and that the results are investigated and remediated.

V7.D

Verify that a change to the system can be deployed with low risk in a timely manner (normally within an hour for IG3).

There are few verifications here, but this is a notoriously difficult thing to get right. Further, package vulnerabilities and dependencies are highly probable attack vectors for any system.

In addition to the verifications listed above, OWASP ASVS section 14.2 provides technical guidelines and relevant guidelines for this control.

Control 08 – Audit log management

Centralized and supervised logging is essential for detecting malicious behavior in any system. This is true for both detections of ongoing attacks and as an audit tool to estimate effects after a breach. Modern services from cloud providers enable automated detection of anomalies but typically require that the system collaborates by returning correct HTTP responses, logging domain events and exceptions.

Even with tuned, automated detection of anomalies, we still need manual review of logs to complement automation. A strong team will tune a process as they gain experience with production events.

Note that the verifications for this control address both audit and system logs, as well as network monitoring logs (see Control 13.) In a cloud-native environment all logging should be centralized and enable the team and organization to detect, understand, and recover from an attack.

V8.A

Verify that a central service for logs is used that is built for the purpose. In example supporting security information and event management (SIEM.)

V8.B

Verify that the logs can be used to detect penetration tests, system misuse and support intrusion detection.

V8.C

Verify that audit and security related logs are retained for a minimum of 90 days.

V8.D

Verify that there is a documented process for manual review of logs on a weekly schedule.

V8.E

Verify that external services are part of the log review process (IG3).

V8.F

Verify that complete request chains and events can be traced and correlated to a given context.

V8.G

Verify that there are automated alarms for anomalies and unexpected data exfiltration.

V8.H

Verify that automated alarm thresholds are tuned periodically, e g weekly. (IG3).

V8.I

Verify that the team's responsibility is well understood and aligned with the organization's SOC capabilities.

Please note that the team probably need to enable separate cloud products to collect all logs needed in V8.B. For example, in Azure, to comply with Safeguards such as 1.4 and 8.6 you likely need to enable Defender for Cloud (other platforms have similar security services.)

In addition to the verifications listed above, OWASP ASVS section 1.7 and chapter 7 provide relevant guidelines for this control.

Control 09 – Email and web browser protections

Threats from email and web browser vectors are normally not managed by the DevOps team. However, developers (in particular those who do operations in production environments) are high-value targets, and these vectors are important to understand. We want to emphasize browser plugins in particular since they are commonly used.

V9.A

Verify all CIS Safeguards in control 9.

Control 10 – Malware defenses

Protection against malware is often managed by a separate team. For a DevOps team, centrally managed software and restrictions often need to be relaxed for effective work to happen. The team needs to understand the risks and balance the need for malware defenses with developer efficiency.

A good example is the plugin model of many types of applications. For example, the team's development process may be more efficient while using extensions in the IDE. However, it's hard to continuously verify the intent and quality of these plugins, which could lead to unauthorized code being executed on the developers' computer. It is therefore necessary for the team to reason about the need of plugins and extensions in the IDE and build pipelines.

The team should share an understanding of risks associated with installing plugins, developer tools, etc. For a cloud-native DevOps team this is to some extent addressed by verifications for the controls 2, 7, 15 and 16, but it is important to also include developer tools as part of the threat model.

V10.A

Verify all CIS Safeguards in control 10.

V10.B

Verify that a process exits for selecting any kind of tooling (software) the team installs on their devices.

Control 11 – Data recovery

Availability is an often neglected part of cybersecurity for DevOps. The ability to quickly recover by restoring data or repaving a deployment is critical. Documentation in the form of text files committed to source control and infrastructure source code is a simple, working solution for many teams.

Note that the DevOps team often is part of an enterprise wide incident response plan, and it is important that the plans for business continuity (BCP) and disaster recovery are aligned with the process for handling incidents, see Control 17.

Performing regular disaster recovery exercises is vital, in the same way testing your data backups is vital. An exercise not only verifies the documentation and IaC but also spreads knowledge about the overall system in the team. It should be clear to the team how to:

• Set up a completely new environment
• Rotate all credentials
• Restore suitable backups
• Restart the system to enable normal operations in a timely manner (meeting BCP requirements)

Keeping the availability and integrity of backups are essential to protect from ransomware attacks. The team should consider the effect of losing the backups and take relevant measures. Minimise the consequence of an attack can be done by using the backup services supplied by the cloud provider and following the best current practises asserting least privilege for write operations. A common configuration for backups and logs are to only allow append (not update or delete of existing data.)

To protect against accidental loss or malicious deletion it is also important to assert proper configuration regarding isolation of backups from the source environment and in example proper usage of geo-redundancy features provided by the cloud provider.

The team must also ensure that read access is under the principle of least privilege to maintain the confidentiality of the data. Backups and potentially even logs are often just as sensitive as the live production data and need the same level of protection (including monitoring and alarms.)

Also note that rotating credentials is part of mitigating and recovery from attacks.

V11.A

Verify that all data is automatically backed up using a service that is built for purpose.

V11.B

Verify that backups are protected to the same level as the source data.

V11.C

Verify that backups are protected from accidental loss or malicious deletion.

V11.D

Verify that backups are tested on a recurring schedule that matches the risk of data loss.

V11.E

Verify that there is a documented disaster recovery process that is tested on a recurring schedule.

In addition to the verifications listed above, OWASP ASVS sections 8.1.5, 8.1.6 and 14.1.4 provides relevant guidelines for this control.

Control 12 – Network infrastructure management

Network infrastructure management, architecture and segmentation are often, just as availability and disaster recovery, overlooked by cloud-native DevOps teams. Many organisations and teams tends to focus on development of the applications the team builds, and underestimate the resources needed for secure networking and operations. Network infrastructure management is addressed by verifications in controls 1 and 4. Verifications in this control concerns network architecture, segmentation and resilience.

The network architecture should enable segmentation based on least privilege. Any resource, web application, or API that does not need to be publicly available should be segmented, with firewall protection denying all access from untrusted resources or networks.

One reason why segmentation is overlooked is that cloud resources are typically available from the internet by default since cloud providers prioritize ease of setup over network segmentation. Leaking a connection string in a default configuration means an attacker has unrestricted access to that data from the internet. Databases and storage services should typically not be exposed directly to the internet.

It should also be noted that even if zero trust is applied, with authentication of all requests in each service, a strong solution should also apply defense in depth techniques, applying networking and infrastructure defenses as well. Strong identity based security does not replace the need for e g firewalls and gateways, just as a firewall does not replace the need for proper access control in each service.

There should be a relationship between information classification of data and the network architecture. This relation is trivial to understand for some systems, but some need dedicated documentation on the information security architecture.

V12.A

Verify that there is a segmented network architecture that is based on least privilege.

V12.B

Verify that there is documentation that maps information classification to the network architecture. Note that this also should map to information documented in V3.A.

V12.C

Verify that users connecting to resources in network segments do so in a way that follows best practices from the cloud provider.

V12.D

Verify that all parts of the system meet availability requirements and have an SLA that meets those requirements (if SLA is appropriate.)

V12.E

Verify that all endpoints in the system have appropriate infrastructure protection, e g all public endpoints should have a Web Application Firewall and DDoS protection supported by the cloud platform.

Please note that CIS Safeguard 12.8 requires dedicated computing resources that never connect to the internet for all administrative tasks. It is unreasonable to never connect to the internet for a cloud-native system, since the cloud-platforms are manged by using public web interfaces (cloud vendor portals) and APIs.

Even so, care should be taken, and V12.C should be aligned with the threat model. For some teams (or organisations) this means separate hardware, VPN and specific personal administrative accounts for operations in production. For other teams using a developer machine, dedicated VMs on a developer machine or connecting via a jumpboxes is a sufficient solution.

Regardless, it is vitally important to follows best practices from the cloud provider and use strong user authentication, preferably combined with device policies which for example restricts access to known managed devices that are compliant with enterprise policies.

Please also note that CIS Safeguards 9.2, 13.9, 13.10, and 13.4 require that we restrict traffic between network segments and outbound (“known malicious domains”). We include these aspects in the “least privilege” concept in V12.A.

In addition to the verifications listed above, OWASP ASVS sections 1.9, 1.14, and 11.1 provide relevant guidelines for this control.

Control 13 – Network monitoring and defense

Just as secure network infrastructure management and configuration, network monitoring and defense is often overlooked by DevOps teams, as teams often have focus on the applications the build and less resources for operations and infrastructure.

Compared to a traditional on-premises application hosted on VMs, network monitoring, and defense are simplified for a cloud-native application built without IaaS. Selecting cloud resources that move security hardening and actions to the cloud supplier simplifies work for the team.

It should, however, be noted that cloud environments still need hardening; they are not secure by default. The team need to follow guidance on network infrastructure management and configuration from Control 4 and Control 12 (which in example includes applying relevant CIS Benchmarks.)

A cloud-native DevOps team that knows their system and what traffic to expect can have very good situational awareness. In this context, network monitoring and defense safeguards are to a large extent covered by the verifications in Control 8, together with controls 4 and 12.

Aspects of CIS Control 13 Safeguards not covered by verifications for control controls 4, 8, 12 and 16 are consider not applicable for a cloud-native DevOps team. In example 13.9 - Deploy Port-Level Access Control is typically not the responsibility of the DevOps team. See mapping of CIS Control 13 Safeguards in Mapping to CIS Controls v8 safeguards.

V13.A

Verify all CIS Safeguards in control 13 are addressed by verifications in other controls or considered not applicable for the DevOps team.

In addition to the verifications listed above, OWASP ASVS chapter 7 provides relevant guidelines for this control.

Control 14 – Security awareness and skills training

The approach to training and education varies between organizations. If there is no structured effort in the organization, we expect the team to fill the gap themselves and then follow the CIS control safeguards without the need for interpretation. We expect the DevOps team to receive additional role-specific training. Besides application security, it is common for a DevOps team to lack resources (or understanding) of secure operations and networking.

Examples of role specific training for a cloud-native DevOps team:

• In depth education and training for the cloud platform, for examples certifications and CIS Benchmarks
• In depth education and training for application security, both building and attacking, for example using OWASP ASVS and Juice Shop

It is hard to measure and decide on how many resources a team should spend on training. One way to measure this is given in CIS Controls Assessment Specification, see https://controls-assessment-specification.readthedocs.io/en/stable/control-14/index.html

V14.A

Verify all CIS Safeguards in control 14.

In addition to the verifications listed above, OWASP ASVS chapter 1 provides relevant guidelines for this control.

Control 15 – Service provider management

The team does not always control the selection of services outside of the cloud provider. However, the team should always be a stakeholder in the selection process since the service will affect the cybersecurity of the system they build, operate, and defend. And it is also important that the team takes operational responsibility for the integrations and understands the risks they might introduce.

One example of services that often are overlooked might be external services, brought in by the DevOps team, like Google Analytics or vulnerability scanners. Even if the purpose is good, most integrations introduce some attack vectors and need proper service management.

For a cloud-native DevOps team many aspects of the CIS control 15 safeguards are also addressed in verifications V3.A, V8.I, V16.D and V16.E. In addition to that the CIS control 15 safeguards are clear and to the point, and there is no need for further interpretation. It should be noted that documenting how to assess a service provider for the team often overlaps with how to select dependencies (V2.F) and manage developer tooling etc. (V10.B.)

V15.A

Verify all CIS Safeguards in control 15.

Control 16 – Application software security

The development process should take a structured approach to security. From a build perspective, we are looking for:

• Define security as part of the requirements, tests, and quality assurance (just as any other non-functional requirement)
• Version control of all parts of the software, including infrastructure and configuration
• Enforced pull requests with tracking of work items that reference requirements
• Automated, continuous build and deployment to production from main or dedicated release branch only (including unchanged artifacts between test and deploy)
• Automated tests and scans in the build pipeline
• Management of secrets in a service that is built for purpose
• Applications should support rotation of secrets
• Selection, management, and replacement at end-of-life for all packages, frameworks, OS etc. (see section 8.2 for a discussion on package management)

From an architectural perspective, we are looking for:

• Isolation of production environment from all other environments
• A design based on defense in depth, zero trust and least privilege
• All networks are considered insecure
• All clients and users are authenticated
• Access control for every request
• Minimal privileges to perform an operation
• Established trust boundaries
• Network segmentation (with information classification, public exposure only when needed)
• Security in multiple layers, in both infrastructure and applications
• Centralized authentication of users and services via a token service (OIDC/OAuth2)
• Centralized logging with alerts and audit
• Implementation according to the best current practices from e g OWASP, CIS, FAPI and OAuth 2 BCPs etc. This also includes relevant industry standards, reference architectures, and IT-polices.
• Documentation that allows the team to understand and explain their system, and reason about security.

CIS Controls references a process for vulnerability management and root cause analysis in some detail. The team should be able to handle vulnerability reports in a structured way. Communication with customers and stakeholders is typically out of scope, but if there is no process in place in the company, the team needs to have their own.

V16.A

Verify that the team has a structured way of working and follows a secure development process, aligned with the defined security baseline. This includes keeping the security baseline and GAP analysis up to date.

V16.B

Verify that there is a process for handling vulnerability reports from customers and stakeholders, including root cause analysis and the capability to prioritize between reports and audit remediation timelines.

V16.C

Verify that the team has knowledge of application security, as it applies to the system, and time to keep tools and skills up to date.

V16.D

Verify that the development process includes threat modeling and that those results are understood and guide the implementation decisions (IG3).

V16.E

Verify that implementation is according to the build- and architectural principles in this chapter.

Note that we interpret CIS Safeguard 16.13 as part of V18.B If the team has a structured way of working with security and can verify security requirements, then the team should perform internal security testing is part of the process. This work is important, but does not replace penetration tests from an independent external partner (see Control 18).

CIS Safeguard 16.12 is interpreted as optional, as the value of static analysis tools varies depending on the kind of code base and level of security (IG2 or IG3). Reviewing code manually from a security perspective is important and is part of V16.A and V16.E. It should also be included in penetration tests (see Control 18).

Control 17 – Incident response management

If there is no company plan for incident handling, then the team must take full responsibility for this control, including all CIS safeguards. However, if there is a well-defined company plan, the minimal documentation needed for the team is contact information and instructions on how to start the incident process and to understand the teams role in the incident response process.

V17.A

If managed by the team: Verify all CIS Safeguards in control 17.

V17.B

Verify that team documentation includes contact information and instructions on how to start the incident process and that the team understand the teams role in the incident response process

Control 18 – Penetration testing

Like incident handling, a recurring, structured approach to penetration testing is rarely handled by the team itself, but it is important that the team understands strategies for penetration testing and how it concerns the team. Therefore, there is only one additional interpretation given by V18.C.

V18.A

Verify all CIS Safeguards in control 18.

V18.B

Verify CIS Safeguard 16.13.

V18.C

Verify that penetration test are accepted by the organization and that the threats represented by the listed weaknesses and vulnerabilities are understood and mitigated.

Mapping to CIS Controls v8 safeguards