- Building a Security Model File Structure
- Protecting the Local Area Network
- Authentication Methods
- Protecting Your WAN: A Complete Security Model
- Testing Security
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.
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.
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 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 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 http://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.