Javier Merchan reflects back on a recent project and how he and his team used serverless technology to build a stronger, more cost-efficient security solution for a customer.
Recently, I was working on a somewhat routine, activity report summarizing my project’s last six months. Afterward, while reflecting on the big picture of what has changed during this time, I had an idea for some material that I thought would make a nice blog post.
On the surface this looked like a bit of a humdrum activity: I had to go all the way through our AWS bills in order to map services and manpower and match costs to my project’s roadmap and budget. Reasonably monotonous to be fair but it helped me realize the size of the impact of serverless adoption on our security infrastructure.
I noticed that while we spend considerably less on security, we have built stronger protection against cyber-criminals. Furthermore, we have fewer unused resources, fewer people doing maintenance and, best of all, we are using more exciting tools.
Before and after
Six months ago, my project’s security infrastructure was largely server-based: threat detection was mainly performed on EC2 instances with security tools installed, running 24/7 (as intruders and robots don’t sleep at night).
In the old days, all those servers required some maintenance duties and sometimes even hurried identification and remediation after outdated or unpatched operating systems or applications exposed potential vulnerabilities.
Nowadays, my project goes serverless-first. It took some time to get there, but my team is beginning to enjoy it: less infrastructure management and less maintenance. No more rushing to do patches and no more overnight interventions.
“There is still server in Serverless”, as some seasoned engineers say from time to time. They are absolutely right, but I prefer to think that now AWS manages all those servers on my behalf. In the medium-term, when comparing figures from several months ago, both availability and uptime figures are better on serverless.
My team has replaced some server-based tools with their serverless counterparts. For instance, GuardDuty is now my project’s main threat detection tool. Lesser known, it may need an introduction. GuardDuty is a managed service that monitors all the API Calls on your accounts as well as flow logs. It generates alerts when abnormal activity is detected: brute force attacks, port probing, bitcoin mining, IAM misuse, etc. Furthermore, it uses AI for shorter reaction times as well as for detection of newly developed, and increasingly sophisticated, attacks.
GuardDuty worked well out-of-the-box, so the “nice to have” next step was to try out Macie. This managed service looks for indiscreet Personal Identifiable Information left on S3 buckets and is highly effective at doing just that. The service is powered by AI and it is particularly useful for GDPR compliance assessments and audits.
Instead of processing GuardDuty’s findings manually, my team relies on automated remediations. These remediations are tailored for different kinds of threats, and they act on-the-spot minimizing the attack surface. This is only possible by using Lambda and its bigger brother: Step Functions.
In this case, serverless enables us to spin up computing power automatically only when it is necessary, thus reducing the Total Cost of Ownership. More interestingly, we benefit from its asynchronous nature by spinning up a huge number of concurrent remediations in the event of prolonged or distributed attacks.
The thing I like best about serverless, is that it reconciles me with my computer scientist background: it is loosely coupled (each Lambda function is, on average, about 30 lines long) and code is reused frequently (same Lambdas for multiple different finding types, Lambda layers for our commonly used code).
Serverless all the way
In this project, managed services have worked well with Functions-As-Code so far. Now, I would like to introduce a 100%-serverless tool.
Cloud Custodian (c7n for the initiated) is an open-source, no-servers-included compliance enforcement tool. It deploys Lambdas containing all needed libraries into target AWS accounts and works hand-in-hand with CloudWatch for scheduled execution.
A Cloud Systems Developer needs only to create YAML descriptions (policies in c7n jargon) using Custodian’s own DSL for compliance rules so c7n can check them automatically. In this way, resources can be verified constantly for compliance-readiness, thus minimizing the risk for potential security holes.
When non-compliant resources are found, c7n can invoke Lambda functions for automating notification, archiving, remediation or integration with other tools and services.
We can even reuse Lambda functions from GuardDuty’s remediations for automating compliance enforcement on Custodian’s findings. That way, we can get double protected for no extra cost.
I am really impressed with this tool, because it can work using serverless assets exclusively. I believe this architectural model can be used on many different application types, not only security and compliance.
The bottom line
Please consider going Serverless Secure: lots of features, near-daily improvement, and cost savings to boot, what’s not to like?