Application Security on Cloud-The cloud model has motivated industry and academia to adopt cloud computing to host a wide spectrum of applications ranging from high computationally intensive applications down to light weight services.
Developers and IT departments are being told they need to move applications to the cloud and are often left on their own to navigate the challenges related to developing and managing the security of applications in those environments.
What’s more important and elemental is to examine if the web application being used is more vulnerable because of the way it was built, and then deployed in the cloud – versus focusing on cloud security risks from an environmental or infrastructure perspective.
Lack of visibility with respect to resources in cloud computing can create a number of security and compliance issues. Security questions can span from whether information transferred between systems in the cloud is safe, to what type of data is best stored in the cloud, to how do I control who accesses my data?
In addition to the usual challenges of developing secure IT systems, cloud computing presents an added level of risk because essential services are often outsourced to a third party. Cloud computing shifts control over data and operations from premise to their cloud providers. The security problem becomes more complicated under the cloud model as new dimensions have entered into the problem scope related to the model architecture, multi-tenancy, elasticity, and layers dependency stack. Cloud computing is available in SPI model stack which is SaaS, PaaS, IaaS and each presents different levels of responsibility for security management.
Cloud Computing security is fundamentally about three goals/objectives:
CIA – Confidentiality Integrity and Availability
- Confidentiality (C): Confidentiality refers to keeping data private.
- Integrity (I): Integrity is a degree confidence that the data in the cloud is what is supposed to be there, and is protected against accidental or intentional alteration without authorization.
- Availability (A): It refers to availability of Information.
How different is this from application security in the traditional enterprise/non-cloud environment? Of course, with the cloud you have the additional aspect of shared or outsourced environment.
Traditional security or transport layer security is performed at the physical, link, Network and transport layer, commonly known as layers 1-4. There are a number of technologies used to secure these layers such as FWs, intrusion detection/prevention, encryption, anti-virus etc.. This security is ok, when an application is inward facing, typically used on an organizations intranet that can only be access by internal employees and possibly business partners, depending on how that security is set up, such as a federation.
When an application is outward facing or being put in a cloud solution, message layer security performed at the session, presentation and application layers (layers 5-7) in addition to traditional security should be required. End to end solution meaning that access control and payload are secured from the requester to requestee.
While it is true that traditional application security issues still apply in the cloud, and that you still need to take advantage of established processes associated with requirements, design, and implementation and testing, organizations can’t simply repackage what they know about application security. Applications in the cloud require special care. IT teams can’t be content to use mitigation techniques only at the network or operating system level anymore.
It’s imperative to understand the inherent (and non-storied) threats facing applications in virtualized environments. Common vulnerabilities associated with multi-tenancy and cloud provider services, like identity and access management, must be examined from both a security and compliance perspective.
Organizations lose control over physical network or computing systems, even local storage for debugging and logging is remote. Additionally, auditors may be concerned about the fact that the cloud provider has access to sensitive data at rest and in transit.
Inherent threats are not only present in the virtualized deployment environment, but also in the way applications for the cloud are developed in the first place. Consider the choices many architects and designers are forced to make when it comes to developing and deploying applications in the cloud. Because they are now in a position where they are relying on external controls put in place by the provider, they may feel comfortable taking short cuts when it comes to building in application security features.
“Cloud security is not bad, it is just different”. It seems that what we hear a lot is the word “uncertainty“which can be translated into actual meaning “I don’t know how?”.
As opposed to traditional internal application infrastructures, in the cloud the trust boundary shrinks down to encompassing only the application itself, with all the users and related storage, database and identity management systems becoming “external” to that application. In this situation, “trust no one” takes on great significance to the IT organization. With all these external sources wanting access to the application, how do you know what request is legitimate? How can we make up the lack of trust? It boils down to establishing an additional layer of security controls. Organizations must encrypt all sensitive data stored or transmitted and treat all environmental inputs as untrusted in order to protect assets from attackers and the cloud provider itself.
Best practices aimed at building protection must be incorporated into the development process to minimize risks. How can you help applications become more secure? It starts with a seatbelt – in the form of application level security controls that can be built into application code or implemented by the cloud services provider itself.
Examples of these controls can include encryption at rest, encryption in transit, point-to-point and message contents, auditing and logging, or authentication and authorization.
In an IaaS environment, it may not be an option to have the provider manages these controls.
Using PaaS APIs to establish these controls, for example, is that in most cases the service provider has tested and debugged the API to speed time to market for the application.
In SaaS environments offer no choice to the developer, as the SaaS provider will be totally in control of how data is secured and identity managed.
Each environment, IaaS, PaaS or SaaS, requires its own checklist to ensure the applications are ready for prime time.
Security testing must be done at the application level, not the environmental level. Threat modeling and design phases need to take additional cloud environmental risks into account. And, implementation needs to use cloud security aware coding patterns in order to effectively eliminate vulnerability classes such as Cross-Site Scripting (XSS) and SQL Injections. Standards such as OWASP Top 10 and CWE/SANS Top 25 are still applicable for testing IaaS and PaaS applications, and many SaaS extensions.
The following security measures represent cloud security areas to be concerned about.
Security Areas in Cloud Computing
- Build and maintain a secure cloud infrastructure.
Ø Implement N/W security
Ø Implement virtualization security
Ø Ensure physical security
- Ensure confidential data protection.
- Implement strong access and identity management.
We need to understand over here:
“The service model may adjust the defined roles & responsibilities in collaborative information security governance and risk management (based on the respective scope of control for user and provider).”
“The deployment model may define accountability and expectations (based on risk assessment).”