Architecture

The Signal Sciences platform is an application security monitoring system that proactively monitors for malicious and anomalous web traffic directed at your web servers. The system is comprised of three key components:

• A web server integration module
• A monitoring agent
• Our cloud-hosted collection and analysis system

The module is the architecture component that is responsible for directly interacting with requests. It listens for incoming requests and passes them to the agent for a decision. After receiving a decision from the agent, the module will block, allow, or tag requests in accordance with that decision. The module can exist as a plugin to the web server or a language specific implementation.

The agent decides whether to block, allow, or tag requests. When it receives a request from the module, it runs through the rules set up and decides how the request should be handled. The agent then relays the request and its decision back to the module. The agent is also responsible for relaying with the cloud-hosted collection and analysis system; uploading processed request data and downloading new rules and configurations set up in the console.

The cloud-hosted collection and analysis system receives data from the agent and other sources. This includes request data, IP address information, and agent/module performance metrics. This information is then exported and made visible in the Signal Sciences console, through the API, and any third-party integrations you have set up.

What language is the agent written in?

The agent is written in Go. We chose Go because of its combination of performance, ease of deployment, and memory safety guarantees. In other words, it gets very close to native code performance, without the security issues associated with C/C++ (e.g., buffer overflows).

Where is it typically deployed?

Our software is typically installed directly on your web server. It can also be deployed on a reverse proxy or load balancer running Apache/NGINX. Another less common but technically viable approach is to deploy our software at the application layer. We currently provide modules for Node.js, Java, and .NET and can supply documentation to help you write an application layer module in other languages.

Where are you hosting the service?

We are hosting the service in AWS West across multiple availability zones.

What does Signal Sciences need firewall access to?

To download and install Signal Sciences, you will need to ensure your firewall allows access to the following:

• apt.signalsciences.net
• yum.signalsciences.net
• dl.signalsciences.net

The Signal Sciences agent communicates with the following endpoints outbound via port 443/TCP:

• c.signalsciences.net
• wafconf.signalsciences.net
• sigsci-agent-wafconf.s3.amazonaws.com
• sigsci-agent-wafconf-us-west-2.s3.amazonaws.com

If the agent is unable to download from the Fastly CDN, it will fall back to downloading directly from an S3 bucket with an additional fallback to a secondary bucket in a second region until it can download from the CDN or primary S3 bucket again.

What sort of scale do you support?

Our architecture allows us to support applications with high traffic volume. We are deployed across full production with companies in the top 50 of the Alexa Traffic Rankings.

Do you support configuration management?

Yes, we support Chef, Puppet, Ansible, and others. It's easy to manage typical deployments with configuration management tools.

Do you support CDNs?

Yes, we can consume the X-Forwarded-For or any other header to obtain the true client IP address.

Do you support egress HTTP proxies?

Yes, instructions for configuring the Signal Sciences agent to use a proxy for egress traffic can be found here.

Do you have an API?

Yes, we have a fully documented, RESTful/JSON API so you can pull your Signal Sciences console data into your other systems.

Do you support integrations with SIEMs?

Yes, we support any SIEM via our API.