- Using dashboards
- Managing alerts across Cylance Endpoint Security services
- Managing users, devices, and groups
- Manage CylancePROTECT Desktop and CylanceOPTICS devices
- Manage zones
- Manage devices with the CylancePROTECT Mobile app
- Manage CylancePROTECT Mobile app and CylanceGATEWAY users
- Managing CylanceAVERT users
- Manage user groups
- Configure device lifecycle management
- Remove a registered FIDO device for a user account
- Discover unprotected devices
- Managing threats detected by CylancePROTECT Desktop
- Managing threats detected by CylancePROTECT Mobile
- Managing safe and unsafe lists for CylancePROTECT Desktop and CylancePROTECT Mobile
- Add a file to the CylancePROTECT Desktop global quarantine or global safe list
- Add a file to the CylancePROTECT Desktop local quarantine or local safe list
- Add a certificate to the CylancePROTECT Desktop global safe list
- Add an app, certificate, IP address, or domain to a CylancePROTECT Mobile safe or restricted list
- Analyzing data collected by CylanceOPTICS
- Using CylanceOPTICS to detect and respond to events
- Monitoring network connections with CylanceGATEWAY
- Monitoring sensitive files with CylanceAVERT
- View mobile OS vulnerabilities
- Auditing administrator actions
- Managing logs
- Send events to a SIEM solution or syslog server
- Enable access to the Cylance User API
- Troubleshooting Cylance Endpoint Security
- Using the BlackBerry Support Collection Tool
- Removing the BlackBerry Connectivity Node software from Cylance Endpoint Security
- Troubleshooting CylancePROTECT Desktop
- Remove the CylancePROTECT Desktop agent from a device
- Re-register a Linux agent
- Troubleshoot update, status, and connectivity issues with CylancePROTECT Desktop
- A large number of DYLD Injection violations are reported by Linux devices
- Time zone variances for CylancePROTECT Desktop
- Folder exclusions when using CylancePROTECT Desktop with third-party security products
- Linux driver is not loaded. Upgrade the driver package.
- Troubleshooting CylanceOPTICS
Paths
Paths define how the CAE interprets the flow of multiple state objects within a rule. You use paths when a rule consists of multiple state objects (also known as a multistate rule). States define the flow of a CAE rule and allow
CylanceOPTICS
to statefully observe a series of events that occur on a device. These represent a "1, then 2, then 3" scenario that might occur.If a rule has one state object only, you don't need to use a paths object. Rules consist of a single state object and do not explicitly require the use of the paths object. Rules that do utilize the paths object do so for explicit definition only (not for rule functionality).
In the following examples, two state objects are used, NewSuspiciousFile and CertUtilDecode. Each state has its own set of logic.
Example 1
: In the following configuration, the CAE will look for an event that satisfies the NewSuspiciousFile state. When that state is satisfied, the CAE will look for an event that satisfies the CertUtilDecode state."Paths": [ { "StateNames": [ "NewSuspiciousFile", "CertUtilDecode" ] } ],
Example 2
: In the following configuration, the CAE will look for an event that satisfies the CertUtilDecode state, then the NewSuspiciousFile state."Paths": [ { "StateNames": [ "CertUtilDecode", "NewSuspiciousFile" ] } ],
Example 3
: In the following configuration, the CAE will look for an event that satisfies the NewSuspiciousFile state or the CertUtilDecode state. This is helpful when states have different filter object sets. In this example, NewSuspiciousFile uses a File Write filter and CertUtilDecode uses a process Start filter."Paths": [ { "StateNames": [ "CertUtilDecode" ] }, { "StateNames": [ "NewSuspiciousFile" ] } ],