Cloud application is a highly scalable application deployed on public cloud (shared environment) and can be accessed remotely by end users over the internet. The cloud application benefits from the inherent features of cloud computing like scalability, elasticity, shared resources etc.

Although there are many advantages of using a cloud application, the major concern is the security of the data present outside an organization's premises. This concern hinges on the following facts about cloud computing, which cannot be overlooked:

  1. "Better the devil you know than the devil you don't"
    As cloud computing is the newly introduced model, there is room for uncertainty about security, and the ability of cloud computing to provide protection has come under the scanner.
  2. CSPs lacking promptness
    In the event of some failure, business critical applications should be made available within a short period of time. Failing to do so may result in huge financial losses for the customer. As CSPs (Cloud Service Providers) are handling multiple customers, their readiness to react to such urgency is limited.
  3. CSPs lacking decisiveness
    CSPs are hesitant to disclose the security measures taken at the micro level, fearing that this may open doors for hackers.
  4. EDoS (Economic Denial of Sustainability) Attack
    Scalability is the quality of the cloud computing. The SLA (Service-level Agreement) between the CSP and customer allows the CSP to charge for the extra resource utilization of the application. If a malicious attacker launches a DDoS (Distributed Denial-Of-Service) attack, it may result in consumption of more resources, and the customer has to pay for extra usage as per the SLA. Such DDoS attacks specific to cloud are termed as EDoS.
  5. Cross-Tenant Data Access
    Isolation of multitenant applications is absolutely paramount in this area. The zero-day attack might enable someone to break out of the "sandbox" environment and access other customers’ sensitive data which may ultimately harm the CSPs reputation and business.
  6. Lack of forensic assistance
    With cloud computing, the customer does not have physical access to the media where the data resides. In the event of any security breach, logs and audit trails are often required for forensic investigation. Since this data is maintained by the CSP, auditors face problems in procuring the data governed by the CSP. Also, being multi-tenant in nature, the data belonging to different tenants may reside in the same media and it becomes difficult for CSPs to segregate and provide the data specific to any tenant for forensic purposes.
  7. Insufficient Traditional IDS
    IDS devices have become an integral part of the security architecture for any organization. Both traditional HIDS and NIDS are insufficient to prevent cloud-based attacks as HIDS placed in multitenant environments may degrade the performance of the host on which the application resides, and NIDS placed at strategic network points such as switch or router may not be efficient to handle large data travelling over the network.

Upon this, the question may arise in anybody’s mind that "shall I refrain myself from cloud applications?" The answer is - cloud applications still can be a great alternative for traditional applications, if security requirements are included in each and every stage of the SDLC. Secure SDLC or S-SDLC is a crucial methodology, not just for cloud applications, but any software development.

Here we will discuss the S-SDLC cycle specific to cloud application. Let's try to understand how the security aspect can be incorporated in this cycle.

cloud-security_1
Fig: SDLC Cycle

  1. Requirement Gathering:
    Along with business requirements, requirements related to security should also be gathered in the early stages of the SDLC cycle. Security requirements vary according the nature of the application and the sensitivity of data. Some of the basic requirements include what type of data needs to be protected, what are the isolation measures to be taken in order to prevent cross-tenant access, how to manage privileges, in case of PasS (Platform as a service) what are the security features supported by the platform used for application development, and how to maintain the backup of the data, etc.
  2. Design:
    Cloud applications are comparatively more vulnerable than traditional intranet applications, because of the fact that they are accessible over the internet and hence within the reach of malicious hackers. Hence, it becomes imperative to conduct threat modeling to identify all possible security threats that can harm applications. The actual security testing will be based on these threats. Any particular threat can exploit the application in multiple ways. For example, session hijacking threats can be exploited by cross-site scripting or session fixation or brute forcing session identifier etc. Hence, it is important to list down all possible threats well in advance in order not to miss any vulnerability that may ruin the security posture of the application.
    While designing security architecture for cloud applications, cloud-specific threats should be taken into consideration. For example, in order to prevent EDoS, one can propose to use efficient distributed multi-threaded NIDS or even procuring third party puzzle server for human verification.
  3. Coding:
    This is the most important stage of SDLC from the security perspective as most of the application threats originate from the insecure way of coding: Following secure coding guidelines published by well-known security communities like OWASP, training and encouraging team members to adhere to guidelines. Also, regular static code analysis helps to discover security bugs. Fixing security bugs in this stage is less expensive than later in the development cycle.
  4. Testing:
    Once the coding is finished, the entire application should undergo thorough security testing. It can be carried out by internal staff or via third party. Third party audits give independent opinions about the security posture of the application, highlight unknown vulnerabilities and suggest remedies which help the organization to reduce risk. Most importantly, it gives customers the assurance that the application has been assessed by a neutral auditor.
    Also, fuzz testing or negative testing can be employed by the organization to find out the most vulnerable part of the application quickly. It is a testing methodology which involves sending invalid input values to the application. Vulnerabilities like memory leakage, improper error handling, system crash etc. are commonly found.
  5. Deployment and Sustenance:
    In this last stage, once the application is deployed, network part pertaining to the application should be assessed to discover network level vulnerabilities. Such assessments help in identifying and fixing network level threats. Also, configuration audit of the servers and network devices improves the performance of systems. These audits reduce risks associated with file security, auditing, logging, access control, authentication, and insecure user rights. All these risks can be grouped and termed as "insider threats".
    In the cloud environment, IDS is placed within the CSP’s network and the CSP is solely responsible for sending security alerts whenever any security breach occurs. However, relying on the CSP for getting security alerts can be risky, as the CSP may not inform the customer about security breaches fearing that it may tarnish brand value. In such cases, a neutral third party monitoring service can be employed to bear the responsibility of providing security alerts to the cloud customer.

In a mature development environment, the vulnerabilities are found in early stages and fixed at lower costs, which ultimately results in reducing security breaches. To sum up, organizations that fail to incorporate security in SDLC will have to pay dearly later.

Aujas is now an Amazon Web Services partner, offering robust cloud security services to all businesses hosting applications on Amazon. For more information send an email to apn@aujas.com

References:

  1. Cloud Computing Security Risk Assessment:
    http://www.enisa.europa.eu/activities/risk-management/files/deliverables/cloud-computing-risk-assessment
  2. Secure Coding: Practice steps to defend your web apps:
    http://software-security.sans.org/resources/paper/cissp/defining-understanding-security-software-development-life-cycle
  3. Secure SDLC:
    http://www.sans.org/reading-room/whitepapers/securecode/software-engineering-security-process-sdlc-1846