Gain in-depth knowledge for passing your exam with Exam-Labs AWS Certified Security - Specialty: AWS Certified Security - Specialty (SCS-C01) certification video training course. The most trusted and reliable name for studying and passing with VCE files which include Amazon AWS Certified Security - Specialty practice test questions and answers, study guide and exam practice test questions. Unlike any other AWS Certified Security - Specialty: AWS Certified Security - Specialty (SCS-C01) video training course for your certification exam.

Domain 1 - Incident Response

6. Understanding Incident Response Terminology

Hey everyone and welcome to the Knowledge Pool video series. and in today's lecture we'll be speaking about incident response. So incident response is one of the most important topics to understand, especially if you're working in the sixth security domain and dealing with real-world implications. If you're planning on getting a security certification like AW security specialty, CISSP, CCSK, or even CISA, incident response is one of the most important topics to understand. So let's go ahead and speak more about incident response. So before we go ahead and discuss incident response, the first thing that we need to understand is the first word, which is what is an incident? So, in security terminology, an incident isn't even something that poses a threat to information or computer security. So we can understand it with a better example that we have in the next point. So some of the sample incidents can be relatedto unauthorised access, some kind of attempts maybe failor successful attempts to break into systems, theft orloss of equipment that contains sensitive information, etc.Etc. So I'll give you one of the real-world use cases. In one of the organisations that I have been working with, one of the security engineers gave access—basically, he gave puddle access—to one of the critical security systems to one of the developers. And during the user access review, we came to know that a developer had pseudoaccess to one of the critical security systems. So that comes under unauthorised access. And once we realised that the part was done, our incident was raised. So this is how it really works. Let me give you one of the examples again. In one of the previous organisations, one of the security engineers was my colleague, and he accidentally shut down one of the anti-malware malware server.So that server acted as anti-malware as well as the IPS system. And by mistake, instead of shutting down some other EC2 instance, he shut down the IPS and the anti-malware server. And again, an incident was raised because once the server was not functioning in a way, it posed a threat either to the information or to the computer's security. So, for example, suppose a USB device containing sensitive information is stolen. So this is again an incident. One example is when a developer commits his AWS access secret key to a public repository. So this again is termed an "incident." So let me give you some more examples of the incident. So this is AWS guard duty. So we'll be discussing more about guard duty in much more detail. But if you'll see over here, it gives a lot of information, like that this specific IP61, 107, or 82212 one is performing SSH bruteforce attacks against a specific instance ID. So again, if you go down, you see 181-5713617, so this specific IP is performing RDB bruteforce attacks against the specific instance ID. So this can be termed an incident because someone is actually trying to break into your organization. So this can be termed an incident. Along with that, any event that poses a threat to information or computer security can also be termed an incident. something similar to what we discussed. Someone has shut down the IPS server, so that's a threat to computer security because we weren't actually aware of what was going on. So that can be termed an incident. Now the question is, what happens once an incident occurs? and that is something that is part of the incident response. So incident response is an organised approach to address and manage the aftermath of a security incident in an organization. This is very important because once an incident has occurred, it is important to know how to overcome that specific incident. So again, we were discussing the fact that someone is trying to do SSH brute force attempts or someone is trying to do RDP brute force attacks. So this is an incident. Now, an incident's response is what? What you can do is you can block this specificIPS in the network ACL or in the security group. So that can act as an incident response. So incident response is the organised approach. So it's not like a system engineer or security engineer decided, "Okay, there seems to be RDP brute force, just block them from the network ACL or block them from the firewall." This can definitely be done, butideally it is an organised approach. So we will be discussing the organised approach in the upcoming lecture. But basically, there should be some kind of process that needs to be followed. So it should not be like a security engineer is googling, "Okay, I'm having a brute force attempt. What can I do?" So that should not be done. There should be an organized, systematic approach that the incident response team should follow when a specific incident would occur.So coming back to the PowerPoint presentation, the main goal of the incident response is to handle the situation in such a way that limits the damage, reduces the recovery time, and lowers the overall cost. So this is what incident response is all about. Now again, some of the challenges that we have been discussing in the previous few lectures as well are that most of the incidents are generally reported by a third party, which can either be direct clients, governments, or hosting providers as well. So most of the organization, they are notaware that they are getting attacked or theyare not aware that they are actually compromised. So as we have been discussing, there has to be a very robust security monitoring solution that will give a lot of insights related to what users are actually doing, whether they are doing some genuine activity or whether they are trying to do some kind of brute force attack or something very similar. So many of you might say, "Okay, my organisation is ready," so let's look into some of the use cases to see whether your organisation is really ready to deal with security. Even so, these are some of the high-level use cases that we will be discussing now. First, do you have a solution to detect brute force attacks on your server? So if someone is performing brute force attacks, do you have some kind of solution, maybe a log monitoring solution, or maybe something like OS X that would automatically block those brute force attacks and also send an email to the security engineer that someone from this IP is sending a lot of brute force attempts? So this is first. Second, do you have any solution to identify when someone makes critical changes to your file? So if you have some important security configurations on your server and someone modifies them, do you have any solution that will identify and alert you if someone modifies the critical file? Next, do you have any solution to identify if servers are sending traffic to unexpected locations? So, if you have an e-commerce website based in India and you know that the majority, if not all, of your clients will be from India, and you suddenly see a huge spike in traffic where someone from Russia is contacting your server back and forth, Do you have any control over identifying that unexpected traffic? Then do you have any solutions to identify if someone is trying to do web application-based attacks like SQL injection attacks or cross-site scripting? Do you have any web application firewalls that can actively detect and alert when those attacks occur? Then, do you have any solution to track what exactly users are doing within your network? So, while AWS cloud trailers are one thing, when it comes to Linux servers, most organisations do not have a solution that can provide a robust level of detail into what exactly a user is doing. So if I ask you what user A did on January 9, 2018, will you be able to show me the exact logs on what user A did on server A? So this is something that is quite important, whether you are able to do that. Another solution is to identify. Do you have any solutions to identify when someone is scanning your network? So do you have some kind of IPS solution or idea for a solution that can scan for various attacks like port scanning, which is generally done with the help of Nmap or something similar? So these are some of the common use cases that I relate to, and I'm sure that if you are working as a solution architect, even if you're working as a security engineer, your organisation would lack some of these controls. In fact, most of the organization lacks some controls, even when it comes to common use cases. So when you talk about incident response, the first and very important aspect is to identify that the incident has occurred. So if you are not able to identify that the incident has occurred, the entire process of incident response does not come into the picture. So if you're not able to identify that someone is brute forcing against your server, there is no point in having an incident response process, which would give you a detailed guideline on what you can do when someone is doing a brute force attack against your server. So incident response and security monitoring are directly interconnected with each other. And in the upcoming few lectures, we will be discussing more about how we can solve some of these use cases.

7. Incident Response Use-Cases for Exams

Hey everyone and welcome back. In today's video, we will be discussing the use cases for incident response. Now in the earlier video, we already discussed the basics of what an incident is as well as what incident response is all about. Now definitely as a security engineer, we should beable to handle the various types of security incidentsthat might be occurring within your organization. Now, as far as AWS is concerned, there are two specific use cases that you should be expected to know as part of your exams. So these two use cases are the exposed AWS access and secret keys. And second, there are two compromised EC instances. And if you look into these two use cases, they are very common in a typical organisation that is using AWS. Specifically, the first one exposed AWS access and secret keys and even compromised EC2 instances, which are very common use cases. Now in this exam, you will be tested on the incident response steps that you would take on each of these specific incidents if they occurred in an organization. Now, let me quickly show you the exam blueprint so that you can know where exactly these things lie. So this is the exam blueprint, and within the 1.1 section, if you'll see over here, first is evaluating the suspected compromised instance, and second is exposing accident secret keys. So there are two scenarios that are defined within your exam blueprint, and there will be certain questions that will evaluate your knowledge on what you would do in case these incidents occurred within your organization. Now, definitely, it's not about what you would do; it's about what is the best practise when one of these incidents occurs? So this is it. In today's video, I just wanted to give you an overview of the use cases that we will be preparing for. So in the upcoming videos, we will start with the incident of exposed AWS access and secret keys. We'll look into what steps you should be taking as part of the incident response plan, as well as into the compromised EC2 instances and what other steps you should be taking if you have a compromised EC2 instance within your organization.

8. Use Case - Dealing with Exposed Access Keys

Hey everyone and welcome back. In today's video we look into the incident response planfor one of the use cases which is specified withinthe exam blueprint which is the exposed access keys. Now, generally exposing access and secret keys is one of the most common use cases that you will find in most organizations, typically because they typically allow all the developers to have their own access and secret keys, and the developers end up posting them either on GitHub or in a public repository. So as a security engineer, you should be aware of the steps that you need to take when your organisational access and secret keys are compromised. Now, there are certain steps that AWS recommends in such a scenario. Now these steps are mentioned in the form of five pointers. Now don't worry, this lecture is not going to just be a theoretical lecture. In fact, we are going to speak about a very interesting part of a temporary credential. So this is very interesting and this issomething which I have seen a lot ofpeople are not really aware about. So let's begin and discuss each of these points. The first thing you should understand is that once your access and secret key are compromised, such as when you know that a specific access and secret key are compromised, you should be able to determine the access that is associated with those keys. So, consider the following scenario: you have an access key and a secret key that are used in your production application, and those access and secret keys are compromised. Now, if you delete or disable those access and secret keys, you are sure that your production application will go down, and your business will be impacted. What you should do in those cases is now in those cases, first thing you shoulddetermine what are the access which is associated. So let's assume that the access associated with the exposed keys is that the key has read and write access to very sensitive data. Now, in such cases, you should disable the access immediately. In such scenarios, a production application going down is not that impactful when it comes to your very sensitive data getting leaked. Now, in the second use case, you have exposed keys, which have read access to a public S3 bucket. Now, this is not a very impactful situation, but you know that if you disable these keys, your production application will go down. So in such a case, you can let the keys remain functional, and during the night hours, you can generate a new key and deploy it in the application. So this is just a simple scenario that we have looked into, which will help you understand this specific pointer. Now the second pointer is invalidating the credentials. Now, there are two ways in which you can invalidate a credential. First is you can either disable the Credentialor second is either you can delete it. Now, an important part to remember is that, ideally, the best practise says that you should disable the credential instead of deleting it. Because if you disable the credential, there are chances that you can enable it back in case certain situations arise, but if you delete the credentials, you will never be able to get it back. Now, I'll give you one of the use cases—in fact, one of the real-world use cases that has happened within the organisation where I was working on it. So we had an accident secret key that was compromised, and the access associated with those accident secret keys was SQS related. Read and write. Now, we went ahead and disabled these credentials. Now what happened? The production application went down, and the business guys came and said that we cannot really afford this thing right now; just enable the keys because there was a huge impact made to the business. So we went ahead and re-enabled those access and secret keys, and then we went ahead and disabled it and generated a new one during the night hours. So in that case, if we had deleted the access and secret keys, the entire production application would have gone down and we would have had to replace the new set of keys on more than 100 servers. Now, I'll just quickly show you what exactly this point is all about. So before we move to the third point, which is a very interesting point, I'll just quickly show you this specific aspect. So if you'll see over here, I have a username as "grantee user," and the grantee user has a specific access and secret key. Now, there are two ways of invalidating this. One is to make it inactive, and the second is to directly terminate it. Now, if you make it inactive, this is something that is recommended as an ideal solution. So by making it inactive, there is the possibility that you can make it active again. However, if you terminate or if you delete these credentials, you will never be able to get them back. And this is the reason why disabling access is the recommended value. Now, the third pointer states that invalidating any temporary credentials that might have been issued with the help of exposed keys Now, if you think that disabling a credential or deleting the access and secret keys is a short-cut way to ensure that the attacker will not be able to use the credentials for malicious purposes, that is the wrong idea. Now, I'll show you this with a practical example so that it will become much more clear to you. So let me do one thing. I'll quickly add a user, I'll name it Hackerone, and we'll give it programmatic access. Let me just attach administrator access forthe time being for our demo andI'll click on create a user perfect. So now we have access and a secret key. I'll copy the access key ID, and I'll do a quick AWS configure here. So let me paste the access key ID over here, and let me also paste the secret key. Perfect. The region would be us. East one. So let's quickly double-check with the AWS's three LS. Perfect. So now we are able to see all the buckets within my AWS accounts. Now, from this access and secret key which we haveconfigured, so from this access and secret key, it ispossible to generate a temporary credentials from this. So we will be discussing more in detail about the temporary credentials in our identity access management lecture. But for this demo, I'll quickly go ahead and generate temporary credentials from my long-term access and secret keys. So, the command to generate temporary credentials is AWS STIs get a session token. You press Enter, and as you can see, you get three results. You got a secret access key, you got a session token, and you got the access key ID. So you can use these three things to perform the same things that you are doing with the help of long-term access and secret keys. Now, one difference between these temporary keys and the long-term keys is the expiration. So the temporary tokens will expire after a certain period of time, and the long-term fees will not expire unless you explicitly disable or delete them. So this is my text file, and within our AWS credentials file we'll use all of these values. So I'll go to my AWS credentials, and within this we'll create a profile. I'll name the profile attacker. And the first thing that we have to input is the AWS access key ID. We have to put in the AWS secret access key. And the third is an AWS session underscore token. So these are the three parameters that we have to input. So let's take each one by one. So I'll copy this access key ID and paste it there; I'll copy the secret key and paste the secret key, and the last thing we'll do is I'll copy this token and paste it over here. All right. So, to see if everything is working properly, we can run AWS S 3 and give the profile a name. Perfect. So now you see, with this temporary credentials weare able to perform all the activities that wewere able to do with the long term credentials. Now, let's assume that your keys associated with the hacker user are compromised. So what would you ideally do? In fact, what I have seen a lotof organisation doing is they either make itas inactive or they either delete it. So let's look into what would happen if I made it inactive. So now I have made it inactive. So now let's do one thing; let's do AWSS three LS and look into whether we are able to perform the operation or not. And if you look over here, it says invalid access key ID. It is basically saying that this key ID is inactive. Now comes the interesting part: let's try it with the attacker's profile, and you'll see that I am still—or we are still—able to use those temporary credentials, which is why it becomes quite dangerous. Most of the organisations that I have seen, they eitherdelete it or they either make it as inactive. Now even if you delete it, the temporary credentials that are generated will still work. So you might assume that I have deleted these accesses and secret keys. Now attacker will not be able to do that butin fact if he has undertook temporary credentials he willbe able to still do things perfectly fine. So now the question comes: What is the ideal way to deal with such scenarios? And the ideal way is to add explicit denial policies. Now let's go add an inline policy Now, you can either choose a service over here. Let me just select a random service. Let's select auto scaling.For the time being, I'll put all the actions and, for the resources, I'll select all resources, click on review, and I'll see it as an explicit deny. I'll go ahead and create a policy. Let us now do one thing: click on Edit Policy. I'll go to the JSON, and within the actions I'll just remove the auto scaling. So now we have actions for asterisk and resources for asterisk. I'll go ahead and review policy, and now our policy is explicitly denied. So actually, currently, it is still allowed. So we missed one thing, we haveto add a deny over here. So this policy will deny all the operations that are generated for this specific user. So I'll click on save changes perfect. So now that you have gone ahead and done AWS three-LEVELS, you are still able to do that. So let us quickly confirm that everything is in order. So, if you see over here, our denial policy has kicked in, and you now have access denied over here. So let's try this out again. Perfect. So the "access denied" policy is put into effect. So in case I remove this policy and now you see that you are able to view all the ST buckets again, So do remember that there are two things that are not really important: even if you delete your keys, an attacker will not be able to use the temporary tokens. So in fact, let me just delete the key so that we can explore all the scenarios. So currently I have deleted the keys, and if I doAWS SLS, you see, I'm still able to do that. So, do remember that deleting or disabling the keys is not a very idle solution. There are two ways: either you add an explicit deny or you just remove all the policies that are associated with the user. So I'm sure you get what the.3 is all about now. Now, just one part that you should remember is that these temporary credentials that we generate either stay for 15 minutes or for 36 hours. So remember that disabling or deleting your keys will not help you protect against those temporary credentials. Now, point number four is to restore the access with the help of new credentials. So, if you've disabled or deleted your keys, it's possible that your application or some of its functionality has gone down. So you disable or delete the keys, and you generate a new key pair and give it to the specific principle. Again, it is recommended that instead of using long-term access and a secret key, you always make use of IAM roles or federation. Last but not least, you should always review the activities that were performed with those access and secret keys. It's possible that you don't have an access and secret key associated with the administrator privilege, which was exposed, and the attacker created another im user with the same privilege. So you should always verify the things that were done with those exposed access and secret keys. Now, in case some of your sensitive data was modified within your S3 bucket, you should go ahead and restore it with the SD from a newer timed backup.

9. Use Case - Dealing with compromised EC2 Instances

Hey everyone and welcome back. In today's video, we will look into the incident response steps that you should take when it comes to the compromised EC two instances. Now, a compromised EC2 instance again, like exposing secrets, is one of the very common use cases that you will find in a lot of organizations. Now, there are certain steps that are recommended that you should be dealing with in such a use case. So these are the five steps that are present, and for the exams it is very important to know each and every step because you might get a question about these specific scenarios. Now, the first step is to lock the instance down. So generally, if your instance is compromised and that instance is basically brute forcing or attacking other servers that do not belong to your account or your environment, that is a troublesome approach. So, as a first step, you should secure that instance. So your instance would not be a malware spreader, and it would not be an attacker machine. So this is basically a very important step. And, in general, your instance should only be accessible from a server or a simple-to-create instance that is only used for forensic purposes. So only a machine that will be used for forensic purposes should be allowed to connect to your compromised instance and disk. Nothing should be allowed to go inside or go outside. Now, within this pointer, automation is a key aspect. I'll give you an example because we used to follow this approach in one of the organisations where we used to have a script. So there used to be a GUI, and within the GUI we used to post the instance ID and the script, and it would automatically remove all the security groups within that instance and put only one security group called "4 and 6," and that security group allowed the connection from one of our forensic machines. That was it; nothing else was permitted. So automation is the key over here. As a result, the situation was never jeopardized. However, if the instance is compromised, we just have to put the instance ID and the script used to handle the rest. So this is the reason why automation is the key here. A second important pointer is EBS snapshots and memory dumps. This is a very, very important point to remember. Make sure that you should take a EBS snapshot. So EBS snapshot will basically ensure that all yourfiles there would be a malicious script, there wouldbe a malicious binary within your EC two instance. As a result, EBS snapshot will ensure that all of those files and malicious scripts are captured for later use in forensics. However, just taking an EBS snapshot is not enough because it might be possible that there is a malicious script that is already running within your memory. And this is the reason why having a memory dump is also important. Make sure that you also ensure that a memory dump of all the processes is being taken, and both the EPA snapshot and the memory dump will together help you do the forensics. The pointer four and the pointer five perform the foreign six and terminate the instance. So ideally, four and six are done based on the EBA snapshot as well as the memory dump if certain things are not being done correctly. So if you suspect that certain processes are not part of the memory dump, you still have the live EC2 instance, which is still isolated, for which you can do the forensics directly. So once forensics are done and RCA, which is root cause analysis, is done, it basically says the root cause of why the instance was compromised. So once the forensics are done and the RCA is released, you can go ahead and terminate the EC 2 instance. Now, an important pointer for the certification is that you are not really expected to know the step-by-step process to maybe perform an EPA snapshot or maybe to perform a memory dump EBS snapshot. I'm sure you already knew because it was part of the associate level certification. But detailed steps related to how you can perform memory dump forensics are not expected in this exam. So the only thing that is expected is these five pointers that we have discussed in this video.

10. Incident Response in Cloud

Hey everyone and welcome back to the Knowledge Pool video series. And in today's lecture, we will be discussing more about incident response in terms of the cloud environment. So, whenever you choose a cloud environment for your organisation and you have an incident response plan, a lot of things change, and some things become much more difficult. Like for example implementing of IPS inthe cloud is one of a challenge. However. There are many of the things which will becomemuch more easier like auditing the infrastructure environment withcloud trail config you have guard duty and thereare a lot of services which will make mostof the things related to the incident response planningmuch more easier way and what AWS expects you As a security engineer, you should be aware of what tools and methodologies will help you with overall incident response management. So before we actually start, let me just show you the syllabus paper within domain one of incident response. If you look at.1.2, you'll notice that it says, "Verify that the incident response plan includes relevant AWS services." So AWS actually offers a lot of services that can help you in your incident response plan, and as part of the security certification, understanding which services will help you during the incident response plan is what is expected in this domain. So let's begin with this slide. So, AWS provides various visibility, security, and automation controls that can help us overall in the incident response process. Now, when we use cloud environments, many of the things related to detection, reaction, and recovery become much easier and faster. So we'll be discussing this point in the upcoming slide. So, in terms of AWS, with the help of various tools, AWS actually provides various tools such as AWSconfig, cloud trail, guard duty, AWS cloud watch, and there are various other services that will basically help us to track, monitor, and analyse various security-related events. So when you talk about incident response processes, a typical incident response plan has several steps. One is preparation, detection, containment, investigation, recovery, and lessons learned. Don't worry, we don't have to like in exams; they won't ask which phases there are after preparation or which phases there are after containment. The exam is more focused on your ability to implement various AWS services that will help in each of these phases. So, let's start with one of these phases and investigate what it entails as well as the relevant AWS services that can assist us in that phase. So the first is the preparation phase, and this is one of the most important phases of the incident response plan. So in this phase, we have to make sure that proper security controls are in place that will help us in the detection of animals within the infrastructure. As an example, during the phase, ensure that logging is enabled using Cloud TrailVPC flow logs logging of EC in two instances. Second is using AWS organisation to separateaccounts to reduce the blast surface. So in many of the organisations you see, there are separate environments. You have dev staging and production, and each of these environments has a different AWS account. So all of that falls under the category of preparation. So let's assume that you have not enabled Cloud Trail Logging or VPC Flow Logging. Now, once the incident occurs, you will not really have any logs at all. So the detection phase will not work without the preparation phase. So in the preparation phase, you ensure that all the security controls are enabled and are working properly. So once you have the preparation phase properly,you can then go for the detection phase. So detection is again one of the most important. If you do not know if something is going wrong, you will not be able to respond to it. If you're not able to recognise that there is a brute-force attack going against your server, you will not be able to respond to it. In order to respond, you need to firstunderstand that there is an ongoing attack orthere already has an attack which had occurred. So this is what the detection phase is all about. Now, one of the important parts duringthe detection phase is the behavioural baserules by identifying or detecting breaches. Now let me actually show you. So if you do Splunk user behaviour analytics, this is one of the amazing things that Splunk offers as part of the threat intelligence platform. So again, this is a premium solution. So this actually does user behavioural analysis, and a lot of enterprise organisations are using these kinds of approaches as part of the detection phases. So we'll be discussing this in the relevant section. So let's look into some of the steps during this phase. There have been numerous AWS console sign-in failures in the last hour. So this can be achieved with the help of the integration of Cloud Trail and Cloud Watch. So you can set up Cloud Watch alarms, which will detect that there are more than three login failures in the past five minutes. So if there are three login failures in the past five minutes, alert us. So this is one of the examples of detection phase seconds, which is related to user behavioural analytics. like if a user is logging in at 3:00 a.m. in the morning and launching new servers. So for the past year, the user has never logged in at night, at 03:00 a.m., but suddenly, you find that the user is logging in at 03:00 a.m. And he's engaged in a lot of activity. So that is some kind of suspected behavior. So those behaviours should be detected at the detection phase. Now, there are a lot of AWS services that will help us in the detection phase. like a cloud trail. You have Cloud Watch; you have SNS; you have guard duty, and many more. So next is the containment phase. So once we have identified that the incident has occurred or is occurring, it is ideal for containment to happen. So in the earlier presentation we were discussing theuse case of malware where if a server isinfected with malware, the first step which was partof the incident response plan was to remove thenetwork associated with the server so that the malwaredo not spread to other servers. Similarly, the containment phase is very similar, where you try to contain the breach, and it is preferred that you use some kind of automation to help you contain the resources. Now, ideally, with AWS, we can use AWSCLI or SDKs for quick containment using some kind of predefined security group. So let's understand this. So if you have identified one server that is infected with malware, you can quickly run a predefined AWS CLI command associated with the infected instance ID, which will attach a restrictive security group both inbound and outbound and remove the earlier security group. So there should be a restrictive security group that only allows traffic from a specific IP address and does not allow traffic from the machine to leave the machine. So there should be a certain predefined security group. And whenever you find that the servers are infected with malware, what you can do is run the CLI command, which would automatically attach those predefined security groups to those two instances. So this is where AWS CLI and automation will help you. So, after you've contained the server, the next phase is the investigation phase, in which you conduct forensic analysis to determine what exactly happened in that server. So again, a lot of services like AWS Cloud Watch, which will help you analyse the logs of the server, will help you determine what has occurred inside the server. You can also make use of AWS configuration to see the infrastructure timeline: what was the infrastructure yesterday and were there any changes today? Were there any security groups that were opened? So you need to look into that phase as well. So again, you have a lot of services that can help you during the investigation phase. Finally, once you've identified the source, such as whether the application was vulnerable and was exploited, the recovery phase begins. So once you have been identified during the investigation phase, now it's time to recover. So again, during the recovery phase, automation plays a very important role. So you can use a pre-built AMI for the application to launch a fresh new application server and terminate the server that was infected. So these can be used for recovery phases. The final phase was definitely the lessons learned, where you actually write down what the lessons were, what was missing, and what you learned and implemented as part of the additional security controls. So this is it for this lecture. Now, one important thing, as you might have noted, is that we have not really discussed various services, like Cloud Watch Conflict; those services will be discussed in greater detail in the upcoming sections in greater detail.So this was just a high-level overview related to exam pointer 1.2, so that's how we can know what exactly that point is all about.

Pay a fraction of the cost to study with Exam-Labs AWS Certified Security - Specialty: AWS Certified Security - Specialty (SCS-C01) certification video training course. Passing the certification exams have never been easier. With the complete self-paced exam prep solution including AWS Certified Security - Specialty: AWS Certified Security - Specialty (SCS-C01) certification video training course, practice test questions and answers, exam practice test questions and study guide, you have nothing to worry about for your next certification exam.

Hide