When a safeguard or a countermeasure is not present or is not sufficient, what is created?

Logic Bombs Logic bombs are malicious code objects that lie dormant until events occur that satisfy one or more logical conditions. At that time, they spring into action, delivering their malicious payload to unsus- pecting computer users. They are often planted by disgruntled employees or other individuals who want to harm an organization but for one reason or another might want to delay the malicious activ- ity for a period of time. Many simple logic bombs operate based solely upon the system date or time. For example, an employee who was terminated might set a logic bomb to destroy critical business data on the first anniversary of their termination. Other logic bombs operate using more complex criteria. For example, a programmer who fears termination might plant a logic bomb that alters pay- roll information after the programmer’s account is locked out of the system. Worms Worms are an interesting type of malicious code that greatly resemble viruses, with one major distinction. Like viruses, worms spread from system to system bearing some type of malicious payload. However, whereas viruses must be shared to propagate, worms are self-replicating. They remain resident in memory and exploit one or more networking vulnerabilities to spread from system to system under their own power. Obviously, this allows for much greater propa- gation and can result in a denial of service attack against entire networks. Indeed, the famous Internet Worm launched by Robert Morris in November 1988 technical details of this worm are presented in Chapter 8 actually crippled the entire Internet for several days. Distributed Environment The previous section discussed how the advent of networked computing facilitated the rapid spread of malicious code objects between computing systems. This section examines how distributed com- puting an offshoot of networked computing introduces a variety of new malicious code threats that information system security practitioners must understand and protect their systems against. Essentially, distributed computing allows a single user to harness the computing power of one or more remote systems to achieve a single goal. A very common example of this is the cli- entserver interaction that takes place when a computer user browses the World Wide Web. The client uses a web browser, such as Microsoft Internet Explorer or Netscape Navigator, to request information from a remote server. The remote server’s web hosting software then receives and processes the request. In many cases, the web server fulfills the request by retrieving an HTML file from the local file system and transmitting it to the remote client. In the case of dynamically generated web pages, that request might involve generating custom content tai- lored to the needs of the individual user real-time account information is a good example of this. In effect, the web user is causing remote servers to perform actions on their behalf. Agents Agents also known as bots are intelligent code objects that perform actions on behalf of a user. Agents typically take initial instructions from the user and then carry on their activity in an unattended manner for a predetermined period of time, until certain conditions are met, or for an indefinite period. The most common type of intelligent agent in use today is the web bot. These agents contin- uously crawl a variety of websites retrieving and processing data on behalf of the user. For example, a user interested in finding a low airfare between two cities might program an intel- ligent agent to scour a variety of airline and travel websites and continuously check fare prices. Whenever the agent detects a fare lower than previous fares, it might send the user an e-mail message, pager alert, or other notification of the cheaper travel opportunity. More adventurous bot programmers might even provide the agent with credit card information and instruct it to actually order a ticket when the fare reaches a certain level. Although agents can be very useful computing objects, they also introduce a variety of new security concerns that must be addressed. For example, what if a hacker programs an agent to continuously probe a network for security holes and report vulnerable systems in real time? How about a malicious individual who uses a number of agents to flood a website with bogus requests, thereby mounting a denial of service attack against that site? Or perhaps a commer- cially available agent accepts credit card information from a user and then transmits it to a hacker at the same time that it places a legitimate purchase. Applets Recall that agents are code objects sent from a user’s system to query and process data stored on remote systems. Applets perform the opposite function; these code objects are sent from a server to a client to perform some action. In fact, applets are actually self-contained miniature programs that execute independently of the server that sent them. This process is best explained through the use of an example. Imagine a web server that offers a variety of financial tools to Web users. One of these tools might be a mortgage calculator that processes a user’s financial information and provides a monthly mortgage payment based upon the loan’s principal and term and the borrower’s credit information. Instead of processing this data and returning the results to the client system, the remote web server might send to the local system an applet that enables it to perform those calculations itself. This provides a number of benefits to both the remote server and the end user: The processing burden is shifted to the client, freeing up resources on the web server to pro- cess requests from more users. The client is able to produce data using local resources rather than waiting for a response from the remote server. In many cases, this results in a quicker response to changes in the input data. In a properly programmed applet, the web server does not receive any data provided to the applet as input, therefore maintaining the security and privacy of the user’s financial data. However, just as with agents, applets introduce a number of security concerns. They allow a remote system to send code to the local system for execution. Security administrators must take steps to ensure that this code is safe and properly screened for malicious activity. Also, unless the code is analyzed line by line, the end user can never be certain that the applet doesn’t contain a Trojan horse component. For example, the mortgage calculator might indeed transmit sensitive financial information back to the web server without the end user’s knowledge or consent. The following sections explore two common applet types: Java applets and ActiveX controls.