Fortinet black logo
7.2.0

Example use case

Example use case

Let us assume the following:

We have an Apple M1 MacBook Air running the MAC-OS-X persistent agent version 10.7.0.2, which identifies adapters (MAC Addresses) on the host.

A Belkin ethernet adapter connects the MacBook Air to port 8 on a FortiSwitch.

In this example, this Belkin adapter will be moved between hosts. We will want to find the device to which the adapter has been moved, detect it, and – if it isn’t communicating with FortiNAC – quarantine it.

In this example, we’ve defined a Corporate Device Network Access that places the host in VLAN 140.

Steps to detect the dongle

First, create a Network Access Policy to place a device with a “Non-communicating persistent agent” into the Dead End network.

Note: A “non-communicating PA” means that the device is connected to the network but does not respond to any agent communication requests.

The pre-defined host filter for “Non Communicating PA” identifies that the host is on the network but the Persistent Agent is not communicating as it should be to the FortiNAC server.

Since our network access configuration for Non Communicating PA policy was set to Dead End Configuration, non-communicating devices will be dead-ended.

Now, in the work environment, the Belkin adapter is moved between endpoints...

Here, a potential security risk is about to occur. Let’s see if our policy will react appropriately.

The Belkin adapter is disconnected from the MacBook.

This triggers a Host Disconnect Event.

Next, the Belkin adapter is connected to a different host, one that has no Persistent Agent installed, potentially rogue.

When that device connects to the network, its persistent agent does not communicate with FortiNAC, thus indicating that it is unauthorized and yet has connected to the network.

FortiNAC gets a Host Connected Event and a Persistent Agent Not Communicating Event.

Thanks to our policy, the VLAN will change to the Dead End VLAN.

FortiNAC has successfully addressed this scenario.

Clicking into Policy Details shows the host now matches the “Non Communicating PA Policy.”

Example use case

Let us assume the following:

We have an Apple M1 MacBook Air running the MAC-OS-X persistent agent version 10.7.0.2, which identifies adapters (MAC Addresses) on the host.

A Belkin ethernet adapter connects the MacBook Air to port 8 on a FortiSwitch.

In this example, this Belkin adapter will be moved between hosts. We will want to find the device to which the adapter has been moved, detect it, and – if it isn’t communicating with FortiNAC – quarantine it.

In this example, we’ve defined a Corporate Device Network Access that places the host in VLAN 140.

Steps to detect the dongle

First, create a Network Access Policy to place a device with a “Non-communicating persistent agent” into the Dead End network.

Note: A “non-communicating PA” means that the device is connected to the network but does not respond to any agent communication requests.

The pre-defined host filter for “Non Communicating PA” identifies that the host is on the network but the Persistent Agent is not communicating as it should be to the FortiNAC server.

Since our network access configuration for Non Communicating PA policy was set to Dead End Configuration, non-communicating devices will be dead-ended.

Now, in the work environment, the Belkin adapter is moved between endpoints...

Here, a potential security risk is about to occur. Let’s see if our policy will react appropriately.

The Belkin adapter is disconnected from the MacBook.

This triggers a Host Disconnect Event.

Next, the Belkin adapter is connected to a different host, one that has no Persistent Agent installed, potentially rogue.

When that device connects to the network, its persistent agent does not communicate with FortiNAC, thus indicating that it is unauthorized and yet has connected to the network.

FortiNAC gets a Host Connected Event and a Persistent Agent Not Communicating Event.

Thanks to our policy, the VLAN will change to the Dead End VLAN.

FortiNAC has successfully addressed this scenario.

Clicking into Policy Details shows the host now matches the “Non Communicating PA Policy.”