Unit 5th Securing the Cloud

Cloud Security Fundamentals

Cloud evolution can be considered synonymous to banking system evolution. Earlier people used to
keep all their money, movable assets (precious metals, stones etc.) in their personal possessions and
even in underground lockers as they thought that depositing their hard earned money with bank can be
disastrous. Banking system evolved over the period of time. Legal and security process compliances
protected by Law played a big role in making banking and financial systems trustworthy. Now, people
hardly keep any cash with them. Most of us carry plastic money and transact digitally. Cloud computing
is also evolving the same way.

Robust cloud architecture with strong security implementation at all layers in the stack powered with
legal compliances and government protection is the key to cloud security. As Banks didn’t vanish
despite frauds, thefts and malpractices, cloud security is going to get evolved but as much faster rate.
Digital world has zero tolerance for waiting! Evolution is natural and is bound to happen.

Cloud is complex and hence security measures are not simple too. Cloud needs to be secured at all
layers in its stack. Let’s briefly look into major areas.

At infrastructure level: A sysadmin of the cloud provider can attack the systems since he/she has got all the
admin rights. With root privileges at each machine, the sysadmin can install or execute all sorts of
software to perform an attack. Furthermore, with physical access to the machine, a sysadmin can
perform more sophisticated attacks like cold boot attacks and even tamper with the hardware.

Protection measures:

1. No single person should accumulate all these privileges.

2. Provider should deploy stringent security devices, restricted access control policies, and surveillance
mechanisms to protect the physical integrity of the hardware.

3. Thus, we assume that, by enforcing a security processes, the provider itself can prevent attacks that
require physical access to the machines.

4. The only way a sysadmin would be able to gain physical access to a node running a costumer’s VM
is by diverting this VM to a machine under his/her control, located outside the IaaS’s security perimeter.
Therefore, the cloud computing platform must be able to confine the VM execution inside the
perimeter, and guarantee that at any point a sysadmin with root privileges remotely logged to a machine
hosting a VM cannot access its memory.

5. TCG (trusted computing group), a consortium of industry leader to identify and implement security
measures at infrastructure level proposes a set of hardware and software technologies to enable the
construction of trusted platforms suggests use of “remote attestation” (a mechanism to detect changes to
the user’s computers by authorized parties).
At Platform level:

Security model at this level relies more on the provider to maintain data integrity and availability.
Platform must take care of following security aspects:

1. Integrity

2. Confidentiality

3. Authentication

4. Defense against intrusion and DDoS attack

5. SLA

At Application level:

The following key security elements should be carefully considered as an integral part of the
SaaS application development and deployment process:
1. SaaS deployment model

2. Data security

3. Network security

4. Regulatory compliance

5. Data segregation

6. Availability

7. Backup/Recovery Procedure

8. Identity management and sign-on process

Most of the above are provided by PaaS and hence optimal utilization of PaaS in modeling SaaS
is very important.
Some of the steps which can be taken to make SaaS secured are:

• Secure Product Engineering

• Secure Deployment

• Governance and Regulatory Compliance Audits

• Third-Party SaaS Security Assessment

At Data level:

Apart from securing data from corruption and losses by implementing data protection mechanism at
infrastructure level, one needs to also make sure that sensitive data is encrypted during transit and at
rest.
 Apart from all the above measures, stringent security process implementation should also be part of
making cloud secure. Periodic audits should happen. Governing security laws should be amended with
advent in technologies, ethical hacking and vulnerability testing should be performed to make sure the
cloud is secure across all layers.

Cloud Security Services :-

loud security is a collection of procedures and technology designed to address external and internal
threats to business security. Organizations need cloud security as they move toward their digital
transformation strategy and incorporate cloud-based tools and services as part of their infrastructure.

Security Design Principles:-

There are six design principles for security in the cloud:

1.Implement a strong identity foundation:

Implement the principle of least privilege and enforce separation of duties with the
appropriate authorization for each interaction with your AWS resources. Centralize
privilege management and reduce or even eliminate reliance on long-term credentials.

2.Enable traceability:
Monitor, alert, and audit actions and changes to your environment in real -time.
Integrate logs and metrics with systems to automatically respond and take action.

3.Apply security at all layers:

Rather than just focusing on protecting a single outer layer, apply a defense-in-depth
approach with other security controls. Apply to all layers, for example, edge network,
virtual private cloud (VPC), subnet, load balancer, every instance, operating system,
and application.

4.Automate security best practices:

Automated software-based security mechanisms improve your ability to securely scale
more rapidly and cost-effectively. Create secure architectures, including the
implementation of controls that are defined and managed as code in version -controlled
templates.

5.Protect data in transit and at rest:

Classify your data into sensitivity levels and use mechanisms, such as encryption and
tokenization where appropriate. Reduce or eliminate direct human access to data to
reduce the risk of loss or modification.

6. Prepare for security events:

 Prepare for an incident by having an incident management process that aligns with
your organizational requirements. Run incident response simulations and use tools
with automation to increase your speed for detection, investigation, and recovery.

cloud security challenges.

1: DDoS and Denial-of-Service Attacks

As more and more businesses and operations move to the cloud, cloud providers are becoming a
bigger target for malicious attacks. Distributed denial of service (DDoS) attacks are more common
than ever before. Verisign reported IT services, cloud platforms (PaaS) and SaaS was the most
frequently targeted industry during the first quarter of 2015.

A DDoS attack is designed to overwhelm website servers so it can no longer respond to legitimate
user requests. If a DDoS attack is successful, it renders a website useless for hours, or even days.
This can result in a loss of revenue, customer trust and brand authority.

Complementing cloud services with DDoS protection is no longer just good idea for the enterprise;
it’s a necessity. Websites and web-based applications are core components of 21st century business
and require state-of-the-art cybersecurity.

2: Data breaches

Known data breaches in the U.S. hit a record-high of 738 in 2014, according to the Identity Theft
Research Center, and hacking was (by far) the number one cause. That’s an incredible statistic and
only emphasizes the growing challenge to secure sensitive data.

Traditionally, IT professionals have had great control over the network infrastructure and physical
hardware (firewalls, etc.) securing proprietary data. In the cloud (in all scenarios including private
cloud, public cloud, and hybrid cloud situations), some of those security controls are relinquished
to a trusted partner meaning cloud infrastructure can increase security risks. Choosing the right
vendor, with a strong record of implementing strong security measures, is vital to overcoming this
challenge.

3: Data loss

When business critical information is moved into the cloud, it’s understandable to be concerned
with its security. Losing cloud data, either through accidental deletion and human error, malicious
tampering including the installation of malware (i.e. DDoS), or an act of nature that brings down a
cloud service provider, could be disastrous for an enterprise business. Often a DDoS attack is only
a diversion for a greater threat, such as an attempt to steal or delete data.
To face this challenge, it’s imperative to ensure there is a disaster recovery process in place, as well
as an integrated system to mitigate malicious cyberattacks. In addition, protecting every network
layer, including the application layer (layer 7), should be built-in to a cloud security solution.

4: Insecure access control points

One of the great benefits of the cloud is it can be accessed from anywhere and from any device.
But, what if the interfaces and particularly the application programming interfaces (APIs) users
interact with aren’t secure? Hackers can find and gain access to these types of vulnerabilities and
exploit authentication via APIs if given enough time.

A behavioral web application firewall examines HTTP requests to a website to ensure it is

legitimate traffic. This always-on device helps protect web applications and APIS from security
breaches within cloud environments and data centers that are not on-premises.

5: Notifications and alerts

Awareness and proper communication of security threats is a cornerstone of network security and
the same goes for cloud computing security. Alerting the appropriate website or application
managers as soon as a threat is identified should be part of a thorough data security and access
management plan. Speedy mitigation of a threat relies on clear and prompt communication so steps
can be taken by the proper entities and impact of the threat minimized.
Overcoming Challenges

In general, what can be done to improve cloud security? Always follow the best security practices
whether you are a tenant or a provider, such as tracking new vulnerabilities and attacks against
components of your cloud. If you are a cloud provider, do background research on entities that wish to
join your environment.

If you are a tenant, always understand your cloud model and compensate for any weaknesses inherent in
that type. Be sure to support TLS 1.2 access. This ensures stronger cryptography and is the latest secure
protocol for connections to Web servers.

Both providers and tenants should institute regular vulnerability scanning as frequently as is feasible.
They should also lock IP addresses so only authorized networks are able to access your cloud or site. If
this is not possible as a provider, then be sure to employ strong authentication and access controls.

As a provider, make logs relevant to your tenants available. This complements the tenant’s own
logging.

As a tenant, make sure all software is up to date. PaaS providers need to do the same with their
environments. In one of the most important measures, tenants must encrypt data. This is critical for data
protection, but be sure to implement cryptography correctly. There are solutions available to minimize
the ciphertext reduplication problem.
Cloud Security Architecture

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 3rd 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, 3rd 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 figure 4.1:

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.
Y User Security and Monitoring
o
u Identity Services AuthN/Z Federation, delegation, provisioning
r

R Supporting Services-Auditing Super user privilege management

e
s
p
o
n Information Security Data
s
i Encryption (transist, reset, processing), Key management, ACL, Logging
b
i
l
i
t
y
i
l Network- Level (BGP, Load balancers, Firewall, Security monitoring)
i
t
y

Figure: 4.1 Cloud Security Architecture

Threats to the Cloud

The first and most dangerous threat in any IT system is the insider threat. It’s especially hard to defend
against because users, and particularly administrators, have usually been granted some degree of trust.
Technological countermeasures can usually be circumvented if the user has the right level of access.
This is why it is critical for organizations to have an efficient off boarding process so that disgruntled
released employees do not have access to the systems.

Side-channel threats occur when an attacker has the ability to obtain information from another tenant’s
node by measuring some side effect of the system’s use. These have been popularized in the research
community but, to IBM X-Force’s knowledge; have not been seen in the real world.

Perhaps the most dangerous real-world threat is the loss of authority over the cloud control interface.
We aren’t talking about the provisioning portal but rather the administrative interface of your
enterprise’s cloud. Think of it as a control console for your cloud nodes.

In the right situation, this can lead to a complete loss of integrity, confidentiality and availability. Note
that the attack here is against the interface’s Web server, or a cross-site scripting (XSS) or cross-site
request forging (CS‘F) attack against the administrator’s Web browser.

Make sure the interface’s Web server is up to date and that the interface does not have any XSS or
CSRF vulnerabilities. These are just good security practices in general and are not unique to the cloud.
If you use SSO, be sure your security assertion markup language (SAML) implementation follows the
recommended specification.

Additionally, use two-factor authentication. Note that this is good practice for restricting access to any
sensitive servers and data.

Additional Risks to Cloud Environments

There is a somewhat rare attack called virtual host confusion. It is often seen with content delivery
networks and shared platform-as-a-service (PaaS) clouds. This attack can allow for server
impersonation under the right circumstances. Once again, the X-Force team is not aware of this being
exploited in the wild. For more information, read the paper “Network-based Origin Confusion Attacks
against HTTPS Virtual Hosting.”

This attack is from the same group that identified Logjam, FREAK, SLOTH and others. To prevent this
attack, never use certificates for more than one domain. Avoid using wildcard certificates and carefully
configure TLS caching and ticketing parameters to be different for every Web server. Finally, make sure
your domain fallback page is an error page.
Shared data and computations on shared (typically off-premises) clouds can be exposed in the right
circumstances. This particularly applies to MapReduce operations. To prevent this leakage, consider
dedicated clouds, where there is a lesser chance of malicious actors having a presence.

Never make the mistake of assuming that on-premises or dedicated clouds need not be secured
according to industry best practices. These clouds are often considered a more valuable target by
attackers.

Finally, there is shadow IT, or the inability of IT to monitor the activities of the user. This happens when
the user’s client is connected to a cloud with an encrypted connection. In that case, the user can interact
with the cloud and perhaps perform unauthorized actions. To combat this, consider federating. Monitor
your logs to see which applications are in use and use a proxy to intercept cloud traffic. You can also
use an analytics engine and create relevant rules at your endpoint device.

Legal Issues in Cloud :-

These are major issues in Cloud Computing:

1. Privacy: The user data can be accessed by the host company with or without
permission. The service provider may access the data that is on the cloud at any point
in time. They could accidentally or deliberately alter or even delete information.

2. Compliance: There are many regulations in places related to data and hosting. To
comply with regulations (Federal Information Security Management Act, Health
Insurance Portability and Accountability Act, etc.) the user may have to adopt
deployment modes that are expensive.

3. Security: Cloud-based services involve third-party for storage and security. Can
one assume that a cloud-based company will protect and secure one’s data if one is
using their services at a very low or for free? They may share users’ information with
others. Security presents a real threat to the cloud.

4. Sustainability: This issue refers to minimizing the effect of cloud computing on

the environment. Citing the server’s effects on the environmental effects of cloud
computing, in areas where climate favors natural cooling and renewable electricity is
readily available, the countries with favorable conditions, such as Finland, Sweden,
and Switzerland are trying to attract cloud computing data centers. But other than
nature’s favors, would these countries have enough technical infrastructure to sustain
the high-end clouds?
 5. Abuse: While providing cloud services, it should be ascertained that the client is
not purchasing the services of cloud computing for a nefarious purpose. In 2009, a
banking Trojan illegally used the popular Amazon service as a command and control
channel that issued software updates and malicious instructions to PCs that were
infected by the malware So the hosting companies and the servers should have
proper measures to address these issues.
data security in cloud computing :-
Cloud data security is the combination of technology solutions, policies, and procedures that you
implement to protect cloud-based applications and systems, along with the associated data and user
access.

The core principles of information security and data governance—data confidentiality, integrity, and
availability (known as the CIA triad)—also apply to the cloud:

Confidentiality: protecting the data from unauthorized access and disclosure

Integrity: safeguard the data from unauthorized modification so it can be trusted
Availability: ensuring the data is fully available and accessible when it’s needed
These tenets apply regardless of:

Which cloud model you adopt—public, private, hybrid, or community clouds

Which cloud computing categories you use—software-as-a-service (SaaS), platform-as-a-service
(PaaS), infrastructure-as-a service (IaaS), or function-as-a-service (FaaS)
You need to consider data security during all stages of cloud computing and the data lifecycle: from
development, deployment, or migration of applications and systems, to the management of the cloud
environment.

Cloud Disaster Recovery

Get maneuverability by shifting the provision of expensive recovery infrastructure to the cloud.
We provide proven recovery scenarios of your applications to secure Virtual Private Clouds (VPCs)
with our Cloud Recovery Service in all available AWS regions worldwide. Your regular cloud
backups guarantee the most current data state. We take care of the adjustments of the complete
scenario, guarantee recovery point objectives (RPOs) and recovery time objectives (RTOs), and
the safety and ease of use of the Cloud Recovery environment. The best: We adapt the Cloud
Recovery if your application environments or your disaster recovery requirements change over
time. This complete Cloud Recovery Service consists of part services that you can make use of
individually:
Cloud Recovery Consultation and Implementation: Analysis of Cloud Recovery scenarios,
determining the resource and performance requirements, design and implementation of
recovery scripts.
Automated Application Tests: Regular automated checking the serviceability of the Cloud
Recovery scenarios.
The Cloud Recovery Services - whether booked individually or as a whole - can be used for
example for:
2-stage Cloud Recovery for all application environments of your company: while the
restore takes place into the data center, quickly restore to a temporary cloud environment.
Forks of the production environment for testing, simulations, expert opinions or reproduction of
transactions outside the production environment.
Recovery environments for critical communications infrastructure such as email, important documents
(SharePoint, file servers), chat and video / audio conferencing .

Service-level agreements (SLAs)

 Service-level agreements (SLAs) are a focal point of negotiations, contract terms, legal obligations,
and runtime metrics and measurements.
 SLAs formalize the guarantees put forth by cloud providers, and correspondingly influence or
determine the pricing models and payment terms.
 SLAs set cloud consumer expectations and are integral to how organizations build business
automation around the utilization of cloud-based IT resources.
 The guarantees made by a cloud provider to a cloud consumer are often carried forward, in that the
same guarantees are made by the cloud consumer organization to its clients, business partners, or
whomever will be relying on the services and solutions hosted by the cloud provider.
 It is therefore crucial for SLAs and related service quality metrics to be understood and aligned
support of the cloud consumer’s business requirements, while also ensuring that the guarantees can,
in fact, be realistically fulfilled consistently and reliably by the cloud provider.
 The latter consideration is especially relevant for cloud providers that host shared IT
resources for high volumes of cloud consumers, each of which will have been issued its own SLA
guarantees.
 A Service Level Agreement (SLA) is the bond for performance negotiated between the cloud
services provider and the client. Earlier, in cloud computing all Service Level Agreements were
negotiated between a client and the service consumer. Nowadays, with the initiation of large utility-
like cloud computing providers, most Service Level Agreements are standardized until a client
becomes a large consumer of cloud services. Service level agreements are also defined at different
levels which are mentioned below:
Customer-based SLA
Service-based SLA
Multilevel SLA

 Few Service Level Agreements are enforceable as contracts, but mostly are agreements or contracts
which are more along the lines of an Operating Level Agreement (OLA) and may not have the
restriction of law. It is fine to have an attorney review the documents before making a major
agreement to the cloud service provider. Service Level Agreements usually specify some parameters
which are mentioned below:
Availability of the Service (uptime)
Latency or the response time
Service components reliability
Each party accountability
Warranties

In any case, if a cloud service provider fails to meet the stated targets of minimums then the
provider has to pay the penalty to the cloud service consumer as per the agreement. So, Service
Level Agreements are like insurance policies in which the corporation has to pay as per the
agreements if any casualty occurs.
Microsoft publishes the Service Level Agreements linked with the Windows Azure Platform
components, which is demonstrative of industry practice for cloud service vendors. Each individual
component has its own Service Level Agreements. Below are two major Service Level Agreements
(SLA) described:

Windows Azure SLA –

Window Azure has different SLA’s for compute and storage. For compute, there is a guarantee that
when a client deploys two or more role instances in separate fault and upgrade domains, client’s
internet facing roles will have external connectivity minimum 99.95% of the time. Moreover, all of
the role instances of the client are monitored and there is guarantee of detection 99.9% of the time
when a role instance’s process is not runs and initiates properly.

SQL Azure SLA –

SQL Azure clients will have connectivity between the database and internet gateway of SQL Azure.
SQL Azure will handle a “Monthly Availability” of 99.9% within a month. Monthly Availability
Proportion for a particular tenant database is the ratio of the time the database was available to
customers to the total time in a month. Time is measured in some intervals of minutes in a 30-day
monthly cycle. Availability is always remunerated for a complete month. A portion of time is
marked as unavailable if the customer’s attempts to connect to a database are denied by the SQL
Azure gateway.
Service Level Agreements are based on the usage model. Frequently, cloud providers charge their
pay-as-per-use resources at a premium and deploy standards Service Level Agreements only for that
purpose. Clients can also subscribe at different levels that guarantees access to a particular amount
of purchased resources. The Service Level Agreements (SLAs) attached to a subscription many
times offer various terms and conditions. If client requires access to a particular level of resources,
then the client need to subscribe to a service. A usage model may not deliver that level of access
under peak load condition.

CLOUD SECURITY AND TRUST MANAGEMENT

Cloud Security Defense Strategies Basic Cloud Security:-

Three basic cloud security enforcements are expected. First, facility security in data centers
demands on-site security year round. Biometric readers, CCTV (close-circuit TV), motion detection,
and man traps are often deployed.
network security demands fault-tolerant external firewalls, intrusion detection systems (IDSes), and
third-party vulnerability assessment.
Finally, platform security demands SSL and data decryption, strict password policies, and system
trust certification.

A security-aware cloud architecture demands security enforcement. Malware-based attacks such as

network worms, viruses, and DDoS attacks exploit system vulnerabilities. These attacks
compromise system functionality or provide intruders unauthorized access to critical information.
Here are some cloud components that demand special security protection:

• Protection of servers from malicious software attacks such as worms, viruses, and malware
• Protection of hypervisors or VM monitors from software-based attacks and vulnerabilities
• Protection of VMs and monitors from service disruption and DoS attacks
• Protection of data and information from theft, corruption, and natural disasters
• Providing authenticated and authorized access to critical data and services

Privacy and Copyright Protection

Here are several security features desired in a secure cloud
• Dynamic web services with full support from secure web technologies
• Established trust between users and providers through SLAs and reputation systems
• Effective user identity management and data-access management
• Single sign-on and single sign-off to reduce security enforcement overhead
• Auditing and copyright compliance through proactive enforcement
• Shifting of control of data operations from the client environment to cloud providers
• Protection of sensitive and regulated information in a shared environment