Software QA FYI - SQAFYI

Applying Software Assurance Concepts to the Cloud

By: Randall Brooks, Raytheon John Whited

It was once said that the last time one had full control of their software was right before they released it. This is ever more important as organizations move applications and services into a public cloud to support a mobile lifestyle. Clouds have been described as “a safe and secure private cloud,” “a semi-trusted partner cloud,” or “a Wild West full and open public cloud.” It is typically toward the latter in which the industry has been moving. Because of this, developers must understand their attack surface and threat environment to ensure that they have focused on “building security into” their applications

Software Assurance
Software Assurance (SwA) is defined by the National Information Assurance Glossary, Committee on National Security Systems Instruction (CNSSI) No. 4009, as “the level of confidence that software is free from vulnerabilities, either intentionally designed into the software or accidentally inserted at anytime during its lifecycle, and that the software functions in the intended manner.” SwA focuses on “building security in” to ensure the software is resilient in harsh operating environments such as those in which cloud applications operate. According to the DHS, SwA addresses:
• Trustworthiness
• Predictable Execution
• Conformance

In a cloud environment, Trustworthiness is key to providing confidence to the user that no exploitable vulnerabilities exist. With use of mobile and the cloud, users will demand Predict -
able Execution. Cloud applications that function as intended will avoid user frustration. Cloud applications must conform to appropriate secure APIs to ensure interoperability with other applications and services.
To deliver SwA, various principles can be applied such as determining the criticality of the application, defining the Attack Surface, developing misuse cases, and testing for unintended consequences. But these principles have a slightly different emphasis when applied to the cloud.
Determine Component Risk and Criticality As with other complex problem spaces, understanding Attack Surface, the threat environment, and related elements of risk management in the cloud is best addressed by first decompos ing the problem space into its constituent components. Stepping down in the hierarchy from “the cloud,” we find the following:

• A cloud environment is composed of interacting systems. •
Each system may be comprised of multiple subsystems. •

Systems and subsystems are built from one or more components – at a software level, the host OS, most likely one or more guest operating systems, and the applications that are controlled by the OS and use OS services.

This decomposition can be extended arbitrarily to the required depth, until assessing the risk of the lowest level ele - ment (here, a “component”) can be meaningfully addressed. At this lowest level, the risk associated with a component can be characterized by assessing the following:

• Weaknesses or vulnerabilities inherent in the component
• The likelihood that a weakness or vulnerability can be exploited
• The existence of a means to exploit the weakness or vulnerability
• The presence of a threat actor with the skills and access to launch an exploit
• The impact of a realized exploit should it occur Once a risk profile is created using these factors for each component, a combined risk analysis can then be undertaken on subsystems and then systems while considering the operational importance to the organizational mission. This top-down decom - position, component risk assessment, and bottom-up reconstitu - tion yields a structured means of assessing the risk associated with a complex cloud environment.

Threat Modeling: Define the Attack Surface and Develop Misuse Cases

To further understand component risk, one must understand the specific means by which a threat actor might be able to exploit a vulnerability. This is the component’s Attack Surface. Once decomposition is accomplished, a good way to define one’s composite Attack Surface is to perform Threat Modeling on each component. Microsoft teaches an application centric method called Spoofing, Tampering, Repudiation, Informa - tion Disclosure, Denial of Service, and Elevation of Privilege (STRIDE). Aspects such as Denial of Service (DoS) and Eleva - tion of Privilege have a more pronounced importance in cloud applications.
For example, due to the need of accessibility to data, an effect of a DoS attack may cause far worse consequences in a public cloud than a private cloud. A prolonged DoS attack may also affect user perception of how well an application operates. Further, if one hosts their cloud application with a cloud provider, it is likely that their application will reside on a virtual machine (VM) running on a large server class system with other VMs, as many public cloud-based systems utilize hosted VMs. In this virtual environment, privilege escalation may have a far-reaching effect on one’s hosted application and other ap - plications hosted on the same system. As depicted in Figure 1, a successful privilege elevation attack of a hosted VM may put other hosted VMs in one’s “digital neighborhood” at risk.

Full article...

Other Resource

... to read more articles, visit

Applying Software Assurance Concepts to the Cloud