Introduction

Cloud application developers and devops have been successfully developing applications for IaaS (Amazon AWS,
Rackspace, etc) and PaaS (Azure, Google App Engine, Cloud Foundry) platforms. These platforms provide basic security
features including support for authentication, DoS attack mitigation, firewall policy management, logging, basic user and
profile management but security concerns continue to be the number one barrier for enterprise cloud adoption. Cloud
security concerns range from securely configuring virtual machines deployed on an IaaS platform to managing user
privileges in a PaaS cloud.

Given that the cloud services can be delivered in many flavors i.e. in any combination of service delivery models, SaaS,
PaaS and IaaS (SPI), and operational models, public, private and hybrid, the cloud security concerns and solutions are
context (pattern) dependent. Hence, the solution architecture should match these concerns and build security safeguards
(controls) into the cloud application architecture.

So what are the architectural frameworks and tools that cloud application architects and devops have at their disposal when
developing applications for IaaS and PaaS platforms? In this article, I’ll discuss the approach to baking “adequate” security
into your application deployed in IaaS and PaaS clouds .

Cloud Security – Shared Responsibility

The figure below highlights the layers, within a cloud service, that are secured by the provider versus the customer.

Prior to signing up with a provider, it is important to perform a gap analysis on the cloud service capabilities. This exercise
should benchmark the cloud platform’s maturity, transparency, compliance with enterprise security standards (e.g. ISO
27001) and regulatory standards such as PCI DSS, HIPAA and SOX. Cloud security maturity models can help accelerate the
migration strategy of applications to the cloud. The following are a set of principles you can apply when evaluating a cloud
service provider’s security maturity:
 Disclosure of security policies, compliance and practices: The cloud service provider should demonstrate
compliance with industry standard frameworks such as ISO 27001, SS 16 and CSA Cloud controls matrix. Controls certified
by the provider should match control expectations from your enterprise data protection standard standpoint. When cloud
services are certified for ISO 27001 or SSAE 16, the scope of controls should be disclosed. Clouds that host regulated data
must meet compliance requirements such as PCI DSS, Sarbanes-Oxley and HIPAA.
 Disclosure when mandated: The cloud service provider should disclose relevant data when disclosure is
imperative due to legal or regulatory needs.
 Security architecture: The cloud service provider should disclose security architectural details that either help or
hinder security management as per the enterprise standard. For example, the architecture of virtualization that guarantees
isolation between tenants should be disclosed.
 Security Automation – The cloud service provider should support security automation by publishing API(s)
(HTTP/SOAP) that support:
 Export and import of security event logs, change management logs, user entitlements (privileges),
user profiles, firewall policies, access logs in a XML or enterprise log standard format.
 Continuous security monitoring including support for emerging standards such as Cloud Audit.
 Governance and Security responsibility: Governance and security management responsibilities of the customer
versus those of the cloud provider should be clearly articulated.

Cloud Security Threats and Mitigation

Does cloud computing exacerbate security threats to your application? Which emerging threats are relevant? Which
traditional threats are amplified or muted? Answers to these questions are dependent on the combination of cloud service
deployment and operational models in play. The following table illustrates the dependencies which should be taken into
consideration when architecting security controls into applications for cloud deployments:
  Public/Hybrid Cloud -Threats Private Cloud Mitigation
-Threats
IaaS · OWASP Top 10 · OWASP Top 10 · Testing apps and
API for OWASP
· Data leakage (inadequate ACL) · Data theft (insiders) Top 10
vulnerabilities
· Privilege escalation via · Privilege escalation
management console via management · Hardening of VM
misconfiguration console image
misconfiguration
· Exploiting VM weakness · Security controls
including
encryption, multi-
· DoS attack via API factor
authentication, fine
· Weak protection of privileged keys granular
authorization,
· VM Isolation failure logging

· Security
automation -
Automatic
provisioning of
firewall policies,
privileged
accounts, DNS,
application identity
(see patterns
below)
PaaS [In addition to the above] [In addition to the
above]
· Privilege escalation via API
· Privilege escalation
· Authorization weakness in via API
 platform services such as Message
Queue, NoSQL, Blob services

· Vulnerabilities in the run time

engine resulting in tenant isolation
failure

In addition to the aforementioned threats to information confidentiality and integrity, threats to service availability need to be
factored into the design. Please remember that the basic tenets of security architecture are the design controls that protect
confidentiality, integrity and availability (CIA) of information and services.
Threat to cloud service availability - Cloud services (SaaS, PaaS, IaaS) can be disrupted by DDoS attacks or
misconfiguration errors by cloud service operators or customers. These errors have the potential to cascade across the cloud
and disrupt the network, systems and storage hosting cloud applications. To achieve continuously availability, cloud
applications should be architected to withstand disruptions to shared infrastructure located within a data center or a
geographic region. This vulnerability is best illustrated by the recent Amazon outage when Elastic Block Storage (EBS)
brought down customer applications deployed within a single availability zone in US east region. However, applications that
were architected to tolerate faults within a region were largely shielded from this outage and continued to be available to the
users. As a design principle, assume everything will fail in cloud and design for failure. Applications should withstand
underlying physical hardware failure as well as service disruption within a geographic region. Loose coupling of applications
and components can help in the latter case.

Cloud Security Architecture – Plan

As a first step, architects need to understand what security capabilities are offered by cloud platforms (PaaS, IaaS). The
figure below illustrates the architecture for building security into cloud services.

(Click on the image to enlarge it)

 Security offerings and capabilities continue to evolve and vary between cloud providers. Hence you will often discover that
security mechanisms such as key management and data encryption will not be available. For example: the need for a AES
128 bit encryption service for encrypting security artifacts and keys escrowed to a key management service. For such critical
services, one will continue to rely on internal security services. A “Hybrid cloud” deployment architecture pattern may be the
only viable option for such applications that dependent on internal services. Another common use case is Single Sign-On
(SSO). SSO implemented within an enterprise may not be extensible to the cloud application unless it is a federation
architecture using SAML 1.1 or 2.0 supported by the cloud service provider.

The following are cloud security best practices to mitigate risks to cloud services:
 Architect for security-as-a-service – Application deployments in the cloud involve orchestration of multiple
services including automation of DNS, load balancer, network QoS, etc. Security automation falls in the same category which
includes automation of firewall policies between cloud security zones, provisioning of certificates (for SSL), virtual machine
system configuration, privileged accounts and log configuration. Application deployment processes that depend on security
processes such as firewall policy creation, certificate provisioning, key distribution and application pen testing should be
migrated to a self-service model. This approach will eliminate human touch points and will enable a security as a service
scenario. Ultimately this will mitigate threats due to human errors, improve operational efficiency and embed security controls
into the cloud applications.
 Implement sound identity, access management architecture and practice – Scalable cloud bursting and elastic
architecture will rely less on network based access controls and warrant strong user access management architecture. Cloud
access control architecture should address all aspects of user and access management lifecycles for both end users and
privileged users – user provisioning & deprovisioning, authentication, federation, authorization and auditing. A sound
architecture will enable reusability of identity and access services for all use cases in public, private and hybrid cloud models.
It is good practice to employ secure token services along with proper user and entitlement provisioning with audit trails.
Federation architecture is the first step to extending enterprise SSO to cloud services. Refer to cloud security alliance,
Domain 12 for detailed guidance here.
 Leverage APIs to automate safeguards – Any new security services should be deployed with an API
(REST/SOAP) to enable automation. APIs can help automate firewall policies, configuration hardening, and access control at
the time of application deployment. This can be implemented using open source tools such as puppet in conjunction with the
API supplied by cloud service provider.
 Always encrypt or mask sensitive data – Today’s private cloud applications are candidates for tomorrow’s public
cloud deployment. Hence architect applications to encrypt all sensitive data irrespective of the future operational model.
 Do not rely on an IP address for authentication services – IP addresses in clouds are ephemeral in nature so
you cannot solely rely on them for enforcing network access control. Employ certificates (self-signed or from a trusted CA) to
enable SSL between services deployed on cloud.
 Log, Log, Log – Applications should centrally log all security events that will help create an end-to-end transaction
view with non-repudiation characteristics. In the event of a security incident, logs and audit trails are the only reliable data
leveraged by forensic engineers to investigate and understand how an application was exploited. Clouds are elastic and logs
are ephemeral hence it is critical to periodically migrate log files to a different cloud or to the enterprise data center.
 Continuously monitor cloud services – Monitoring is an important function given that prevention controls may not
meet all the enterprise standards. Security monitoring should leverage logs produced by cloud services, APIs and hosted
cloud applications to perform security event correlation. Cloud audit (cloudaudit.org) from CSA can be leveraged towards this
mission.

Cloud Security Principles

Every enterprise has different levels of risk tolerance and this is demonstrated by the product development culture, new
technology adoption, IT service delivery models, technology strategy, and investments made in the area of security tools and
capabilities. When a business unit within an enterprise decides to leverage SaaS for business benefits, the technology
architecture should lend itself to support that model. Additionally the security architecture should be aligned with the
technology architecture and principles. Following is a sample of cloud security principles that an enterprise security architect
needs to consider and customize:
 Services running in a cloud should follow the principles of least privileges.
 Isolation between various security zones should be guaranteed using layers of firewalls – Cloud firewall, hypervisor
firewall, guest firewall and application container. Firewall policies in the cloud should comply with trust zone isolation
standards based on data sensitivity.
 Applications should use end-to-end transport level encryption (SSL, TLS, IPSEC) to secure data in transit between
applications deployed in the cloud as well as to the enterprise.
 Applications should externalize authentication and authorization to trusted security services. Single Sign-on should
be supported using SAML 2.0.
 Data masking and encryption should be employed based on data sensitivity aligned with enterprise data
classification standard.
 Applications in a trusted zone should be deployed on authorized enterprise standard VM images.
 Industry standard VPN protocols such as SSH, SSL and IPSEC should be employed when deploying virtual private
cloud (VPC).
 Security monitoring in the cloud should be integrated with existing enterprise security monitoring tools using an API.

Cloud Security Architecture Patterns

Architecting appropriate security controls that protect the CIA of information in the cloud can mitigate cloud security threats.
Security controls can be delivered as a service (Security-as-a-Service) by the provider or by the enterprise or by a 3 rd party
provider. Security architectural patterns are typically expressed from the point of security controls (safeguards) – technology
and processes. These security controls and the service location (enterprise, cloud provider, 3 rd party) should be highlighted in
the security patterns.

Security architecture patterns serve as the North Star and can accelerate application migration to clouds while managing the
security risks. In addition, cloud security architecture patterns should highlight the trust boundary between various services
and components deployed at cloud services. These patterns should also point out standard interfaces, security protocols
(SSL, TLS, IPSEC, LDAPS, SFTP, SSH, SCP, SAML, OAuth, Tacacs, OCSP, etc.) and mechanisms available for
authentication, token management, authorization, encryption methods (hash, symmetric, asymmetric), encryption algorithms
(Triple DES, 128-bit AES, Blowfish, RSA, etc.), security event logging, source-of-truth for policies and user attributes and
coupling models (tight or loose).Finally the patterns should be leveraged to create security checklists that need to be
automated by configuration management tools like puppet.

In general, patterns should highlight the following attributes (but not limited to) for each of the security services consumed by
the cloud application:
 Logical location – Native to cloud service, in-house, third party cloud. The location may have an implication on the
performance, availability, firewall policy as well as governance of the service.
 Protocol – What protocol(s) are used to invoke the service? For example REST with X.509 certificates for service
requests.
 Service function – What is the function of the service? For example encryption of the artifact, logging, authentication
and machine finger printing.
 Input/Output – What are the inputs, including methods to the controls, and outputs from the security service? For
example, Input = XML doc and Output =XML doc with encrypted attributes.
 Control description – What security control does the security service offer? For example, protection of information
confidentiality at rest, authentication of user and authentication of application.
 Actor – Who are the users of this service? For example, End point, End user, Enterprise administrator, IT auditor and
Architect.

Here is a subset of the cloud security architecture pattern published by open security architecture group
(opensecurityarchitecturegroup.org).

(Click on the image to enlarge it)

This pattern illustrates the actors (architect, end user, business manager, IT manager), interacting with systems (end point,
cloud, applications hosted on the cloud, security services) and the controls employed to protect the actors and systems
(access enforcement, DoS protection, boundary protection, cryptographic key & management, etc). Let’s look at details
communicated by the pattern.

Infrastructure Security services (controls) at cloud service providers

As per the pattern a cloud service provider is expected to provide security controls for DoS protection and protection of
confidentiality and integrity for sessions originating from Mobile as well as PC. Typically these sessions initiated by browsers
or client applications and are usually delivered using SSL/TLS terminated at the load balancers managed by the cloud
service provider. Cloud service providers usually don’t share the DoS protection mechanisms as hackers can easily abuse it.

Application Security Services (in-house or cloud service provider)

Security services such as user identification, authentication, access enforcement, device identification, cryptographic
services and key management can be located either with the cloud service provider, within the enterprise data center or
some combination of the two.

The second pattern illustrated below is the identity and access pattern derived from the CSA identity domain.

(Click on the image to enlarge it)

 This pattern illustrates a collection of common cloud access control use cases such as user registration, authentication,
account provisioning, policy enforcement, logging, auditing and metering. It highlights the actors (end user, enterprise
business user, third party auditor, cloud service owner) interacting with services that are hosted in the cloud, in-house
(enterprise) and in third party locations.

This pattern communicates the following:

Identity Security services (controls) at cloud service providers

The cloud hosts the following services:
 Authentication service that supports user authentication originating from an enterprise portal (Local AuthN UI) and
typically delivered using SAML protocol. The authenticated session state is maintained in a cloud session store.
 Account and profile provisioning service supports the provisioning of new accounts and user profiles, typically
invoked via SPML (Service Provisioning Markup Language) or a cloud service provider specific API. Profiles are stored in the
user profile store.
 Cloud policy admin service is used for managing policies that dictate which resources in the cloud can be
accessed by end users. Using this service, cloud service owners (enterprise) can perform administrative functions and end
users can request for access to cloud resources. Cloud policies are stored in the cloud policy store.
 Logging and auditing service supports dual functions. The first function is event logging, including security events,
in the cloud and the second is for audit purposes. Cloud Audit protocols and APIs can be employed to access this service.
 Metering service keeps track of cloud resource usage. Finance departments can use this service for charge-back
as well as for billing reconciliation.

Identity Security services in the Enterprise

In this pattern, a subset of the applications is hosted in the enterprise:
 Cloud registration UI provides the UI service for end users to register, manage and provision new cloud resources.
Authentication and Authorization is enforced by the cloud services.
 Cloud usage reporting UI is utilized by end users to generate usage reports.
 Cloud provisioning service is used to provision cloud resources (compute, storage, network, application services).
Access control (AuthN, AuthZ) and session management are enforced at the cloud service end. 

A summary of the security threats and vulnerabilities discussed in Section 4 is presented in Table 1.

Table 1: A Classification of the Security Threats and Vulnerabilities in Cloud Computing

No. Category Security threats and Vulnerability

XML Signature Wrapping Attack
Flooding Attack (DDoS)
Malware Injection Attack
1 Security at Network Level Metadata Spoofing Attack
Insecure Web Applications and APIs
Cross Site Scripting Attack
SQL Injection Attack
Hypervisor Vulnerabilities
VM Escape
VM Sprawl
2 Virtualization Security Cross VM Side Channel
Attack Outdated SW Packages
in VMs Single Point of Failure
VM Image Sprawl
Identity Management
Authentication
3 Identity and Access Management
Authorization & Access Control
Federation
Data Confidentiality
Data Integrity
Data Availability
Data Isolation
4 Data and Storage Security Data Sharing
Data Backup and
Redundancy Data
Sanitization
Data Provenance
Dynamic Data Updates
Improper Data Sanitization
5 Governance Information leakage
Vendor Lockin
Data Location
Contracts and Electronic Discovery
6 Legal and Compliance Issues
Laws and Regulations
Audit Assurance
1 Cloud Computing Challenges
Security and privacy are the two major concerns about cloud computing. In the cloud computing world, the
virtual environment lets user access computing power that exceeds that contained within their physical world. To
enter this virtual environment a user is required to transfer data throughout the cloud. Consequently several security
concerns arises [4] [7] [8] [16].

1.1 Information Security

It is concerned with protecting the confidentiality, integrity and availability of data regardless of the form the
data may take [9].
 - Losing control over data: Outsourcing means losing significant control over data. Large banks don’t want to run a program
delivered in the cloud that risk compromising their data through interaction with some other program [3][10]. Amazon Simple
Storage Service (S3) APIs provide both bucket- and object level access controls, with defaults that only permit authenticated
access by the bucket and/or object creator. Unless a customer grants anonymous access to their data, the first step before a user
can access data is to be authenticated using HMAC-SHA1 signature of the request using the user’s private key [9][15][16].
Therefore, the customer maintains full control over who has access to their data. [13].
- Data Integrity: Data integrity is assurance that data changes only in response to authorized transactions. For example, if the client
is responsible for constructing and validating database queries and the server executes them blindly, the intruder will always be able to
modify the client- side code to do whatever he has permission to do with the backend database. Usually, that means the intruder can
read, change, or delete data at will [3]. The common standard to ensure data integrity does not yet exists [8]. In this new world of
computing users are universally required to accept the underlying premise of trust. In fact, some have conjectured that trust is the
biggest concern facing cloud computing [7].
- Risk of Seizure: In a public cloud, you are sharing computing resources with other companies.. Exposing your data in an
environment shared with other companies could give the government “reasonable cause” to seize your assets because another
company has violated the law. Simply because you share the environment in the cloud, may put data at risk of seizure [4][8]. The only
protection against the risk of seizure for user is to encrypt their data. The subpoena will compel the cloud provider to turn over user’s
data and any access it might have to that data, but cloud provider won’t have user’s access or decryption keys. To get at the data, the
court will have to come to user and subpoena user. As a result, user will end up with the same level of control user have in his private
data center [4][16].
- Incompatibility Issue: Storage services provided by one cloud vendor may be incompatible with another vendor’s services should
you decide to move from one to the other. Vendors are known for creating what the hosting world calls “sticky services” – services
that an end user may have difficulty transporting from one cloud vendor to another. For example, Amazon’s “Simple Storage Service”
[S3] is incompatible with IBM’s Blue Cloud, or Google, or Dell [4][8][13]. Amazon and Microsoft both declined to sign the newly
published Open Cloud Manifesto. Amazon and Microsoft pursue interoperability on their own terms [11][12][14].
- Constant Feature Additions: Cloud applications undergo constant feature additions, and users must keep up to date with
application improvements to be sure they are protected. The speed at which applications will change in the cloud will
affect both the SDLC (Software development life cycle) and security [4][8]. Updates to AWS infrastructure are done
in such a manner that in the vast majority of cases they do not impact the customer and their Service use [9][13] .
AWS communicates with customers, either via email, or through the AWS Service Health Dashboard when there is
a chance that their Service use may be affected [9].
- Failure in Provider’s Security: Failure of cloud provider to properly secure portions of its infrastructure – especially in the
maintenance of physical access control – results in the compromise of subscriber systems. Cloud can comprise multiple entities,
and in such a configuration, no cloud can be more secure than its weakest link [3][7]. It is expected that customer must trust
provider’s security. For small and medium size businesses provider security may exceed customer security. It is generally
difficult for the details that help ensure that the right things are being done [3][7].
- Cloud Provider Goes Down: This scenario has a number of variants: bankruptcy, deciding to take the business in another
direction, or a widespread and extended outage. Whatever is going on, subscriber risk losing access to their production system
due to the actions of another company. Subscriber also risk that the organization controlling subscriber data might not protect it
in accordance with the service levels to which they may have been previously committed [4]. The only option user have is to
chose a second provider and use automated, regular backups, for which many open source and commercial solutions exist, to
make sure any current and historical data can be recovered even if user cloud provider were to disappear from the face of the
earth [4].

1.2 Network Security

Network security measures are needed to protect data during their transmission, between terminal user and
computer and between computer and computer [21][22].

- Distributed Denial of Service (DDOS) Attack: In DDOS attack servers and networks are brought down by a huge amount of
network traffic and users are denied the access to a certain Internet based Service. In a commonly recognized worst-case
scenario, attackers use botnets to perform DDOS. In order to stop hackers to stop attacking the network, subscriber or provider
face blackmail [21][14]. Amazon Web Service (AWS) Application Programming Interface (API) endpoints are hosted on large,
Internet-scale, world-class infrastructure that benefits from the same engineering expertise that has built Amazon into the
world’s largest online retailer. Proprietary DDOS mitigation techniques are used. Additionally, Amazon’s networks are multi-
homed across a number of providers to achieve Internet access diversity [9].
- Man in the Middle Attack: This attack is a form of active eavesdropping in which the attacker makes independent
connections with the victims and relays messages between
them, making them believe that they are talking directly to each other over a private connection when in fact the entire
conversation is controlled by the attacker [21]. All of the AWS APIs are available via SSL-protected endpoints which
provide server authentication. Amazon EC2 AMIs automatically generate new SSH host certificates on first boot and log
them to the instance’s console. Customers can then use the secure APIs to call the console and access the host certificates
before logging into the instance for the first time. Customers are encouraged to use SSL for all of their interactions with
AWS [9].
- IP Spoofing: Spoofing is the creation of TCP/IP packets using somebody else’s IP address. Intruder gain unauthorized access to
computer, whereby he sends messages to a computer with an IP address indicating that the message is coming from a trusted host.
[21][22]. Amazon EC2 instances cannot send spoofed network traffic. The Amazon-controlled, host-based firewall infrastructure
will not permit an instance to send traffic with a source IP or MAC address other than its own [9].
- Port Scanning: If the Subscriber configures the security group to allow traffic from any source to a specific port, then that
specific port will be vulnerable to a port scan. Since a port is a place where information goes into and out of the computer, port
scanning identifies open doors to a computer [21]. There is no way to stop someone from port scanning your computer while you
are on the Internet because accessing an Internet server opens a port which opens a door to your computer [8]. Port scans by
Amazon Elastic Compute Cloud (EC2) customers are a violation of the Amazon EC2 Acceptable use Policy (AUP). Violations of
the AUP are taken seriously, and every reported violation is investigated. Customers can report suspected abuse. When port
scanning is detected it is topped and blocked. Post scans of Amazon EC2 instances are generally ineffective because, by default,
all inbound ports on Amazon EC2 instances are closed and are only opened by the customer [9].
- Packet Sniffing: Packet sniffing by Other Tenants: Packet sniffing is listening (with software) to the raw network device for
packets that interest you. When that software sees a packet that fits certain criteria, it logs it to a file. The most common criteria
for an interesting packet is one that contains words like “login” or “password” [21][22]. It is not possible for a virtual instance
running in promiscuous mode to receive or “sniff” traffic that is intended for a different virtual instance. While customers can
place their interfaces into promiscuous mode, the hypervisor will not deliver any traffic to them that is not addressed to them [9].
Even two virtual instances that are owned by the same customer, located on the same physical host, cannot listen to each other’s
traffic. Attacks such as ARP cache poisoning do not work within Amazon EC2. While Amazon EC2 does provide ample
protection against one customer inadvertently or maliciously attempting to view another’s data, as a standard practice customers
should encrypt sensitive traffic [9]
1.3 Security Issues
They are more complex in a virtualized environment because you now have to keep track of security on two
tiers: the physical host security and the virtual machine security. If the physical host server’s security becomes
compromised, all of the virtual machines residing on that particular host server are impacted. And a compromised
virtual machine might also wreak havoc on the physical host server, which may then have an ill effect on all of the
other virtual machines running on that same host [23].

Instance Isolation: Isolation ensuring that different instances running on the same physical machine are
isolated from each other. Virtualization efficiencies in the cloud require virtual machines from multiple
organizations to be co- located on the same physical resources. Although traditional data center security still applies
in the cloud environment, physical segregation and hardware-based security cannot protect against attacks between
virtual machines on the same server [18]. Administrative access is through the Internet rather than the controlled and
restricted direct or on-premises connection that is adhered to in the traditional data center model. This increase risk
of exposure will require stringent monitoring for changes in system control and access control restriction [8].
Different instances running on the same physical machine are isolated from each other via Xen hypervisor. Amazon
is active in the Xen community, which ensures awareness of the latest developments. In addition, the AWS firewalls
reside within the hypervisor layer, between the physical network interface and the instance’s virtual interface. All
packets must pass through this layer, thus an instance’s neighbors have no more access to that instance than any
other host in the Internet and can be treated as if they are on separate physical hosts. The physical RAM is separated
using similar mechanisms [9].

Host Operating System: Administrators with a business need to access the management plans are required to
us multi-factor authentication to gain access to purpose-built administration hosts. These administrative hosts are
systems that are specifically designed, built, configured, and hardened to protect the management plane of the cloud.
All such access is logged and audited. When an employee no longer has a business need to access the management
plane, the privileges and access to those hosts and relevant systems are revoked [18].

Guest Operating System: Virtual instances are completely controlled by the customer. Customers have full
root access or administrative control over accounts, services, and applications. AWS does not have any access rights
to customer instances and cannot log into the guest OS. AWS recommends a base set of security best practices
including: customer should disable password-based access to their hosts, and utilize some form of multi-factor
authentication to gain access to their instances, or at a minimum certificate-based
SSH Version 2 access [9][13][15]. Additionally, customers should employ a privilege escalation
mechanism with logging on a per-user basis. For example, if the guest OS is Linux, After hardening
their instance, they should utilize certificate- based SSHv2 to access the virtual instance, disable
remote root login, use command-line logging, and use ‘sodu’ for privilege escalation. Customers
should generate their own key pairs in order to guarantee that hey are unique, and not shared with
other customers or with AWS [9]. AWS Multi- Factor Authentication (AWS MFA) is an additional
layer of security that offers enhanced control over AWS account settings. It requires a valid six-digit,
single-use code from an authentication device in your physical possession in addition to your standard
AWS account credentials before access is granted to an AWS account settings. This is called Multi-
Factor Authentication because two factors are checked before access is granted to your account:
customer need to provide both their Amazon email-id and password (the first “factor”: something you
know) AND the precise code from customer authentication device (the second “factor”: something
you have).

1.4 General Security Issues

In addition to the above mentioned issues there are few other general security issues that are
delaying cloud computing adoption and needs to be taken care of.

Data Location: When user uses the cloud, user probably won’t know exactly where his data is
hosted, what country it will be stored in [3][4][8]? Amazon does not even disclose where their data
centers are located. They simply clam that ach data center is hosted in a nondescript building with a
military-grade perimeter. Even if customer know that their database server is in the us-east-1a
availability zone, customer do not know where that data center9s0 behind that availability zone is
located, or even which of he three East Coast availability zones us-east-1a represents [4].

Data Sanitization: Sanitization is the process of removing sensitive information from a storage
device. In cloud computing users are always concerned about, what happens to data stored in a cloud
computing environment once it has passed its user’s “use by date” [18]. When a storage device has
reached the end of its useful life, AWS procedures include a decommissioning process that ensures
customer data are not exposed to unauthorized individuals. AWS uses the technique DoD 5220.22-M
as per National Industrial Security Program Operating manual to destroy data, as part of the
decommissioning process [9][13]. When item and attribute data are deleted within a domain, removal
of the mapping within the domain starts immediately, and is also generally complete within seconds.
Once the mapping is removed, there is no remote access to the deleted data. The storage area is then
made available only for write operations and the data are overwritten by newly stored data [9].
 Job Starvation due to some virus or worm: It is where one job takes up a huge amount of
resource resulting in a resource starvation for the other jobs. Customer can reserve the resources
in advance. Customer can also reduce the priority of the affected tasks/job [16] [18].

In the next section of our paper we discuss about the various cloud related working groups
and their contribution in the cloud computing environment.