Security Issues In SCORM

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 Cheaters Should Be Proctored • 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….

5. Technical Security Issues Points of Entry • 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/

6. Technical Security Issues Points of Entry (Debuggers) • 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-Live-site-_2D00_-Fun-and-Games.aspx

7. Technical Security Issues Framing the 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? • A combination of both is a good bet.

8. Prevention Stop Them in Their Tracks • 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.

9. Lines of Defense The Basics • 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 hacker will just proceed through the course.

10. Lines of Defense First Line 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

11. Lines of Defense Second Line 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.

12. Lines of Defense Third Line 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.

13. Lines of Defense Fourth Line 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.

14. Detection Trespassers will be prosecuted! • 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.

15. Examples "Show Me" • 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

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 Further Research • 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/DispForm2.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

18. SCORM Security Hands-On Training JCA Solutions Hands-On Guide to 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. http://www.jcasolutions.com/training.php

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