Yesterday, I was working on this somewhat routine activity report of my project’s last six months stint. Afterwards, while I was reflecting on the big picture of what has changed during this time, I had the idea of what I think can be some nice blog post material.

Please, let me explain why I found this activity report a bit humdrum: 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. It was a fairly monotonous task on the surface but it helped me realize that change was big at the end of the day.

Now, please let me explain some interesting facts about this report: nowadays we spend considerably less on security but we have built stronger protection against cyber-criminals. Now we have fewer unused resources, fewer people doing maintenance on them and, best of all, we are using more exciting tools.

Before and after

Six months ago, my project’s security infrastructure was mainly serverful: 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 some casual rushing after outdated or unpatched operating systems or applications exposing potential vulnerabilities.

Nowadays, my project goes serverless-first. It took some time to get there, but my team is beginning to enjoy it smoothly: fewer infrastructure management and fewer maintenance. No more rushing for patches and no more afternight interventions.

Serverless services

“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 some months ago, both availability and uptime tend to be better on serverless.

My team have replaced some server-based tools with their serverless counterparts. For instance, GuardDuty is now my project’s main threat detection tool. It is kind of recent so it may need an introduction; it is a managed service that monitors all the API Calls on your accounts as well as flow logs, and it generates alerts when abnormal activity is detected: brute force attacks, port probing, bitcoin mining, IAM misuse and other kinds of abuse. Furthermore, it uses AI for shorter reaction times as well as for detection of more sophisticated attacks as the days go by.

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 it is highly effective on that. It can be useful for GDPR compliance assessments and audits. Again, it is powered by AI.

Just Serverless

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 case we get under distributed attacks.

The thing that I like best with 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 libraries)

Serverless all the way

In this project, managed services have worked well with Functions-As-A-Service 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 its libraries onto target AWS accounts and works hand-in-hand with CloudWatch for scheduled execution.

A Cloud Systems Developer’s job here is only to create YAML descriptions (policies on the c7n idiom) using Custodian’s own DSL for compliance rules so c7n can check them automatically. That 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.

One can even reuse Lambda functions from GuardDuty’s remediations for automating compliance enforcement on Custodian’s findings. That way, one can get double protected for no extra cost.

I am really impressed about this tool, because it can work using serverless assets exclusively. I believe that this architecture model can be used on many different application types, besides security and compliance.

The bottomline

Please consider going Serverless Secure. It worked for my project and it gets better everyday. And it is fairly cheaper.