CONTENTS
In this chapter, you will learn how
to maintain a secure system. A system is simply a collection
of computers, applications, data, and people. A secure system,
on the other hand, is a system that includes only authorized
people performing authorized functions with specific applications
to properly accessible data.
Secure systems are different from secure
data, which involves making sure that when, where, and how
data is stored is secure. Secure means inaccessible by unauthorized
people who would otherwise alter or view that data. Secure
systems also differ from secure transmissions, which involve
transmitting data so that it is safe from prying eyes. Because
the concepts are different, dealing with them all at once
is, in the planning stages, inappropriate. Deciding which
users to let use your main database will only be clouded
if you are also trying to decide what encryption scheme
to use. This confusion will result in the creation of incomplete
security models and thus compromise the effectiveness of
your security as a whole. The process of creating secure
systems is about setting up a network, intranet, or any
computer system, and assuring that the people who are not
supposed to access it cannot gain entrance as a trusted
user of the system.
Keeping a system secure means careful planning
of a sound system that takes all threats into account. During
this planning, you must keep dangers in perspective. Your
danger from unknown outside threats is, in computers as
in life, very remote. The big dangers are from those people
you know and who know you. The important thing to remember
about security is that all threats come from people and
all threats must be stopped by people. Computers can make
the monitoring easier, but they cannot counter an attack.
Knowing how to design a security model
is important. Begin by making a model of where your important
files are stored. Draw out what computers store these files
and to which computers they can be transferred. If anyone
has access to those files and access to another file system,
it is safe to assume that that person will transport the
files from one file system to another. If one file system
is secure and the other is not, you have a problem, so make
sure that data cannot be transferred.
Look at the connections. Sometimes these
connections run through user accounts; in other cases they
don't. Connection routes are not always readily apparent.
They run through particular users, using particular computers
at particular times in particular ways. That is, even one
user/computer/time/application combination can be a security
hole large enough to compromise the system, as you can see
in the illustration shown in Figure 14.1. Note how paths
of access are formed by different combinations of each element.
Note also that some unusual combinations could be formed
to allow possibly unintended access. Some longtime UNIX
users may remember that GNU EMACS could give clever users
on certain computers system-level access to entire networks.
Figure 14.1: A
computer network and a security plan that includes users,
times, and applications.
Once you have created a list of where the
files are and how they are stored, you must make a list
of who has access to these areas. Such a list should include
the names of individuals who have access to each file system
and each branch of the file system and how they are accessing
it. Can they only access it through FTP or can they actually
mount it as a file system on their computers?
Don't always be concerned with malicious
damage. The biggest problem could be inadvertent damage
or transfer of files, which is just as dangerous as someone
purposely intercepting the data.
With the user structure, define the levels
of access. Someone has top-level access, and you must determine
who has it. Top-level access lets these users create and
destroy user accounts and read any users' data; it also
provides access to the complete system. Anyone with this
privilege needs to be aware of that power.
For all the data and file systems, how
many authentication points does a user pass through to access
these systems? Are users required to pass through a firewall?
If so, what are the requirements or barriers to get through
that firewall? Could anyone access that firewall? You must
decide the answers to these questions and determine who
has read and write access as well. The ability to read and
write in general is determined when you're deciding access
levels, but you also need to decide if authentication will
take place at the actual read-write moments. Does someone
have to be authenticated to read the data or to write the
data, and can the person writing the data destroy the data?
To maintain a secure system, users should
be required to prove who they are at least a couple of times
and in a couple of ways. When sitting down at a workstation
for the first time, for example, users should at least be
required to type in a password. When accessing sensitive
files, users should have to put in or have already put in
enough information so that their identities can be logged
along with anything done to the file. Whenever connecting
to a network from a remote location, users should always
have to prove their identities either through a username-password
exchange or through more secure methods such as s/key or
kerberos, explained later in this chapter.
Any plan to protect your computer systems
must begin with their physical security. The most important
thing about a local area network (LAN) is its physical security.
Physical security is important because on most LANs all
messages are transmitted to all workstations. That is, local
networks transmit messages from one computer to one other
computer only from a logical perspective. From a physical
standpoint, the electrical signal that constitutes the message
is received by every computer connected to the wire. Additionally,
most LANs are set up to trust the hosts (computers) directly
connected. So anyone who can tap into your LAN's wiring
or anyone who can access one of your LAN's existing computers
has access to various data and resources. System administrators
should investigate card or combination door locks to the
most sensitive areas. Additionally, it is imperative that
the systems administrator be aware of how secure the whole
building is as well as be aware of the level of security
in any room with computers connected to the LAN.
To protect your LAN from nonphysical threats,
consider the following nine questions:
What resources are on the LAN
(for example, CD-ROMs, software, UNIX workstations, printers,
data)?
What resources are available LAN-wide (for example, databases,
Web pages, printers, e-mail)?
What computers are on the LAN?
Which users have access to which resources?
What are the paths running into and out of your LAN?
Which users are allowed on the LAN?
When are the users allowed access to the LAN?
What resources are accessible during users' access to the
LAN?
What resources does the LAN include?
The level of security on the LAN depends
on what computers, software, applications, data, and resources
the LAN contains. Additional concerns to consider include
the following:
Will files be shared across the
network?
Will users be able to access other computers physically
or electronically?
Will printers be shared?
Will sensitive information be printed on shared printers?
What databases will be in use?
How will users access databases?
Each of these questions requires a decision
about security, and each of these resources needs its own
security measures and influences the security of the system
as a whole. The following sections further explore each
of the nine questions.
This first question (What resources are
on the LAN?) refers to the resources located on the LAN
but not necessarily shared. The response is a consideration
for system administrators whose users access the LAN electronically.
File systems available LAN-wide, workstations that accept
connections across the LAN, and databases that accept requests
from other LAN computers are all potentially vulnerable.
Just as vulnerable are any file systems, workstations, or
databases on the LAN that are not shared but are also not
protected against sharing. All resources must have specific
security measures, such as local password protection for
all workstations. Other needed measures include preventing
computers from being rebooted to evade security, preventing
file systems not meant to be shared from being shared by
a user, and password-protecting sensitive files no matter
on which disk they reside.
Can users access all information on the
servers or are certain areas restricted within the LAN,
such as certain functions, printers, file systems, backup
devices, CD-ROM drives, or administrative applications?
You must decide where restricted resources will be stored
and create secure areas for them. You need to store backup
tapes and backup devices, for example, with the same security
as the computers. Programs set to be run by the system at
certain times need to be guarded carefully so that only
the system-and not some user-runs them. You need to secure
printers on which certain sensitive data will be printed
and to prevent others from sending jobs to that printer.
Shared File Systems
An area that deserves special consideration
is shared file systems such as Network File System (NFS),
which is commonly implemented under UNIX. Operating systems
often include a method for broadcasting certain areas of
the file system to be mounted by other computers. Clearly,
using NFS and other sharing schemes increases the security
exposure of a particular computer. Other important concerns
for UNIX environments are authentication and system file
distribution.
For Sun System users, it is important to
decide whether to use Network Information System (NIS)-previously
known as Sun Yellow Pages. NIS is used to share among a
number of hosts common lists that are important to the system,
such as the username password list, the NFS mounting tables,
and trusted hosts. Using NIS, you can distribute those files
so that all the systems on your LAN can use the same user
lists. This capability is convenient but dangerous, because
it is important not to send out copies of your password
list to the wrong system. If you're using NIS or any other
system of distributing system files, make sure that no one
can intercept these distributions.
The types of computers on the LAN greatly
influence your security measures. Computers running the
UNIX operating system have many built-in security features,
whereas computers running Windows 95 and Windows 3.x have
almost no security features. Examine each computer on your
LAN for vulnerability. Each type of computer and each different
operating system requires a different set of protective
measures. To protect the LAN adequately, you must set restrictions
on the types of data and applications that can be run on
specific computers. If you are using a database server,
for example, you may want to restrict the access that Windows
3.x clients have because the security on these clients is
so poor.
When you're considering a security model,
you need to consider compartments. Visualize compartments
by making a diagram of all LAN resources and drawing circles
around the items that should be secure. Creating compartments
is a method of keeping systems separate from one another,
data separate from other data, and keeping applications
separate from certain systems.
When you're considering compartments, be
sure to decisively divide areas that should not be intermingled.
Determine whether you can separate your LAN users by function,
such as accounting, design, or administration departments.
Determine whether they can be completely separated in the
kind of data and applications that they need to access or
if different departments need to share common resources.
You should put the system administrators in a completely
separate group so that they can get at everything in the
other compartments but not have anyone get back at those
same file systems or same computers.
You may find that some systems and certain
computers should be accessible only to specific users. A
server with financial data, for example, should be kept
separate from the rest of the network so that general users
cannot access confidential financial data. If any of the
data is off-limits, you should place it on a file system
that is accessible only from certain systems, making those
systems off-limits to general users.
All the systems, access paths, and data
should be classified into particular groups. You should
create groups for all resources, including a group for unsecure
systems. You also should define each access path, workstation,
file system, printer, database, or any other item and place
it in a particular group.
Another facet to consider in the security
model is the paths of access. Paths should be well-defined,
laying out the routes of access, who can access these routes,
where and when access can occur, and how these routes are
protected. When you're compartmentalizing everything, you
should make sure that the paths from compartment to compartment
are well-defined. Define those paths; even if no path exists
from one compartment to another, the model should indicate
the path's intentional absence.
If you plan to offer paths into and out
of your LAN, you need to decide who will travel these paths.
If possible, restrict this list to a specific set of users.
Make a list of these users, and keep it current. If you
must allow access to users in groups, keep a list of the
groups and keep strict guidelines for admission to each
group. If you are going to allow universal access-access
to people who have not been pre-approved-you always need
to be cognizant of this use.
Also, you must define subordinate levels
of access. Who is actually allowed to work on any part of
the system? Should someone be allowed to create user accounts
who doesn't receive the remaining route privileges? With
Novell, this option is common, especially where you can
define administrators who create and destroy certain accounts
with a certain level of power.
You also must define levels for ordinary
users who get access. In defining these users, determine
what they will do with the system. Deciding by function
makes it easier for you to define to which resources users
get access. A person who does graphic development, for example,
needs to browse on the Web and access testing sites. The
system administrator's knowledge of the file areas for the
designers, the graphic design tools they use, and computers
the designers need access to makes it easier to fit these
users into a file structure list.
Don't forget to define a guest level and
anonymous access. If there is no guest or anonymous access
level, be sure to define the system that way. In addition,
make sure that, if you are restricting the system to no
guest level access, no guest level access occurs. Test the
system to make sure.
Don't make access levels too complicated.
Choose a few levels and types of users, and stick with them.
Individually tailoring security to each person is a big
hassle, and these types of haphazard choices are destined
to go wrong. The more complicated the security, the more
likely problems will occur, and someone will be unable to
access the system when he or she needs to access it.
A system is designed to give people access
to data and perform functions, but if the security is too
tight and users can't do what they are supposed to, the
system can't be used. The result is a security system that
is not workable.
When you're thinking about how to give
access to the LAN, you need to decide where the authentication
will take place, define gates, and draw circles around compartmentalized
systems. This modeling exercise will give you a tight list
of action items for securing your system. Draw circles around
the compartments that are supposed to be secure, define
gates into those compartments, and create barriers to entry.
Any secure system needs a gate in front of it, and knowing
what kind of authentication is taking place at that gate
is important. If you don't want users to access certain
file systems, for example, make sure that username and password
authentication takes place before the users can access these
systems. To avoid having users from outside coming into
your LAN and doing anything but Telnet connections, make
sure that at these connections authentication is taking
place and that no other connections are possible.
What if more than one authentication process
exists? Generally, users on a system become angry when they
are asked to enter usernames and passwords several times.
How many times and in how many ways do people have to prove
that they are authorized to access certain file systems,
applications, and computers? Security frequently involves
a balance between security and access. You must make a decision
about how secure the system should be versus how easily
users can access it. If the system is easily accessible,
it will not be very secure. With only a little hassle for
the user, however, the system can be very secure.
What data can your LAN users access on
other systems? If they are turning to other LANs to access
resources that require more connections to other systems,
such as accessing files directly on the file system as opposed
to simple FTP, these connections require a lot of trust
between two hosts. Do your LAN users need to go out and
get this access? If so, you will need to more carefully
plan and monitor your connections to other systems.
Knowing when users can go in and out of
your LAN means not only knowing what times, but also knowing
under what circumstances (see Figure 14.2). That is, are
users aware of situations that may cause the paths to be
closed, such as maintenance, upgrades, or off-hours? Channels
you use to communicate these situations also can be used
as security checks. Announce that you're closing some systems
down, and see who doesn't get the message. By keeping careful
track of when users can access the LAN, you can spot intruders
more easily.
Figure 14.2: A
full LAN security model.
Keep lists of resources that users are
allowed to access from outside the LAN. Any item that is
not on your list needs to be carefully protected from outside
access. Part of designing a security model for your LAN
includes creating a combined list of the users and groups,
when they can access the system, and what they can access.
This combined list and any explanatory or supplementary
material is your security model.
Your system has no security without authentication.
Authentication means proving your identity. Authentication
does not always have to be electronic. Locks, guards, and
cameras can all provide authentication of some kind. None
of these devices, however, are as constantly vigilant, carefully
discriminating, or as fully reviewable as electronic methods
are for protecting computer systems.
The first and most simple type of authentication
method is a post name check. The system checks where
the user is coming from and uses that information to authenticate
the user. In other words, the system has a secure list of
trusted hosts, and anyone attempting to gain a connection
from the trusted host can gain access, but users not from
the trusted host are not allowed access. This method does
have drawbacks, however, because it depends only on the
physical security of one of the trusted hosts. If anyone
can gain access to a trusted host, that user can then gain
access to an individual computer in the system. In the early
days of the Internet, this type of security was common.
A slightly more secure method is username
authentication in which the user merely types in his
or her username; if the name is on the list, he or she is
given access to the system.
An even more secure method, however, is
username and password authentication, which allows
the user to enter the username and password combination.
This information is compared to a list that the computer
has, and the user is then given access to the system if
this information is the proper combination. You can use
various twists on this arrangement to encrypt either part
of that pair or both parts of the pair to make the system
somewhat more secure. One example is the way in which UNIX
stores passwords; in this approach, the username is stored
in plain text, and the password is stored encrypted so that
a user cannot steal the list and use it to gain access to
the system. Encrypted passwords are very difficult to decrypt.
Keep in mind that usernames and passwords need to be updated
and changed every three months, because eventually they
may be decrypted.
Another authentication method includes
kerberos. The name comes from the mythical name of
the three-headed dog that guards the entrance to Hades.
This method, primarily implemented under UNIX, is used to
overcome problems with secure transmissions. It allows the
user to be authenticated locally-that is, on the workstation-but
to use network resources.
In the kerberos system, the user puts in
his or her username and password, and then the workstation
itself authenticates the user. The workstation then requests
from the kerberos server a secret ticket for the user. This
ticket is then used as a credential for any network resources.
It is unique to the user for a specific time and situation.
Transmitting this ticket is possible when the user wants
to access certain resources that are protected. It is very
secure because the user never transmits the username and
password. Any eavesdroppers cannot steal the username and
password, but instead get only an unusable ticket.
Smartcards, smartkeys, and
what is known as a challenge-and-response system
are protection methods similar to kerberos. These systems
create one-time usernames and passwords, which are the most
secure. Challenge-and-response systems conduct all authentication
on the local computer, avoiding transmission of passwords.
Like kerberos, challenge-and-response systems create one-time
passwords, but unlike kerberos, they do not require a special
server.
Keep in mind that usernames are not security.
As I mentioned previously, keeping a list of usernames can
be a method of authentication. Expecting usernames to remain
secret is not a good idea. It is like a lock on a door that
doesn't have a deadbolt: The lock isn't particularly safe;
someone could kick the door in. But you need that lock in
place so that someone can't simply walk in. With a username
list, someone can't just get on a system, but it is not
to be considered the final word in security.
There are guidelines for making passwords
that people repeat over and over again much like a mantra.
Remember, when you're making a password
list, don't use a word in the dictionary. Not only could
someone guess that word by trying a few combinations, but
the words could be subjected to a dictionary attack. In
UNIX, passwords are stored in encrypted form. A password
file contains the username and the encrypted password. Breaking
that encryption is difficult, but a list of dictionary words
could be encrypted and the encrypted string then compared
to the encrypted passwords in a username and password file.
If a match occurs, the password is known. The list has a
limited set of words, and if that set of words matches a
particular password, that account has been compromised.
At that point, whoever is breaking into the system can go
in as a trusted user and access the system. So the effort
to keep the system secure has failed.
Using simple strings of numbers as passwords
is also not a very good idea, because these strings could
be subject to the same kind of attack. Letter-number combinations
are harder to crack. Using special characters is a good
idea; they help to increase the number of possible combinations.
As you add characters to a list that you use for any passwords,
the security of those passwords is increased exponentially.
Another important rule about passwords
that is rarely followed is to never write down the password-not
on paper, tape, or under someone's desk. Anyone who can
gain access to the space is going to read the password.
Any password that is written down can be read by everyone
that enters the space and sees the password.
Never put passwords on e-mail, and never
send them over e-mail. Users with administrator access to
the system can read all e-mail on the system. E-mail is
in plaintext, and users can simply scan through the file,
find the password, and then use it.
A firewall is a device, set of devices,
or combination of hardware and software that protects the
systems on one side from systems on the other side. "Firewall"
has become somewhat of a buzzword, and so people often do
not realize that this term can mean many things and is really
a concept, not a product. Hence, the definition includes
broad terms such as "protect," "system,"
and "side." The definitions of these words depend
on the purpose of a firewall.
The firewall concept applies to an internetwork.
An internetwork is a network with internal barriers. These
barriers can be firewalls-that is, barriers designed to
protect-or they can be barriers designed to better administrate
or engineer the network. These barriers can be Ethernet
or IP address barriers; that is, they can restrict traffic
from one side of the barrier to the other based on Ethernet
or IP addresses. They also can be based on names of computers
or on the type of communication; they might allow Web traffic
to pass, for example, but not file transfers. The barrier
therefore allows only certain computers to communicate with
certain other computers in certain ways. If these barriers
exist only for security reasons, they are called "firewalls."
Protecting a wide area network (WAN) or
internetwork means embracing a complete security model.
A WAN is made up of individual LANs and users. The LANs
serve as compartments for the process of security planning.
A LAN model for any particular compartment in this WAN should
be completed before you determine how they interact. Plan
out LAN-to-LAN access; in other words, decide how users
will connect from one to the other. Decide how outside users
will access each LAN compartment. Pick the services that
can travel over those paths between LANs, such as Telnet,
FTP, or HTTP. When you're choosing services, also decide
what protocols such as TCP/IP or IPX will be allowed and
whether you will use network addresses as the basis to create
barriers. Know what applications will be used across the
network such as network monitoring or Web browsers. List
what files users will access between LANs. Plan out all
these paths, where they lead, to what system, what applications,
and what file systems.
Does your WAN include the Internet? Are
you accessing pieces of your network across the Internet?
Can people from the Internet access your network? If so,
this access makes the model more complicated. Assume that
everyone on the Internet will want to gain access to your
WAN. Protecting against these threats is important. If you're
going across the Internet to get to another part of your
WAN, anyone on the Internet may be able to do the same.
You need to understand how users could get access and decide
what specific measures you will take to prevent this access.
With a WAN, you must consider a password
exchange model: how will you get usernames and passwords
available to users? Passwords should be transmitted only
over verifiably secure means. This could mean nonelectronic
transmission or encrypted electronic transmission. Consider
methods such as challenge-and-response and kerberos, which
allow distributed authentication and no password transmission.
Also consider authenticating the recipient of the username
and password. When you pass authentication credentials to
someone, you need to know that they go to the right person.
You also must know that the right person is actually authorized
to this access.
A firewall is a particular computer system-sometimes
hardware, sometimes software, sometimes both-that stands
between a secure system and an insecure system, and it allows
only privileged traffic to flow through. You can build a
firewall in many ways, such as a bridge that discriminates
against certain Ethernet addresses (which happens to be
the simplest firewall to develop). Every network interface
card has an address. A bridge can discriminate and say that
it does not accept traffic from certain addresses and only
accept traffic from certain addresses on the other side
of the bridge. With this method, faking an Ethernet address
is somewhat difficult.
One level up is to restrict access and
resources on the basis of IP address, but this approach
is vulnerable to fake IP addresses or "IP spoofing."
Giving your computer a network address belonging to another,
for example, would allow you to get traffic that is bound
for that address. Routers help to prevent this situation.
Routers and bridges are lower-level firewalls. Often they
act only as agents of network engineering and organization
and are not designed to protect. Because they operate at
such low levels, they are subject to many kinds of sophisticated
attacks.
Another type of a firewall is an application-level
firewall, which lets only predetermined traffic and packets
through. A firewall of this type denies all traffic except
for certain services that you enable. You can also restrict
traffic so that it goes only to certain computers. Packets
sent to other computers just never get there. This firewall
is particularly secure and also can be used as a proxy.
People inside the system send out packets that go to the
firewall. The firewall claims the packets as its own and
keeps records of where the packets came from; it then sends
them out to where they are going. When the packets are received
on the other end, the remote system believes that they were
sent from the firewall, and this system sends all return
packets there. The packets then get back to the firewall,
where the firewall routes them back to the inside computer
that originated the connection. Because the firewall acts
as proxy in this way, people outside the network can see
only the firewall, and anyone analyzing the packets sees
only the firewall's address and ports. This type of firewall
is particularly secure because it presents only the firewall
to the outside system.
|
MCKEON & JEFFRIES |
| McKeon & Jeffries set up a fairly
routine security system for their intranet based on
the fact that, besides Web connections from inside
the firewall, no one but the systems administrator
and the intranet administrator would have access to
the Web server. The firewall was set up at the one
point of contact with the Internet, which was the
ISDN line going out of the Philadelphia office. It
sits on an old 486 machine with 32MB of RAM and a
200MB hard drive. This machine runs Windows NT and
Eagle Raptor firewall software, which keeps out any
users trying to access computers inside the firewall
from the Internet, including the Web server. The accounting
firm's Web server is only accessible via the Ethernet
LAN and the WAN set up between the three offices.
Because the server is a Windows NT platform that
does not run remote services (Telnet or FTP), it
is only accessible to the systems administrator
and intranet administrator when they are physically
at the machine or dialed in through remote access
via a modem. Thus, security for the server is not
too much of a concern. |
|
THE SPORTING GOODS AND APPAREL
ASSOCIATION |
| The SGAA's security plan included
using the Sun server and the router to set up a custom
firewall. The router passed data packets to only one
machine, the Sun server. That machine in turn looked
at the packets and, via proxy servers, passed packets
for authorized services onto the other machines on
the LAN only
The consultants who helped build the intranet
software also helped the association set up this
security system. Throughout the setup, the consultants
instructed the systems' administrator, who carefully
documented every step of the setup. The systems
administrator keeps careful track of new security
developments. |
When you're setting up a secure system,
following sound engineering principles is important. One
such principle is testing the system. When you're testing
the system, you can use any of several methods. For example,
try to break into the system from the outside. Use varying
levels of knowledge of the system to simulate every potential
attacker from a random hacker to a trusted insider. You
also can consult one of the many security analysis firms
that make a business out of helping companies ensure secure
networks.
When you're testing your security, find
some standard attacks that people use, and guess some usernames
and passwords. Try a dictionary attack on the password file.
Some programs that explain how to do a dictionary attack
on the system are available. Checking passwords is a good
method of keeping users aware of what the vulnerabilities
are.
Examine your security model, look at the
paths that you are explicitly denying, and be sure that
the paths are explicitly denied. System administrators often
believe that their systems are secure from certain attacks,
when in fact some file has been erased and some setting
has been altered. When that path is tested, it turns out
to be wide open. Make sure that the holes are plugged in
your system.
Finally, no security can be complete without
subscribing to the CERT Mailing List. The Computer Emergency
Response Team (CERT) puts out regular bulletins on vulnerabilities
in various systems; you should check these bulletins regularly.
CERT was formed in association with the Software Engineering
Institute and Carnegie-Mellon University. Their home page,
where you can find all the information you need, is located
at www.cert.org.
As an overall concept, pay attention to
and recheck the simple security risks, because often this
is the place where the security holes are. Simple security
risks include the easiest ways for people to access your
system-passwords written in e-mail or on paper; services
offered to the network that are unnecessary or unsafe; a
failure to change the system password; giving out the system
password; or not plugging known security holes. If you attend
to these risks, little can actually happen. Minor awareness
and careful attention to detail will tighten security considerably,
making it less important for you to worry about the fancy
high-tech items. Keep an eye on the important bridges, and
this will cover the system.
Security is always a balance between ease
of access and security. It is important to figure out what
the balance is. If the system must be especially secure,
the people who are using it must understand that. If the
users know that they must jump through hoops to access the
system, they should understand that these measures will
make the system more secure. Overall, the system must look
secure to users as well as intruders.
A secure system requires the cooperation
of everyone involved: the system administrators, the system
designers, and the users. The security is only as good as
each person's commitment to it. No amount of high-tech firewalls,
guard dogs, and transaction logging can protect you if your
trusted users are writing down their passwords for the janitors
to steal. Therein lies the real danger: Far more breaches
of security have been caused by careless or, just as often,
malicious employees. Preventing an angry employee from wreaking
havoc on the system is the most difficult but most important
security job. By comparison, hackers are a remote and easily
controlled threat.
System security is both the foundation
and the summation of all security. Data and transmission
security has no value if the system is insecure. System
security depends on data and transmission security. For
most modern businesses, the computer system is the business.
If the system doesn't work, the business doesn't work. The
security of the computer system, then, is the security of
the business. Good employees don't leave their financial
statements or the keys to the file cabinet lying on their
desks, but many employees leave their passwords to the same
computer files or disks containing that information. Despite
the thousands of books and articles written on the subject,
the "it won't happen here" attitude is just as
widespread as ever. Take precautions.
|
