The Shifting Risk Profile in Serverless Architecture
Technology is as diverse and advanced as ever, but as tech evolves, so must the way we secure it from potential threats. Serverless architecture, i.e. AWS Lambda, is no exception. As the rapid adoption of this technology has naturally grown, the way we approach securing it has to shift. To dive into that shift, let’s explore the past and present of serverless architecture’s risk profile and the resulting implications for security.
Past
For the first generation of cloud applications, we implemented “traditional” approaches to security. Often, this meant taking the familiar “Model-View-Controller” view to initially segment the application, and sometimes we even had the foresight to apply business logic separation to further secure the application.
But our cloud security model was not truly “cloud-native.” That’s because our application security mechanisms assumed that traffic functioned in a specific way, with specific resources. Plus, our ability to inspect and secure that model relied on an intimate knowledge of how the application worked, and the full control of security resources between its layers. In short, we assumed full control of how the application layers were segmented, thus replicating our data center security in the cloud, giving up some of the economics and scale of the cloud in the process.
Figure 2. Simplified cloud application architecture separated by individual functions.
Present
Now, when it comes to the latest generation of cloud applications, most leverage Platform-as-a-Service (PaaS) functions as an invaluable aid in the quest to reduce time-to-market. Essentially, this means getting back to the original value proposition for making the move to cloud in the first place.
And many leaders in the space are already making major headway when it comes to this reduction. Take Microsoft as an example, which cited a 67% reduction in time-to-market for their customer Quest Software by using Microsoft Azure services. Then there’s Oracle, which identified 50% reduction in time-to-market for their customer HEP Group using Oracle Cloud Platform services.
However, for applications built with Platform-as-a-Service, we have to think about risk differently. We must ask ourselves — how do we secure the application when many of the layers between the “blocks” of serverless functions are under cloud service provider (CSP) control and not your own?
Fortunately, there are a few things we can do. We can start by having the architecture of the application become a cornerstone of information security. From there, we must ask ourselves, do the elements relate to each other in a well understood, well-modeled way? Have we considered how they can be induced to go wrong? Given that our instrumentation is our source of truth, we need to ensure that we’re always in the know when something does go wrong – which can be achieved through a combination of CSP and 3rd party tools.
Additionally, we need to look at how code is checked and deployed at scale and look for opportunities to complete side by side testing. Plus, we must always remember that DevOps, without answering basic security questions, can often unwittingly give away data in any release.
It can be hard to shoot a moving target. But if security strategy can keep pace with the shifting risk profile of serverless architecture, we can reap the benefits of cloud applications without worry. Then, serverless architecture will remain both seamless and secure.
The post The Shifting Risk Profile in Serverless Architecture appeared first on McAfee Blogs.
Read more: The Shifting Risk Profile in Serverless Architecture