Your friendly neighborhood AppSec advisor and honeypot enthusiast. Formerly @ Goldman Sachs and Ernst & Young. Find his thoughts in code form committed to Github.
There are numerous ways to monitor attack and anomaly activity with Signal Sciences. Integrating with third-party tools like Slack, PagerDuty, or Datadog is an effective way to receive alerts on the events you care about the most (more on Signal Sciences integrations). In addition, visually, the Signal Sciences dashboards provide a clear picture of offending traffic, which makes it easy to spot events of interest.
Lastly, Signal Sciences has a rich API that enables you to download and ingest data into any SIEM or monitoring solution you prefer (for reference, video tutorial on this). All of the options mentioned above are great solutions for active monitoring, however what if you preferred a more passive method of monitoring?
One way to passively monitor for events is with sound. If you can imagine, as you go about your busy day, hearing recognizable tones emitting from your computer that indicate your web site is under attack. Perhaps among these tones are sounds representing blocked requests, which tell you the attack attempts are being blocked. Without gleaning events from a dashboard or receiving alerts, you’re now aware of events you care about and can decided to investigate further or not.
Signal Sciences Sounds
To experiment with the concept of audible monitoring I wrote a program I call sigsci-sounds. It is a Golang application and it is available on Github here: https://github.com/foospidy/sigsci-sounds. As an initial release, the implementation is really very simple. It calls the Signal Sciences API (timeseries endpoint) to retrieve attack and anomaly events over a period of time, and will play a sound for each type of event.
Quick disclaimer: I consider this approach of passive audible monitoring to be very experimental, and it should not be your only or primary means of monitoring security events for your web site. You should establish processes for active monitoring with the options described above, e.g. integrations, visually, and SIEM solutions.
A bit more detail…
When executed, the program reads from a configuration file where you can specify which events you want to monitor, and which sounds to play. To play sound files, sigsci-sounds is just making a system call to another progam to play the specified sound. In this initial release there are two options. First, specifying the full path to an .aiff or .mp3 sound file, the afplay command will be called to play the sound file. The second option actually leverages the say command in OS X. With this option you can specify text to be spoken for each event.
Note: the initial release was built and tested on OS X, and is coded to use OS X commands.
Next, it will retrieve the last 10 minutes of data and enumerate through the data to play the sounds that correspond with the event type. It will then sleep for 10 minutes before calling the API again to retrieve the next batch of data. Below is an example JSON snippet from the timeseries API endpoint. Sigsci-sounds iterates through the values in the “data” field, which is an array of event counts per minute. The configured sound will play once for each minute if the value is greater than zero. For the example below the sound for XSS will play 8 times. This process will repeat itself until you terminate the program.
The Signal Sciences API opens up opportunities to create interesting integration and automation solutions for managing the security of your web site. Audible monitoring with a utility like sigsci-sounds is a simple, and perhaps fun, example of this. For existing Signal Sciences customers, I invite you to give sigsci-sounds a try and experiment with it. At minimum, sigsci-sounds is a reference implementation that can help you get started on your own ideas on how to leverage the Signal Sciences APIs.