1. Security Issues In SCORM

2. The "Recent" History
• Dr. Bill Blackmon introduces SLAG and
Assessment Security (Aug. 23rd
, 2006)
• Claude Ostyn addresses Assessment Security in
"In the Eye of the SCORM" (Last Revised March
2007)
• Philip Hutchison posted WORKING bookmarklet
on his blog PiPwerks.com (April 2nd
, 2009)
• SCORM Community reacts
– Mike Rustici (scorm.com) responds (April 3rd
, 2009)
– Tom King (mobilemind.net) responds (April 5th
, 2009)
• ADL responds (May 31st
, 2009)
• ADL Implementation Fest Developers’ Workshop :
Security Issues in SCORM

3. Types of Security Issues
• Physical Security Issues
– Open Book, Open System
– Student Validation
– Plain Old Cheating
• Technical Security Issues
– Bookmarklet
– Script Injection / Script Include
– JavaScript Debugger

4. Physical Security Issues
• Open Book / Open System
– Search the web
– Search a book
• Student Validation
– Who is taking the test?
• Plain Old Cheating
– Taking screenshots of the exams
– Paying / bartering for the answer keys
• The list goes on….
Cheaters Should Be Proctored

5. Technical Security Issues
• Bookmarklets
– JavaScript can be written in the address bar of the browser and made
to execute on the current web page loaded in the browser.
• http://libgmail.sourceforge.net/googlemaps.html
• http://www.gnucitizen.org/blog/bookmark-of-death-domain-hijacking-
without-0days/
– Browser support
• https://www.squarefree.com/bookmarklets/browsers.html
• Script Injection / Script Include
– If the bookmarklet is not robust enough, you can use the bookmarklet
to embed your own JavaScript files into the web page.
– http://leftlogic.com/lounge/articles/bookmarklet-coding/
Points of Entry

6. Technical Security Issues
• Internet Explorer
– Web Accessibilty Toolkit
– Microsoft Script Debugger
– Internet Explorer Developer’s Toolbar
– IE Script Debugger (View > Script Debugger) IE7 and IE8
• FireFox
– Web Accessibilty Toolkit
– Fire Bug
– FireFox Error Console
• Any Browser
– Visual Studio 2005
• http://weblogs.asp.net/pglavich/archive/2006/11/02/Debugging-Javascript-on-a-
Points of Entry (Debuggers)

7. Technical Security Issues
• Who will be trying to hack the course or assessment?
– Students that do not know the material well enough to pass the course
– Students that want to see if they can beat the system.
– Developers that are testing vulnerabilities.
• What will the hacker be trying to accomplish?
– Modify the score, status, session time, interactions, objectives …
• Most students will only think to modify score and status.
• What is the benefit and risk to the hacker?
– Is the hacker confident that the solution they have (created or found on
the Web) will work on the system they intend to hack? And if it fails, or
if they are detected, what is the risk to them personally?
• Prevention vs. Detection
– Is the goal of the implemented security measure to prevent hacking or
detect hacking once it has occured?
Framing the Issues

8. • First Line of Defense
– Easy to implement. Stop most weekend hackers.
– Easily circumvented by savvy hackers
• Second Line of Defense
– A bit more difficult to implement
– Stops programmers that do not have knowledge of SCORM
• Third Line of Defense
– Take significant time and skill to implement
– This defense comes down to “Is it worth it to hack?” not “Can it be
hacked?”
– Coupled with Detection and Prosecution there is virtually no reason
for someone to take the risk.
• Fourth Line of defense
– Proctor the exam!
– If the stakes are that high that someone will try to even break the 3rd
line of defense, then there may be a need to have an instructor
present.
Prevention
Stop Them in Their Tracks

9. Lines of Defense
• Must be logged into the LMS as a student and be able to
access the course to be hacked.
– Remind students not to share passwords and make a strong dis-
incentive for doing so.
• That means if you can detect an attempted hack, you can locate the
account and person responsible.
• Must have the knowledge to perform the hack.
– Gained the knowledge from their own knowledge of programming
• Highest risk to the course
– Gained the knowledge from another hacker (e.g., the Web, word of
mouth)
• Medium risk to the course
• Must have the willingness / incentive to perform the hack
– In most cases, if it is easier to pass the course than implement a hack,
The Basics

10. Lines of Defense
• Disable right click
– This will keep the student from using the right click functionality to
view the source code of the course
• Obfuscate (scramble) or crunch your JavaScript code
– Use a JavaScript obfuscation application which removes all whitespace
and replaces function and variable names with “a” and “-#-” so the
code becomes virtually unreadable
• Only use Script includes
– This is just a good coding practice in general. Don’t include JavaScript in
with the HTML. Put JavaScript in “.js” files and use <script
src=“myFile.js”></script> to include them in the page.
• Open the course in a new window with the address bar and
toolbar hidden AND disable F11.
• Hide SCORM code in frames
First Line of Defense

11. Lines of Defense
• Use FLASH
– FLASH is compiled into .swf files, so it is harder to see the code from
within the browser
• FLASH can be decomplied, so obfuscating the code is also an option
• Use more than score and status to determine grade
– Make sure that the course uses objectives, interactions and session
time, along with score and status, to calculate the overall grade.
• The "Fake" API
– Add an API object local to your course, so hackers will find that API and
set values there instead of the real API.
• Set and Terminate
– Set all important data at the LAST possible moment before Terminate()
is called.
Second Line of Defense

12. Lines of Defense
• Secret SCO
– Create a manifest file with a hidden SCO that must be completed in order for
the course to be passed. Have the assessment SCO set an objective on the
hidden SCO equal to the score on the quiz SCO.
• Hide and Go Seek
– Have the assessment SCO set an encrypted cookie or Flash Shared Object and
then the last SCO of the course looks at this cookie to determine the final
score. The final SCO will not set any score that does not match the score in the
cookie.
• Rollup With a Twist
– Have a combinaton of random objective scores that must be set, and add up to
the proper total, in order to mark the course completed.
• SCO1 : Objective 1 score = .10
• SCO2 : Objective 1 score = .17
• SCO3 : Objective 1 score = .28
• If the total for objectives = .55 then course is passed.
Third Line of Defense

13. Lines of Defense
• Don’t use SCORM for assessments
– Use a 3rd
party server side assessment service.
• Proctor The Exam!
– This could also be your first and only Line of Defense as well,
depending on the stakes involved.
Fourth Line of Defense

14. Detection
• On the LMS Side
– Session Time Comparison
• Compare the session time to the actual time the student spent in the SCO.
– Compare results to known averages
• Compare student "X" SCORM data with the average students’ SCORM data.
– Make sure that there is not too much or too little data reported and that it fits
within the "normal" parameters for that course.
• On the SCO Side
– The "Fake" API
• Using the fake API, you can detect when a hack is being attempted on the
fake API, which will be the first one that the would-be hacker will locate.
• Once a hack is detected, the SCO should write some data to the LMS to
signal a breach has occured.
– Set an objective, set an interaction, set suspend_data. You would want to set a
data model element that can be reported on by the LMS.
Trespassers will be prosecuted!

15. Examples
• First Line of Defense
– Disable Right Click
– Open new window and disable F11
• Second Line of Defense
– Fake the API
– Set and Terminate
• Third Line of Defense
– Rollup With a Twist
"Show Me"

16. Conclusion
• High stakes assessments should be proctored
• SCORM may not be a good technology choice for non-
proctored high stakes exams.
• There are ways to make courses more difficult to hack, but
this does not prevent physical types of cheating.
• In the end, any type of technical secutiry measure should be
seen as a deturent and not as the ultimate solution. And any
security measure implementation should ultimately be
weighed against the effect the security measure has on
usability.

17. Resources
• SCORM Security – Some Perspective
– http://www.scorm.com/blog/2009/04/scorm-security-some-
perspective/
• PiPwerks Blog
– http://pipwerks.com/journal/2009/04/02/scorm-security-two-kinds-
of-scorm-people/
• ADL’s Answer
– http://www.adlnet.org/Technologies/scorm/Lists/Announcements/Dis
pForm2.aspx?List=025c59e6-41d3-4496-b4cb-7a3033dea50d&ID=6
• SCORM Vulnerabilities + IMS Spec withdrawal = Excitement
– http://mobilemind.net/2009/04/scorm-vulnerabilities-ims-spec.html
• In the Eye of The SCORM : Assessment Security
– http://www.ostyn.com/standards/docs/Eye_Of_The_SCORM_draft.pdf
Further Research

18. SCORM Security
• Instructor Lead On-Line Training Seminar
• One-Day of lecture and labs
• Discusses security risks and pros and cons of the solutions
• Learn how the hackers think
– For every security solution demonstrated you will learn the
vulerabilityes so you can assess the risk for yourself.
Hands-On Training
JCA Solutions Hands-On Guide to SCORM Security
http://www.jcasolutions.com/training.php

19. Contact Info
Brian Caudill
bcaudill@jcasolutions.com
http://www.jcasolutions.com
321-765-4947
Workshop Materials @
www.jcasolutions.com/scorm_securit
y
JCA Solutions