Announcements

Announcing gRPC proxy deployments

The Next-Gen WAF agent can now act as a proxy for gRPC traffic to allow inspection of protobuf-based gRPC messages (Content-Type: application/grpc). For more information, check out our Configuring gRPC proxy deployments guide.

Next-Gen WAF core command line utility

The new Next-Gen WAF core command line utility (ngwafctl) is a tool that compiles information about your Next-Gen WAF core installation within your Kubernetes environment and cloud provider. The tool can perform basic troubleshooting and generate a support bundle containing logs and deployment specification details. You can use the utility to help troubleshoot issues with your Kubernetes Next-Gen WAF integration and can optionally send the generated support bundle TAR.GZ file to our Support team for additional help.

Unified Fastly and Signal Sciences Login Experience

Fastly is excited to announce the launch of a unified login experience across Fastly and Signal Sciences consoles. The new experience will make it simpler and easier for you to access Fastly products and services using a single set of login credentials. For more information, check out our complete feature announcement.

Upcoming session timeout standardization

To help you increase your security posture on the Fastly platform, starting Q1 2024 all users will be logged out after 30 minutes of inactivity. Session timeouts will also have a default maximum of 12 hours for any organization that hasn't set up single sign-on. If your session timeout was previously set to greater than 12 hours, it will be reduced to 12 hours, and any timeout setting less than 12 hours will remain as is. The minimum timeout for sessions will be 30 minutes.

Protection from CVE-2023-50164 (Apache Struts directory traversal)

A directory traversal vulnerability within file uploads has been found in Apache Struts and has been assigned CVE-2023-50164. Fastly has created a virtual patch for it that is now available within your account. To activate it and add protection to your services:

1. Log in to the Next-Gen WAF console.
2. From the Sites menu, select a site if you have more than one site.
3. From the Rules menu, select Templated Rules.
4. In the search bar, enter CVE-2023-50164 and then click View for the CVE-2023-50164 templated rule.
5. Click Configure and then Add trigger.
6. Select the Block requests from an IP immediately if the CVE-2023-50164 signal is observed checkbox.
7. Click Update rule.

Site alert management

System site alerts monitor and handle requests from IP addresses that have been tagged with attack signals by placing a cap on the number of requests that can originate from the same IP address and that contain attack signals. The default caps or thresholds are based on historical patterns that we've seen across all customers. Now, you can raise or lower the attack thresholds via our web interface and API. For example, you can block all requests that contain at least one attack signal by setting the attack thresholds to 1. This functionality is available for all Next-Gen WAF customers.

We've also improved threshold counting for site alerts. Previously, only the cloud engine handled threshold counting. This meant that the Next-Gen WAF agent had to wait for the cloud engine to tell it when an IP address was flagged. Now, the agent has local counters and is immediately able to determine when a request exceeds a site alert. The agent still uses aggregation from the cloud engine when there are multiple agents deployed. Only Core and Cloud WAF deployments support local counters.

New Anomaly Signal: OOB-DOMAIN

We have introduced an anomaly signal (OOB-DOMAIN) that allows you to detect when known out-of-band domains are observed within a client request. Out-of-Band domains are generally used during penetration testing to identify vulnerabilities in which network access is allowed. Want to learn more? For full descriptions of this and all other system signals, check out our system signals documentation.

Announcing Next-Gen WAF Simulator

We are excited to announce the availability of the Next-Gen WAF Simulator, which allows you to pass sample requests and responses to help with debugging and testing rule creation logic. The Simulator helps you identify whether requests would be blocked or allowed and shows what the WAF would return as response codes for those requests, as well as the signals that would be added. Access the Next-Gen WAF Simulator by selecting Simulator from your site's Rules menu.

Agent management functionality (GA)

We previously announced a beta release of expanded agent management functionality which included a service that automatically updates agent versions and a plugin for HashiCorp Vault that stores and rotates agent keys. These features are now available for all Next-Gen WAF customers.

Protection from CVE-2023-38218 (insecure direct object reference)

An insecure direct object reference (IDOR) vulnerability has been found in Adobe Commerce and Magento Open Source and has been assigned CVE-2023-38218. Fastly has created a virtual patch for it that is now available within your account. To activate it and add protection to your services:

1. Log in to the Next-Gen WAF console.
2. From the Sites menu, select a site if you have more than one site.
3. From the Rules menu, select Templated Rules.
4. In the search bar, enter CVE-2023-38218 and then click View for the CVE-2023-38218 templated rule.
5. Click Configure and then Add trigger.
6. Select the Block requests from an IP immediately if the CVE-2023-38218 signal is observed checkbox.
7. Click Update rule.

New rule condition operators available

You can now use the greater than or equal to and less than or equal to operators when defining rule conditions. This can be helpful when creating rules such as checking if the response code was greater than or equal to or less than or equal to a specific response code range and much more.

Attack signal thresholds are now aggregated

System site alerts monitor and flag IP addresses that exhibit repeat malicious behavior and then block or log subsequent malicious requests from the flagged IP addresses. Previously, flagging occurred when the number of requests that were tagged with the same attack signal and that were from the same IP address reached one of our thresholds. Now, attack signals are counted in aggregate instead of per-signal, meaning that even if attackers rotate their attacks, the total number of requests with attack signals will count towards the thresholds.

This change only applies to the default thresholds for attack signals. It does not affect any attack signals that have had their thresholds adjusted through custom site alerts or are being used in instant blocking rules.

Protection from CVE-2023-34362 (MOVEit Transfer Critical SQL Injection Vulnerability)

A SQL injection vulnerability has been found in the Progress MOVEit Transfer web application and has been assigned CVE-2023-34362 (also known as MOVEit Transfer Critical SQL Injection Vulnerability). Fastly has created a virtual patch for it that is now available within your account. To activate it and add protection to your services:

1. Log in to the Next-Gen WAF console.
2. From the Sites menu, select a site if you have more than one site.
3. From the Rules menu, select Templated Rules.
4. In the search bar, enter CVE-2023-34362 and then click View for the CVE-2023-34362 templated rule.
5. Click Configure.
6. Click Add trigger and select the Block requests from an IP immediately if the CVE-2023-34362 signal is observed checkbox.
7. Click Update rule.

Edge deployment now available for the Premier platform

Advanced rate limiting rules and the Site Flagged IP signal have been added for Premier plan customers using edge deployment. Customers who have upgraded from the Professional plan to the Premier plan will now be able to author new site rules that rate limit requests. The Site Flagged IP signal will also be available for use in all types of site rules.

Check out the details about edge deployment and about advanced rate limiting rules to learn more.

Edge deployment setup changes

The setup process for the edge deployment has been changed from custom VCL to dynamic VCL snippets. This change is expected to simplify the onboarding process for all customers using the edge deployment. In particular, if you are using custom VCL for other features of the delivery platform, your setup will become simpler.

This setup change to dynamic VCL snippets applies to new Signal Sciences Corps using the edge deployment and the Edge Deployment documentation has been updated accordingly.

IMPORTANT: Existing edge-deployed sites require a backend configuration change to begin using VCL snippets. Without the configuration change, custom VCL will continue to be used. If you would like to switch to using VCL snippets for your corp and sites reach out to support@fastly.com.

Custom response codes

We've expanded the functionality of our custom response codes feature. Custom response codes allow you to specify the HTTP status code that is returned when a request to your web application is blocked.

Specifically, you can now change the site default blocking response code from 406 to an alternative response code. Blocking actions use the site default blocking response code unless a different response code is specified in a rule.

We also now support the 301 and 302 custom response codes and allow you to specify a redirect URL.

Advanced rate limiting user experience

We've updated the advanced rate limiting user workflow to simplify rate limiting rule configuration. Advanced rate limiting rules put a cap on how often an individual client can send requests that meet set conditions before some or all of the requests from that same client are blocked or logged.

Specifically, the Add form for advanced rate limiting rules has been redesigned. It now includes the Match type field. With this field, you can define which requests from the client should be blocked or logged after the threshold has been passed. Options include:

• Rule conditions: rate limit requests from the client that match the rule's conditions.
• Other signal: rate limit requests from the client that are tagged with a specific signal.
• All requests: rate limit all requests from the client.

We've updated and expanded several other areas of the Add form as well. Specifically:

• The Actions section now has two subsections: Tracking and Rate Limiting. In the Tracking section, you specify a signal that should be applied to requests that meet the rule's condition set and define the threshold. In the Rate limiting section, you define how a client that exceeds the threshold should be rate limited.

• The Counting signal field has been renamed to the Threshold signal.

• Action type menu options have been renamed from Log request and Block signal to Log and Block.

Finally, you can use the new ratelimited field to search for requests that have been tagged with a specific threshold signal and that have been rate limited.

PHP and Python modules are now open source

As announced, today marks the start of the self-service model for the PHP and Python modules. These modules now have a public-only development workflow. You may continue to use the modules at your own discretion but Fastly will not update or provide technical support for the modules.

Agent management functionality (Beta)

We've expanded our agent management functionality to include:

• a service that automatically updates agent versions.
• a plugin for HashiCorp Vault that stores and rotates agent keys.

When the agent auto-update service is enabled, the service checks the Signal Sciences package downloads site for a new version of the agent and updates the agent when a new version is available. By default, the check for a new version is performed on the second Thursday of the month. The agent auto-update service is only compatible with agents on Debian 8 or higher, Red Hat CentOS 7 or higher, and Ubuntu 18.04 or higher.

With the Signal Sciences plugin for HashiCorp Vault, you can use Vault to store and rotate the Agent Access Key and Agent Secret Key for your site. Vault is an identity-based secrets and encryption management system.

These features are now available for all Signal Sciences customers as part of a beta release.

Professional Plan Edge Deployment Updates

Custom signals, dashboards, lists, templated rules, and custom response codes are now available for Professional plan customers using edge deployment. Customers who have upgraded from the Essential plan to the Professional plan will find that some features now appear in different locations. Specifically:

• Virtual patching (CVE) rules can be found in the Templated Rules menu.
• Threshold functionality can be found in the Rules menu under Site Alerts.

The edge security service includes a health check inside the edge_security function. Using the backend.health property, this health check will skip security processing entirely if the edge security service is unhealthy for any reason. The edge security service is modeled as an origin using the backend type and uses the same health check feature.

Learn more about the edge deployment by visiting our documentation site.

Protection from CVE-2022-42889 (Text4Shell)

A code execution vulnerability affecting the Apache Commons Text library has recently been identified and assigned CVE-2022-42889 (also known as Text4Shell). Fastly has created a virtual patch for it that is now available within your account. To activate it and add protection to your services:

1. Navigate to the Signal Sciences console and select Templated Rules from the Rules menu.
2. Search the templated rules for CVE-2022-42889 and then click View.
3. Click Configure and then click Add trigger to configure the rule's thresholds and actions.
4. Select Block requests from an IP immediately if the CVE-2022-42889 signal is observed and then click Update rule.

Protection from CVE-2021-44228 (Log4Shell)

SmartParse has been extended to allow for advanced and precise detection of CVE-2021-44228 (also known as Log4Shell) payload attacks with minimal-to-no false positives. SmartParse is our proprietary detection method that analyzes request parameters to determine whether code is actually executable. It requires no manual tuning or configuration because it does not rely on ever-expanding regex pattern matching.

When SmartParse detects Log4Shell attacks, the requests are tagged with the new LOG4J-JNDI attack signal. You should begin seeing requests that match this signal in your requests feed immediately. We've enabled it by default along with default threshold rules. You can adjust these thresholds using site alerts or by creating an instant blocking rule.

To learn more about this new attack signal, check out our blog post.

Agent and module end-of-support plan

Beginning January 31, 2023, agent versions will enter a two year support cycle with versions older than two years being retired or deprecated on a quarterly cadence. Retiring older versions with fewer features will enable us to focus our resources on supporting and developing newer versions that provide more value to our customers. At the end of January, we will support Agent v4.16.0 and above.

Support for our Python and PHP modules will be moving to self-service in March 2023. At that time, you may continue to use the modules at your own discretion, but we will no longer update and provide technical support for the modules. Until the self-service transition occurs, we will fully support both modules. More information about this transition will be posted at a later date.

Reach out to your account manager or securitysupport@fastly.com if you have questions about how to upgrade your agent or about the modules' transition to a self-service model.

AWS Lambda Integration is now GA

We've expanded the Fastly Next-Gen WAF (powered by Signal Sciences) capabilities to include protection for serverless and FaaS traffic. Our support for AWS Lambda can help companies grow their web applications without requiring supporting infrastructure and provisioning servers. This support is now generally available to all Signal Sciences and Fastly Next-Gen WAF customers. For more information, see our install guide.

Additionally, we have received the AWS Service Ready designation for our Lambda support, which means our Fastly Next-Gen WAF has gone through full technical evaluations with the AWS team and has tight integration into the AWS marketplace. You can find us listed as an official AWS Lambda partner.

Enabling and disabling logging via the rule builder

We have introduced a new feature in the site and corp rule builder that allows you to select whether to store the logs for requests that match a rule's criteria.

Historically, when creating a custom site or corp rule without a custom signal attached, requests matching the rule's criteria would not be logged. Not logging matching requests reduced the potential noise in your request logs. In cases where you did want to store the logs for matching requests, you had to create a custom signal for the rule.

Now, you no longer have to create a custom signal to log requests that match a rule's criteria. The new Request Logging menu in the site and corp rule builder allows you to select whether matched requests are logged (data storage policy applies).

For new rules, logging is enabled by default, but you can disable logging for a rule by setting the Request Logging menu to None. Existing rules that have a custom signal will continue to log matching requests, and existing rules that do not have a custom signal will not log them.

Announcing the AWS Lambda Integration (Beta)

We're expanding the Fastly Next-Gen WAF (powered by Signal Sciences) capabilities to include protection for serverless and FaaS traffic. We now support AWS Lambda, which is helping companies grow their web applications without having to worry about supporting infrastructure and provisioning servers.

This feature is available now as part of a beta release and will require a configuration change to enable it via feature flag. It is available for all Signal Sciences and Fastly Next-Gen WAF customers, and you can learn how to set it up in our install guide.

Protection from CVE-2022-26134 (Unauthenticated RCE in Confluence)

A remote code execution vulnerability affecting the Atlassian Confluence product has recently been discovered and assigned the identifier CVE-2022-26134 (also known as Unauthenticated RCE in Confluence). Fastly has created a virtual patch for it that is now available within your account. To activate it and add protection to your services:

1. Navigate to the Signal Sciences console and select Templated Rules from the Rules menu.
2. Search the templated rules for CVE-2022-26134 and then click View.
3. Click Configure and then click Add trigger to configure the rule's thresholds and actions.
4. Select Block requests from an IP immediately if the CVE-2022-26134 signal is observed and then click Update rule.

Essential Plan Updates

Common Vulnerabilities and Exposures (CVE) signals are now supported for Essential plan customers to help protect you against known exploits and threats. The new functionality can be configured through the web interface from the Signals menu or through the templated rules section of the API.

We’ve also included a number of enhancements to the edge cloud deployment for the Fastly Next-Gen WAF: new APIs have been added for deprovisioning, origin syncing has been improved, and a percentage ramp up feature is now supported to control the amount of traffic through the edge security service. Learn more about this by visiting our documentation site.

Announcing Fastly Security Labs

We’re happy to announce the launch of Fastly Security Labs, a new program that empowers customers to continuously innovate by being the first to test new detection and security features — helping shape the future of security.

Fastly Security Labs provides our customers with an open line of communication directly to the Security Product team and bolsters our feedback loops that bring our customers directly into our product lifecycle process for the Fastly Next-Gen WAF (powered by Signal Sciences), helping us create stronger products. We’ll use the program to release a wide range of features from new Signals and Templated Rules to new inspection protocols. You can read more about it in our blog.

Announcing GraphQL Inspection

We are introducing a new GraphQL Inspection feature as a part of Fastly’s Next-Gen WAF (powered by Signal Sciences). With this addition, we can apply our current set of WAF detections to GraphQL requests, which include protection against OWASP-style attacks. The ability to inspect GraphQL requests means you can apply customs rules to specifically handle those requests. We’ve also added GraphQL-specific attack and anomaly Signals to address certain targeted attacks. With many common attack vectors at play in GraphQL, we've added new signals out of the box so that any specific routing can be applied to them.

To track GraphQL API requests, your agents must be on version 4.33.0 or above and you need to enable the GraphQL API Query templated rule. GraphQL Inspection is available for all Next-Gen WAF customers. Reach out to your account manager or sales@fastly.com to learn more.

Support for ARM Processors

We're expanding the Fastly Next-Gen WAF (powered by Signal Sciences) capabilities to include more deployment models than ever before. We now support processors using ARM architecture, which are gaining popularity in web applications due to the potential speed gains and overall cost-savings compared to other processors.

The new set of ARM-compatible Agent and Module will sit alongside our existing packages made for other processors, which includes a new ARM Agent and a complementary NGINX-native Module that supports NGINX v1.18.0 and above. It is available for all Signal Sciences / Fastly Next-Gen WAF customers, and you can read more about it in our blog.

Custom Response Codes

We’ve introduced custom response codes for site rules that block requests. This feature provides you with tighter integration between upstream services and your agents. It is especially powerful for connecting the Fastly edge and the Fastly Next-Gen WAF (powered by Signal Sciences).

You can use this feature to override the default 406 response code from Signal Sciences to enable additional security enforcement in programmable layers. In Fastly, you can use VCL to help you accomplish enhanced enforcement actions such as edge rate limiting or tarpitting.

The feature is available for Professional and Premier platform customers. Learn more about custom response codes by visiting our documentation site.

Renamed - Observed IPs and Rate Limited IPs pages

The Observed IPs page has been renamed to Observed Sources. In addition, the Rate Limited IPs tab has been renamed to Rate Limited Sources. To learn more about Observed Sources, read our announcement or visit our documentation site.

New Identity Provider Integration - Manage users with Okta

We have updated our official Okta integration to support automated provisioning, de-provisioning, and management of users. If you use Okta as your Identity Provider, you can easily install or update the Signal Sciences integration from the Okta Integration Marketplace.

After configuring the integration, any existing Signal Sciences users will be automatically matched to existing Okta users that have identical email accounts.

Customers can use Okta “groups” to assign Signal Sciences roles and site memberships to users in that group.

From Okta, you can:

• Create users in Signal Sciences
• Delete users from Signal Sciences
• Edit users’ site memberships
• Edit users’ role

Learn more by visiting our official documentation site.

Moved - Rate Limited IPs list

As of February 24, the Rate Limited IPs list, previously available as a tab on the Events page (under the Monitor menu), is now available on the brand-new Observed IPs page (also under Monitor menu).

You can also find new Suspicious IP and Flagged IP lists on the Observed IPs page. To learn more about Observed IPs, read our announcement or visit our documentation site.

New Observed IPs page

We've introduced a new Observed IPs page in the Signal Sciences console, found underneath the Monitor menu.

This page is your one-stop-shop to find information about what we're calling Observed IPs. There are three stateful IP statuses we represented on lists: Suspicious IPs, Flagged IPs, and Rate Limited IPs. Now, you can find all of these lists in one convenient view.

Important note: The Rate Limited IPs tab on the Events page has now moved to the Observed IPs page.

Learn more about Observed IPs by visiting our documentation site.

New Dashboards and Templated Rules Page

We are excited to announce today the launch of API and ATO Protection Dashboards, a new set of features dedicated to identifying, blocking, and analyzing malicious behavior that attackers use against web applications and APIs. Now available on the Signal Sciences console, these new dashboards surface security telemetry from over 20 new signals for advanced attack scenarios such as account takeover, credit card validation, and password reset.

For more information, view our blog post about the features.

To configure and activate your new templated rules, login to the management console and select templated rules, or navigate directly to the new dashboards from any site's home dashboard.

New Request Volume Graph

A new Request Volume graph is included in the first position of the default Overview system dashboard on every site. The graph represents the number of requests hitting a site over a given timeframe, along with average RPS. The graph can also be added to any custom dashboard.

To learn more about your site's Overview Page and how to customize dashboards, head over to the relevant docs page.

Deprecated - Weekly Summary Page

The Weekly Summary page is no longer available as of September 9. The summary's information and functionality can now be accessed from site-level dashboards (with the release of the new Request Volume card) Any existing links to the Weekly Summary will be redirected to the site's Overview dashboard with a seven-day look back.

Learn more about dashboards and how to customize them by visiting the relevant docs page.

New Client IP Headers setting

You can now set the real client IP of incoming requests across all agents via the console web interface. The new setting replaces the need to update the /etc/sigsci/agent.conf file on each agent to specify the real client IP.

To use the new feature, visit site settings > agent configurations in your console and scroll down to the Client IP Headers section. Learn more

New request to site rule converter

Our latest introduction to the console makes it easier than ever to use data from a request to create a new site rule. To use the tool, click “View request detail” for any request in the requests page, then look for the new “Convert to rule” button. With the new menu, you can select from the available request data to jump-start the process of creating a rule.

API Access Token updates

We've made a number of improvements to API Access Token security, management, and visibility for corp Owners.

Security:

• Corp Owners can set an expiration TTL that applies to all tokens. The expiration countdown is based on the token's creation timestamp.
• Corp Owners can create a list of IP or ranges that all tokens needs to be used from (i.e., a corporate network) otherwise API access will result in a 400-error
• Corp Owners can restrict token usage on a user-by-user basis. See below.
• These restrictions can be enabled or disabled from the Corp Manage > User Authentication page

Restrictions by user:

• When per-user restrictions are enabled, globally users cannot create or use tokens unless they are given explicit permission by the corp Owner
• IMPORTANT: If users have existing tokens when this feature is enabled, these existing tokens will be disabled (not deleted) until permissions are given to their owners and then they will resume working. Users just need permission once.
• Permission is granted to users from the Corp Manage > Corp Users > Edit User page

Visibility and management:

• Corp Owners can see all the tokens created and in use across the corp from the brand new Corp Manage > API Access Tokens page
• Corp Owners can view info about the tokens (like creator and IP), as well as info related to the changes above, like expiration, status (Disabled by Owner, Expired, Active)
• When they turn on Restrictions by User, a corp Owner can use this page to see who needs permission and which tokens are disabled
• Corp Owners can delete access tokens
• An individual user's tokens have moved from their account settings page to the new My Profile > API Access Tokens page

New rules conditions

We are pleased to announce the introduction of several new rules conditions that will help give you better visibility into abusive or anomalous behavior on your applications.

• Response Conditions Use Response code or Response header as conditions in request rules or signal exclusion rules for finer detail when adding or removing a signal. Combine response conditions with request conditions to gain greater insight into the results of client requests.

• Custom Signals Use custom signals as conditions in request rules to improve workflows or create more complex rule logic.

Learn more

SSO Bypass

A couple updates to the feature formerly known as API Users:

1. We're no longer using the term "API Users" in the console or the API. Instead, these are now "users with SSO Bypass." The intent of this attribute is to enable organizations to invite third-parties to access their SigSci instance (for example, a contractor who is outside the organizations SSO setup). While users with SSO Bypass can still connect to the API, we recommend users create API Access Tokens to connect services or automations to our API.

2. Users with SSO Bypass can now use Two-Factor Authentication (2FA). Corps with SSO enabled can continue to invite users from outside their organization's SSO, like contractors, now with the added protection of 2FA.

Templated rules response header and value conditions

You can now add optional response header name and value conditions to ATO templated rules, which include:

• Login Success
• Login Failure
• Registration Success
• Registration Failure

We’re excited to give you these additional levels to protect your apps against ATO and excessive authentication attempts! If you have any questions about these changes, reach out to us at support@fastly.com.

Example for the Login Success templated rule:

Agent 1x and 2x End-of-Life

We will disable all agents older than 3.0 on March 31, so if you have any agents between 1.x to 2.x please upgrade them before March 31. We’ve improved our newer agent versions to be much more efficient and secure. If you need help upgrading, let us know at support@fastly.com. If you’re wondering if this affects you, don’t worry! We’ve been reaching out to anyone this impacts to help them upgrade and we’ll make sure that no one is left behind.

Multiple custom dashboards

We are excited to announce that we've introduced the ability for users to create and edit multiple custom dashboards for each site. Last year, we introduced the ability for users to edit the dashboard found on each site's overview page, by adding custom signal time series graphs and rearranging the layout of those cards. Today, we've introduced the ability to save multiple custom dashboards, each with their own name and card layout. Every card type is moveable, including default cards like the Flagged IPs card. Owners, Admins, and Users can edit and view all of a site's dashboards, and Observers can view them.

Find out more about custom dashboards in our blog post and learn how to create and customize dashboards by visiting our documentation.

Changes to the User API

We've made a few changes to our user roles lately, and we updated the API response for /api/v0/corps/_/users to return new values. The new values are already available for use. The old values are still available as well, but they will be deprecated Friday, September 27, 2019.

Announcing Corp Rules

Take advantage of corp rules in order to create rules that apply to all, or a select number of sites within your corp. In the corp level navigation, simply navigate to Corp Rules > Corp Rules. From this page, manage existing corp rules, or add a new rule with the existing rules builder. Select the global scope to apply the rule to all sites within the corp, or select specific sites that you'd like the rule to apply. Note, this is a corp level feature available to corp owners and admins. For more information on rules look at our documentation

Dashboard navigation changes

We've made some big changes to the dashboard navigation. We've launched a few new features recently, with a focus on elevating some configurations from the site-level to multi-site- or global-level. We wanted to update the nav to make it clearer and more consistent.

We took a look at making sure each navigation item is in the right menu, and that the menu names are parallel at both the corp- and site-level. Think "Corp Rules" versus "Site Rules." You'll also notice a few items and page names have changed as well. For example, "Activity" is now "Audit log." See a full list of changes below:

Renamed and reorganized categories:

• Library is now “Corp Rules”
• Corp Tools is now “Corp Manage"
• Configure is now split up into “Site Rules” and “Site Manage”
• Corp Rules and Site Rules categories now only contain pages that directly relate to rules.
• We added the words “Corp” and “Site” in front of pages that have a corp/site equivalent to prevent confusion between corp and site levels (e.g., rules, lists, signals, integrations, audit log).
• We removed 2 pages from the navigation to prevent duplicate access points: Corp Overview and Monitor View. Corp Overview was removed since it can be accessed by clicking on your corp name. Monitor View was removed because it can be accessed on the Site Overview page.
• Site Settings is now underneath Site Manage to prevent overcrowding in the nav.
• Site Audit Log (formerly Activity) was moved to Site Manage to stay consistent with Corp Audit Log being underneath Corp Manage

Page nomenclature changes include:

• "Activity" is now "Audit Log"
• "Settings" is now "User Authentication"
• "Week in Review" is now "Weekly Summary"
• "Data Privacy" is now "Redactions"
• "Dashboards" is now "Signals Dashboards"
• "Custom Alerts" is now "Site Alerts"

Event page updates

We have launched some great new improvements to the Events page. Read about the updates below or see them for yourself.

1) We've added filters to the Events page to make it easier to triage and review events. You can filter by IP, signal, and status (Active/Expired).

2) Scrolling and navigation has been improved. First, we've made navigation elements sticky so they follow the user as they scroll up and down the page. Second, we've added a new interaction that automatically scrolls the user to the top of the page when they select a new event, reducing the amount of scrolling you have to do when reviewing multiple events.

3) We also have always-persistent Next Event and Previous Event buttons that make it easy to cycle through and review events. We think this will make it easy to manage the reviewing workflow when there are a lot of events.

4) Copy updates, like to the title of the Event Detail, to make it easier to know which event you're focused on at any time.

Assign multiple users to a site at once

Corp Owners and Admins can now assign multiple existing users to a site at once.

Corp Owners and Admins can now assign multiple existing users to a site at once. This provides business unit leaders and site managers an easy way to add their entire team to a new site at once. This feature can be accessed by Owners from the Corp Users page (under the Corp Tools menu) or by Owners and Admins from the Site Settings page.

Check out our documentation to learn more.

User Management Updates

The web interface for the corp-level Users Page has been improved to give Owners a better experience when managing and editing users across their entire corp. We’ve added enhanced filtering so users can now focus on specific sites or roles. This also lays the groundwork for some highly requested user management features.

We have also enhanced the Site Settings page usability with an easier-to-use tabbed layout.

Announcing Corp Signals

Corp Signals allow you to centrally manage and report on signals that are specific to your business at the corp-level rather than on individual sites! For example, you can create a single corp-level “OAuth Login” signal that can be used in any site rule which will then show up on the Corp Overview page. Learn more.

Stay on top of your corp activity

With corp integrations, you can receive alerts on activity that happens at the corp level of your account. Events relating to authentication, site and user administration, corp rules, and more can be sent to the tools you use for your day-to-day workflow. These are the same events you see in the Corp Activity section of the dashboard.

The following events are available for notification:

• New releases of our agent and module software
• New feature announcements
• Sites created/deleted
• SSO enabled/disabled on your corp
• Corp Lists created/updated/deleted
• Corp Signals created/updated/deleted
• Users invited
• User MFA enabled/updated/disabled
• Users added/removed
• User email bounced
• API access tokens created/updated/deleted

Currently, we offer integrations with Slack, Microsoft Teams, and email. Please visit the Corp Integrations page to configure one today.

Brand new Corp Overview

We have redesigned the Corp Overview page from the ground up to give you better tools to analyze security trends across your entire organization. It has been enhanced to allow you to:

Visualize attack traffic: New request graphs offer a high-level view of traffic across all of your monitored properties, as well as site-by-site breakdowns down of attack traffic and blocked attack traffic.

View corp-level Signal counts: For the first time in the dashboard, you can view the total number of requests tagged with specific Signals across your whole corp using the Signal Trends table. See what security trends are affecting your properties and adjust your security strategy accordingly.

Filter, filter, filter: We've added filtering and pagination tools to just about every aspect of the Corp Overview, allowing you to specify the data you want to see. Filter by site or Signal to zoom in on request data, or use the powerful new time range selector to report day-, week-, or month-over-month.

Visit the Corp Overview page to see for yourself. It can be accessed by clicking on your corp name in the navigation, or by selecting Corp Tools > Overview.

To learn more about the Corp Overview, read our new blog post.

Updated Permissions and Roles

tl;dr: Roles and permissions have been updated. Corp Admin is a brand-new role, and existing Corp Owners and Corp Users with multiple site roles experienced some permission updates. Check out the changes below.

What's new?

We’ve made some changes to our roles and permissions. These changes are designed to make it simpler to manage users across multiple sites at once, and will allow us to introduce some powerful new features in the near future.

Owner has full access and full owner permissions across every site within their corp. This isn’t a substantial change; previously Corp Owners could set themselves as members of any and all sites. We’re just simplifying the process of granting these permissions.

Admin is a brand new role we created to make it simpler for users to manage multiple sites. The Admin has Site Admin permissions on specific sites, meaning they can invite users and can edit configurations and agent mode (blocking/non-blocking). Admins do not have visibility into sites they do not manage and have limited visibility into corp-level or multi-site features.

User manages specific sites, including configurations and agent mode (blocking/non-blocking). Users do not have visibility into sites they do not manage and have limited visibility into corp-level or multi-site features.

Observer views specific sites in a read-only mode and has limited visibility into corp-level or multi-site features.

How was I affected by the update?

If you were previously a Corp Owner: you now have access to every site within your corp and are granted Site Owner permissions by default. Previously, Corp Owners could optionally choose to be members of sites. This option is no longer available.

If you were previously a Corp User:

• If you were either a Site Owner or Site Admin on any site in your corp, you are now an Admin across all your site memberships.
• If you were a Site User or a Site Observer on sites (and not a Site Owner or Site Admin) , you are a User on those same sites.
• However, if you only had the Site Observer role across all of your site memberships, you are an Observer with visibility limited to those same sites.

Questions or concerns? Check out our Customer Support portal.

Updated APT and YUM repository signing keys

Due to a change with our package hosting provider, we have updated the GPG keys for our YUM and APT repositories. Updated GPG URLs are now listed in all relevant installation instructions.

If you have scripts for automated deployment, you will need to update the scripts with the new GPG key URL to ensure they continue to work:

Old URL: https://yum.signalsciences.net/gpg.key or https://apt.signalsciences.net/gpg.key New URL: https://yum.signalsciences.net/release/gpgkey or https://apt.signalsciences.net/release/gpgkey

Note: If you’re using NGINX 1.9 or earlier, then you will instead want to use the legacy URL of: https://yum.signalsciences.net/nginx/gpg.key

Introducing Corp Lists!

Corp Lists are a new feature that allow Corp Owners to manage Lists at the corp-level which can be used by any site-level rule. You can find Corp Lists by going to Library > Corp Lists in the corp-level navigation.

For example, you can centrally manage a list of OFAC-sanctioned countries, or scanner IPs that you may want to block or allow across multiple sites.

Customize the Monitor View

Here by popular demand, you can now customize the Monitor View. Previously, the Monitor would display 5-6 default graphs. With the new update, the Monitor now reflects any custom Overview page graphs or arrangements. When displayed as a grid, the Monitor shows the first 6 cards from the Overview page. When displayed as a carousel, the Monitor will cycle through all cards.

Check out the new Custom Signals page!

Custom Signals enable you to gain visibility into traffic that's specific to your application. You can create these signals either on the Custom Signals page (Configure > Custom Signals) or, more commonly, when creating or editing a Rule.

The new Custom Signals page now shows:

• The number of requests tagged with a particular signal in the past 7 days.
• The number of Rules that add that signal.
• The number of Alerts that use that signal.

This additional data makes it easier to determine whether a Custom Signal is working correctly or is no longer used by any Rules or Alerts.

Check out our fresh new status page!

Be sure to subscribe to our new status page at https://www.fastlystatus.com/ so that you can receive alerts in the rare occasion that Signal Sciences has an unexpected event. Please note that you’ll need to resubscribe to this new page if you were previously subscribed to the old status page.

Rules Simplification

Starting today, November 8th, we’ll be rolling out a new unified Rules page.

Previously Request Rules (rules that allow you block, allow, or tag requests) and Signal Rules (rules that allow you to exclude signals for specific criteria) were managed on two distinct pages. Now Request and Signal Rules can be viewed, managed, and filtered from a single page.

Why are we making this change?

In addition to simplifying the number of pages in the product you need to go to manage rules, this change lays the groundwork for future changes to more easily share rules across sites.

How will this change affect me?

From a user-facing perspective, this change should be minimal — existing URLs will be redirected and you will create and manage rules from a single page.

Where can I learn more about rules?

Check out our rules documentation.

Coming soon: Updated roles and permissions

tl;dr: Roles and permissions will be changing in January. Corp Admin is a brand-new role, and existing Corp Owners and Corp Users with multiple site roles will experience permission updates. Review the changes below and prepare your organization.

What's new?

We’re making some changes to our roles and permissions. These changes are designed to make it simpler to manage users across multiple sites at once, and will allow us to introduce some powerful new features in the near future.

Owner will have full access and full owner permissions across every site within their corp. This isn’t a substantial change; current Corp Owners can already set themselves as members of any and all sites. We’re just simplifying the process of granting these permissions.

Admin is a brand new role we created to make it simpler for users to manage multiple sites. The Admin has Site Admin permissions on specific sites, meaning they can invite users and can edit configurations and agent mode (blocking/non-blocking). Admins will not have visibility into sites they do not manage and will have limited visibility into corp-level or multi-site features.

User will manage specific sites, including configurations and agent mode (blocking/non-blocking). Users will not have visibility into sites they do not manage and will have limited visibility into corp-level or multi-site features.

Observer will view specific sites in a read-only mode and will have limited visibility into corp-level or multi-site features.

How will I be affected when the roles are updated?

If you are currently a Corp Owner: you will have access to every site within your corp and will be granted Site Owner permissions by default. Currently, Corp Owners can optionally choose to be members of sites. This option will no longer be available.

If you are currently a Corp User:

• If you are either a Site Owner or Site Admin on any site in your corp, you’ll become an Admin across all your site memberships.
• If you are a Site User or a Site Observer on sites (and not a Site Owner or Site Admin) , you will be a User on those same sites.
• However, if you only have the Site Observer role across all of your site memberships, you will become an Observer with visibility limited to those same sites.

Questions or concerns? Check out our Customer Support portal.

Personal API Access Tokens

Personal API Access Tokens are permanent tokens that can be used instead of passwords to authenticate against the API. This allows SSO and 2FA users to easily access the API without the additional workaround. Furthermore, these tokens can be used directly against API endpoints without having to authenticate and obtain a session token.