Skip to main content

Introducing AWS Mirror Toolkit

3CS AWS Mirror Toolkit Mascot

Providing traffic analyses in AWS environments is at the core of what we do. Up until recently, the options available to develop these platforms with cloud providers didn't allow us to develop these programs in a truly secure and redundant fashion. 

The limitations that made us feel uncomfortable with these type of deployments were all addressed, however, with the release of AWS Traffic Mirror Sessions. This release, even though it provided us with new opportunities, also had a few challenges for medium to big size deployments.

AWS's Traffic Mirror Sessions were presented at re:Inforce 2019 (keynote recording) and we immediately started using it to replace our legacy approach. What we found was that, even though a great feature, its deployment and usage in large scale environments would lead to quite intensive maintenance and overhead. It would also leave teams with the responsibility of additional configurations, something we spend quite a substantive amount of time trying to avoid in our managed detection services.

3CS AWS Mirror Toolkit is our answer to those challenges. 

The toolkit, which will continue to grow with additional tools and projects, was developed with a few objectives in mind:
  • Completely automate the creation of sessions/visibility of chosen sources
  • It should be minimal in footprint as well as in IAM permissions
  • Tie in with existing workflows and procedures of clients environments
  • Work regardless of how clients choose to do their deployments (CloudFormation, Terraform, Console, AWS CLI, etc)
    • This would also tie in nicely in organizations that have infrastructure as a code (IaC)
  • It shouldn't cost our clients any money
The result of these requirements for one particular project, 3CS AutoMirror, was an AWS Lambda function that acts based on the AWS EC2 instance state. After testing it for a few weeks, we learned we needed another selection/interaction mechanism, as simply having it run on all matching instance states didn't really provide us with what we needed. 

That lead us to a tag-based control of the toolkit. Tags are, after all, something that should be part of everyone's AWS workflow. With this option, we gave our clients full control over what traffic they get to see with something as simple as a Mirror=True.

For our compliance project, 3CS AWS Config MirrorSession, the methodology didn't differ much, even though there are some limitations in AWS Config that make this type of development a bit more tricky. Our goal for this project was to provide our clients with the capability of quickly addressing the state of their Network Security Monitoring program, and do this in a way that would tie in well with AutoMirror usage. We feel we accomplished that.

3CS AWS Mirror Toolkit was released at Suricon 2019, the yearly conference of a software project that is very dear and important to all of us here. 

We gave a presentation about Network Security Monitoring in AWS environments titled Suricata & AWS - Pre and Post Session Mirroring. Slides are available at SpeakerDeck and a recording of the talk is available in Vimeo.

Going forward, the toolkit will continue to increase in functionality and incorporate additional projects. We're receiving a lot of good feedback and have a few changes in the pipeline that should result in even better automation and orchestrations.

Stay tuned!

Follow us on Twitter!
Labels:

Popular posts from this blog

Community Update - 3CORESec Blacklist 📓 🍯

Recently we tweeted about some issues we had with 3CORESec Blacklist , a platform that shares - openly and freely - a subset of the information seen and processed by our honeypot network.  While those issues have been addressed, and seeing as significant changes were made to how we monitor the generation of the lists (which is reflected in our status page ) and how we determine if an IP should be listed as an offending IP or not, this felt like a good opportunity to write a bit more about the platform as well as the changes we made.   For regular users of Blacklist 📓 the first thing they’ll notice is an increase on the numbers of IPs we include. That is a direct result of the changes we made and the growth of the honeypot network itself. We have not - and will not - ever increase the period for which we query the honeypot network, as we believe anything higher than 24h (as specified in the project page) for IP addresses can quickly fall into a decaying state that adds little value
Read more

Detection as Code (DaC) challenges - Introducing Automata

This blog post is the second part of our Detection as Code (DaC) challenges series. You can read part one here . The development process of detections by itself doesn't pose a lot of barriers for security engineering teams, as they are typically done in a lab/controlled environment, but after tuning and deploying rules to a SIEM, the work is only starting. Many things can go wrong after this, and a process of continued and automated testing is crucial. Detection Validation In an ideal (and fictional) world, once the datasets are parsed, normalized, and put into production, detections developed by your team would work forever. Still, the reality is quite different. Maintenance is heavy work that needs to be done frequently - especially if you work on an MSP - but the reality is that the ecosystem lacks tooling and processes to do it proactively. Effectiveness is an important metric and crucial to the successful response of incidents in time, and effectiveness is what we aim to ensu
Read more

Trapdoor - The serverless HTTP honeypot

  Today we are announcing the release of Trapdoor , our AWS-based serverless honeypot.  The idea of a serverless honeytoken isn't new. Adel released his honeyLambda a few years ago and we've been working with it for quite some time. It was because of this experience and the goal of improving on what was already a great idea that we decided to go to the drawing board and see how we would change and tweak the concept.  What is it? Trapdoor is a serverless application that can be deployed in any AWS environment. Its goal is to receive HTTP requests with the intent of identifying, and alerting, on its visitors. The URLs generated by Trapdoor can also be referred to as honeytokens .  While you can get creative on how to use it, one of the goals of a honeytoken is to be hidden or stored in a "safe" place and, if accessed, fire of an alarm, as access to the token would be considered a compromise or unauthorized access.  This example is the passive way of using deception ta
Read more