Skip to main content

Lawmaker UI/UX Improvements & Device Health

 


Over the last few weeks we've been working on improving the user interface of Lawmaker with the intent of making it easier and faster for our users to do their work as well as make the experience more enjoyable. 

In this post we will go over those features in more detail. 

User Menu

In the previous versions of Lawmaker, under some contexts, it wasn't always clear what options were tenant-specific (like the API key) and which options were part of the user account, as they were both listed under Settings. 
 
We've changed that by including a user menu where all user-specific options will be listed, with the added bonus of leaving the sidebar less crowded.


The option "My Account" now holds only account-related settings, such as managing your password and subscription.

Dark Mode

Undoubtedly one of the most anticipated features of Lawmaker UI was the inclusion of a dark theme. This option is now available in the User Menu and we're extremely excited you get to start using it.

Notices

We understand the importance of communicating changes or problems in Lawmaker, even though we, technically and purposely, have no way to mass-email our users. Starting today there will be a notice information popup close to the User Menu.
 

This allows us to effectively get our message across in a passive and non-intrusive matter.

lawmaker-agent

Not only the "LM Agent" page in Lawmaker but also the actual agent have been updated for this release.
 
Going forward the API Key that allows your sensors to retrieve the files from Lawmaker will no longer be in the Settings page, as those are now completely account-specific, and instead, the API Key is listed (and manageable) in the LM Agent page itself:
 

 
With this change you now have all the information to learn about, deploy, configure and manage lawmaker-agent in a single page.

Device Health Dashboard

While we've tweeted about it this feature is worth a lot more than 280 characters. 

While the focus of Lawmaker was, and still is, the management of rules and the tasks that usually go into managing an NIDS (or several) deployments at scale, we felt that adding some monitoring capabilities to the platform would go a long way into making the life of operators a lot easier. 

We released the Device Health dashboard in a previous sprint and today we're adding more functionalities to it.


After upgrading lawmaker-agent, and if you opt-in to Device Health, we'll list information about the sensors (rules loaded, last reload time, last connection to Lawmaker API, etc) but also provide you with additional sensor logs such as lawmaker-agent execution output, Suricata service status and the Suricata start log.


It is important that your sensors are running an updated version of lawmaker-agent for these changes to appear in your account.

Duplicate SID messages

Another improvement that was added to this release is how we display the signature name when there are several matches. 

If a SID has more than 1 match, for example in the Emerging Threats improved ruleset for Suricata 5.0.0 and the ruleset for previous versions of Suricata, we will now display both matches:
 
 
We generate the identifiers (what you see when browsing Lawmaker and creating the conditions) from as many rulesets as possible. While we don't have control over the usage of SIDs we believe this option is the best fit for doing this in a way that we don't leave out any SIDs, even if a SID collision happens.

Replicate Condition

In today's release we've added an option to leave the wizard option open so that you can more easily make adjustments between creating similar conditions:

 
And that's it for this update!
 
As always, make sure you're following us on Twitter to keep up to date with what we're doing and feel free to join our Community Slack.

We'd love to hear what you think about these changes or if there's something we could be doing better in Lawmaker.

Don't forget that if you're a school, training provider or security researcher, you can use Lawmaker for FREE! Reach out to us to know more.
Labels:

Popular posts from this blog

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 decept...
Read more

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 litt...
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