1.5 Ensure 'unique application pools' is set for sites

Warning! Audit Deprecated

This audit has been deprecated and will be removed in a future update.

View Next Audit Version

Information

IIS introduced a new security feature called Application Pool Identities that allows Application Pools to be run under unique accounts without the need to create and manage local or domain accounts. It is recommended that all Sites run under unique, dedicated Application Pools.
Rationale:
By setting sites to run under unique Application Pools, resource-intensive applications can be assigned to their own application pools which could improve server and application performance.In addition, it can help maintain application availability: if an application in one pool fails, applications in other pools are not affected.Last, isolating applications helps mitigate the potential risk of one application being allowed access to the resources of another application. It is also recommended to stop any application pool that is not in use or was created by an installation such as .Net 4.0.

Solution

The following appcmd.exe command will set the application pool for a given application:
%systemroot%\system32\inetsrv\appcmd set app '<website name>/' /applicationpool:<apppool name>
The output of this command will be similar to the following: APP object 'Default Web Site/' changed (applicationPool:DefaultAppPool)
Run the above command to ensure a unique application pool is assigned for each site listed
OR
Enter the following command in PowerShell to configure:
Set-ItemProperty -Path 'IIS:\Sites\<website name>' -Name applicationPool -Value <apppool name>
OR
1. Open IIS Manager
2. Open the Sites node underneath the machine node
3. Select the Site to be changed
4. In the Actions pane, select Basic Settings
5. Click the Select? box next to the Application Pool text box
6. Select the desired Application Pool
7. Once selected, click OK
Default Value:
By default, all Sites created will use the Default Application Pool (DefaultAppPool).

See Also

https://workbench.cisecurity.org/files/2297