We are continuing to simplify security testing automation in your CI/CD pipelines. Many users have requested to have FAST work with several CI pipelines simultaneously. We’re glad to announce that such support was added in the latest version of FAST.

You no longer need to run multiple instances of the FAST node for each CI pipeline. Instead, the only instance of the FAST node can now be used in multiple pipelines. It greatly simplifies tool deployment and makes the whole testing architecture more elegant.

Just specify an additional parameter BUILD_ID in the configuration of your project in the CI/CD system. For example if you work in Jenkins, add -e BUILD_ID = $ {env.BUILD_ID} into the command that launches FAST.

The parameter should be unique for each build so that the FAST node can associate any given requests with the necessary Test Run. Note that support for parallel pipelines works with both modes: recording baselines and running security tests.

Don’t have FAST but want to try it out? Send us a note!

With the growing complexity of new applications and technology stacks, as well as evolving attack techniques, we can implement regular improvements in how the Wallarm WAF detects attacks. Here are some highlights from March 2020 that our detection team wants to share:

• Expanded list of possible NoSQLi (NoSQL Injection) vectors that can be detected;
• Improved the mechanism for detecting SSTI (Server Side Template Injection) attacks;
• Redesigned SSI (Server Side Includes) discovery mechanism;
• New rules for detecting IMAPi (Mail Injection) have been added.

This update will expand the WAF's ability to detect attacks by adding new rules and reducing the number of false positives by optimizing existing algorithms.

Do I need to update anything to apply these changes?
No, all improvements in the attack detection techniques are delivered to customers automatically.

How do you ensure that these changes will not affect my traffic flow?

For the next two weeks, the update will work in the experimental mode without any additional blocking. Changes will be activated once we make sure no additional false positives are introduced.

For questions related to the detects and updated rules, you can contact our support team.

We are pleased to announce the general availability of the Wallarm Node 2.14. This is a major update that is recommended to install.

Highlights

• The protection of gRPC-based APIs and microservices is now supported. gRPC/Protobuf parser has been added. Read more.
• When blocked by an IP address, it is now possible to return a custom error page and server code to the client
• A few improvements have been made to the monitoring and other system components
• Support for the following operating systems has been added:- Debian 10
  • Amazon Linux 2

How to upgrade

• The installation and update packages for all supported platforms are already available in the repositories
• AWS AMI and GCP VM Image have been updated

The migration guide is available in the docs portal.

Support for modern stacks is where Wallarm has always stood out from its competitors. For a long time it was the only product that provided full comprehensive protection for WebSockets-based web applications, and now we are the first to add support for the gRPC protocol.

Many customers, especially among large tech companies, are adopting gRPC as a fundamental piece of tech while architecturing their new APIs and microservices. Developed by Google, gRPC is a popular framework for remote procedure which serializes data using Protobuf and relies on HTTP/2 for transport.

New improvement is a part of Intelligent Parsing technology. Every Wallarm Node runs deep request inspection, parses Protobuf messages and detects malicious payloads even if they are nested inside complex data structures. This allows you to protect your web assets against the modern-days challenges, ranging from OWASP Top10 threats to Account Takeover.

Node: you don’t need to run any additional configuration or upload any API schema or protobuf structures to protect your assets. Wallarm will automatically figure everything out based on the traffic.

This way, you can protect those APIs that use gRPC and are frequently updated as a part of CI/CD process. With no extra configuration.

Recently we’ve launched a new Dashboard widget—Attack Sources.

On its left side you can see the GeoIP map, which shows the distribution of malicious requests (hits) from different countries. The bigger the red indicator, the more requests that originated from that country. Hover over the indicator to see the exact number of hits.

On the right side of the widget you can also see the top of attack sources, such as Tor and data centers. For example, if most of your attacks came from the Tor network or from networks of cloud providers, then you would be able to see it at the top of the table and take action.

Any feedback? Let us know!

PagerDuty is an incident response platform that is very popular among the DevOps community. It empowers teams with automation capabilities that quickly and accurately orchestrate the right response, every time.

With the Wallarm/PagerDuty integration, it is possible to automate reaction and escalation policies for security incidents. PagerDuty can now pull data from Wallarm, including events on discovered vulnerabilities and changes in the network perimeter. For instance, many people set up a workflow when a critical security issue is discovered.

Unified workflows and shared tools are crucial to align DevOps and Sec teams and guarantee service SLA and its security.

We continue to expand the list of supported DevOps tools. More to come in the coming months! Tell us if anything missing.

There is an update in the Wallarm Console, which presents a brand new dashboard that can't be missed.

There are three significant changes that are worth mentioning:

1. New structure. The dashboard has a new, clear structure emphasising multiple modules of the Wallarm Platform — WAF, Scanner, FAST. The WAF section includes data on the normal traffic against malicious hits. The Scanner section gives a quick overview on the security issues identified by the scanner modules. The FAST section shows the results of automated security testing in CI/CD pipelines. You can jump to each of the dashboard sections right from the main menu.
2. New data. Additional new data points have been released and are coming within the next couple months. The WAF section can now show data and analytics regarding the amount of traffic against malicious payload detected. If you have multiple apps and APIs, you can see the breakdown on the malicious hits and incidents across them in one unified view. The Scanner section has a new vulnerability subsection with more visibility of what's happening with the security issues of different risks.
3. New menu. We reinvented the product's navigation. The whole menu has been revamped and transferred to the side to make navigation to any part of the system easier!

Have any feedback? Is anything missing? Please reach out to us at request@wallarm.com.

Wallarm extends deployment support for Wallarm filtering node to more platforms. We consistently monitor new application architectures and new trends in application deployment. Additionally, as current platforms evolve and release new versions, we adapt the software and test compatibility to support the latest releases.

Summary of updates:

1. An updated version of Wallarm for Heroku to support Heroku-18 Stack at the request of our customers. Wallarm can be used with any version: Cedar-14, Heroku-16 and Heroku-18. The updated Buildpack is available in our GitHub account.
2. Filtering node is now available on Debian 10.
3. Filtering node is now available on Amazon Linux 2. Amazon Linux is a special Linux distribution supported by Amazon and optimized for Amazon Web Services.

Packages for all of these platforms are already available in our repositories.

Next in line is support for the new CentOS 8 release!

Running apps with AWS Lambda? You can now protect your serverless workloads in AWS, GCP, Azure and any other cloud provider!

More and more customers rely on the serverless stack to develop their business critical applications. Those require proper protection against OWASP and other threats. Architecture wise it may be tricky to install filter nodes in front of serverless workloads. In AWS, customers tend to use AWS native load balancers (such as ALB) that route requests directly to AWS Lambda functions.

We currently support Python and Node.JS which are the most common languages to develop serverless workloads. In fact Middleware RASP can be used to protect any apps and API (not necessarily serverless) when deploying reverse proxy is a challenge.

We released an important FAST update. You can now disable any tests for the static files and with that significantly improve test performance.

Traffic of automated tests and manual testing of QA engineers typically contains HTTP requests to the static files (such as images, js, CSS). By default, FAST records baselines for all the requests and for the static files too. Most often, running tests against static files doesn't make sense. So skipping these tests can give you speed boost and allow testing to finish much faster.

In the TestRun settings, you can now enable option "Skip following files extensions" and choose which files to consider as static. They be excluded for the further testing.