KEMBAR78
Module 2 - Security Concepts | PDF | Cloud Computing | Computer Network
0% found this document useful (0 votes)
40 views12 pages

Module 2 - Security Concepts

Uploaded by

Sarthak Gupta
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
40 views12 pages

Module 2 - Security Concepts

Uploaded by

Sarthak Gupta
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 12

CBE 321– Cloud Computing

and Security
Dr. E.Silambarasan
Assistant Professor
Department of CSE - Cyber Security
Indian Institute of Information Technology, Kottayam
Security Concepts:
Infrastructure Security: Network Level
• If you choose to use public cloud services, changing security requirements will
require changes to your network topology.
• You must address how your existing network topology interacts with your cloud
provider’s network topology.
• There are four significant risk factors in this use case:
• Ensuring the confidentiality and integrity of your organization’s data-in-transit
to and from your public cloud provider
• Ensuring proper access control (authentication, authorization, and auditing) to
whatever resources you are using at your public cloud provider
• Ensuring the availability of the Internet-facing resources in a public cloud that
are being used by your organization, or have been assigned to your organization
by your public cloud providers
• Replacing the established model of network zones and tiers with domains
Infrastructure Security: Network Level
Ensuring Data Confidentiality and Integrity
• Some resources and data previously confined to a private network are now exposed
to the Internet, and to a shared public network belonging to a third-party cloud
provider.
• An example of problems associated with this first risk factor is an Amazon Web
Services (AWS) security vulnerability reported in December 2008.
• In a blog post, the author detailed a flaw in the digital signature algorithm used
when “... making Query (aka REST) requests to Amazon SimpleDB, to Amazon Elastic
Compute Cloud (EC2), or to Amazon Simple Queue Service (SQS) over HTTP.”
• Although use of HTTPS (instead of HTTP) would have mitigated the integrity risk,
users not using HTTPS (but using HTTP) did face an increased risk that their data
could have been altered in transit without their knowledge.
Infrastructure Security: Network Level
Ensuring Proper Access Control
• Since some subset of these resources (or maybe even all of them) is now exposed to
the Internet, an organization using a public cloud faces a significant increase in risk
to its data.
• The ability to audit the operations of your cloud provider’s network (let alone to
conduct any real time monitoring, such as on your own network), even after the fact,
is probably non-existent.
• You will have decreased access to relevant network-level logs and data, and a limited
ability to thoroughly conduct investigations and gather forensic data.
Infrastructure Security: Network Level
Ensuring Proper Access Control
• An example of the problems associated with this second risk factor is the issue of
reused (reassigned) IP addresses.
• Generally speaking, cloud providers do not sufficiently “age” IP addresses when they
are no longer needed for one customer.
• Addresses are usually reassigned and reused by other customers as they become
available.
• From a cloud provider’s perspective this makes sense.
• IP addresses are a finite quantity and a billable asset. However, from a customer’s
security perspective, the persistence of IP addresses that are no longer in use can
present a problem.
• A customer can’t assume that network access to its resources is terminated upon
release of its IP address.
Infrastructure Security: Network Level
Ensuring Proper Access Control
• There is necessarily a lag time between the change of an IP address in DNS and the
clearing of that address in DNS caches.
• There is a similar lag time between when physical (i.e., MAC) addresses are changed
in ARP tables and when old ARP addresses are cleared from cache; an old address
persists in ARP caches until they are cleared.
• This means that even though addresses might have been changed, the (now) old
addresses are still available in cache, and therefore they still allow users to reach
these supposedly non-existent resources.
• Recently, there were many reports of problems with “non-aged” IP addresses at one
of the largest cloud providers; this was likely an push for an AWS announcement of
the Amazon
• Elastic IP capabilities in March 2008.† (With Elastic IP addresses, customers are
given a block of five routable IP addresses over which they control assignment.
Infrastructure Security: Network Level
Ensuring Proper Access Control
• However, the issue of “non-aged” IP addresses and unauthorized network access to resources
does not apply only to routable IP addresses (i.e., resources intended to be reachable directly
from the Internet).
• The issue also applies to cloud providers’ internal networks for customer use and the
assignment of non-routable IP addresses.
• Although your resources may not be directly reachable from the Internet, for management
purposes your resources must be accessible within the cloud provider’s network via private
addressing. (Every public/Internet facing resource also has a private address.)
• Other customers of your cloud provider may not be well intentioned and might be able to
reach your resources internally via the cloud provider’s networks.
• As reported in The Washington Post, AWS has had problems with abuses of its resources
affecting the public and other customers.
• Some products emerging onto the market will help alleviate the problem of IP address reuse,
but unless cloud providers offer these products as managed services, customers are paying
for yet another third-party product to solve a problem that their cloud provider’s practices
created for them.
Infrastructure Security: Network Level
Ensuring the Availability of Internet-Facing Resources
• Trust on network security has increased because an increased amount of data or an
increased number of organizational personnel now depend on externally hosted
devices to ensure the availability of cloud-provided resources.
• Consequently, the three risk factors enumerated in the preceding section must be
acceptable to your organization.
• BGP prefix hijacking (i.e., the falsification of Network Layer Reachability Information)
provides a good example of this third risk factor.
• Prefix hijacking involves announcing an autonomous system address space that
belongs to someone else without her permission.
• Such announcements often occur because of a configuration mistake, but that
misconfiguration may still affect the availability of your cloud-based resources.
Infrastructure Security: Network Level
Ensuring the Availability of Internet-Facing Resources
• According to a study presented to the North American Network Operators Group
(NANOG) in February 2006, several hundred such misconfigurations occur per month.
• Probably the best known example of such a misconfiguration mistake occurred in
February 2008 when Pakistan Telecom made an error by announcing a dummy route
for YouTube to its own telecommunications partner, PCCW, based in Hong Kong.
• The intent was to block YouTube within Pakistan because of some supposedly
blasphemous videos hosted on the site.
• The result was that YouTube was globally unavailable for two hours.
Infrastructure Security: Network Level
Ensuring the Availability of Internet-Facing Resources
• In addition to misconfigurations, there are deliberate attacks as well.
• Although prefix hijacking due to deliberate attacks is far less common than
misconfigurations, it still occurs and can block access to data.
• According to the same study presented to NANOG, attacks occur fewer than 100 times
per month.
• Although prefix hijackings are not new, that attack figure will certainly rise, and
probably significantly, along with a rise in cloud computing.
• As the use of cloud computing increases, the availability of cloud-based resources
increases in value to customers.
• That increased value to customers translates to an increased risk of malicious activity
to threaten that availability.
Infrastructure Security: Network Level
Ensuring the Availability of Internet-Facing Resources
• DNS attacks are another example of problems associated with this third risk factor.
• In fact, there are several forms of DNS attacks to worry about with regard to cloud
computing.
• Although DNS attacks are not new and are not directly related to the use of cloud
computing, the issue with DNS and cloud computing is an increase in an organization’s
risk at the network level because of increased external DNS querying (reducing the
effectiveness of “split horizon” DNS configurations) along with some increased number
of organizational personnel being more dependent on network security to ensure the
availability of cloud-provided resources being used.
Infrastructure Security: Network Level
Ensuring the Availability of Internet-Facing Resources
• A final example of problems associated with this third risk factor is denial of service
(DoS) and distributed denial of service (DDoS) attacks.
• Again, although DoS/DDoS attacks are not new and are not directly related to the use
of cloud computing, the issue with these attacks and cloud computing is an increase in
an organization’s risk at the network level because of some increased use of resources
external to your organization’s network.
• For example, there continue to be rumors of continued DDoS attacks on AWS, making
the services unavailable for hours at a time to AWS users. (Amazon has not
acknowledged that service interruptions are in fact due to DDoS attacks.)

You might also like