Tag: Hardening

Prowler 2.0: New release with improvements and new checks ready for re:Invent and BlackHat EU

Toni de la Fuente 1 Comment

Taking advantage of this week AWS re:Invent and  next week BlackHat Europe, I wanted to push forward a new version of Prowler.

In case you are new to Prowler:

Prowler is an AWS Security Best Practices Assessment, Auditing, Hardening and Forensics Readiness Tool. It follows guidelines of the CIS Amazon Web Services Foundations Benchmark and DOZENS of additional checks including GDPR and HIPAA groups. Official CIS benchmark for AWS guide is here.

This new version has more than 20 new extra checks (of +90), including GDPR and HIPAA group of checks as for a reference to help organizations to check the status of their infrastructure regarding those regulations. Prowler has also been refactored to allow easier extensibility. Another important feature is the JSON output that allows Prowler to be integrated, for example, with Splunk or Wazuh (more about that soon!). For all details about what is new, fixes and improvements please see the release notes here: https://github.com/toniblyx/prowler/releases/tag/2.0

For me, personally, there are two main benefits of Prowler. First of all, it helps many organizations and individuals around the world to improve their security posture on AWS, and using just one easy and simple command, they realize what do they have to do and how to get started with their hardening. Second, I’m learning a lot about AWS, its API, features, limitations, differences between services and AWS security in general.

Said that, I’m so happy to present Prowler 2.0 in BlackHat Europe next week in London! It will be at the Arsenal

and I’ll talk about AWS security, and show all new features, how it works, how to take advantage of all checks and output methods and some other cool things. If you are around please come by and say hello, I’ve got a bunch of laptop sticklers! Here all details, Location:  Business Hall, Arsenal Station 2. Date: Wednesday, December 5 | 3:15pm-4:50pm. Track:  Vulnerability Assessment. Session Type: Arsenal

BIG THANKS!

I want to thank the Open Source community that has helped out since first day, almost a thousand stars in Github and more than 500 commits talk by itself. Prowler has become pretty popular out there and all the community support is awesome, it motivates me to keep up with improvements and features. Thanks to you all!!

Prowler future?

Main goals for future versions are: to improve speed and reporting, including switch base code to Python to support existing checks and new ones in any language.

If you are interested on helping out, don’t hesitate to reach out to me. \m/

Prowler 1.6: AWS Security Best Practices Assessment and Forensics Readiness Tool

Toni de la Fuente 1 Comment

It looks like Prowler has become a popular tool for those concerned about AWS security. I just made Prowler to solve an internal requirement we have here in Alfresco. I decided to make it public and I started getting a lot of feedback, pull requests, comments, advices, bugs reported, new ideas and I keep pushing to make it better and more comprehensive following all what cloud security community seems to need.
I know Prowler is not the best tool out there but it does what I wanted it to do: “Take a picture of my AWS account (or accounts) security settings and tell me from where to start working to improve it”. Do the basics, at least. And that’s what it does. I would use other tools to track service change, etc., I discuss that also in my talks.
Currently, Prowler performs 74 checks (for an entire list run `prowler -l`), being 52 of them part of the CIS benchmark.

Digital Forensics readiness capabilities into Prowler 1.6

`prowler -c forensics-ready`
I’m into DFIR, I love it and I read lot about cloud digital forensics and incident response, I enjoy investing my time R&D about that subject. And I’m concerned about random or targeted attacks to cloud infrastructure. For the talk I’m doing today at the SANS Cloud Security Summit 2018 in San Diego, I wanted to show something new and I thought about adding new checks to Prowler related to forensics and how to make sure you have all (or as much) what you need to perform a proper investigation in case of incident, logs that are not enabled by default in any AWS account by the way. Some of those checks are included and well described in the current CIS benchmark for AWS, or even in the CIS benchmark for AWS three tiers web deployments (another hardening guide that is way less popular but pretty interesting too), but there are checks that are not included anywhere. For example, I believe it is good idea to keep record of your API Gateway logs in your production accounts or even your ELB logs, among many others. So when you run  `prowler -c forensics-ready` now you will get the status of your resources across all regions, and you can make sure you are logging all what you may eventually need in case of security incident. Currently these are the checks supported (https://github.com/toniblyx/prowler#forensics-ready-checks):
  • 2.1 Ensure CloudTrail is enabled in all regions (Scored)
  • 2.2 Ensure CloudTrail log file validation is enabled (Scored)
  • 2.3 Ensure the S3 bucket CloudTrail logs to is not publicly accessible (Scored)
  • 2.4 Ensure CloudTrail trails are integrated with CloudWatch Logs (Scored)
  • 2.5 Ensure AWS Config is enabled in all regions (Scored)
  • 2.6 Ensure S3 bucket access logging is enabled on the CloudTrail S3 bucket (Scored)
  • 2.7 Ensure CloudTrail logs are encrypted at rest using KMS CMKs (Scored)
  • 4.3 Ensure VPC Flow Logging is Enabled in all VPCs (Scored)
  • 7.12 Check if Amazon Macie is enabled (Not Scored) (Not part of CIS benchmark)
  • 7.13 Check if GuardDuty is enabled (Not Scored) (Not part of CIS benchmark)
  • 7.14 Check if CloudFront distributions have logging enabled (Not Scored) (Not part of CIS benchmark)
  • 7.15 Check if Elasticsearch Service domains have logging enabled (Not Scored) (Not part of CIS benchmark)
  • 7.17 Check if Elastic Load Balancers have logging enabled (Not Scored) (Not part of CIS benchmark)
  • 7.18 Check if S3 buckets have server access logging enabled (Not Scored) (Not part of CIS benchmark)
  • 7.19 Check if Route53 hosted zones are logging queries to CloudWatch Logs (Not Scored) (Not part of CIS benchmark)
  • 7.20 Check if Lambda functions are being recorded by CloudTrail (Not Scored) (Not part of CIS benchmark)
  • 7.21 Check if Redshift cluster has audit logging enabled (Not Scored) (Not part of CIS benchmark)
  • 7.22 Check if API Gateway has logging enabled (Not Scored) (Not part of CIS benchmark)
Screenshot while running `forensics-ready` group of checks, here only showing 3 of the first checks that are part of that group
I haven’t added yet a RDS logging check and I’m probably missing many others so please feel free to open an issue in Github and let me know!
If you want to check out my slide deck used during my talk at the SANS Cloud Security Summit 2018 in San Diego, look at here: https://github.com/toniblyx/SANSCloudSecuritySummit2018

Hardening assessment and automation with OpenSCAP in 5 minutes

Toni de la Fuente 1 Comment
SCAP (Security Content Automation Protocol) provides a mechanism to check configurations, vulnerability management and evaluate policy compliance for a variety of systems. One of the most popular implementations of SCAP is OpenSCAP and it is very helpful for vulnerability assessment and also as hardening helper.
In this article I’m going to show you how to use OpenSCAP in 5 minutes (or less). We will create reports and also dynamically hardening a CentOS 7 server.
Installation for CentOS 7:
yum -y install openscap openscap-utils scap-security-guide
wget http://people.redhat.com/swells/scap-security-guide/RHEL/7/output/ssg-rhel7-ocil.xml -O /usr/share/xml/scap/ssg/content/ssg-rhel7-ocil.xml
Create a configuration assessment report in xccdf (eXtensible Configuration Checklist Description Format):
oscap xccdf eval --profile stig-rhel7-server-upstream \
--results $(hostname)-scap-results-$(date +%Y%m%d).xml \
--report $(hostname)-scap-report-$(date +%Y%m%d)-after.html \
--oval-results --fetch-remote-resources \
--cpe /usr/share/xml/scap/ssg/content/ssg-rhel7-cpe-dictionary.xml \
 /usr/share/xml/scap/ssg/content/ssg-centos7-xccdf.xml
Now you can see your report, and it will be something like this (hostname.localdomain-scap-report-20161214.html):
 
See also different group rules considered:
You can go through the fails in red and see how to fix them manually or dynamically generate a bash script to fix them. Take a note of the Score number that your system got, it will be a reference after hardening.
In order to generate a script to fix all needed and harden the system (and improve the score), we need to know our report result-id, we can get it running this command using the results xml file:
export RESULTID=$(grep TestResult $(hostname)-scap-results-$(date +%Y%m%d).xml | awk -F\" '{ print $2 }')
Run oscap command to generate the fix script, we will call it fixer.sh:
oscap xccdf generate fix \
--result-id $RESULTID \
--output fixer.sh $(hostname)-scap-results-$(date +%Y%m%d).xml
chmod +x fixer.sh
Now you should have a fixer.sh script to fix all issues, open and edit it if needed. For instance, remember that the script will enable SELINUX and do lots of changes to Auditd configuration. If you have a different configuration you can run commands like bellow after running ./fixer.sh to keep SElinux permissive and in case you can change some actions of Auditd.
sed -i "s/^SELINUX=.*/SELINUX=permissive/g" /etc/selinux/config
sed -i "s/^space_left_action =.*/space_left_action = syslog/g" /etc/audit/auditd.conf
sed -i "s/^admin_space_left_action =.*/admin_space_left_action = syslog/g" /etc/audit/auditd.conf
Then you can build a new assessment report to see how much it improved your system hardening (note I added -after to the files name):
oscap xccdf eval --profile stig-rhel7-server-upstream \
--results $(hostname)-scap-results-$(date +%Y%m%d)-after.xml \
--report $(hostname)-scap-report-$(date +%Y%m%d)-after.html \
--oval-results --fetch-remote-resources \
--cpe /usr/share/xml/scap/ssg/content/ssg-rhel7-cpe-dictionary.xml \
 /usr/share/xml/scap/ssg/content/ssg-centos7-xccdf.xml
Additionally, we can generate another evaluation report of the system in OVAL format (Open Vulnerability and Assessment Language):
oscap oval eval --results $(hostname)-oval-results-$(date +%Y%m%d).xml \
--report $(hostname)-oval-report-$(date +%Y%m%d).html \
/usr/share/xml/scap/ssg/content/ssg-rhel7-oval.xml
OVAL report will give you another view of your system status and configuration ir order to allow you improve it and follow up, making sure your environment reaches the level your organization requires.
Sample OVAL report:
Happy hardening!

Prowler: an AWS CIS Security Benchmark Tool

Toni de la Fuente 2 Comments

screenshot-2016-09-14-22-43-39In this blog post I’m happy to announce the recent release of Prowler: an AWS CIS Security Benchmark Tool.

At Alfresco we run several workloads on AWS and, like many others companies, we use multiple AWS accounts depending on use cases, projects, etc.

To make sure we have a foundation security controls applied to each  account, AWS counts with a service called Trusted Advisor which has, among other features, a section for Security Best practices, it checks some services and give us some recommendations to improve Security of our account, 3 checks are free the rest of them (12) are available only for customers with Business or Enterprise support plan:

screenshot-2016-09-14-17-26-09

Trusted Advisor is fine, but it is not enough comprehensive and it is not free. Here is a screenshot of Trusted Advisor in the AWS Console on a Business support plan account:
screenshot-2016-09-14-17-30-09

In addition to that AWS service, few months ago the Center or Internet Security (CIS) along with Amazon Web Services and others, released the CIS AWS Foundations Benchmark. In that document we can find a collection of audit checks and remediations that cover the security foundations for these main areas in AWS:

  • Identity and Access Management (15 checks)
  • Logging (8 checks)
  • Monitoring (16 checks)
  • Networking (4 checks)

The 89 pages guide goes through 43 recommendations by explaining why that check is important, how to audit it and how to remediate it in case you don’t have it properly configured.

If you try to follow all these checks manually it may take you a couple of days to have all of them checked. This is why in Alfresco we decided to write a tool to make it faster, thus I wrote “Prowler”, a command line tool based on AWS-CLI that creates a report in a minute and shows you how is your AWS account configured in terms of security (using fancy color codes).

screenshot-2016-09-13-09-31-07

Prowler, whose name comes from the Iron Maiden song with the same name, works in Linux, OSX and Windows (with Cygwin), with AWS-CLI installed. It also requires an AWS account with at least the SecurityAudit policy applied as specified in the documentation. For more information, details and sample reports visit the project repository in Github here https://github.com/toniblyx/aws-cis-security-benchmark.

Please, go ahead, check it out and give me feedback!

Hope it helps!

UPDATE! Right after I published this post, I was pointed in Twitter by @MonkeySecurity about Scout2, which is a tool we use here since long time and it is very helpful. It has many different checks and it is complementary to Prowler, don’t forget to give it a try! And also use SecurityMonkey if you are not doing so already!

UPDATE2! Another tool to perform AWS security checks is the CloudSploit Scans, more info here.