In recent years, security has become an increasingly
important part of the network designer’s and administrator’s jobs.
Security is no longer an afterthought; you must include security
considerations in all your network planning from the outset, and at
every level. Nearly all the remaining lessons in this book are concerned
with security issues, but before you deploy the security features in
Windows Server 2003, your organization should have a framework for
designing and implementing security policies.
High-Level Security Planning
Windows Server 2003
includes a great many security features, tools, and capabilities. Much
of this book is devoted to the processes involved in planning,
implementing, and maintaining these features. However, before you deploy
specific security features, someone must decide which features are
appropriate for your organization. A security framework is a logical,
structured process by which your organization performs tasks like the
following:
Estimating security risks
Specifying security requirements
Selecting security features
Implementing security policies
Designing security deployments
Specifying security management policies
This lesson, therefore, is
concerned not so much with developing a security solution for your
organization, but with the process your organization uses to develop a
security solution.
Creating a Security Design Team
Security
is not strictly an IT issue anymore, so the first step in creating a
security framework is to determine which people in your organization are
going to be responsible for designing, implementing, and maintaining
the security policies. Technical people, such as network administrators,
might be familiar with the capabilities of specific security mechanisms
and how to implement them, but they are not necessarily the best people
to identify the resources that are most at risk or the forces that
threaten them. Management might be more familiar with the resources that
need to be protected and the potential ramifications of their being
compromised, but is probably not familiar with the tools that can be
used to protect those resources. There are also economic issues to
consider, and the effect of new security policies on employee
productivity and morale.
All these
arguments lead to the conclusion that most organizations need to
assemble a team or committee responsible for providing a balanced
picture of the organization’s security status and capable of deciding
how to implement security policies. The number of people on the team and
their positions in the company depend on the organization’s size and
political structure. A well-balanced team should consist of people who
can answer questions such as the following:
What are your organization’s most valuable resources?
What are the potential threats to your organization’s resources?
Which resources are most at risk?
What are the consequences if specific resources are compromised?
What security features are available?
Which security features are best for protecting specific resources?
How secure is secure enough?
What is involved in implementing specific security features?
How do particular security features affect users, administrators, and managers?
Mapping Out a Security Life Cycle
Creating a security
framework is not a one-time project that ends when you have finished
designing the initial security plan for your network. Security is an
ongoing concern, and the responsibilities of the security design team
are ongoing as well. A security life cycle typically consists of three
basic phases:
Designing a security infrastructure
Implementing security features
Ongoing security management
These phases are discussed in the following sections.
Designing a Security Infrastructure
The
initial design phase of a security infrastructure should run
concurrently with the network design. Security issues can have a major
effect on many elements of your network design, including the hardware
components you purchase, the locations you select for the hardware, and
how you configure individual devices. The design phase begins with
identifying the resources that need protection and evaluating the
threats to those resources.
Even the smallest
organization has information it should protect, such as financial data
and customer lists. Other valuable commodities might include order entry
data, research and development information, and confidential
correspondence. In more extreme cases, your organization might possess
secret government or military information. The threats to your data can
range from the casual to the felonious. In many cases, a modicum of
security can protect your confidential data from curious employees and
casual Internet predators. However, targeted threats, such as those
mounted by business competitors and even rival governments, require more
serious security measures.
Tip
In
addition to deliberate attempts to penetrate security, your
confidential data is in danger from accidents, thefts of equipment, and
natural disasters. When planning the protection of your data, don’t
forget to include fault tolerance solutions that can prevent data loss
due to drive failures, fires, and other accidents. |
Once your team has
identified the resources that need protection and has determined how
severe the threats are, you can plan how to secure them. This is where
the technically oriented members of the team come into play, because
they are familiar with the security measures that are available and what
is involved in deploying them. Depending on the requirements of the
organization, the security plan might consist of merely taking advantage
of the features already included in the network’s operating systems and
other hardware and software components or you might have to purchase
additional security products, such as firewalls, smart card readers, or
biometric devices.
A typical security plan for a network includes implementations of the following security principles:
Access control
The granting of specific levels of access based on a user’s identity.
Access control capabilities are built into most network operating
systems and applications.
Auditing
A process by which administrators monitor system and network activities
over extended periods. Most network operating systems and applications
include some form of auditing that administrators can configure to their
needs.
Authentication
The verification of a user’s identity before providing access to
secured resources. Authentication mechanisms can use encrypted
passwords, certificates, and hardware devices such as smart cards and
biometric sensors, depending on the degree of security required.
Encryption The
process of protecting data through the application of a cryptographic
algorithm that uses keys to encrypt and decrypt data. The strength of an
encryption mechanism is based on the capabilities of the algorithm
itself, the number and types of keys the system uses, and the method of
distributing the keys.
Firewalls
A system designed to prevent unauthorized access to a private network
from outside. Firewalls can use a variety of mechanisms to secure a
network, including packet filtering, network address translation,
application gateways, and proxy servers.
The security plan is not
just a matter of technology. Your security team is also responsible for
creating security policies for the organization. For example, you might
agree to use encrypted passwords for user authentication, but you must
also decide who is going to supply the passwords, how long the passwords
should be, how often they should change, and so forth.
Implementing Security Features
After deciding
what security mechanisms you are going to use and designing your
security policies, the next step is to devise an implementation plan for
these mechanisms and policies. In some cases, the implementation plan
might consist of a procedure and timetable for the process of
evaluating, purchasing, installing, and configuring security hardware
and software products. For security mechanisms included with operating
systems and applications, the implementation plan might consist of
modifications to an existing installation or configuration routine.
Implementing
security policies can be more problematic than implementing security
technologies, because you must devise a way to disseminate the policies
to everyone who needs them and to ensure compliance. In some cases, your
software will contain mechanisms that enable you to enforce your
policies; in other cases, you might have to compel your users to comply
using other methods (such as gentle reason and logic or, failing that,
bribes and threats).
|
For a simple example,
your team might decide that the network users must use passwords at
least eight characters long, containing numeric characters and symbols
as well as letters, and that users must change their passwords once a
month. You can advise the users of these new requirements by sending a
general e-mail, but the most important part of the implementation plan
would be using a tool like Windows Server 2003 group policies to enforce
your requirements. In this case, Windows Server 2003 has preconfigured
password policies that enable you to require the use of eight-character,
complex passwords, modified every 30 days. In other cases, however,
enforcing compliance might be more complicated, for example, asking them
not to store their password information in their unlocked desks.
|
Ongoing Security Management
With
your security mechanisms and policies in place, you might be tempted to
think that the work of your team is finished, but this is definitely
not the case. Security is an ongoing concern that requires the continued
attention of the entire team.
For the
technical staff, security management means regular checking of audit
logs and other resources, as well as monitoring individual systems and
network traffic for signs of intrusion. Administrators must also update
the security software products as needed. Beyond these regular tasks,
however, the entire team must be aware that the organization’s security
situation changes constantly. Every day can bring new resources to
protect or new threats to existing resources. Security is often an arms
race between the intruders and the protectors, and whichever side allows
itself to become lax or complacent ends up losing the race.
