There are a number of ways of implementing adaptive security policies for security architectures which separate the definition of the policy from its enforcement. From the entire range of such implementations, this paper has examined four possible methods all of which have been implemented for the DTOS prototype by Secure Computing. Each implementation has strengths and weaknesses, and the trade-offs are encapsulated in Table 6 below. From the table, the server stack and the extended state appear to be the most attractive options for implementing adaptive security, but which choices one makes depends on the eventual application for the implementation as suggested below.
| Criteria | Implementations | |||
|---|---|---|---|---|
| Reload Policy | Expanded State | Hand-Off | Server Stack | |
| Policy Flexibility | Fair | Good | Fair | Excellent |
| Functional Flexibility | Poor | Good | Fair | Excellent |
| Security | Good | Excellent | Fair | Poor |
| Reliability | Fair | Excellent | Poor | Good |
| Performance | Good | Excellent | Poor | Fair |
Table 1: Summary of Trade-Offs
When applied appropriately, reloading the policy and the expanded state methods are the lightest weight implementations and provide good features for a narrow set of applications. In particular, the key features of these two methods are that they allow the Security Server to change the database without changing the algorithms from which the Security Server makes its security computations. The database and Security Server implementations for the expanded state have the potential to become complex. The additional complexity posed by this work may make alternate methods for implementation more attractive. The expanded state method is best left to small, incremental changes in the policy. By comparison, reloading the policy is probably not a an attractive option for system in which there are a large number of small changes to the databases since each change of policy would require its own database, and the issue of scalability may be burdensome.
The other two methods, the hand-off and server stack, allow for changes to the algorithms for computing permissions, and this is what accounts for the greater degree of policy flexibility. Because of the multiple points of control, the security server stack offers the greatest functional and policy flexibility, and the inheritance structure of the parent-child relationships between Security Servers offers the ability to grandfather permissions for running applications. However, that very same asset is a liability. Policy changes using the stack are local, not global. Thus, it is not possible to revoke permissions using that method alone. Furthermore, depending on the number of policies supported by the system, the security server stack holds the potential for being the heaviest weight implementation.
Not addressed in Table 6 is the possibility of mixing and matching the four methods described in this paper to capture the best security features of one method with the best flexibility features of another. For example, one might combine the security server stack and with the hand-off method in the following way. Tasks would operate under task-based policies with the server stack up to a certain point in time, allowing for local changes to the policy based on roles and tasks, and then a server might hand off to its parent and shut down. For example, in the banking application in which the more restrictive nighttime policy is the child of the less restrictive daytime policy (i.e., the stricter Security Server is pushed onto the stack at 5 PM), the nighttime server could hand off to its parent the following morning at 8 AM and shut down. Similarly, one might follow the hand-off or server stack by reloading the policy to change the internal tables of a Security Server without changing the fundamental algorithms by which it operates.
Current work on adaptive security has focused on theoretical aspects of adaptive security policies and on various mechanisms for implementing adaptive security. Future work on adaptive security policies should turn from the theoretical to the applied, hopefully by implementing a demonstration system. For example, one might implement a set of banking applications that would operate under policies for daytime and after-hours processing. A demonstration system of this type should also be accompanied by formal assurance evidence such as a formal security policy. However, until there is a real system to examine, formal assurance for adaptive security can only be speculative.