Network Computingwww.networkcomputing.com

Whether you're protecting trade secrets or just trying to keep office automation systems running smoothly, whether you're part of a multinational corporation or a small startup, following a few basic principles will go a long way toward building a safer computing environment.

Put together a security policy team, with representation from key functional areas-not just the IT group. Involve groups whose data assets are most at risk, such as finance or human resources. Garner as much visibility for the security team as you can muster, particularly among the upper management ranks. The team should identify the most valuable data and systems, assess the impact of losses or downtime and develop a plan for improvement. Focus on pinpointing real actions that will make assets more secure, not on simply filling binders on a shelf.

Define and separate the roles of security officers, s ystem administrators and implementation reviewers. No matter how professional a system administrator is, another person should assess how well policies are implemented.

Establish periodic security audits of existing systems, and include security considerations early in the project planning process. Conduct security reviews at major milestones of a new system implementation.

Write a disaster recovery plan, even if it's just a list of phone numbers to call when things go awry.

Ensure that systems are well documented, starting at the physical layer. Create overlays for logical networks, such as by protocol and service. Examine where logical networks overlap, and look for hidden links between networks.

Review perimeter devices, such as firewalls and remote access servers. Apply the correct amount of security to these items, but don't go overboard. It's likely that your real threats lie elsewhere .

Educate users on their role in keeping information safe. Set a goal to build a s tate of continual awareness.

Simplify systems as much as possible. You can't secure what you can't understand. Use common directory services such as NIS or NDS to minimize the number of accounts, and limit the number of passwords that users must remember. Use Radius to manage perimeter authentication across heterogeneous systems, or one of the TACACS variants in pure Cisco environments.

Limit your risk. Turn off host services you don't use. Don't advertise network services to locations that don't need to know them-you'll save on network traffic as well as make it more difficult to hack. Similarly, separate internal and external DNS servers, and review the corporate directory service from a security viewpoint.

Make security transparent and automatic. Ask users to do as little as possible. Enforce policies on Java and ActiveX at the point at which they enter your network. Screen viruses at this point, as well as at the server. On client PCs, execute automatic virus scans on disks.

R estrict application process accounts (daemons, services, NLMs) when possible. For example, don't allow web server child processes to run as root. Don't run services as NT Administrator unless required to do so.

Inform users about open security threats that you can't close. For example, executables received via email and ActiveX components with unknown sources should be examined carefully before execution.

Be aware of the inside threat. If you're serious about accountability, require strong authentication always, even within the firewall.

Keep up with organizational changes. Incorporate user account administration into the hiring, firing and reassignment process. Don't allow users to retain authorizations as they move between jobs.

Physically secure servers and key network components. For example, NetWare and Windows NT servers may be highly secure when accessed remotely, but easily cracked by someone a t the console.

Forbid the sharing of accounts, especially privileged acco unts. Sharing undermines accountability, making it impossible to know who did what, and it can inadvertently lead to system leaks. For example, by default, Windows95 keeps a cache of passwords, which allows remote server access to cascade from the user's desktop ID, and into the hands of any serious hacker.

Avoid security tool frenzy and use what's built-in. There is no silver bullet to make your network secure, but you must make use of what's available to keep from being blindsided. For example, everybody should use built-in operating system security assessment tools and have anti-virus software available. Be smart: Examine potential risks first, before you make a big investment in security products.

For all its benefits, RADIUS does not assist users in establishing encrypted communications sessions, and the dialog between the NAS and the RADIUS server is not encrypted. Kerberos fills the gaps. It may work in tandem with RADIUS, although the ov erlap of services is pretty large. Kerberos was created at MIT to provide mutual authentication between end systems, or "principals"; it provides some assurance that the principal at each end of a conversation is who it claims to be, encrypting some of the dialog between principal and the Kerberos Key Distribution Center (KDC).

KDC also provides a session key that may be used for encrypting the dialog between principals. Kerberos is mainly geared to symmetric key distribution. Extensions are being discussed that would handle public keys, but large public key infrastructures are most often implemented in Certificate Authorities (more on these later).

Beyond this, Kerberos has little to offer, relying on other services for authorization and accounting (see "Kerberos: A Piece of the Net Security Puzzle," December 1, 1996, page 156). The modifications required to "Kerberize" an application are fairly trivial, but there is very l ittle software that supports it. The currently implemented version-versio n 4-suffers from scalability problems generated by the way peer relationships between individual security domains, or realms, are set up.

Kerberos version 4 becomes very tricky to manage as the number of realms increases, especially when applications seek resources between realms. If you have n realms, with users and resources spread around them, you may need as many as (n-1) interrealm relationships to support them.

This problem should be familiar to managers of very large Windows NT networks, since NT is even less scalable because domain trusts (the equivalent of interrealm relationships) are not bidirectional. Therefore, you may need as many as 2(n-1) connections defined. The approach simply doesn't work in large environments, leading to performance bottlenecks at domain controllers and security holes when all of the relationships become too much to track.

Kerberos version 5 will address the scalability problem by building a hierarchy of realms that eliminates the need to explicity intr oduce each realm to all others; Microsoft is borrowing from Kerberos v5 with NT version 5 to eliminate performance problems associated with domain controllers and registries. Instead of flat, peer-to-peer relationships between domains, Kerberos 5 security will move to a hierarchical directory with transitive trusts-in other words, if A trusts B and B trusts C, then A trusts C. Transitive trusts, once considered a security weakness because of unpredictable side effects, now are recognized as an aid to management, and perhaps to security. One-way trusts will still be used, not to establish the relationships in the tree but to restrict them.

The National Computer Security Center's C2 security is frequently cited as a benchmark for measuring an operating system's strength (see "Stepping Up to Big Challenges," Network Computing, December 1, 1996), but it only indicates wh ether an OS can comply with certain secure implementations. The con figurations that gain C2 certification are almost never what you'd actually install, are slanted toward military and government applications, and don't address a product's default security configuration. Compliance should not be the basis for judgment of a product's security.

The Open Group Baseline Security 96 Brand addresses business security needs by branding products that support the Open Group Baseline Security Services (XBSS) specification. Like C2, XBSS addresses core security services like auditing, access control and accountability, but it also covers secure system setup and installation, policy parameters, separation of roles and password authentication requirements.

To earn an Open Group brand, vendors must agree to support the given standard through the lifetime of their branded products. Open Group participants include most major players, such as SunSoft, Microsoft Corp. and IBM Corp. This is a new initiative, and there is no guarantee that vendors will adopt the branding scheme-but we hope they do.

A year ago, a storm was brewing over Internet security in the browser: Was it better to secure the Net at the HTTP level via S-HTTP, or to use the lower-level Secure Sockets Layer (SSL) protocol? Since then, SSL has emerged as the de facto protocol for ensuring a private connection between a web browser and a server. Although version 3 is implemented in current browsers, it's not yet an IETF standard. An IETF working group is examining a similar protocol, Transport Layer Security (TLS), which simplifies the SSL 3.0 protocol and incorporates elements of Personal Communications Technology, a Microsoft technology.

Sitting on top of a reliable transport protocol-for example, TCP or even IPX/SPX-is SSL's most important component: the SSL Record Protocol, which encapsulates higher-level protocols such as the SSL Handshake Protocol. SSL Handshake negotiates the secure attributes of a session, such as what algorithms will be used for authentication and encrypti on. In this way, both parties can find the most secure, common way to communicate.

SSL uses symmetric key mechanisms such as DES or RC4 for encryption, and uses public key certificates for authentication. It also provides for message integrity by computing a secure hash using SHA or MD5.