Clouds as applied to information security: some unobvious consequences

Introduction

It is no secret that we are witnessing the rapid development of clouds aka Clouds. Everything and everyone moves to these very clouds. But what benefit (and harm) can we derive from this in terms of information security?

Consider new opportunities and new threats.
')
Here, thesis packages to reduce the confusion of presentation.

1. Keep in the clouds - not safe.
1.1. No need to store your pirated collections there.
1.2. It is necessary to hide competently, diluting with noise.
1.3. A bit of healthy paranoia does not hurt, we encrypt ourselves.

2. Handle in the clouds - profitable.
2.1. To do this, you need to build cloud services in a new way.
2.2. Survive attacks are now easier.

3. Evil hackers are now also easier - anyone can build a farm for cracking passwords.
3.1. We use passwords pozamenee and more authentic, not from the dictionary.
3.2. We use Keepass and analogs for password management.
3.3. Everywhere where you can - go to the keys.

Cloud Storage

Storage, in contrast to services - relate to everyone.

All these Google Drive and K appear like mushrooms after rain only because if you already have 100,000 active customers, then the next 100,000 won't bring that much unique content. And pay - as for the first time.

Do you have a terabyte music collection? Pour it into the cloud. In the typical case (usual pops, already assembled in digital form), it will actually take (at the right substitute) a zero byte drive. Zero!

All these compositions have already been uploaded to you, you have sent file hashes and counters for matching files increased by one.

As a rule, unique content from each is not so much. This text (in different formats), illustrations and photos.

Your “unique” content - how to stay awake

Interesting consequences follow from this.

For example - this. Pour your pirated content on our drive, and pay by credit card. We like it. Only hashes to compare, and automatically send to copyright holders a list of those from whom they coincided.

And the marketing department will tell you about "strong encryption" and "only for technical needs."

Media content - he is, yes.

Steganography - new non-obvious limitations

For lovers of hiding information in the pictures come hard times. Using steganography in the cloud is the same as hanging a lantern around your neck so that you can be seen from afar.

Say, poured photos of Pamela Anderson? And why not a single hash coincided with a million photos uploaded to the same hosting? Look in my eyes!

And it is caught - by statistics.

Therefore, it is necessary to fill in the noise - the pictures are ordinary.

UPD: This question has raised questions, so I will explain more about the statistics.

The danger here is not in the use of pictures or media files there. And in using the same files that have no analogues in the storage.

Typical use-cases with photos look like this

1. I downloaded from someone (a poster, a demotivator, a photo of a kitty, it’s necessary to substitute) and uploaded it to myself. Result? That's right, another 100,500 of the same is 1-in-1. The hashes are the same. And no longer changes. Write once.
2. I clicked the iPhone, brought the pack to the computer right away, cut it off and poured it in. There are no matches, but the files no longer change. Write once.

How does this differ from the situation “I'm hiding in a picture”? The fact that our unique content is constantly changing. It ceases to be write once. This makes it easy to take on a pencil those who are interested in steganography.

Therefore, in order to avoid such a stat-analysis, it is necessary to change the names of the images more often, leaving the old versions nearby. And fill in not one thing at a time, but in the company of new photos from an iPhone. In this case, this use pattern already looks like “I’m shooting everything I see,” and not “I'm hiding here under a lamp.”

That, in general, notably adds fuss on level ground.

Encryption

Our, native, manual content encryption is salvation. Stores do not like you - there is no profit from you. No content to compress, or glue with the same.

Just do not forget to separate encryption from storage. While we, paranoids, a little - it does not matter.

But if suddenly every second begins to encrypt - (you need to substitute) - the driver will have to put your key on the server. Not in order to get unauthorized access - but in order to get your profit.

And here the same moment appears as with steganography - and why should you encrypt the files yourself, are you an Arab terrorist? Do not forget to take help that you are paranoid!

Cloud Services

Now let's move on to services (for example, Amazon) - this is more useful.

Obviously, you can use these services in the style of "and I set myself PHP on a microinstante and it replaced me with shared hosting." In this case, the benefits of the clouds will be a little, namely - Vasya’s friend is harder to do with your phpbb, and the real pieces of iron will not fall into you.

However, if wisely approached, the possibilities are much greater. This is a balancer, and CloudWatch, and of course - the most delicious! - S3 and CloudFront.

These are the services that are typically used in a typical project, designed for 500k + active users.

1. EC2 (usually a bundle of specialized servers + RoR, JBoss, etc)
2. S3
3. Cloudfront
4. Cloudwatch
5. RDS (MySQL or Oracle - depending on the data model)
6. Beanstalk or SQS (communication between EC2 servers)
7. SES and / or SNS (mail and push-to-talk)

The higher the expected load - the more actively S3 and CloudFront are used, and the more EC2 we need for various Apache Solr and K.

Experienced look does not detect ElastiCache aka memcached in the list, and it is clear why. Because in the presence of JBoss Cache or Oracle Coherence, which already go on the stack of technologies used, one more cache is simply not required.

Instead, most of the results of specialized services using the S3 / CloudFront API are forcedly poured onto Amazon servers. Therefore, videos, pictures and other reports not only do not have to be built every time, but even host, remembering only their UIDs in the database.

I dwelt on this typical case in such detail, since it is this architecture that provides the prerequisites for using the full power of the clouds in protection.

DDoS is a thing of the past

An example would be the famous story with Wikileaks.

DDoSsili Assanzheevo creation, DDoSsili and not for DDoSsili. To score completely one of the largest networks of the world, located on four continents - this is from the realm of fantasy.

Brute force - bad power under the hood

However, black hats also get an advantage.

Now you do not need to build special devices and data centers, with 7-digit costs (not in rubles). Just rent a couple of three thousand on-demand EC2 with John to our The Ripper, preferably with Tesla on board, and the amount is already five-digit.

Reducing the price of brute force by 2 orders of magnitude - this is strong.

And more accessible.

From here conclusions are obvious:

• We use passwords pozamenee and more authentic, not from the dictionary.
• We use Keepass and analogs for password management.
• Everywhere where you can - go to the keys.

Habraeffekty and close to them types of attacks

It's also pretty obvious here - CloudWatch will raise as many front-end nodes in the balancer as needed, just a matter of competently prescribing restrictions. And he will put them when the need disappears.

S3 / CloudFront will withstand any number of people who want to “see these gorgeous photos yet”.

And SQS / Beanstalk will not allow applications for long-time operations to be lost.

The question as a matter of fact will rest against settings of a cluster of a DB and its cost. A full-fledged MySQL Cluster with synchronous replication is very expensive.

findings

New features - new realities. Security on the Internet!