Application Discovery

  • 5 minute read
Prev Next

Application Discovery can be a vital tool when you are migrating from a traditional network model to the ZTNA model. With a traditional  VPN solution you may not really know which apps users are connecting to, so you can't easily define the policies/entitlements that AppGate ZTNA requires. Application Discovery allows organizations to quickly identify which apps users are connecting to and then to create the appropriate policies/entitlements.

This feature analyzes user behavior and access patterns over time. It then generates actionable insights that empower administrators to define and fine-tune entitlements and policies, ensuring that only authorized users can access specific resources aligned with the organization’s security objectives.

As organizations adopt hosted or connected deployments, leveraging Application Discovery can significantly enhance their ability to respond to evolving security threats while preserving a seamless user experience.

NOTE

Public IPs are not detected in the current version of Application Discovery, and there is currently a maximum cap of 10,000 apps, 5,000 users, and 5,000 groups per system.

Use the Discovered Apps UI to see discovered applications.

Prerequisites for Application Discovery

  • A Collective that is either ZTP connected or ZTP hosted.

  • A configured LogServer or LogForwarder that can connect to logpusher.[region].appgate.net

  • A feature license that includes Application Discovery or the advanced or the enterprise license tier.

  • Some broad host definitions in the entitlements (using only TCP up actions) for the Site where applications are to be discovered.

  • An IdP attribute mapped to the “groups” claim. You can also map the "role" attribute, or other attributes used to group users, from the IdP to the "groups" claim.

  • The DNS servers related to the discovered apps should be the same as the ones the Gateways are configured to use. The Gateways should also be handling the DNS traffic from the clients. The use of zone transfer is recommended for this feature.  

NOTE

This will not work in conjunction with secure DNS.

Operation of Application Discovery

Application Discovery occurs when entitlement actions have hosts are defined as an IPv4/6 subnet (such as 192.168.0.0/24) and/or a full port range (1-65535), and the protocol defined as TCP up (broad host definitions). The use of the domain syntax (*.mycompany.com) is not considered broad host definitions.

NOTE

Up to 5,000 applications can be discovered with a limit of 5,000 users per application. If you are on version 6.5 or earlier, there is a limit of 5,000 user groups per application. In version 6.6 and beyond, the limit is 200 user groups.

Data collection and retention

Application Discovery will collect and export specific data from the AppGate ZTNA environment to ZTP. This data comprises the following audit log record types:

  • authentication_succeeded

  • authorization_succeeded

  • ip_access

See Audit log types for detailed content of these records.

Additionally the Gateway's DNS request data will be exported.

The data will be kept in the document database for 30 days from when it was pushed and then deleted.

If the Collective is disconnected from ZTP, its stored data will be deleted at 00.00 UTC.

It is important to remember how AppGate ZTNA handles overlapping entitlements. Rule 2 states, "The action with a smaller subnet has higher precedence". This means that any precisely-defined actions, even if they sit within a broad host definition, will be not be forwarded to the LogPusher service.

Example with four entitlement actions:

TCP up to 192.168.0.0/24

TCP up to 192.168.0.1

TCP up to 192.168.1.1

TCP up to myserver.mycompany.com (resolves to 192.168.0.2)

In this example, only traffic in the 192.168.0.3 to 192.168.0.254 range will be forwarded to LogPusher.

Application Discovery collects specific data used to identify this traffic, which will then be forwarded to ZTP's LogPusher service.

The LogPusher will then store the information in a document database. The database is structured by Collective; so the data cannot be accessed from other Collectives, even within the same account.

Every night, at 00:00 UTC, ZTP's Advisor service will analyze the data stored in the document database and combine it into a summary that will be available to administrators. This summary is stored in the same document database until it is requested by the Collective. The summary is presented in the Discovered Apps UI as individual discovered apps, where an “app” is defined as a hostname and port. From the list in the Discovered Apps page, you can create policies and entitlements for that specific traffic and group of users.

NOTE

It can take up to 15 minutes for discovered apps to appear.

Once the specific entitlements have been created, the subsequent traffic using these new entitlements will be excluded from the discovery data. As explained above, this new entitlement will now have a higher precedence so any traffic will use this new entitlement and not the broad one (which you can leave as it was).

The greater the number of specific entitlements, the less traffic will be using the broad host definition, and the number of discovered apps will reduce.

When there is no more traffic using the broad host definition, the related entitlement can be disabled. If however you want to continue to monitor for any remaining traffic then just convert the broad host definition action to use the DENY rule instead. This will still provide the same information in discovered apps but the traffic will not be allowed until a new entitlement is created allowing it.

Troubleshooting Application Discovery

The Discovered Apps UI includes the Troubleshoot action, which will help you understand the data sets being used by the system.

Selecting Action > Troubleshoot opens the Troubleshooting window.

The Troubleshooting window shows the date and time that the three data sets—Access Data, Authentication Data, and DNS Data—were last received. It can take up to 15 minutes for these timestamps to be updated.

  • If there is no Access Data Received, one of the following may be the issue:

    • The LogForwarder or LogServer aren't able to connect to logpusher.[region].appgate.net (see the Prerequisites for Cloud Services section of the ZTP User Guide)

    • There is no LogForwarder or LogServer configured for the collective

    • The traffic isn't routed through AppGate ZTNA if there is no "Authentication Data Received", the Controller isn't able to connect to logpusher.[region].appgate.net

There is already a narrow entitlement for the traffic, and narrow entitlements take precedence over broad entitlements.

  • If there is no Authentication Data Received, the controller isn't able to connect to logpusher.[region].appgate.net

  • If there is no DNS Data Received, the DNS requests aren't routed through AppGate ZTNA (see the DNS and name resolution section)

The Download Data button will download Application Discovery data in JSON format to your machine.

NOTE

You may need to refresh the Discovered Apps page to see new troubleshooting data.

Related articles