We talk about secure cloud architecture and how serverless and cloud providers can provide a secure solution and more time for developers to think about and design secure solutions.
Security and Serverless Episode from Serverless Craic
Secure Cloud Architecture
Dave Anderson
There’s been quite a lot of talk about secure cloud architecture in the past few weeks. We always see lots of conversations about serverless and security. It’s one of the obstacles that people think of. Sometimes there’s a CISO who doesn’t want to touch Serverless because they believe it’s not secure. What do you folks think? Is serverless more secure or less secure?
Photo by Luis Villasmil on Unsplash.com
Mike O’Reilly
It’s a good question. I’m of the opinion that it’s more 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.
Serverless approach is highly opinionated
I think the other element tying back into rapid delivery and serverless is that serverless terms of the approach is highly opinionated. There are only so many ways that you can go about assembling your workloads and services. That’s not to say you can’t configure things in security. There still is responsibility there for application security that lands with the teams. And I know, we’ll probably talk about this later. But there’s probably a number of things that we do and that we’ve always done, regardless of whether or not we’re in Serverless. I think serverless definitely gives us more security. But it doesn’t mean that we don’t take it seriously, or that we don’t treat it as a fundamental.
Shared Responsibility Model
Mark McCann
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 cloud architecture and give guidance. I know a lot of the vulnerabilities are announced regularly. When you go and check your app, you find that if you’re on serverless or lambda AWS have already taken care of that and that vulnerability has been addressed.
There’s a large benefit in letting the cloud provider manage and operate that because they’re going to be better than any internal team that you’re going to assemble. Serverless is more secure as a default, but based on your responsibility you can make secure cloud architecture insecure. And that’s where the guidance for well architected helps to address any gaps. So that makes sure that responsibilities that are yours/your team’s are taken seriously.
Risk Exposure
Dave Anderson
There’s also the risk exposure. If you have a purely serverless application, then you’re responsible for application security rather than secure cloud architecture. 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.
Reduce your risk exposure with Serverless
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.
There’s also a part for me on the attitude to Security. It’s traditional versus modern thinking. Traditional thinking is perimeter detection: we’ll build a wall with loads alarms on it and we’re done.
But with a modern strategy, it’s about securing each asset appropriately to what it contains. Your castle has a big wall around it, but once you get through the gates you can get access to everything. Once you get through the wall, there’s additional security, because the crown jewels have crazy security. The park or back yard is fine, you can walk around all day long as there’s nothing there that you can damage.
So you do need some perimeter protection to keep out the opportunistic hackers. But your real security is by each asset, where it’s locked in. I fear that many companies still have perimeter access.
Evolve your security attitude from Castle and Moat to Zero Trust
Mark McCann
We’re evolving from the Castle and Moat mentality to Zero Trust. You assess the trust as you go through and every individual component has its own security boundaries. There’s strength and depth. I think serverless helps enable a Zero Trust security stance.
Mike O’Reilly
A lot of those challenges exist if you’re in with a cloud provider or in your own data centre. I’ve found since moving into serverless workloads that you have more capacity for thinking about authentication, authorisation designs, processes, touch points and boundaries.
The capacity to understand Security
I’ve certainly had a lot more time to design those things and a lot of those services are flexible. Whereas, if you’re in the data centres, you’re working across a polyglot and have to support many different COTS capability. That can become challenging. The other way has a certain degree of flexibility or (what’s the word?) it’s a bit more accessible.
Mark McCann
With serverless and the responsibilities shifting left, teams have more visibility, ownership, and control over security. In the past with the traditional architectures and systems we worked on, security was almost taken care of for you by another team and you weren’t really exposed to it. It was on the perimeter somewhere: we’re fine because the permanently will catch up and we don’t need to worry about security!
Whereas now, it’s a requirement for the team to understand and have a handle on. Even though the burden is lowered, they still need to be aware of it, own, test and secure it.
Don’t shift left, start left
Dave Anderson
It’s no longer shift left when it comes to secure cloud architecture. I met Ian Heritage at AWS re:Invent 2021. His talk was about don’t shift left, start left. You need to identify your assets on Day One, and establish access control from the off. It’s part of what you need to do.
Mike, you mentioned, authentication and authorization. I think people beginning to understand this better now. You could be authenticated to get in somewhere, but still not authorised to do a bunch of stuff. Traditional security authenticated and let you in to go nuts on everything. Understanding authorization as a design consideration on Day One is absolutely critical. It’s hard to retrofit that.
OWASP Serverless Top 10
Mark McCann
There’s been a maturity around what security means for serverless workloads as well. The emergence of the OWASP serverless top 10 has been a big fall back in our careers. If you hear something, you can check OWASP and make sure we’re covered for it. So it’s good to see a tailored version for serverless workloads. And a lot of it is standard stuff that we would be addressing. But it’s good to see it called out that there’s different attack vectors here. The code that you use, the dependencies and NPM that you bring in are things you need to be aware of. But it’s good to google the OWASP serverless top 10 to get good advice.
Working with Security
Dave Anderson
So what about security itself? Do we still need a security department if developers can start left? Or do we still need a security presence: evil security people versus good developers? I think the relationship between security and developers is very important. And just for the record, I don’t think security are evil. I’m afraid that somebody will press a mute button on me.
Mark McCann
We’ve talked about this. You want security to be an enabler. You don’t want to be the ‘Department of No’. Historically that may have been the perception.
But typically, we’ve interacted with brilliant (security) people. They have buckets of integrity and they’re trying to do the right thing and balance a lot of different concerns: speed versus security, tech debt versus going fast etc. Some of the best people in the industry are in security. You should want to have a good working relationship and take them on the journey with you as you as you explore new stuff.
Shared responsibility between developer and cloud provider
Mike O’Reilly
It’s a symbiotic thing. Going back to the shared responsibility between the developer and the cloud provider, it’s the same thing between the developer and cybersecurity or the security department in your organisation. You’ve got to have a good working relationship. We’ve talked about this in previous discussions. The responsibility that a service team has for security, reliability, resiliency, performance costs, the operational side and security means that the application team has a duty to take security seriously. If they’re doing that then the relationship with cybersecurity is good. The interaction can be productive because it can be a consult or coaching session.
In threat modelling, you should never invent your own mitigations. You should be using well known ones, so you need that expertise within the organisation. If you’re not sure, it’s always good to have support from a cybersecurity expert to consult with and give you confidence that you have taken a good approach to security within your workload. And you haven’t come up with something that isn’t a good mitigation to a particular threat. It’s a symbiotic thing and it can be quite complimentary when everyone’s working at a good level.
Dave Anderson
You need to talk to security people and understand what you’re trying to do.
So that’s the craic. There’s more about this on TheServerlessEdge.com. On Twitter, we’re @ServerlessEdge. So thanks very much!
Transcribed by https://otter.ai
Top comments (0)