Subject: [sacm] Scenario 1: Network Profiler

From: Clifford Kahn <[email-masked]>
Date: Fri, 17 Apr 2015 04:03:39 +0000

Hello all.

What is a network profiler? Here are two definitions from vendors:
Cisco(r) NAC Profiler enables network administrators to keep a real-time, contextual inventory of all devices in a network. It greatly facilitates the deployment and management of Cisco Network Admission Control (NAC) systems by discovering and tracking the location and type of all LAN-attached endpoints, including those that are not capable of authenticating. [http://www.cisco.com/c/en/us/products/collateral/security/nac-profiler/product_data_sheet0900aecd806b7d4e.html]
Starting with basic network data, we profile and automatically apply policies the whole infrastructure in real-time. . . .  Correlating what devices claim to be and what they are actually doing on the network . . . [http://www.rebasoft.net/solutions/]
For our purposes, here is a proposed definition:
A network profiler characterizes endpoints on the basis of network traffic the endpoint sends and receives.  A profiler may observe network traffic directly and/or indirectly. For example, it may learn about ARP traffic by querying ARP caches of routers.
We can specify that a SACM-equipped profiler SHALL be able to publish endpoint attribute assertions with the following attributes:*
                IP address: XXXXXX
                                Routing domain: {string, optional} --  to disambiguate
                and/or
                MAC address: MMMMMM
                                Layer 2 broadcast domain: {string, optional} -- to disambiguate
                Endpoint characteristics. One or more of:

o   Manufacturer: {string}

o   Model: {string}

o   os: {string}

o   os-version: {string}

o   device-type: {string}
                Time stamp and all other universal attributes
* To credit my source, these attributes are based on section 3.1.8 of TNC IF-MAP Metadata for Network Security v1.8 (https://www.trustedcomputinggroup.org/files/resource_files/281C050E-1A4B-B294-D018131B07BC2030/TNC_IFMAP_Metadata_For_Network_Security_v1_1r8.pdf). Appendix A of that document has values for device-type.
The addresses are identifying attributes.
We have said that an identifying attribute has to be authenticatable. But does the profiler *authenticate* an address? It observes it. Instead of "authenticatable" I suggest we say "dependable".
The IP address is dependable. Many enterprises have machinery to prevent IP spoofing. A NAT within the enterprise can lead the profiler to present a NATted address, which is not useful for SACM. But, it is typical to configure a profiler to recognize the address of the NAT and avoid reporting on NATted addresses. (We can put all of this into Security Considerations.)
The MAC address can also be dependable. If the profiler observes traffic that came to it through a router, it will tend to report the MAC address of the router, which is not useful for SACM. However, there are other techniques (such as querying ARP caches) that allow profilers to get the endpoint's MAC address. A profiler SHOULD NOT  publish the MAC address of a midpoint network device; it SHOULD either publish the MAC address of the endpoint, or no MAC address at all.
Scenario 1: Detecting an endpoint that should be under closer SACM monitoring

*         The enterprise's policy requires that all Windows endpoints (for example) be under close SACM monitoring.

*         A profiler finds a Windows endpoint at address 1.2.3.4.

*         No other SACM collector has information about a Windows endpoint at address 1.2.3.4.

*         An evaluator flags a compliance issue.
Scenario 1b: Cross-checking other SACM collectors
If the profiler's report about an endpoint clashes with another collector's report, it is worth flagging this condition. An unspecified component or a human can investigate. One possibility is that the endpoint is compromised and is lying about itself.

Scenario 2: Classifying a constrained endpoint
I know that IoT is out of scope for now. However, scenario 1 works out better if the profiler can identify IoT endpoints that cannot be monitored by a SACM collector. That way, these endpoints can be dismissed, rather than being worried about.
For this usage scenario, the MAC address of the endpoint is important, because relatively stable.

Scenario 3: Network Profiler Coupled with Authentication of Endpoint
The endpoint signs in using 802.1X, presenting credentials that identify the endpoint.
The switch or wireless controller sends the endpoint's MAC address to the RADIUS server, as a RADIUS attribute.
The RADIUS server publishes an endpoint attribute assertion with these attributes:
                authenticated identity of endpoint
                MAC address
3a:
An evaluator joins this endpoint attribute assertion to an endpoint attribute assertion from a profiler, which must mention the endpoint's MAC address. The derived endpoint attribute assertion (which may or may not be published) has these attributes:
                authenticated identity of endpoint
                MAC address
                Endpoint characteristics

The evaluator now has a strong connection between some posture attributes and the endpoint's identity.
3b:
After 802.1X, the following often happens:

o   The endpoint uses DHCP to get an IP address

o   The switch or wireless controller performs DHCP snooping and learns the IP address

o   The switch or wireless controller sends the IP address to the RADIUS server
Then the RADIUS server publishes a better endpoint attribute assertion, with these attributes:

o   authenticated identity (typically username or certificate)

o   MAC address

o   IP address
An evaluator can join this improved endpoint attribute assertion to an endpoint attribute assertion from a profiler that mentions the endpoint's IP address.

Scenario 4:
Like scenario 3, but the endpoint signs in with credentials that identify the user, but do not identify the endpoint.
This is common, and therefore important, even if not ideal.
For this to work, the enterprise must register endpoints and keep an inventory, with:

o   The identity of the user who uses the endpoint

o   The MAC address(es) of the endpoint

o   Unique identifier of the endpoint
The inventory component produces endpoint attribute assertions, with the above attributes.
An evaluator joins three endpoint attribute assertions:
1. From the RADIUS server:
                authenticated identity of user
                MAC address
                IP address (optional)
2. From the profiler:
                IP address and/or MAC address
                Endpoint characteristics
3. From the inventory:
                The identity a user who uses an endpoint
                The MAC address(es) of the endpoint
                Unique identifier of endpoint
By joining these, an evaluator derives an assertion with these attributes (it may or may not publish the assertion):
                authenticated identity of user
                MAC address
                Endpoint characteristics
                Unique identifier of endpoint
Combinations:

Scenario 1 combines with scenarios 3 and 4.

Clifford Kahn
Principal Engineeer, Technical Lead