• The software restriction policies are used to define which programs are allowed or disallowed in the system. They are commonly used in corporate environments where parental controls are not able to be used.





• Some of the AppLocker enhancements over software restriction policies include:
• Rules can be applied to specific users and groups rather than all users
• Default rule action is deny to increase security
• Wizard to help create rules.
• Audit only mode for testing that only writes events to the event log


• You can audit or enforce AppLocker rules. Auditing or enforcement relies on the configuration of appropriate rules and the Application Identity service.


• The following rules collections are:





• Executable: These rules apply to mexe and mcom files. Use these rules to control which applications users can run.
• Windows Installer: These rules apply to .msi and .msp files. Use these rules to control which users can install applications and from what locations.
• Scripts: These rules apply to .ps1, .bat, .cmd, .vbs, and .js files. Use these rules to control which users can run scripts.
• DLL: These rules apply to .dll and .ocx files. Use these rules to verify that the DLLs used by applications are not modified or unknown. These rules are not enable by default due to negative performance impact.

For each rule collection, you can:

• Create a New Rule: This allows you to manually specify the characteristics of a rule. To create rules in this way, you must understand the exact end results that you are trying to achieve.
• Automatically Generate Rules: This scans your computer and creates rules that match the current configuration of your computer. In a larger corporate environment, you can create the rules on a standardized reference computer and then apply them to all computers in the organization. You should review the rules before applying them.
• Create Default Rules: This creates standardized rules for a rule collection that meet the needs of many users and organizations. Because these rules are very general, they provide less security than automatically generated rules but are generally easier to manage. The default rules created vary for each rule collection.
• Each rule contains permissions that define whether the rule allows or denies software the ability to run.




Permissions also def ne which users the rule applies to. A rule can be applied to an individual user or group, but not multiple users or groups. This means it is very important plan out which groups to use for allowing access.

In general, the best strategy for applying rules is to begin by creating rules that allow access for larger groups of users. Then you can restrict smaller groups or individuals with a rule that denies access or create an exception within the original rule. The deny permission overrides the allow permission when multiple rules apply for a user.

• Rule conditions define the software that is affected by the rule. There are three conditions that can be used:
• Publisher
• Path
• File hash

The publisher rule condition identifies software by using a digital signature in the software. If the software is not digitally signed, you cannot use a publisher rule condition to identify it. Consider using a file hash rule condition instead.

• Rule exceptions: An AppLocker rule exception defines software that the rule does not apply to. In general, you use rule conditions to define a large set of software and then use exceptions to define a smaller set of software that the rule does not apply to. Similar to rule conditions, when you add an exception, it can be based on publisher, path, or file hash. You can add multiple exceptions to a single rule.

Activity 7-3