Avoiding Web-based Training Security Issues
June 24, 2008
Many users and system administrators have configured their browsers for optimal security, but this can wreak havoc with Web-Based Training (WBT).
By By Steven A. Kerschenbaum and Sean Brady
New and more comprehensive computer security measures are making computing more difficult and complex for everyone. This is especially true for the Web-based Training (WBT) community because the threats are not always obvious (as compared to identity and information theft) and the impacts can be subtle and hard to detect and troubleshoot. Security threats are real, but organizations still need to understand and appreciate the potential impacts of their IT security decisions on training. Unfortunately, computer security measures often are implemented without coordinating with the training group, and students and instructors are left scratching their heads about problems with the courseware.
Controlling the Browser
Most WBT is delivered to the user via standard Web browsers such as Microsoft Internet Explorer (IE), Apple Safari, or Mozilla Firefox. Browsers themselves are computer programs that provide various configuration and extension options, and work with the content to deliver the end-user experience. For this reason, WBT content developers often rely on the proper configuration of the Web browser to deliver their content.
Due to security concerns, many users and system administrators have configured their browsers for optimal security. These "locked down" browsers prevent any further configuration by end users—or more specifically—any rogue software they may have launched unintentionally. These steps can prevent security breaches, but they also can interfere with effective WBT delivery in several ways:
• Disabled JavaScript: JavaScript—the principle scripting language for the Web—is used as a primary means for courseware to communicate with a learning management system (LMS), the program delivering and tracking the courseware. When completely disabled in the browser, ADL content cannot communicate correctly with the LMS, and often presents strange behaviors that are difficult to troubleshoot. The JavaScript settings can be enabled to fix the problem, but the user must have the proper privileges and expertise to make the change.
• Pop-up blockers: In an attempt to stop annoying and occasionally malicious pop-up windows, many of the current browsers come with a pop-up blocker feature (usually enabled by default). Unfortunately, pop-up blockers also affect courseware because LMSs maintain their own windows when launching courses, and create a separate window to hold the course materials. If the browser blocks the new window, the courseware fails to launch and causes problems. This issue can be addressed by configuring the browser to "trust" content from certain locations and allowing their pop-up windows to launch.
• Blocked cookies: Cookies—small bits of information written to a user's computer to retain information about the site or the user—often are the target of security scares. Unfortunately, these bits of "persistent" data frequently were the targets of unwanted spyware that ferreted out users' browsing habits and personal information. While there are several work-arounds used by today's WBT content developers (e.g., by storing information in variable within invisible frames), some existing content still uses "session cookies" (a less irksome variety) to pass information from screen to screen. These courses do not work when the browser blocks the cookie.
• Plug-in restrictions: Plug-ins—small applications that interact with a Web browser to provide a richer, more complex Web experience—extend the browser's ability to display content and objects otherwise not permitted by standard HTML and JavaScript. Java is one such Web plug-in that is necessary for some modern courseware to function, and often is required by the LMS to communicate correctly. These additional components need to be "plugged" into the browser to provide the necessary functions (e.g., Adobe Acrobat readers and Apple QuickTime video players). In the past, some malicious plug-ins caused trouble, and resulted in many folks simply preventing their installation. In many cases, critical plug-ins are installed initially and then locked down for protection. Unfortunately, new courseware often requires updated versions of the initial plug-ins, and the locked configurations prevent the installations. (Web content can be written to check first and ensure that the plug-in is available, and provide links to the latest version as needed, but the user must have the privileges to install them on his or her system.)
• IE 7 display of external content: When Internet Explorer was updated to version 7.0, new capabilities and functionalities were introduced to the popular browser. With these new capabilities also came new "features," including some new security-related changes. More specifically, all Web content accessed from an outside domain (http://machine.domain.com vs. http://machine/) must display the address bar AND footer activated by default. This feature cannot be disabled, and is intended to prevent outside content from hiding its source (a nasty habit of malicious Websites). These additions, however, add roughly 52 pixels to the height of the browser window and sometimes introduce scroll bars into the content (see "Cascading Style Sheet Compatibility in Internet Explorer 7," Markus Mielke and Dave Massy, Microsoft Corporation, January 31, 2006, for more details regarding the impact of IE7). This relatively small reduction in screen real estate caused trouble for many WBT users and even greater challenges for folks trying to troubleshoot the cause.
• SCORM cros-domain problem: WBT normally is delivered through an LMS, and most are Web-based and use standard communication protocols to deliver and track the delivered content. The most prevalent protocol is SCORM, short for the Sharable Content Object Reference Model. It provides a reference standard for both communication—known as the run-time environment (RTE)—and content structure—known as the aggregation model (see www.adlnet.gov/scorm/index.aspx for more information regarding SCORM.)
In the past, malicious Web code that probed open browser windows for information was discovered. To counter this threat, security measures were implemented to ensure that the LMS was only running code from a trusted domain (attempting to prevent malicious code from running by restricting the content to your current domain). However, as architectures grew and folks wanted to share content more broadly (normally a good thing), the industry discovered that launching content from a different domain was interpreted as a potential security violation and, therefore, prevented.
The simplest way to correct this is to co-locate the ADL content server with the LMS application server in the same Web domain. For situations where this is not possible, the ADL Co-Lab provides further work-arounds such as "cross-domain scripting" and the use of a reverse proxy (see the ADL Co-Lab Cross Domain Scripting Document for more details, www.adlnet.gov/downloads/downloadpage.aspx?ID=58). Even with established guidance, these technical issues and work-arounds are considerably complex, and continue to challenge experienced and inexperienced WBT users alike.
Moving Forward
Most of these issues can be avoided by coordinating closely with corporate IT to determine the proper browser configuration and WBT location. While it seems absurd to allow a training initiative to jeopardize organizational and personal security, it does make sense to review certain security restrictions regularly to ensure that training is being delivered effectively in concert with the latest security measures. Sometimes, under the right circumstances, security protocols may even have to be relaxed to accommodate training requirements.
Sidebar: Checklist
To help avoid some Web-Based Training (WBT) issues, answer the following questions about your program:
• What will your WBT require from the browser (plug-ins, JavaScript)?
• How many different browsers will the WBT support?
• Where are the learners located (behind the corporate firewall, at remote offices, at home?)
• Where will the WBT content be located?
Armed with these answers, you should have enough information to discuss the security needs of your WBT with your corporate IT staff. They should be able to determine whether their standard browser configurations will accommodate your needs, or whether additional browser or hosting configurations will need to be changed. Based on other IT initiatives, they may ask you whether you can reduce some of the WBT requirements to avoid problems (perhaps with users outside your corporate environment). In any event, it is always best to have this discussion as early as possible for each WBT initiative.
Steven A. Kerschenbaum is CTO/GC, and Sean Brady is CIO/chief systems architect at Falls Church, VA-based VERTEX Solutions, Inc. For more information, visit www.vertexsolutions.com.
|
RSS
