My previous article discussed the benefits of threat modelling while developing serverless applications. In this article, I will explain the process of conducting threat modelling, documenting the threats, attackers, and mitigation steps.
As we briefly saw in my previous article, STRIDE is a methodology widely used in threat modelling. The process I will explain here is based on STRIDE. It stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege.
Spoofing is pretending to be someone or something other than the origin-self.
This is the first of a two-part series on threat modelling in serverless.
In this first article, we discuss the threats related to a serverless application and build a case for incorporating threat modelling as part of the development process.
In the second part, I will explain the threat modelling process with simple steps that will help you understand, adapt, and expand as per your domain and development practices.
“Trust nobody!” “Secure everything!” “Defend in depth!” These phrases are echoed at every tech conference, more so at cloud and serverless ones.
Most organizations embark upon various measures to raise security…
Scale-to-zero and pay-per-use have been the main drivers for many organizations adopting serverless. Given the premise, the motivation behind everyone going serverless is to reduce the cost of operation. Almost every serverless success story revolves around the cost factor.
There was a time when I used to compare the cost of EC2 instances against Lambda functions. It was interesting at the beginning.
AWS re:Invent 2020 is coming to us this time. With hundreds of sessions and talks to attend, choosing the right ones can be a challenge!
Here, I am adding here a list of sessions that I identified that I thought would benefit a serverless engineer. Not all sessions are on serverless. I have reasons why I have included non serverless sessions as well. You will understand as you read through the short description I have added for each.
You can see my complete list under the AWS Hero’s pick in Cloud Pegboard’s AWS re:Invent 2020 agenda. …
6:30 AM. A bright day is dawning. I am walking briskly through a leafy path.
My ears are free!
No electronics jammed into my ears!
No heavy metal pumping into my head!
No soothing music floating in my heart!
No talk-show host influencing my decisions!
I am listening to the world!
Echoes of the traffic on the road!
Little birds chirping in the bush alongside the path!
A lonesome crow caws in the distance!
A couple of greedy squirrels joyfully squeak as they collect more nuts than they need!
They fill me with the music and the noise and communicate…
I had a humble beginning with Amazon DynamoDB. I heard that DynamoDB was the place to store the sessions in a serverless environment. So I created a table.
Many recommended the session identifier (ID) as the Partition Key (PK) and a timestamp attribute to store the creation time. I thought it was so simple.
Soon, the sessions were flourishing in millions. Adding a session, reading a session took just a few milliseconds. I was happy!
One day, I asked myself, how would I block someone from using an old session? Easy! Fetch the session, check the timestamp. If old, then…
An event is something of importance that happens at a certain point in time. It is unique. It is singular. In technical speak, an event carries information that has the potential to influence one or more applications.
Here are a few sample events.
A typical application can emit numerous events during its operation.
When we think of an event, we mainly relate it to having a simple data structure that carries one message. …
I once worked for a corporation that had its offices close to a river. It was a beautiful location with great views. Lunch-hour walks became the most satisfying part of my workday.
Something I witnessed along my walking path one day, completely changed how I had perceived and practiced my talks up until that day.
On a dry summer day, as I was walking, I heard a distant but faint voice. I stopped and listened. It sounded more like a one-way talk than a conversation.
As I walked closer, I saw a man standing at the edge of the riverbank…
In the previous article “Think and Develop Serverless Applications as Set-Pieces”, we saw how a serverless application can be thought of as a collection of set-pieces and developed as independent smaller services. In this article, we will see how to apply the set-pieces concept in practice. For this, we will look at Back-in-stock Email Notification feature as a case study.
As I walk you through the requirements and the architecture, I will try and follow a simple narration. I believe simple messages do not require expansive modeling artifacts!
Here is the one-liner requirement for the Back-in-stock Email Notification feature.
In my previous articles on serverless, I used themes such as cooking, growing, fishing, and hiring. In this, I talk about football, movies, and music. “What do they have to do with serverless?”, you might ask. Well, there isn’t anything directly common between these themes and serverless. However, with some imagination and story-telling, we can easily build the connections ourselves.
Engineer. Architect. Leader. Writer. Speaker. At The LEGO Group. AWS Serverless Hero.