1.3 Policy-Based Self-Protection in Computer Networks
Policy-based management in network administration has been practiced for more than a decade and has been used successfully in many application areas. A common usage of policies in network management is to regulate the traffic in the network, especially dealing with the security, access control, and quality of service of different traffic streams. Some examples of network traffic security policies include the following:
Allow telnet connections out of the local network.
Block telnet connections into the sites on the local network.
Allow only secure HTTP traffic, and block any other traffic into the local network.
If a UDP packet on an illegal port is received from an external computer, disallow any communication to that computer.
The enforcement of these policies within the network, which is the target system in this case, needs to be managed in the context of the configuration of a specific network. If we consider a simple model of network access protection, in which access to the local network is secured and protected by means of one or more perimeter firewalls, then the policies can be readily seen as configuration constraint policies as described in the previous section. The enforcement of these policies requires that the configuration of the firewall be done in a manner that is consistent with these policies. In this case the attributes are source and destination IP address and ports.
As in the previous example, we need to have means to specify the policies, interpret and enforce the policies, and distribute policies from the entity specifying them to the entities interpreting and enforcing them.
For the purpose of defining policies, a machine-readable language needs to be developed for their specification. For access control and security policies, the language could be a standard access control policy language such as the “eXtensible Access Control Markup Language” (XACML) [OASI] from the Organization for the Advancement of Structured Information Standards (OASIS) or some other policy languages with similar capabilities.
The firewalls in the system need to implement and enforce the access control policies. If they are able to interpret the language selected for specifying policies, they can take the policy as it is specified for enforcement. Otherwise, a translation of the policies to a format that the firewall can interpret needs to be done. In some cases, the policies might not be able to be translated easily into a firewall configuration. An example would be the presence of a policy requiring that a notification should be sent out to the administrator whenever an access attempt to a forbidden site is made. Because the firewall is not capable of sending notifications—it merely records passively the sites that users are trying to access—an additional mechanism is needed. In this case, an independent software package would be required to periodically collect the records of which sites were accessed by each user from the firewall, and then process them to check whether a notification needs to be generated.
If there is more than one firewall in the system, we need to have a mechanism that will keep the policies specified in different firewalls consistent. Although this can be done manually, it would be more convenient to have an automated mechanism to dispense and distribute the policies. Various alternative approaches to the distribution of policies can be developed and they are discussed in detail in Chapter 5, “Policy Transformation and Analysis.”
In another variation of self-protection, policies may be defined that indicate how the set of applicable policies ought to be changed. As an example, if a system detects that the system is under attack by a newly identified infected host, the applicable policy rules may be augmented to prevent traffic from that infected host to reach the rest of the network.
There are several other uses of policies in managing computer networks. The application of policy-based fault management in computer networks is discussed in detail in Chapter 7, “Policy-Based Fault Management.”