Technical Risk

To understand the technical security risks of a system, architects and designers need to understand the nature of these risks in order to prevent problems. The nature of risks in our systems can be categorized into four major areas:

  • Improperly configured systems
  • Buggy software
  • Poor authentication, or insufficient password requirements
  • Lack of encryption in network traffic

The primary reason that any given part of a system is a security risk is improperly configured, or buggy, software. An improperly configured system, or a system with a bug, opens a security hole that can be exploited. One of the most famous security breaches has been chronicled by Clifford Stoll in his book The Cuckoo's Egg, in which he describes the eventual capture of a successful West German cracker.[3] The cracker managed to gain privileged access to a number of systems throughout the world by exploiting a bugunknown featurein a common text-editing program. The program allowed users of the system to save a file to a particularly important area of the file system. Files in this directory were automatically executed with root-level privileges and considered normal parts of the operating system. Once there, the hacker's file was run, giving the intruder a secret and unmonitored account on the system, which he used to anonymously examine the system for important information, and as a jumping-off point to the next unconquered system. This bug has long since been fixed, along with many other bugs that have been discovered as a result of a security breach.

[3] Not to be confused with the term hacker, a cracker is someone who maliciously breaches a system's security, whereas a hacker is someone who is considered an authority on computer-related things.

Anonymous attackers are not the only worry of a security-conscious designer. A disgruntled employee can cause even more damage to a system than an intruder who has only the most basic knowledge of the system. It is therefore important to establish the identity of the users of the system as best as practically possible. At a minimum, separate user accounts and private passwords need to be established.

In a Web application, proper authentication of a system's users can happen at several levels. At one level, the client computer itself can be authenticated for use with the system. A Web application can be designed to allow only clients with certain IP addresses. My previous Internet service provider (ISP) uses this type of authentication to protect certain Web pages in the technical support section of its Web site. Because I travel a lot, I often need to look up the local access numbers for the city I am visiting. This information is important to the ISP's customers but represents a minor potential for abuse from noncustomers, by tying up these lines trying to gain unauthorized access. This particular page is set up such that anyone whose IP address is one of the ISP's own addresses is allowed full access to this page, whereas others are diverted to a page that contains only partial access numbers: just enough to determine whether an access line might be a toll call for a customer. This type of authentication is not perfect, but the complexity it adds to the system does balance out with the risks involved.

The most common form of authentication is a simple password. Users of a system are given a log-on IDa publicly known identification of the userand a secret ID (password). To gain access to the system, the user must use both. After the first access to the system, the user is usually prompted to change the password to something that only the user will remember. Passwords are usually the first line of defense in a system and help prevent interactive attacks on the system.

This type of authentication has many problems. From a purely technical point of view, a user ID and password tell the system only that a user who knows that combination is requesting access to the system, not necessarily that it is the person who is supposed to have that knowledge. What a system is really authenticating is a user with knowledge of a valid user ID and password combination, not the real identity of the person requesting access to the system.

This problem is exacerbated by the practice in some organizations of creating "group" accounts, in which a number of individuals use the same user ID and password combinations. In these situations, an individual user's identity is never really known, and any given password is likely to overlap with the introduction and expulsion of employees. So it is likely that at any given time, valid user ID and password combinations are known by unauthorized individuals.

In Web systems, especially Internet systems, anonymous users are the norm, and a special account is often created for this type of user. Popular systems may have many thousands of simultaneous users, all using the same account ID. In many Web applications, one user ID/password pair is used to gain access to the application and the business logic resources but to share another common user ID/password pair for access to the database.

In many situations, knowing a particular log-on account won't gain a cracker immediate access to all a system's resources. Typically, user accounts are restricted to allow access to only those system resources necessary to perform the user's responsibilities. Of more interest to a cracker are the administration passwords, root or administrator. With this level of access, the entire system's resources are open for exploitation.

Administrator-level access can be gained to a system by obtaining a copy of the system's password file. The default configurations of many UNIX and NT systems allow this. The cracker can then use special software programs to "crack" the password file's encryption and thus obtain access to the system's more interesting administrator and root accounts.

Simple passwords can be cracked with programs that repeatedly guess passwords from dictionary words and combinations of numbers or other common symbols. Short passwords are especially vulnerable because fewer combinations of letters and numbers exist. The best passwords are combinations of letters and numbers that are truly random. The problem, however, is that a human is less likely to remember a completely random sequence of digits than one that has some semantic meaning to the user. Once a semantic meaning is placed in a password, it stops being purely random and is more likely to be cracked.

When creating passwords, you should not base your password on

  • Your name or any part of your name
  • Any part of a dictionary word or proper name
  • Acronyms

In general, any systematic way of producing a password is subject to be repeated by an unscrupulous cracker. The following passwords are all considered bad because they can be cracked easily with common password-cracking software:

pba Too short
jimc1 Based on user name
merlin Dictionary word
bilbobaggins Dictionary word
qwerty Dictionary word and easy to see when typing
aaaaaa Dictionary word and easy to see when typing
4tune Prepending character to dictionary word
tune4 Postpending character to dictionary word
hIho Capitalization in a dictionary word(s)
c00l Substitution of numbers for characters in dictionary word

The best passwords are those that the individual creates on a purely personal and random basis. The practical trick in password usage, however, is using passwords that can be remembered. I worked in one environment in which the passwords were distributed by the company's network administrator, who used a special piece of software that he believed produced very random and difficult-to-guess passwords. To increase securityin his mindhe changed them every three months. He assigned passwords to users of the system, expecting us to quickly remember them and to destroy written copies. The passwords were cryptic and difficult to remember. The result was that half of the users ended up writing down their passwords on Post-it notes and sticking them on their monitors. In the end, this was not very secure, yet there was very little that the common user could do.

The trick to the use of passwords is not to consider them the ultimate security tool but simply a first line of defense. To be effective, passwords need to be as close to random as the user is capable of remembering. Additionally, users need to be the ones to create the password; any systematic and organization-wide method of producing passwords is more likely to be cracked than are isolated and uniquely derived ones.

The final general category of security risk is lack of encryption. In this type of risk, intruders monitor network traffic, collecting the dialogs of communication between clients and servers. The most common network protocol on the Internet today is TCP/IP. When designed, security was not foremost in mind; the Internet, being the world's largest public network, does not prevent anonymous users from monitoring the general traffic passing through their systems. Crackers can use "sniffers" to monitor and to analyze the network traffic to a specific server or client and, possibly, to reconstruct important information useful in gaining further access to the system or simply picking up a few valid credit card numbers.

To counter this risk, the traffic between the client and the server can be encrypted. Encryption is discussed in more detail later in this chapter, but the general idea is to encode the network traffic between a specific client and server so that the traffic cannot be understood by any listening third party.

One major use of network encryption is in virtual private networks (VPNs). In a VPN, a public network, such as the Internet, is used as a private network. All members of the private network use encryption to communicate with other members of the private network. From the user's point of view, the network looks like a private network, as might be seen in a small business with a local area network (LAN); see Figure 5-2.

Figure 5-2. Virtual private networks


VPNs have the distinctive advantage of allowing small companies to give private network access through the public Internet to individuals remotely located, rather than through more expensive private leased lines. Using VPNs places most of the security responsibilities, such as network traffic encryption, on the infrastructure rather than on the individual applications. Some Web applications may use VPNs as part of their security measures. VPNs can be implemented with a combination of software and hardware or with software alone.

Overview of Modeling and Web-Related Technologies

Building Web Applications

show all menu

Building Web Applications With UML
Building Web Applications with UML (2nd Edition)
ISBN: 0201730383
EAN: 2147483647
Year: 2002
Pages: 141
Authors: Jim Conallen
Similar book on Amazon © 2008-2017.
If you may any questions please contact us: