Home > Articles > Security > Network Security

Writing Mobile Code Policies

  • Print
  • + Share This
Mobile code consists of small pieces of software automatically downloaded into the user's workstation and executed without the user's initiation or knowledge. Because these are executable programs downloaded from a server, there are security risks for using mobile code without appropriate controls in place. Even with the demands for the functionality offered by mobile code, security policies must be written to protect your organization's system and networks from malicious mobile code.
From the author of

It started with a simple idea: Allow the user to download a small piece of software that would enhance his or her online experience. Programmers could use this software to customize pages, do data validation on forms, and perform some basic processing, removing these burdens from the server. When Sun released their Java language and Java Virtual Machine (JVM) environment, the possibilities became endless. Sun's JVM was supposed to revolutionize Internet programming. A developer would write one program that could run anywhere the JVM was available. With the JVM available in most popular browsers, the concept of mobile code was born. Mobile code is defined as small pieces of software automatically downloaded into the user's workstation and executed without the user's initiation or knowledge.

Mobile code can be downloaded from many sources. With the proliferation of mobile devices such as personal digital assistants (PDAs) and cellular phones capable of executing mobile code, understanding the risks of mobile code is important for setting security policies. These new devices not only have the processing power to run mobile code, but the memory to store significant information, even beyond the organization's employee and customer lists. Put simply, there are security risks for using mobile code without appropriate controls in place.

The use of mobile code to create viruses and Trojan Horses has been well documented in the mainstream press. Less emphasized are some of the following dangers posed by malicious mobile code:

  • Deletion of user and system files that may require a complete reinstall of the operating system

  • Installation of hidden malicious code that runs at a later time (Trojan Horse)

  • Modification of the Windows Registry and the user's security settings

  • Emailing the malicious code to everyone in the user's address book

  • Executing ActiveX controls (installed with the operating system) that compromise user data

  • Sending sensitive user information to remote web sites

The problem with mobile code is that under the guise of providing flexible services for legitimate programmers, some technologies allow the code to have full access to system resources and services. Other technologies attempt to mediate or constrain the code to a restricted environment. For example, the following technologies could be used to write mobile code that has full access to system resources:

  • ActiveX

  • Visual Basic for Applications (VBA), which is embedded in many Windows-based programs, such as Outlook

  • MS-DOS or Windows batch scripts

  • PostScript

Technologies such as the following can be used to attempt to mediate or constrain the code to a restricted environment:

  • Java

  • JavaScript (and the JScript variant)

  • VBScript

  • Portable Document Format (PDF)

Even for those that execute in a restricted environment, however, mobile code can still have security implications because the restricted environment itself could be at risk. Despite its careful development, the Java Virtual Machine still includes a number of bugs; the implementation of a seemingly simple request can compromise security.

The most public example of the threat of malicious mobile code is the various worms that have been written in VBA. These pieces of mobile code performed various functions on the system that should not have been allowed by software downloaded from outside the environment. The lack of containment and access control allowed the worm to read the user's address book and transmit itself to other users listed in the address book.

  • + Share This
  • 🔖 Save To Your Account