Threat categorization - Critical to the identification of threats is the use of a threat categorization model, which is highly recommended in order that the threat modeler can approach the threat identification process in a structured and repeatable manner. A threat categorization such as STRIDE can be used or the application security frame that defines threat categories such as Auditing & Logging, Authentication, Authorization, Configuration Management, Data Protection in Storage and Transit, Data Validation, Exception Management. The goal of the threat categorization is to identify root causes for threats and make sure that countermeasures are in place to mitigate such threats. Threats could be mitigated by common countermeasures since threats can belong to more than one category. For example a threat to authentication can also be a threat to data protection in transit if authentication credentials are passed in clear or just encoded between client and server (for example using basic authentication). In this case using a countermeasure such as SSL mitigates both the threat to authentication and data protection. As long as appropriate countermeasures for such threats are available, this does not
present a significant problem. The value of threat identification in support of the threat modeling is to identify gaps in security controls to mitigate such threats. Threats, vulnerabilities and attacks - A general list of common threats, vulnerabilities and attacks represent a baseline for identifying specific threats driven by the use of the threat categorization . Generic checklists can be used for this scope based on common vulnerabilities such as the OWASP Top Ten as well mapping to such vulnerabilities to attacks such as phishing, privacy violations, identity theft, system compromise, data alteration or data destruction, financial loss and reputation loss. Once common threats, vulnerabilities and attacks are assessed, a more focused threat analysis should take in consideration use and abuse cases. By thoroughly analyzing the use scenarios, weaknesses can be identified that could lead to the realization of a threat. Abuse cases should be identified as part of the security requirement engineering activity. These abuse cases can illustrate how existing protective measures could be bypassed, or were a lack of such protection exists.
THE INFORMATION GATHERED ACROSS THE DIFFERENT VIEWS WILL BE USED TO DETERMINE THE DATA FLOW, IDENTIFY TRUST BOUNDARIES, AND ENTRY POINTS.
Identification of countermeasures - Countermeasures are mitigating strategies or components that can help prevent a threat from being realized. A generic list of countermeasures for known vulnerabilities can be used. When applied to the application architecture, countermeasures are in-substance security controls. Options of company approved security controls and technologies can be documented in secure architecture guidelines. Such guidelines promote the use and application of such controls after thorough evaluation that truly meet company technology standards and compliance. For example in case of encryption controls, the organization encryption standards might drive the choice of compliant encryption algorithms and key lengths. The same might apply for regulatory compliance (e.g. FFIEC) for example as a driver for the choice of strong authentication such as multiwww.insecuremag.com
factor authentication in application that needs to handle high risk transactions. Threat prioritization and risk rating - It is important that organizations have risk management processes on how to deal with such threats. For example these threats must be accepted by the business otherwise the design of the application must change to remove the threat entirely (e.g. don't store credit card numbers to remove the threat of disclosure). Through a prioritized list of threats the business can make informed decisions on which threats have to be mitigated first or whether to mitigate them at all. For each threat, a risk model should provide an assessment of the likelihood and impact factors to determine the criticality of the threat and the overall risk or severity level. 98