Effective security requires proper management. This means that the various steps from problem definition and inception until final implementation of hardware and procedures constantly need close attention. The security definition application must support the entire process of creating a security policy and transforming it into a security model for implementation and testing. Other integrated software applications may provide support for additional aspects of the management of the security life-cycle, including documentation and risk assessment. As we have discussed in the previous chapter, there exists a close relationship between risk analysis and the knowledge in our security expert system.
At some point this expert knowledge has to be made available to the central security management service. A security definition application consists of the tools that enable an expert to carry over his expertise to the system. Additionally, this component may also provide interfaces that allow for easy integration of the output of risk analysis packages into the security definition process.
The definition application works on the knowledge base by adding, refining or removing rules. It also integrates with the various system scanners to keep their vulnerability databases up-to-date. The definition application therefore needs access to well maintained -- and reliable! -- sources where bug exploits, protocol weaknesses and other attack scenario's are reported, so that the information in the system can be frequently and securely updated. The frequency with which the security scanners are activated can be set from the management console.
Other settings that can be changed by the security operator include the filtering rules from the monitor applications. More generally, the management console provides direct access to the various settings of the components that surround the central security management service so that it can be bypassed in case of an emergency or for routine inspection. One exception could be the access to the auditing application, where special access rules may apply in order to keep the auditing process consistent.
Setting up the whole adaptive security system consists of two major steps. At the side of the central security management service this implies creating a rule-base, creating a vulnerability database and inserting the appropriate engines to provide the required functionality. If the definition process were to stop here, the central security service would constitute a single point of failure. It is therefore required that the peripheral applications are also provided with default settings for their operation in case the central system would fail. Creating all the definitions and settings at one central point simplifies control and also allows for simulation to prevent contradicting settings. A simulation program also provides the possibility of performing a ``what-if'' analysis before changes are actually applied.
Peripheral applications could either be reconfigured through the central security management service or at the application itself. According to the first scenario, the security manager changes certain parts of the security definitions and asks the the central system to apply the changes. The definitions are examined for correct formatting and conflicts by the definition application and are then sent to the central security management system. Another check is performed there to see if the required functionality is available. The security management service sets up a security association2.8 with the peripheral application and has the application apply the changes. An exit code is returned from the application to the security management service who forwards it to the definition application on the management console. The whole process is logged by the logging application. This seems the preferred way of acting, because the changes are applied centrally and can be checked for compliance with the security policy and for correctness relative to the entire security system. Roles and associated access control rules can be enforced locally. It also allows for central logging of the various steps, which can help to trace who made which alterations.
Alternatively, the modifications are applied locally at the side of the peripheral applications. This means that every application must know who is allowed to make what changes and it makes it much more difficult to manage access rights and keep them consistent over a whole distributed system. Applied changes cannot easily be checked for consistency on a higher level. The central management system must be informed of the modifications and eventually change the knowledge base data. While the settings are actually modified, the monitors should not trigger any alarms.