Amazon AWS SysOps – Security and Compliance for SysOps part 1

1. Section Introduction

Welcome to this section around Security and compliance. This section is one of the hardest going into the Sysaps exam because we’re going to learn about new technologies. All of them have a lot of different names such as Inspector Hsm, Waf, Trusted Advisor, Guard Duty, etc. Etc. Now, in this section, I wanted to make things easy, so we’ll go over them one by one, and I will try to include a hands on where possible.  Also at the end of this section, I have a whole lecture that will just summarize what all these technologies does. And going into the exam, you should just rewatch that lecture for a quick refresher and you should be all right. I hope you’ll enjoy it. Security is fascinating and I will see you in the next lecture.

2. Shared Responsibility Model

So first let’s talk about something that I think you should know already, but it is the AWS shared responsibility model. So let’s understand what is your responsibility and what is Aws’s responsibility? So Amazon’s responsibility is to secure their cloud. That means that they need to protect their infrastructure. And that means everything the hardware, the software, the facility, the networking that runs all their services. So they’re responsible for the data centers, they’re responsible for their wires, they’re responsible for the network, everything like this. They’re also responsible for services like S Three, DynamoDB, RDS, et cetera. They’re basically responsible for anything they manage and they advertised as a managed service.

Yet they’re not responsible for everything. You are also responsible for the security in the cloud. That means that, for example, for an easy to instance, you’re responsible for the management of the guest OS. That includes all the security patches and the updates. You’re responsible for the firewall. So that means the security group and the network configuration, that means the enis and you’re responsible for the IAM roles, et cetera, et cetera, et cetera. So I think that’s pretty clear. Amazon’s does not give you access to their hardware, they don’t give you access to their network, they don’t give you access to their facility.

So that’s for them to manage, but they give you access to a lot of things. And the security of these things that they give you access to, such as an easy to instance, is your responsibility. Now we go to two concrete examples. The first one is for RDS. For RDS, think about it in your head what is Amazon’s responsibility and what is your responsibility? Now, I’ll go ahead for Amazon responsibility, well, they will manage the underlying EC. Two instance, they will disable Ssh access. They will automate the database patching. They will automate the OS patching on the EC to instance, they will audit everything for the underlying instance and the disk and guarantee it works.

Whereas your responsibility is going to be that you need to check the ports, the IP, the security group inbound rules for the DB security group. You also need to make sure that you control entirely the database user creation as well as their permissions and their roles within the database. You also need to make sure you create a database with or without public access. Usually it is without public access. And then you need to ensure parameter groups of the database is configured, for example, to only allow SSL connections for encrypted intrinsic traffic. And you’re also responsible for any other type of encryption setting such as Kms and Enablement.

So this is where you see really what is Amazon responsibility, more on the lower level type of settings and your responsibility, which is on the user settings. Okay. If we take such an example, such as S three adam’s responsibility is to guarantee you almost unlimited storage to guarantee you that you get encryption to ensure the separation of the data between you and their different customers to ensure that the Amazon’s employee cannot access your data. Whereas your responsibility on your own is to make sure the bucket is configured correctly. That the bucket policy and the public setting are set correctly. That you need to make sure that your IAM reserves and roles are set correctly and finally, whether or not you want to enable encryption.

I think that’s pretty clear. I won’t go over other examples, but you get the idea. Amazon is responsible for their stuff and you’re responsible for your stuff. Now, what is their stuff and what is your stuff? There’s a cool diagram that they have on the Amazon websites for compliance, which is what is your responsibility as a customer versus what is Amazon responsibility as their provider? And so, as you can see, Amazon’s responsibility is to be for the hardware and the global infrastructure that includes regions, AZ, Edge locations and for the software such as Compute, storage, database and networking.

Whereas you as a customer, you’re responsible for your own data security, you’re responsible for your own IAM users, et cetera. Your OS network and Firewall configuration for easy two instances, for example. And you’re responsible for whether or not you want to enable encryption. You want to verify data integrity, you want to have server side encryption or some kind of network traffic protection such as encryption identity and integrity and identity. So I hope that makes sense. It’s quite a simple lecture, but Exam will ask you sometimes what is your responsibility versus what is Amazon’s responsibility? So make sure you’re on point with that and I will see you in the next lecture.

3. DDoS, AWS Shield and AWS WAF

So what’s a DDoS attack? And DDoS stands for Distributed Denial of Service. So DDoS attacks are very, very common on the web, although people are quite well protected against it now. Thanks all the tooling you will see in this lecture. But still they may happen to you, they may happen to anyone. And it is great to know how you can protect yourself from this DDoS attack and make sure that your application isn’t impacted by them. So at the core, we have an attacker. An attacker could be one person, it could be a group of person, whatever. And that person wants to attack you. It wants to attack your application server. So the idea is that it wants to flood it as much as it can, such as it won’t work anymore.

The idea is that the attacker are just going to create a bunch of master servers or whatever it is, and then these masters will simultaneously spin up a lot of buts now these butts may be infected machines from people’s computer. It may be data centers that are compromised, anything like this. Anyway, an attacker gains access to ThreeMasters and butts a lot of machines. And these machines all of a sudden, all of the time start querying and asking a lot of questions to the application server. Now, these questions can be different. It could be a DNS, it could be some layer four, layer seven, which depends on if you want to use TCP or TCP. There’s a lot of way of flooding an application server.

For example, if you just send it 100 megabyte files and you basically clogged the network, or if you do too many requests per second, then your application server can’t follow. There’s different kind of DNS attack of attacks, DDoS attacks. Some can be with the DNS. Anyway, the idea is that in some way all the butts are going to attack this application server and the application server cannot serve all the requests and all the traffic at the same time. Therefore it is stuck. It will try to keep up with the right, but basically because the butts are flooding in because they’re doing a DDoS attack, then the application server is rendered useless.

So for our normal users, what will happen is that they won’t be able to access or they won’t be seeing any response from the application server because the application server will try to reply to first to all of the butts. And this is how a DDoS attack works. It’s not about a hacker getting into an application server, trying to hack it and Ssh into it. No, it’s not like that. The attacker basically will just flood the application server with as many requests as it can. So this is quite a scary attack and attackers know how to do this really, really well. So what can we do on AWS? Well, you have different ways of protecting yourself. By the way, this is a high level overview and we’ll do a small deep dive on Shield and wealth. So for Shield this is a service and you have two tiers for it.

The first one is Shield Standard which is available for you for no additional cost and it’s already available and it protects you against DDoS attack for your website and applications. You have to do nothing to get it. But there’s also Shield Advance and we’ll see in the detailed lecture what this means. But you get 24/7 premium DDoS protection. So this is quite cool. If you see the exam 24/7 premium DDoS protection. This is Shield. That is hinting at it. Shield, advance. Then there is Web Waf or Web Application Firewall which is to basically have a firewall that allows you to filter specific requests based on the rules you can define. These rules may be a request. More than two megabytes are a little bit fishy.

No one of my users does a request of more than two megabytes. Therefore we’ll filter them out. This kind of filters. Then you have some advanced protection through Cloud Front and Route 53. The idea is that you get availability because you have using Cloud Front and Route 53 all the traffic being served at the edge network. So a lot of edge locations on the AWS network. So that means that for an attacker to attack you on the global scale, they need to also attack all the edge network which is a lot more effort than just attacking one location. And when this is combined with AWS Shield, then it provides you basically attack mitigation at all the edge network locations which is really really nice.

Also a way for you to protect yourself against DDoS is to leverage autoscaling. If your application can autoscale and really start serving more traffic with adding more easy to instances or whatever, then you are ready to let the attackers know that even if they try to increase the traffic on your application, your application will scale and hopefully still service your normal users. There’s also a really cool trick where you can separate your static resources so all your HTML CSS image files onto S Three, Cloud Front and then the dynamic ones which is the API calls onto EC Two and your application load balancer. The idea is that now it’s much harder for your application to be DDoS because all the static resources are served through something that’s static and meant to scale tremendously.

Whereas your API can have very safe guards, for example against Pig request or whatever using EC Two and Ald. Overall I do recommend reading this white paper if you want to prepare for the exam or if you’re just interested into the DDoS. So skim through it. The DDoS white paper is quite nice, but within it you will see that there’s some reference architecture. This is just one from the AWS and service website but basically it shows you that as users the protections you have is Shield on 53 to avoid DNS type of attacks. Then you have Shield enabled on platform distribution on which you can also top of it, add a web application firewall to filter some request, and then if the traffic goes through, then your security group, your load balancer, everything will be protected by Shield.

And then if it goes through again, then you have your auto scaling group ready to scale in case a lot of requests happen all of a sudden. So this is good to know. Let’s do a deep dive on Shield. Shield has two tiers, the first one is Shield standard and it’s a free service and it’s activated for every alias customer. So you get it right of the way and it will basically provide you protection from common attacks that are called Sin, UDP reflection or other type of layer three or layer four attacks. Now you don’t need to know this much specifics, but just know that Shield does protect you by default. But the exam will ask you about Shield Advance or this kind of questions.

And Shield Advance is going to be an optional service for DDoS and it’s more advanced because it costs you up to $3,000 per month per organization. So you need to have a sizable basically infrastructure to require Shield advanced. But what it gives you now you’re protected against more sophisticated attacks on cloud front group GD three classic EC two, you can get application network, no balancer elastic, IP, et cetera. Now what you get from it for paying 3000 per month is that if you do get a DDoS attack, you’re going to get 24/7 access to the AWS DDoS response team or Drp. So if the exam is asking you hey, we need to have 24/7 DDoS protection from team that is going to be able to mitigate it if it happens.

This is the kind of question that says you should use AWS Shield Advance. Also if you do get higher fees because your application is getting DDoS, so you’re scaling so you have more requests, more traffic, maybe more easy to instances being created, then all the higher fees that happen during this usage spike will be waived because you used eight of us Shield Advance. So it’s quite cool because on top of protecting you against DDoS attacks, it also protects you against rising costs due to DDoS attacks. So it is quite a good service to have if you have a sizable organization and you get attacked very frequently. Finally there is Waf or web Application firewall and that will protect your application from common web exploits and you can define web security rules such as I want to know who to block or allow for my web applications.

I can include IP addresses, Http headers, buddy, Uri strings, and you can be protected against common attacks such as SQL injection or cross site scripting so Xss and you can be protected against bot, bad user agents, et cetera. And you can even have size constraints on the request. So you say, I don’t want to have any request more than two megabytes. For example, to limit the number of network bandwidth that is going to be used. You can do some geolocation maps. So if you see all the bad traffic coming from, I don’t know, America, then you can block all of America and then you can deploy this on cloudfront application load balancer API gateway.

So it does provide you some protection on all the common AWS components you already have today. And on top of it, there is a marketplace of rules you can use directly from Wif, which allows you to leverage the rules that some other people did. So it gets basically protection for free because someone else thought about all the good rules to include to get you self protected with Waff. So that’s it. It’s quite a theoretical lecture, I know, but remember, basically you need to read that DDoS paper. You need to understand what Shield and wealth are. They’re very different. Shield is for DDoS is more going to be for security rules if you want to protect yourself from specific kind of request. And that’s it. I will see you in the next lecture.