Announcements

Protection from CVE-2024-53677 (Apache Struts File Upload Logic Vulnerability)

A directory traversal vulnerability within file uploads has been found in Apache Struts (S2-067) and has been assigned CVE-2024-53677. Fastly has created a virtual patch for it that is now available within your account. To activate it and add protection to your services follow the steps for your control panel below.

Next-Gen WAF control panel

Fastly control panel

1. Log in to the Fastly web interface.
2. Go to Security > Next-Gen WAF > Workspaces.
3. Click Virtual Patches.
4. In the search bar, enter CVE-2024-53677 and then click the pencil to the right of the CVE-2024-53677 virtual patch.
5. From the Status menu, select Enabled.
6. (Optional) If your workspace is in blocking mode, choose whether to Block requests or Log requests if the CVE-2024-53677 signal is observed.
7. Click Update virtual patch.

Immediate end-of-support for Windows Server 2008 & Windows Server 2012

In accordance with our product lifecycle policy, our Next-Gen WAF’s Core deployment method on Windows Server 2008 and 2012 hosts has reached an end-of-life support state due to third-party decisions to change or retire their solution. Effective immediately, we are no longer able to support agent upgrades for Next-Gen WAF services on a Windows Server 2008 or Windows Server 2012 host, as neither Microsoft nor Golang support them. Versions of Next-Gen WAF core 4.50.0 and earlier will continue to function on Windows Server 2008 and Windows Server 2012, but we will not be able to update the agent should issues arise.

If left unattended, this could leave your service vulnerable to a variety of risks, including:

1. Running your service on an unsupported version of Windows will prevent you from applying security patches that are regularly released by your operating system's manufacturer. Unsupported server operating systems that remain unpatched leave your services vulnerable to security exploits, malware threats, and data breaches. These unsupported operating system versions could also expose you to legal or compliance issues for customers (and their end users) who have strict security requirements.
2. Fastly's Security Research and Engineering teams are constantly developing and releasing service protections in new agent versions. In addition, agent support is deprecated on a regular cadence for all agents more than two years old. Once those deprecations happen, your services will no longer have access to the newest security features and integrations included with newer agent versions; they will no longer be using the latest version of the Fastly Next-Gen WAF.

Upgrade Recommendations

To mitigate these risks, we strongly recommend that you upgrade your hosts to operating systems supported by Microsoft such as Windows Server 2022, and your Next-Gen WAF core deployment to the latest version (4.58.2) to maximize the protection for your applications. If preferred, Next-Gen WAF core versions 4.51.0 and later are supported on Windows Server 2016 and later.

If you are unable to upgrade the Windows Server 2008 or Windows Server 2012 host, we recommend a reverse proxy running a supported Next-Gen WAF in front of your application, such as deploying the core Next-Gen WAF to a supported host in reverse proxy mode and routing all traffic through it to your application.

Customers using a Windows Server 2008 or 2012 host and currently have a 4.51.0+ agent should consider updating their Windows Server to a newer version before proceeding with any additional Next-Gen WAF core version upgrades. This will help reduce support and security risks.

Questions? Concerns?

Customers with any questions or concerns may engage with our Support team or contact their designated account management team members.

Protection from CVE-2024-45115 (Adobe Commerce and Magento Open Source Improper Authentication)

An authentication bypass and privilege escalation vulnerability has been found in Adobe Commerce and Magento Open Source and has been assigned CVE-2024-45115. Fastly has created a virtual patch for it that is now available within your account. To activate it and add protection to your services, follow the steps for your control panel below.

Next-Gen WAF control panel

Fastly control panel

1. Log in to the Fastly web interface.
2. Go to Security > Next-Gen WAF > Workspaces.
3. Click Virtual Patches.
4. In the search bar, enter CVE-2024-45115 and then click the pencil to the right of the CVE-2024-45115 virtual patch.
5. From the Status menu, select Enabled.
6. (Optional) If your workspace is in blocking mode, choose whether to Block requests or Log requests if the CVE-2024-45115 signal is observed.
7. Click Update virtual patch.

New comment support in Lists

We have released support for comments within IP and Country lists using the # character. The comment can be added on its own line or inline with an entry.

Next-Gen WAF on Compute for Edge WAF deployments

Fastly's Next-Gen WAF now supports the Edge WAF deployment option for use with Rust-based Compute projects. Check out our deployment guide for additional details and try things out with our tutorial on using Next-Gen WAF in Compute.

New anomaly signal: INSECURE-AUTH

We have introduced an anomaly signal (INSECURE-AUTH) that allows you to detect when insecure authentication methods are used (such as the JSON Web Tokens with the None Algorithm). Want to learn more? For full descriptions of this and all other system signals, check out our system signals documentation.

Next-Gen WAF configuration via the Fastly control panel

Today, Fastly begins offering the ability to configure some of the features of the Fastly Next-Gen WAF from directly within the Fastly control panel. To use the new controls, you must purchase the Next-Gen WAF Security Starter Package and have a Fastly account. The original Next-Gen WAF control panel continues to remain available for existing Next-Gen WAF customers.

The Security controls web interface guides describe where these controls appear in the Fastly control panel. Likewise, we've added instructions to our guides that describe how to use the Fastly Next-Gen WAF with details on how to configure the new Next-Gen WAF starter package features.

For more details about the Next-Gen WAF, including how to purchase it, contact your account manager or email sales@fastly.com.

Protection from CVE-2024-34102 (Adobe Commerce and Magento Open Source unauthenticated XML entity injection)

An unauthenticated XML entity injection has been found in Adobe Commerce and Magento Open Source and has been assigned CVE-2024-34102. 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 control panel.
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-2024-34102 and then click View for the CVE-2024-34102 templated rule.
5. Click Configure and then Add trigger.
6. Select the Block requests from an IP immediately if the CVE-2024-34102 signal is observed checkbox.
7. Click Update rule.

Protection from CVE-2024-5806 (Progress MOVEit Transfer Authentication Bypass Vulnerability)

An authentication bypass vulnerability has been found in Progress MOVEit Transfer and has been assigned CVE-2024-5806. 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 control panel.
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-2024-5806 and then click View for the CVE-2024-5806 templated rule.
5. Click Configure and then Add trigger.
6. Select the Block requests from an IP immediately if the CVE-2024-5806 signal is observed checkbox.
7. Click Update rule.

Upcoming Code Signing and Repository Key Rotation for RPMs

To continue ensuring the integrity of the software we distribute as well as conform to evolving platform security standards, we are making changes to how we sign software distributed in RPM packages for the core Next-Gen WAF product. Specifically, the repository and code signing keys will be updated from the older SHA-1 algorithm to use the newer and more secure SHA-256 algorithm. This change will impact users who consume the core Next-Gen WAF agent as well as any modules that are packaged as RPMs.

We plan to make this change on Monday, September 23rd at 12:00PM EDT (4PM GMT). After this, all RPM packages released as part of the core Next-Gen WAF product will be signed with keys using the SHA-256 algorithm.

Who is impacted by this change?

Users who run the core Next-Gen WAF on Red Hat Enterprise Linux (RHEL) and systems derived from it, such as CentOS or Amazon Linux, are impacted by this change. If the packages you install or update have an extension of .rpm then you are affected.

What will I need to do?

After Monday, September 23rd, 2024, at 12:00 PM ET (4PM GMT), you will need to download new public keys for both our repository and our packages. Before then, no changes will be needed to package updates. Take the actions below after the planned change date.

If you delete the existing public keys, the repository tool YUM will download the new ones during update. To delete the code signing and repository keys, execute the following command:

$ rpm -e gpg-pubkey-db6249a1-666932d2
$ rpm -e gpg-pubkey-b61c0150-5cf6f75f

If you are using a RHEL 7 or earlier system, you will need to take additional steps to delete the keys. Follow these instructions:

1. Check your /etc/yum.conf file and note the value of persistdir. If persistdir is not set, you can assume it is /var/lib/yum.

2. Determine which CPU architecture the repository has been installed for: x86_64 for 64-bit x86 systems and aarch64 for 64-bit ARM systems.

3. Determine the version number of the CentOS or Red Hat you are running (7, 8 or 9).

4. Replace x86_64 and 7 in the following command with your CPU architecture and CentOS or Red Hat version:

   $ gpg --homedir /var/lib/yum/repos/aarch64/7/sigsci_release/gpgdir --delete-key DB6249A1
   $ gpg --homedir /var/lib/yum/repos/aarch64/7/sigsci_release/gpgdir --delete-key B61C0150

What will happen if I don’t make any changes?

If you do not make any changes, all of your existing agents will continue to protect your application from attacks; nothing will stop working. However, you will not be able to upgrade to newer versions of the core Next-Gen WAF agent or modules released after Monday, September 23rd at 12:00PM EDT (4PM GMT). If you do not upgrade to newer versions of the core Next-Gen WAF agent or module, you may miss important bug fixes and features.

Who is not impacted by this change?

Users who do not install or update the core Next-Gen WAF using RPMs are not impacted. Specifically, users who install the core Next-Gen WAF using DEB (Debian or Ubuntu) or APK (Alpine Linux) packages are not affected. Windows users are not affected. Users who install our software using a so-called tarball (a packaged file with the .tar.gz extension) are not affected. Users who deploy the Next-Gen WAF using either the Edge or Cloud WAF methods, or users of any other Fastly service are also not affected.

Who can I contact if I need help?

If you have any questions, contact support by visiting https://support.fastly.com/ or sending email to support@fastly.com.

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 control panels. 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 3 hours 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 control panel.
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 control panel.
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 control panel.
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 control panel 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 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 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 control panel 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, 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. 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 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.

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 control panel, 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 control panel, 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.

To configure and activate your new templated rules, login to the management control panel 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 control panel 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 control panel and scroll down to the Client IP Headers section. Learn more

New request to site rule converter

Our latest introduction to the control panel 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 control panel 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.

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 summaries 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.

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.