Top Security Perils When Moving an Application to the Cloud: Infrastructure Set-up

Wrapping up our security peril series, we’ve identified infrastructure set-up / decisions as our fifth peril of forcing applications onto the cloud that weren’t specifically designed for it.

Internally, the application had secure access to authentication databases and content databases, such as product data management systems and ERP systems.  As these systems typically contain confidential content, careful decisions have to be made about these data—which parts should be moved to the cloud and in what form, or can the whole database live on the cloud without risk?  Often times, new and securely implemented login/access procedures are needed.

Follow the discussion on Twitter @hyperguard.

Top Security Perils When Moving an Application to the Cloud: Secure Communication

The third security peril is secure communication, i.e. secure session management or encryption.  Internally, the application had only trusted users, and all communication was trusted in the sense that all other users were no security risk.  However, there is variety of typical web application vulnerabilities that target communication problems, for example, insecure implementations of session management (i.e. insecure session cookies), improper use of encrypted communication (i.e. SSL, key management).  If the application moves to the cloud all relevant aspects of the communication have to be evaluated.  Implementation of secure communication channels have to be done the right way.  This could either be implemented within the application itself by using secure frameworks or in front of the application in a so-called web application firewall.

Follow the discussion on Twitter @hyperguard.

Top Security Perils When Moving an Application to the Cloud: Input Validation

The next security peril we identified is input validation.  Internally, the application had only trusted users who used the application ‘as intended’, and there was not a strong need to validate user input, i.e. in form fields of the application.

The challenge is that there is variety of typical web application vulnerabilities that target weak input validation, including all classes of injection attacks, more commonly SQL injection.  If the application moves to the cloud all input parameters of the application need to be validated.  This could either be implemented within the application itself or in front of the application in a web application firewall.

Follow the discussion on Twitter @hyperguard.

Top Security Perils When Moving an Application to the Cloud: User Management and Authentication

Continuing with our series, we’ve identified user management and authentication as our first security peril.

Internally, the application had only trusted users. Often, internal authentication services, such as, LDAP and Microsoft Active Directory, are based on protected internal databases and used for secure user access and logging of user traffic.

The challenge here is if there has not yet been any user management, solid and secure user management has to be developed and used on the cloud.  However, if the application continues using the current authentication services, the challenge is whether the user’s credentials should be replicated and made available on the cloud—if so, how can this be done in a secure way?  Or should the user access management on the cloud ask in a secure way (i.e. through a VPN tunnel) the internal authentication databases?  Therefore, the user’s credential database does not leave the secure enterprise infrastructure, but the communication with it has to be secure.

Stay tuned for more security perils…

Follow the discussion on Twitter @hyperguard.

Top Security Perils When Moving an Application to the Cloud

Hyperguarding your Web Applications is starting a series of posts showing you the top security perils of forcing applications onto the cloud that weren’t specifically designed for it.

Here’s a typical situation…applications are built from the ground up using programming languages, such as PHP, JAVA or .NET by an internal development team or a third party vendor with the notion of For Internal Use Only in mind.  There is a general assumption by development teams that users can always be trusted, the application will be used ‘as intended’ and all information (i.e. user data) and content (i.e. product data from databases or ERP systems) are coming from safe and secure sources.  Until now, there have never been security issues with applications.

As cloud computing becomes more favorable among companies, they are forcing their applications out of the internal network in to the cloud, causing them to be vulnerable to Web threats.  If the application, or parts of the application, is moved in to the cloud, there will be typically less security within the infrastructure and several more users will be accessing it.  Therefore vulnerabilities turn up and hacks occur.

Every few days we will post typical challenges enterprises face when moving an application to the cloud —so check back often.

Follow the discussion on Twitter @hyperguard.