GFT Technologies : Six techniques in Continuous Compliance

Six techniques in Continuous Compliance

A DevOps approach to security risk and regulatory pressure in the Cloud.

Cloud adoption has profound ramifications for cybersecurity. Consequently, enterprises wishing to adopt the cloud operating in highly regulated areas, such as financial and healthcare institutions, must prove compliance with regulatory requirements related to security threats. These requirements originate from industry standards (such as the Payment Card Industry Data Security Standard or PCI-DSS) or local market regulators (like the European Central Bank). Moreover, some of the chief benefits of the cloud, namely increased agility in adapting to market changes and innovation, improved time to market, as well as a significant reduction in capex, also come at a price. Bottom line is that there is a higher risk of misconfiguration of cloud resources. Indeed, the U.S. National Security Agency indicates misconfiguration as the most common cloud vulnerability[1].

One way to combat this threat is comprehensive auditing. However, ad hoc audit requests aimed at detecting vulnerabilities are costly and often put organisations at risk, since compliance is verified only periodically, leaving room for occurrence of non-compliant scenarios in-between audits. The challenge intensifies with size: huge enterprises with multiple sources of audits (regulators, 3^rd parties, internal audits) end up in a never-ending cycle of auditing, which increases operational costs by a significant margin. Traditionally, extensive documentation was created in documents and spreadsheets that represented regulation compliance at a specific point in time only. In each instance, creating such fixed documentation took tremendous amount of effort by qualified people, using a myriad of data sources. And once that was done, an audit became outdated almost immediately.

A viable solution to challenges in compliance management is emerging from the DevOps culture, with Continuous Delivery being one of its most mature outcomes. This approach assumes creating cross-functional teams of delivery (development/QA/support etc.) which leads to adopting the "you build you run it" approach, improving time to market and lowering the number of incidents in post-deployment stages. This is achieved primarily through introduction of automation in artifact generation, pre-deployment quality verification with automated tests, as well as post-deployment verification.

Continuous Delivery is transforming the classic model of delivery into a continuous process by reducing the feedback and delivery loops. This is typically achieved by categorizing delivery into the smallest possible pieces (e.g., a single microservice), creating templates for re-use in other areas. These practices build trust in smaller parts of distributed systems and contribute to improved time to market for changes and higher stability.

Similar to how DevOps allows for continuous delivery, it may be grounds for establishing continuous compliance: an efficient approach to people culture, tools and services.

Some of the common approaches to satisfy continuous compliance are:

• pre-build and pre-deployment checks,
• usage of templates when building resources,
• transformation to vending machine model for creating cloud resources,
• post-deployment checks,
• immutable infrastructure.

Let's look at six examples of how introducing continuous compliance helps organisations face the ever-increasing challenges in cybersecurity and regulatory requirements.

1. Verifications in delivery pipelines

Pre-build / pre-deployment verifications are the most beneficial because remediation costs are at the lowest when problems are detected already at the desk of a developer, who can fix them quickly. Typically, these checks include artifacts license checks and library checks against common vulnerabilities for software artifacts. For infrastructure provisioning, these checks are typically focused on verification of following fundamental patterns. For example, ensuring that all new databases are encrypted at rest and use customer managed encryption keys.

2. Creation of resources from compliant templates

Another technique of continuous compliance consists in the creation and usage of resources configuration templates built based on bigger security design patterns. As an example of a security pattern, let's take a securely built API gateway for B2B integration. A security pattern may be created by translating upfront security regulations and/or by threat analysis (e.g., risk of DDoS for public endpoints). These security patterns are then translated into Infrastructure as Code modules. By encapsulating into modules, other API gateways or component parts can be quickly multiplied with the same configuration applied. Identical configuration ensures compliance with documented standards in the module.

3. Vending machines

A slightly more advanced version of the software module approach is the concept of a vending machine. Business squads can utilise wizard-like interfaces to setup new infrastructure components. By isolating resource template execution behind automation and a wizard-like interface, the risk of modification of the template during creation of a resource is mitigated.

4. Runtime checks

Independently from focusing on creation of reusable, standardised building blocks representing patterns compliant with regulators and internal auditing, organisations introduce separate automated checks to created resources. These can be divided into two variations: preventive and detective. Preventive checks guard against creating non-compliant resources even if a person could overcome pre-deployment checks (e.g., by using a different method of creation). Detective checks are focused on raising alerts and reporting resources as non-compliant but without preventing their creation. Depending on company policy, detective rules might be preferred in the non-production environment in order to speed up experimenting with resources, while production environments might depend on preventive rules.

5. Compliance as Code

To help achieve transparency in introducing pre- and post-deployment checks, we use the same process as in software delivery, i.e., rely on tracking changes using some form of a source code management system (e.g., git). This provides complete transparency of audit trail to auditors, e.g., when encryption in transit is now required and what encryption keys were agreed to be accepted. The approach of using compliance rules controlled by source code management tools is called Compliance as Code. When such configuration is stored in a source code management system, it is much easier to show it as evidence to an auditor, instead of extracting such information from different tools.

6. Immutable infrastructure

Another approach that embodies the idea of continuous compliance is immutable infrastructure. Mutable infrastructure means that if some configuration change is required, it is done on a deployed resource (e.g., a server). If we authorise these changes, we may need to check whether the updated server remains compliant with an agreed security pattern. To drastically reduce compliance check cost, instead of modifying resources after deployment, deployment from an already compliant new image is executed. This allows for only a single compliance check of the new server image.

These practices are a result of our extensive experience in delivering secure and compliant cloud solutions for clients that operate mainly in highly regulated sectors such as finance.

Our expertise has enabled us to recently obtain the Amazon Web Services (AWS) DevOps Competency, which serves as important evidence of our strong knowledge and hands-on experience in secure cloud infrastructures.

Read here or press release about our Amazon Web Services (AWS) certification "AWS Migration and DevOps Competencies":www.gftglobal.com/3CUMkNB

[1] https://media.defense.gov/2020/Jan/22/2002237484/-1/-1/0/CSI-MITIGATING-CLOUD-VULNERABILITIES_20200121.PDF