2. And thanks to
Ilja Livenson CSA - Cloud Security Alliance
"Security Guidance for Critical Areas of Focus
in Cloud Computing"
http://www.cloudsecurityalliance.org/guidance
"Top Threats to Cloud Computing"
http://www.cloudsecurityalliance.org/topthreats
ENISA - European Network and Information Security Agency
“Cloud Computing: Benefits, Risks and Recommendations
for Information Security”
http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-
risk-assessment
#306, 10th Main, 46th Cross, 4th Block Rajajinagar, Bangalore – 560010 M: +91
8050580888
6. Economies of scale and Security
• All kinds of security measures, are cheaper when implemented on a larger
scale. E.g. filtering, patch management, hardening of virtual machine
instances and hypervisors, etc)
• Staff specialization & experience - Cloud providers big enough to hire
specialists in dealing with specific security threats.
• Timeliness of response to incidents - Updates can be rolled much more
rapidly across a homogenous platform
• Default VM images and software modules can be updated with the latest
patches and security settings. Snapshots of virtual infrastructure (in IaaS)
to be taken regularly and compared with a security baseline.
"The same amount of investment in security buys
better protection"
#306, 10th Main, 46th Cross, 4th Block Rajajinagar, Bangalore – 560010 M: +91
8050580888
7.
8. Cloud-based defenses can be more robust,
scalable and cost-effective, but..
....the massive concentrations of resources
and data present a more attractive target to
attackers
10. "It is so easy
to get started"
Just pick up your credit
card and get started on
AWS
Not many questions asked
..... maybe that's a problem?
11. Threat #1: Abuse and Nefarious Use
of Cloud Computing
The problem:
Cloud Computing providers (IaaS) are actively being targeted, partially because their
relatively weak registration, systems facilitate anonymity, and providers’ fraud detection
capabilities are limited.
What have happened (so far):
• IaaS offerings have hosted the Zeus botnet, InfoStealer trojan horses, and downloads
for Microsoft Office and Adobe PDF exploits.
• Botnets have used IaaS servers for command and control functions.
• Spam continues to be a problem — as a defensive measure, entire blocks of IaaS
network addresses have been publicly blacklist.
What to do about it:
- Stricter initial registration and validation processes.
- Enhanced credit card fraud monitoring and coordination.
- Comprehensive introspection of customer network traffic.
- Monitoring public blacklists for one’s own network blocks.
13. Threat #2: Insecure Interfaces and APIs
The problem:
Reliance on a weak set of interfaces and APIs exposes organizations to a
variety of security issues related to confidentiality, integrity, availability and
accountability.
What have happened (so far):
Anonymous access and/or reusable tokens or passwords, clear-text
authentication or transmission of content, inflexible access controls or
improper authorizations, limited monitoring and logging capabilities,
unknown service or API dependencies.
What to do about it:
- Analyze the security model of cloud provider interfaces.
- Ensure strong authentication and access controls are implemented in
concert with encrypted transmission.
- Understand the dependency chain associated with the API.
14. Threat #3: Malicious Insiders
" If you work with a company long enough,
eventually you will have access to everything, and
no one will know it. "
16. Data loss....
• The Microsoft data loss of 2009 resulted in an estimated 800,000
smartphone users in the United States temporarily losing
personal data, such as emails, address books and photos from
their mobile handsets.
• The computer servers holding the data were run by Microsoft.
• At the time, it was described as the biggest disaster to affect the
concept of cloud computing.
17. Threat #6: Account or Service Hijacking
What to do about it:
• Prohibit the sharing of account credentials between users and services.
• Leverage strong two-factor authentication techniques where possible.
• Employ proactive monitoring to detect unauthorized activity.
• Understand cloud provider security policies and SLAs.
18.
19. Security should be implemented in every
layer of the cloud application architecture
• Physical security is typically handled by your
service provider which is an additional benefit
of using the cloud.
• Network and application-level security is your
responsibility and you should implement the
best practices as applicable to your business.
• AWS Security Best Practices tells you how.
20. • If you need to exchange sensitive or confidential information between a
browser and a web server, configure SSL on your server instance.
• You’ll need a certificate from an external certification authority like
VeriSign or Entrust.
• The public key included in the certificate authenticates your server to the
browser and serves as the basis for creating the shared session key used
to encrypt the data in both directions.
• Create a Virtual Private Cloud by making a few command line calls (using
Amazon VPC). This will enable you to use your own logically isolated
resources within the AWS cloud, and then connect those resources
directly to your own datacenter using industry-standard encrypted IPSec
VPN connections.
• You can also setup an OpenVPN server on an Amazon EC2 instance and
install the OpenVPN client on all user PCs.
Protect your data in transit
http://aws.amazon.com/vpc/
21. • If you are concerned about storing sensitive
and confidential data in the cloud, you
should encrypt the data (individual files)
before uploading it to the cloud.
• For example, encrypt the data using any
open source or commercial PGP-based tools
before storing it as Amazon S3 objects and
decrypt it after download.
Protect your data at rest
22. • On Amazon EC2, file encryption depends on the operating
system.
• Amazon EC2 instances running Windows can use the built-in
Encrypting File System (EFS) feature. This feature will handle
the encryption and decryption of files and folders automatically
and make the process transparent to the users.
• If you need a full encrypted volume, consider using the open-
source TrueCrypt product; this will integrate very well with
NTFS-formatted EBS volumes.
• Amazon EC2 instances running Linux can mount EBS volumes
using encrypted file systems using variety of approaches
(EncFS6, Loop-AES7, dm-crypt8, TrueCrypt9).
Protect your data at rest (cont.)
23. • Regardless of which approach you choose, encrypting
files and volumes in Amazon EC2 helps protect files
and log data so that only the users and processes on
the server can see the data in clear text, but anything
or anyone outside the server see only encrypted data.
Protect your data at rest (cont.)
24. • No matter which operating system or technology
you choose, encrypting data at rest presents a
challenge: managing the keys used to encrypt the
data.
• If you lose the keys, you will lose your data forever
and if your keys become compromised, the data may
be at risk.
• Therefore, be sure to study the key management
capabilities of any products you choose and
establish a procedure that minimizes the risk of
losing keys.
Protect your data at rest (cont.)
25. Protect your data at rest (cont.)
• Besides protecting your data from
eavesdropping, also consider how to
protect it from disaster.
• Take periodic snapshots of Amazon EBS
volumes to ensure it is highly durable and
available. Snapshots are incremental in
nature and stored on Amazon S3
(separate geo-location) and can be
restored back with a few clicks or
command line calls.
26. • AWS supplies two types of security credentials:
AWS access keys and X.509 certificates.
• Your AWS access key has two parts: your access
key ID and your secret access key.
• When using the REST or Query API, you have to
use your secret access key to calculate a
signature to include in your request for
authentication.
• To prevent in-flight tampering, all requests
should be sent over HTTPS.
Protect your AWS credentials
27. • If your Amazon Machine Image (AMI) is running
processes that need to communicate with other
AWS web services (for polling the Amazon SQS
queue or for reading objects from Amazon S3,
for example), one common design mistake is
embedding the AWS credentials in the AMI.
• Instead of embedding the credentials, they
should be passed in as arguments during launch
and encrypted before being sent over the wire.
Protect your AWS credentials (cont)
28. Protect your AWS credentials (cont)
• If your secret access key becomes compromised,
you should obtain a new one by rotating to a
new access key ID.
• As a good practice, it is recommended that you
incorporate a key rotation mechanism into your
application architecture so that you can use it
on a regular basis or occasionally (when
disgruntled employee leaves the company) to
ensure compromised keys can’t last forever.
29. • Alternately, you can use X.509 certificates
for authentication to certain AWS services.
• The certificate file contains your public key
in a base64-encoded DER certificate body.
• A separate file contains the corresponding
base64-encoded PKCS#8 private key.
Protect your AWS credentials (cont)
30. • Every Amazon EC2 instance is protected by one
or more security groups, named sets of rules
that specify which ingress (i.e., incoming)
network traffic should be delivered to your
instance.
• You can specify TCP and UDP ports, ICMP
types and codes, and source addresses.
• Security groups give you basic firewall-like
protection for running instances.
Secure your Application (cont.)
31. Over time, errors in software are discovered and require patches to
fix. You should ensure the following basic guidelines to maximize
security of your application:
• Regularly download patches from the vendor's web site and update
your AMIs
• Redeploy instances from the new AMIs and test your applications to
ensure the patches don't break anything. Ensure that the latest AMI is
deployed across all instances
Secure your Application (cont.)
32. • Invest in test scripts so that you can run security
checks periodically and automate the process
• Ensure that the third-party software is configured
to the most secure settings
• Never run your processes as root or Administrator
login unless absolutely necessary
Secure your Application (cont.)
33. Secure your Application (cont.)
• All the standard security practices pre-cloud era
like adopting good coding practices, isolating
sensitive data are still applicable and should be
implemented.
• In retrospect, the cloud abstracts the complexity
of the physical security from you and gives you
the control through tools and features so that
you can secure your application.
34. Summary
• Cloud services gives economy of scale = The same amount of
investment in security buys better protection
• But the massive concentrations of resources and data present a more
attractive target to attackers
• Cloud providers need to guard against theft or denial of service
attacks by users.
• Users need to be protected against one another.
• And users need to be protected against their cloud providers
• The old problems didn't go away, they just got a little bigger