Towards Cloud-Aware Vulnerability Assessments - IEEE Computer ...

2015 11th International Conference on Signal-Image Technology & Internet-Based Systems

Towards Cloud-Aware Vulnerability Assessments Kennedy A Torkura and Christoph Meinel Chair of Internet Technologies and Systems Hasso Plattner Institute, University of Potsdam Potsdam, Germany Email: {kennedy.torkura, christoph.meinel}@hpi.de

Abstract—Vulnerability assessments are best practices for computer security and requirements for regulatory compliance. Potential and existing security holes can be identified during vulnerability assessments and security breaches could be averted. However, the unique nature of cloud computing environments requires more dynamic assessment techniques. The proliferation of cloud services and cloud-aware applications introduce more cloud vulnerabilities. But, current measures for identification, mitigation and prevention of cloud vulnerabilities do not suffice. Our investigations indicate a possible reason for this inefficiency to lapses in availability of precise, cloud vulnerability information. We observed also that most research efforts in the context of cloud vulnerability concentrate on IaaS, leaving other cloud models largely unattended. Similarly, most cloud assessment efforts tackle general cloud vulnerabilities rather than cloud specific vulnerabilities. Yet, mitigating cloud specific vulnerabilities is important for cloud security. Hence, this paper proposes a new approach that addresses the mentioned issues by monitoring, acquiring and adapting publicly available cloud vulnerability information for effective vulnerability assessments. We correlate vulnerability information from public vulnerability databases and develop Network Vulnerability Tests for specific cloud vulnerabilities. We have implemented, evaluated and verified the suitability of our approach. Index Terms—Cloud security, cloud vulnerabilities, vulnerability assessment

I. I NTRODUCTION Security remains a key decision factor for migrating resources to the cloud [1], several enterprises are hesitant to adopt cloud technologies because of perceived security uncertainties. Innovative measures are continually developed to improve cloud security, yet new vulnerabilities emerge daily. One reason for this trend could be the concentration of mitigative efforts on IaaS. Though, virtualization and other technologies like web services form the core of cloud computing, several building blocks are integral to Software as a Service (SaaS) and Platform as a Service (PaaS). Furthermore, the impression that Cloud Service Providers (CSPs) bear responsibility for these other cloud models is erroneous and as much as 40 percent of cloud users have this wrong impression[2]. In order to clear this confusion, CSPs introduced the Shared Security Responsibility Model (SSRM) which clearly shows the areas of security responsibilities for all cloud stakeholders. The model also permits clients to use several security tools and processes that are similar to those used for on-premise infrastructure such as security audits and vulnerability assessments. 978-1-4673-9721-6/15 $31.00 © 2015 IEEE DOI 10.1109/SITIS.2015.63

746746

Vulnerability assessments are best practices for cloud security [3] and are required for regulatory compliance especially for enterprises that employ cloud-based services. Vulnerability assessments employ vulnerability scanners which in turn depend on credible and timely vulnerability information from various sources including software vendors and third party sources. We surveyed the availability of cloud vulnerability information at the National Vulnerability Database (NVD) and third party vulnerability information repositories and discovered a shortage of information. Even if currently available information suffices for general cloud vulnerabilities, more accurate information is requisite for mitigating cloud specific vulnerabilities. The implications of this deficiency worsens with the current upsurge of cloud-aware application which leverage on deep integration [4] with cloud technologies. In order to breach this concern, we propose an approach that monitors, collects, processes and integrates vulnerability information from NVD and security advisories/bulletins of CSPs. We designed and developed a prototype of our approach called Cloud Aware Vulnerability Assessment System (CAVAS), and used Amazon Web Services (AWS) as a case study. However, other CSPs can be easily integrated into the system. Our approach is suitable for both general cloud vulnerabilities and cloud-specific vulnerabilities. It provides a platform for the development of a knowledge base for cloud vulnerabilities. To the best of our knowledge, this is the first work that considers the suitability of available open vulnerability data for automated cloud vulnerability assessment and gives practical approaches to mitigating cloud specific vulnerabilities. Our major contributions are as follows: • Realistic data analysis of publicly available cloud vulnerability information. • Proposal of a framework for conducting vulnerability assessments for both general cloud vulnerabilities and cloud specific vulnerabilities. • Extension of Open Vulnerability Assessment System (OpenVAS) for cloud vulnerability assessment through the development of Network Vulnerability Tests (NVTs) specifically targeting cloud applications and environments. • Inclusion of information extracted from CSP security advisories and bulletins for vulnerability scanning tests rather than the normal reliance on NVD. The rest of this paper is organized as follows : in next section,

we discuss the changing cloud vulnerabilities landscape particularly as it affects cloud specific vulnerabilities, cloud-aware applications and SSRM. Thereafter, an appraisal of available public cloud vulnerabilities information is done in Section III. Consequent of cloud vulnerability information gaps outlined in the preceding section, we introduce and give implementation details of our proposed approach in Section IV. An evaluation of our implementation is done in Section V while related works are discussed in Section VI. Highlights of future research directions and our conclusion are at Sections VII and VII respectively. II. T HE DYNAMICS OF C LOUD V ULNERABILTIES In this section, we discuss the changing cloud vulnerabilities landscape and how it affects vulnerability assessments. Cloud models are rapidly maturing, unfortunately this growth comes with new security threats and vulnerabilities. Traditional security methods do not effectively tackle these security concerns [5] hence the need for more dynamic techniques. Possible mitigative approaches consists in having robust understanding of these new vulnerabilities especially cloud specific vulnerabilities. Similarly, the kind of vulnerabilities emerging from cloud-aware applications ought to be investigated since they are also cloud specific. Another important concept which could potentially ensure secure cloud environments is the SSRM. We correlate the above mentioned concepts in the following subsections. A. Cloud Specific Vulnerabilities Cloud specific vulnerabilities are distinct from general vulnerabilities affecting the cloud. Grobauer [6] identified four indicators of cloud specific vulnerabilities. We briefly discuss these indicators below and show the relevance of our work to these vulnerabilities. 1) Intrinsic to or prevalent in a core cloud computing technology: Generally these kinds of vulnerabilities are those that form the core of cloud computing model. Examples are web applications, virtualization technologies and cryptographic schemes. Although several research efforts[1] [7] and implementations provide approaches for identifying and resolving vulnerabilities in this category, some gaps remain. One example is that of Amazon Linux [8] vulnerabilities. Most cloud virtualization technologies are based on Linux distributions, and vulnerability assessment approaches for Linux OS is quite mature. But, Amazon Linux is a new Linux distribution only available on Elastic Computing Cloud (EC2) platform. There is scarcely any research on security vulnerabilities specific to Amazon Linux and most vulnerability scanners identify it wrongly as RedHat Linux or CentOS. However, just like other Linux distributions, Amazon Linux has both general and specific vulnerabilities. Vulnerabilities inherited from the Linux kernel or affecting one or more Linux distributions would be classified as a general vulnerability, while those affecting only Amazon Linux could be classified as cloud-specific.

747747

2) Root cause in one of NIST’s essential cloud characteristics: The National Institute of Standards and Technology (NIST) described five essential characteristics of cloud computing [9] including on-demand self service, ubiquitous network access, resource pooling, rapid elasticity and measured service. The nature of the cloud results to specific vulnerabilities in these characteristics such as unauthorized access to management interfaces, metering/billing evasion and data recovery vulnerabilities. Practical vulnerabilities in this category are those resulting from cloud services such Amazon ElasticCache [10] which is designed for rapid deployment and scaling of in-memory databases on AWS. 3) Cloud innovations that make a tried and tested security control difficult: Security controls which have been proven effective in traditional networks do not necessarily suffice in the cloud. Vulnerabilities arising from this effect are known as ”control challenges”. A typical example is the inability of cloud subscribers to scan their virtual environments without requesting for authorization from the providers. Another example is the difference in definition and implementation of Demilitarized Zone (DMZ)-based security [11]. 4) Prevalence in the established state-of-the-art cloud offering: Cloud computing is rapidly growing alongside its enabling technologies. Some of these technologies are a hybrid of existing technologies, while others are novel. For example, several databases used in traditional applications such as MySQL and noSQL are now hosted as managed services in the cloud. CSPs also offer proprietary databases such as Amazon DynamoDB [12] and Google Datastore [13]. These innovative services introduce vulnerabilities which could either be traditional like SQL injection and commend injection or could even be new variants. However, there are rarely vulnerability assessments suited for these kinds of vulnerabilities. Our work produces a first step in identifying and eliminating these kinds of vulnerabilities. B. Understanding Cloud-Aware Applications Cloud-aware applications are applications built to fully optimize the advantages of the cloud [4] such as scalability and elasticity. They differ from normal cloud applications in that while traditional cloud applications are built normally and thereafter deployed on cloud platforms, cloud-aware applications are developed with the cloud in mind using cloud design patterns. Similarly, they differ from multi-tier applications deployed on cloud infrastructure in several areas such as dynamic discovery rather than static IP addressing and port numbers assignments. Encryption of data and use of APIs are some characteristics of cloud-aware applications. Cloud-aware applications are capable of identifying the cloud environment on which they are deployed. Enabling these capability requires tight integration with cloud platforms and by implication closer reliance on the core cloud architectures. This development opens opportunities for vulnerabilities which are [14] mostly specific to the cloud. To illustrate this scenario, let us imagine a cloud-aware application deployed on an Amazon Linux image with DynamoDB as its database, AWS ElasticCache for in-memory caching and AWS Elastic Load Balancing for

fault tolerance. This setting exemplifies a simple cloud-aware application, however several security holes could emerge from any of the technologies interacting with the application. Such vulnerabilities are consequent of the innovative nature of the cloud and hence cloud specific. Adequate vulnerability assessment for these kinds of vulnerabilities is an open question. C. Shared Security Responsibility Model The Shared Security Responsibility Model [15] is widely adopted by CSPs. It aims at defining and sharing security responsibilities between cloud customers and service providers. CSPs are responsible for securing host operating systems, physical infrastructures and virtualization layer e.t.c. On the other hand, customers take responsibility for security of virtual images/operating systems, configuration of logical network security devices like firewalls and hardening of access control schemes. Customers are also permitted to consolidate security with security processes and tools like resource monitoring tools, vulnerability assessment and access control. The SSRM clarifies areas of confusion especially for cloud managed applications like databases and resource monitoring tools. While CSPs handles tasks like launching and replication of managed databases, customers are responsible for securing these databases with encryption, credentials security and access control. Cloud-aware applications are deeply integrated into cloud managed services and by implication exposed to similar cloud specific vulnerabilities. Cloud vulnerability assessments are useful for aiding customers effectively perform their responsibilities, for example unprotected access to a managed cloud-based database could be identified through a vulnerability assessment exercise. III.

PUBLICLY AVAILABLE INFORMATION FOR CLOUD VULNERABILITY ASSESSMENTS

The main focus of vulnerability assessment is to identify existing or potential security holes in any system, rank discovered vulnerabilities in order of severity and perform remediation. Automated or semi-automated scanners are utilized for assessments, common vulnerability scanners include OpenVAS, Nessus and Nexpose. Vulnerability scanners are capable of identifying installed software, security configurations and analyzing existence of security flaws. However, a great deal of this capability relies on knowledge-base derived majorly from public vulnerability information repositories especially the NVD. The information acquired from these sources is used to add signatures of specific vulnerabilities to plugins that perform the actual scanning operations. Integration of information from third party databases was a common practice in the past but dependence on NVD has increased in recent years since almost all discovered and verified vulnerabilities are published at NVD. However, several researchers have shown the inaccuracy of information hosted at NVD [16] [17] [18] and the need to include information from other sources. Similarly, our investigations indicate that the NVD has insufficient information for effective cloud vulnerability assessments.

748748

Most security incidences in the cloud are consequent of unpatched or undiscovered security vulnerabilities exploited by malicious hackers. For example CVE 2014-2019 1 was exploited by hackers to compromise iCloud last year owing to one or more of the above mentioned reasons. A report on the statistical overview of cloud vulnerability incidents [19] by Cloud Security Alliance (CSA) revealed that CSPs are not very transparent in disclosing vulnerabilities. Consequently, few cloud vulnerabilities are published by the CSPs and much less published at NVD. However, rather than entirely relying on either of these sources, a better approach could be employment of a system that monitors and integrates vulnerability information from multiple these sources and other relevant sources. Enterprises are recommended to monitor vulnerabilities from at least the following sources ; • • • •

Provider security sources. Vendor security sources. Third Vulnerability databases e.g. NVD Other party vulnerability sources such as black market exploit sources.

Fig. 1: A Graph Showing Publicly Available Data on AWS Vulnerabilities. In order to have empirical results on cloud vulnerability information, we conducted an analysis of vulnerability entries for AWS at three popular vulnerability information sources :NVD, Open Source Vulnerability Database (OSVDB) and Exploit-DB and realized an inadequacy of available information. We used AWS as a case study since several cloud industry reports [20] attest to their leading position in the cloud landscape. We also compared the results of our investigation with the vulnerabilities disclosed by AWS, the details of the surveys are: • NVD: Considering the period between 2009 and 2015, out 71,780 vulnerabilities published at the NVD, only 11 directly refer to AWS. • OSVDB: At the OSVDB [21], 37 vulnerabilities were published concerning Amazon between 2005 and 2015. But only 11 of these concerned AWS, the other 26 refereed to Amazon retail services. 2 1 https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-1426 2 https://www.amazon.com/gp/gw/ajax/s.html

• Exploit-DB : The Exploit-DB [22] is a Common Vulnerabilities and Exposures (CVE) compliant online archive for vulnerable applications, exploits and proof-of-concept vulnerabilities. We discovered only 16 vulnerabilities affecting Amazon, again most of them referred to Amazon retail services, only 2 vulnerabilities directly referred to AWS. • AWS: We investigated the vulnerabilities publicly disclosed at AWS, we discovered that 543 security advisories and bulletins were released between 2009 and 2015. The afore-mentioned statistics (Fig.1) reveal a lack of sufficient data publicly available for cloud vulnerability assessments. The information at AWS greatly surpasses other sources and provides more specific information for applications deployed on the platform. Other sources also contain huge amounts of information which are also useful for assessing traditional applications in the cloud however information at the CSPs is imperative for cloud-specific vulnerability assessments. This further demonstrates the need for an approach that concisely combines vulnerability information from multiple sources for accurate assessments.

vulnerabilities. Hence, in order to suit our framework we extend the functionality of OpenVAS by developing our custom NVTs. NVTs are developed using Nessus Attack Scripting Language (NASL), a scripting language originally developed for the Nessus vulnerability scanner. We assigned severity ratings for NVTs based on OpenVAS scoring guidelines for NVT development. Generally, OpenVAS employs the base metrics of the Common Vulnerability Scoring System (CVSS). Similarly, AWS security advisories conform to CVSS hence assigning severity ratings for custom NVTs was standardized. Our custom NVTs are added to the OpenVAS cache. Most components of CAVAS are implemented in Java programming language, scanning requests are configured and initiated from the Central Management Server (CMS), and passed to the scanning module. One key advantage of using our CMS is to automate scanning operations and to remotely manage several scanners installed on remote machines. In the next paragraphs, we briefly explain the architecture of CAVAS, which is comprehensively represented by Fig.3. A. Vulnerability Information Gatherer The Vulnerability Information Gatherer crawls information from the NVD and AWS security bulletins/advisories. AWS provides security information about their proprietary software and third party applications via bulletins and advisories. Though the crawlers are capable of pulling information in various formats, we prefer XML via Really Good Syndication (RSS) feeds since this provides a better structured format. We exclude unwanted tags and retain the information in separate MongoDB databases for further processing.

IV. I MPLEMENTATION OF P ROPOSED F RAMEWORK – CAVAS

Fig. 2: High Level Architecture of CAVAS In the this section we present the implementation of our proposed framework called CAVAS(Fig.2). Owing to insufficiency of precise cloud vulnerability information in public repositories, a more deliberate and dynamic approach towards vulnerability assessments for cloud environments is imperative. CAVAS monitors, gathers and correlates vulnerability information from NVD and AWS security advisories and bulletins, additional CSPs can be easily integrated into the system. We integrate OpenVAS [23] scanning engine into CAVAS for the actual vulnerability scanning. OpenVAS is a popular open source vulnerability scanner consisting of several tools suitable for vulnerability management. It employs NVTs or plugins for vulnerability scanning of target systems. There are currently about 40,627 NVTs employed for detection of installed software, software versions and specific vulnerabilities. However OpenVAS like other vulnerability scanners relies on vulnerability information from NVD majorly, we realized that NVTs are not currently developed for AWS

749749

Fig. 3: Detailed Architecture of CAVAS

B. Vulnerability Information Processor The Vulnerability Information Processor intelligently retrieves information from the local NVD and CSPs databases for processing. Firstly, the collected information is harmonized into

a specific format and then duplicate entries are eliminated. Duplicate elimination is done by checking vulnerability description and related CVEs. Thereafter, the information is passed unto the central database from where it is exposed on our public web client for cloud vulnerabilities. At the same time, the vulnerability information processor cross-matches the processed vulnerabilities against the local OpenVAS NVT cache. The aim of this step is to identify those vulnerabilities which already have NVTs developed or assigned to them. Tickets for custom NVT development are automatically generated for unmatched vulnerabilities. C. Central Management Server The CMS is implemented in Java, it is the hub of CAVAS. All activities including scan configuration, target selection, scheduled scanning and scan reports generation are configured and managed from the CMS. The CMS leverages on OpenVAS Management Protocol (OMP) for interaction with the OpenVAS scanner. The OMP provides an XML-based communication platform for communicating with third party systems. Other tasks such as report generation, are handled at the CMS. D. Scanner Module Rather than implementing our scanning engine, we leverage on OpenVAS scanner which supports third party integration [24] through OMP Application Programming Interface (API) [25]. OpenVAS has a modular structure including OpenVAS scanner, OpenVAS manager and OpenVAS Command Line Interface (CLI). OpenVAS scanner is the core of the entire system and functions well with third party systems. It synchronizes NVTs from OpenVAS central repository and the local NVT cache. We hope to integrate other scanning engines e.g. Nessus in the future as this could reduce possibilities of false positives and false negatives. E. NVT Update Alerting System The NVT Update Alerting System is a feature for sending alerts to users whenever NVTs are developed for previously ticketed vulnerabilities. This alert is helpful so that users can repeat the same scans for better results. Alerts could be configured for email delivery or as pop-ups on the user interface. V. E VALUATION We evaluated CAVAS with several cloud-aware web applications deployed on t2-micro Amazon Linux image and t2micro Ubuntu image. Amazon Linux images are pre-installed with various packages and configurations suitable for tight integration with AWS while Ubuntu images come bare. We alternated the databases for the applications between AWS Relational Database Service (RDS), DynamoDB and MySQL. All databases were configured for access from within EC2 as well as on our local system using the AWS CLI. AWS CLI provides an interaction interface for several services hosted on the AWS platform. We conducted a series of vulnerability scanning tests against the web applications using CAVAS and OpenVAS. CAVAS correctly identified AWS Linux installation

750750

TABLE I: Summary of Comparison between CAVAS and OpenVAS Cloud Applications CAVAS OpenVAS

Amazon Linux

Ubuntu

DynamoDB

Amazon RDS

MySQL

Identified Correctly Identified Wrongly

Identified Correctly Identified Correctly

Identified Correctly Not Identified

Identified Correctly Not Identified

Identified Correctly Identified Correctly

as well as the RDS versions (Table .1). OpenVAS wrongly detected the same Amazon Linux (as CentOS) and could not detect RDS installation. We connected the web applications to our DynamoDB and again CAVAS detected it while OpenVAS scanner could not detect it. A comparison of our scanning results between CAVAS and OpenVAS is at Table 1. From these results, we deduce that CAVAS produces more accurate scanning results for cloud applications. An evaluation for false positives and false negatives was not conducted. VI. R ELATED W ORK Several works have focused on identification, mitigation and prevention of cloud vulnerabilities. In [26], the authors introduced VULCAN, a framework for modeling vulnerabilities using ontological approaches such as semantic natural language processing. Their approach is different from ours, we carry a more realistic analysis on a real cloud system. Bleikertz et al [1] conducted an intensive assessment of AWS EC2 focusing on the reachability and vulnerability of the virtual machines, their assessments were however more concerned with Infrastructure as a Service (IaaS). Balduzzi et al’s security analysis of Amazon EC2 images [27] discovered serious security and privacy violations in these public images. More recently another empirical study on prevalent vulnerabilities in IaaS used Amazon cloud as a case study [28]. The authors employed game theory and risk gain analysis to demonstrate that the cost of attacking and defending cloud resources is cheaper than in traditional computing networks. Most of the existing work in the assessment of cloud vulnerabilities have focused on IaaS, however there are vulnerabilities in SaaS and PaaS which do not ultimately fall under the responsibility of service providers, this is reflected in the SSRM. Our work is applicable across all cloud computing models defined by NIST [9] and especially tackles cloud specific vulnerabilities. The closest work to ours was by Suftario et al [29], in which vulnerability information was similarly integrated to have better vulnerability assessments. However, this work tackles vulnerabilities in traditional systems and not cloud systems. VII. F UTURE W ORK CSPs are not transparent in disclosing vulnerabilities in their services [19], hence an interesting research direction could be predictive vulnerability analysis for zero-day cloud vulnerabilities and application of vulnerability discovery methods in the context of cloud computing. Similarly, cloud based vulnerability assessments could be a useful research direction,

for example deploying CAVAS client/sensors within AWS. We hope to extend the functionality of CAVAS in the future by adding more vulnerability scanners as this could reduce the possibilities of false positives and false negatives. Also, we hope to conduct extensive tests to benchmark performance and vulnerability detection rates for CAVAS especially against larger cloud environments as this could be a more realistic use-case for enterprises. Our custom NVTs will eventually be committed to the central OpenVAS NVT repository as a contribution to the open source community. We also hope to extend the functionality of CAVAS by including more CSPs. VIII. C ONCLUSION This paper discussed the current challenge of effective vulnerability assessments in the cloud, especially for cloud-specific vulnerabilities and cloud-aware applications. We observed that most cloud computing vulnerability research focus on IaaS, but PaaS and SaaS are also important for cloud security. These cloud models are becoming more important as cloud adoption increases and cloud-aware applications gets proliferated. Cloudaware applications are designed to fully derive the advantages offered by the cloud, and this requires closer integration and dependence on cloud services such as managed cloud-based services. More cloud specific threats and vulnerabilities are emerging owing to this integration. Also, the responsibilities of cloud users which is clearly defined in the SSRM shows that users have greater responsibilities than the general perception. Cloud vulnerability assessments are fundamental to fulfillment of these security responsibilities. But, our findings reveal availability gaps in cloud vulnerability information which is imperative for effective vulnerability assessments. Hence, we propose a framework for comprehensive cloud vulnerability assessments. Our approach monitors, acquires and correlates cloud vulnerability information from NVD and CSPs. The information is thereafter employed for developing suitable NVTs for our proposed CAVAS. Though our work focused on AWS, we believe that our findings are applicable to other other cloud providers. R EFERENCES [1] S. Bleikertz, M. Schunter, C. W. Probst, D. Pendarakis, and K. Eriksson, “Security audits of multi-tier virtual infrastructures in public infrastructure clouds,” in Proceedings of the 2010 ACM Workshop on Cloud Computing Security Workshop, ser. CCSW ’10. New York, NY, USA: ACM, 2010, pp. 93–102. [Online]. Available: http://doi.acm.org/10.1145/1866835.1866853 [2] HP, “The case for a cloud access security broker.” [Online]. Available: http://www.hp.com/hpinfo/newsroom/press kits/2015/RSA2015/ TheCaseForaCloudAccessSecurityBrokerAPR2015 4AA5-8064ENW.pdf [3] CSA, SecaaS Implementation Guidance Category 5 : Security Assessments, Cloud Security Alliance, 2012. [Online]. Available: https://downloads.cloudsecurityalliance.org/initiatives/secaas/ SecaaS Cat 5 Security Assessments Implementation Guidance.pdf [4] O. D. C. Alliance, Best Practices: Architecting Cloud-Aware Applications Rev. 1.0. [Online]. Available: https://www.opendatacenteralliance.org/ advanced-search-and-tools/advanced-search/best-practices-papers/ whitepapers/architecting-cloud-aware-applications-whitepapers

751751

[5] K. Hashizume, D. G. Rosado, E. Fern´andez-Medina, and E. B. Fernandez, “An analysis of security issues for cloud computing,” Journal of Internet Services and Applications, vol. 4, no. 1, pp. 1–13, 2013. [6] B. Grobauer, T. Walloschek, and E. Stocker, “Understanding cloud computing vulnerabilities,” IEEE Security & Privacy, vol. 9, no. 2, pp. 50–57, 2011. [7] H.-Y. Tsai, M. Siebenhaar, A. Miede, Y.-L. Huang, and R. Steinmetz, “Threat as a service?: virtualization’s impact on cloud security,” IT professional, no. 1, pp. 32–37, 2011. [8] [Online]. Available: https://aws.amazon.com/amazon-linux-ami/ [9] The NIST Definintion of Cloud Computing, NIST, 2011. [Online]. Available: http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145. pdf [10] [Online]. Available: https://aws.amazon.com/elasticache/ [11] L. M. Kaufman, “Can public-cloud security meet its unique challenges?” IEEE Security & Privacy, vol. 8, no. 4, pp. 55–57, 2010. [12] [Online]. Available: https://aws.amazon.com/dynamodb/ [13] [Online]. Available: https://cloud.google.com/datastore/ [14] IBM, “Develop secure cloud-aware applications.” [Online]. Available: http://www.ibm.com/developerworks/ cloud/library/cl-develop-secure-cloud-aware-applications/ cl-develop-secure-cloud-aware-applications-pdf.pdf [15] “Amazon web services: Overview of security processes,” Amazon Whitepaper, November 2014. [Online]. Available: https: //media.amazonwebservices.com/pdf/AWS Security Whitepaper.pdf [16] S. Zhang, D. Caragea, and X. Ou, “An empirical study on using the national vulnerability database to predict software vulnerabilities,” in Database and Expert Systems Applications. Springer, 2011, pp. 217–231. [17] V. H. Nguyen and F. Massacci, “The (un)reliability of nvd vulnerable versions data: An empirical experiment on google chrome vulnerabilities,” in Proceedings of the 8th ACM SIGSAC Symposium on Information, Computer and Communications Security, ser. ASIA CCS ’13. New York, NY, USA: ACM, 2013, pp. 493–498. [Online]. Available: http://doi.acm.org/10.1145/2484313.2484377 [18] W. M. Fitzgerald and S. N. Foley, “Avoiding inconsistencies in the security content automation protocol,” in Communications and Network Security (CNS), 2013 IEEE Conference on. IEEE, 2013, pp. 454–461. [19] CSA, Cloud Computing Vulnerability Incidents: A Statistical Overview. [Online]. Available: https://downloads.cloudsecurityalliance. org/initiatives/cvwg/CSA Whitepaper Cloud Computing Vulnerability Incidents.zip [20] “Experts forecast the 2015 cloud computing market,” online. [Online]. Available: http://searchcloudcomputing.techtarget.com/feature/ Experts-forecast-the-2015-cloud-computing-market [21] [Online]. Available: http://osvdb.org/ [22] [Online]. Available: https://www.exploit-db.com/about/ [23] [Online]. Available: http://www.openvas.org/index.html [24] Greenbone Security Manager. [Online]. Available: http://docs.greenbone. net/GSM-Manual/gos-3.1/en/ [25] [Online]. Available: http://www.greenbone.net/technology/omp.html [26] P. Kamongi, S. Kotikela, K. Kavi, M. Gomathisankaran, and A. Singhal, “Vulcan: Vulnerability assessment framework for cloud computing,” in Software Security and Reliability (SERE), 2013 IEEE 7th International Conference on, June 2013, pp. 218–226. [27] M. Balduzzi, J. Zaddach, D. Balzarotti, E. Kirda, and S. Loureiro, “A security analysis of amazon’s elastic compute cloud service,” in Proceedings of the 27th Annual ACM Symposium on Applied Computing, ser. SAC ’12. New York, NY, USA: ACM, 2012, pp. 1427–1434. [Online]. Available: http://doi.acm.org/10.1145/2245276.2232005 [28] S. Zhang, X. Zhang, and X. Ou, “After we knew it: empirical study and modeling of cost-effectiveness of exploiting prevalent known vulnerabilities across iaas cloud,” in Proceedings of the 9th ACM symposium on Information, computer and communications security. ACM, 2014, pp. 317–328. [29] R. H. Yap and L. Zhong, “A machine-oriented integrated vulnerability database for automated vulnerability detection and processing.”