Blogs > How we automate security verifications using AWS services
10 diciembre –

How we automate security verifications using AWS services

Ubirajara Aguiar Jr., Information Security Specialist at Pismo, spoke about active security monitoring at the Open Web Application Security Project (OWASP)

Pismo
6 mins read

Operational cyber security requires constant monitoring of computer systems, a task that we can automate by orchestrating cloud-based services. Ubirajara Aguiar Jr., Information Security Specialist at Pismo, showed how to do this in a recent speech at the Open Web Application Security Project (OWASP).

The attack surface

The goal of Ubirajara’s demonstration was to show how to detect security vulnerabilities on the attack surface (the points where an unauthorised user might try to enter or extract data from a computer environment). “The attack surface includes, for instance, code repositories, file storage buckets, social networks, websites, and DNS servers,” explained Ubirajara.

We must check several aspects to ensure the attack surface is well protected. “For each of these tasks, we can create an automation routine using a script”, said Ubirajara. He gave examples of procedures that we can automate this way:

  • Monitoring web applications
  • Searching for public buckets
  • Checking e-mail verification methods (DMARC, SPF, and DKIM)
  • Detecting sensitive information (such as log-in credentials) in code repositories
  • Listing unused subdomains that could become attack vectors
  • Verifying anti-spoofing measures
  • Probing for open ports on host servers
  • Mapping open data sources that an attacker could exploit using “Google dorks.”

Example 1 — Checking HTTP response headers

Ubirajara showed how we could automate the verification of the HTTP response headers on a website.

OWASP hosts the OWASP Secure Headers project that lists best practices to be followed when implementing these headers. Its goal is to increase the security of web applications. Given a list of websites, an automated routine can check if they follow the best practices and warn the security team if it finds a non-compliant header.

Ubirajara used Amazon Web Services (AWS) for his demonstration: “Let’s think backwards. We want to receive a warning if a vulnerability is found. So we can use SNS, AWS messaging service. Before sending this message, we must run the script. We can do this serverless on AWS Lambda. And we need to evaluate the HTTP headers periodically, which we can do with AWS Config, Amazon auditing tool.” So we will have this configuration:

AWS Config > Lambda > SNS

Step by step implementation

The steps that Ubirajara followed in his demonstration are:

  1. Instal and configure awscli, AWS command-line interface
  2. Instal AWS Config Rule Development Kit (RDK)
  3. Use RDK to generate a template for the script
  4. Create an SNS topic to receive notifications
  5. Edit and test the script
  6. Use RDK to deploy the script

The script

Let’s see a few details of this implementation. After installing awscli and RDK, Ubirajara ran RDK, which created a bucket on AWS to store the code templates. With the same tool, he defined a template for a Python script that would run daily.

RDK includes ready-to-use templates for several security verifications, and it’s much easier to create the script with this tool than write it from scratch. “Though the template files are huge, we only have to edit the first block, where we will insert our logic,” says Ubirajara.

AWS Lambda functions follow the same standard as Python lambda functions. They receive an event and context as parameters and return an output value,” he explains. “Our function receives data from AWS Config. The code generated by RDK already includes a Lambda handler. So it’s ready to be used on Lambda.”

“It’s important to create the SNS topic before editing the script. We need the Amazon Resource Name (ARN) that identifies the topic to send the output of our Python program to SNS.”

In the template, Ubirajara edited the block identified by the comment “Add your custom logic here.” The Python code has a dictionary with the expected values for the HTTP response headers, based on the OWASP recommendations. The program checks if these headers exist on the website and have the recommended values.

Depending on what it finds, the program returns either compliant, non_compliant, or not_applicable. This output goes to AWS Config, where a non_compliant value is highlighted in red. Another function in the Python program sends an e-mail to the system administrator with the verification results.

Time to deploy

With RDK, we can test the solution and correct any possible errors in the program. When we finish the tests, it’s time to deploy the script. The deployment generates several files, including:

  • A template for CloudFormation, the AWS infrastructure-as-code tool
  • A Lambda function, with the logic that we specified in the Python code
  • A rule in AWS Config to run the script

After finishing the deployment, we will have the automatic HTTP response header checker ready.

Read more about security:

How we apply the defence in depth concept for red team engagements

Example 2 — Using Docker with Lambda to run a port scanner

A second example given by Ubirajara is a routine to probe host servers for open ports periodically. He used the popular Nmap port scanner for this task. Since Nmap is not native to AWS, he installed it in a Docker container. The configuration is:

AWS Config > Docker > Lambda > SNS

To control Nmap with the Python script, Ubirajara used the python-nmap library. He orchestrated the services so that the security team would receive a warning if an abnormal open port were found. The steps for the implementation are:

  1. Instal and configure awscli
  2. Instal AWS Config Rule Development Kit (RDK)
  3. Use RDK to generate a template for the script
  4. Create an SNS topic to receive notifications
  5. Mount a Docker image using the docker build command
  6. Create an AWS ECR repository and send the Docker image to it
  7. Create a Lambda function pointing to the Docker image
  8. Manually define a rule on AWS Config referring to the Lambda function

“We input the Lambda function’s ARN into AWS Config so that it can call the function. Then we specify that the function should run daily. After each execution, a notification will be sent to the administrator listing open ports that should be closed,” says Ubirajara.

Serverless x server-based

Ubirajara used the AWS Pricing Calculator to evaluate the cost of this serverless solution. He compared it with a server-based option implemented on AWS EC2. In the hypothetical scenario that he considered, the EC2-based implementation would be 26 times more expensive than the serverless solution that he proposed.

“Except in the case of an extremely complex environment, with many functions and frequent executions, the Lambda-based solution is much cheaper,” he concluded. “And it is also easier to maintain than an EC2-based implementation.”

The main limitation of this serverless implementation is that a Lambda function cannot run for more than 15 minutes. If the verification process requires a longer execution time, we must adopt a server-based solution instead.

Here is the video footage of the demonstration in Portuguese:

More Articles

05 octubre -

Embrace the public cloud to power a new generation of banking

Alexander Hamilton
6 min

03 octubre -

Pismo is a finalist in the DevPortal Awards; public voting is open

Fernanda Testa

30 septiembre -

Open finance still timid in Brazil, says Daniela Binatti at BTG Pactual

Fernanda Testa

Suscríbete a nuestro Boletín

Contact Pismo