Netskope Global Technical Success (GTS)
Case Insights - Device Classification
Netskope Cloud Version - 126
What is this article about?
As a new initiative, this report examines the most recurrent “How-to” questions raised by customers and managed by Netskope Global Technical Success (GTS) Team.
Netskope Device Classification
The most common issues raised by customers regarding Device Classification revolve around the logic applied within the rules and debugging its status.
Logic in Device Classification Rules (AND vs OR)
When configuring a Device Classification rule, the "Classification Criteria" setting offers two options: "All" or "Any." This setting determines whether all specified criteria must be met ("All") or if meeting any of the specified criteria ("Any") is sufficient for the rule to apply.
Path: Netskope Tenant UI >>> Manage >>> Device Classification >>> New Device Classification Rule
When "All" is selected, the criteria operate with AND logic. However, for criteria allowing multiple definitions, at least one of those definitions must be true. The diagram below illustrates this behaviour.
For instance:
This rule includes the conditions: (chrome.exe OR test.exe) AND (Windows 10 All). As a result:
| chrome.exe | test.exe | Windows 10 all | Device Classification status |
| 0 | 0 | 0 | Unmanaged |
| 0 | 0 | 1 | Unmanaged |
| 0 | 1 | 0 | Unmanaged |
| 0 | 1 | 1 | Managed |
| 1 | 0 | 0 | Unmanaged |
| 1 | 0 | 1 | Managed |
| 1 | 1 | 0 | Unmanaged |
| 1 | 1 | 1 | Managed |
Selecting "Any" activates an OR logic across all criteria. The diagram below illustrates this behaviour.
For example:
Based on the previous example, the rule logic would be: (chrome.exe OR test.exe) OR (Windows 10 All), As a result:
| chrome.exe | test.exe | Windows 10 all | Device Classification status |
| 0 | 0 | 0 | Unmanaged |
| 0 | 0 | 1 | Managed |
| 0 | 1 | 0 | Managed |
| 0 | 1 | 1 | Managed |
| 1 | 0 | 0 | Managed |
| 1 | 0 | 1 | Managed |
| 1 | 1 | 0 | Managed |
| 1 | 1 | 1 | Managed |
Debugging Device Classification Status
Netskope Client obtains all device classifications based on the operating system. This information is combined into a configuration file called nsdeviceid.json. The default logging level for Netskope Client is info, and when operating at this level, the resolution of each rule definition can be observed in the nsdebuglog.log file.
| Criteria | nsdebuglog.log |
| Encryption | deviceId Disk encryption check: name <encryption name>, status 0|1 |
| OPSWAT | #1: deviceId process check: status 0|1, name GearsAgentService.exe |
| Registry | deviceId reg check: status: 0|1, data: <Data Value> |
| Process | deviceId process check: status 0|1, name <process name>.exe |
| File | deviceId File check: status 0|1 name <filename>.<file extension> |
| AD Domain | deviceId Domain check: status 0|1, name <AD Domain> |
| AV | nsUtil AVRunning status: 0|1 |
| OS | deviceId OSVersion check: status 0|1 |
| Certificate | deviceId Client cert check :status 0|1 |
| ℹ️
/Library/Application Support/Netskope/STAgent/data/nsdeviceid.json /Library/Application Support/Netskope/STAgent/Logs/nsdebuglog.log
%programdata%\netskope\stagent\data\nsdeviceid.json %programdata%\netskope\stagent\Logs\nsdebuglog.log |
Where to check what was the last Device Classification applied?
End-User
By default, Netskope Client log level is in info while in debug, we could search for the following entries:
nsdebuglog.log
info tunnel.cpp:x nsTunnel DTLS Device classification status: managed
info tunnel.cpp:x nsTunnel DTLS Device classification custom status: <Device Classification name>
info tunnel.cpp:x nsTunnel DTLS Device classification custom status id: <Device Classification ID>
Or look for the heartbeat that Netskope Client sends with its status, this will be a json format,
info clientStatusHandler.cpp:x clientStatusHandler client status message {..."device_classification_status": "managed","device_classification_custom_status": "<Device Classification name>","device_classification_custom_status_id": <Device Classification ID>...}
nsAppUI.log
info config.cpp:10972 Config csessId x] Last dcStatus: managed
info config.cpp:10976 Config csessId x] Last custom dcStatus: <Device Classification name>
info config.cpp:10980 Config csessId x] Last custom dcStatusId: <Device Classification ID>
Also on the device, you can leverage nsdiag with --check-dc to force Netskope Client to run a device classification validation. For example:
Command: nsdiag.exe --check-dc
| ℹ️
"/Users/<user>/Library/Logs/Netskope/nsAppUI.log" "/Library/Application Support/Netskope/STAgent/nsdiag"
%appdata%\Netskope\stagent\Logs\nsAppUI.log %programfiles(x86)%\Netskope\STAgent\nsdiag.exe
|
Netskope Tenant
Devices tagged by Device Classification are visible on the Devices page.
Path: Netskope Tenant UI >>> Settings >>> Security Cloud Platform >>> Devices
This information can also be found within the General Section of Application Events or Alerts.
Path: Netskope Tenant UI >>> SkopeIT >>> Application Events or Alerts.
| ℹ️ Advanced Analytics distinguishes only between managed or unmanaged devices. It does not report/consume custom device classifications fields. |
REST API V2
The endpoint /api/v2/events/datasearch/clientstatus can be used to pull device classification information.
Path: Netskope Tenant UI >>> Settings >>> Tools >>> REST API V2
REST API V1
The endpoint /api/v1/clients can be used to pull device classification information.
Path: Netskope Tenant UI >>> Settings >>> Tools >>> REST API V1
Helpful content
Using the REST API v2 Datasearch Endpoint
Terms and Conditions
- All documented information undergoes testing and verification to ensure accuracy.
- In the future, it is possible that the application's functionality may be altered by the vendor. If any such changes are brought to our attention, we will promptly update the documentation to reflect them.
Notes
- This article is authored by Netskope Global Technical Success (GTS).
- For any further inquiries related to this article, please contact Netskope GTS by submitting a support case with 'Case Type – How To Questions'.
