Serverless workloads in the cloud can be as secure as traditional applications with the right processes and tools. The key: start small, scale as your application scales, and involve everyone.
For many organizations, serverless is already a part of their day-to-day operations. Often it has permeated from the ground up, with developers embracing a software development, deployment, and operations paradigm that empowers them to do more with less. For security professionals who are still reeling from the move into the cloud, this change sometimes conjures up the instinct to just declare defeat and move on.
You may be in one of those organizations. In fact, if your organization has a significant software operation on a public cloud, there’s a pretty good chance that some teams have already started experimenting, if not deploying, serverless workloads. While there are a set of new security tools and technologies that have emerged to help security in this new world, there are also many steps security professionals and advocates can do on their own to help contain the situation.
I always like to clarify that, in and of itself, the move to serverless doesn’t make things worse, in terms of security. In fact, in some areas, such as patching operating systems and protecting runtimes, cloud providers are taking the load off of you and will usually do a great job. The challenge is that once you cede control and responsibility of the platform to the cloud provider, you will often need to find new ways to deploy the application security you need to protect your valuable business services.
I like to view the shifting needs of serverless security in three buckets:
- Same old attacks, but where do you put the firewall? In other words, how do you protect serverless applications from attackers when you don’t or can’t put your classic security tools in the way.
- New attacks for serverless applications. These are mostly attacks that leverage new event triggers that were externally accessible in the past, or attacks that take on new forms in serverless.
- New opportunities for security in serverless. This is where the shift to serverless actually has the potential to make security better. For example, the shift from rather large multipurpose services in traditional applications, to small single-purpose functions, creates an opportunity to leverage identity and access management to tightly constrain each function and prevent malicious activity.
Long term, you probably need to be thinking more fundamentally about how you’re going to handle serverless security as serverless becomes an ever more significant part of your ecosystem. But there are things you can do right now to get a better grip on the situation — especially when your serverless infrastructure is still small. I’m going to give you three tasks. Pick one each day and try to make as much progress as you can.
Task 1: Know the Unknowns
The single biggest challenge with securing any cloud native application is knowing what resources are deployed in the cloud and how they are connected to each other and to the outside world. If you don’t have a tool that will do this for you, don’t worry. Open a spreadsheet and make a list of all the serverless resources you have, including functions, storage buckets, database tables, and APIs and service meshes. Try and list how the resources can be accessed (this can be tricky, but do your best).
The goals of this exercise are to:
Find and prune all the old stuff you’re not using anymore. Serverless encourages clutter and hoarding, since you pay almost nothing for resources that are lying around unused. But these resources could be your biggest security liability, so look for things that haven’t been accessed for a while or seem redundant.
Have conversations with the owners of these resources. Review the necessity and the risk of the resource. Ask whether this function could live in a virtual public cloud or if that bucket should be marked private?
Task 2: Become a Small Target
One of the biggest advantages of serverless architecture and deployment is that you can do a lot to minimize your attack surface. This can be labor intensive if you do it manually, but the upside is huge. Focus on:
Roles and permissions: Sit with your developers and review each function. Start with the ones that are most risky — ones that can be called from an external trigger or can access sensitive data). Make a list of what the function needs to do and compare that to what it is allowed to do. Nine times out of 10, you’ll find gaps, sometimes scary ones. But you can close the gaps, by reconfiguring function IAM roles. I strongly recommend using a unique role for each function; otherwise, you’ll almost always be overprovisioning something. Use a naming convention so you don’t get lost in them.
Timeouts: This is something of a hang-up of mine, and some may disagree. But here’s the gist of it: developers will often leave timeouts set to the maximum (usually 5 or 10 minutes). Since you only pay for what you use, they figure why not? But these unnecessarily long timeouts increase the potential for attackers to do more damage. Keeping timeouts close to the most your function actually uses, severely limits the amount of damage an attacker can do when exploiting your weaknesses, and it makes attacks more complicated to execute and easier to spot and defend.
Use your cloud providers dashboards to look at the longest your function runs, usually on cold-start, and pick a suitable margin of error so you can sleep at night. That’s your new timeout. Work with developers on this, as these timeouts might be controlled in their deployment scripts. For extra credit, set alarms in your cloud providers monitoring platform to alert you if the function comes close to the new timeout so you can reassess your decisions before you break something.
Third-party libraries: Your functions likely include much more third-party code than your own developers’ handy work. That’s how development rolls these days, and it makes for big gains in application velocity. Catching these vulnerabilities early can mean the difference between safety and mayhem by:
- Making a list of libraries or modules that your function uses
- Checking those against known CVEs to see if you’re at risk
- Replacing or upgrading anything vulnerable
- Repeat periodically.
Unfortunately, this can be labor intensive, so if you have more than a few functions, you may need to automate the process.
Task 3: Communicate
The move to serverless creates an additional challenge for many organizations because even these basic suggestions involve both security engineers and developers. This is not by chance. Increasingly, developers have ownership of configuration and security controls, and any attempt to improve security without close partnership between developers, DevOps, and security is doomed to fail. The solution is to create cross-functional teams to review security. Make it everyone’s problem. Enable communications with shared Slack groups or joint Jira accounts. If you’re choosing security platforms to help you, don’t just evaluate what they detect or what they can defend but also how they enable this dialogue natively.
Related Content:
Why Cybercriminals Attack: A DARK READING VIRTUAL EVENT Wednesday, June 27. Industry experts will offer a range of information and insight on who the bad guys are – and why they might be targeting your enterprise. Go here for more information on this free event.
Hillel Solow is the chief technology officer and co-founder of Protego. Prior to this he was chief technology officer in Cisco’s IoT security group, where he worked on innovative security solutions for new technology markets. View Full Bio
Article source: https://www.darkreading.com/cloud/securing-serverless-apps-3-critical-tasks-in-3-days--/a/d-id/1332118?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple
