How to Prepare Your Apps for Regulated Markets – InApps Technology 2022

Many successful startups and SaaS companies were constructed cloud-first with a build-it culture, prioritizing problem solving and speed above all else. As they grow, these startups inevitably seek to sell into regulated markets like finance, healthcare or government. A rude awakening often occurs, courtesy of auditors who inform them that their service will violate multiple compliance requirements. At this point, organizations worry that fulfilling compliance needs will destroy their build-it culture, and worse, that adapting to compliance requirements will mean their product won’t work in a cloud native landscape.

Fortunately, you can have your cloud native cake and top it with some regulatory industry frosting, too, without a crisis. Plus, your applications and infrastructure will emerge more secure and resilient.

Here’s a high-level recipe for checking important boxes for customers in regulated markets without sacrificing your flexible and open source-centric development workflows.

Step 1: Manage Your Internal Expectations

Serving regulated environments requires changes in key aspects of your operations. For example: In compliant environments, you will likely be mandated to respond to security risks or indicators of compromise (IOCs) within a specific time, often referred to as a CVE (common vulnerabilities and exposures) mitigation SLA (service-level agreement) in FedRAMP data centers. You will also need to prepare detailed security plans, explaining how you will monitor and observe your services. Regulators take this very seriously, and your team must be ready to do so as well. This could mean a change of mindset that requires a dedicated “owner” for regulated industry projects/operations (RegOps, anyone?).

Step 2: Move Everything Possible into a Compliant Cloud Environment

This might sound like a no-brainer, but moving to an environment maintained by a large cloud provider will immediately remove many headaches. Maintaining operating systems to be fully compliant is an onerous task, but you can shift much of the compliance burden (hardware-level FIPS, SOC 2, HIPAA, GDPR) onto the cloud provider by using the provider’s default operating systems and container images. If you’re already cloud native, then this move should be easy because your apps were designed for the cloud. But if you’re a cloud native service functioning inside a legacy business — reliant on other parts of your organization’s compute stack, proprietary or otherwise — then you’ll need to devise a plan to either bring those elements into compliance or “lift and shift” that functionality to run in a regulated cloud.

Step 3: Create an SBOM for Your App

Simply put, the software bill of materials (SBOM) is a detailed inventory of all the software components, commercial and open source, that make up an application. The SBOM is considered best practice — indeed it was even before the 2021 U.S. Executive Order on Improving the Nation’s Cybersecurity, which identified SBOMs as a critical component for enhancing software supply chain security.

You’ll get two benefits from an SBOM:

• Benefit #1: Identify Potential Compliance Risks
  This exercise helps you identify components of your application that could be problematic for regulated use cases, which will be covered in Step 4. Further, it also makes it easy to see dependencies. Managing dependencies is critical, because each dependency must be individually compliant for your entire service to be considered compliant.
• Benefit #2: Improve Your Reputation
  The SBOM is useful in the sales process because it demonstrates to potential customers that you’re serious about security. In fact, many customers in regulated industries will request an SBOM to evaluate potential risks introduced by your product.

To learn more about SBOMs, read “Create a Software Bill of Materials for Your Operating System.” Then check out the National Telecommunications and Information Administration’s one-stop-shop for SBOM templates and resources.

Step 4: Determine Whether Your SBOM Is Compliant

Now that you have a full picture of your software stack, thanks to the SBOM, it’s time to flag items that aren’t compliant.

When initially designing an application in build-it mode, companies rarely think ahead to when they might face compliance checks. Of course, applications serving regulated industries from the start, like healthcare apps, can and should be designed with compliance in mind. Companies often use default tooling supplied by a cloud provider — such as a load balancer, message queue or front-end components — because default tooling makes it easy to get up and running quickly. But many of these options are not designed to fully comply with all regulated industry needs and may be built using open source software that lacks the specific features needed to achieve compliance.

For example, most default load balancers cannot be sufficiently customized to achieve FIPS 140-2-compliant SSL/TLS ciphers. Additionally, observability tools for application metrics might not have the proper security processes in place. There could also be embedded open source tools, such as API gateways or web application firewalls (WAFs), inside the tech stack. Lastly, many major open source projects, such as Envoy, are not commercial entities, so they might not issue SLAs on vulnerability disclosure or guaranteed patch times, leaving you more vulnerable to CVEs. That, in turn, can unintentionally put your services out of compliance with the required standards. For those reasons, you need to verify whether each individual component in your SBOM can be made compliant.

Step 5: Decide What to Refactor (and How) to Achieve Compliance

Once you know which components of your technology stack have compliance challenges, you’ll know where you need to identify replacement parts. This can require some major refactoring of your application stack, which isn’t necessarily a bad thing. When you’re building for scale and compliance, you’ll need the ability to customize and configure technologies to the full extent necessary, given your regulated market compliance requirements.

Multicloud Considerations

A multicloud strategy is often adopted to increase flexibility and performance. For example, some large organizations choose to build three versions of their application architecture — each customized to run in a different cloud — with the fewest changes possible to mitigate unexpected problems in production.

But multicloud introduces additional complexity because applications and technologies tend to have different capabilities across the different clouds. For example, each public cloud offers its own load balancer and WAF, each with different capabilities for exposing and protecting the service’s underlying components. Choosing to use default tooling in a multicloud strategy leads to tool sprawl and all the associated problems: inconsistent policies, wasted money and challenges with security. A better choice for multicloud deployments are cloud-agnostic tools that can be used across all of your environments.

A great example of a multicloud strategy enabled by cloud-agnostic tools is described in this article by Snowflake.

While pursuing a multicloud strategy like Snowflake’s is easier today than it was in the past, thanks to containers and cloud native development, it’s still a big lift. Often this strategy is achieved with a mix of mature, enterprise open source distributions that integrate with other mature cloud service offerings, such as Grafana Enterprise for visualization, HashiCorp Vault for secrets management and NGINX Plus as a flexible load balancer/API gateway. Most organizations use the tools as non-managed software packages or binaries in regulated markets cloud implementation. In some cases, they’ll ship a refactored version of their cloud architecture to an on-premises colocation or data center, either where workloads will run more persistently or where it’s absolutely necessary for data governance reasons.

Outsourcing Options

There is also a growing pool of third-party companies that deliver functionality as an already compliant service — effectively an outsourcing option. In most cases, these services are used for the internal functions of a regulated environment. Hosted services outside of cloud native or first-party cloud services are rarely used for live traffic in a FedRAMP data center. However, this will likely be a high-growth area over time. Determining which parts of your tech stack you can change and then own, and which parts are simply easier to replace, will help guide your decision-making.

Conclusion: Regulation Is a State of Mind and a Process

The above steps describe a culture evolution in your application architecture and the entry points to a new stage of maturity. Regulated markets are regulated for very good reasons: The services that companies in those markets provide are critical to society. In that sense, companies seeking to enter that market must deal with a third stakeholder: the public sector. Fortunately, there are enough options in the cloud native world to ensure that clearing hurdles for regulated markets is less likely to cause outsized disruption or expense. Yes, it might entail some shifts in choices of applications and technologies, but given that more apps are composed of connected services linked via APIs, the modern application is far more amenable to refactoring to meet regulatory needs.

The best approach is to think about entering a regulated market well in advance. Plan for it by adopting a regulated state of mind early in the game. Once you’re in this mindset, you will find that making the necessary changes is a smaller lift that drives real improvements in your application performance and security.

Feature image by Sarah Anderson, NGINX.