Search for a command to run...
Miguel is a Principal Engineer and the author of the “Serverless Security” book. He has worked on multiple serverless projects as a developer and security engineer, contributed to open-source serverless projects, and worked on large military systems in various engineering roles.
No comments yet. Be the first to comment.
Protect your system from vulnerabilities
How I saved my company $1 million
This YouTube video series provides quick overviews of the top 10 cybersecurity risks for serverless applications. Each video covers the risk and some recommendations on how to address it. Why is the OWASP Serverless Top 10 important? In this video, I...
![Overview of the OWASP Serverless Top 10 [videos]](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1636408504092%2FBcNttK9q2.png&w=3840&q=75)
A little over one year ago, I published my first book thanks to Apress and author Nihad Hassan. I am in a cybersecurity writing group with Nihad, where he shared he had published his 4th book; this was back in 2019. I was impressed by his accomplishm...
You may have heard, “If you build it, they will come.” Have you heard, “If you build it, I will break it?” This is a skill I developed over my career to build better systems. It is a skill that took me a while to learn I had. Shortly before I graduat...
Miguel's Blog · Serverless · Security
49 posts
Miguel A. Calles is the author of the Serverless Security book, and a Cybersecurity engineer who works on serverless and cloud computing projects.
Do your serverless deployments go like this?
It’s so easy to quickly deploy serverless resources. Because of this, we should follow best practices to protect our resources, applications, and cloud service provider accounts. Here are some best practices for you to consider.
A serverless function should perform a specific function. Similar to a function or method in any code should do one thing (e.g., increment a counter, transform data, etc.), a serverless function show perform a logical function. For example, you would create one serverless function for validating a login, another for validating a login session, another for deactivating a login session. Having a serverless function perform more than one thing makes it vulnerable to bugs and makes it more difficult to maintain.
Microservices allows us to contain data stores and functions into a maintainable group. The microservice will follow a contract that limits what it can and cannot do. For example, an account microservice will allow creating, updating, and deleting user accounts. This microservice should never modify any data outside of the user account data store. Furthermore, it will have a specific application programming interface (API). This allows other microservices to interact with the user account serverless functions in a consistent way without having to modify any of its user account data stores.
AWS allows us to use CloudFormation stacks when deploying resources, and each Serverless Framework configuration deploys one CloudFormation stacks. We should aim to have one stack per resource type. For example, our user account microservice could have: database stack (to store account metadata in DynamoDB), identity provider (IdP) stack (to set up and maintain user sessions with Cognito), function stack (to deploy Lambda functions that provide the user account microservice API), and object store stack (to capture user account profile pictures in S3). This allows you to update a resource type without disrupting another resource type. For example, if you make an error in a functions stack deployment, your other stacks remain unaffected.
AWS offers three types of APIs: HTTP APIs, REST APIs, and GraphQL APIs. Each API has different benefits. HTTP APIs use API Gateway, are lightweight and natively support OpenID and OAuth. REST APIs use API Gateway, are fully featured REST APIs and provide additional security features. GraphQL APIs use AppSync, use a simple, but string query language, and integrates with DynamoDB databases and Elasticsearch Service data aggregator. API Gateway HTTP and REST APIs are best for interactions between APIs (or microservices) and providing external applications access to your applications API. AppSync GraphQL APIs are best between client and backend integrations within the same application (of course your client can still use an API Gateway API too.)
All your resources should have the smallest set of IAM permissions. For example, a serverless function that reads a DynamoDB table should only have the read action for that one DynamoDB table. You should avoid using an asterisk “*” when defining privileges whenever possible. If you Lambda function is ever compromised and it uses asterisks such that every DynamoDB is accessible and every action is allowed, then a hacker can read and delete all database data.
When you are first developing an application, deploying from the command line interface (CLI) is okay. Ideally before you get to deploying to production, you should be using a CI/CD pipeline to deploy your code. You can use services such as Serverless Framework Pro, GitHub Actions, SEED, and many others. CI part of the pipeline allows you to run linting checks, unit tests, and many other automated checks before allowing a pull request to merge. The CD part of the pipeline allows you to automatically deploy your serverless application whenever a PR is merged or a branch is updated. Using a CI/CD pipelines removes human error and introduces repeatability in your process.
We should use services, such as Dashbird, to monitor our serverless resources. There may be so many resources and they may be used so much that it would be difficult to manually check them for errors. Monitoring services can report health, longer executions, delays, and errors. Having a service that tells us when our serverless application and resources are having issues helps us to find and fix issues faster.
In addition to monitoring, we want to audit. Monitoring tells when when something stops working or is having issues. Auditing tells us when our resources deviate from a known configuration or are improperly configured. We can use services such as AWS Config to create rules that audit our resources and their configurations. Config also has some predefined conformance packs that help us implement best practices. Here are some to consider:
We also want to audit our software dependencies. Just because we no longer have a server, it does not mean we are free from “patching.” We want to make sure any software dependencies we define are up-to-date and have no known vulnerabilities. We can use services such as GitHub Dependabot and Snyk to keep us informed the software packages that need updating.
Your mileage will vary depending on your business and technical requirements, the complexity of your application, and your cost and schedule. These best practices are aimed to guide in the right direction; they are based on the “Serverless Security” book.
Originally published on Medium.com
Photo by Sarah Kilian on Unsplash
