Chapter 12: Security on AWS (Part 2)

Encrypted puzzle at rest.




This is a long chapter, there's still more to go.

Again I'll start with things I'm not familiar with or look odd or interesting. I get the feeling however that this chapter is really just designed to overawe the reader with the extent and variety of security that AWS has provided. At some level I don't think the detail matters. There's security for data in transit and (mostly) at rest, security for networks, security for IP addresses, security for APIs, security for accounts, users, roles, federation, etc. Security for everything!  Again I'm not 100% sure who needs to know all this stuff? I guess security managers and administrators? And there's still the unanswered question of (1) how do you set a security goal and metrics, and (2) how do different combinations of security features get you closer to or further away (or reaching) the goal and metrics?

Back to EC2:

One way to get your AMIs updated and patched without doing it yourself is to relaunch the instances and they get updated.

Encryption of Data at Rest

EBS volumes support encryption. For example, between EC2 and EBS, but this is only supported for larger instance types as there is an overhead.

A number of parts of the book mention encryption of data at rest. Which services support this?

There's a whitepaper.

Some slides.

Another blog talks about different methods.

Page 356 says that the following services offer encryption of data at rest as a feature:

S3, EBS, Glacier, Storage Gateway, RDS, Redshift, Workspaces.

Not DynamoDB? EFS? SQS?

Where's a complete list?

There's also a service AWS Server Side Encryption (SSE). What services does it work for? Only the following? It's very difficult to search for services which support SSE (Why? Ah, it's only a S3 service!)

S3

SQS

The  white paper dates from 2014 and doesn't even mention SSE. A table summarizes options.

The latest whitepaper on compliance mentions SSE, but again not list of services supported.

There are 3 types of SSE-X service, depending on who manages the keys:

SSE-C is with customer supplied key.

SSE-KMS with KMS managed keys.

SSE-S3 with S3 managed keys.

• Server-side encryption with customer-provided encryption keys (SSE-C).
• SSE-S3.
• SSE-KMS.

But the exception is that SSE can be used with SQS! The detailed SQS SSE FAQ. and detailed docs.

And the performance impact? This blog says it's minimal or even better for RDS.

There are some impacts of using server side encryption. For example, for Redshift the advice is that enabling encryption will impact performance.   And for RDS (other services to!) SSL encryption from client to application will increase the latency of the connection.  However, I'm not sure where the justifications for these can be found (benchmarks, AWS whitepapers, etc).

MAC Spoofing and ARP Spoofing

Next I came across this sentence:

Subnets: Customers create one or more subnets within each VPC; each instance launched in the VPC is connected to one subnet. Traditional Layer 2 security attacks, including MAC spoofing and ARP spoofing, are blocked.

Straight out of this very old whitepaper.

MAC spoofing

ARP spoofing

Ok I'm still none the wiser. What's a MAC? An ARP? A spoofing???

Well spoofing is easy-ish (OED):

SPOOF

NOUN

• 1A humorous imitation of something, typically a film or a particular genre of film, in which its characteristic features are exaggerated for comic effect.

• ‘There are certainly examples dating back to the 1870s of photographers mixing up different images to make jokes or spoofs" (OED example)

2 A trick played on someone as a joke.

‘word got out that the whole thing had been a spoof’

A Spoof book (maybe?)




So this is what subnets are good for? Stopping layer 2 attacks?
Do they also stop MAC flooding?
ARP cache poisoning? (Yes, same as ARP spoofing).
The VPC security doc is useful.

MAC Flooding? (I.e. Mac = Trenchcoat in the trenches)




What other layer attacks are there?

Quick reminder of OSI layered model



US gov summary of layer 1-7 attacks.

Layer 1-4.

Which parts of AWS security address each of the network layer attacks?

Layer 1 attacks

Layer 2 attacks



AWS Shield is managed DDOS protection for layers 3, 4 and 7.

http://docs.aws.amazon.com/waf/latest/developerguide/ddos-overview.html

Page 10 of the DDOS guide has a good table with different layers protected by different AWS services.

And this is interesting. All subnets in same VPC have layer 2 reachability:

It’s tempting to describe route tables as being similar to virtual routing and forwarding (VRF) tables. However, subnets in the same VPC can communicate directly with one another, so the separation VRFs typically provide doesn’t apply. Functionally, everything in the same VPC has Layer 2 reachability. Use security groups and Network ACLs (explained below) to provide more granular access.


And useful info about ELB layers information.

And this clarifies which layers load balancers work at:

Today we are launching a new Application Load Balancer option for ELB. This option runs at Layer 7 and supports a number of advanced features. The original option (now called a Classic Load Balancer) is still available to you and continues to offer Layer 4 and Layer 7 functionality.

it would probably be useful to have an architectural level diagram which shows which layers each AWS service works at? TODO

This blog points out the differences between layer 2 and 3 in terms of traditional data centres and public clouds

All the AWS security resources in one place, but no way to search them all for "layer x" relevance pity.

Most of them don't refer to network layers at all.