New Event Timeline Helps Teams See Detailed Insights Into Blocked Attacks

Here at Signal Sciences, our Product and Technology teams adhere to three core product principles for our next-gen WAF: Data Insights, Ease of Use, and Visibility. These principles ensure we’re designing and building the right product to solve our customers’ issues and needs to protect their web apps and APIs. (Note, too, that our Technology Group encompasses Engineering, Product and Support – a trio that together work to provide and uphold a strong customer-centric experience).

Today, we’re going to cover all three as we unveil Timeline, our new feature that gives you the distilled picture of the beginning, middle, and end of a blocked attack.

Condensing Data into Concise, Actionable Insights

If you follow Signal Sciences and recall our founding story, we lived in the trenches as CISOs, CTOs, and product owners when facing the problems of protecting our web apps and APIs. To get a good picture of what was going on against our apps, we’d have to open a number of browser tabs – one into our SIEM system, one into our web logs, and so on — just to piece together a rough sketch (see Image 1). The WAFs we were using didn’t provide a whole lot of details into the alerts they fired — but just indicated that something triggered a signature. There wasn’t a “jumping off point” to start further investigations.

Logs: the old way

Image 1.

That’s exactly why we set out to provide this curated event timeline. Our customers can see a simple story of an attack on one page without having to build their narrative themselves. We show in one view the details of the attack, what happened, what was blocked, what signal was involved, and the origin of the the attack (see: image 2).

Timeline: the New Way

Image 2.

Let’s break down the components of our Timeline:

Details of the attack

Timeline shows you the summary, with links to dig right into the details. No more “blocked: security policy” vague alerts. Our details are unrivaled in the industry – and turn a security product into a developer tool.

Where the attack came from

See the country of origin of the malicious IP.

What signal was involved

Signal Sciences provides many out-of-the box signals that immediately populate in our Console’s Dashboards – attack signals like attack tooling, SQLi, command execution, and many others. You can also create your own signals for pretty much anything you like – mapping particular API endpoints, large response sizes and times, and so on. In our Timeline feed, we show which signals triggered the event and action.

What triggered the event

Rather than wondering what actions took place, we show in the singular Timeline view what Signal Sciences action was. We’ll show how many requests from a given source we saw to trigger an event, causing a “flagged” IP.

What actions Signal Sciences took

We take a lot of pride in the fact that 95% of Signal Sciences customers run our product in blocking mode for their production sites. By showing the explicit action we took via the attack signal and origin details, we gain confidence from the user to use us in blocking mode. Depending on your preferences, we can show that we logged or blocked subsequent requests from a flagged source.

Current Status

Many alert systems leave teams wondering, “Is this attack still going on?” We answer definitively by showing “Blocking Active Event” or “Flag Expired.”

Different status explanations provide clear details

Now here’s where we crank things up

We’re constantly feeding this type of anonymized event data into our intelligent,decision making algorithms in our Cloud Engine to form unique insights (see Image 3). This means when malicious traffic we’ve seen elsewhere on our network makes its way to your site, we tell you. More announcements around these exclusive insights coming soon!

Signal Sciences alerts you to malicious activity we’ve seen elsewhere in our network with a “Signal Sciences Network” signal.

Image 3.