FinTech Compliance: Tales from the Cloud

Public cloud providers enable financial services firms to deliver new products and capabilities at breakneck speeds, but how do you balance speed to market against FinTech compliance mandates – do you have to choose? This presentation looks at how to prove to auditors that you’re protecting personal data across your cloud estate, and reveals tips for reducing friction between DevOps and IT security teams, and lessons learned from Orca Security FinTech customers.


Thank you for giving me the next 30 minutes of your time. I know everybody’s suffering from a little bit of Zoom meeting and presentation fatigue, so I really do appreciate it and hope that you find it valuable. Today, we’ll be speaking about cloud compliance and governance in the context of financial services and some strategies to both innovate rapidly by making use of modern cloud infrastructure and staying compliant with those regulations and data security standards that govern us.

My name is Patrick Pushor, technical evangelist here at Orca Security. My background includes both a decade-long stint as an infrastructure consultant here in Western Canada, and almost 15 years working with startups across FinTech, cybersecurity, and infrastructure operations and automation. I’ve been to lead both product and sales teams, so I’ve had a chance to work directly with customers and hear of their challenges first-hand. In the next 20 to 25 minutes, we will cover the current challenging FinTech compliance landscape. We’ll talk about the drivers for constant innovation in FinTech. Next, how the whole tech stack, which isn’t exactly the same as infrastructure has become a differentiator. We’ll talk about compliance versus innovation and some different perspectives around that. Then six different strategies for innovation while remaining compliant. And lastly, we will talk through some success stories from FinTech and FinServ customers of Orca and how they’ve managed to innovate while maintaining visibility and compliance.

Financial services face very challenging times as individuals and businesses struggle with the COVID-related economic fall-out. But at the same time, they must cope with unprecedented growth as financial transactions shift online. Financial services have access to more data about their customers than ever before through analytics, but struggle to create value out of that data in the short-term, as machine learning models and AI capabilities mature. They are governed by a complex regulatory landscape that spans international boundaries with significant consequences for non-compliance. The instant-on digital retail experience informs our expectations in terms of digital transacting and sets a high bar for financial institutions and FinTech providers to achieve. Lastly, threat actors become more and more sophisticated over time in modern cloud infrastructure and have access to the same powerful tools that we do as information owners.

Challenges Facing Financial Services Executives and Managers

Financial services leaders are focused on four main buckets of problems. First, differentiation. How can I add value to my offerings? How can I capitalize on major trends in my industry like blockchain, the internet of things, or AI?

Customer experience: How can I make the customer journey more fluid? How can I communicate with customers in the way that they want?

Optimization: How do I leverage cloud to reduce costs and increase my time to value when launching new products and services? How do I make use of the data I collect about my customers?

Cybersecurity: How do I innovate quickly while staying well-governed and compliant? Which, of course, is our focus today. What processes and tools will I require to stay one step ahead of bad actors?

The Tech Stack as a Differentiator

As I mentioned before, I’ve been fortunate enough to work with multiple FinTech startups that often engage with the many platform players, the building blocks of financial services, and I quickly learned about how modern digital banks were being built, and that is by composing multiple FinTech providers together. These platform providers exist only to integrate into a part of the tech stack and provide a solution to a problem. Their bread and butter is integration. They talk APIs, data formats, and identity all day long. The result is the possibility to integrate those solution providers together to create unique services. This is predicated on the fact, of course, that you understand and have experience with software integration, leveraging APIs, modern data formats, great user experience design, and the list goes on.

All of this requires infrastructure. As we build, if we’re iterating on concepts that may or may not be part of our final solution, it only makes sense to leverage the pay-only-for-what-you-use nature of the public cloud. The pervasive perspective is that the combination of agile infrastructure and agile software development methodologies is a real differentiator versus financial services built atop big monolithic systems that have limitations around interoperability and scale. Antony Jenkins, the former Barclay’s CEO described traditional banks as “museums of technologies,” meaning that they are poster children for hanging onto obsolete technology and hence racking up technical debt.

Why? There isn’t one single answer, but a big part of that reluctance to modernize is rooted in the cost of compliance to an organization. Pivoting on technology is expensive but coming to grips with governance and compliance of new technology, and more specifically, new infrastructure is really difficult and thus expensive. For businesses to succeed internationally, it’s imperative for them to stay compliant. However, in the face of rapid transformation and digital disruption, one of the greatest risks organizations face is the failure to innovate. In one respect, one needs to be a disruptor, and yet compliance is a discipline where there is little tolerance for major change.

FinTech Compliance vs Innovation: Six Recommendations

Compliance is the foundation we need to hold everything together. So, how do we marry innovation and compliance? Let’s talk about six different strategies to innovate at the speed of cloud, if you will, while being able to remain in compliance with security standards. Number one, plan compliance early and develop a framework such that follow-on initiatives can easily adopt it. It can be simple to start. Number two, plan a holistic view of compliance and risk across all processes and technology. Number three, although it sounds the same as number two, it isn’t. Find methods to measure risk and compliance that are painless for the rest of your organization. Low or no friction means 100% adoption, and that’s your goal. Number four, build guard rails to enforce process automatically rather than building manual processes wherever possible. Number five, when calculating risk, consider context. It’s the best answer to alert fatigue. We’ll talk about this shortly. Lastly, number six, compliance provability needs to be both wide like a cloud security posture manager measuring control status of many different services, and deep right down into workload and data protection.

Planning Compliance a Real Strategic Advantage

I was listening to a webinar earlier in the week featuring George Kurian, who heads up security at Moody’s, who laid a bunch of different financial instruments among other things. He spoke about the phenomenon of explosive cloud growth across an organization. Once a business unit adopts the cloud and rumblings of instant-on, all the scale you’ll ever need and virtually no procurement cycle make their way around an organization, well, if you haven’t considered how you’re going to keep this thing on the rails by then, good luck. You’ve got an uphill battle ahead of you. If you are formally regulated, each cloud provider has done a relatively good job mapping the major standards to controls and best practices. If you want to go further, and you probably should, most FinTech compliance standards lack some operational security checks that you’ll want to leverage, or if you aren’t regulated but want to ensure great governance and provability of that standard to customers, consider leveraging parts of existing standards that make sense for your business.

Amazon Web Services has done a really good job of mapping PCI controls to AWS features and how to use them. I recommend you pull out those parts that make sense for you or use it in its entirety. This small screenshot of the AWS spreadsheet that maps PCI controls to AWS features and talks about how to encrypt, log, assign rights, and much, much more.

Public Cloud Compliance Differs from Data Center Compliance

Compliance in the public cloud versus in the data center is a very different challenge. Assumptions about what we think we know get us into trouble here, but the fact remains that way more controls exist that represent way more change than ever before. Micro-segmentation alone means that instead of a pair or several pairs of firewalls to manage in our data centers, we have hundreds and thousands of them to manage in the public cloud. In addition, unauthorized change is always only, at most, a credit card away. With the rate of change associated with the public cloud, it’s important to ensure that tools measure continuously and not point-in-time as we did back in the data center. This will likely require new tools and processes, so while you’re shopping, it’s a perfect time to ensure support for the technology you utilize today and that you plan to utilize tomorrow. So, for example, multi-cloud, containers, serverless, etc.

Orca customers tell us that leveraging technology and processes that require buy-in across organizations is virtually impossible. So, find solutions that are non-obtrusive, but provide the level of visibility you need. To communicate with all stakeholders effectively, it’s important that both detailed reporting and summarized executive dashboards are available to convey security situational awareness. In the same vein, ensuring business units have their own visibility into the problem of security and compliance means that your reports don’t have to have the level of detail that a practitioner will need to solve problems, and will also translate into a better understanding of the problem over time.

It’s key to ensure that you have more than simple alerting in place. Do the alerts have enough information to fix the problem? If not, why not? A cloud security and compliance skillset is still difficult and expensive to hire and train. Your FinTech compliance tools and process should do as much of the heavy-lifting as possible. Lastly, cloud security posture managers, which measure cloud services for security control best practices, are great and needed, but don’t forget the deep stuff as well, the workload configuration and data contained within them.

So, detecting anomalies in production is a good first step, but stopping them from being provisioned in the first place is the goal. This is the famous shift-left and CI/CD security paradigms we hear so much about. When we get compliance and security to the process earlier, we can ensure that everything we do is measured before we actually provision anything. Infrastructure as code is one of the ways we do this, expressing our intent in code. In cloud infrastructure terms, this is often referred to as a cloud formation template, an Azure blueprint, or a Terraform module, or something similar. Other means to shift-left include assessing incidents and container images as they are created but before they are deployed to production environments. Insofar as remediation, it can still be done manually, but make sure you have enough information to do so efficiently. If you are doing or considering auto-remediation, you must have zero tolerance for false positives. Do you have that sort of accuracy in your compliance test today?

When we think about judging workload vulnerabilities, CVSS scores that function as risk scores simply aren’t enough as not all clouds are created and configured equally. For example, if a remotely exploitable vulnerability is found on an isolated workload with no network access, is that a high-risk finding? How about a software vulnerability where no fix exists? Should that vulnerability be scored as high as one that is fixable? In the same breath, would I rather hear about hundreds of vulnerabilities or understand that upgrading one software package will take care of them all? This is the power of context, and it’s our best weapon against defending alert fatigue. We should pay attention to the consequences of alert fatigue. In research of the Cloud Security Alliance and McAfee released a couple of years back, nearly a third of IT pros ignore alerts. Forty percent of those say that the alerts lack enough information to be actionable, and nearly a third say that alerts get ignored because so many of them wind up being false positives.

We’ve touched on this in a couple of different parts of the presentation thus far, but it’s important and worth considering on its own. Cloud compliance means measuring cloud security controls, workloads, and data for risks. Each of these planes is inseparable. From an attacker’s perspective, they would love to skip the network entirely and simply gain control of your cloud console. And this becomes possible when they find embedded cloud credentials on a host, for example. Most compliance standards demand endpoint visibility and protection, no less than seven require file integrity monitoring or FIM. It boils down to auditors needing to see that you have constant eyes on both your configuration and data. Using native tools becomes challenging with multi-cloud use cases as data and capabilities consistency across providers becomes difficult to maintain.

Customer Case Studies: FinTech Compliance, Provability from the Trenches

With that, I’d like to spend our time remaining together to talk about Orca customers that have faced this problem of achieving and maintaining compliance, a very modern public cloud infrastructure. We’ll talk about the ins and outs and lessons learned from the trenches.

Orca Facilitates Security and Compliance for Live Oak Bank

Live Oak Bank is a North Carolina bank that has made the transition to AWS and has a sprawling estate not unlike the story we heard earlier from George at Moody’s. The bank also has FinTech partners that use both AWS and Azure with Live Oak’s system interconnecting them. As a chartered bank, Live Oak must comply with U.S. data privacy and security regulations like any financial institution must do, both regionally and internationally. Live Oak values the fact that Orca helps them convey the security posture of their cloud environments. The Live Oak Corporate Risk Group finds it very advantageous to have Orca to meet this need. And it’s worth mentioning that Live Oak uses a hybrid-SaaS version of Orca Security called Orca Pod. It permits the bank to keep its data within its own environment while only transferring metadata to Orca. Orca works by scanning your workloads out of band, which is different from an agent approach that requires software installation and interpreting those findings.

Orca Security Identifies and Protects PII, Easing Paidy’s Compliance Efforts

Paidy is a Japanese mobile payment platform and must comply with a number of data privacy laws. Orca helps prove to auditors that Paidy is fully capable of identifying personal information. Jeremy at Paidy really likes that Orca lets them know if PII is suspected across all of their workloads and storage buckets. He calls it a beacon for PII potential. Paidy had a situation with the data science team created a database joiner that led to a combination of personally identifiable data, but Orca helped them catch it in time to nip it in the bud.

Rapyd Uses Orca Security’s Deep Cloud Visibility to Protect Global Payments Systems

The Rapyd platform portfolio includes many different payment-related services, including collection, wallet services, and card program management. Orca helps with deep workload assessment and inventory. Orca’s Sidescanning™ technology scans each workload and assesses the delta in software versions once patching has occurred, acting as the proof that each system has been addressed. One of Rapyd’s largest challenges was that other approaches didn’t report actionable findings. Rapyd stated, “We’ll get a list of 1,000 patches, all deemed critical, but some can’t be deployed because they don’t match our distribution, or they’re for offline servers where patching doesn’t matter. If I show such a report to an auditor, they would think we’re not taking care of business.” Orca, however, risks findings appropriately using context. If a resource cannot be reached from outside of your network, a vulnerability may be de-risked, for example. Orca will also aggregate findings and let you know that if you upgrade a single software package, you will take care of many different vulnerabilities all at once.

Orca Security Gives MRS BPO “X-ray and Thermal Vision” for the Cloud

Orca has empowered MRS BPO to innovate by utilizing forward technology like containers-as-a-service and serverless functions, and still stay secure. Despite his enthusiasm for the cloud, Mike had concerns about any gap in visibility. He was satisfied with front-end protection from Cloudflare and his custom engineering to protect the middleware but really struggled to look deep inside his cloud infrastructure. MRS found value in AWS’ native tools but ultimately found that they lacked the depth and breadth that they were looking for. Mike’s perspective is that many tools don’t work well in serverless environments in that they provide limited visibility.

In fact, Orca Security has case studies in the double digits on our website at We’re really proud of this fact and put a lot of effort into understanding our customers’ journeys and their largest gaps in compliance and security visibility. Orca Security has just released our next-generation user interface and several new features at the request of our customers and partners. It’s still very simple to get started with a one-and-done one-time deployment, which is in stark contrast to the per asset integration strategy leveraged by security agents and scanners. Once deployed, Orca begins to side-scan your entire cloud estate and populates the dashboard with findings. These include malware, vulnerabilities, neglected assets, authentication risk, outdated resources, insecure configuration, data at risk, and lateral movement risk.

As we heard from more than one customer during this presentation, Orca also has deep inventory capabilities. Whether you’re interested in networks, policies, virtual machines, containers, or storage buckets, they are all inventoried and serve as a means to dive deep into the risks of specific resources. Clicking on a single alert will show us more context on the right-hand pane but will also show the path that a bad actor must take to land on this particular resource. Clicking Investigate gives us a deep dive into the alert in question. In this case, a web service unpatched alert. Here, Orca has rolled up over 60 individual CVEs such that if we upgrade our poorly aging Nginx web server, we will take care of them all. Compliant standards both at the workload and cloud levels are well-supported within Orca. You will find overall compliance results here against any standard of your choosing, but also under the Compliance tab in the Per Resource section of the product. I can talk Orca all day, but hopefully, you’re able to envision most of the concepts we spoke of today here in the product. We’d love the opportunity to show you more.

And that’s it. We’re at the end of our time together, but I want to thank you for spending about the last half hour-ish with me. Hopefully, you found value in our compliance versus innovation discussion. We’d love to hear more about your challenges, show you about Orca, and explain how we can help you better understand the risks hiding in your cloud estate. Please do get in touch.