By now, most practitioners are familiar with the cloud. Because of that familiarity, it can sometimes be hard to...
remember what the original promise of cloud was.
Cloud's original promise was that organizations could shift attention from things that didn't add value to the business to things that do. Specifically, cloud was meant to shift attention from the nuts and bolts of building infrastructure, maintaining data centers and providing the plumbing required to provide applications on which their businesses rely, and instead move that attention to offering better, more seamless and more relevant applications to the business.
Of course, just because something is in the cloud doesn't necessarily mean that the angels sing and all the requirements for maintenance go away. An infrastructure-as-a-service implementation, for example, still requires that you follow through on patching, that you lay out virtual network paths, that you provide an underlying security apparatus and that you complete numerous other tasks that are equal in complexity to what you might have been doing if you were hosting that in a data center on premises.
The new trend of serverless applications promises to help fulfill the original dream of cloud. Specifically, with serverless applications, the work of maintaining that underlying plumbing is offloaded, and in its place, there is room to focus on building better applications. As such, it is every bit as compelling -- and as powerful -- as you would imagine.
That said, the specifics associated with ensuring serverless applications are secure is a bit different than what organizations might have used in the past. It also happens to align with areas where organizations haven't been particularly strong in the past. This means, if you're going to use a serverless application, you probably want to think through your security approach ahead of time and lay some groundwork.
What does serverless mean?
Serverless doesn't mean there are no servers; there are. It's just that the user or, in this case, the developer building business applications doesn't need to know about the servers, care about what they're doing, understand how they operate or be alert to what might be going on below the application layer. Instead, the developer can interact through defined APIs to implement the logic they need. Things like scaling, the logic of interfacing with specific hardware or underlying middleware services, are handled seamlessly and transparently by the environment.
In environments like Google Cloud Functions or Amazon Web Services Lambda, functionality is triggered via events, and application functionality is built to respond to those events and accomplish small, bite-size pieces of functionality. The environment deals with provisioning the functionality as needed and scaling them up in response to demand. The advantage to this is that, even beyond most cloud usage situations, you only pay for what you use.
How's that different from a regular, nonserverless platform as a service (PaaS) implementation? The simple answer is that it's pretty close from a philosophical point of view. However, even in a PaaS context, there are still artifacts of the underlying implementation that you need to worry about more than in a serverless context.
For example, you might have to specifically provision resources in many PaaS situations, so scaling is not truly invisible. Likewise, configuration of specific services in a PaaS, such as a database or mail, might require explicit knowledge of the underlying implementation. So, in a sense, serverless is sort of like PaaS++.
Security considerations for serverless applications
As you might imagine, securing a serverless app is a bit different than securing a traditional monolithic application, or even other cloud deployments.
First, and most importantly, your ability to interact with anything below layer 7 is pretty much nonexistent. This means you can't go out and drop a virtual intrusion detection appliance onto the virtual network or install malware scanning tools on the underlying OS. As such, you need to understand -- thoroughly and concretely -- the threat model associated with the logic you're implementing.
Likewise, you need to ensure that the code you're developing is robust. This can be a sticking point because application security is a domain with which many organizations have struggled.
For example, injection attacks are still top of the list when it comes to application issues. While, to some degree, bugs will always happen, our ability to secure a serverless application correlates directly to our ability to understand the application logic, remove or mitigate potential issues, keep code quality high, and monitor the environment. It's not rocket science, but it does take discipline.
If you're not already doing so, one approach that can provide immediate value here is threat modeling. Threat modeling, already a useful tool for hardening applications, has even more value in a serverless context than in other situations. Not only does it enable you to systematically map and analyze interaction points between components, but it also produces a data flow map as part of the process. While you may not have full visibility into the underlying mechanics of data storage or computation, a virtual map of how the application elements interact is useful in other ways, beyond just the analysis of the threat model.
As you do this, you might consider what options are available to you to insulate application logic in such a way that it offers you additional visibility or control over operations. Tools like Vanadium, for example, are built to enable you to wrap functions in such a way that they are transparent to the developer. You can also choose to implement a wrapping strategy yourself. A strategy like this one can help find and filter injection attacks in a way that doesn't assume all developers are going to produce injection-free code.
Lastly, as with anything, monitoring is a must. In addition to the obvious -- e.g., access control decisions and the like -- you want to also understand the application logic itself. You want to keep an eye out for any anomalous events that are not in keeping with business rules. This will vary depending on what your particular application is designed to do. This is, again, one area where threat modeling can provide value because, ideally, by the time you create and document the threat model, you will have a pretty good idea of what the application is designed to do in the first place.
Serverless applications can be powerful tools, but ensuring the security of these tools isn't always something that security teams are equipped to jump on out of the gate. As such, it can be beneficial to get supplemental external or internal expertise to do this.
It can also be helpful to train internal staff on, for example, threat modeling methods, robust coding practices, and even common misuse cases and attack and threat patterns. This is a useful opportunity to develop staff, build your skills and increase the sophistication and maturity of applications throughout the organization in general.
Discover Microsoft Azure's services for serverless containers
Find out if serverless makes sense for your organization
Learn how to get the most from a serverless app in a public cloud