Compliance in modern applications that leverage containers, serverless or other next-generation technologies is increasingly vital.
Compliance has always been important, of course. But given the soon-to-be-implemented General Data Protection Regulation (GDPR), along with the recent congressional hearings on Facebook and its data privacy issues, the subject of data protection and regulatory standards now has more purchase than ever.
So, what do you do? This article explains some ways to meet compliance challenges for modern, microservices-oriented applications.
Key Principles for Compliance
While specific compliance requirements vary between different frameworks and applications, in general, you should strive to achieve the following in order to meet compliance requirements:
- Provide a configuration for storing and processing personal data.
- Monitor third-party solutions for security flaws.
- Access control: Whatever IAM solution you are using, make sure and monitor that for any changes to permissions to access data.
- Along with access, ensure that any admin and user access of data and activities are traceable.
- Be especially careful with possible data injection vulnerabilities in your serverless architecture.
- Keep up-to-date with security exposures and vulnerabilities.
4 Steps to Achieve Compliance with Microservices, Containers and Serverless
Meeting these compliance requirements with modern applications can be particularly challenging, given the highly complex and dynamic nature of microservices, containers and serverless platforms. But there are steps you can take to overcome this challenge. Let’s take a look at them.
Keep It Simple
Keeping a container’s purpose as singular as possible (of course this is the point of containers and a serverless architecture), and preventing unnecessary exposure to other containers and their data is a good practice that should help address the security demands of GDPR. This also ensures legible access management and the isolation of more sensitive operations to specific users, while keeping the pipeline clean and tamper-proof, which is vital especially in the global context.
When using serverless functions, also keep this simplification mindset. Don’t give the function more responsibility or access than it needs. Only give the function the necessary responsibilities and you can avoid this security issue.
Understand Serverless Security Risks
When you choose a serverless architecture, you increase the attack surface for your application. This is because serverless environments use a lot of different sources for consumption of data. The complexity of this architecture does not allow for standard application layer protection to be effective. Dynamic application and static application testing tools are not as effective in a FaaS environment, as the complexity of the serverless architecture and the sources of data for these functions are not only HTTP.
For this reason, a multi-layered approach to security is especially crucial in serverless environments. So is adopting security tools designed specifically for serverless, as legacy security solutions are unlikely to be able to handle the security risks of serverless environments.
As the response to security compromises and attacks has risen, return-oriented programming (ROP) has evolved into a way to exploit the call stack of serverless functions, which could lead to access control bypass and/or denial-of-service attacks. The attacker in this case uses the code in your application like any other developer on the team, except that the return logic is changed. This would allow the attacker to chain the functions together in a way that could natively attack the application code and thus bypass any authentication/authorization that your team has configured. As I mentioned, isolating responsibility and minimizing privileges could prevent this kind of attack.
Mitigate Data Injection Risks
Data Injection remains a serious attack risk, especially for modern application architectures. The increase in event sources which trigger serverless functions allows an attacker more opportunities to tamper with data and get deep access into your application. In particular, Server-Side Request Forgery (SSRF) and object deserialization are key injection flaws in serverless architecture. There are other risks such as insecure deployment configuration, inadequate logging, insecure third-party dependencies, insecure storage of app secrets, and improper execution handling.
There is no denying that compliance requirements are more difficult to address with modern applications. Yet by adopting a security strategy founded upon the principles of isolation, minimalism and multi-layered defenses, developers can effectively handle the security and compliance challenges of dynamic application environments.
Links for further reading
- GDPR Guidelines and Container Security
- Docker CVE Database
- Kubernetes Advisories
- Consider “Zero-Knowledge” Platforms
- Make sure that you have some sort of data processing agreement (DPA)
- Try to do a Data Protection Impact Assessment (DPIA)
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
5 Questions to Ask When Choosing a Cloud Native Security Platform for DevOpsRead the Blog
CVE-2018-1002105: Critical K8s VulnerabilityRead the Blog
Advanced runc Debugging for Fun and ProfitRead the Blog
Introducing Twistlock Support for AWS Lambda LayersRead the Blog
Cloud Native Security Intelligence: Integrating with AWS Security HubRead the Blog