Getting started with scarlet

If you’re wondering what to do next, then you’ve come to the right place!

This guide is to help you get the best out of evaluating and using scarlet, and to make sure you’re not overwhelmed with choices or the volume of events.

 

Proof of Concept (POC) Options

We think that scarlet is so ridiculously simple to setup, and the results are so easy to use within your existing workflows, that the best way to evaluate it is to simply integrate it with your production systems.

That may be a bit much to stomach for some organisations though, so we also have a couple of suggestions as alternatives:

• If you’d like to see live data in real-time, but just not on your production systems, we’d suggest signing up for a free-tier Microsoft Azure account, and creating some representative assets, plus a Microsoft Sentinel instance, then plugging them all into scarlet.

• However, if you’d just like to see scarlet in action, and don’t want to do any configuration at this stage, then feel free to contact support@scarlet.ae and we’ll be happy to organise a demonstration walk-through.

But if you’re ready to start setting up scarlet now, then the rest of this guide is for you!

 

Destinations

The first thing to do is to make sure that you have some destinations configured for the events that scarlet will generate for you.

SIEM

Your SIEM is a great place to send events from scarlet. For example, if your team is responding to an incident, wouldn’t it be useful to pinpoint when an environment was deployed, and a vulnerability was first introduced? Or would you like to be able to quickly see which other applications share the same infrastructure, so that a realistic blast-radius can be established? For SIEM, scarlet currently supports Elasticsearch, Sentinel and Splunk. Simply add the API credentials, and scarlet will forward events in near real-time.

Wiki

Keeping your systems documentation up-to-date is often a laborious, manual task. Luckily, scarlet makes it effortless. For wiki, scarlet currently supports Confluence (with Sharepoint coming soon). Just add the wiki API credentials to scarlet, and it’ll automatically generate, then update your documentation if anything changes. What could be easier than that?

Vulnerability Management

For Vulnerability Management, scarlet currently supports Qualys, and will soon also support Tenable and Rapid7 too. Most of the vulnerability management platforms already have integrations available to allow you to import assets from the main cloud providers (like Amazon, Google and Azure). But you may have noticed that the results can be a bit patchy, with some technologies being missed out (like containers, functions, load balancers, and IPv6 addresses etc). scarlet plugs these gaps, and seamlessly synchronises your attack surface with your vulnerability management tools. It also renames and tags the assets with clear descriptions, which makes finding asset owners and getting issues fixed a whole lot easier.

ChatOps

It is now common for teams to use ChatOps as way to monitor and control the development and deployment lifecycle. scarlet makes it easy to add a feedback loop to this process, so that when the DevOps team deploys a new environment, they can see the new systems being created, and applications being deployed, as it happens. Using this approach, it is really easy to see if something failed, was deployed incorrectly, or maybe didn’t get torn-down automatically afterwards when it was supposed to.

For ChatOps and general messaging, scarlet supports Slack, Teams and Discord. Unfortunately though, all of these platforms rate-limit the volume of messages you can receive. And what is worse, once they start rate-limiting, they may silently drop messages, or deliver them out-of-order (which can be a bit confusing).

To avoid this, we’d recommend that you create a couple of channels for receiving scarlet events. One channel for the audit trail generated by scarlet itself (such as when people login to the portal, or change the configuration), and a second channel for tracking changes to the assets. If you have less than a hundred assets in total, then you’ll probably get away with sending all the available event types to a single channel without being rate-limited. However, for larger environments we’d recommend selecting only the essential event categories: just Assets, or maybe Assets and Ports at a stretch.

When you click on the Add Destination box for one of the ChatOps destinations, you’ll see a dialog a bit like the following.

Scarlet lets you choose which event categories to send to a ChatOps destination:

• The event categories on the right in the picture above, labelled as Subscription, Configuration and Users, are all general scarlet events, and cover things like users signing-in, updates to the configuration etc.

• The Assets category is for events that are generated due to changes in the IP addresses, domain names and URIs that scarlet is monitoring.

• The Ports category is for state changes in the ports that are attached to assets (such as when a firewall changes, and a new port opens up).

• The Services category is for events that are sent when the system that is listening on a port changes (like when an X.509 certificate is renewed).

 

Sources

Once you have your destinations configured, you can add some sources to scarlet. These are currently all cloud platforms, but we have support for the common firewalls in development, which will soon allow us to cover the hybrid environments too.

 

What next?

scarlet was designed from the outset to use the most efficient, most non-intrusive ways to detect changes to your attack surface. It does though send a bunch of packets to your assets, and these may be picked up and flagged by your security tools.

To exclude the scarlet platforms from these alerts, you can add the scanner.scarlet.ae domain to your tools (usually in an ignore or alert suppression list).