Overview

Compliance as Code with qTOOLS for Financial Services

The Financial Services industry is known for being risk-averse, which has made it slow to adopt new technologies. This is especially true for cloud technology, which was initially seen as a risky proposition. In the early days of cloud, there were concerns about security, reliability, and data privacy that made it difficult for Financial Services companies to justify the risk of moving their critical applications and data to the cloud. Additionally, highly regulated industries like Financial Services must get things right the first time, or risk being front-page news due to a security breach or compliance violation.

However, over time, it became clear that the benefits of cloud technology could not be ignored. The scalability, flexibility, and cost-effectiveness of cloud infrastructure made it an attractive option for many Financial Services companies. As a result, many companies began to explore cloud solutions, but they still approached it with caution. Rather than taking a “let’s get there first and figure out the rest” approach, they took their time to make sure they got it right. A prominent bank in California (the client) is one of those organizations that took a cautious approach to cloud adoption. The client recognized the benefits of cloud technology, but they also understood the importance of security and compliance in their industry. As a result, they implemented numerous processes and tools to shift-left with their security posture. However, they still required any application destined for public cloud to go through multiple checks before it could go live for consumers.

Opportunity

The security, compliance, and risk teams at the client defined the “Permit To Operate” (PTO) process as a review gate for applications to migrate to the cloud. To get the green checkmark for PTO, an application had to satisfy a set of 50+ items, including security and compliance requirements. To meet these requirements, the AppDev and DevOps team had to collect evidence, such as screenshots from the AWS console and snippets of log data from security scanning tools, then provide them to the architecture, security, and compliance team for verification and signoff.

Initially, the PTO process was a manual process that quickly became a bottleneck in the process of releasing an application on the cloud. PTO for each application took weeks. To solve this problem, the Cloud Governance team at the client set out to automate the PTO process to the extent possible.

Given the complexity of the rules, no tools available in the market were a straight fit for the PTO process. Additionally, the client security team already utilized AWS Config to validate compliance. As a result, Cloud Governance decided to write custom AWS Config rules to automate the gathering of evidence for AWS resources.

However, during the initial phase of automating the first 5 PTO items, the Cloud Governance team realized some pitfalls in this approach. For instance, developing custom AWS Config rules needed developers with advanced knowledge of AWS. Additionally, AWS Config service usage and access were strictly controlled by the client security team, which added a layer of complexity to implementing custom rules. At the end of the day, custom rules were still codes that needed to go through their PTO process. Once the evidence was gathered, it ended up again on AWS Config. Application teams still needed to gather screenshots from AWS Config to seek signoff.