Applying Software Assurance Concepts to the Cloud
By: Randall Brooks, Raytheon John Whited
Abstract.
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 http://sqa.fyicenter.com/art/
|