Fendley how secure is your e learning


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Fendley how secure is your e learning

  1. 1. How Secure Is Your E-learning Environment? <br />step by step process for developing a threat profile of your environment<br />
  2. 2. Bryan FendleyDirector of Academic Computing University of Arkansas at Monticello <br />Instructor for network security courses<br />Blackboard Certified Unix Administrator, Blackboard Certified Trainer <br />SANS Certifications: Penetration Testing, Incident Handling, Web Application Security, and Computer Law, Reverse Engineering Malware <br />
  3. 3. Agenda<br />Basics of Threat Modeling<br />Review of Threat Modeling Processes<br />Threat Modeling Tools<br />
  4. 4. What’s the Big Deal?<br />Majority of hacker attacks occur on web applications<br />E-learning lives on the web<br />
  5. 5. Top Ten Web Vulnerabilities<br />Injection<br />Cross-Site Scripting (XSS)<br />Broken Authentication and Session Management<br />Insecure Direct Object References<br />Cross-Site Request Forgery (CSRF)<br />Security Misconfiguration<br />Insecure Cryptographic Storage<br />Failure to Restrict URL Access<br />Insufficient Transport Layer Protection<br />Invalidated Redirects and Forwards<br />
  6. 6. Why would anyone even want to hack a CMS? <br />Accidental discovery<br />Automated malware<br />The Curious attacker<br />Script Kiddies<br />The Motivated Attacker<br />Organized Crime<br />
  7. 7. Advantages of Threat Modeling<br />Understand application architecture<br />Identify what needs to be protected<br />Identify vulnerabilities associated with each part of your system<br />Develop mitigation strategies<br />
  8. 8. Basics of Threat Modeling<br />
  9. 9. Basic Steps that most Threat Models have in common<br />Gather Information<br />Decompose App<br />Data Flow Diagrams<br />Identify Risk<br />Use Cases<br />Attack Trees<br />
  10. 10. Gather Information<br />Ask questions<br />Learn how your system is being is used<br />It’s what you don’t know that can hurt you<br />
  11. 11. Decompose App<br />List and describe system components<br />Client <br />Web<br />Presentation Layer<br />Business Logic<br />Data<br />
  12. 12. DFDs<br />Data flow diagrams (DFDs) examine flow from process view<br />A data-flow diagram (DFD) is a graphical representation of the "flow" of data through an information system.<br />
  13. 13. Determine Risk<br />Determine major data types and corresponding classification<br />Classification based on business risk, will vary by organization<br />
  14. 14. Use Cases<br />Using threat modeling systemically define attack vectors and threat risk for each use case<br />Generally time is limited so you’ll need to limit your analysis to those use cases with the most sensitive data<br />
  15. 15. Determining Risk<br />This is where application security-specific domain knowledge is required<br />Risk= Likelihood x Impact<br />Lots of great resources<br />Open Web Application Security Project (OWASP) has a list of known attacks (http://www.owasp.org/index.php/Category:Attack)<br />An even more comprehensive resource is the Common Weakness Enumeration by MITRE (http://cwe.mitre.org/). Many of these also come with likelihood<br />
  16. 16. Review of Threat Modeling Processes<br />
  17. 17. 6 Threat modeling processes/classification schemes<br />Microsoft’s Threat Modeling Process<br />STRIDE (classification scheme)<br />DREAD<br />AS/NZ 4360<br />CVSS (classification scheme)<br />OCTAVE<br />
  18. 18. This will give you ideas for which approach works best for you, and to adopt the most appropriate threat modeling tools for your organization<br />
  19. 19. Notable Threat Models<br />Microsoft Threat Modeling Process <br />STRIDE<br />DREAD<br />Trike<br />AS/NZS 4360:2004 Risk Management<br />OCTAVE<br />
  20. 20. Microsoft Threat Modeling Process<br />
  21. 21. 1. Identify Security Objectives<br />What needs to be protected?<br />Identity<br />Financial<br />Reputation<br />Privacy and regulatory<br />Availability<br />Microsoft Threat Modeling Process<br />
  22. 22. 2. Application Overview<br />How does your app work?<br />Once the security objectives have been defined, analyze the application design to identify the components, data flows, and trust boundaries<br />Microsoft Threat Modeling Process<br />
  23. 23. 3. Decompose Application<br />Once the application architecture is understood then decompose it further, to identify the features and modules with a security impact that need to be evaluated<br />Microsoft Threat Modeling Process<br />
  24. 24. 4. Identify Threats<br />What are the most likely threats to your system?<br />Microsoft Threat Modeling Process<br />
  25. 25. 5. Identify Vulnerabilities<br />Where are your weaknesses<br />Microsoft Threat Modeling Process<br />
  26. 26. Notable Threat Models<br />Microsoft Threat Modeling Process<br />STRIDE<br />DREAD<br />Trike<br />AS/NZS 4360:2004 Risk Management<br />OCTAVE<br />
  27. 27. STRIDE<br />Classification scheme for characterizing known threats according to the kind of exploit used<br />STRIDE acronym is formed from the first letter of each of the following categories<br />Spoofing Identity<br />Tampering with Data<br />Repudiation<br />Information Disclosure<br />Denial of Service<br />Elevation of Privilege<br />
  28. 28. Spoofing Identity<br />Key risk for applications with many users<br />Provides single execution context at the application and database level<br />Users should not be able to become or assume the attributes of any other user<br />STRIDE<br />
  29. 29. Tampering with Data<br />Users can change data, return data, and manipulate client-side validation<br />STRIDE<br />
  30. 30. Repudiation<br />Users may dispute transactions if there is insufficient auditing or recordkeeping<br />STRIDE<br />
  31. 31. Information Disclosure<br />Users are rightfully wary of submitting private details to a system<br />
  32. 32. Denial of Service<br />Application designers should be aware that their applications may be subject to a denial of service attack<br />STRIDE<br />
  33. 33. Elevation of Privilege<br />If an application provides distinct user and administrative roles, then it’s vital to ensure that the user cannot elevate their role to a higher privilege one<br />STRIDE<br />
  34. 34. Notable threat models<br />Microsoft Threat Modeling Process<br />STRIDE<br />DREAD<br />Trike<br />AS/NZS 4360:2004 Risk Management<br />OCTAVE<br />
  35. 35. DREAD<br />Classification scheme for quantifying, comparing and prioritizing the amount of risk presented by each evaluated threat<br />DREAD acronym is formed from the first letter of each category below<br />Damage Potential<br />Reproducibility<br />Exploitability<br />Affected Users<br />Discoverability<br />
  36. 36. Damage Potential<br />If a threat exploit occurs, how much damage will be caused?<br /> 0 =Nothing<br /> 5 = Individual user data is compromised or affected<br />10= Complete system or data destruction<br />DREAD<br />
  37. 37. Reproducibility<br />How easy is it to reproduce the threat exploit?<br />0 = Very hard or impossible<br />5 = One or two steps required<br />10 = Just a web browser and the address bar is sufficient<br />DREAD<br />
  38. 38. Exploitability<br />What is needed to exploit this threat?<br />0 = Advanced programming and networking knowledge, with custom or advanced attack tools<br />5 = Malware exists on the Internet, or an exploit is easily performed<br />10 = Just a web browser<br />DREAD<br />
  39. 39. Affected Users<br />How many users will be affected? <br />0 = None<br />5 = Some users, but not all<br />10 = All users<br />DREAD<br />
  40. 40. Discoverability <br />How easy is it to discover this threat?<br />0 = Very hard to impossible<br />5 = Can figure it out by guessing or monitoring network traces<br />9 = Details of faults like this are already in public domain and can be discovered by a search engine<br />10 = The information is visible in the web browser address bar or in a form<br />DREAD<br />
  41. 41. Notable Threat Models<br />Microsoft Threat Modeling Process<br />STRIDE<br />DREAD<br />Trike<br />AS/NZS 4360:2004 Risk Management<br />OCTAVE<br />
  42. 42. Trike<br />Identifies areas of importance with assistance from system stakeholders<br />(use of automated tools to test results)<br />Empower stakeholders to understand and reduce the risks to them and other stakeholders<br />Works from a defensive perspective not from the hackers<br />
  43. 43. Notable Threat Models<br />Microsoft Threat Modeling Process<br />STRIDE<br />DREAD<br />Trike<br />AS/NZS 4360:2004 Risk Management<br />OCTAVE<br />
  44. 44. AS/NZS 4360:2004 Risk Management<br />Australian/New Zealand Standard is the world’s first formal standard for documenting and managing risk<br />Does not lock organizations into a particular risk management methodology<br />
  45. 45. Five steps of the AS/NZS 4360 process are:<br />Establish Context<br />Identify the Risks<br />Analyze the Risks<br />Evaluate the Risks<br />Treat the Risks<br />
  46. 46. Advantages of AS/NZS 4360<br />Works well for organizations that prefer to manage risks in a traditional way, such as just using likelihood and consequences to determine an overall risk<br />Works best for business or systematic risks than for technical risks<br />
  47. 47. OCTAVE<br />The Operationally Critical Threat, Asset and Vulnerability Evaluation<br />
  48. 48. OCTAVE<br />OCTAVE is a process, not a technology one can purchase.<br />OCTAVE requires a cross-functional analysis team to lead the process (executives, managers, workers and IT).<br />OCTAVE was developed thru coordination between CERT and Carnegie Mellon Software Engineering Institute. <br />OCTAVE is self-directed, flexible and focuses on balancing risk with productivity thru tactical operations, strategic direction and technology. <br />
  49. 49. Clearly Define An Asset<br />IT personnel may be aware that a large Oracle database is housing student records, but may have no idea what version of Solaris is installed on the server or what version of Oracle is active.<br />
  50. 50. Multi-Perspective<br />OCTAVE recommends that from a network point of view, each asset is analyzed from multiple perspectives-including from within the network and from outside the network.<br />Inspection of an asset from many perspectives ensures that different levels of vulnerability risks are discovered. <br />
  51. 51. Scope<br />Attempting to manage any security analysis for an entire network presents an unwieldy challenge. <br />OCTAVE suggests that an analysis should be scoped according to the parameters set forth by the analysis team. <br />
  52. 52. Reference Public Catalogs<br />OCTAVE suggests benchmarking a threat against a common directory such as CVE or lists such as BugTraq or the SANS Top 20.<br />The OCTAVE process suggests benchmarking against public catalogs of references such as CVE and SANS.<br />By utilizing the internal vulnerability databases of these tools, OCTAVE analysts are automatically given the cross-reference information linking to public security catalogs.<br />
  53. 53. Design, Implementation and Configuration Vulnerabilities<br />Design Vulnerability<br />Implementation Vulnerability<br />Configuration Vulnerability<br />
  54. 54. Limitations of OCTAVE<br />Large and complex<br />Does not provide a list of “out of the box” practices for assessing and mitigating web application security risks<br />But it does come with workbooks!<br />
  55. 55. CVSS<br />Common Vulnerability Scoring System<br />The Common Vulnerability Scoring System (CVSS) provides an open framework for communicating the characteristics and impacts of IT vulnerabilities.<br />Common Vulnerability Scoring System Version 2 Calculator<br />
  56. 56. Threat Modeling Tools<br />
  57. 57. Tools<br />Microsoft Threat Analysis and Modeling free tool is best bet<br />Search for this at msdn.microsoft.com<br /> Alternative open-source Risk Management tools<br />OSMRMARCOCORAS Risk Assessment PlatformISO 17799 Risk Assessment ToolkitEasy Threat Risk AssessmentARMSMinacciaThreatMindOpen Source Requirements Management Tool<br />
  58. 58.
  59. 59. Applied Threat Modeling Conclusion<br />Lots of people talk about threat modeling, few people do it<br />Why? It is very time consuming and cumbersome<br />ways to reduce workload:<br />Keep threat pattern libraries for specific application types<br />Concentrate on only highly sensitive data types<br />Prioritize attack trees<br />Once a threat model has been created it is a living document<br />
  60. 60. OWASPThe Open Web Application Security Project <br />Where to learn more<br />
  61. 61. Too learn more about web vulnerabilities try WebGoat<br />
  62. 62. Final Message<br />Pick a Method that Works for You <br />and <br />Make the Effort to do a Formal Vulnerability Assessment!<br />http://BryanFendley.com<br />