Glossary
Last updated 2023-05-05
| Term | Definition |
|---|---|
| Admin | A user role that has limited access to corp configurations, can edit specific sites, and can invite users to sites. |
| Agent | One of the main components of the Signal Sciences architecture. The agent receives requests from modules and quickly decides whether those requests contain attacks or not. The agent then passes their decision back to the module. |
| Agent alerts | Custom alerts that trigger notifications whenever: - The average number of requests per second (RPS) for all agents across all sites reaches a user-specified threshold - The number of online agents reaches a user-specified threshold. |
| Agent mode | Determines whether to block requests, not block requests, or entirely disable request processing. |
| Allow | An agent decision to allow a request through. |
| Anomalies | Abnormal requests that, although not attacks, may still be notable. Examples include malformed request data and requests originating from known scanners. |
| API access tokens | Permanent tokens used to access the Signal Sciences API. Users can connect to the API using their email and access token. |
| Attacks | Malicious requests containing attack payloads designed to hack, destroy, disable, steal, gain unauthorized access, and otherwise take harmful actions against a corp’s sites. |
| Audit log | An audit of activity, changes, and updates made to a site or corp. |
| Blocking | An agent mode that blocks subsequent attacks from a flagged IP address after it has been identified as malicious. Blocking mode still allows legitimate traffic through if the requests do not contain attacks. |
| Cards | Visual charts of data that can be monitored and customized on site dashboards. |
| Cloud engine | One of the main components of the Signal Sciences architecture. The cloud engine collects metadata to help improve agent detections and decisions. |
| Configurations | A set of features that users can customize to meet their business needs. Configurations include: rules, lists, signals, alerts, integrations, site settings, and user management. |
| Corp (Corporation) | A company hub for monitoring all site activity and managing all sites, users, and corp configurations. Users are authenticated against a corp and can be members of different sites in that corp. |
| Dashboards | The corp and site homepages. The site dashboard gives visibility into specific types of attacks and anomalies. The corp dashboard gives a snapshot of all top site activity including which sites have the most attack requests, blocked requests, and flagged IP addresses. |
| #about-the-events-page) | Actions that Signal Sciences takes as the result of regular threshold-based blocking, templated rules, site alerts, and rate limit rules. This includes any occurrence that happens on the Events page, such as a flagged IP address. Events are automatically system generated. |
| Flagged IP addresses | An IP address that has been flagged for exceeding thresholds. |
| Header links | External data like Splunk or Kibana that connects with request data from Signal Sciences. |
| Integrations | DevOps toolchain apps that send activity notifications to users. Examples include Slack, Datadog, PagerDuty, mailing lists, and generic webhooks. |
| IP Anonymization | IP addresses are converted to anonymous IPv6 addresses so that Signal Sciences will not know the actual IP address, which causes the IP address to appear anonymous in the dashboard. |
| Lists | Sets of custom data used in corp and site rules, such as a list of countries a corp doesn't do business with. Lists include sets of countries, IP addresses, strings, and wildcards. |
| Log | In not blocking mode, requests that would have been blocked are logged and allowed to pass through instead. |
| Module | One of the main components of the Signal Sciences architecture. The module receives and passes requests to the agent. It then enforces the agent's decisions to either allow, log, or block those requests. |
| Monitor | To observe and keep watch over corp and site events. |
| Monitor view | The site dashboard in a TV-friendly format. |
| Not blocking | The default agent mode. In this mode, attacks are logged but not blocked and the site is not actively protected. |
| Notification | Any product message sent internally or externally. External notifications are sent through integrations when activity happens (e.g., a Slack notification is sent when a new site is created). |
| Observer | A user role that can view sites they are assigned to, but cannot edit any configurations. |
| Off | An agent mode that stops sending traffic to Signal Sciences and disables all request processing. |
| Owner | A user role that has access to all corp configurations, can edit every site, and can manage users. |
| Rate limit rule | A type of rule that allows you to use the Advanced Rate Limiting feature to define arbitrary conditions and automatically begin to block or tag requests that pass a user-defined threshold. |
| Redactions | Sensitive data that is not sent to the Signal Sciences backend for privacy reasons. Signal Sciences redacts some sensitive data by default, such as credit card numbers and social security numbers. In addition to the default redactions, users can specify their own custom redactions. |
| Request rule | A type of rule that allows you to define arbitrary conditions to block, allow, or tag requests. |
| Requests | Information that is sent from the client to the server over the hypertext transfer protocol (HTTP). Signal Sciences protects over a trillion production requests per month. |
| Response time | The amount of time between when a request was received by the server and when the server generated a response. |
| Role | Every user is assigned one role: owner, admin, user, or observer. |
| Rules | A configuration that defines conditions to block, allow, or tag requests or exclude built-in signals. |
| Sampling | The act of taking a random sample of certain types of requests to be stored and available in the console. |
| Signal | A descriptive tag about a request. |
| Signal exclusion rule | A type of rule that allows you to define arbitrary conditions to exclude a specific system signal (such as XSS). |
| Signal Sciences | The overall platform that protects a corp's sites. |
| Site (Workspace) | A single web application, bundle of web applications, API, or microservice that Signal Sciences can protect from attacks. Users can monitor events, set up blocking mode to block attacks, and create custom configurations on sites. |
| Site alerts | A custom alert that allows users to define thresholds for when to flag, block, or log an IP address. |
| Suspicious IP addresses | IP addresses that are approaching thresholds, but have not yet met or exceeded them. |
| Templated rule | A type of partially pre-constructed rule that, when filled out, allows you to block, allow, or tag certain types of requests. |
| Thresholds | A limit either set by Signal Sciences or custom set by users that must be exceeded for a certain event to happen. For example, suspicious IP addresses must exceed a certain threshold to become flagged. |
| User (role) | A user role that can edit site configurations on sites they are assigned to. |
| Users | All of the people who manage, edit, or just observe activity. A user belongs to a particular corp and is identified by an email address and password. A user can be a member of one or more sites. |
| Virtual Patch | A virtual patch prevents attacks of a known vulnerability in a module or framework by not allowing the attacks to reach the web app. This buys time to fix the underlying vulnerability while the virtual patch is protecting the app. |
Do not use this form to send sensitive information. If you need assistance, contact support. This form is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.