SOC 2, ISO, HIPAA, PCI DSS, and FedRAMP Certifications From the DevOps Perspective 

Software compliance has never been easy. Nuanced spreadsheets, endless checklists, and cross-functional teams conducting myriad long meetups to understand how processes, policies, and workflows are actually executed—all at the end of the development cycle—were an integral part of compliance procedures. It was a long and cumbersome process, and quite often, teams ended up making changes in “non-compliant” parts of code. 

However, businesses put up with all these inconveniences of the given approach. Why? It worked—until the end of the epoch of on-premise hosting and monolith architectures. Today, modern development teams face new compliance challenges stemming from the advent of new technologies, such as cloud computing and microservices. Let’s take a closer look at each of them.

Cloud computing

While there are many reliable, compliant cloud solutions nowadays, you need to understand where the cloud provider’s responsibilities end and yours begin in terms of security and compliance. For example, research reveals that misconfiguration is the second-most widely spread reason for data breaches in cloud environments.

Ironically, another challenge stems from the attempts of cloud providers to help businesses achieve compliance. For example, Amazon provides separate cloud environments for businesses that abide by FedRAMP and other regulatory standards. To access such environments, you need to pass a screening process. Which adds to your compliance challenges. 

Microservices and containers 

Together with cloud computing, microservice architecture and the subsequent advent of containers—as one of the most popular ways to implement microservices—have made the life of developers easier. Individual software elements can be easily deployed independently without affecting the rest of the system. This allows developers to move fast. 

Sounds optimistic, right? Well, it isn’t so if you have to deal with a complex system consisting of thousands of containerized microservices while staying compliant. This adds roadblocks to your compliance journey. For example:

• It’s hard to map traffic flows and runtime dependencies between microservices and identify a compliance gap.
• It’s challenging to bridge compliance gaps without causing cascading failures and—as a result—downtime.
• If development teams in your organization are free to choose any languages and frameworks for each microservice, managing security and compliance risks across microservices built using different tech stacks is a nightmare.
• Multiple microservices make the attack surface huge. You need to secure each endpoint according to the best cybersecurity practices and regulations you are subject to. 

Additionally, container orchestration tools, if not managed properly, can pose another cybersecurity and non-compliance risk. 

The three compliance challenges of modern tech businesses

With the introduction of new technologies and practices into the development process, regulatory requirements didn’t become less strict: the over 300 sub-requirements of the PCI standard aren’t going anywhere, for example. And if you are a business that directly deals with credit card data, you need to comply with them all, across a myriad of microservices and containers. 

Clearly, the traditional way of approaching compliance—pushing it to the very end of the development lifecycle—doesn’t work anymore. Also, we can’t forget about compliance after product release and successful certification until the reassessment. Modern products are changing rapidly (otherwise, a business won’t survive the competition), and so are regulatory requirements. 

Besides this, sometimes continuous monitoring is a legal requirement standard. FedRAMP, for example, requires covered organizations to monitor their systems continuously to ensure the required risk posture.

As a result, modern companies that are subject to regulatory standards have three main tasks to resolve: 

1. Rolling out a secure software product that complies with all the applicable standards, regardless of its hosting type and the level of architecture complexity. 
2. Monitoring the entire system’s compliance 24/7 post-release and preventing compliance gaps before they occur.
3. Detecting and bridging compliance gaps before they have any effect.

And that’s where DevSecOps and continuous compliance come into play.

DevSecOps is an offshoot of DevOps. But unlike the latter, this approach integrates security initiatives at every stage of the software production pipeline and after the product release. That is, instead of stepping in only after all the coding is finished, security professionals participate in the product implementation, coordinating their efforts with development and operation teams from the very beginning. 

Continuous compliance is one of the key practices of DevSecOps. Aiming to weave the information security element into the entire product lifecycle, continuous compliance starts with defining compliance standards, security policies, and practices. After that, the company aims to fully achieve compliance. And finally, it maintains compliance on an ongoing basis. 

Let’s see how we can use DevSecOps and continuous compliance practices to achieve compliance within the cloud and microservice architecture setup. 

Shift left 

Checking security and compliance after all the development is done doesn’t work anymore. Instead, embrace the “shift left” approach, which implies taking care of security and compliance as early as possible. Ideally, rather than adjusting a ready-made solution to regulatory requirements, you should build your product based on these requirements. 

Besides, inserting regular static tests into the development process will allow you to check your code for security and compliance before executing it. 

Document and share 

The DevOps approach of documenting everything along the way and sharing it with everyone involved in the process also applies to DevSecOps and continuous compliance. Using solutions like Git, you can consolidate and track the documentation of those who release changes (ops) and those who implement them (devs).

GitLab, for example, takes documentation and process transparency in their SOC 2 compliance efforts to the next level: they make all the information about the product and how it is built available to everyone. If there’s information that needs to be kept confidential, they provide justification as to why this information can’t be public. 

They applied the same self-serve approach when undergoing the SOC 2 audit: they enabled auditors to self-serve as much information about their practices and procedures as possible, which helped them make things easier and faster for everyone involved in the process.

Embrace automation all the way 

Automation lies at the heart of DevOps, and the same applies to DevSecOps and continuous compliance. Automate everything that needs to and can be automated. For this purpose, it’s advisable to continuously monitor the software market for new solutions and weave the most efficient ones into your process. Basically, you should automate the entire continuous compliance pipeline, including:

• Prevention. Prevent non-compliance by establishing rules. For example, to prevent defective Dockerfiles from entering your system, you can validate their compliance with your security policies using tools like OPA/conftest and a Dockerfile linter like Hadolint. Or you can secure your container orchestration solution, you can enforce some policies-as-code, such as “do not run untagged container images,” “run container images only from trusted sources,” and so on.

• Monitoring. Monitor your system with customized compliance checks 24/7. With a robust automated solution, you can keep track of system logs, configuration, user access and identity management, adherence to regulation and best security practices, and beyond. If you are running containers, you can periodically check container images stored in your registry or monitor what’s going on in a cluster of containers managed by your container orchestration solution.

• Detection. Use a solution that alerts you on every non-compliance incident, visualizes all the incidents, and sorts them by the relevant standard. 

• Remediation. Wherever possible, enable automatic remediation of issues. For example, you can use self-healing practices for ensuring data integrity—a requirement of many regulatory standards. Here is how it usually works: two copies of the same data set are stored on two different storages synchronously, and a content-related hash value is assigned to each data set. Using the hash values, the system then continuously checks the integrity of all records. Once a flawed data set is identified, it’s automatically replaced with the valid one. 

Armed with DevSecOps practices, companies can efficiently address the main compliance challenges. The key requirement here is to enforce these practices wisely—otherwise, you risk wasting your budget on things that don’t work. 

If you don’t have the needed expertise in-house, ALPACKED is here to help you. Well-versed in FedRAMP, PCI DSS, SOC 2, and some of the other most required security certifications, our engineers will help you weave the DevSecOps element into your compliance journey, enabling you to stay 100% compliant at all times.