No more forgotten servers!

I’ve been asked quite a few times where the idea for scarlet came from, and as so often with this kind of thing, the answer is that it was born out of necessity: there simply wasn’t the tooling available to do what I needed to do.

I’d noticed a common theme across various clients that I was consulting for: that the simplicity and ease that comes with using the cloud can be a double-edged sword. My clients typically had teams split over multiple time-zones, they relied heavily on deployment automation tools (like Terraform), and also used a lot of auto-scaling technologies (like Kubernetes).

Their cloud environments were literally changing minute-to-minute. Which made keeping track of what they had a bit of a nightmare. Let alone trying to secure it.

Added to this was that the larger organisations also seemed to have a challenge dealing with the proliferation of cloud vendors. Different suppliers and teams would choose what they liked best, or they’d buy an organisation, who were built on a different cloud.  Some organisations had literally hundreds of cloud-vendor accounts to manage!

When it came to tackling the problem, the different roles that were responsible for managing this cloud infrastructure also had very different requirements:

• The DevOps team needed to keep track of what they had in near real-time, so that they could get visibility of assets starting and stopping, ports opening, or TLS certificates getting close to expiry. For example, it was far too easy for someone to use Terraform to run up a new test environment, then forget about it (running up thousands of dollars in unnecessary costs). They wanted to become proactive to changes, not reactive to complaints. On top of this, they also didn’t want yet another dashboard to monitor: they were looking for alerts to be sent to a group-chat channel, where they already spent much of their time.

• The security blue-team needed to automate the basics of asset discovery, incident response and vulnerability scanning, so that they could focus on the critical, people-centric parts of the job. They were finding that static lists of assets were next to useless in an environment that changes minute-to-minute. And like the DevOps team, they also didn’t want another product to manage, but instead were looking to leverage their existing investment in SIEM and VM platforms.

When we evaluated the existing products for managing the cloud, we found that there was nothing that matched their needs.

Most of the existing tools were part of a larger, enterprise-management product, which was prohibitively expensive, required extensive configuration, or worse, agents to be installed everywhere (which is a bit like painting the Forth Bridge). And on top of this, the tools typically only supported the big-three cloud platforms: Amazon AWS, Microsoft Azure and Google GCP. Many organisations also have cloud vendor accounts with one of the other providers, like IBM Cloud, DigitalOcean or Alibaba Cloud, so the existing tools only offer partial coverage.

scarlet was built to address these challenges, and enable DevOps and security blue-teams to quickly automate a response to their ever-changing cloud infrastructure. So, if your organisation has a multi-cloud infrastructure, wants to respond to changes in real-time, and doesn’t want to pay the earth for the privilege, then you know where to come. [grin]