Pass Amazon AWS Certified Security - Specialty Exam in First Attempt Easily

Getting started with the course

1. Understanding AWS Security Specialty exams

Hey, everyone, and welcome to the AWS Certified Security Specialty Video Course. I am Zel, and I am going to be an instructor throughout the course. Now, in today's video, we'll have a high-level overview of what the Security Specialty Certification Exam is all about, what the prerequisites are, and how we can go about preparing for this certification exam. Now, AWS has launched the full-fledged version of the security specialty after the two beta exams. So initially, AWS had launched the first beta exam, which they somehow canceled it. Then they relaunched the certification with the second beta exam, and only after the second beta exam was completed was the full-fledged certification launched. And in terms of exam domains and even the questions that you might be asked, it is very similar to the second beta exam that AWS has launched. Now, in terms of syllabus, this exam is divided into five domains. The first one is incident response. Domain two is logging and monitoring. Domain three is infrastructure security. Domain four is identity and access management. Domain Five is data protection. Now, among these five domains, infrastructure security is the most important, and the domain for identity and access management is one of the most critical.

Now, I have seen a lot of candidates not be able to pass the certification, primarily because of a lack of understanding about identity and access management. And this is the reason why we have given a lot of emphasis to this specific domain. We have also given a good amount of emphasis on each and every domain. And all the videos that we have for this certification video course will prove to be extremely important for you to clear the exam. Now, in terms of scoring systems and prerequisites, the AWS Certified Security Specialty is a pass-fail exam. Now, scores are measured against the maximum of 1000 marks, with 750 passing of 750.So it can be considered that the total of 75% is the minimum for passing. Now, in terms of prerequisite and recommended knowledge, AWS has removed the prerequisite of having the AWS Solutions Architect, Associate, or Cloud Practitioner, which was earlier mandatory. So that prerequisite is now removed, so you can directly go ahead and prepare for the exam. Now, AWS does recommend that the candidate have two years of hands-on experience with AWS workloads. Remember that AWS Security Specialty is not a simple example. It is a very challenging exam. So you need to understand the fundamentals, or have a solid foundation in AWS, which is what I recommend. So this second point is added by me: at least the candidate who is sitting for the exam should have the AWS Associate Certification or knowledge that is similar to the AWS Solutions Architect Associate Certification. So let's do one thing. Let's look at the official certification page. So this is the official AWS page, and if you scroll down, you'll see that they recommend a minimum of five years of it security experience. This is, I would say, beneficial but not mandatory for this exam. I have seen a lot of candidates who have quite good knowledge, and they have the certification, but they do not really have five years of IT security experience. One important part here is the exam overview. So again, this is going to be a multiple-choice and multiple-answer question. The length is going to be 170 minutes, as mentioned here, and you will have a total of 65 questions. And the registration fee, very similar to the professional certification, is 300 USD. Now, if you are on the right side, you can download the exam guide. The exam guide looks somewhat similar to what we have over here. Now, if you see over here, this exam consists of five domains. You have domains 1234 and five. And if you look into the percentage of examination, the minimum is 12%. So each and every domain is extremely important, and you cannot skip any one of these. And I'm sure that if you go through the video course that we have throughout all five domains, you will be pretty well prepared for this certification exam.

Hide

Domain 1 - Incident Response

1. Introduction to Domain 1

Hey, everyone, and welcome to the first introductory lecture for domain one. So what we'll be doing in this lecture is having a high-level overview related to the domain that we will be discussing in the subsequent acute lectures. So in today's lecture, we'll be discussing primarily domain one, which is incident response. So, it's quite an interesting domain. So incident response, as a gist, if I can say so, is a way in which you can tackle security-related events. Let's assume that you are working as a security engineer and there are certain attacks that are happening or certain attacks that have already happened. How will you mitigate those attacks? How will you deal with those attacks? And something similar to this is part of the incident response domain. Now, the incident response domain covers a lot of topics that actually match with other domains. Assume you are a security engineer and are under attack by a distributed denial of service. So how will you protect your AWS infrastructure against DDoS attacks? So there are various ways. You might be able to use Network ACL, CloudFront, AWS Shield, and other services. However, those topics are definitely relevant under the Incident Response section, but they are more relevant under the Infrastructure Security section. So, you see, a single lecture can traverse two domains. And in order to make sure that we don't really overlap, what we'll be doing is that any practical lectures like AWS, Config, Cloud, and Front will fall under the category of infrastructure security, and under incident response, we'll try and cover the theoretically related aspect. Because this is more of a theoretical aspect where you see it talking about the incident response plan, we have to look into the incident management process. So, within this domain, we will have more theory, and our main practical will begin with domains three, four, and five. So out of all the domains, domain one will try to keep it more of a theory, and whatever practicals that are associated will be part of the infrastructure security. So if you don't really find some interesting practicals in this domain, I apologize; however, in the next domain, you will find amazing practicals. We have amazing practicals, which are part of each and every domain over here. So this is it. about the domain one. In the upcoming lecture, we'll begin by understanding what incident response is, and we'll go into more detail related to how we can manage the incident response process. So this is it. About this lecture, I hope it has been informative and formative for you, and I look forward to seeing you in the next lecture. Bye.

2. Case Study of Hacked Server

Hey everyone, and welcome to the Knowledgeable Video series. And in today's lecture, we will be looking into one of the case studies related to the haggard server. So this is one of the real-world scenarios that I have worked with for a long time buying back. So this will be useful for us both in terms of motivation as well as in terms of looking into what things would really look like in terms of compromised servers. So let's begin now. A year ago, I received an email from one of my colleagues basically requesting assistance with respect to security as the servers were hacked. So now the question is, how did they come to know whether the servers were hacked or not? And the answer to this is the third party and various complaints from the hosting provider. So they themselves were not really aware that they had been hacked. Their customers informed them that their websites were forcing the users to download a malicious APK file. So APK is generally for Android, so whenever a user used to visit their website from an Android phone, it would automatically download an APK, and customers started to complain about that. Along with that, they started to receive a lot of complaints from their hosting provider, and this is how they actually came to know that they were hacked. So once I receive this, I'll share some of the screenshots, which will show you exactly what it looked like. So this is the abuse complaint that they received from their hosting provider. So this is the IP address of their service. And the problem was spam senders. So from the spam emitters, I hope many of you might guess that the servers were also used to emit lots of spam messages, and that was absolutely true. So when we were investigating the server, we realized that it was actually used as the SMTP to send thousands of emails every day to many users. And that email contained a lot of malicious files as well as spammy contents. So if you look into the Spool directory of PostFix, POSTIX is one of the clients that is responsible for sending emails. So within the VAR Spool post-fix directory, you see there are so many, I guess you could say, files, and each file corresponds to a single email, and there were more than tens of thousands of such files per day. And when you open one of those files, and I have actually opened one of those files, you can actually see the contents that were actually present within that specific file. So if you'll pay attention, this letter can change your life. A group of German mathematicians, blah blah blah, and along with this, there is a reference link, and there is also an attachment that is basically malware, and this was sent to a lot of users. So how exactly do things work? So, as previously discussed, whenever a user visited the website automatically, a malicious APK was downloaded, and upon further investigation, we discovered that their main index PHP file, which served as the main web page, was compromised. So you see, this is the encoded code, which basically does a lot of malicious activity. So this is actually the hacked quote, which the hacker has put up to serve the users. So it will not go into too much detail, but the question is, "Why?" and "Why did it happen in the first place?" Now, there are a lot of reasons. To begin with, improper firewall configuration left everything open: port 22 was open, internal web services were open, and everything was available for people to exploit. That is the first major vulnerability. Second is the lack of a web application firewall. So if you are running a web application, you have to make sure that it is secure in terms of the web application security side, like there is no SQL injection, no cross-site scripting attacks, et cetera. And, if you can't have all of those, at the very least, you should have a web application firewall deployed to help you protect at a certain level. Third, no server hardening was there. Fourth, file integrity monitoring was not there. So, when their index PHP was modified, ideally, whenever an application file is modified in a production environment, the system engineer or system administrator should immediately receive an alert that the file was modified that wasn't there, which could have been done with the help of FM Tool. Next is patch management. So every month there are certain kinds of high- or critical-level vulnerabilities that are released against operating system patches, and this is the reason why patch management should always be there. The next important point is to always code with a web application scanner. So this is part of the vulnerability assessment. The vulnerability assessment part was missing. Next, we monitor for sudden open ports and locks. So if one port suddenly opens in the middle of the night, you should always receive an alert. So this is all related to the monitoring aspect, and the last is much more. So there are a lot of things that you need to do in order to ensure that security is always present and is always a top priority. Now, in most organizations, you will see that many of the security controls that are there are missing. And this is the reason why there are thousands of websites that get hacked every single year. Now, even if people have a simple firewall, it can actually protect a lot of websites from getting compromised. However, as a security engineer, if you're working for an organization, you have to ensure that you have a proper security control, a proper defense, and a depth-based architecture that can help your organization protect against malicious users.

3. Dealing with AWS Abuse Notice

Hey everyone and welcome back to the Knowledgeable Video series. Continuing on our journey, in the previous lecture we discussed one of the use cases for a haggard server, and today we will discuss AWS abuse reports. AWS basically sends an abuse report to customers when their AWS resources are being used for abusive purposes. So what do I mean by this? So in the earlier lecture, let me actually show you. In the earlier lecture, we had seen one of the abuse complaints from the hosting provider, which basically said that this specific IP address of the customer is being used for spamming-related activity. So generally, whenever you opt for a hosting provider and you use that hosting provider's resources for some kind of abusive purposes like bruteforce attacks, spamming, denial of service, and many others, then you will get an abuse complaint from the hosting provider directly asking you to double check and stop that specific activity. Now, in most of the cases, the abuse complaints are directly related to the hacked server. So something similar to what we had seen, like many of the customers servers are compromised and they do not really have any detective control that can inform them that the servers are compromised. However, they come to know about compromised servers from third-party customers or third-party entities about their compromised servers. So whenever they generally receive abuse reports, they are directly related to some kind of attack that the customer servers are doing unintentionally. Now, whenever you choose a hosting provider, we should ideally check the acceptable usage policy. And as a solutions architect, we need to know what the AWS Acceptable Usage Policy is all about. So if you look into the AWS Acceptable Usage Policy, it basically says what the customers can do and what the customers cannot do. So if you see over here, the customer is not allowed to do some illegal, harmful, and fraudulent activities or upload offensive content, and there are so many things that are mentioned over here. So these are some things that no customer is supposed to do. And if you as a customer are found to be performing certain activities that are part of this, then you will receive an official report from AWS to verify why exactly these things are happening. So, in general, when we talk about who files the abuse complaint, let me give you one of the examples, but first, let me show you one of the abusive complaints that one of the startups for which I consult has received. So just a week ago, they received an abuse complaint from AWS saying that this specific instance ID has been implicated in an activity that resembles a denial of service attack against a remote host. So there was a customer who was receiving a lot of brute force-related attempts from one of the IP addresses that belong to the AWS resources. So that customer complained to AWS, and AWS sent that complaint to the customer whose ECTWO instance was responsible for doing that. So, if you go a little further down, the customer has actually provided the exact logs on what is happening. So you see, this is the source IP address of the EC2 instance. And the service is basically port flooding. So this is basically reported from the abuse team. As a result, this specific server was responsible for a large number of denial of service attacks and brute force attempts. So on further investigation, we came to know that there was a certain open source application that was running and that it was actually running an older version that had a lot of vulnerabilities. And that application was compromised, and the server was compromised. So the server had a script that was used to perform various brute-force attacks on remote hosts. So whenever you talk about abuse complaint, abuse complaint can directly file by the clients who are getting affected. So let me give you one of the examples. So let's assume that I have a server in a data center, and suddenly I am receiving a lot of brute force attacks from one of the specific IPS. On further investigation, I learned that IP belongs to the AWS block. So I complained to AWS, saying that this IP belongs to your customers, who are sending me certain kinds of activity that they are not supposed to do. And AWS will send that complaint to the customer, asking them to stop. And this is exactly what it really looks like. Now, if you are a customer who is getting affected by some kind of AWS attack, for instance, maybe trying to brute force or trying to send you spam messages, then you can actually create a report on Amazon EC2, where you have to give certain private information along with the source IP as well as the locks. So if you look into this email, they have actually the customer or the organization have attached the log file and this is what the customers can do. And you can actually select the exact activity, and you can send a report of abuse to the AWS. AWS will verify this, and it will then send this email to the customer, asking them to look into what exactly is happening and to stop it. So, this is what AWS abuse reports are all about. Since we are a solutions architect who will be working more on the security aspect, there are a lot of chances that you will be receiving certain kinds of abusive reports that you need to work out to ensure that the servers are patched accordingly. So, this is it for this lecture. I hope this lecture has been informative for you, and I look forward to seeing you in the next lecture. Bye.

4. AWS GuardDuty

Hey everyone and welcome back. In today's video, we will be speaking about one of the new security services that AWS has launched, which is called the AWS Guard Duty. So, guard duty has been one of my favorite great security services, and we look into why this is considered one of the very great services that have been launched as far as the security aspect is concerned. Now, by definition, AWS Guard Duty is a threat intelligence service by AWS, which basically monitors for malicious behavior within your AWS account to help customers protect their AWS workloads. Now, within this definition, these two terms, threat intelligence," are very important terms that you should be understanding. Now, when you talk about a threat, it can be applied to a human and even to a machine. So a threat is something that is harmful to a specific entity, and intelligence is something that can help you determine whether that harmful content is present or not. So. What basically AWS Guard duty does is that it looks into multiple log files. As a result, it investigates cloud trail log events. It looks into your VPC flow logs. It looks into your DNS logs and depends on the threat intelligence feed that AWS has. It will try and detect a lot of attacks, like bitcoin mining. It can detect DNX exfiltration. It can detect Trojans. It can detect SSH brute-force attacks and various others. So, if you look into a Guard Duty Finding dashboard, you'll see that it has detected a lot of things like RDB brute force, phishing, bitcoin, SSH brute force, and various others. So this is what guard duty is all about. Now, as expected, the ideal thing that you should see within the guard-duty console is nothing. So having nothing is the best thing for your AWS account. So, let me quickly show you what a Guard duty console might look like in real life. So I'm currently in my AWS console, and what I've done is intentionally added a security group to two of my instances. So if you look into the security group over here, it basically allows allowed of all. So this was just to see what exactly might happen and to trigger a few alerts and test whether guard duty really works as expected. So, from my console, I go to Guard Duty, and within my Gut Duty console, if you'll see over here, it has given me four findings. First is the SSH brute force, then you have therecon, which is basically a scan, and you also have a SSH brute force, which is basically what you have; I have two instances over here. If you look here, I have two instances, Kplan one and two. And for both of these instances, I had attached the security group. So, Gutt is basically referring to both of these instances. So that's a six and a five. So these are the two instances that guard duty is referring to. Now, within the brute force attack, clicking over here within the finding gives you a lot of information. So the first thing that it tells you is the source, which is affected by this brute force attack. So this is the instance ID for which the brute-force attack is coming from. Now, if you go a bit down, it basically gives you a lot of information, like the attack vector. So if you look over here, the attack vector is this specific IP address. This IP address comes from China. It basically gives you a lot of information related to the ISP, which holds this IP address and various others as well. So if you see very nice information, it's something that God's duty is allowing us to look into. So let's do one thing. Let's go ahead and enable guard duty in one of the accounts. So this is my second account where guard duty has not been enabled. So typically, when you go into the guard duty console, this is what the console will look like. So you can go ahead and click on get started and the only thing which you will have to do is you'll have to click on Enable Guard Duty. Now, along with that, do remember that guard duty is free for 30 days, after which you will have to pay. So I'll click on Enable Guard Duty, and this is the only thing that is required. Now, Guard Duty will go through your cloud trail log, it will go through your DNS log, it will go through your VPC flow log, and then it will analyze each one of them and try and report various threads that might occur within your organization that it is able to detect through those log files. Now, one important part that I wanted to show you is that if you go into the settings, you have an option to generate a sample finding. So if you go ahead and generate the sample findings, and if I go into the findings over here, you will see that guard duty has really generated a lot of sample findings. Now, these sample findings are basically guard duty has various categories. So one is of severity high, second is of severity of media and third is of severity of information or it is also called as the low. So basically high suggest that it contains information leakage. So if you look into, say, DNS exploitation, So this is one of the attacks that signifies that the data from your EC2 instances is getting infiltrated through DNS queries. So anyways, understanding each of these attack vectors is not part of the certification, but you should be aware of what guard duty is and how you should be enabling guard duty. Now again, as a security professional, Enabling guard duty is the first thing that you should be doing in an AWS account that you are auditing, and just wait for a certain duration of time, maybe a few hours. And if you are not getting any samples, that is the best thing. If you are getting samples, then you should go ahead and resolve those. Last but not least, guard duty is not merely a platform, nor is it merely a tool capable of detecting threat intelligence. There are various other tools and technologies. Like Kaspersky, which has its own threat intelligence portal, Kaspersky also does a very similar thing. So you must upload all of your log files to this threat intelligence portal, and Casper's Key will go there and examine each of these lock files to see if any threats are associated with those log files. So there are a lot of other threat intelligence platforms that are available, but guard duty is something that is very easy to enable and is recommended for the AWS environment that you are using.

5. Whitelisting Alerts in AWS GuardDuty

Hey everyone and welcome back. Now in today's video, we will look into the whitelisting of alerts in guard duty. Now, Amazon Guard Duty can generate a wide variety of alerts. Now, some of these alerts might be true, but you might want to ignore them. Now let's understand the simple use case. example, you have created an application, and hundreds of users within your organization have started to access that specific application. Now, if all these hundreds of users are within the same organization and they are making a call towards the Internet, that basically means that the outgoing IP will remain the same. When Guard Duty notices that hundreds and hundreds of requests are coming from a single IP address, it may suspect a brute-force attack and send you an alert. All right? So this is one use case where, although Guard Duty Alert is true, there are hundreds of requests from a single IP address, but you do not want them because you know that it is a genuine alert. So, in order to overcome this kind of scenario, you can build your own trusted IP list. Now, Amazon Guard Duty allows customers to add their own trusted IP list. Now, what would happen is that once you have added, in this example, my IP address to the trusted IP list, Once added, Guard Duty will no longer generate the finding for an IP address that is on the trusted IP list. So this will reduce your alertness quite a bit. So let's understand how this would look like: So, this is my guard duty console. Now let's do one thing. Let's go to lists, and within the first tab here, you have a trusted IP list. So here, you can manage your own list. So you can add a trusted IP list here, where you can specify a list name, a location, and a simple format over here. So there are various formats that are supported. The simplest one that you can make use of is the plain text one. So let's do one thing: let's create it from scratch. Now, I'm in my Atom editor, and let's add an IP. I'll say 1167-535-5032, and I'll save it as a trusted IP PhD. Now, once you have saved this, let's go to the S-3 service here. And within the SD console, I have a bucket called life and my demo bucket. Let's go ahead and upload the file here. So I have selected the trusted IP TXT and I'll go ahead and upload it. Now, within guard duty, let's go ahead and add a list. I'll call it a KP lapse. And for the location, you can specify the URL; you can even specify it directly via S 3. So let's do a Kplashmidemocket followed by the name, which is trusted TXT. So let's quickly verify that it's trusted IP TXT, and the format of the list would be plain text in our case once. Then you can add a list over here. So now it says that it has successfully created the list. So once you have created it, make sure that the list is in the "active" status. Now that's an overview of the trusted IP list. You now have a threat list that you can refer to at any time. Let's say you recently detected an attack from a malicious user and you know the range of IP addresses belongs to malicious users who are attacking your website. So you can also create your own custom threat list because it can happen that even though those malicious users are trying to connect with your environment, Guard Duty might not detect it because Guard Duty has its own threat list, which is available. So in that case, if you are sure that there are certain IP addresses that you do not want, then you can create your custom threat list based on those malicious IP addresses. So that whenever God Duty receives the request, it will notify you as well, based on those IP addresses.

Hide