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.

The vital part of FAST's philosophy is making security testing automation easier, especially within CI/CD pipelines. It'll be simpler with the new feature — Reuse Test Record.

You can now rerun existing security tests that you created earlier, without recording a new Test Record. It may be especially convenient when the methods and variables of your API haven't changed, and it doesn't make sense to record new test baselines. You can just run the Test Run using the existing Test Record. For instance, after the new build of the application.

In FAST Console, you can try the action "Create similar Test Run". Note: you can reuse only Test Records that have more than one baseline and are not in Recording state.

Our scanner component just received a powerful update. Our monthly extensions continually improve perimeter discovery and asset checks for security issues. However, you couldn't manage those extensions.

Now, you can configure extensions in the scanner settings. Choose which extensions are relevant to your infrastructure.

Extensions are grouped by CWE. As an example, group CWE-200 Information Exposure includes detects of security issues that may expose sensitive data to the attacker. You can turn on or off any extension. For instance, activate extension to discover Git or SVN repository that is open to the world. Or disable check for the MongoDB admin panel without any authentication.

To customize your navigation, filter extensions using their tags. If you want to quickly find everything related to Java, search for its associated CVE. You can search through extensions by tags relating to technology, vulnerability type, or CVE.