Serverless and cloud providers can provide a secure solution and more time for developers to think about and design secure solutions.
Secure Cloud Architecture
There’s been much talk about secure cloud architecture and many conversations about serverless and security. It’s one of the obstacles that people think of about Serverless. Sometimes a CISO wants to avoid touching Serverless because they believe it’s not secure. We’ve talked in previous articles 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 is not worrying about the operational side of maintaining those managed servers. The cloud provider is patching and doing those things to a level organizations would need help to keep up with. From the infrastructure and operational side, there are many good security benefits.
The serverless approach is highly opinionated.
The other element tying back into rapid delivery and serverless is that serverless terms of the approach are 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 is still a responsibility for application security that lands with the teams. And we’ll probably talk about this later. But there are several things we do and have always done, regardless of whether or not we’re Serverless. Serverless gives us more security. But it doesn’t mean that we don’t take it seriously or that we don’t treat it as fundamental.
Shared Responsibility Model
The shared responsibility model is critical here. A lot more shared responsibilities for cloud security 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 intricate and secure cloud architecture and give guidance. I know that organizations announce vulnerabilities regularly. When you check your app, you find that if you’re on serverless or lambda, AWS has already taken care of that and has addressed the vulnerability.There’s a significant benefit in letting the cloud provider manage and operate that because they’re going to be better than any internal team you will assemble. Serverless is more secure as a default, but you can make secure cloud architecture insecure based on your responsibility. And that’s where the guidance for well-architected helps to address any gaps. So that ensures that your team takes their responsibility seriously.
Risk Exposure
There’s also the risk exposure. If you have a serverless application, you’re responsible for application security rather than secure cloud architecture. And if you mess up application security, somebody might steal details or data or hijack a session. But you know it’s at an application or session level, and the cloud provider handles infrastructure security.
Reduce your risk exposure with Serverless.
But your whole company is down if somebody compromises your infrastructure security, such as ransomware. Losing customer data is terrible. But losing your entire company’s data center is catastrophic. So the exposure is less with Serverless.There’s also a part for me on the attitude to Security. It’s traditional versus modern thinking. Conventional thinking is perimeter detection: build a wall with loads of alarms, 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. With Serverless, there’s additional security once you get through the wall because the crown jewels have colossal security. The park or backyard is fine; you can walk around all day as there’s nothing you can damage.So you do need some perimeter protection to keep out the opportunistic hackers. But your absolute 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
We’re evolving from the Castle and Moat mentality to Zero Trust. You assess the trust as you go through it, and every component has its security boundaries. There’s strength and depth. Serverless helps enable a Zero Trust security stance. A lot of those challenges exist if you’re with a cloud provider or in your data center. Since moving into serverless workloads, you have more capacity for thinking about authentication, authorization designs, processes, touchpoints, and boundaries.
The capacity to understand Security
You have more time to design those things, and many services are flexible. Whereas, if you’re in the data centers, you’re working across a polyglot and have to support many different COTS capabilities. That can become challenging. The other way has a certain degree of flexibility and is a bit more accessible.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. It was on the perimeter somewhere: we’re okay because they 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 cloud provider has lowered the burden, they still need to be aware of it, own, test, and secure it.
Don’t shift left. Start left
It’s no longer a 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 must identify your assets on Day One and establish access control. It’s part of what you need to do. People are beginning to understand this better now. You could be authenticated to get in somewhere but still need authorization to do some stuff. Traditional security is authenticated to let you go nuts on everything. Understanding authorization as a design consideration on Day One is critical. It’s hard to retrofit that.
OWASP Serverless Top 10
We have seen maturity around what security means for serverless workloads. The emergence of the OWASP serverless top 10 has been a significant fallback in our careers. You can check OWASP and ensure you are covered if you hear something. 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 that there are different attack vectors here. You need to be aware of The code you use, the dependencies, and NPM that you bring in. But it’s good to google the OWASP serverless top 10 for good advice.
Working with Security
So what about security itself? Do we still need a security department if developers can shift left? Or do we still need a security presence: evil security people versus good developers? The relationship between security and developers is significant. And for the record, security is not hateful. You need security to be an enabler. You want to be something other than the ‘Department of No.’ 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 many different concerns: speed versus security, tech debt versus going fast, etc. Some of the best people in the industry are in security. You should have a good working relationship and take them on the journey as you explore new stuff.
Shared responsibility between the developer and cloud provider
Mike O’Reilly It’s a symbiotic thing. Returning 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 organization. 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 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 modeling, you should never invent your mitigations. You should be using well-known ones, so you need that expertise within the organization. If you need more clarification, 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 have yet to develop something that isn’t an excellent mitigation to a particular threat. It’s a symbiotic thing, and it can be complimentary when everyone’s working at a reasonable level.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.