|
While configuring a single device for even a complex access rule is
relatively easy, the same can't be said for configuring multiple
devices on a network. Access to network resources tends to be
controlled on a component-by-component basis. And when there's no
policy infrastructure or unifying set of policy components, things can
get difficult.
To make matters worse, different devices implement different parts
of security policy. Those at the edge of the corporate network, like
firewalls, routers, RASs (remote access servers), and VPN (virtual
private network) gear, allow wholesale access. Such devices as proxy
servers handle access from within the network to the outside world.
And within the network, individual servers and workstations have
access cont
rols like Windows NT logins and Kerberos tickets.
These controls usually aren't implemented in a way that allows
policy to be applied across equipment boundaries. Different devices
may offer the same user different levels of access, eliminating any
chance of deploying an effective security policy.
This kind of compartmentalization doesn't help in network
administration either. When an employee leaves an organization, for
example, net managers face the tedious task of finding and
reconfiguring all the devices the employee had access to. The
piecemeal approach also makes it more difficult to track down network
intruders. If an attacker tries to break into a mainframe through a
firewall, the attempt may show up in the log of one but not the
other.
Multiple points of access, multiple devices controlling policy, and
multiple groups enforcing policy. Is it any wonder that implementing
an effective, unified policy is so difficult?
On the Same Page
Fortunately, all three of
those problems can be addressed.
Synchronization is the key: Make sure that all staff and all devices
implement the same set of policies.
Start with the issue of multiple points of access. Each device
should have the same idea of who is granted access. Network managers
can and should set up processes to synchronize different sets of
authorized users on various devices. For example, the users in a RAS's
access list should be the same as those authorized by the router
linking the RAS to these users' various LAN segments. (Besides
simplifying administration, synchronization also makes it easier to
audit usage.)
But no matter how well synchronized the access lists, policy will
always have to be enforced on multiple components. Regardless of the
network device involved, there's going to be some sort of database
(generically speaking) containing access information. Whenever
possible, net managers should set up procedures to allow databases to
be combined—or at least compared.
Ideally, t
his process can be automated, with devices producing
machine-readable versions of their policy databases and exporting them
to some central policy server. Policy information would then flow in
the opposite direction, out to the various devices in the network. But
such systems generally aren't available yet; thus, net managers end up
inventing their own policy server through the consolidation
process.
While vendors today don't share policy in an interoperable data
format, there are several ways net managers can get a jump on unifying
access control information. First, use CAs (certificate authorities)
and X.509 digital certificates when possible (see
"Certificate
Authorities: Who Do You Trust?"
page 54). A CA is among the most
powerful mechanisms available for distributing security policy.
Second, employ hardware-based tokens, like smart cards, to ensure that
only authorized users gain access to the network. Third, look for an
SNMP system that allows for securit
y policy changes to be implemented
globally, across devices from multiple vendors.
But even if policy databases can't be merged automatically, it's
still worth the effort to do so manually. Having them all reside on
one management workstation allows for much easier analysis, change
control, and auditing.
There's something else to remember when it comes to unifying
security policy: Several different groups are likely to be involved,
especially in large organizations. Obviously, the easiest approach is
for management to mandate that responsibility for policy be
coordinated and unified within the organization. Of course, that's not
always possible—and where it isn't, setting up an "inter-policy
committee" might be wise. It could help ease the tasks that require
cooperation, like determining roles during a network attack, major
corporate reorganization, or facility change.
Outsourcing is another option. Even if companies can't force their
different groups to synchronize policy efforts
, it may be possible for
all parties to work with one (outsourced) entity that ensures
consistency. Yes, this means there's an outsider managing security.
But that's a decision some businesses may be willing to make.
Getting it Write
Keeping the need to unify in mind, net managers can then get to
work designing the policy itself. This is a two-step process: writing
it and then implementing it.
Remember, the policy is essentially a description of the
permissions users and systems possess. For users, policy definition
issues include the basics—user name, password, directory access
rights, resource access rights, and e-mail access rules.
For network devices, policy is more protocol-oriented. Typical
issues here are the TCP/IP addresses a device may transmit to or
receive from; the applications a device may process; the routes a
device is configured to recognize; and the protocols the device will
respond to (this is especially useful in handling routing updates and
multicas
t protocols).
Policy device descriptions have to contain combinations of these
elements, resulting in rules like "FTP to this IP address is
permitted" or "e-mail from this host is denied." And as network access
requirements become more complex, policy has to evolve. An effective
security policy might today include rules like "use 40-bit RC4
encryption when transmitting data to the on-campus warehouse, but use
Triple-DES [Data Encryption Standard] when transmitting to the remote
warehouse."
As for implementing policy, the rule is simple: Policy should be
distributed to all devices in the enterprise. Net managers should be
able to query any networking device with questions like, "What systems
does employee 14937 have access to?" Devices should also share
auditing information, such as comparing the number of times a RAS is
used on weekends to the number of user logins to a file server during
the same period.
Network managers also should be able to distribute policy
changes—like move
s, adds, and changes—from a central
location. Under certain conditions it should be possible to apply
policy changes globally by broadcasting them to all devices.
Policy implementation also should address business processes. For
example, the routine for terminating an employee shouldn't merely
reside on page 289 of volume 17 of the network security operations
guide. There also should be software in place to execute a "terminate
employee" applet or batch file that sends e-mail and policy update
requests to all appropriate systems.
Policy In Place
A unified security policy also is essential when it comes to
corporate intranets and extranets. Here it's best to look at an
example of each to see how and where policy should be applied.
|
