In the .NET Framework version 4, the common language runtime (CLR) is moving away from providing security policy for computers. Microsoft is recommending the use of Windows Software Restriction Policies as a replacement for CLR security policy. The information in this topic applies to the .NET Framework version 3.5 and earlier; it does not apply to version 4.0 and later. For more information about this and other changes, see Security Changes in the .NET Framework 4.
The practices described in this section are applicable to every administration scenario. You should keep them in mind as you set up and administer your security policy.
Define applicable categories of trust that you can use to administrate policy. Define several code groups to discriminate code that is likely to be run in your environment and define the permissions that each group should receive. Craft policy accordingly and deploy. You should do establish your overall policy when you initially set up your environment, rather than piece-by-piece as you need to run various applications.
The policy level that you choose to administer is determined by the scope that you want to affect. Always administer security policy on the lowest policy level that impacts the fewest users and still satisfies your administration scenario. For example:
If you are administering a policy that affects every workstation and user in your enterprise, make the policy additions on the enterprise level. Never make an addition to the enterprise level of one computer that is not meant to affect every computer in your enterprise.
If you are administering a policy that affects all users on a particular computer, make the policy additions on the machine level.
If you are administering a policy for a particular user or group of users, make the policy additions on the user level.
Use the NTFS file system whenever possible to store the security policy files. NTFS helps provide file protection based on users and groups, and only allows users with administrative privileges for a particular level to edit security configuration files. Systems that do not use the NTFS file system create security weaknesses by allowing unauthorized users to modify security policy.