Tom McLaughlin
This past week I teamed up with James Wickett of Signal Sciences to discuss security when it comes to serverless cloud infrastructure. James and I first discussed this idea over barbecue while I was visiting Austin several weeks back. We thought it would be a great idea to have someone from ops (me) and someone from security (James) team up to have a question and answer period. The DevOps mantra is about removing silos. And as we move towards DevSecOps, we thought this information sharing format would be a perfect.
Looking back at the webinar and the questions and answers given, there were three main themes.
- Serverless lets you focus on existing problems that many of us haven’t had the time to properly spend time on.
- Serverless will affect the future job roles of operations and security professionals.
- Security and operations engineers have a lot we need to share with one another so we can be successful securing serverless.
Let’s discuss some of the questions we covered in the webinar which demonstrated these themes.
Q: If we’re no longer patching hosts and tracking SSH logins what should we be doing?
Well, there’s a lot we could be doing! Just think of all the tasks you can’t get to right now because you’re too busy with host patch management and chasing down failed (or even successful) logins. By offloading a degree of security work to a cloud provider through going serverless you’ve freed up time to focus on areas of your infrastructure and application stack that you maybe haven’t had enough time for previously.
Let’s start with securing your cloud perimeter. With serverless, the amount of surface area you’re responsible for has decreased. At the same time, your perimeter has become less gated. What you should be doing is auditing the configuration and exposure of your cloud resources. Let’s give a perfect example. Are you sure, and can you prove, that you have no publicly available AWS S3 buckets with sensitive data in them? What about internal controls? Does the data you have stored in S3, and even elsewhere like DynamoDB, have proper access controls and governance? Can anyone in your organization access all the data you’ve collected about your customers? No one wants to be the next organization known for leaking sensitive data through an open S3 bucket. Not only are these controls important when moving to a public cloud provider, but serverless frees you up to spend time ensuring your security in this area.
Next, take a look at your application dependencies. Right now you spend so much time updating the base OS your applications run on, but do you audit the third party modules or libraries that ship with your applications? Your application isn’t just the thousands of lines of code you developed in house. It is the totality of code both produced by you and by others that is required to make the application function. That view takes the amount of lines of code you’re responsible for and can multiply it by 10s, 100s, or even more. For many of us, particularly in smaller organizations or ones with less security maturity, this is out of reach due to time constraints. But with a serverless infrastructure we’ve removed the time spent on host patch management and freed us to travel up the stack to dependency patch management.
Just like you maybe freed up the time spent on physical data center security by moving to the public cloud, moving from virtualization or even containers to serverless let’s you free up more time to address existing but underserved issues in your environment.
Q: Is Serverless The Death Of DevOps (Or even DevSecOps)?
No.
I guess that needs elaboration. The job of operations and security are not going away but they are definitely changing. Serverless gives a high degree of freedom and control to software developers. Where we both could act as gatekeepers previously, serverless takes that ability away from us. Additionally, the ease of managing serverless infrastructure will also mean new organizations will be making operations, and therefore probably security, hires later in their maturity. Many of us have been in the situation of being the first hire in our position and we have our stories about the infrastructure or security debt we inherited. But now imagine the compounded debt of an organization a year or two more along in their life and maturity?
For us to start being involved we need to “shift left” and move closer to development. For that to happen, when supporting or defending serverless infrastructure we need to become better coders and developers. When I speak to operations engineers about this I discuss how we can re-apply our existing skills. We should be involved in architecture design as well as code reviews. We should be ensuring the best design patterns are being chosen to solve a given problem and we should be reviewing and fixing code to make it more resilient to failure. This same advice applies to security engineers as well. They should be reviewing architecture designs to ensure they fall within appropriate risk levels as well as reviewing code for security mistakes.
Companies embracing DevOps and DevSecOps are already doing this more and more. However, it may be time in some organizations, particularly those with a heavy serverless investment, to go a step further and integrate operations and security engineers directly onto development teams. No more development, operations, or security teams, just cross-functional teams dedicated to solving a particular set of business problems. The velocity at which developers can can make changes in a serverless architecture over a virtualization architecture potentially means that the best practices we’re adopting today won’t be enough.
To become productive members of these teams, it means finding an area of the code to own and improve. Let software developers own developing application business value and let operations and security engineers pick up other code tasks. For operations engineers I suggest focusing on performance tuning and fixing bugs in the serverless application code you support. For security engineers I think an interesting approach would be to own the testing, deployment pipeline and other code release functions? Why should security look at owning QA and release engineering functions? Because it let’s security engineers bake in security checks along the way through the software development lifecycle! This allows security to go from being reactive to proactive in defending their applications.
By the way, at ServerlessOps we’ve already written about where we the future of DevOps when server goes away. We’d love to see a companion post for security professionals.
Q: What is OWASP?
I chose this question to cover here because it demonstrates the siloed knowledge we have between security and operations. OWASP is the Open Web Application Security Project and it provides materials for improving understanding of and security of web applications. One of the most important materials they produce is the OWASP Top 10. This list provides organizations with information around the most common security mistakes and risks seen in web applications. If you haven’t started your application security program or don’t know where to start, you should consult the OWASP Top 10.
I knew to ask this question of James during the webinar because even though I knew the answer, I remember being in awe when a security engineer told me about OWASP. While OWASP is well known in security circles, I had never heard of it until I broke out of my normal DevOps circles and began interacting with security professionals more. Just think about that! As an ops person I’m being pushed up the application stack and being asked to better secure applications without being aware of the materials already available from the application security community.
Parting Words
I hope you found something informative and enlightening regarding serverless security during the webinar. However, if there's one thing that you should get out of this presentation it was the communication between operations and security. This webinar was an ops person and a security person sitting down to share their expertise and improve each other’s understanding of the infrastructure they’re responsible for. Take time to sit down with the appropriate teams in your organization and have these conversations. There’s a wealth of information that each team has and when properly combined, leads to a far safer cloud environment. Just think about my OWASP question. How much do you already know that coworker doesn’t because they’ve never been exposed to all that you know?
Finally, didn’t catch us? Have a recap here.