4 minutes read

POSTED Apr, 2020 dot IN Serverless

How Compliance Standards See Serverless in Production?

Emrah Samdan

Written by Emrah Samdan

Former VP of Product @Thundra


Compliance in the Serverless Space

How Do Regulatory Agencies View Serverless Applications?

As companies grow, one of the most significant changes they must make is to comply with government regulations. As a company takes on third-party shareholders and its actions come to affect those without a direct say in their planning, data security and compliance become more important. 

Companies that don’t focus on compliance can be endangered by legal issues. The compliance process is often highly detailed, requiring extensive diagramming and documentation and the involvement of many of the most senior team members to field questions from regulators.

Because serverless applications remove the ability to point to a physical machine as proof of your security, they further complicate regulatory compliance. For this reason and because the serverless field is relatively new, these architectures will need greater attention and research to appease regulators. 

Below we’ll explore some of the most common and important regulations that serverless applications will have to comply with. We’ll look at the background of each one, then discuss how serverless applications built on top of AWS Lambda can drive your application’s compliance efforts.

Sarbanes-Oxley (SOX) Act of 2002—U.S.

We’ll start with the Sarbanes-Oxley Act of 2002, or SOX, which the U.S. Congress passed as a set of controls for all public company boards and members of management, as well as employees of public accounting firms. The act’s primary goal is to protect sensitive business-critical information, whether it is personally identifiable information, like a tax ID, or critical financial information, like contractor invoice data.

This information, if leaked to the wrong hands, could adversely affect critical reporting-related data. It’s important for companies serving the public to protect this critical data with a series of procedures and controls designed to establish a chain of ownership. This is the goal of SOX compliance.

Considerations for AWS Lambda

SOX compliance is really easy to demonstrate with AWS, since it doesn’t strictly depend upon the infrastructure running your application. Instead of hardware requirements and regulations driven by physical machine connections, SOX focuses on direct control of the paths that allow for manipulation of data, whether that is the code deployed by your developers or the user interfaces written for your customer support teams. 

In truth, good software engineering practices and DevOps policies will get you a significant portion of the way to SOX compliance. However, you’ll need to develop a strategy for dealing with personally identifiable information to achieve full compliance. 

In terms of Lambda functions and SOX compliance, this means that a significant portion of your responsibility will be in AWS configuration and development pipeline restrictions. With proper restriction to resources in AWS—something tools like Thundra excel at—you can meet most SOX compliance requirements with minimal effort. To learn more, review the AWS information on data security.

General Data Protection Regulation (GDPR) of 2016—EU

The General Data Protection Regulation, or GDPR, is a European Union response to growing concerns about the privacy of consumers browsing the web. The GDPR includes data destruction and “right to be forgotten” regulations, which enable users in Europe to request that their sensitive information be removed from your system. Furthermore, you’re required to inform all EU members of the types of information your application tracks, including use of cookies.

This regulation aims to improve the lives of European citizens, and as a result, it applies to every company that wants to do business with the European Union. Violating this regulation can get very expensive.

Considerations for AWS Lambda

Once again, key elements of the regulation include proper security implementation, data access restrictions, change control management, data retention, and destruction policies—all the items expected of a publicly traded company and thus, generally implemented as part of an effort for an organization to become SOX-compliant. This provides a benefit to achieving GDPR compliance, as much of the basic infrastructure needed to support SOX requirements can do double duty in supporting GDPR requirements as well.

Nevertheless, the difficulty of compliance is compounded by strict time limits in the original text of the GDPR act—currently 30 days. Serverless tech offers a boon in this case, however, since the ability to quickly spin up data handlers and shut down functionality gives your infrastructure engineering team the tools they need to quickly and competently handle requests as they come in.

Compliance here requires a strategy for automated removal of tracked user activity that is flexible enough to grow as your application does. Additionally, resource-level restrictions on access are critical. While AWS offers some of this functionality, full GDPR compliance requires integrating third parties to remove all relevant user data, and these third parties may not be available in AWS. Using Thundra, you can leverage comprehensive whitelisting and blacklisting to provide security restrictions not only for sensitive AWS resources, but for all of the resources in your application.

Payment Card Industry Data Security Standard (PCI-DSS)

The payment card industry is a network of companies that drive the terms of processing of credit card payments. The PCI-DSS, or payment card industry data security standard, is a set of standards defined by this network that determines how deeply your organization can participate in the credit payment process. 

These security standards and restrictions must be applied by an external auditor. This is done to protect critical financial data from unauthorized access, and the levels at which your organization complies determine your maximum capability to implement as a credit card payment handler.

Considerations for AWS Lambda

When you process payments in a serverless context, there are a number of items you should keep in mind:

  • As with GDPR and SOX compliance, it is critical that you restrict access to all payment-related data.
  • Depending on your level of certification, you may not be allowed to send payment data to your server. Therefore, it is important to recognize that Lambda functions will need to work with tokenized payment methods.
  • You will need a clear boundary between test and production environments, as using production environments will result in charges being issued against a credit card, even in test mode.
  • Just because information is sensitive, that doesn’t mean it’s relevant to PCI standards. Credit card account number and expiration date may be problematic from the point of view of PCI-DSS, but as far as the standard is concerned, it’s perfectly fine to store bank account and routing numbers wherever you like.

For more information on restrictions for AWS Lambda in the payment space, review the AWS documentation on PCI compliance.

Learning More

While the compliance standards discussed above are some of the more significant ones you are likely to encounter, this list is far from exhaustive. We pay legislators to write laws, after all, and they’ll always find new ones to work on. Many industries are already regulated by specific legislation, such as privacy acts like HIPAA or the numerous jurisdictional regulations around casino gaming. Ultimately, it all boils down to the specific regulations with which your company must comply.