You have a stand-alone computer named Computer1 that runs Windows 7. Several users share Computer1.
You need to prevent all users who are members of a group named Group1 from running Windows Media Player. All other users must be allowed to run Windows Media Player.
You must achieve this goal by using the least amount of administrative effort.
What should you do?
A. From Software Restriction Policies, create a path rule.
B. From Software Restriction Policies, create a hash rule.
C. From Application Control Policies, create the default rules.
D. From Application Control Policies, create an executable rule.
Correct Answer: D
Explanation/Reference:
Explanation:
Executable Rules
Executable rules apply to files that have .exe and .com file extensions. AppLocker policies are primarily about executable files, and it is likely that the majority of the AppLocker policies that you work with in your organizational environment will involve executable rules. The default executable rules are path rules that allow everyone to execute all applications in the Program Files folder and the Windows folder. The default rules also allow members of the administrators group to execute applications in any location on the computer. It is necessary to use the default executable rules, or rules that mirror their functionality, because Windows does not function properly unless certain applications, covered by these default rules, are allowed to execute.
When you create a rule, the scope of the rule is set to Everyone, even though there is not a local group named Everyone. If you choose to modify the rule, you can select a specific security group or user account.
NOT Default rules
Default rules are a set of rules that can be created automatically and which allow access to default Windows and program files. Default rules are necessary because AppLocker has a built- in fallback block rule that restricts the execution of any application that is not subject to an Allow rule. This means that when you enable AppLocker, you cannot execute any application, script, or installer that does not fall under an Allow rule. There are different default rules for each rule type. The default rules for each rule type are general and can be tailored by administrators specifically for their environments.
For example, the default executable rules are path rules. Security-minded administrators might replace the default rules with publisher or hash rules because these are more secure.
NOT Path Rules
Path rules, allow you to specify a file, folder, or registry key as the target of a Software Restriction Policy. The more specific a path rule is, the higher its precedence. For example, if you have a path rule that sets the file C: Program filesApplicationApp.exe to Unrestricted and one that sets the folder C:Program filesApplication to Disallowed, the more specific rule takes precedence and the application can execute. Wildcards can be used in path rules, so it is possible to have a path rule that specifies C:Program filesApplication*.exe. Wildcard rules are less specific than rules that use a file’s full path.
The drawback of path rules is that they rely on files and folders remaining in place. For example, if you created a path rule to block the application C:AppsFilesharing.exe, an attacker could execute the same application by moving it to another directory or renaming it something other than Filesharing.exe. Path rules work only when the file and folder permissions of the underlying operating system do not allow files to be moved and renamed.
NOT Hash Rules
Hash rules, work through the generation of a digital fingerprint that identifies a file based on its binary characteristics. This means that a file that you create a hash rule for will be identifiable regardless of the name assigned to it or the location from which you access it. Hash rules work on any file and do not require the file to have a digital signature. The drawback of hash rules is that you need to create them on a per-file basis. You cannot create hash rules automatically for Software Restriction Policies; you must generate each rule manually. You must also modify hash rules each time that you apply a software update to an application that is the subject of a hash rule. Software updates modify the binary properties of the file, which means that the modified file does not match the original digital fingerprint.
Explanation/Reference:
Explanation:
Executable Rules
Executable rules apply to files that have .exe and .com file extensions. AppLocker policies are primarily about executable files, and it is likely that the majority of the AppLocker policies that you work with in your organizational environment will involve executable rules. The default executable rules are path rules that allow everyone to execute all applications in the Program Files folder and the Windows folder. The default rules also allow members of the administrators group to execute applications in any location on the computer. It is necessary to use the default executable rules, or rules that mirror their functionality, because Windows does not function properly unless certain applications, covered by these default rules, are allowed to execute.
When you create a rule, the scope of the rule is set to Everyone, even though there is not a local group named Everyone. If you choose to modify the rule, you can select a specific security group or user account.
NOT Default rules
Default rules are a set of rules that can be created automatically and which allow access to default Windows and program files. Default rules are necessary because AppLocker has a built- in fallback block rule that restricts the execution of any application that is not subject to an Allow rule. This means that when you enable AppLocker, you cannot execute any application, script, or installer that does not fall under an Allow rule. There are different default rules for each rule type. The default rules for each rule type are general and can be tailored by administrators specifically for their environments.
For example, the default executable rules are path rules. Security-minded administrators might replace the default rules with publisher or hash rules because these are more secure.
NOT Path Rules
Path rules, allow you to specify a file, folder, or registry key as the target of a Software Restriction Policy. The more specific a path rule is, the higher its precedence. For example, if you have a path rule that sets the file C: Program filesApplicationApp.exe to Unrestricted and one that sets the folder C:Program filesApplication to Disallowed, the more specific rule takes precedence and the application can execute. Wildcards can be used in path rules, so it is possible to have a path rule that specifies C:Program filesApplication*.exe. Wildcard rules are less specific than rules that use a file’s full path.
The drawback of path rules is that they rely on files and folders remaining in place. For example, if you created a path rule to block the application C:AppsFilesharing.exe, an attacker could execute the same application by moving it to another directory or renaming it something other than Filesharing.exe. Path rules work only when the file and folder permissions of the underlying operating system do not allow files to be moved and renamed.
NOT Hash Rules
Hash rules, work through the generation of a digital fingerprint that identifies a file based on its binary characteristics. This means that a file that you create a hash rule for will be identifiable regardless of the name assigned to it or the location from which you access it. Hash rules work on any file and do not require the file to have a digital signature. The drawback of hash rules is that you need to create them on a per-file basis. You cannot create hash rules automatically for Software Restriction Policies; you must generate each rule manually. You must also modify hash rules each time that you apply a software update to an application that is the subject of a hash rule. Software updates modify the binary properties of the file, which means that the modified file does not match the original digital fingerprint.
