- Introduction
- Understanding the Basis for Policies
- Determining and Assigning Risk
- Writing Mobile Code Policies
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Determining and Assigning Risk
There is no formula for assigning risk. In some organizations, ActiveX or Java applets served from trusted servers and only used within the organization's network are not a significant risk for the environment. However, others may see the use of ActiveX and Java applets as too risky unless signed or even reviewed before their use. Therefore, as you write your policy, you should understand the technologies, their classes of access controls and mitigations, and where each policy should be applied.
Before setting policies, we need to define the risk types or categories. They can be defined in any way that is meaningful to your organization. I have found that the best way to do this is to base the risk categories on how well the technology controls access to the system that will run this code. Simply, I create the following three risk categories:
High Risk: Mobile code technologies that exhibit a broad functionality, allowing unmediated access to host and remote system services and resources.
Medium Risk: Mobile code technologies that have full functionality, allowing mediated or controlled access to local system services and resources.
Low Risk: Mobile code technologies that have limited functionality, with no capability for unmediated access to local system services and resources.
Using this type of risk assessment, it is easy to categorize the various technologies. But this does not mean that you should write policies to ban all technologies that are considered to be High Risk. There are other considerations, such as execution environment, and other mitigations, such as code signing, that could provide a risk that is not a concern for your organization. A common method of showing that a risk may have a mitigation strategy or that a technology with the mitigation strategy can be acceptable can be classified with the qualifier MITIGATED.
For example, if your organization has a policy that allows for code signing of applets from trusted systems as a mitigation strategy, you can create two additional categories such as the following:
High Risk (MITIGATED): High Risk mobile code technologies that come signed from trusted servers defined in mobile code procedures.
Medium Risk (MITIGATED): Medium Risk mobile code technologies that come signed from trusted servers defined in mobile code procedures.
Although this sounds like a good idea, I prefer staying with the original three levels of risk and assigning policy based on context or domain. The context or domain can look at where the mobile code originated and where it is being transmitted. While we think of the transmittal of mobile code to and from the Internet as the only threat, we can also look at transmission that is interdepartmental or between various business units as possible domains that require policy considerations.
Before writing these policies, you should categorize the various technologies so that you can see how to create the policy. I am not suggesting that these categories become part of your policy. However, understanding how the technologies are being classified and where they may be used may provide informative background to the policies.
Based on the risk categories outlined above, here is how I have classified various popular mobile code technologies:
High Risk: ActiveX, VBScript embedded in documents
Medium Risk: Java applets, Visual Basic for Applications (VBA), PostScript
Low Risk: JavaScript and variants within the browser environment, VBScript, Portable Document Format (PDF), Shockwave/Flash