Advanced Rules: Publisher & File Identification Criteria

See How It Works - Feb 26th 2021 at 1PM EST

WEBINAR: Demo of AutoElevate's New Rules Engine - Production Release

on Feb 26, 2021 1:00 PM EST

REGISTER: https://attendee.gotowebinar.com/register/3305935009771932944

After registering, you will receive a confirmation email containing information about joining the webinar. If you are unable to attend the webinar live you will receive a link to watch a recording after the webinar has concluded.

When Rules are created in AutoElevate, from either the mobile app or from Events in the Admin Portal, the identification criteria* is set to the file's MD5 hash by default. Beginning with agent v2.4+, the identification criteria can now be changed and edited and can include additional criteria from the Publisher certificate or File attributes.

* Identification criteria are the different specified criteria on a Rule that are used to identify the application that is attempting to be elevated. Once a match is found between the app attempting to be elevated and a Rule, the agent then executes specific actions depending on how the Rule is configured (Approved, Denied, etc). The 2 types of identification criteria that can be set are Publisher and File.

Publisher Criteria

Publisher criteria can be set to 1 of 2 different options: Subject Elements or Certificate Hash.

Note: You will see an expandable section of information about the publisher certificate along with the publisher options. This data is generated from the file examined on the local machine that the Event originated from. Whether the file is marked as "Verified" or not, depends on whether the certificate chain on the local machine was verified. Verified certs are where that the certificate and/or it's issuer are in the local certificate authority (CA) on the local machine, as well as whether the "Signing Time" falls between the "Valid From" to "Valid To" time stamps.

• Subject Elements: These are the different parts of the "Subject" distinguished name found embedded in the publisher certificate. Any combination of elements can be selected, however, it's good to note that each software publisher can potentially use many different certificates. Targeting less subject elements will allow for a wider range of software that will match the identification criteria selected.
• Certificate Hash: This is the "thumbprint" of the certificate used to sign the file. It is very specific to that certificate only. Typically, publisher certificates expire after a year or 2. This means that publishers need to get new certificates, with new thumbprints, frequently. Targeting the certificate hash may mean that you will need to create new Rules to account for these new certificates when they are issued. 

File Criteria

File criteria can be set to any combination of 5 options: Product Name, File Path, File Name, Original File Name, MD5 Hash. The default values of these criteria are set to what was read from the actual file from the local computer where the original Event happened. Wilcard characters can be used to specify dynamic elements (* ? [a-z]).

• Product Name: A value specified by the software publisher and embedded in the binary of the file itself. It can be blank if the file did not contain version information.
• File Path: The full path of where the file was located on the local machine, including the name of the file itself. When processing the File Path, the agent will expand any Windows environment variables included. Click HERE for more information on Windows env vars.
  • Note: Currently, the agent cannot process env vars that include any local user information (ie. %LOCALAPPDATA%). This will be adjusted in a future update.
• File Name: The file name extracted from the path.
• Original File Name: The name the file was created with. It can be blank if the file did not contain version information.
• MD5 Hash: The MD5 hash of the file.

How can I create advanced Rules with these new types of identification criteria?

Requirements: Make sure your agents are at v2.4+. They will be automatically updated as part of our normal updating process. If you see agents still stuck on v2.3.8, check that they have at least .NET v4.7 as this is now required. If the machine does not have version 4.7 the Agent will not install and should remain at the previous version. Powershell v3.0+ is also required to process any rules with wildcard characters.

From Events:

1. Generate UAC Events on a machine using agent v2.4+.
2. Make Rules from the new Events. After generating Events from the agent v2.4+, from the “Events” screen check the box next to an Event and then select “Convert to Rule” from the “Actions” menu.

From Requests:

1. Make Rules from new real-time Requests that are generated from agent v2.4+.
2. "Edit" the Rule from the Rules screen by clicking the "Edit" (pencil icon) next to the Rule in the Rules screen.

If you don't see these options, be sure to reload/refresh the Admin Portal in your browser (if it's already open). Additionally, only users in the Administrators and Technician (Level 3) roles have the permissions to edit & set the identification criteria on Rules.

Other important things to know:

• You can combine both Publisher & File criteria in a single Rule by simply selecting the checkboxes next to all elements that you would like to apply.
• Only events that are generated from a machine running version agent v2.4+ will have the ability to define a rule using publisher certificate & file info. This agent captures additional information required to make publisher certificate rules which the previous Agent versions were not capturing. Additionally, this is the only version that can interpret and process the identification criteria set on these new Rules.
• 1-Time responses can be converted to Rules by converting the corresponding Events into Rules from the Events screen.

Additional publisher certificate verification has been built into agent v2.4+ to ensure the safety and security of making rules based off of publisher certificate criteria. The AutoElevate rules engine does this verification, in the same manner that most security tools do, using information from the local certificate authority store (CA) on each machine. The local certificate authority stores are updated by Microsoft. Security and mitigation of threats to the local certificate store on each machine is strongly dependent upon users only having standard user privileges.