ISCS version 0.1.1
Security Policies are one of the most powerful features of ISCS and a primary reason why it achieves such efficiency while at the same time minimizing exposure to human error. For all this power, they are amazingly simple to implement. Most of the work is done by creating the PEPs, Accessors and Access Groups, and Resources and Resource Groups. Security Policies just pull them all together.
Simply drag an Access Group onto a Resource Group or vice versa to provoke the Security Policy dialog shown in figure 1.
Figure
1
Choose what type of policy this should be, whether it should be enabled and add any descriptive comment up to 255 characters. We should take a moment to digress on DENY policies. Explicit DENY policies should be made as a last resort. They add significant overhead to both the SPM and the PEP and are rarely necessary. ISCS denies by default; if it is not explicitly allowed, it is denied. That alone eliminates most requirements for explicit DENY. Best Match addresses almost all remaining issues.
Consider this example. Let's suppose that there is a malicious public web server where a new trojan is sending stolen password files. We might consider creating a Resource Group named Internet Banned Sites and adding a Resource for HTTP on this malicious server to the Resource Group and creating a DENY policy for it. That would work but there is a better way. General HTTP Internet access comes through a policy granting access to HTTP to the World server (IP address 0.0.0.0-255.255.255.255). If we simply define the malicious server as Best Match enabled, it will be excluded from the World Server's range and users will not longer have access to it by virtue of their access to the World Server.
Existing policies may be enabled or disabled by clicking the enabled checkbox.