Chapter 14
Security: Keeping Hackers Out
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.
|
