Recommended
More Related Content
What's hot
What's hot (20)
Similar to Null bachav
Similar to Null bachav (20)
Recently uploaded
Recently uploaded (20)
Null bachav
- 2. Agenda Introduction to Threat Modeling Different Ways to perform Threat Modeling Different Stages of Threat Modeling Understanding STRIDE & DREAD Basics of Mobile Threat Modeling LAB Conclusion
- 5. SDL Threat Modeling Tool
- 6. Where do Threat Modeling Fit?
- 7. Asset Definition: “an item of property owned by a person or company, regarded as having value and available to meet debts, commitments, or legacies”
- 8. What is a threat?
- 9. Threats Threats can be of: • Natural Disasters: Floods, earthquakes etc. • Service failures: air conditioners, power • Accidental Threats: Humans • Technical failures: network issues • Malicious Human: insider and external attackers
- 10. What is a Vulnerability? •Vulnerability is a weakness in the system which will aid the attacker in successful execution/exploitation of the threat. Example: Suppose you have a web server with low bandwidth connection. Where the threat is that your server could be taken offline, a pothential vulnerability is that you have low bandwidth and could be a prey for a DoS attack. A paper is vulnerable to fire. •Risk: Risk is nothing but threat times vulnerability. That means the potential loss/damage of an assest as result of a threat exploitation using vulnerability.
- 11. Tom & Jerry
- 12. Threat
- 13. Vulnerability
- 15. A Suggestion! Before starting Threat Modeling warn development team that “ Do Not Hide Sensitive information from Doctors, Lawyers and SECURITY ENGINEERS”
- 16. Cost of Bug Fixing
- 17. Threat Modeling ● Structured approach to Analyze the security of the application ● Allows to understand the entry points to the application and their associated threats. ● Not an approach to review code but helps in code a lot. ● Threat Modeling will be done in design phase of SDLC. ● Threat modeling in SDLC will ensure the security builtin from the very beginning of the application development.
- 18. Who can perform & involve a Threat Model • Developer • Tester/QA • Architect • Security Engineer
- 19. Threat Modeling High Level Overview Kick-off •Have a kick-off and get product overview •Get the TLDS and PRDS •Identify the assets Identify Use cases •Draw level-0 diagram & analyze (STRIDE) •Document the findings •Have a meeting with dev team to discuss findings •Identify uses cases for level-1 Level-1 •Draw level-1 diagram & analyze (STRIDE) •Document the findings •Have a meeting with dev team to discuss findings •Repeat the above procedure depending upon the project complexity
- 20. Threat Modeling High Level Overview ASF • Prepare the checklist and send it to the dev team • Analyze the document • Document the findings Report • Prepare the final report • Submit it to the product team • Explain the findings to the product team • Provide the mitigations to the threats
- 21. Different Ways to perform Threat Modeling • Attack Centric • Software Centric • Asset Centric • Worst Case Analysis • Negation Analysis • Defensive • Offensive • Threat Traceability Matrix
- 22. Attack Oriented Analysis This approach requires profiling of an attacker’s characteristics Attacker Dedication Stealth Time Knowledge Access Rank Script Kiddie Medium Medium Weeks to Months Medium No access 4 External hacker Medium High Days to weeks High No access 3 Inside hacker Medium Medium Days to week Medium Indirect access 2 Organized cyber criminal High High Weeks to months High Direct 1
- 23. Software Centric Spoofing • Property Authentication • Impersonating something or someone else Tampering • Integrity • Modifying data or code Repudiation • Non- Repudiation • Claiming to have not performed an action Information Disclosure • Confidentiality • Exposing info to unauthorized Denial of Service • Availability • Deny or degrade service to users Elevation of Privilege • Authorization • Gain capabilities without proper authorization
- 24. Asset Centric Asset-centric threat modeling involves starting from assests entrusted to a system, such as a collection of sensitive personal information. Two ways to perform Asset-centric analysis • Worst case scenario analysis • Negation Analysis
- 25. Worst case scenario analysis
- 26. Worst case scenario analysis Credit card details exploited Credit card details sent over non secure channel http communication to App server Communication to database server in clear text database Credit card details stored in clear text SQL injection Input validation not done Parameterized prepared statement not used
- 27. Negation Analysis Example 1: Credit card details should not be exposed Negation Statement: Credit card details should be exposed Example 2: Application should be available all the time Negation statement: Application should not be available all the time.
- 28. Defense Oriented Analysis ➢ Authentication ➢ Authorization ➢ Cookie Management ➢ Data/Input Validation ➢ Error Handling/Information Leakage ➢ Logging/Auditing ➢ Cryptography ➢ Session Management
- 29. Defense Oriented Analysis: Example Some Cryptography Cheatsheet questions: S.No Defense Mechanism Response Comments 1 Is sensitive data at rest encrypted? Yes/No 2 Is the algorithm used to encrypt data meet the compliance requirement Yes/No 3 Is the key size of min 128 bits? Yes/No 4 Are keys properly managed Yes/No 5 Is data in transit over SSL Yes/No
- 30. Offensive Threat Modeling : 5P’s Identify Assets Decompose Assets Asset Posture Compromise Asset Monitor and Update Identify Objectives
- 31. Threat Traceability Matrix Who Where What How Impact Mitigation Threat Attack Surface Conceptual Goals
- 32. Threat Traceability Matrix: Example Who Where What How Impact Mitigation External Attacker Database Steal credit card information SQL Injections Loss of trust for the organization Parameterized prepared statement, input validation
- 33. Three Stages of Threat Modeling The threat modeling process can be decomposed into 3 high level steps: ➔ Decompose the Application ➔ Determine and rank threats ➔ Determine countermeasures and mitigation
- 34. Decompose the Application Threat Model Information Data Flow Diagrams Assets External Dependencies Entry Points Trust Levels
- 36. Determine and Rank Threats (STRIDE) Spoofing • Property Authentication • Impersonating something or someone else Tampering • Integrity • Modifying data or code Repudiation • Non- Repudiation • Claiming to have not performed an action Information Disclosure • Confidentiality • Exposing info to unauthorized Denial of Service • Availability • Deny or degrade service to users Elevation of Privilege • Authorization • Gain capabilities without proper authorization
- 37. Trust Levels
- 38. Microsoft SDL Threat Modeling Tool
- 39. Sample Problem
- 40. Student Results Portal You need to perform threat analysis on a student portals web application. You have three users Administrator, Teacher and Student. The users should login to the application and perform their respective tasks as follows: Administrator is the user who will maintains the application and does not perform any other actions. Teacher can view, enter and modify the student marks A Student can give his register number and view the marks Perform Threat modeling on the application by making an initial assumption that non of the security controls exist in the application.
- 41. Use Cases Entire Architecture Administration Use Case Authentication Use Case Registration Use Case Entering Marks Use Case Displaying Marks Use Case etc.
- 42. Sample Use case (Displaying Marks)
- 43. Analyzing The use case
- 44. Analyzing The use case
- 45. Analyzing The use case
- 46. Analyzing The use case
- 47. Analyzing The use case
- 48. STRIDE Matrix Spoofing Tampering Repudiation Info Disclosure Denial of Service Elevation of Privilege 2.teacher ✓ ✓ 3.student ✓ ✓ 4.firewall ✓ ✓ ✓ ✓ ✓ ✓ 5.App Server ✓ ✓ ✓ ✓ ✓ ✓ 6.Http req ✓ ✓ ✓ 7. Http req ✓ ✓ ✓ 8.response ✓ ✓ 9.JDBC req ✓ ✓ ✓ 10. respon ✓ ✓ ✓ 11.http req ✓ ✓ ✓ 12.res ✓ ✓ ✓ 13.res ✓ ✓ ✓ 14.Database ✓ ✓ ✓
- 49. Threat Analysis
- 50. Scoring: DREAD DREAD is a risk ranking model D Damage Potential R Reproducibility E Exploitability A Affected users D Discoverability
- 51. Mitigation STRIDE Threat & Mitigation Techniques List Threat Type Mitigation Techniques Spoofing Identity 1.Appropriate authentication 2.Protect secret data Tampering with data 1.Appropriate authorization 2.Hashes 3.MACs 4.Digital signatures 5.Tamper resistant protocols Repudiation 1.Digital signatures 2.Timestamps 3.Audit trails Information Disclosure 1.Authorization 2.Privacy-enhanced protocols 3.Encryption 4.Protect secrets 5.Don't store secrets Denial of Service 1.Appropriate authentication 2.Appropriate authorization 3.Filtering 4.Throttling 5.Quality of service Elevation of privilege 1.Run with least privilege
- 52. Threat Modeling in Agile Development
- 53. Threat Modeling in Agile Development In different project stage in Agile Development you need to perform different actions: • Project Inception • Requirements Planning • Sprint Planning • Sprint • Final Release Planning
- 55. Mobile Threat Model •Improper session handling •Social Engineering •Malicious QR Codes •Untrusted NFC Tag or peers •Malicious application •Weak Authorization Spoofing • Modifying local data • Carrier Network Breach • Insecure Wi-Fi Network Tampering • Missing Device • Toll Fraud • Malware • Client Side Injection Repudiation • Malware • Lost Device • Reverse Engineering • Backend Breach Information Disclosure •Crashing Apps •Push Notification Flooding •Excessive API usage •DDoS Denial of Service • Sandbox escape • Flawed Authentication • Weak Authorization • Compromised credentials •Make Unauthorized purchases •Push Apps Remotely • Compromised Device •Rooted/JailBroken •RootKitsElevation of Privilege
- 56. LAB • Assume a shopping application which has minimum web server, application server, database, LDAP, payment service. • Create High Level architecture diagram(Level-0) • Identify use cases for the application • Perform STRIDE on couple of use cases(Level-1) using Microsoft threat modeling tool.
- 57. Conclusion Implement Threat Modeling in SDLC Cuts down the cost Makes analysis simple Mix and Match different types of Threat Models
- 60. THANK YOU
Editor's Notes
- What is the use of threat modeling? The main aim of the threat modeling is to identify the import assets or functionalities of the application and to protect it. The output of the threat modeling is the threat and its associated vulnerabilities for each component in the application You can identify the security issues which you can identify by PT. Example ip addresses Microsoft SDL threat modeling tool
- What is your guess about the circled one?
- Vehicles for Mining. Human for scale
- Microsoft SDL threat modeling tool is just to perform threat model like the tool in the picture
- http://resources.infosecinstitute.com/intro-secure-software-development-life-cycle/
- An asset requires: limited accessibility and generates value• Assets can be intangible Tell me general assets that you feel like assets in real life.
- There are three important terms in Security : Threat, Vulnerability and Risk Well threat is nothing but anything but any damage/harm that could be done on an asset by an attacker Example: For banking application it is data, for cricinfo it is functionalities Anything (e.g., object, substance, human) that is capable of acting against an asset in a manner that can result in harm
- And the next one is the vulnerability, which is nothing but weakness in the system which will aid the attacker in successful execution/exploitation of the threat. Example: Suppose you have a web server with low bandwidth connection. Where the threat is that your server could be taken offline, a pothential vulnerability is that you have low bandwidth and could be a prey for a DoS attack. A paper is vulnerable to fire. There is another term called Risk. Risk is nothing but threat times vulnerability. That means the potential loss/damage of an assest as result of a threat exploitation using vulnerability. Vulnerability (n) - A weakness in the design, implementation, operation, or internal controls in a process or artifact that could be exploited to violate system security or otehrwise cause a negative impact. Vulnerability is some flaw in our environment that a malicious attacker could use to cause damage in your organization. Vulnerabilities could exist in numerous areas in our environments, including our system design, business operations, installed softwares, and network configurations. In software terms, a bug is commonly referred to as a defect, resulting from an err that causes the system to violate its specification. So, in software terms, a vulnerability is a software bug that causes the system to violate its specified or implicit security policy
- Jerry-> Application/Developer Tom Attacker
- Application vulnerable to Cheese
- As a security engineer you need to identify What do you want to protect? Who do you want to protect it from? How likely is it that you will need to protect it? How bad are the consequences if you fail? How much trouble are you willing to go through in order to try to prevent those?
- You may ask we a question, Why do we need Threat modeling? Threat modeling is a structured approach which is used to analyze the security of the application If you need to perform SCA on a project and you do not have enough time. Through the results of the threat modeling instead of reviewing all source code with with equal focus, you can prioritize the components whose threat modeling has ranked with high risk threats. Which will save lot of time. There something called SSDLC, So the inclusion of Threat modeling in SDLC will ensure the security builtin from the very beginning of the application development. Microsoft The inclusion of threat modeling in the SDLC can help to ensure that applications are being developed with security built-in from the very beginning. This, combined with the documentation produced as part of the threat modeling process, can give the reviewer a greater understanding of the system. This allows the reviewer to see where the entry points to the application are and the associated threats with each entry point.
- Approaches to threat modeling Let’s look at a scenario to better understand when a threat model is complete. Consider a Level 1 diagram that includes a number of services and interactions that enable multiple user stories. Now let’s say that those stories will be implemented over a number of iterations or sprints. Do you need to complete the entire threat model at the end of the iteration? Certainly not.
- Attacker-centric threat modeling starts with an attacker where he will list down his goals, and how they might achieve them. Attacker's motivations are often considered, for example, the attacker wants to access the user account, then he will try for XSS/phishing not the DOS attack. it helps at the time of decision making that a particular risk is worth mitigating or not. It is possible that dedication of attacker is less and he might not try further after a couple of attempts and current defense mechanism is sufficient to withstand those attacks. An attacker-centric approach to threat modeling requires profiling an attacker’s characteristics, skill-set, and motivation to exploit vulnerabilities, and then using those profiles to understand the type of attacker who would be most likely to execute specific types of exploits, and implement a mitigation strategy accordingly. The attacker-centric approach also uses tree diagrams. Key elements of this approach include focusing on the specific goals of an attacker, the various considerations related to the system upon which the attack could be perpetrated, along with its software and assets, how the attack could be carried http://myappsecurity.com/approaches-to-threat-modeling/
- Software-centric threat modeling starts from the design of the system, and attempts to step through a model of the system, looking for types of attacks against each element of the model. This approach is used in threat modeling in Microsoft's Security Development Lifecycle. STRIDE is Software-centric approach
- Asset-centric threat modeling involves starting from assets entrusted to a system, such as a collection of sensitive personal information.
- first we list the assets write the worst case scenarios possible for those assets Initially we don’t know if the worst case scenario for each asset will be realized or not. To realize that there could be many preconditions. attacker have to achieve one, some or all of the preconditions So there could be a tree like structure in which the nodes will represent all the steps The tree is called attack tree
- Where hacking could be done? Data at rest and data in transit Explain about the And condition
- Get all the statements of the use cases Modify the use case statement Make the use case statement to negative Credit card details should be exposed : check for data at rest and data in transit vulnerabilities Application should not be available all the time: Try for DoS attacks, account lockout functionality
- Authentication: Ensure all internal and external connections (user and entity) go through an appropriate and adequate form of authentication. Authorization: Ensure that there are authorization mechanisms in place. Authorizing End Users Authorizing the Application in the Database Restricting the Access of application to System-Level Resources Identify the PAP, PDP, PEP points in High Level Architecture diagram Cookie Management: Ensure entire cookie is encrypted if sensitive data is persisted in the cookie. Data/Input Validation: Ensure that a DV mechanism is present. Error Handling/Information leakage: Ensure that all method/function calls that return a value have proper error handling and return value checking. Logging/Auditing: Ensure that no sensitive information is logged in the event of an error. Cryptography: Ensure no sensitive data is transmitted in the clear, internally or externally. Secure Code Environment: Examine the file structure. Are any components that should not be directly accessible available to the user? Session Management: Examine how and when a session is created for a user, unauthenticated and authenticated.
- Threat Model Information understading of the application Application Name -Application Version - Description -Document Owner - Participants - Reviewer External dependencies are items external to the code of the application that may pose a threat to the application. Example reports is a third party application This involves creating use-cases to understand how the application is used, Entry points are the interfaces through which potential attackers can interact with the application or supply it with data. Trust levels represent the access rights that the application will grant to external entities. The trust levels are cross referenced with the entry points and assets
- Why to use DFD’s The DFDs will allow us to gain a better understanding of the application by providing a visual representation of how the application process the data. The external entity shape is used to represent any entity outside the application that interacts with the application via an entry point people other systems The process shape represents a task that handles data within the application. Services, Web services, EXEs etc. Data Flow Function call, Network traffic, RPCs Data Store Database, File, Registry, shared memory, queue/stack The privilege boundary shape is used to represent the change of privilege levels as the data flows through the application. These Privilege boundaries are attack surface to the attackers.
- After decomposing the application you need to apply STRIDE to identify the threats. You need to analyze whether the particular component is going to get affected by the STRIDE or not. A threat exists as there is a weakness in security control In the era of cloud, there are lot of integrations through this TM we can identify the vulnerabilities very effectively. Give example network sniffing There are two ways two determine the threats. One is through STRIDE and another is through Application Security Frame (ASF). The goal of the threat categorization is to help identify threats both from the attacker (STRIDE) and the defensive perspective (ASF). There is one tree for each threat goal. From the defensive perspective, ASF categorization helps to identify the threats as weaknesses of security controls for such threats
- Rate each of these on a scale of 10 and find the average of all 5.
- https://technet.microsoft.com/en-us/security/hh855044.aspx The key to effectively incorporating threat modeling is to decide on the scope of the threat modeling that you will perform during the various stages of your agile development project. Threat modeling solely the functionality that you plan to release in the first iteration might not reveal enough of the system design to identify threats or allow sufficient time to address them. On the other hand, if you create complete threat models for how the entire application is envisioned, that would obviously be too expensive a single agile iteration. So what’s the best approach? I recommend a strategy in which you create the context and Levels 0, 1, and 2 diagrams during the early inception and requirements phases of the project. Additionally, any other diagrams in which sufficient detail is known about the likely application architecture or high-level design should be included during this phase. It’s not important during this stage to identify every threat and mitigation for each diagram, though the more you can, the better. The point here is that it’s better to diagram what you do know at this stage, versus waiting for the entire design to be completed. The following list categorizes the suggested threat modeling activities based on project stage: Project Inception - Create context and Level 0 and Level 1 diagrams. Requirements Planning - Identify the threats and mitigations that you expect to have greatest impact on the overall system design and architecture. Sprint Planning - Identify where new threat models are required and where current threat models need to be updated or completed. Sprint Execution - Develop, update, and complete threat models according to tasks assigned during sprint planning. Final Release Planning - Ensure that all threat models are complete and included in the project archive.
- DFDs can be used in next release. If there are small modifications then those can be easily added and analysed.