Harden cloud apps with a secure software development lifecycle

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. 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 looks 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 requirements of a secure software development lifecycle that mandates such systems 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.

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 arc 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 CCSP needs to understand the basic concept of a cloud software development lifecycle and what it can do for the organization. A secure 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 this 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.

The intent of a secure software development lifecycle process is to help produce a product that is cost-efficient, effective, and high quality. The secure software development lifecycle methodology usually contains the following stages; analysis (requirements and design), construction, testing, release, and maintenance (response).

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. In an effort to reduce these complexities, where possible (and available), the CSP's API should be used.

Overarching challenges

At all times, developers adhering to a secure software development lifecycle must keep in mind two key risks associated with applications that run in the cloud:

Multi-tenancy
Third-party administrators

It is also critical that developers understand the security requirements based on the following:
       Deployment model: public, private, community, or hybrid (that the application will run in);
       Service model: infrastructure as a service, platform as a service, or software as a service.

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.

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.

CCSP® is a registered mark of (ISC)².