Policy-Based Networking

team lib

If the most common utopian dream of a hard-pressed network manager is the self-healing network, the second most common is the policy-driven network. It goes something like this: Upper management establishes policies-a set of principles concerning the availability of computing resources to employees and departments; the objectives and resources that will be made available for safeguarding the organization's data and computing assets; and factors that are sufficiently important to create exceptions to these principles. These policies are then entered into the distributed system, after which they are cascaded out to each desktop, server operating system, application, directory service, database, router, and VLAN.

This (fantasy-based) procedure automatically builds a call-response system, which informs users of any policy-based constraints or limitations that might be obstructing their access to certain resources. The system also points departments and users in the right direction if they need to change something: "Press 1 if you have forgotten your password. Press 2 if your department needs video conferencing at the desktop every day. Press 3 if you need encrypted e-mail."

No doubt, this pleasant dream will remain forever unattainable. But standards organizations and vendors are making efforts to help automate some of the steps of policy implementation for networked systems.

Policies, Practices, And Procedures

Policies are more general and abstract than practices, which in turn are more general than procedures. For example, policies might be, "Every employee will have access to e-mail and calendaring applications." Or, "The organization has legal and moral obligations to maintain the confidentiality of customers' personal information with respect to anyone outside the organization or anyone within the organization without a specific need."

Sample practices might be, "New employees will be assigned e-mail and calendaring accounts on their first work day. They will be scheduled for training within 30 days." Or, "Only members of the Customer_Confidential group will be permitted to look up confidential customer data. Physical security devices will be employed to assure better confidentiality than a password-only system provides."

Sample procedures might include such statements as, "Employee mail accounts are named according to the following system: Firstname_Lastname. Duplicate first and last names are resolved by having the employees with the least seniority insert their middle name in this way: Firstname_Middlename_Lastname. Names not resolved by this method will be referred to the Chief Directory Officer for resolution. It is the user 's responsibility to archive messages. The IT organization will maintain backups of current messages." Here's another example of a procedure: "Members of Customer_Confidential will receive read-access rights to tables X, Y, and Z in the Customer database. They will use a card key and a six-digit PIN to log in. All the data in tables X, Y, and Z will be encrypted using Triple DES."

Policies are generally expressed in ordinary business language; they don't address implementation methods. Practices address implementation methods , but not at the level of specific products, data structures, and keystrokes; these specifics are covered in procedures. The advantage of having three specification levels is that changing particular products or vendors should not generally require changing practices. Additionally, practices that do a better job of carrying out policies can be adopted without high-level policy debates. Wise organizations encourage broad participation when formulating policies. Widespread understanding of why policies are the way they are make the derivation of practices from policies smoother and less politicized than would be the case if policies were mandated by a small group of executives or IT staff. Moving from practices to procedures is a technical (and budgetary) matter that should be relatively free of organizational politics.

Different organizations have various levels of commitment to developing and maintaining documents related to policies, practices, and procedures. Large, distributed enterprises with numerous resources will typically have a greater need than small organizations for documenting uniform policies, practices, and procedures. For educational institutions, spelling out user responsibilities and prescribing consequences for abusive activities might have a high priority. Financial institutions will certainly have strong incentives to explicitly document the steps they take to secure data and prevent tampering. To minimize bureaucracy, every organization needs to determine which aspects of its business need to have policies, practices, and procedures spelled out in detail.

Common Policy Target Areas

The most common subjects for policies include distributing resources, defining security requirements, and setting performance expectations. Resource distribution might include defining the accounts and access permissions users are entitled to; spelling out the kind of desktop configurations various classes of users can expect; defining the role of mobile-computing and work-at-home resources; and establishing the applications the organization makes available and users' obligations with respect to those applications.

Security policy is a huge area that includes many topics not directly related to distributed systems policies. For example, organizations need procedures for physically securing the premises, as well as for teaching users how to resist "social engineering." Nevertheless, there are many important areas of overlap between security policy and distributed systems policy. Backup and restore procedures are one example. Disaster recovery plans are another. Other related topics include the usual network security items, such as data integrity, confidentiality, continuity of service, and nonrepudiation, which are implemented via such tools as authentication, access control, virus protection, encryption, a public key infrastructure, and intrusion detection.

Performance policy is often a matter of setting priorities among users, groups, and applications. Should a resource become scarce , the most important operations should be the last to suffer. The biggest constraint in most environments is wide area throughput, and many products and proposed standards that refer to policies emphasize the particular practices and procedures that prioritize WAN traffic. Routers and switches are often equipped with multiple queues; traffic is steered to the shortest queues based on addresses, port numbers , and other characteristics, providing a crude sort of Quality of Service (QoS) hierarchy. The RSVP Working Group is working to define the Common Open Policy Services (COPS) protocol, which will make it easier to prioritize traffic on IP networks that define resource reservations . Of course, one of ATM's strengths is its rich set of built-in mechanisms for defining QoS.

Policy fulfillment and Service Level Agreements (SLAs) also come together in performance and availability. Many performance and availability goals can be more aptly described as policy statements than as SLAs, because an organization's internal "customers" are generally not paying for IT services and thus have no incentive to accept particular service levels or to negotiate them realistically .

Policies And Directories

In order for practices and procedures to be implemented, a great deal of information must be captured and maintained , as well as easily accessed. If directory proliferation wasn't a serious problem before installing a policy-based network, putting a set of policies, practices, and procedures in place would itself cause a directory overload. In addition to applications, NOSs, and host gateways-each of which requires its own passwords and access control mechanisms-you have to keep track of desktop configuration standards and compliance; IP addresses, DHCP leases, and DNS data; firewall settings; public keys; digital signatures; remote access authentication and accounting; and traffic priorities-all the things policies affect. Without interoperable directories, each of these policy areas could result in yet another directory. In addition, as Internet commerce becomes more and more feasible , the need to tie organizational roles to purchasing authority and to other restricted activities will require new directory information and access to a public key infrastructure- potentially even more new directory fodder.

Fortunately, vendors and standards bodies are addressing the directory-proliferation problem by developing extensible, replicable, communicative directory services, thereby eliminating the need for new directories for every new application. Directories must be extensible because no matter how complete their features might be, not every aspect of applications, services, security measures, and corporate roles can be anticipated. Replication allows organizations to copy relevant portions of a directory to a database close to the users and applications that need the information. Directories that can communicate with other directories don't have to be comprehensive and universal, so the problems of synchronizing multiple repositories are minimized.

The NetWare Directory Service, NDS, has been extensible and replicable since its introduction, and version 5 fully supports Lightweight Directory Access Protocol 3 (LDAP-3), the first truly workable version of that directory access protocol. Microsoft's Active Directory, due out with Windows NT 5.0, will for the first time support LDAP and an extensible schema. Metadirectories , such as Zoomit's VIA (the company was acquired by Microsoft in 1999), provide an alternative means of binding together disparate directories.

NOS directories have long been the most important databases for storing server account and basic security information, including password authentication, server access control mechanisms, and even local data encryption mechanisms. Extended versions of these directories are natural repositories for the policy data of the future. Novell extended the role of NDS for managing desktop configurations and application software with its ZEN Works products. NetWare 5 also enables NDS to perform many public key infrastructure functions. The NetWare 5 directory also lets NDS be a DNS server and a DHCP server. The Microsoft Active Directory is also tightly integrated with DNS and DHCP, as well as PKI elements.

In 1996, Microsoft and Cisco Systems announced an initiative called Directory Enabled Networks (DEN), which aims to define directory schema extensions for networks, especially in the areas of performance and traffic prioritization. This work will help minimize the need for multiple directories and reduce the risks of duplicating data. After incorporating input from several hundred companies, Microsoft and Cisco turned the DEN project over to the Desktop Management Task Force (DMTF), which folded the DEN schema into its Common Information Model (CIM). (CIM is the DMTF's candidate specification for managed objects independent of protocols, OSs, programming languages, and object models.)

Not all the information relevant to traffic control and policy-based transactions belongs in a directory. Dynamic, fast-changing data about networking devices, for example, probably won't work well in a repository designed for relatively long-lived data and whose replicas converge on a single data model over a period of minutes or hours rather than in real time. This need for supplementary data storage facilities is an additional incentive for using metadirectories that can tie multiple directory services together.

Several other vendors have begun to move beyond the dedicated directories for each application or device. Integrated security vendors, including Check Point Software (Redwood City, CA) and Internet Devices (Sunnyvale, CA), have announced intentions to support LDAP in their products, and have taken steps to design user interfaces that provide a broad view of security and traffic management policies. 3Com has announced an ambitious framework called Policy-Powered Networks. It includes Policy Server, an LDAP-compliant directory that holds the data and procedures for determining specific policy actions; Policy Manager, an application that lets users define rules; compliant switches, routers, and NICs (called enforcers ), which carry out the actions specified by the Policy Server; other directories, which the Policy Server can query via LDAP; and compliant applications that can request specific services or classes of service.

Developing usable, consensual policies and practices will always require hard work. Over the next few years , vendor efforts and the development of standards will make implementation simpler and less error prone than it has been.

This tutorial, number 121, by Steve Steinke, was originally published in the August 1998 issue of Network Magazine.

 
team lib


Network Tutorial
Lan Tutorial With Glossary of Terms: A Complete Introduction to Local Area Networks (Lan Networking Library)
ISBN: 0879303794
EAN: 2147483647
Year: 2003
Pages: 193

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net