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.

Good news! Wallarm Nodes now natively support auto-scaling capabilities in AWS and GCP. Updated images are already available in cloud provider marketplaces.

Many of our customers rely on the auto-scaling capabilities to horizontally scale their apps and APIs. Auto-scaling mechanisms monitor your applications and automatically adjusts capacity to maintain steady, predictable performance at the lowest possible cost.

In the earlier releases, it was already possible to automatically scale Wallarm Nodes based on the load, for example, with native support of Kubernetes. From now on, you can also dynamically add additional nodes or remove underutilized ones using the native auto-scaling mechanism of AWS and GCP.

You can scale the number of instances based on a number of standard load parameters including: the utilization of CPU, amount of inbound/outbound traffic, etc. For example, for a group of Wallarm Node instances in AWS, you can set up the following policy: If Average CPU Utilization exceeds 60% for over 5 min then add 2 more nodes.

Support of auto-scaling is available in Wallarm Node 2.12.0+. Find the images in Amazon Web Services and Google Cloud Platform.

Detailed tutorials on how to set up auto-scaling are available in the Wallarm Docs for AWS and GCP.

Wallarm nodes can operate in detection only (aka monitoring) or blocking modes. With a recent change in UI, every malicious request from the traffic is displayed with an explicit status detailing whether it was blocked or reached the application. Designed to be especially helpful for teams using individual modes for different applications and APIs.

With previous console versions, teams had to pay attention to each status code returned to the client. A 403 was the default status code if an incoming request was blocked by Wallarm node. Now, an explicit status of whether a malicious request was blocked is shown in the console. The same data is provided for attacks (groups of malicious request related to each other).