Security practitioners by now realize that securing applications in the cloud is an important endeavor. And there...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
are a variety of approaches organizations have taken to do this.
Many organizations now include security provisions in contractual negotiations they have with service providers. Depending on the usage, they might supplement that with an assessment that they or another performs.
For example, they might conduct an assessment of the service provider's environment, they might send them a questionnaire or some other data gathering instrument, or they might leverage an assurance registry, such as the Cloud Security Alliance Security, Trust and Assurance Registry program, to gather data about countermeasures and security operations.
Likewise, specific controls that are designed to operate in a cloud environment -- tools like cloud access security brokers (CASBs), secure tunnels, gateways and other measures -- can form part of an organization's cloud security strategy.
However, despite the time and effort that most organizations have spent ensuring the security for applications in the cloud is robust, there is often a blind spot -- specifically, custom applications.
Custom applications, those that are either built on a platform as a service (PaaS) environment or those that are developed internally and fielded into an infrastructure as a service (IaaS) environment, have a different set of challenges than software as a service (SaaS) applications.
In the case of SaaS, the service provider is typically responsible for the security of the application itself and the entirety of the stack below it. In the case of custom applications, though, the cloud service provider can't assume that every application every customer wants to host with them has the same set of security requirements and requires the same controls. As such, providers offer a stock set designed to work in most circumstances and for most apps. It is up to the organization deploying the application into that environment to provide the necessary security measures.
Custom application challenges
There are a few challenges that can arise as a result of this. First, an organization can't have a throw it over the wall mentality. The security of the application needs to be systematically addressed the same way that it would address the security requirements and countermeasures for an application it hosts in an on-premises data center. An organization can't just assume that the appropriate security measures will magically be there because the application is now in an IaaS or PaaS application instead of being in an on-premises environment.
Secondly, existing controls, such as a CASB, that have been put in place to make sure that SaaS applications are protected, may not necessarily extend to applications they build themselves -- at least, not without accounting for it ahead of time. For example, consider a CASB that uses a reverse proxy strategy to enable the organization to encrypt or tokenize specific fields on a remote SaaS application. In that case, because the CASB doesn't know the specific fields that will be in use for the custom application, you may find that using that control to provide that same level of support for your custom app is either impracticable or difficult to accomplish.
Lastly, it is not always the case that the application you are fielding will be one that was developed with cloud in mind. Consider legacy applications that you might move to an IaaS provider as you consolidate or reduce your internal technology footprint. You might have controls below the application layer that are designed to offset specific types of risks -- and that work in the context of an on-premises data center -- but that might not be there or work the same way in a cloud context.
What can be done?
The question for security organizations then becomes how they can ensure that they apply the appropriate security measures for an app regardless of who authors that application (themselves or a service provider), and regardless of the environment to which it is deployed. Fortunately, there are a few measures that can help in this regard.
First and foremost, a reliable inventory of which applications are where in the cloud environment can be a lifesaver, and should include both the environment that the app is fielded in (cloud or otherwise), as well as information about the application and contact points. That sounds easy, but in practice, it can be more difficult than you'd think.
Keep in mind that an application can be on premises, in a hybrid cloud, in an IaaS or PaaS application, or can reside in different environments depending on context; for example, an application that bursts to the cloud when demand is high. Likewise, the application can be on a virtual host, in an application container -- and, in some cases, both -- or in a PaaS application.
If you don't have an inventory already, initiating a discovery activity to find out which applications are being used by business teams -- including the custom ones that might be in play -- is a useful starting point. With an inventory in hand, you can systematically take stock to make sure that you're addressing security across the whole application ecosystem.
Once you have a good idea of what you have out there, a next step might be to integrate a more formal method of analyzing those applications from a risk standpoint, using a tool such as application threat modeling.
Threat modeling has a few advantages, in that it can leverage design artifacts that you might already have; for example, if you have sequence diagrams, interaction diagrams, web service maps, data flow maps, or other documentation to illustrate how the application interacts with its various components. Analyzing the application in this way enables you to see what possible threats the application might need to be resilient against and can help you map out the specific countermeasures that you'd employ to mitigate those issues.
The goal here is not to get to 100% coverage out of the gate. Instead, start slowly and build, beginning with applications that are more critical, more sensitive or that might be in a blind spot relative to the operation of other controls that are in place.
Either way, it is important to keep in mind that custom applications in the cloud need to be protected in just the same way that other applications are. Moreover, because the application controls that you might have in place for other third-party cloud apps might not perform the same way for a custom application that you develop, it's particularly important that security considerations be thought through and examined systematically.
Learn how to choose the right cloud app development platform
Discover how to strategically implement CASBs
Find out why cloud isn't always the answer when it comes to apps