Serverless Craic Ep7 Security

Serverless Craic from The Serverless Edge

1×

0:00

-25:34

Serverless Craic Ep7 Security

Treasa Anderson

Jan 21, 2022

The team talk about serverless and security.

Sometimes there's a CISO who doesn't want to touch Serverless because they believe it's not secure. Is serverless more secure or less secure?

We've talked in previous sessions about rapid delivery and the fact that we're assembling or aggregating various components or managed services together to form a product, feature or capability. A massive part of that is not having to worry about the operational side of maintaining those managed servers. The cloud provider is patching and doing those things to a level that organisations would struggle to keep up with. From the infrastructure and operational side, there's a ton of good security benefits.

The shared responsibility model is key here. A lot more of the shared responsibilities for security of the cloud fall onto your cloud provider ie. AWS, in this instance. With leveraging higher level building blocks and managed services, more of that responsibility is on AWS. They have some of the best security engineers in the business. They're very good at articulating and working behind the scenes to patch hard and secure and give guidance.

There's also the risk exposure. If you have a purely serverless application, then you're responsible for application security. And if you mess up application security then maybe somebody might steal detail or data or hijack a session. But you know that it's at an application or session level and infrastructure security is handled by the cloud provider. But if somebody compromises your infrastructure security such as ransomware, then your whole company is down. Losing customer data is bad. But losing your entire company's data centre is catastrophic. So the exposure is slightly less with Serverless. .

You need to sit down with security people and talk to them to understand what they're trying to do. I find huge value (when you're hit with a process that's difficult), in understanding what's the control behind the process, because the process is just trying to put a control in force.

Having a shared vocabulary and a common language is critical. We have had great success with threat modelling to help bridge that common language/vocabulary. Threat modelling, as a technique has been awesome, not only for good application design, but also for having conversations with security partners/teams on the threats we have identified and what we're doing to mitigate them.

When you come to the Security Team and say: 'This is what I think you want to do. And this is how I think we should do it.'. You're opening up the conversation. That is a key point. These collaborative, facilitated team based activities, surface so much value.

As an architect, I think it's a really good exercise for making sure you understand how teams are going about certain things as well. So you're constantly validating your thinking. When you are walking through the Microsoft threat model, you're building DFDs (data flow diagrams), and you're constantly reaffirming what it this talking to here, what are we doing, what what are we passing across?

One last point on the threat modelling piece is when you get into the mitigations, and how you verify your mitigations, it leads you down the path for creative testing. You are arming your engineers with ways to test the system through a different perspective and you look at different techniques.

Another great piece is ident