As cloud computing based application development continues to gain popularity and widespread adoption, it is important to recognize the benefits and efficiencies, along with the challenges and complexities.
cloud computing application development typically includes integrated development environments (IDEs), application lifecycle management components, and application security testing
Benefits and efficiencies tend to conflict with challenges and complexities
Inherent to the continued and expanded use of technology to deliver services, organizations are presented with quantitative and qualitative risks and challenges.
The failure to address these risks directly affects the organization, its software supply chain (extended enterprise API management), and its customers.
For the appropriate steps and controls to be implemented, these organizations must understand application security in a cloud computing application environment, along with the differences from traditional information technology (IT) computing.
Just as traditional deployments within a data center or even a hosted solution where network controls are ubiquitous and compensating perimeter controls are sometimes depended upon to offer application security, cloud computing applications can be secure as long as the same security evaluation for cloud computing application environments is performed.
Organizations and practitioners alike need to understand and appreciate that cloud-based development and applications can vary from traditional or on-premises development. When considering an application for cloud computing application deployment,
you must remember that applications can be broken down into the following subcomponents:
- Data
- Functions
- Processes
The components can be broken up so that the portions that have sensitive data can be processed or stored in specified locations to comply with enterprise policies, standards, and applicable laws and regulations.
This domain highlights some of the key security differences that must be addressed in a cloud operating environment.
Determining Data Sensitivity and Importance
To begin, applications should undergo an assessment of the sensitivity and importance of an application that may be implemented in a cloud computing application environment.
The following six key questions can be used to open a discussion of the application to determine its cloud-friendliness
What would the impact be in the following situations:
- The data became widely public and widely distributed (including crossing geographic boundaries)
- An employee of the cloud service provider (CSP) accessed the application
- The processor function was manipulated by an outsider
- The process or function failed to provide expected results
- The data was unexpectedly changed
- The application was unavailable for some time
These questions form the basis of an information-gathering exercise to identify and understand the requirements for the AIC of an application and its associated information assets.
These questions can be discussed with a system owner to begin a collaborative security discussion.
Further assessments will be discussed in later sections of this domain.
Note that this exercise should be performed by an independent resource or function without bias or preference within the organization.
Independence and the ability to present a true and accurate account of information types along with the requirements for AIC may be the difference between a successful project and a failur.
Understanding the API Formats
In many cloud computing application environments, access is acquired through the means of an API.
These APIs consume tokens rather than traditional usernames and passwords.
This topic is discussed in greater detail in the “Identity and Access Management” section later in this domain.
APIs can be broken into multiple formats, two of which follow:
- Representational State Transfer (REST): A software architecture style consisting of guidelines and best practices for creating scalable web services1
- Simple object access protocol (SOAP): A protocol specification for exchanging structured information in the implementation of web services in computer networks
| REST | SOAP |
| Representational State Transfer | Simple object access protocol |
| Uses simple hypertext transfer protocol (HTTP) | Uses SOAP envelope and then HTTP (or file transfer protocol [FTP]/simple mail transfer protocol [SMTP] to transfer the data |
| Supports many different data formats like JavaScript Object Notation (JSON), eXtensible Markup Language (XML), and Yet Another Multicolumn Layout (YAML) | Slower performance, scalability can be complex, and caching is not possible |
| Widely used | Used where REST is not possible, provides WS-* features |
CSPs should familiarize themselves with API formats as they relate to cloud services.
The ability to identify, communicate, and plan for potential cloud computing application challenges proves an invaluable skill for developers and project teams.
Failure to do so can result in additional costs, failed projects, and duplication of efforts along with loss of efficiencies and executive sponsorship.
Although many projects and cloud journeys may have an element of unique or nonstandard approaches, the pitfalls discussed in this section should always be followed and understood.
On-Premises Does Not Always Transfer (and Vice Versa)
Present performance and functionality may not be transferable. Current configurations and applications may be hard to replicate on or through cloud services.
Cloud Computing Application The rationale for this is twofold
First, they were not developed with cloud-based services in mind.
The continued evolution and expansion of cloud-based service offerings look to enhance previous technologies and development, not always maintaining support for more historical development and systems.
Where cloud-based development has occurred, this may need to be tested against on-premises or legacy-based systems.
Second, not all applications can be forklifted to the cloud.
Forklifting an application is the process of migrating an entire application the way it runs in a traditional infrastructure with minimal code changes.
Generally, these applications are self-contained and have few dependencies; however, transferring or utilizing cloud-based environments may introduce additional change requirements and additional interdependencies.
Not All Apps Are Cloud Ready
Where high-value data and hardened security controls are applied, cloud development and testing can be more challenging.
The reason for this is typically compounded by the requirement for such systems to be developed, tested, and assessed in on-premises or traditional environments to a level where confidentiality and integrity have been verified and assured.
Many high-end applications come with distinct security and regulatory restrictions or rely on legacy coding projects, many of which may have been developed using COBOL, along with other more historical development languages.
These reasons, along with whatever control frameworks may have to be observed and adhered to, can cause one or more applications to fail at being cloud-ready.
Cloud Computing Application Lack of Training and Awareness
New development techniques and approaches require training and a willingness to utilize new services.
Typically, developers have become accustomed to working with Microsoft .
NET, SQL Server, Java, and other traditional development techniques. When cloud-based environments are required or are requested by the organization, this may introduce challenges (particularly if it is a platform or system with which developers are unfamiliar).
Lack of Documentation and Guidelines
Best practice requires developers to follow relevant documentation, guidelines, methodologies, processes, and lifecycles to reduce opportunities for unnecessary or heightened risk to be introduced.
Given the rapid adoption of evolving cloud services, this has led to a disconnect between some providers and developers on how to utilize, integrate, or meet vendor requirements for development.
Although many providers are continuing to enhance levels of available documentation, the most up-to-date guidance may not always be available, particularly for new releases and updates.
For these reasons, the cloud professionals needs to understand the basic concept of a cloud software development lifecycle and what it can do for the organization.
A software development lifecycle is essentially a series of steps, or phases, that provide a model for the development and lifecycle management of an application or piece of software.
The methodology within the software development lifecycle process can vary across industries and organizations, but standards such as ISO/IEC 12207 represent processes that establish a lifecycle for software and provide a mode for the development, acquisition, and configuration of software systems.3 a software development lifecycle process intends to help produce a product that is cost-efficient, effective, and high quality.
The software development lifecycle methodology usually contains the following stages: analysis (requirements and design), construction, testing, release, and maintenance (response).
Cloud Computing Application Complexities Of Integration
Integrating new applications with existing ones can be a key part of the development process.
When developers and operational resources do not have open or unrestricted access to supporting components and services, integration can be complicated, particularly where the CSP manages infrastructure, applications, and integration platforms.
From a troubleshooting perspective, it can prove difficult to track or collect events and transactions across interdependent or underlying components. To reduce these complexities, where possible (and available), the CSP’s API should be used.
Cloud Computing Application Overarching Challenges
At all times, developers must keep in mind two key risks associated with applications that run in the cloud:
- Multitenancy
- Third-party administrators
It is also critical that developers understand the security requirements based on the following:
- Deployment model (public, private, community, hybrid) that the application will run in
- Service model (infrastructure as a service [IaaS], platform as a service [PaaS], or software as a service [SaaS])
These two models will assist in determining what security your provider will offer and what your organization is responsible for implementing and maintaining.
It is critical to evaluate who is responsible for security controls across the deployment and services models. Consider creating a sample responsibility matrix (Figure 4.3).
Security responsibility matrix for cloud service models.
Additionally, developers must be aware that metrics will always be required and cloud-based applications may have a higher reliance on metrics than internal applications to supply visibility into who is accessing the application and the actions they are performing.
This may require substantial development time to integrate said functionality and may eliminate a forklift approach.
Dependencies in the following modes:
- Encryption of data at rest: Addresses encrypting data as it is stored within the CSP network (such as hard disc drive [HDD], storage area network [SAN], network attached storage [NAS], and solid-state drive [SSD])
- Encryption of data in transit: Addresses security of data while it traverses the network (such as CSP network or Internet)
Additionally, the following method may be applied to data to prevent unauthorized viewing or accessing of sensitive information:
- Data masking (or data obfuscation): The process of hiding original data with random characters or data
- When encryption will be provided or supported by the CSP, an understanding of the encryption types, strength, algorithms, key management, and any associated responsibilities of other parties should be documented and understood.
- Additionally, depending on the industry type, relevant certifications or criteria may be required for the relevant encryption being used. Beyond encryption aspects of security, threat modeling (discussed later in this domain) must address attacks from either other cloud tenants or attacks from one organization application being used as a mechanism to perform attacks on other corporate applications in the same or other systems.
