Posted by Tom King
There’s been much discussion among developers and insiders about recent posts and vendor notices regarding automated cheating tools for SCORM 1.2/SCORM 2004 content. I’d like to share some thoughts on the underlying issues and measures that can be taken to reduce vulnerability. This is no joke… unlike the recent fun on Eric’s blog. This is the first in a series of posts on this topic. I’d like to review a few key concepts before delving into specific areas and solutions that will come in the posts to follow.
Security is important. The cornerstone of successful education, training and certification is the effective use of assessments. Inaccurate, misleading or falsified performance data can lead to poor decisions, increased liability and other significant risks or consequences. Questionmark is keenly aware of the importance of security and has addressed the issue from the beginning.
Vulnerabilities exist. Note that this is vulnerabilities in the plural. About a week ago, an independent elearning developer published one: a simple bookmarklet to send false score and status data to a SCORM LMS (see Cheating in SCORM, Phillip Hutchison, 2009). [Note: The post remains, but the sample bookmark has been removed after an outside party requested this.]
Using the published exploit is as simple as saving a book mark to your browser and then picking that bookmark while content is running. It is what I’ve called a “cheatlet” and current implementations may foreshadow other potential issues (see Security Before Features, Tom King, 2008 on LETSI SCORM 2.0 web site). Others have discussed how common in-browser debugging tools like Firebug can be used to similar effect. The key message is that this type of exploit is possible, and it gets easier and more viable over time.
Defense in depth. That phrase is a bit of a mantra in the cybersecurity world. Questionmark has taken this approach with its implementation of interoperability solutions, including SCORM. Some in the SCORM community recognize the “cheatlet” exploit as a known weakness that has just become easier for the common man to use. They go on to indicate that SCORM shouldn’t be used for high stakes assessments, and end their argument or response there. It is left for future specifications to deal with this issue. However there are several alternatives to decrease vulnerability.
I think I now have your attention for the subsequent posts.
Also, if you’re attending the Questionmark User Conference 2009 this coming week in Memphis, please feel free to stop by for my session on standards and ask about this or other standards-related issues.