When an "application" was a monolithic software unit run on a single server, application lifecycle management (ALM) could still be challenging because of the need to sustain business operations through levels of software change. With the cloud and the combination of resource elasticity, multi-provider integration, and componentization and orchestration often on a per-worker basis, the challenge is considerably magnified. One area where the magnifying effect is particularly acute is that of security. The cloud's security demands, like all demands placed on application deployment, should be reflected in the
In ALM, applications go through an iterative rotation of development/modification, testing, staging, deployment, production/operation, version management and then return to the start. In traditionally static data center deployments, security processes were often applied to the environment (data center, network, and the like) in which applications were developed, tested and deployed for operation rather than to the applications themselves. The cyclical ALM processes took place inside a consistent security umbrella. Unfortunately, this approach doesn't work for the cloud.
In cloud deployments, applications increasingly deploy on a virtual sub-network that hosts virtual-machine or SaaS-component elements. These are then accessed through a WAN that connects to this application sub-network via a gateway -- which could be a router, a load-balancing switch or even a virtual device. All of this virtualization can disguise the fact that for security purposes each of these application structures is new infrastructure. Just as a virtual LAN without any gateway can't support user connections, a virtual LAN without security features specific to that network is not secure. This forces users to shift security management from an environmental issue to an application issue, and thus into an ALM issue.
The starting point for ALM-based security must be a virtual network model that, like real infrastructure, can be secured. Both public and private clouds, and all of the SaaS models of cloud services, are compatible with the assumption that a given application's components are hosted on a virtual LAN and accessible through a gateway via an IP address set. This model offers a network connection framework that can be secured in the same way a LAN in a data center could be, meaning that firewalls, access control, and the like can follow the standard data center model ALM professionals likely already use for internal IT. The model will have to be adapted to the cloud, and will also have to evolve through the ALM process from development/change to re-versioning and initiation of a new change cycle.
Changes in security practices for the cloud can now be linked to differences between the virtual-network model where the application is hosted and the real network model is used for data center applications. If the application's virtual network is accessible only from a controlled VPN, it presents no incremental security risks versus traditional applications accessed from that same VPN. If the application's virtual network is accessible via the Internet or via an Internet VPN, then the application's gateway may be addressable on the Internet and be subject to attempted hacking or DDoS attacks. These will almost always have to be mitigated either by the ISP or by the application's VLAN gateway, and in either case the process of activating security will have to be explicit (by contract or by selecting and setting up the gateway properly). These steps will have to be added to the ALM process list, not only for the deployment to production but also for any prior phases where the application is exposed to use.
The other issue in accommodating cloud security in ALM is the multiplicity of versions or operating states that applications can be in at a given point. A given software application probably exists in a minimum of two operating states (production and testing) and possibly five or even more states, depending on the complexity of the software change process and the number of test and pre-production phases associated with migrating an application to full production. While it's important that each of these test phases test security as well as application functionality, it's also important that the security processes be as distinct as all of the other version-phased resource sets. It's not desirable to have a single security umbrella spread over all the software ALM phases or there's a risk of testing contaminating production usage.
In fact, the safest route for securing multiple stages or versions of applications in an ALM cycle is to presume that each of the ALM stages or versions (production and testing, for example) have their own application virtual network, and that while the same set of tools and operations processes secures each of these virtual networks, each has its own iteration of those tools and processes. These must be kept as independent of each other as the actual application software versions are kept independent, and for the same reason. Mixing security processes may compromise production application security by accident, or allow users to access test systems when they believe they are using the production version. Most important, security must be an element of ALM for the cloud because virtual resource security simply cannot be managed, or even guaranteed, by traditional network and IT processes that are by their nature tied to fixed resources and devices.
Security isn't the only set of tools and practices that will have to shift from an overall-infrastructure to a per-application focus as applications move from fixed hosting to the cloud, but it's very likely the first and also one of the most important. Given that cloud security issues are the paramount technical barrier to migration of applications to the cloud, it's reasonable to assume that failure to accommodate the new security model in ALM could slow the pace of cloud adoption and reduce overall benefits.
This was first published in October 2012