Create an Aurora Protect Desktop test policy

You should implement Aurora Protect Desktop policy features in a phased approach to make sure performance and operations are not impacted. By default, when you create a device policy, policy features are not enabled and you must manually enable them. As you understand the types of threats that are logged in your environment and how the Aurora Protect Desktop agent behaves, you can gradually enable more policy features.

It is recommended that you test device policies on devices that include the applications that are used in your organization. It is important that the devices that you use to test device policies accurately represent the devices that are in your production environment, and not just a clean machine, to make sure that applications are allowed to run properly when policies are enforced through the Aurora Protect Desktop agent. For example, you might select a subset of devices in your production environment that include all applications (proprietary and custom) that users need for their daily activities. 

The agent uses execution control and process monitoring to analyze running processes only. This includes all files that run at startup, that are set to auto-run, and that are manually executed by the user. The agent only sends alerts to the management console. By default, no files are blocked or quarantined.

  1. In the management console, click Policies > Device Policy > Add new policy.
  2. In the Policy Name field, type a name for the test policy.
  3. Enable Auto Upload to analyze and send suspicious files to the Aurora Protect cloud services for further analysis.
    1. In the File Actions tab, in the Auto Upload section, select all the file types that are available.
    2. Click Create to create the initial test policy.
    3. Assign the initial test policy to the Aurora Protect Desktop endpoints that you are using for testing.
    4. Allow the devices that are assigned to the test policy to run for at least one day to allow applications and processes that are typically used on the device to run and be analyzed. You may want to consider any required applications that run periodically on a device (for example, once a week) that may need to be monitored outside of this test run.
    5. While testing the policy, navigate to the Protection > Threats screen in the management console to view a list of applications and processes that Aurora Protect considers to be a threat (abnormal or unsafe) and identify the ones that should be allowed to run on the endpoint. You can click a threat to view more information about it and download the malicious file to perform your own threat research. The malicious file is unaltered but renamed using the SHA256 hash without a file extension to prevent the accidental detonation of it. If you rename it to include the original file extension, the malicious file may be run. No personally identifiable information is shared with the console or with other tenants or organizations.
    6. Navigate to Policies > Device Policy and edit the device policy to allow specific applications and processes to run on endpoints that have this policy assigned to them. You can add files to the Policy Safe List section in the File Actions tab.
      You may also quarantine or waive files on specific devices or all devices in your organization. For more information, see Managing safe and unsafe lists for Aurora Protect Desktop.
  4. Edit the device policy to enable the background threat detection scans to analyze executable files on the disk that may be dormant threats.
    1. In the Protection Settings tab, enable the Background Threat Detection setting and select the Run Once option. Although periodic scanning is not necessary due to the predictive abilities of the solution, you may select Run Recurring to enable it, for example, for compliance purposes.
    2. Enable the Watch For New Files setting. This setting may negatively impact performance on the device. Adding folder exclusions may help reduce the impact.
    3. To exclude specific folders from background threat detection, select Exclude Specific Folders (includes subfolders) and specify the folders to exclude. To allow the execution of files in the folders that you specified, select Allow execution. For more information about these fields, see Device policy: Malware Protection settings.
    4. Click Save to save the policy.
    5. Test the policy again and make sure that any applications that users are required to use are allowed to run. Background threat detection scanning may take up to one week, depending on how busy the system is and the number of files that require analysis. If necessary, make sure to add files to the policy safe list, global safe list, or waive them for individual devices. You can also exclude the folder containing the file in the protection settings.
  5. Edit the device policy to kill unsafe processes that are running on the system. For example, when a threat is detected in an executable file (.exe or .msi) and it is considered to be unsafe, this setting kills running processes and their sub-processes.
    1. In the Protection Settings tab, enable the Kill Unsafe Running Processes setting. 
  6. Edit the policy to enable the auto-quarantine settings for unsafe and abnormal files.
    1. In the File Actions tab, under the Unsafe table column, enable the Auto Quarantine setting beside Executable to automatically move unsafe files to the quarantine folder on the device. Unsafe files have malware attributes and are likely to be malware.
    2. Under Abnormal, enable Auto Quarantine to automatically move abnormal files to the quarantine folder on the device. An abnormal file has fewer malware attributes than an unsafe file and is less likely to be malware.
  7. Edit the policy to enable memory protection settings to handle memory exploits, process injections, and escalations.
    1. In the Memory Actions tab of the device policy, enable Memory Protection and set the violation types to Alert. When a violation type is set to alert and a threat of that type is detected, the agent sends information to the console but does not block or terminate any processes running in the device memory.
    2. While testing the policy, navigate to the Protection > Memory Protection screen in the console to view a list of memory protection alerts for processes may be a threat.
    3. If you determined that any of the processes are safe for daily business activities, you can add exclusions for the processes that you want to allow to run. In the Memory Actions tab of the device policy, click Add exclusion and specify the relative path to the file.
    4. After you have specified the exclusions for processes that you want to allow to run, set the action to Block for all violation types. When a violation type is blocked, the agent sends information to the console and blocks the malicious process from running in the memory. The application that called the malicious process is allowed to continue to run.
  8. Edit the policy to enable the device control settings. This example demonstrates how to block access to all device types and allow the exceptions, but you may choose to allow full access to all device types and block the exceptions instead.
    1. In the Device Control tab of the device policy, enable the Device Control policy.
    2. Set the access level for each of the USB device types to Full Access.
    3. Save the policy.
    4. On the test device, insert a USB device.
    5. In the management console, navigate to Protection > External Devices and identify the vendor ID, product ID, and serial number of any devices that you want to allow. Not all manufacturers use a unique serial number with their products; some manufacturers use the same serial number for multiple products.
    6. In the Device Control tab of the device policy, in the External Storage Exclusion List section, click Add device to add any devices that you want to allow.
    7. Once testing is complete, set the access level for each of the device types to Block. You can add any exclusions as needed.
  9. Edit the policy to enable the script control settings. The suggested testing time is 1 to 3 weeks.
    1. In the Script Control tab of the device policy, enable the Script Control policy.
    2. Set the policy for each of the script types to Alert. The longer the time script control is set to alert, the more likely you are to find infrequently run scripts used in the organization.
      Note: Enabling the script control setting can cause a high-volume of events if scripts are used to manage Active Directory settings.
    3. Navigate to Protection > Script Control and identify the scripts that were run on devices that you want to allow.
    4. In the Script Control tab of the device policy, in the Exclude Files, Scripts or Processes section, click Add exclusion and specify a relative process path of the scripts that you want to allow (for example, \Cases\AllowedScripts).
    5. After you have added the exclusions for scripts that you want to allow to run, you can set the policy for each of the script types to Block.