Architectural Risk - Revision history

User at 22:24, 2 December 2022

2022-12-02T22:24:45Z

User at 15:54, 2 December 2022

2022-12-02T15:54:50Z

User: The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

2021-02-06T13:50:06Z

The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

User at 16:11, 29 May 2020

2020-05-29T16:11:45Z

User: Architecture risk is the potential for an architectural design to fail to satisfy the requirements for a project. This includes capacity limitations, poor quality designs, flaws and inefficiencies that are either rejected by the sponsor or impede project

2018-12-03T20:44:48Z

Architecture risk is the potential for an architectural design to fail to satisfy the requirements for a project. This includes capacity limitations, poor quality designs, flaws and inefficiencies that are either rejected by the sponsor or impede project

User at 20:43, 3 December 2018

2018-12-03T20:43:17Z

User: Architecture risk is the potential for an architectural design to fail to satisfy the requirements for a project. This includes capacity limitations, poor quality designs, flaws and inefficiencies that are either rejected by the sponsor or impede project

2018-12-03T20:42:48Z

User: Created page with "'''Content Coming Soon'''"

2018-12-03T19:57:52Z

Created page with "'''Content Coming Soon'''"

New page

'''Content Coming Soon'''

@@ Line 6: / Line 6: @@
-== Relationship Between Uncertainty and Architectural Risk (See Figure below)<ref>[https://www.cs.ucsb.edu/~sherwood/pubs/MICRO-17-archrisk.pdf Relationship Between Uncertainty and Architectural Risk]</ref><br />
+== Relationship Between Uncertainty and Architectural Risk (See Figure below)<ref>[https://www.cs.ucsb.edu/~sherwood/pubs/MICRO-17-archrisk.pdf Relationship Between Uncertainty and Architectural Risk]</ref> ==
 Architectural risk, intuitively, is the degree to which the performance of a design is fragile in the face of unknowns. In many industrial settings, high-level design decisions are made at the level of spreadsheets and other high-level analytical models or data points drawn from past experience. Most do not consider the uncertainty in the assumptions being made nor the fragility of the decisions with respect to those uncertainties. Uncertainty and risk are commonly used terms in many fields
 including economic and financial analytics.

@@ Line 1: / Line 1: @@
-'''Architectural [[Risk]]''' is defined as independently tracked risk or issue observable in the [[architecture]]. It is typically captured by an Enterprise Architect. This entity may contain links to documentation of the risk, escalations, exceptions, status, events, and quantifiable measures.<ref>Defining Architectural Risk [http://motivationmodel.com/ontology-enterprise-strategy-viewpoint/ EBMM]</ref>
+== What is Architectural Risk ==
-Architecture risk is the potential for an architectural [[design]] to fail to satisfy the requirements for a project. This includes capacity limitations, poor [[quality]] designs, flaws and inefficiencies that are either rejected by the sponsor or impede project work.<ref>What is Architectural Risk? [https://simplicable.com/new/architecture-risk Simplicable]</ref>
+Architecture risk is the potential for an architectural design to fail to satisfy the requirements of a project. This includes capacity limitations, poor quality designs, flaws, and inefficiencies that are either rejected by the sponsor or impede project work.<ref>[https://simplicable.com/new/architecture-risk What Does Architectural Risk Mean?]</ref>
-'''Relationship Between Uncertainty and Architectural Risk (See Figure below)'''<ref>Relationship Between Uncertainty and Architectural Risk [https://www.cs.ucsb.edu/~sherwood/pubs/MICRO-17-archrisk.pdf ucsb.edu]</ref><br />
+== Relationship Between Uncertainty and Architectural Risk (See Figure below)<ref>[https://www.cs.ucsb.edu/~sherwood/pubs/MICRO-17-archrisk.pdf Relationship Between Uncertainty and Architectural Risk]</ref><br />
-Architectural risk, intuitively, is the degree to which the performance of a design is fragile in the face of unknowns. In many industrial settings high level design decisions are made at the level of spreadsheets and other high-level analytical models or [[data]] points drawn from past experience. Most do not consider the uncertainty in the assumptions being made nor the fragility of the decisions with respect to those uncertainties. Uncertainty and risk are commonly used terms in many fields
+Architectural risk, intuitively, is the degree to which the performance of a design is fragile in the face of unknowns. In many industrial settings, high-level design decisions are made at the level of spreadsheets and other high-level analytical models or data points drawn from past experience. Most do not consider the uncertainty in the assumptions being made nor the fragility of the decisions with respect to those uncertainties. Uncertainty and risk are commonly used terms in many fields
-including economic and financial [[analytics]].
+including economic and financial analytics.
 [[File:Architectural Risk.png|500px|Architectural Risk]]<br />
-source: [https://www.cs.ucsb.edu/~sherwood/pubs/MICRO-17-archrisk.pdf UC Santa Barbara]
+source: UC Santa Barbara
-'''Architectural [[Risk Analysis]]'''<ref>Architectural Risk Analysis [https://www.us-cert.gov/bsi/articles/best-practices/architectural-risk-analysis/architectural-risk-analysis US-CERT]</ref><br />
+== Architectural Risk Analysis<ref>[https://www.us-cert.gov/bsi/articles/best-practices/architectural-risk-analysis/architectural-risk-analysis Architectural Risk Analysis]</ref> ==
-Three activities can guide architectural risk analysis: known [[vulnerability]] analysis, ambiguity analysis, and underlying platform vulnerability analysis. Architectural risk analysis examines the preconditions that must be present for vulnerabilities to be exploited and assesses the states that the [[system]] may enter upon exploitation. As with any quality assurance [[process]], risk analysis testing can only prove the presence, not the absence, of flaws. Architectural risk analysis studies vulnerabilities and threats that may be malicious or non-malicious in nature. Whether the vulnerabilities are exploited intentionally (malicious) or unintentionally (non-malicious) the net result is that the confidentiality, integrity, and/or availability of the organization’s assets may be impacted. Risk [[management]] and risk transfer instruments deal with unmitigated vulnerabilities. One of the strengths of conducting risk analysis at the architectural level is to see the relationships and impacts at a system level. In practice, this means assessing vulnerabilities not just at a component or function level, but also at interaction points. Use case models help to illustrate the relationships among system components. The architecture risk analysis should factor these relationships into the vulnerabilities analysis and consider vulnerabilities that may emerge from these combinations.
+Three activities can guide architectural risk analysis: known vulnerability analysis, ambiguity analysis, and underlying platform vulnerability analysis. Architectural risk analysis examines the preconditions that must be present for vulnerabilities to be exploited and assesses the states that the system may enter upon exploitation. As with any quality assurance process, risk analysis testing can only prove the presence, not the absence, of flaws. Architectural risk analysis studies vulnerabilities and threats that may be malicious or non-malicious in nature. Whether the vulnerabilities are exploited intentionally (malicious) or unintentionally (non-malicious) the net result is that the confidentiality, integrity, and/or availability of the organization’s assets may be impacted. Risk management and risk transfer instruments deal with unmitigated vulnerabilities. One of the strengths of conducting risk analysis at the architectural level is to see the relationships and impacts at a system level. In practice, this means assessing vulnerabilities not just at a component or function level, but also at interaction points. Use-case models help to illustrate the relationships among system components. The architecture risk analysis should factor these relationships into the vulnerabilities analysis and consider vulnerabilities that may emerge from these combinations.
-*Known Vulnerability Analysis
+*Known Vulnerability Analysis: There are a lot of known vulnerabilities documented throughout software security literature. They range from the obvious (failure to authenticate) to the subtle (symmetric key management). Static code checkers, runtime code checkers, profiling tools, penetration testing tools, stress test tools, and application scanning tools can find some security bugs in code, but they do not address architectural problems. For example, a static code checker can flag bugs like buffer overflows. It cannot identify security vulnerabilities like transitive trust. When performing known vulnerability analysis, consider the architecture as it has been described in the artifacts that were reviewed for asset identification. Consider it against a body of known bad practices or known good principles for confidentiality, integrity, and availability. For example, the good principle of "least privilege" prescribes that all software operations should be performed with the least possible privilege required to meet the need. To consider architecture in light of this principle, find all the areas in the system that operate at an elevated privilege. Perhaps diagram the system's major modules, classes, or subsystems and circle areas of high privilege versus areas of low privilege. Consider the boundaries between these areas and the kinds of communications across those boundaries.
-There are a lot of known vulnerabilities documented throughout [[software]] security literature. They range from the obvious (failure to authenticate) to the subtle (symmetric key management). Static code checkers, runtime code checkers, profiling tools, penetration testing tools, stress test tools, and [[application]] scanning tools can find some security bugs in code, but they do not address architectural problems. For example, a static code checker can flag bugs like buffer overflows. It cannot identify security vulnerabilities like transitive trust. When performing known vulnerability analysis, consider the architecture as it has been described in the artifacts that were reviewed for [[asset]] identification. Consider it against a body of known bad practices or known good principles for confidentiality, integrity, and availability. For example, the good [[principle]] of "least privilege" prescribes that all software operations should be performed with the least possible privilege required to meet the need. To consider architecture in light of this principle, find all the areas in the system that operate at an elevated privilege. Perhaps diagram the system's major modules, classes, or subsystems and circle areas of high privilege versus areas of low privilege. Consider the boundaries between these areas and the kinds of communications across those boundaries.
+*Ambiguity Analysis: Ambiguity is a rich source of vulnerabilities when it exists between requirements or specifications and development. Architecture's role is to eliminate the potential misunderstandings between business requirements for software and the developers' implementation of the software's actions. It is vital to acquire business statements (marketing literature, business goal statements, etc.) and requirements-phase artifacts (use cases, user stories, requirements). These pre-requirement and requirement artifacts must be contrasted with development artifacts (code, low-level design, API documentation) and then compared to the intermediate architecture documentation. The important point is to note places where the requirements are ambiguously stated and the implementation and architecture either disagree or fail to resolve the ambiguity. For example, a requirement for a web application might state that an administrator can lock an account and the user can no longer log in while the account remains locked. What about sessions for that user that are actively in use at the time the administrator locks the account? Is the user suddenly and forcibly logged out, or is the active session still valid until the user logs out? The authentication and authorization architecture must be compared to the actual implementation to learn which way this question was decided. The security ramifications of logins that persist even after the account is locked should be considered against the sensitivity of the information assets being guarded.
-*Ambiguity Analysis
+*Underlying Platform Vulnerability Analysis: An architectural risk assessment must include an analysis of the vulnerabilities associated with the application's execution environment. This will include operating system vulnerabilities, network vulnerabilities, platform vulnerabilities (popular platforms include WebLogic, WebSphere, PHP, ASP.net, and Jakarta), and interaction vulnerabilities resulting from the interaction of components. The goal of this step is to develop a list of application or system vulnerabilities that could be accidentally triggered or intentionally exploited and result in a security breach or a violation of the system’s security policy. When credible threats can be combined with the vulnerabilities uncovered in this exercise, a risk exists that needs further analysis and mitigation. The types of vulnerabilities that will exist and the methodology needed to determine whether the vulnerabilities are present will vary depending on which phase in the SDLC the risk assessment occurs. In the requirements phase, the search for vulnerabilities should focus on the organization’s security policies, planned security procedures, non-functional requirement definitions, use cases, and misuse and abuse cases. In the implementation phase, the identification of vulnerabilities should include more specific information, such as the planned security features described in the security design documentation. For fielded applications that are operational, the process of identifying vulnerabilities should include an analysis of the software security features and the security controls, technical and procedural, used to protect the system. Fielded systems can also use the results of system tests and reports from users in the field to identify problems. Independent of the life-cycle phase, online vulnerability references should be consulted. Every application platform and operating system has a mailing list and a website where up-to-date vulnerability information can be found. There are also several websites that aggregate vulnerability information. These sites and lists should be consulted regularly to keep the vulnerability list current for a given architecture.
-===See Also===
+== See Also ==
-[[Architectural_Style|Architectural Style]]<br />
+[[Architectural Style]]<br />
-[[Architectural_Pattern|Architectural Pattern]]<br />
+[[Architectural Pattern]]<br />
-[[Architectural_Principles|Architectural Principles]]<br />
+[[Architectural Principles]]<br />
-[[Architecture|Architecture]]<br />
+[[Architecture]]<br />
-[[Architecture_Description_Language_(ADL)|Architecture Description Language (ADL)]]<br />
+[[Architecture Description Language (ADL)]]<br />
-[[Architecture_Development_Method_(ADM)|Architecture Development Method (ADM)]]<br />
+[[Architecture Development Method (ADM)]]<br />
-[[Service_Oriented_Architecture_(SOA)|Service Oriented Architecture (SOA)]]<br />
+[[Service Oriented Architecture (SOA)]]<br />
-[[Software_Architecture|Software Architecture]]<br />
+[[Software Architecture]]<br />
-[[The_Open_Group_Architecture_Framework_(TOGAF)|The Open Group Architecture Framework (TOGAF)]]<br />
+[[The Open Group Architecture Framework (TOGAF)]]<br />
-[[Architecture_Driven_Modernization|Architecture-Driven Modernization]]<br />
+[[Architecture Driven Modernization]]<br />
-[[Design_Pattern|Design Pattern]]<br />
+[[Design Pattern]]<br />
-[[Enterprise_Architecture|Enterprise Architecture]]
+[[Enterprise Architecture]]
-===References===
+== References ==
 <references/>
-===Further Reading===
+== Further Reading ==
-*Identifying and Understanding Architectural Risks in Software Evolution: An Empirical Study [https://dl.acm.org/citation.cfm?id=1425936 Odd Petter N Slyngstad, Jingyue Li et. al]
+*[https://dl.acm.org/citation.cfm?id=1425936 Identifying and Understanding Architectural Risks in Software Evolution: An Empirical Study]
-*Estimating and Understanding Architectural Risk [https://www.cs.ucsb.edu/~sherwood/pubs/MICRO-17-archrisk.pdf Weilong Cui, Timothy Sherwood]
+*[https://www.cs.ucsb.edu/~sherwood/pubs/MICRO-17-archrisk.pdf Estimating and Understanding Architectural Risk]

@@ Line 1: / Line 1: @@
-'''Architectural Risk''' is defined as independently tracked risk or issue observable in the architecture. It is typically captured by an Enterprise Architect. This entity may contain links to documentation of the risk, escalations, exceptions, status, events, and quantifiable measures.<ref>Defining Architectural Risk [http://motivationmodel.com/ontology-enterprise-strategy-viewpoint/ EBMM]</ref>
+'''Architectural [[Risk]]''' is defined as independently tracked risk or issue observable in the [[architecture]]. It is typically captured by an Enterprise Architect. This entity may contain links to documentation of the risk, escalations, exceptions, status, events, and quantifiable measures.<ref>Defining Architectural Risk [http://motivationmodel.com/ontology-enterprise-strategy-viewpoint/ EBMM]</ref>
-Architecture risk is the potential for an architectural design to fail to satisfy the requirements for a project. This includes capacity limitations, poor quality designs, flaws and inefficiencies that are either rejected by the sponsor or impede project work.<ref>What is Architectural Risk? [https://simplicable.com/new/architecture-risk Simplicable]</ref>
+Architecture risk is the potential for an architectural [[design]] to fail to satisfy the requirements for a project. This includes capacity limitations, poor [[quality]] designs, flaws and inefficiencies that are either rejected by the sponsor or impede project work.<ref>What is Architectural Risk? [https://simplicable.com/new/architecture-risk Simplicable]</ref>
 '''Relationship Between Uncertainty and Architectural Risk (See Figure below)'''<ref>Relationship Between Uncertainty and Architectural Risk [https://www.cs.ucsb.edu/~sherwood/pubs/MICRO-17-archrisk.pdf ucsb.edu]</ref><br />
-Architectural risk, intuitively, is the degree to which the performance of a design is fragile in the face of unknowns. In many industrial settings high level design decisions are made at the level of spreadsheets and other high-level analytical models or data points drawn from past experience. Most do not consider the uncertainty in the assumptions being made nor the fragility of the decisions with respect to those uncertainties. Uncertainty and risk are commonly used terms in many fields
+Architectural risk, intuitively, is the degree to which the performance of a design is fragile in the face of unknowns. In many industrial settings high level design decisions are made at the level of spreadsheets and other high-level analytical models or [[data]] points drawn from past experience. Most do not consider the uncertainty in the assumptions being made nor the fragility of the decisions with respect to those uncertainties. Uncertainty and risk are commonly used terms in many fields
-including economic and financial analytics.
+including economic and financial [[analytics]].
@@ Line 14: / Line 14: @@
-'''Architectural Risk Analysis'''<ref>Architectural Risk Analysis [https://www.us-cert.gov/bsi/articles/best-practices/architectural-risk-analysis/architectural-risk-analysis US-CERT]</ref><br />
+'''Architectural [[Risk Analysis]]'''<ref>Architectural Risk Analysis [https://www.us-cert.gov/bsi/articles/best-practices/architectural-risk-analysis/architectural-risk-analysis US-CERT]</ref><br />
-Three activities can guide architectural risk analysis: known vulnerability analysis, ambiguity analysis, and underlying platform vulnerability analysis. Architectural risk analysis examines the preconditions that must be present for vulnerabilities to be exploited and assesses the states that the system may enter upon exploitation. As with any quality assurance process, risk analysis testing can only prove the presence, not the absence, of flaws. Architectural risk analysis studies vulnerabilities and threats that may be malicious or non-malicious in nature. Whether the vulnerabilities are exploited intentionally (malicious) or unintentionally (non-malicious) the net result is that the confidentiality, integrity, and/or availability of the organization’s assets may be impacted. Risk management and risk transfer instruments deal with unmitigated vulnerabilities. One of the strengths of conducting risk analysis at the architectural level is to see the relationships and impacts at a system level. In practice, this means assessing vulnerabilities not just at a component or function level, but also at interaction points. Use case models help to illustrate the relationships among system components. The architecture risk analysis should factor these relationships into the vulnerabilities analysis and consider vulnerabilities that may emerge from these combinations.
+Three activities can guide architectural risk analysis: known [[vulnerability]] analysis, ambiguity analysis, and underlying platform vulnerability analysis. Architectural risk analysis examines the preconditions that must be present for vulnerabilities to be exploited and assesses the states that the [[system]] may enter upon exploitation. As with any quality assurance [[process]], risk analysis testing can only prove the presence, not the absence, of flaws. Architectural risk analysis studies vulnerabilities and threats that may be malicious or non-malicious in nature. Whether the vulnerabilities are exploited intentionally (malicious) or unintentionally (non-malicious) the net result is that the confidentiality, integrity, and/or availability of the organization’s assets may be impacted. Risk [[management]] and risk transfer instruments deal with unmitigated vulnerabilities. One of the strengths of conducting risk analysis at the architectural level is to see the relationships and impacts at a system level. In practice, this means assessing vulnerabilities not just at a component or function level, but also at interaction points. Use case models help to illustrate the relationships among system components. The architecture risk analysis should factor these relationships into the vulnerabilities analysis and consider vulnerabilities that may emerge from these combinations.
 *Known Vulnerability Analysis
-There are a lot of known vulnerabilities documented throughout software security literature. They range from the obvious (failure to authenticate) to the subtle (symmetric key management). Static code checkers, runtime code checkers, profiling tools, penetration testing tools, stress test tools, and application scanning tools can find some security bugs in code, but they do not address architectural problems. For example, a static code checker can flag bugs like buffer overflows. It cannot identify security vulnerabilities like transitive trust. When performing known vulnerability analysis, consider the architecture as it has been described in the artifacts that were reviewed for asset identification. Consider it against a body of known bad practices or known good principles for confidentiality, integrity, and availability. For example, the good principle of "least privilege" prescribes that all software operations should be performed with the least possible privilege required to meet the need. To consider architecture in light of this principle, find all the areas in the system that operate at an elevated privilege. Perhaps diagram the system's major modules, classes, or subsystems and circle areas of high privilege versus areas of low privilege. Consider the boundaries between these areas and the kinds of communications across those boundaries.
+There are a lot of known vulnerabilities documented throughout [[software]] security literature. They range from the obvious (failure to authenticate) to the subtle (symmetric key management). Static code checkers, runtime code checkers, profiling tools, penetration testing tools, stress test tools, and [[application]] scanning tools can find some security bugs in code, but they do not address architectural problems. For example, a static code checker can flag bugs like buffer overflows. It cannot identify security vulnerabilities like transitive trust. When performing known vulnerability analysis, consider the architecture as it has been described in the artifacts that were reviewed for [[asset]] identification. Consider it against a body of known bad practices or known good principles for confidentiality, integrity, and availability. For example, the good [[principle]] of "least privilege" prescribes that all software operations should be performed with the least possible privilege required to meet the need. To consider architecture in light of this principle, find all the areas in the system that operate at an elevated privilege. Perhaps diagram the system's major modules, classes, or subsystems and circle areas of high privilege versus areas of low privilege. Consider the boundaries between these areas and the kinds of communications across those boundaries.
 *Ambiguity Analysis
-Ambiguity is a rich source of vulnerabilities when it exists between requirements or specifications and development. Architecture's role is to eliminate the potential misunderstandings between business requirements for software and the developers' implementation of the software's actions. It is vital to acquire business statements (marketing literature, business goal statements, etc.) and requirements-phase artifacts (use cases, user stories, requirements). These pre-requirement and requirement artifacts must be contrasted with development artifacts (code, low-level design, API documentation) and then compared to the intermediate architecture documentation. The important point is to note places where the requirements are ambiguously stated and the implementation and architecture either disagree or fail to resolve the ambiguity. For example, a requirement for a web application might state that an administrator can lock an account and the user can no longer log in while the account remains locked. What about sessions for that user that are actively in use at the time the administrator locks the account? Is the user suddenly and forcibly logged out, or is the active session still valid until the user logs out? The authentication and authorization architecture must be compared to the actual implementation to learn which way this question was decided. The security ramifications of logins that persist even after the account is locked should be considered against the sensitivity of the information assets being guarded.
+Ambiguity is a rich source of vulnerabilities when it exists between requirements or specifications and development. Architecture's role is to eliminate the potential misunderstandings between [[business]] requirements for software and the developers' implementation of the software's actions. It is vital to acquire business statements ([[marketing]] literature, business goal statements, etc.) and requirements-phase artifacts (use cases, user stories, requirements). These pre-[[requirement]] and requirement artifacts must be contrasted with development artifacts (code, low-level design, API documentation) and then compared to the intermediate architecture documentation. The important point is to note places where the requirements are ambiguously stated and the implementation and architecture either disagree or fail to resolve the ambiguity. For example, a requirement for a web application might state that an administrator can lock an account and the user can no longer log in while the account remains locked. What about sessions for that user that are actively in use at the time the administrator locks the account? Is the user suddenly and forcibly logged out, or is the active session still valid until the user logs out? The [[authentication]] and authorization architecture must be compared to the actual implementation to learn which way this question was decided. The security ramifications of logins that persist even after the account is locked should be considered against the sensitivity of the information assets being guarded.
 *Underlying Platform Vulnerability Analysis
-An architectural risk assessment must include an analysis of the vulnerabilities associated with the application's execution environment. This will include operating system vulnerabilities, network vulnerabilities, platform vulnerabilities (popular platforms include WebLogic, WebSphere, PHP, ASP.net, and Jakarta), and interaction vulnerabilities resulting from the interaction of components. The goal of this step is to develop a list of application or system vulnerabilities that could be accidentally triggered or intentionally exploited and result in a security breach or a violation of the system’s security policy. When credible threats can be combined with the vulnerabilities uncovered in this exercise, a risk exists that needs further analysis and mitigation. The types of vulnerabilities that will exist and the methodology needed to determine whether the vulnerabilities are present will vary depending on which phase in the SDLC the risk assessment occurs. In the requirements phase, the search for vulnerabilities should focus on the organization’s security policies, planned security procedures, non-functional requirement definitions, use cases, and misuse and abuse cases. In the implementation phase, the identification of vulnerabilities should include more specific information, such as the planned security features described in the security design documentation. For fielded applications that are operational, the process of identifying vulnerabilities should include an analysis of the software security features and the security controls, technical and procedural, used to protect the system. Fielded systems can also use the results of system tests and reports from users in the field to identify problems. Independent of the life-cycle phase, online vulnerability references should be consulted. Every application platform and operating system has a mailing list and a web site where up-to-date vulnerability information can be found. There are also several web sites that aggregate vulnerability information. These sites and lists should be consulted regularly to keep the vulnerability list current for a given architecture.
+An architectural risk assessment must include an analysis of the vulnerabilities associated with the application's execution environment. This will include operating system vulnerabilities, [[network]] vulnerabilities, platform vulnerabilities (popular platforms include WebLogic, WebSphere, PHP, ASP.net, and Jakarta), and interaction vulnerabilities resulting from the interaction of components. The goal of this step is to develop a list of application or system vulnerabilities that could be accidentally triggered or intentionally exploited and result in a security breach or a violation of the system’s security [[policy]]. When credible threats can be combined with the vulnerabilities uncovered in this exercise, a risk exists that needs further analysis and mitigation. The types of vulnerabilities that will exist and the [[methodology]] needed to determine whether the vulnerabilities are present will vary depending on which phase in the SDLC the risk assessment occurs. In the requirements phase, the search for vulnerabilities should focus on the organization’s security policies, planned security procedures, non-functional requirement definitions, use cases, and misuse and abuse cases. In the implementation phase, the identification of vulnerabilities should include more specific information, such as the planned security features described in the security design documentation. For fielded applications that are operational, the process of identifying vulnerabilities should include an analysis of the software security features and the security controls, technical and procedural, used to protect the system. Fielded systems can also use the results of system tests and reports from users in the field to identify problems. Independent of the life-cycle phase, online vulnerability references should be consulted. Every application platform and operating system has a mailing list and a web site where up-to-date vulnerability information can be found. There are also several web sites that aggregate vulnerability information. These sites and lists should be consulted regularly to keep the vulnerability list current for a given architecture.

← Older revision		Revision as of 16:11, 29 May 2020
Line 1:		Line 1:
−	Architectural Risk is defined as independently tracked risk or issue observable in the architecture. It is typically captured by an Enterprise Architect. This entity may contain links to documentation of the risk, escalations, exceptions, status, events, and quantifiable measures.<ref>Defining Architectural Risk [http://motivationmodel.com/ontology-enterprise-strategy-viewpoint/ EBMM]</ref>	+	'''Architectural Risk''' is defined as independently tracked risk or issue observable in the architecture. It is typically captured by an Enterprise Architect. This entity may contain links to documentation of the risk, escalations, exceptions, status, events, and quantifiable measures.<ref>Defining Architectural Risk [http://motivationmodel.com/ontology-enterprise-strategy-viewpoint/ EBMM]</ref>

@@ Line 45: / Line 45: @@
 ===Further Reading===
 *Identifying and Understanding Architectural Risks in Software Evolution: An Empirical Study [https://dl.acm.org/citation.cfm?id=1425936 Odd Petter N Slyngstad, Jingyue Li et. al]
-*Estimating and Understanding Architectural Risk [Estimating and Understanding Architectural Risk Weilong Cui, Timothy Sherwood]
+*Estimating and Understanding Architectural Risk [https://www.cs.ucsb.edu/~sherwood/pubs/MICRO-17-archrisk.pdf Weilong Cui, Timothy Sherwood]

← Older revision		Revision as of 20:42, 3 December 2018
Line 1:		Line 1:
−	'''~~Content Coming Soon~~'''	+	Architectural Risk is defined as independently tracked risk or issue observable in the architecture. It is typically captured by an Enterprise Architect. This entity may contain links to documentation of the risk, escalations, exceptions, status, events, and quantifiable measures.<ref>Defining Architectural Risk [http://motivationmodel.com/ontology-enterprise-strategy-viewpoint/ EBMM]</ref>
		+
		+
		+	Architecture risk is the potential for an architectural design to fail to satisfy the requirements for a project. This includes capacity limitations, poor quality designs, flaws and inefficiencies that are either rejected by the sponsor or impede project work.<ref>What is Architectural Risk? [https://simplicable.com/new/architecture-risk Simplicable]</ref>
		+
		+
		+	'''Relationship Between Uncertainty and Architectural Risk (See Figure below)'''<ref>Relationship Between Uncertainty and Architectural Risk [https://www.cs.ucsb.edu/~sherwood/pubs/MICRO-17-archrisk.pdf ucsb.edu]</ref><br />
		+	Architectural risk, intuitively, is the degree to which the performance of a design is fragile in the face of unknowns. In many industrial settings high level design decisions are made at the level of spreadsheets and other high-level analytical models or data points drawn from past experience. Most do not consider the uncertainty in the assumptions being made nor the fragility of the decisions with respect to those uncertainties. Uncertainty and risk are commonly used terms in many fields
		+	including economic and financial analytics.
		+
		+
		+	[[File:Architectural Risk.png\|500px\|Architectural Risk]]<br />
		+	source: [https://www.cs.ucsb.edu/~sherwood/pubs/MICRO-17-archrisk.pdf UC Santa Barbara]
		+
		+
		+	'''Architectural Risk Analysis'''<ref>Architectural Risk Analysis [https://www.us-cert.gov/bsi/articles/best-practices/architectural-risk-analysis/architectural-risk-analysis US-CERT]</ref><br />
		+	Three activities can guide architectural risk analysis: known vulnerability analysis, ambiguity analysis, and underlying platform vulnerability analysis. Architectural risk analysis examines the preconditions that must be present for vulnerabilities to be exploited and assesses the states that the system may enter upon exploitation. As with any quality assurance process, risk analysis testing can only prove the presence, not the absence, of flaws. Architectural risk analysis studies vulnerabilities and threats that may be malicious or non-malicious in nature. Whether the vulnerabilities are exploited intentionally (malicious) or unintentionally (non-malicious) the net result is that the confidentiality, integrity, and/or availability of the organization’s assets may be impacted. Risk management and risk transfer instruments deal with unmitigated vulnerabilities. One of the strengths of conducting risk analysis at the architectural level is to see the relationships and impacts at a system level. In practice, this means assessing vulnerabilities not just at a component or function level, but also at interaction points. Use case models help to illustrate the relationships among system components. The architecture risk analysis should factor these relationships into the vulnerabilities analysis and consider vulnerabilities that may emerge from these combinations.
		+	*Known Vulnerability Analysis
		+	There are a lot of known vulnerabilities documented throughout software security literature. They range from the obvious (failure to authenticate) to the subtle (symmetric key management). Static code checkers, runtime code checkers, profiling tools, penetration testing tools, stress test tools, and application scanning tools can find some security bugs in code, but they do not address architectural problems. For example, a static code checker can flag bugs like buffer overflows. It cannot identify security vulnerabilities like transitive trust. When performing known vulnerability analysis, consider the architecture as it has been described in the artifacts that were reviewed for asset identification. Consider it against a body of known bad practices or known good principles for confidentiality, integrity, and availability. For example, the good principle of "least privilege" prescribes that all software operations should be performed with the least possible privilege required to meet the need. To consider architecture in light of this principle, find all the areas in the system that operate at an elevated privilege. Perhaps diagram the system's major modules, classes, or subsystems and circle areas of high privilege versus areas of low privilege. Consider the boundaries between these areas and the kinds of communications across those boundaries.
		+	*Ambiguity Analysis
		+	Ambiguity is a rich source of vulnerabilities when it exists between requirements or specifications and development. Architecture's role is to eliminate the potential misunderstandings between business requirements for software and the developers' implementation of the software's actions. It is vital to acquire business statements (marketing literature, business goal statements, etc.) and requirements-phase artifacts (use cases, user stories, requirements). These pre-requirement and requirement artifacts must be contrasted with development artifacts (code, low-level design, API documentation) and then compared to the intermediate architecture documentation. The important point is to note places where the requirements are ambiguously stated and the implementation and architecture either disagree or fail to resolve the ambiguity. For example, a requirement for a web application might state that an administrator can lock an account and the user can no longer log in while the account remains locked. What about sessions for that user that are actively in use at the time the administrator locks the account? Is the user suddenly and forcibly logged out, or is the active session still valid until the user logs out? The authentication and authorization architecture must be compared to the actual implementation to learn which way this question was decided. The security ramifications of logins that persist even after the account is locked should be considered against the sensitivity of the information assets being guarded.
		+	*Underlying Platform Vulnerability Analysis
		+	An architectural risk assessment must include an analysis of the vulnerabilities associated with the application's execution environment. This will include operating system vulnerabilities, network vulnerabilities, platform vulnerabilities (popular platforms include WebLogic, WebSphere, PHP, ASP.net, and Jakarta), and interaction vulnerabilities resulting from the interaction of components. The goal of this step is to develop a list of application or system vulnerabilities that could be accidentally triggered or intentionally exploited and result in a security breach or a violation of the system’s security policy. When credible threats can be combined with the vulnerabilities uncovered in this exercise, a risk exists that needs further analysis and mitigation. The types of vulnerabilities that will exist and the methodology needed to determine whether the vulnerabilities are present will vary depending on which phase in the SDLC the risk assessment occurs. In the requirements phase, the search for vulnerabilities should focus on the organization’s security policies, planned security procedures, non-functional requirement definitions, use cases, and misuse and abuse cases. In the implementation phase, the identification of vulnerabilities should include more specific information, such as the planned security features described in the security design documentation. For fielded applications that are operational, the process of identifying vulnerabilities should include an analysis of the software security features and the security controls, technical and procedural, used to protect the system. Fielded systems can also use the results of system tests and reports from users in the field to identify problems. Independent of the life-cycle phase, online vulnerability references should be consulted. Every application platform and operating system has a mailing list and a web site where up-to-date vulnerability information can be found. There are also several web sites that aggregate vulnerability information. These sites and lists should be consulted regularly to keep the vulnerability list current for a given architecture.
		+
		+
		+	===See Also===
		+	[[Architectural_Style\|Architectural Style]]<br />
		+	[[Architectural_Pattern\|Architectural Pattern]]<br />
		+	[[Architectural_Principles\|Architectural Principles]]<br />
		+	[[Architecture\|Architecture]]<br />
		+	[[Architecture_Description_Language_(ADL)\|Architecture Description Language (ADL)]]<br />
		+	[[Architecture_Development_Method_(ADM)\|Architecture Development Method (ADM)]]<br />
		+	[[Service_Oriented_Architecture_(SOA)\|Service Oriented Architecture (SOA)]]<br />
		+	[[Software_Architecture\|Software Architecture]]<br />
		+	[[The_Open_Group_Architecture_Framework_(TOGAF)\|The Open Group Architecture Framework (TOGAF)]]<br />
		+	[[Architecture_Driven_Modernization\|Architecture-Driven Modernization]]<br />
		+	[[Design_Pattern\|Design Pattern]]<br />
		+	[[Enterprise_Architecture\|Enterprise Architecture]]
		+
		+
		+	===References===
		+	<references/>
		+
		+
		+	===Further Reading===
		+	*Identifying and Understanding Architectural Risks in Software Evolution: An Empirical Study [https://dl.acm.org/citation.cfm?id=1425936 Odd Petter N Slyngstad, Jingyue Li et. al]
		+	*Estimating and Understanding Architectural Risk [Estimating and Understanding Architectural Risk Weilong Cui,Timothy Sherwood]