On Security Development Lifecycle: Conceptual Description of
Vulnerabilities, Risks, and Threats
Sabah Al-Fedaghi
1and Abdulrahman Alkandari
2Kuwait University, [email protected]
Kuwait University, [email protected]
doi:10.4156/jdcta.vol5.issue5.32
Abstract
Security Development Lifecycle (SDL) is a software assurance methodology that aims at assisting software developers in improving the security of software production. Typically SDL is described in terms of phases that include requirements and design phases. The Requirements phase embraces consideration of security and privacy at a foundational level. This consideration comprises several activities in security requirements, security risk assessment, and threat modeling. The problem is that basic notions at this level are categorized and conceptualized as arbitrary collections of assets, operations, techniques, etc. with no systematic connection between them. This paper is part of an effort that aims at building a uniform foundation for notions in SDL. It focuses on requirements phase analysis, where we analyze conceptual aspects that involve the notions of threats, risks, and vulnerabilities. We work on two aspects:
1. The notions of threats, risks, and vulnerabilities are conceptualized utilizing a new approach based on the notion of flow.
2. The flow-based methodology is presented as an alternative description to using data flow diagrams as a first step in modeling threats.
In both cases the analysis is performed utilizing sample cases.
Keywords
: Security Development Lifecycle, Threats, Risks, Vulnerabilities, Conceptual Model1. Introduction
Developing secure software is a challenging task as sophisticated security threats continue to accumulate. Secure software is a key component for individuals, businesses, and government and affects critical applications and infrastructure. According to the USA President’s Information Technology Advisory Committee (PITAC) [1],
Today, as with cancer, vulnerable software can be invaded and modified to cause damage to previously healthy software, and infected software can replicate itself and be carried across networks to cause damage in other systems. Like cancer, these damaging processes may be invisible to the lay person even though experts recognize that their threat is growing. And as in cancer, both preventive actions and research are critical, the former to minimize damage today and the latter to establish a foundation of knowledge and capabilities that will assist the cyber security professionals of tomorrow reduce risk and minimize damage for the long term.
Security Development Lifecycle (SDL), which focuses on producing secure software, is a software assurance methodology and tool that aims at assisting software developers, designers, builders, and educators in improving the security of software production. SDL prescribes activities to embed security into applications and supplies the foundation for a broad software security assurance that extends across an IT enterprise [2, 3].
In this paper, without loss of generality, we concentrate on one of the leading SDL processes developed by Microsoft.
Combining a holistic and practical approach, the SDL introduces security and privacy early and throughout all phases of the development process. It has led Microsoft to measurable and
widely recognized security improvements in flagship products, such as Windows Vista and Microsoft SQL Server. [4]
The SDL involved is a software development process used by Microsoft to increase reliability of software security. It is divided into several phases that include requirements and design. The Requirements phase comprises several activities in security requirements, security risk assessment, and threat modeling. This paper focuses on this level of analysis, conceptualizing risks, vulnerabilities, and threats.
2. Problem and solution
This paper focuses on the requirements level of SDL. The general goal of the research is to build a uniform and systematic foundation for notions in the security development lifecycle. Specifically, we study the notions of risk, threat, and vulnerability at this level. We conceptualize them in terms of a flow of artifacts we call flowthings. “Flowthings” refer to “software development things,” including concepts and tangible products that are generated and exchanged during each phase of software development. Flowthings are received, processed, created, released, and communicated. They are the units that flow between phases in a flowthing model (FM).
Microsoft’s paper [4] shows that vulnerabilities are categorized as arbitrary collections of assets, operations, techniques, etc. with no systematic connection between them. In contrast, FM-based description presents functional categorization that can be used to group and analyze lower-level vulnerabilities. Risk as a feature caused by vulnerability and environment can also be conceptualized this way. We propose to categorize risks as received risk, processed risk, created risk, released risk, and transferred risk. Also, the same flow-based description can be applied to threats. Instead of threat modeling using traditional data-flow diagrams that mix all types of flows, we show that FM presents a more complete conceptual picture that can be used for identifying different paths through the system and for highlighting privilege boundaries.
In section 3 we review the requirements and design phases in SDL. The purpose is to approach from the top down to reach the focal point where the notions of risk, threat, and vulnerability are the development artifacts. In section 4, some motivational examples of risks and threats are presented to show that new approaches can contribute to advancing this area of research. Section 5 includes a review with new contribution of a model that will be used in analyzing aspects of these notions. The main results that model vulnerability, risks, and threats are given in section 6.
3. Phases of SDL
The current state-of-the-art for security software development can be represented by the Microsoft Security Development Lifecycle, which includes methodologies used for building software applications and online services in environments where there is security risk:
The SDL introduces security and privacy throughout all phases of the development process. . . Integration of secure development concepts into an existing development process can be intimidating and costly if done improperly. . . . The impact of these intangibles can be controlled by understanding the elements of good security development practices and establishing implementation priorities based on the maturity level of the development team. Microsoft has created the SDL Optimization Model to help address these issues. [4]
Microsoft SDL includes five phases: Training, policy, and organizational capabilities, Requirements and design, Implementation, Verification, and Release and response. It includes mandatory security activities executed as part of a software development process.
The Requirements phase of the SDL includes consideration of security and privacy at a foundational level. The best opportunity to build trusted software is during the initial planning
stages, when development teams can identify key objects and integrate security and privacy [4]. The Design phase includes building the plan for implementation, release, and functional and design specifications, and performing risk analysis to identify threats and vulnerabilities.
Functional specifications may describe security and privacy features directly exposed to users, such as requiring user authentication to access specific data or user consent before use of a high-risk privacy feature. Design specifications describe how to implement these features and how to implement all functionality as secure features [4].
In general, if a software development project is determined to be subject to the SDL, it must complete security activities to comply with the Microsoft SDL process. These activities include Security requirements, Quality gates/bug bars, Security and privacy risk assessment, Design requirements, Attack surface reduction, Threat modeling, Dynamic program analysis, Fuzz testing, and Threat model and attack surface review. According to Microsoft [4],
The need to consider security and privacy “up front” is a fundamental aspect of secure system development. This early definition of requirements allows development teams to identify key milestones and deliverables and permits the integration of security and privacy in a way that minimizes any disruption to plans and schedules. The Requirements phase deals with ways to integrate security and privacy into the development process and identify security objectives. The Design phase is concerned with identifying the overall requirements and structure of the software and establishes design practices. A fundamental principle of SDL is to consider security in the initial planning stages of software development.
Other methodologies are similar to Microsoft SDL in neglecting the fundamental notions in this area. In this paper we analyze conceptual aspects of the requirements phase of SDL that involve the notions of threats, risks, and vulnerabilities. Thus, we work on two aspects:
1. The notions of threats, risks, and vulnerabilities are conceptualized utilizing a new approach based on the notion of flow.
2. The flow-based methodology is presented as an alternative to using data flow diagrams as a first step in modeling threats.
4. Motivation: clarifying basic SDL concepts
Microsoft has been using threat modeling to find security design flaws during development. Threat modeling examines a system from the attacker’s perspective and is based on the assumption that an attack comes during interaction with the system [5, 6]. According to Microsoft [4], “threat modeling is a systematic process that is used to identify threats and vulnerabilities in software.” Still, such a clarification that partially describes threats in terms of threats needs a more precise account in the context of SDL.
Bejtlich [7] states that
What Microsoft calls "threat modeling" is actually a form of risk analysis…The five components used to judge a threat: existence, capability, history, intentions, and targeting. That is how one models threats. It has nothing to do with the specifics of the attack. That is attack modeling. Attack modeling concentrates on the nature of an attack, not the threats conducting them. Attack trees are a way to perform attack modeling. Attack modeling can be done separate from threat modeling, meaning one can develop an attack tree that any sufficient threat could execute.
A prerequisite in the analysis of threats is an understanding of the generic definition of risk, which is the probability that a threat agent will exploit a vulnerability to cause an impact on the application. This goes along with the familiar definition of risk as the likelihood of undergoing damage or loss. It is usually expressed as a function of threat and vulnerability, that is,
Accordingly, we understand that a threat is an event that might damage or compromise a system, and that attacks are actions that manifest threats.
In the rest of this paper we approach these notions from a new angle: in the context of a flow model, presented in the next section. In addition to clarifying the basic concepts at this level of SDL, we show that applying the flow model has advantages for conceptualization systems for such purposes as identifying security boundaries.
5. Flowthing model
The flowthing model (FM) was first introduced by Al-Fedaghi [8] and has been used since then in several applications such as software requirements, communication, and business processes [9, 10, 11, 12]. This section provides a review of the basic model as it has been described in other publications, and it introduces new aspects of the model.
A flow model is a uniform method for representing things that “flow,” i.e., things that are exchanged, processed, created, transferred, and communicated. “Things that flow” include information, materials (e.g., manufacturing), and money.
To simplify this review of FM, we introduce a method of describing attack flow. “Attack” here refers to the means of an assault such as bullets, computer virus, or directed violent action. There are five states of attack: transferred, received, processed, created, and released, as illustrated in Figure 1, where the flowthing is an attack. The word “state” is used here in the sense of properties or conditions; for example, states/phases of water in physics: liquid, ice, and gas. If molecular water is in one state, it cannot be in the other states.
The model can also be defined in terms of a transition graph with six states, as shown in the figure; however, for the sake of brevity, we will merge Arrived and Accepted states into one state called Received. That is, we will assume that everything that arrives is accepted. In this case the stages are called receiving, processing, creation, releasing, and transferring stages.
Consider an attack as a computer virus.
1. Creation stage: The virus has been created by a hacker. It is certainly not a released virus (yet), or being transferred to targets. It has not been received by anyone, or processed (e.g., analyzed). It stays in its created state until it is released.
2. Released stage: The released virus may stay in its released state for a while, because, say, the transfer channel is down. This situation is analogous to a factory that manufactures goods, then releases them to be exported; however, the goods stay in their released state, waiting to be transported on a certain date to their destination. Certainly, the goods leave the created state and occupy the released state. The created state has become a past state, and the released state becomes the current state. It is possible that later it will be decided to cancel the shipment, e.g., the ship is not coming (or, in case of a
Processed
flowthing, flowthing Received
Figure 1. State transition diagram for FM.
Released flowthing Created flowthing Transferre d flowthing Arrived flowthing Arriving flowthings may be rejected Created flowthings that flow to the released stage may
“return” to the creation stage if they cannot be transferred
Created flowthings can flow to the process stage, but not vice versa.
virus, the hacker changes his/her mind about where to send the virus), hence, the goods move back to the created state for later release to another customer.
3. Transfer stage: In this case, the released virus is put in the communication channel. This is analogous to passengers in an airport being released after passport processing and waiting to board actually getting on the airplane.
4. Receiving stage: In this case the virus arrives at the target site. It may be stored in its original form, deleted immediately; however, it is in its originally received state.
5. Processing stage: In this case the received virus is processed (changes its form), as in the case of being activated or re-engineered.
Viruses can be stored, copied, destroyed, used, etc. in any of the five generic states; however, those being stored, copied, destroyed, etc. are not in a generic state. A created virus can be stored, a released virus can be stored, a received virus can be stored, and so forth. A flow structure with its five stages is called a flowsystem. In this flow model, flows are denoted by solid arrows; additionally, flows can trigger other types of flow, denoted by dashed arrows.
The environment in which a virus exists is called its sphere (e.g., a computer). Consider three spheres that include a hacker system and two computer systems, as shown in Figure 2. The hacker creates a virus that is released and transferred to computer 1. Processing the virus in computer 1 results in duplicating it and transferring to computer 2. In this example we have three spheres: hacker, computer 1, and computer 2, each with a virus flowsystem.
Figure 3 illustrates the triggering mechanism. Assuming SQL injection attack, the hacker creates SQL statements that are transferred to a computer SQL flowsystem, and that triggers passwords to the hacker in the password flowsystem. In this case, there are two spheres: the hacker system, and the computer system. Each sphere has two flowsystems: an SQL statements flowsystem, and a passwords flowsystem.
Figure 2. Virus flow from a hacker system to two computers. Receive Processed Transfer Receive Released Processed Created Release Transfer Hacker Computer 1 Computer 2 Transfe r Virus Virus Virus Receive Transfer Receive Transfer
Created Release Transfer
Hacker Computer SQL SQL Release Transfer Passwords Passwords File
Figure 3. SQL injection triggers flow of passwords to the hacker. Processed
Identifying flowthings in the conceptualized system is a fundamental first step in FM. Flowthings are things that can be received, processed, created, released, or transferred. A conceptualization of a stream of flowthings may not necessarily contain all stages. For example, conceptualization of a physical airport can model the flow of passengers: arriving (received), processed (e.g., language and passports), released (waiting for boarding), and transferred (to planes); however, airports do not create passengers. In this case, the schema includes only the stages received, processed, released, and transferred.
6. Vulnerabilities, risks, and threats
In this section we apply FM to the notion of vulnerability, risks, and threats. The implication is that FM represents a uniform method for conceptualizing some aspects of these notions.
6.1. Vulnerability
Typically, threats are prioritized according to damage and likelihood [13]:
Rate each vulnerability on a scale of one to ten based on the amount of damage a successful exploit might cause (financial damage, reputation damage, or even physical damage to persons or property). Calculate a second rating on the likelihood of someone being able to pull off the attack. To prioritize, calculate the overall risk factor for each vulnerability: Risk = Damage * Likelihood. Sort your vulnerabilities into a list of decreasing risk, and address the highest risk items first. This is a highly subjective analysis. [Italics added]
There are several ways to categorize vulnerability [14]. For example, security vulnerability can be broadly categorized into the classic security dimensions: confidentiality, integrity, and availability. At a lower level of description, one of Microsoft’s categorizations of vulnerability is as follows [15]: Input and Data Validation, Authentication, Authorization, Configuration Management (e.g., Who does your application run as? Which databases does it connect to? How is your application administered? How are these settings secured?), Sensitive Data, Session Management (e.g., How does your application handle and protect user sessions?), Cryptography, Parameter Manipulation (e.g., Form fields, query string arguments, and cookie values are frequently used as parameters for an application.), Exception Management, and Auditing and Logging
These seem to be arbitrary collections of assets, operations, techniques, etc. with no systematic connection between them. For example, there is no explicit mention of the risk of releasing information, or of creating new “things” (e.g., duplicating viruses). In terms of FM, these vulnerabilities can be categorized as shown in Figure 4. This FM-based description presents functional categorization that can be used to group and analyze lower-level vulnerabilities. Receive Create Release Transfer Vulnerabilities of receiving, e.g., Input
and Data Validation, authentication Vulnerabilities of processing, e.g.,
Authorization, Configuration Management
Vulnerabilities of storage e.g., sensitive data, Cryptography Vulnerabilities of creation, e.g., system files
Vulnerabilities of transferring Vulnerabilities of Releasing
Process
6.2. Risks
In FM, risk as a feature caused by vulnerability and environment can be conceptualized as a flowthing that can be accepted, processed, created, released, and transferred. Vulnerability is a feature of a system analogous to human susceptibility to events (e.g., diseases), and this susceptibility is aggravated by certain characteristics (e.g., birth defect). Also, for a human being, a risk is a function of this susceptibility and of location in an environment that exploits this susceptibility. This understanding of risk and its relationship to threat and attack is illustrated in Figure 5.
We can categorize risks according to FM stages as follows.
Received risk: This risk is a threat imported from outside the system (e.g., acceptance of insecure software). For example, according to Brown [13], “Some risks are so low and so costly to mitigate that they may be worth accepting.” Acceptance of received risk means acceptance of risk because of importing some risky thing from outside the system. Brown [13] gives the following example of “acceptable” risk: “accepting the threat of a nuclear strike that destroys two data centres in two different locations simultaneously might just be the cost of doing business.” This is not received risk but created risk, because the existence of two data centers in two different locations is a feature of the system inherent in its construction, thus, the risk is created internally.
Created risk: This means having a system susceptible or vulnerable to threats. We note that threats exploit vulnerabilities. For example, when vulnerability is described as “a design flaw or mis-configuration which makes your network (or a host on your network) susceptible to malicious attacks from local or remote users” [16], the risk generated by such vulnerability is created risk.
Processed risk: This means that the system changes the form of risks or processes risks (created or received risks) to produce new risks.
Released risk: This means possible exporting of a risk to another system (e.g., potential for AIDS in a baby by pregnant mother).
Transferred risk: This means transferring the risk to another system. Brown [13] considers transfer of risk as delegating responsibility.
In the same context, Brown [13] describes “transfer of risk” as follows.
Transfer of risk can be accomplished many ways. Insurance is one example; warnings are another. Software programs often transfer risk to the users via warnings. For example, try enabling Basic Authentication in IIS and you'll be warned that passwords will be sent in the clear unless you also enable SSL. System Vulnerabilities Environment (e.g., exploiters, their skills, etc.) Threat System Environment (e.g., exploiters, their skills, etc.) Attack
Created risk: Risk is born with the birth of a system with vulnerability.
Figure 5. Risk is the possibility of moving from the upper (dark) state to the lower one.
Patch
Received risk: Risk is imported from the environment.
Processed risk: Risk is changing form or created as a result of internal operation in the system
Another system
Released/ transferred risk: Risk is transported to another system.
But this mixes risk with consequence. When we buy car insurance we don’t transfer the risk of crash or injury to the insurance company. In addition, when a system warns of a risk, this does not transfer the risk from the system to the user. Transfer of risk means “spreading” risk susceptibility to a new system, e.g., transferring a virus.
6.3. Threats
Threat modeling uses traditional data flow diagrams (DFDs). One large project at Microsoft comprises more than 1,400 completed and reviewed threat modeling DFDs [5, 6]. Microsoft and the EU-funded CORAS Project [17] have introduced a threat modeling tool [18, 19], support for threat models using UML. These tools build on previous work in attack graphs [20] and security requirements [21]. UMLsec [22] expands UML to security requirements and to checking for security aspects at the design level.
Typically, the initial stage of the threat modeling process involves producing data flow diagrams for the application. “The DFDs show the different paths through the system, highlighting the privilege boundaries… DFDs … help to identify the potential threat targets from the attacker's perspective, such as data sources, processes, data flows, and interactions with users” [23]. Symbols used in DFDs for threat modeling include External Entity (rectangles), process (circle), multiple process (double circumference circle), Data Store (upper and lower edges box), Data Flow (arrows), and Privilege Boundary (dotted line).
Figure 6 shows an example of a DFD for the college library Web site given in OWASP [23]. We observe that for the threat modeling process, FM presents a more complete conceptual picture that can be used for “the different paths through the system, highlighting the privilege boundaries,” whereas Figure 6 mixes all types of flows and represents them as arrows.
Viewing these embedded flows from an FM perspective, we can identify the following:
Flow of “requests for pages” and pages: Figure 7 shows the stream of this flow. Requests for Web pages flow from users or librarians to the college library Web site. Thus, we have four flowsystems: two request flowsystems, and two page flowsystems. Different flowsystems should not be mixed, analogous to separately specifying the flows of water, gas, and electricity in a building design. The effect of this principle on security consideration is obvious. Also note the completeness and continuity of the flow in the FM representation. The stream of flow is drawn from its origin to its end. The user or librarian creates a request for a Web page (circle 1), then the request is released and transferred to the college library Web site (circle 2). It is processed (circle 3), triggering retrieval of the page from Web pages disc (circle 4), then transferred (circle 5) and received by the user or librarian. We have opted in
Users Requests Librarians Requests Responses Responses
User/web server boundary
SQL query call Pages We pages on disc Database files Data Data Data College library database College library Website
Web server/database boundary
Figure 7 to consider users and librarians as one type of sphere because they have an identical stream of flow; however, it is possible to model their flows separately.
Figure 7. Flows of requests and pages.
In these diagrams it is not difficult to draw “security boundaries” over the topological map of spheres and flowsystem. Additionally, it is possible to draw these boundaries according to streams of flow (e.g., streams 1, 2, and 3; 4, 5, and 6; or the triggering stream between 3 and 4, in Figure 7).
Flow of request for data and data: DFD representation does not distinguish requests for Web pages from requests for data in the database. These are two completely different types or forms of documents (think of a manual system). In some countries, there are two types of flows of water: clean water, and processed water used for cleaning, gardening, etc. Conceptually, even though both are water, their flows are separated into different pipes. Similarly, requests for Web page flow are a separate process from requests for data from the database. This may affect security considerations such as sensitivity of the requested asset.
Figure 8 shows the FM description of this type of flow, which has six flowsystems: - two flowsystems for requests from users to Web site
- two flowsystems for requests from Web system to database system. Note that we assume that communication requests between users and Web site are different from requests from Web site to database.
- Three flowsystems of flow of data: from database, to Web site system, to user.
-Figure 8. Flow of requests for data.
7. Conclusion
This paper proposes incorporating a new model based on the concept of flow into modeling of the lifecycle of software development. We work on two aspects:
1. The notions of threats, risks, and vulnerabilities are conceptualized in a new approach based on the notion of flow.
2. The flow-based methodology is presented as an alternative to using data flow diagrams as a first step in modeling threats.
The categorization of vulnerabilities and the flow-based description that is applied to threats, as demonstrated in this paper, promise to provide a conceptual specification for these notions. We view the general goal of the research is building a uniform and systematic foundation for notions in the security development lifecycle. Further work can focus on a possible application of the flow-based approach to other aspects of this area.
8. References
[1] PITAC, “Cyber Security: A Crisis of Prioritization”, The President’s Information Technology Advisory Committee, February 2005.
http://www.nitrd.gov/pitac/reports/20050301_cybersecurity/cybersecurity.pdf
[2] FORTIFY, “Optimizing the Microsoft SDL for Secure Development”, Whitepaper, Fortify Solutions to Strengthen and Streamline a Microsoft Security Development Lifecycle Implementation, 2010.
http://www.fortify.com/servlet/download/public/Optimizing_the_Microsoft_SDL_for_Secure_De velopment.pdf
[3] Hajar Mat Jani, Salama A. Mostafa, "Implementing Case-Based Reasoning Technique to Software Requirements Specifications Quality Analysis", IJACT: International Journal of Advancements in Computing Technology, vol. 3, no. 1, pp. 23-31, 2011.
[4] Microsoft, Version 5.0, “The Microsoft Security Development Lifecycle (SDL)”, 2010. http://msdn.microsoft.com/en-us/security/cc448177.aspx
[5] M. Abi-Antoun, D. Wang, P. Torr, “Checking Threat Modeling Data Flow Diagrams for Implementation Conformance and Security”, ASE’07, Atlanta, Georgia, 5–9 November, pp. 393-396, 2007. http://www.cs.cmu.edu/~mabianto/papers/07_ase.pdf
[6] M. Abi-Antoun, J. M., Barne, “STRIDE-based Security Model in Acme”, Technical Report
CMU-ISR-10-106, Carnegie Mellon Univ., 2010.
http://reports-archive.adm.cs.cmu.edu/anon/isr2010/CMU-ISR-10-106.pdf
[7] Richard Bejtlich, “Threat Model vs. Attack Model”, TaoSecurity: Richard Bejtlich's blog on digital security and the practices of network security monitoring, incident response, and forensics, 12 June 2007. http://taosecurity.blogspot.com/2007/06/threat-model-vs-attack-model.html
[8] Sabah Al-Fedaghi, “Some Aspects of Personal Information Theory”, 7th Annual IEEE Information Assurance Workshop (IEEE-IAW 2006), United States Military Academy, West Point, NY, pp 155 – 162, 2006. http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01652066
[9] Sabah Al-Fedaghi, “States and Conceptualization of Software Systems”, International Review on Computers and Software (IRECOS), Vo. 4, No. 6, pp. 718-727, 2009.
http://www.praiseworthyprize.com/IRECOS_latest.html#States_and_Conceptual_Modeling_of_So ftware_Systems
[10] Sabah Al-Fedaghi, “Conceptualization of Business Processes”, IEEE Asia-Pacific Services Computing Conference (IEEE APSCC 2009), Biopolis, Singapore, pp. 75-79 (hardcopy proceedings), December 2009.
[11] Sabah Al-Fedaghi, F. Al-Azmi, "Evolution of Data into an Information Hierarchy", Journal of Convergence Information Technology (JCIT), vol. 6, no. 2, pp. 9–21, 2011.
http://www.aicit.org/JCIT/ppl/02-FASTJCIT4-965174.pdf
[12] Sabah Al-Fedaghi, "A Conceptual Foundation for Data Loss Prevention", International Journal of Digital Content Technology and its Applications (JDCTA), vol. 5, no. 3, pp. 293–303, 2011.
[13] Keith Brown, “The .NET Developer’s Guide to Windows Security”, Addison-Wesley,
Professional, 2004. http://alt.pluralsight.com/wiki/default.aspx/Keith.GuideBook/HomePage.html [14] Duan Youxiang, Gao Yang, "Evaluating Vulnerabilities Quantitatively Based On the Rank of
Web Services Confidentiality", Journal of Next Generation Information Technology (JNIT), vol. 2, no. 1, pp. 81-87, 2011.
[15] J. D. Meier, A. Mackman, B. Wastell, “Threat Modeling Web Applications”, Microsoft Corporation, May 2005. http://msdn.microsoft.com/en-us/library/ff648006.aspx [16] Qualys, “Severities KnowledgeBase”, 2010.
http://browsercheck.qualys.com/research/rnd/knowledge/severity/ [17] CORAS, http://coras.sourceforge.net, 2006.
[18] Frank Swiderski, Window Snyder, “Threat Modeling (Microsoft Professional)”, Microsoft Press. http://www.agilemodeling.com/artifacts/securityThreatModel.htm.
[19] Frank Swiderski, “Threat Modeling Tool”, Microsoft, June 2004. www.microsoft.com/downloads [20] O. Sheyner, J. Haines, S. Jha, R. Lippmann, J. M. Wing, “Automated Generation and Analysis of
Attack Graphs”, IEEE Symposium on Security and Privacy, pp. 273-284, 2002.
[21] A. Van Lamsweerde, “Elaborating security requirements by construction of intentional anti-models”, International Conference on Software Engineering (ICSE), pp. 148 – 157, 2004.
[22] Jan Jurjens, “Developing Secure Systems with UMLsec – From Business Processes to
Implementation”, In A. Pfitzmann, D. Fox, M. Kohntopp (eds.), Proc. Verl assliche IT-Systeme 2001 — Sicherheit in komplexen IT-Infrastrukturen, Kiel, Germany. Vieweg Verlag, 2001. [23] The Open Web Application Security Project (OWASP ), “Application Threat Modeling”, 4 May
