Creating application identifiers
Application identifiers, or application IDs, help to define which audit and protection rules apply to which applications, i.e.:
- Applications to protect or to exclude from a protection,
- Applications likely to interact with a protected application, for both legitimate or illegitimate purposes.
Since IDs are specific to each rule set, you must create IDs in each set. You can however export all the IDs of a rule set to import and use them in another set. For more information, refer to the section Importing and exporting identifiers.
EXAMPLE
If you want to prevent all applications from logging keystrokes on your web browser, except the virtualization tool, which has a legitimate need to log keystrokes. In this case, you need to create an application ID for the application you want to protect (web browser), and an ID for the legitimate keylogging application (virtualization tool).
Application IDs are necessary when you create rule sets, and must be created beforehand.
- Select a policy in Security > Policies, then select a set of rules.
- Click on the Identifiers tab at the top right, then on the Application IDs tab.
- Click on Edit in the upper banner, then on Add an ID.
A blank ID appears below the existing IDs. - Click on Edit at the bottom right.
- In the field New application ID, enter an ID name, then a description if needed.
- Click on and select all the identifier criteria you wish to use. E.g. Path and Certificate.
- Click outside the criteria window and define each ID criterion selected:Paths
Click on Edit then in the blue field at the bottom, enter the partial or full path to the application’s executable file. This path may be a link or the path in the file system.
The characters * and ? are allowed. Enter for example *\Apache.exe to identify the Apache application regardless of its location on the workstation.
Full paths beginning with a letter (i.e., E:\Data\Backup) are not supported if the Volume type is remote or removable.
Stormshield strongly recommends the use of EsaRoots path roots provided by SES Evolution instead of drive letters (i.e., C:\...). In fact, these letters may differ from one workstation to another.You can also specify an alternate data stream. The ADSs of an executable file allow it to be looked up by several data streams. For further information, refer to Microsoft Windows documentation.
Click on Add.
Enter other paths in the blue field if necessary, then click on Add.
Click OK to confirm the path list.
Hashes- Hashes make it possible to accurately identify a trusted binary, as any modification will change the hash, which will no longer be recognized. Hash-based identification can be used in the following cases:
- To guarantee that a legitimate binary has not been replaced or modified. However, this requires tedious maintenance as you will need to change IDs after every software update. It should therefore be used only on systems that do not undergo many changes.
- To identify malware programs that often change names but may keep the same hash. Import the list of the most common malware hashes to block them from running.
Click on Edit then on the pencil icon.
In the blue field at the bottom, enter the MD5, SHA1 or SHA256 hash of the application’s binary file and a description, then click on Add.
To obtain the hash of a binary, you can use the following Powershell command. In this example, the SHA256 hash of all .exe files is obtained:
Get-ChildItem -Recurse -Filter '*.exe' | get-filehash -Algorithm SHA256 | select path, Hash
Enter other hashes the blue field if necessary, then click on Add.
Click on OK.
You can also import a list of hashes from a CSV or text file. The file must contain one hash and a description per line separated by a comma, tab or semi-colon:
Hash (MD5, SHA1 or SHA2),
Description.
- Click on OK to confirm the list of hashes.
To add hashes:
If there is an error or duplicate hash, SES Evolution will indicate it and only valid and unique hashes will be imported.
Once they have been entered and imported, the window shows the number of hashes for each algorithm.
Parent processSelect the process that launches the application. The application ID of this process must be created beforehand.
Click on Manage.
Search for the ID of the parent process(es) using the search field and select them from the list that appears.
Click on OK to confirm the list of parent processes.
CertificateImport the digital signature certificate provided by the application’s vendor. Certificate-based identification can be used in the following cases:
To strengthen the identification of a trusted binary by making it less restrictive than a hash because the certificate does not change with every new version of the binary. It is more reliable than using just a path because an attacker can always rename a malware program to winword.exe for example.
To trust a vendor and therefore all software that it signs with its certificate. For example, you can allow the execution of all binaries signed by Microsoft, or even all binaries signed by a trusted certification authority.
To obtain a certificate, you can use the following Powershell command. In this example, we obtain the Acrobat Reader certificate, which we will name Adobe.cer:
(Get-AuthenticodeSignature -FilePath "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe").SignerCertificate | Export-Certificate -FilePath Adobe.cer
To add certificates:
- Click on Manage to the right of the checkbox, then on Import certificate.
- Choose the certificates to import.
- Search for the certificates(s) using the search field and select them from the list that appears.
- Click on OK to confirm the list of certificates.
- The Restrict search to the list ({0} option makes it possible to search for the applications identified by the certificates listed in the ID. Keep the checkbox unselected (by default) if you want a rule to search among all certificates that have signed applications. In this case, certificates do not need to be imported in the identifier.
You can refine the search by using the options Valid and Not valid so that a rule applies when it finds valid or invalid certificates (regardless of whether they are listed in the ID). Invalid certificates refer to certificates with the following status: not signed, revoked, untrusted, expired, corrupted or missing. These options are compatible with agents from version 2.3 upwards. - If needed, select Ignore errors when validating the certificate signature so that rules using this ID apply anyway when the certificate cannot be verified and an application is identified by other defined criteria in the ID.
The verification of the certificate may fail in the following cases:
when a binary file starts running before the agent is installed, before the agent's services start, when the firewall restarts for the first time after the installation of the agent, or after a major update of the operating system,
when the binary file WerFault.exe is involved, as it is processed differently from other files for technical reasons,
when a third-party app prevents the binary file from being blocked.
Run in- Click on Edit.
From the drop-down list at the bottom, select the type of account that launches the identified application (e.g., NT_AUTHORITY\System), then click on Add.
You can choose a strict or higher than or equal integrity level. For example, if you set a Powershell identifier with execution context to Administrator-level integrity (strict), the rule is triggered only for a Powershell run by an Administrator. On the other hand, with an execution context set to Administrator-level integrity (or higher), the rule is triggered if Powershell is run by an Administrator or the Operating System.
To define a specific account, enter the account's SID (security identifier) in the field.
Select other accounts if necessary and click on Add.
Click on OK to confirm the list of accounts.
To obtain an SID, open a command window with administrator privileges and run the following command:
WMIC useraccount get name,sid
Volume typeEnable the volume type(s) on which this application runs: local disk on the workstation, network share (e.g., Samba/CIFS, DFS, etc.) or removable device (e.g., USB key, external hard disk, mobile phones depending on their configuration, etc.).
Command lineFilter applications based on arguments in their command line. making it possible to apply different rules to the same application, depending on how it is used. Refer to the next section for details on how to use the command line criterion.
Specifying more criteria will more accurately identify the application because all criteria must match.
EXAMPLE
By specifying the application PowerShell.exe signed by Microsoft, launched by the scheduled task schtasks.exe, running from the local disk via the account NT_AUTHORITY\System, all five criteria must match for the application to be identified.
- Click on Add an entry if you want to add another list of criteria for the same ID. Having several entries makes it possible to group various resources under the same ID, if the same security rules use them. For example, you can group various browsers together, or group various dangerous applications to set up a blacklist.
- Enable the option Include child applications of the applications identified below so that when a rule is applied to an ID, it will also apply to all of its child applications. This option helps to identify installation programs that are extracted into a temporary folder and run executable files that have random names. By declaring the installation program a legitimate program, all the temporary files that it creates and launches will also be considered legitimate.
- Click on OK.
- If you have finished creating application identifiers, click on Save in the upper banner.
- To show the contents of an application identifier without editing it, click on View.
TIP
Application identifiers can also be created directly from a rule. In a rule, click on , then on Create a new identifier.
Likewise, from a rule, you can click on a selected identifier to modify it. Changes will also apply to the identifier in the Identifiers tab.