Cloud Threat Modeling is performed once an application design is created.
The goal of Cloud Threat Modeling is to determine any weaknesses in the application and the potential ingress, egress, and actors involved before the weakness is introduced to production.
It is the overall attack surface that is amplified by the cloud, and the threat model has to take that into account.
Quite often, this involves a security professional determining various ways to attack the system or connections or even performing social engineering against staff with access to the system.
The Cloud professionals should always remember that the nature of threats faced by a system changes over time.
Because of the dynamic nature of a changing threat landscape, constant vigilance and monitoring are important aspects of overall system security in the cloud
STRIDE Threat Model
STRIDE is a system for classifying known threats according to the kinds of exploits that are used or the motivation of the attacker.
In the STRIDE threat model or Cloud Threat Modeling the following six threats are considered,
and controls are used to address the threats:
- Spoofing: The attacker assumes the identity of the subject
- Tampering: Data or messages altered by an attacker
- Repudiation: Illegitimate denial of an event
- Information disclosure: Information obtained without authorization
- Denial of service: Attacker overloads system to deny legitimate access
- Elevation of privilege: Attacker gains a privilege level above what is permitted
Today’s software applications are built by leveraging other software components as building blocks to create a unique software offering. The leveraged software is often
seen as a “black box” by developers who might not have the ability or thought to ensure the security of the applications and code.
However, it remains the responsibility of the organization to assess code for proper, secure function no matter where the code is sourced.
This section discusses some of the security aspects involved with the selection of software components that are leveraged by your organization’s developers
Approved Application Programming Interfaces
Application programming interfaces (APIs) are a means for a company to expose functionality to applications. Following are three benefits of APIs:
- Programmatic control and access
- Integration with third-party tools
Consumption of APIs can lead to your firm leveraging insecure products.
As discussed in the next section, organizations must also consider the security of software (and APIs) outside of their corporate boundaries.
Consumption of external APIs should go through the same approval process that’s used for all other software being consumed by the organization.
The Cloud professionals needs to ensure that there is a formal approval process in place for all APIs.
If there is a change in an API or an issue due to an unforeseen threat, a vendor update, or any other reason, the API in question should not be allowed until a thorough review has been undertaken to assess the integrity of the API in light of the new information.
When leveraging APIs, the Cloud professionals should take steps to ensure that API access is secured.
This requires the use of a secure sockets layer, or SSL (REST), or message-level crypto access (SOAP) authentication and logging of API usage.
In addition, the use of a tool such as OWASP’s Dependency-Check which is a utility that identifies project dependencies and checks whether there are any known, publicly disclosed, vulnerabilities would be valuable.
This tool currently supports Java and .NET dependencies.14
Software Supply Chain (API) Management
Organizations must consider the implications of nonsecure software beyond their corporate boundaries.
The ease with which software components with unknown pedigrees or with uncertain development processes can be combined to produce new applications has created a complex and highly dynamic software supply chain (API management).
In effect, people are consuming more and more software that is being developed by a third party or accessed with or through third-party libraries to create or enable functionality, without having a clear understanding of the origins of the software and code in question.
This often leads to a situation in which a complex and highly dynamic
software interaction is taking place between and among one or more services and systems within the organization and between organizations via the cloud.
This supply chain supplies agility in the rapid development of applications to meet consumer demand.
However, software components produced without secure software development guidance similar to that defined by ISO/IEC 27034-1 can create security risks throughout the supply chain.
Therefore, it is important to assess all code and services for proper and secure functioning no matter where they are sourced.
Securing Open Source Software
Software that the community at large has openly tested and reviewed is considered by many security professionals to be more secure than software that has not undergone such a process.
This can include open-source software.
By moving toward leveraging standards such as ISO 27034-1, companies can be confident that partners have the same understanding of application security.
This increases security as organizations, regulatory bodies, and the IT audit community learn the importance of embedding security throughout the processes required to build and consume security.
