Skip to main content

Lawmaker - SaaS platform for Suricata rule and ruleset management

We're excited to finally reveal something that has been cooking in the 3CS kitchen for the past few months; After so many changes and iterations, it's ready enough to be shown. 

Introducing Lawmaker

Lawmaker is our approach to a multi-tenant, web-based, API-driven and lightweight platform to manage and control rules and rulesets of a Suricata deployment. 

If you work with any IDS system you'll know that managing the rules, the suppressions and the thresholds, is a vital part of managing the system. Until now there was no easy way to manage a large fleet of systems, within a client or spread through different clients, and we believe Lawmaker will help everyone that is facing this problem.

Lawmaker was developed based on our requirement of having a platform that is highly resilient and constantly available while reducing the time needed to make changes in client environments, in a secure and rapid fashion. 

Lawmaker is a cloud-native application that was developed using the serverless model. It's an API-driven application deployed in AWS CloudFront and completely ran on AWS Lambda, DynamoDB and S3 (as well as many other AWS services; 16 to be exact).

Lawmaker features

One of the main objectives of development was to keep as close as possible to what Suricata has as defaults. Not only would this ease the deployment of an agent in the sensors but would also align Lawmaker's data models to what Suricata had already developed. The features below will reference many aspects of the Suricata documentation and it will give you a good, technical, perspective of what the platform does.

Manage rules

This section is composed of two features:
  1. Global Thresholds
  2. Disable Rules
Global Thresholds implements parts of the Global Thresholds documentation and is 100% aligned with Suricata defaults.

Disable Rules implements the standard way of managing rules in Suricata through the usage of suricata-update. Our implementation follows the documentation and all files created by this feature follow the Suricata defaults.

BPF Filter

Developed to also implement the capability of managing which traffic is ignored, BPF Filter is a vanilla implementation of the capture filters that are documented here. This section allows you to choose Hosts or Networks (CIDRs) for which traffic in Suricata should be ignored. 

The usage of capture filters greatly increase the performance of Suricata as traffic is ignored at a much lower level, saving Suricata from having to deal with traffic we do not want analyzed. 

Ruleset Sources

Again, a feature that is kept very close to standard Suricata usage. Ruleset Sources allows you to interact with the configuration of suricata-update, the standard way of managing the creation of rule files and rulesets.

This feature in Lawmaker was created based on the documentation for suricata-update and implements the same functionality, being limited, currently, to only allowing remote sources (URLs of rulesets).

Multi-tenancy

Multi-tenancy, with a twist. One of our favorite features of Lawmaker is the capability of managing different deployments across different clients with different needs. Lawmaker implements this feature by having an underlying multi-tenancy architecture that segregates all of the previously mentioned configuration items in it's own storage and limiting access only within the tenant itself.

Wait, what's the twist then? That'd be Guest Accounts.

Guest Accounts

Guest accounts are a feature that we're extremely happy we were able to put together. It basically gives tenant administrators the capability of creating a guest account that is associated, and isolated, within a single tenant. 

Often companies will have their own security or infrastructure teams. Having a system that is fully managed by an MSSP and still provide a way for the client to create its own conditions or, at a bare minimum, have the capability of seeing what is in place for their IDS deployment, is something we saw as a major benefit of the multi-tenancy tied with the guest account.

lawmaker-agent

As you create your conditions and manage your ruleset in the web application, your sensors are going to need a way of interacting with the Lawmaker API to put those changes in place. lawmaker-agent is a Bash script, built only with standard tools of a Unix system, that is meant to run on your sensors. 

Create your API key in the web app and add it to lawmaker-agent. You're ready to go. The agent will guide you through everything you need to do. From that moment on, you're set!

Because it's built around standard Unix tools, there is no external dependencies and the fact that it is a script allows you to see everything that is happening on your systems.

Lawmaker sneak peek

Early Access

If the idea behind Lawmaker is something that interests you and you'd like to help us out by testing the platform before we open registration to the public, we'd love to set you up with an early access account. 

During the Early Access period the testing accounts will have unlimited access to the application and anyone that submits bugs in the application will be entitled to some heavy discounts on the PRO features when we open up. 

The signup form for the Early Access is available here. We'll review your request and get back to you with further information. We do not guarantee that all submissions will receive an account, as we plan on actively interacting with the users and we're limited by how many users we can do that with, during this stage.  

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