Understanding Private Site Scanning

ASoC provides Dynamic Application Security Testing (DAST) from a cloud-based scanner as SaaS. This capability requires the cloud-based scanner to be able to access the tested application. Publicly available web-based applications can be scanned without issue. However, Private Site Scanning (PSS) is only possible after adding network components (such as VPNs or proxies) or changing the network to allow the scanner to access the web application’s host server.

PSS tunneling

Our solution for PSS requires no special changes to the customer’s network that might present a risk to the network. The PSS client that is set up in the customer’s network requires only outgoing access to the Internet (either directly or via an HTTP proxy) and access to the site being scanned.

The solution consists of two endpoints (server and client) which create a TCP/IP tunnel that is initiated by the endpoint on the customer’s (client) side.

Tunnel server

This endpoint resides in the SaaS network alongside the scanner. It is started only when a new scan is started. The server has two “sides” to it, consisting of listening connections (Back-to-Back Servers).

  • The first listens for incoming connections from the tunnel client. This is the tunnel-side.
  • The second listens for incoming connections from the scanner. In this respect it emulates an HTTP proxy, and thus is proxy-side.

When connections from the client are available, the scanner sends the requests to the proxy-side, which are then port-forwarded to the incoming connections on the tunnel-side. When responses are returned by the client, they are forwarded back through the proxy side to the scanner.

Tunnel client

This endpoint sits inside the customer’s network and generates the TCP/IP connections to the server. It performs the same function as the tunnel server, except it consists of two sets of client connections (Back-to-Back Clients). The tunnel client also has two “sides”:

  • The tunnel-side is a set of connections which are initiated out to the tunnel server.
  • The client-side is the set of connections that are initiated out to the scanned server (directly or via a proxy).

The tunnel client performs port forwarding.

AppScan Presence

The Private Site Scanning tunnel relies on a SaaS controlled mechanism called the AppScan Presence: a communication channel which receives tasks to be performed from the cloud-based service, and triggers handlers to perform the tasks. The Presence service is a polling service which continuously polls the cloud-based service for tasks, using secured HTTP communication.

The AppScan Presence service serves only to retrieve tasks from the SaaS service, download the information needed to handle the task, and trigger the handler. In this case, the task is handled by the tunnel-client and the information retrieved is the data required for starting the tunneling client connections to the server.

Performing a scan

To perform a scan, the tunnel client needs to be started and connected to a server. This is performed by the AppScan Presence framework.

The AppScan Presence framework consists of a Presence Service which runs on the tunnel-client machine. The Presence service polls the Presence SaaS server, which runs on the Cloud and indicates when a scan is ready to run. The exchange between services consists of the scan details, including the IP address of the tunnel-server the client should connect to. In addition it receives information which allows it to positively identify the server it is connecting to. More on this in the Security Considerations section following.

Once a user has requested a Private scan and selected a Presence instance through which the scan should be performed, a scan agent is allocated and the tunnel-server of that agent is started up. A task is then queued in the SaaS server. This task is accepted by the Presence Service, which then launches a tunnel-client with the relevant connection information.

Security considerations

Two important security aspects were considered: the customer’s network and the security of the tunnel connection.

The solution does not require any changes to the customer’s network. It is important to note that no special concessions are required by the AppScan Presence and the PSS Tunnel Client. This allows the customer to apply the organizational security policies on the host machine running the AppScan Presence and the PSS Tunnel Client. There are no changes required to the organizational firewall (such as allowing incoming connections on certain ports or IP addresses).In most cases no changes to the organizational firewall are required (such as allowing incoming connections on specific ports or IP addresses). The only exceptions are:
  • If machines are restricted from direct outgoing internet access, the machine hosting AppScan Presencemust be allow through.
  • If the organization resigns SSL/TLS traffic with its own certificate, the connections to AppScan on Cloud must be excluded, so communication is not interrupted, and the security mechanisms built into the architecture can function properly.
In such cases make sure the IP ranges used by ASoC are excluded from resigning, or allow direct access to them, and make sure they are not blocked by your firewall.

Presence ID

Each Presence Service has a unique key that serves as its ID. It is used to identify the Presence instance and provide it with the correct scan tasks. The key can be renewed at any time, and so can conform to organizational security policies that require periodic updates. Once a key is renewed on the server, the Presence instance stops receiving tasks until the key is physically placed on the Presence machine.


It is crucial that the tunnel server and tunnel client can trust each other, to prevent external access to the private network from an unvalidated location. When a scan is ready to run and the tunnel-server is started, it generates a private server key and certificate, and a random client key (25 alphanumeric characters). The server certificate and the client key are passed to the tunnel-client, along with the scan task details (via the communication between the Presence Service and the SaaS Service). The tunnel-client and server can then validate the identity of the remote connection.

The server certificate and client key are invalidated once the scan is completed, and are never reused, even for rescanning.

The certificate conforms to the latest NIST and FIPS standards that are updated occasionally (encryption algorithm, hash algorithm, and key length).

In-transit data protection

The tunnel connection is encrypted using TLS 1.2. The Tunnel client gets the ad hoc server certificate in advance, and uses it to verify that the server certificate used in the TLS authentication is the expected one. After the client authenticates the server, it sends the client key to the server, so that the server will be able to authenticate the client. The data passing through this tunnel is made up of the requests and responses between the scanner and the test application and thus is sensitive. To protect the data, it is encrypted in transit between the tunnel ends using these one-time certificate and keys.