Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Secure Coding and Threat Modeling

1 778 vues

Publié le

Secure Coding and Threat Modeling presentation slides for 2017 SFISSA Security Conference

Publié dans : Ingénierie

Secure Coding and Threat Modeling

  1. 1. Secure Coding & Threat Modeling Miriam Celi, CISSP SFISSA Security Conference March 10, 2017
  2. 2. Tenure: 20+ years in IT, various roles, 7 years in security Currently role: ITQA Software Security Technology Leader, Humana Inc. Why I like to work in security: 1. Challenge 2. Unknown 3. Passion 4. Helping Social Media: @mcelicissp Blog: https://mceliblog.wordpress.com/ About me Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  3. 3. Agenda • Statistics • Secure Coding • Resources • Threat Modeling • Approaches • Process • MS Tool Demo Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  4. 4. • Average global cost per breach reached $4 million in 2016 increasing from $3.5 million in 2014. ➢ In the US it rose from $5.85 million in 2014 to $7 million in 2016. • Average global cost per record stolen in 2016 was $158 increasing from $145 in 2014. ➢ In the US it rose from $201 in 2014 to $221 in 2016. • The global cost of cybercrime is expected to reach $2 trillion by 2019, a threefold increase from the 2015 estimate of $500 billion. • The average cost of a data breach will exceed $150 million by 2020 http://www-03.ibm.com/security/data-breach/ https://www.juniperresearch.com/press/press-releases/cybercrime-cost-businesses-over-2trillion Cybercrime Statistics Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  5. 5. IBM 2011 Sampling of Security Incidents 64 security incidents from Jan 8, 2011 to Dec 27, 2011. http://www-03.ibm.com/security/xforce/xfisi/ Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  6. 6. http://www-03.ibm.com/security/xforce/xfisi/ IBM 2016 Sampling of Security Incidents 322 incidents from Jan 4, 2016 to Dec 31, 2016. Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  7. 7. Security Incidents and Vulnerabilities Trend 65 292 256 280 284 322 4155 5297 5191 7946 6452 6435 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 0 50 100 150 200 250 300 350 2011 2012 2013 2014 2015 2016 Number of Security Incidents Number of Vulnerabilities http://www-03.ibm.com/security/xforce/xfisi/ https://www.cvedetails.com/browse-by-date.php Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  8. 8. Secure Coding • Developing software that is resistant to attacks and preventing vulnerabilities from being introduced into the software • A significant number of software vulnerabilities can be traced to coding errors which have been shown to be the main cause for exploited vulnerabilities. • It’s important to be aware of secure coding guidelines and resources that can help us to develop more secure software: Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  9. 9. Secure Coding Principles Miriam Celi, CISSP ~ 2017 SFISSA Security Conference 1. Defense in Depth Security mechanisms are applied in multiple layers throughout the system 2. Secure Default/Default Deny Access is denied by default and requires to be configured or be turned on as needed 3. Positive Security Model (Whitelist) Only what is defined is allowed and what is not defined is denied 4. Least Privilege Application runs with the least set of privileges necessary to complete the job 5. Fail Securely If application fails, the same execution path as disallowing the operation is followed 6. Don’t Trust Not relying on or trusting the security mechanisms of other components 7. Keep it simple The higher the complexity in an application, the greater the attack surface 8. Logging Operations that were performed, the time they were performed, and who performed them. 9. Threat Modeling A way to analyze the security of a system, identifying its weaknesses, threats and exposures
  10. 10. Common Weakness Enumeration (CWE) • Software weaknesses are flaws, faults, bugs, vulnerabilities, and other errors in software implementation, code, design, or architecture that if left unaddressed could result in systems and networks being vulnerable to attack. Software weaknesses lead to software vulnerabilities. • CWE is: • A community-developed dictionary of software weakness types. • A common language for describing software security weaknesses in architecture, design, or code. • Targeted to developers and security practitioners. • A measuring stick for software security tools targeting these weaknesses. • A common baseline definition for weakness identification, mitigation, and prevention efforts. • Maintained by MITRE Corporation. https://cwe.mitre.org/ Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  11. 11. Rank ID Name Rank ID Name [1] CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') [14] CWE-494 Download of Code Without Integrity Check [2] CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') [15] CWE-863 Incorrect Authorization [3] CWE-120 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') [16] CWE-829 Inclusion of Functionality from Untrusted Control Sphere [4] CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') [17] CWE-732 Incorrect Permission Assignment for Critical Resource [5] CWE-306 Missing Authentication for Critical Function [18] CWE-676 Use of Potentially Dangerous Function [6] CWE-862 Missing Authorization [19] CWE-327 Use of a Broken or Risky Cryptographic Algorithm [7] CWE-798 Use of Hard-coded Credentials [20] CWE-131 Incorrect Calculation of Buffer Size [8] CWE-311 Missing Encryption of Sensitive Data [21] CWE-307 Improper Restriction of Excessive Authentication Attempts [9] CWE-434 Unrestricted Upload of File with Dangerous Type [22] CWE-601 URL Redirection to Untrusted Site ('Open Redirect') [10] CWE-807 Reliance on Untrusted Inputs in a Security Decision [23] CWE-134 Uncontrolled Format String [11] CWE-250 Execution with Unnecessary Privileges [24] CWE-190 Integer Overflow or Wraparound [12] CWE-352 Cross-Site Request Forgery (CSRF) [25] CWE-759 Use of a One-Way Hash without a Salt [13] CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') CWE/SANS Top 25 Most Dangerous Software Errors http://cwe.mitre.org/top25/#Listing Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  12. 12. • What is a vulnerability and what is an exposure? • A vulnerability is a mistake in software that can be directly used by a hacker to gain access to a system or network. • An exposure is a system configuration issue or a mistake in software that does not directly allow compromise but could be an important component of a successful attack. • CVE is: • A dictionary of common names for publicly known cybersecurity vulnerabilities. • Each common name includes a unique CVE identifier number, a brief description of the security vulnerability or exposure, and references (i.e., vulnerability reports and advisories). • Cross referenced with CWEs. • A basis for evaluation among tools and databases. • Free for public download and use. • Maintained by MITRE Corporation. Common Vulnerabilities and Exposures (CVE) http://cve.mitre.org Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  13. 13. Examples of Vulnerabilities • OpenSSL security vulnerabilities https://www.openssl.org/news/vulnerabilities.html • Java security vulnerabilities https://www.oracle.com/technetwork/topics/security/alerts- 086861.html • Top 2016 Open Source Vulnerabilities https://www.whitesourcesoftware.com/whitesource-blog/open- source-security-vulnerability/ • Qualys Top 10 Vulnerabilities https://www.qualys.com/research/top10/ • Top 50 Products By Total Number Of "Distinct" Vulnerabilities https://www.cvedetails.com/top-50-products.php Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  14. 14. National Vulnerability Database (NVD) • U.S. government repository of standards based vulnerability management data. • Provides information that enables automation of vulnerability management, security measurement, and compliance. • Includes databases of security checklists, security related software flaws, misconfigurations, product names, and impact metrics. • CVE list feeds NVD, which then builds upon the information included in CVE entries and enhances it with fix information, severity scores, and impact ratings. • NVD CVE scores quantify the risk of vulnerabilities, calculated from a set of equations based on metrics such as access complexity and availability of a remedy. • Provides advanced searching features such as by individual CVE ID; by OS; by vendor name, product name, and/or version number; and by vulnerability type, severity, related exploit range, and impact. https://nvd.nist.gov Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  15. 15. Common Attack Pattern Enumeration and Classification (CAPEC) • Community resource for identifying and understanding attacks • Comprehensive dictionary of common attack patterns • Each attack pattern:  defines a challenge that an attacker may face  provides a description of the common technique(s) used to meet the challenge  presents recommended methods for mitigating an actual attack • Targeted to developers, analysts, testers, and educators to advance understanding of attacks and enhance defenses. • Publicly available https://capec.mitre.org Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  16. 16. Some Well-Known Attack Patterns • HTTP Response Splitting (CAPEC-34) • Session Fixation (CAPEC-61) • Cross Site Request Forgery (CAPEC-62) • SQL Injection (CAPEC-66) • Simple Script Injection (CAPEC-63) • Buffer Overflow (CAPEC-100) • Clickjacking (CAPEC-103) • Relative Path Traversal (CAPEC-139) • XML Attribute Blowup (CAPEC-229) Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  17. 17. OWASP Top 10 https://www.owasp.org/index.php/Top_10_2013-Top_10 • OWASP is an organization focused on improving the security of software. • The Top 10 list represents the 10 most critical web application security risks • Provides guidance and techniques for protection. • A1-Injection • A2-Broken Authentication and Session Management • A3-Cross-Site Scripting (XSS) • A4-Insecure Direct Object References • A5-Security Misconfiguration • A6-Sensitive Data Exposure • A7-Missing Function Level Access Control • A8-Cross-Site Request Forgery (CSRF) • A9-Using Components with Known Vulnerabilities • A10-Unvalidated Redirects and Forwards Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  18. 18. OWASP Mobile Top 10 https://www.owasp.org/index.php/Mobile_Top_10_2016-Top_10 • Represents the 10 most critical mobile application security risks and provides guidance and techniques for protection. • M1: Improper Platform Usage • M2: Insecure Data Storage • M3: Insecure Communication • M4: Insecure Authentication • M5: Insufficient Cryptography • M6: Insecure Authorization • M7: Client Code Quality • M8: Code Tampering • M9: Reverse Engineering • M10: Extraneous Functionality Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  19. 19. OWASP Tools • Dependency check tool - identifies project dependencies and checks if there are any known, publicly disclosed, vulnerabilities. • ZAP proxy tool - used for testing and finding security vulnerabilities in web applications. • Web Goat and Mutillidae - deliberately insecure web applications designed to teach web application security lessons from the OWASP Top 10 list. • OWASP Vulnerable Web Applications Directory Project - registry of all known vulnerable web applications currently available for legal security and vulnerability testing of various kinds. Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  20. 20. OWASP Secure Coding Libraries • OWASP AppSensor - A conceptual framework and methodology that offers prescriptive guidance to implement intrusion detection and automated response into applications. • OWASP CSRFGuard - A Java library that implements a variant of the synchronizer token pattern to mitigate the risk of Cross-Site Request Forgery (CSRF) attacks. • OWASP Java Encoder Project – A Java 1.5+ simple-to-use, high-performance encoder class that helps Java web developers defend against Cross-Site Scripting (XSS). • OWASP Java HTML Sanitizer – A fast and easy to configure HTML Sanitizer written in Java which lets you include HTML authored by third-parties in your web application while protecting against XSS. • OWASP Security Logging Project - Provides developers and ops personnel with APIs for logging security-related events. The aim is to let developers use the same set of logging APIs with Log4J and its successors, while also adding powerful security features. • OWASP Enterprise Security API (ESAPI) - A free, open source, web application security control library that makes it easier for programmers to write lower-risk applications. Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  21. 21. Other Resources and Tools • SEI CERT Coding Standards – for C, C++, Java, and Perl, and the Android™ platform. • Cybrary Secure Coding Course – free online course • SCFM Secure Coding Field Manual - reference book for Cybrary’s Secure Coding course • Burp Suite Free and Professional Editions – scan for vulnerabilities, intercept browser traffic, test security of web applications. • Burp Scanner Issues – Issue definitions, remediations and references • Fiddler – free web debugging proxy for any browser, system or platform for security testing your web applications Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  22. 22. Threat Modeling To build secure software, we need to understand the risks related to:  weaknesses in design, coding and integration  use cases and abuse cases The goal of threat modeling is to identify potential risks or attacks that can occur to the system as it will be deployed, and to make decisions to address these risks in the design and development of the application. Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  23. 23. Threat Modeling • A threat is an undesired event that may damage or compromise an asset or objective. It may or may not be malicious in nature. • An asset is a resource of value and can vary by perspective:  To the business, an asset might be the availability of information, or the information itself, such as customer data.  It might be intangible, such as a company's reputation.  To an attacker, an asset could be the ability to misuse your application for unauthorized access to data or privileged operations. Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  24. 24. Threat Modeling What it is What it’s not A team activity An activity performed by a single person. A crucial activity in developing secure applications An optional activity for developing secure application An activity that helps identify vulnerabilities in software A security audit An activity started early in the design phase An activity started late in the application life cycle An iterative process that should be performed for every release, sprint, or iteration An activity that is only performed once or once in a while Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  25. 25. Benefits of Threat Modeling • Finding security bugs early • Improved understanding of security requirements • Engineer better products and services • Addresses security issues hidden in design • Develop secure by design solutions Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  26. 26. Threat Modeling Participants • Threat modeling is a team activity • Members of development and test teams, such as:  Application architects  Security professionals  Developers  Testers  System Administrators • Work together to identify exposures in the application design of a system. Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  27. 27. Threat Modeling Questions • It is important to identify:  what is being built? (the scope of the threat model)  what are the requirements?  what could go wrong? (abuse and exception cases)  possible bugs  what can be done to address the issues? (mitigation techniques). Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  28. 28. Threat Modeling Approaches 1. Software-centric Focus is on software being built and what weaknesses and vulnerabilities are likely to be introduced in Design, Coding or Build Integration. 2. Asset-centric Focus is on assets needing protection and entrusted to a system or software (data processed by the software) and what scenarios might compromise them or lead to non-compliance. 3. Attacker-centric Focus is on profiling an attacker’s characteristics, skill-set, and motivation to exploit vulnerabilities and what scenarios might attackers use to compromise the application, system or service Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  29. 29. Software-centric Approach • Questions to consider:  How is software designed and constructed?  What are the languages, components and runtimes used?  What are the relevant coding practices followed?  How is software built and integrated? • Involves the use of software architecture diagrams such as data-flow diagrams (DFD), use case diagrams, or component diagrams to identify threats to the design of the system. Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  30. 30. Miriam Celi, CISSP ~ 2017 SFISSA Security Conference Data-Flow Diagram Example
  31. 31. Asset-centric Approach • Questions to consider:  What are the assets entrusted to the system or software?  What is the estimated value of those assets?  What are the consequences to compromise or loss of the assets?  How are those information assets protected? Involves the use of attack trees or attack patterns by which an asset can be attacked. Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  32. 32. Attacker-centric Approach • Questions to consider:  Who is authorized and who is not?  What privileges do users have?  How is the software intended to be used?  How can the software be abused? This approach also uses attack trees or attack patterns with focus on the specific goals of an attacker, how attacks could be carried out, and how to mitigate such attacks. Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  33. 33. Attack Tree Example • Root node represents the goals of the attacker. • Leaf nodes represent the unique attack methods. Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  34. 34. Which Approach to Use? • Software centric approach is best in exposing issues in the design of a system because the focus is on the software being built. • Asset and Attacker centric approaches are important approaches to apply in threat modeling as well, but it’s best not to combine approaches to avoid confusion in the process. • A recommendation would be to start with the software centric approach for one release or sprint, and switch to a different approach for the next release or sprint. • Different approaches bring out different perspectives and different issues to light. Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  35. 35. Threat Modeling Process Threat modeling is an iterative process that should be repeated as the application evolves (for every release, sprint, or iteration) Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  36. 36. Step 1. Identify Assets • Identify the assets that need to be protected. • Assets are classified according to data sensitivity and their intrinsic value to a potential attacker. • Assets can range from confidential data, such as your customer or orders database, to web pages or web site availability. Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  37. 37. Step 2. Create an Architecture Overview • Identify what the application does (Use cases and misuse cases) • Create an architecture diagram • Identify the technologies used (helps to determine technology- specific threats). Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  38. 38. Step 3. Decompose the Application • Identify trust boundaries (surrounding the assets) • Identify data flow (Data flow across trust boundaries is particularly important) • Identify entry points (also serve as entry points for attacks) • Identify privileged code (accesses specific types of secure resources and performs other privileged operations) • Document the security profile (helps to uncover vulnerabilities in the design, implementation, or deployment configuration of your application). Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  39. 39. • Identify the threats that could affect the application (keep goals of attacker, architecture and potential vulnerabilities in mind): • network threats • host threats • application threats • The STRIDE threat classification methodology can be used to identify threats. Step 4. Identify the Threats Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  40. 40. STRIDE – Threat Classification Methodology Category Threat Template Spoofing Threat action aimed to illegally access and use another user's credentials, such as username and password. Tampering Threat action aimed to maliciously change/modify persistent data, such as persistent data in a database, and the alteration of data in transit between two computers over an open network, such as the Internet. Repudiation Threat action aimed to perform illegal operations in a system that lacks the ability to trace the prohibited operations. Information Disclosure Threat action to read a file that one was not granted access to, or to read data in transit. Denial of Service Threat aimed to deny access to valid users, such as by making a web server temporarily unavailable or unusable. Elevation of Privilege Threat aimed to gain privileged access to resources for gaining unauthorized access to information or to compromise a system. Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  41. 41. Step 5. Document the Threats Document each threat using a common threat template that defines a core set of attributes to capture for each threat: Threat Description Attacker obtains authentication credentials by monitoring the network Threat target Web application user authentication process Risk Rating TBD in Step 6 Attack techniques Use of network monitoring software Countermeasures Use SSL to provide encrypted channel Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  42. 42. Step 6. Rate the Threats • Rate the threats to prioritize and address the most significant threats first. These threats present the biggest risk. • The rating process weighs the probability of the threat against damage that could result should an attack occur. • It may turn out that certain threats do not warrant any action when you compare the risk posed by the threat with the resulting mitigation costs. • The DREAD model can be used to help calculate risk. Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  43. 43. DREAD – Risk Ranking Methodology With the DREAD model, you arrive at the risk rating for a given threat by asking the following questions: • Damage potential: How great is the damage if the vulnerability is exploited? • Reproducibility: How easy is it to reproduce the attack? • Exploitability: How easy is it to launch an attack? • Affected users: As a rough percentage, how many users are affected? • Discoverability: How easy is it to find the vulnerability? Risk = (Damage + Reproducibility + Exploitability + Affected Users + Discoverability) / 5 Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  44. 44. Example DREAD Table Rating High (4-5) Medium (2-3) Low (1) D Damage potential The attacker can subvert the security system; get full trust authorization; run as administrator; upload content. Leaking sensitive information Leaking trivial information R Reproducibility The attack can be reproduced every time and does not require a timing window. The attack can be reproduced, but only with a timing window and a particular race situation. The attack is very difficult to reproduce, even with knowledge of the security hole. E Exploitability A novice programmer could make the attack in a short time. A skilled programmer could make the attack, then repeat the steps. The attack requires an extremely skilled person and in-depth knowledge every time to exploit. A Affected users All users, default configuration, key customers Some users, non-default configuration Very small percentage of users, obscure feature; affects anonymous users D Discoverability Published information explains the attack. The vulnerability is found in the most commonly used feature and is very noticeable. The vulnerability is in a seldom- used part of the product, and only a few users should come across it. It would take some thinking to see malicious use. The bug is obscure, and it is unlikely that users will work out damage potential. Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  45. 45. Threat Modeling • An outcome of the threat modeling activity is a threat model document that identifies:  Asset, actors, use cases  Relevant threats  Weaknesses that could be exploited  Countermeasures • Threat modeling is an iterative process. The threat model is a document that evolves and that various team members can work from. Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  46. 46. MS Threat Modeling Tool The Microsoft Threat Modeling Tool (TMT) 2016 is designed to guide you and your product team through the threat modeling process. TMT functionality includes: • An easy drawing environment. • Automatic threat generation using the STRIDE per interaction approach. • Define your own template for threat modeling • An option for user-defined threats to be added. • Graphically identify processes and data flows that comprise an application or service. https://www.microsoft.com/en-us/download/details.aspx?id=49168 Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  47. 47. Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  48. 48. References • https://msdn.microsoft.com/en- us/library/ee823878(v=cs.20).aspx • https://msdn.microsoft.com/en-us/library/ff648644.aspx • https://www.microsoft.com/en- us/download/details.aspx?id=49168 • https://www.owasp.org/index.php/Threat_Risk_Modeling • https://en.wikipedia.org/wiki/Threat_model • https://www.amazon.com/Threat-Modeling-Designing-Adam- Shostack/dp/1118809998 Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  49. 49. Miriam Celi, CISSP ~ 2017 SFISSA Security Conference
  50. 50. Miriam Celi, CISSP ~ 2017 SFISSA Security Conference