GFT Technologies: Six Techniques for Continuous Compliance


Six Techniques in Continuous Compliance

A DevOps approach to security risks and regulatory pressures in the cloud.

The adoption of the cloud has profound implications for cybersecurity. As a result, organizations that want to use the cloud in highly regulated areas such as financial and healthcare facilities must demonstrate compliance with legal requirements related to security threats. These requirements come from industry standards (such as the Payment Card Industry Data Security Standard or PCI-DSS) or local market regulators (such as the European Central Bank). In addition, some of the main advantages of the cloud, namely greater agility in adapting to market changes and innovations, shorter time to market, and a significant reduction in investment costs, also come at a price. The bottom line is that there is a higher risk of misconfiguration of cloud resources. In fact, the US National Security Agency lists misconfiguration as the most common cloud security vulnerability[1].

One way to counter this threat is through extensive auditing. However, ad hoc audit requests to identify vulnerabilities are costly and often pose a risk to companies, as compliance is only checked periodically and there is room for non-compliant scenarios to occur between audits. The challenge increases with size: huge companies with multiple audit sources (supervisory authorities, 3rdapprox Parties, internal audits) end in an endless auditing cycle that significantly increases operating costs. Traditionally, extensive documentation was created in documents and tables that only showed compliance with the regulations at a specific point in time. In any case, the creation of such permanent documentation required an enormous effort by qualified persons using a large number of data sources. And once that was done, an audit was out of date almost immediately.

The DevOps culture results in a viable solution to compliance management challenges, with Continuous Delivery being one of the most mature outcomes. This approach assumes that cross-functional deployment teams (development / QA / support etc) are created, which leads to the adoption of the “you build, you run” approach, reduces time to market and increases the number of post-phase incidents Deployment decreased. This is primarily achieved through the introduction of automation in artifact generation, pre-deployment quality checking with automated tests, and post-deployment verification.

Continuous delivery transforms the classic delivery model into a continuous process by reducing the feedback and delivery loops. This is typically achieved by categorizing the delivery into the smallest possible pieces (e.g. a single microservice) by creating templates for reuse in other areas. These practices create confidence in smaller parts of distributed systems and help reduce time-to-market for changes and greater stability.

Similar to how DevOps enables continuous delivery, this can be a reason for the establishment continuous compliance: an efficient approach to the culture of people, tools and services.

Some of the common approaches to ensure continued compliance are:

  • Pre-build and pre-deployment checks,

  • Use of templates when creating resources,

  • Transformation to the machine model for the creation of cloud resources,

  • Post-deployment controls,

  • immutable infrastructure.

Let’s look at six examples of how adopting continuous compliance can help companies meet the ever-increasing challenges related to cybersecurity and regulatory requirements.

1. Checks in delivery pipelines

Pre-Build / Pre-Deployment verifications are most beneficial because fix costs are lowest when problems are identified at the developer’s desk who can fix them quickly. Typically, these reviews include artifact license reviews and library reviews for common software artifact vulnerabilities. When deploying infrastructure, these reviews typically focus on verifying the following basic patterns. For example, make sure 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 is to create and use resource configuration templates based on larger security design patterns. Let’s take a securely created API gateway for B2B integration as an example of a security pattern. A security pattern can be created through the translation of security regulations in advance and / or through a threat analysis (e.g. DDoS risk for public endpoints). These security patterns are then translated into Infrastructure as Code modules. By encapsulating them in modules, other API gateways or components can be quickly replicated with the same configuration. An 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 teams can use wizard-like interfaces to set up new infrastructure components. By isolating the resource template execution behind the automation and having a wizard-like interface, the risk of the template being changed while a resource is being created is reduced.

4. Run time checks

Regardless of the focus on creating reusable, standardized building blocks that represent patterns that are compliant with regulatory agencies and internal auditing, companies are introducing separate automated reviews for resources created. These can be divided into two variants: preventive and detective. Preventive audits protect against creating non-compliant resources even if a person were able to overcome audits prior to deployment (for example, by using a different creation method). Detective audits focus on raising alerts and reporting resources as non-compliant, but without preventing them from being created. Depending on company policy, detective rules may be preferred in the non-production environment to expedite experimentation with resources, while production environments may depend on preventive rules.

5. Compliance as a code

In order to create transparency when introducing pre- and post-deployment checks, we use the same process as for software deployment, ie we rely on tracking changes using a source code management system (e.g. git). This gives auditors complete transparency of the audit trail, e.g. B. if encryption is now required during transmission and which encryption keys have been accepted. The approach of using compliance rules controlled by source code management tools is called Compliance as a code. When such a configuration is stored in a source control system, it is much easier to present it to an auditor as evidence rather than extracting such information from various tools.

6. Immutable Infrastructure

Another approach that embodies the idea of ​​continuous compliance is immutable infrastructure. A changeable infrastructure means that when a configuration change is required, this is done on a provided resource (e.g. a server). If we authorize these changes, we may need to verify that the updated server conforms to an agreed security pattern. To dramatically reduce the cost of compliance checking, the deployment is performed from an already compliant new image rather than changing resources after deployment. This allows only a single compliance check of the new server image.

These practices are the result of our extensive experience in delivering secure and compliant cloud solutions to customers who primarily operate in highly regulated sectors such as finance.

Our expertise has enabled us to recently acquire the DevOps competency Amazon Web Services (AWS), which serves as important evidence of our in-depth knowledge and practical experience in secure cloud infrastructures.

Read here or press release about our Amazon Web Services (AWS) certification “AWS Migration and DevOps Skills”


Source link

Leave A Reply

Your email address will not be published.