Domain 2 - Logging & Monitoring

14. Patch Compliance with SSM

Hey everyone, and welcome back. So, continuing our journey with the Systems manager, today we'll be focusing specifically on patch compliance. So recently, I have been working with one of the startups. One of the challenges with them was that they were running a public facing endpoint and they had an open source application that they were running and they were hacked. On further investigation, we came to know that the reason why they were compromised was because the application that they were running on the public endpoint had a lot of critical vulnerabilities which the attackers were able to exploit. They would have been saved now if they had updated their application with the latest security fixes. And the same goes with the servers as well. Servers also have a lot of packages, and each package might have some kind of security vulnerability that will be exposed today or tomorrow. Now it is necessary to ensure our servers are up to date. Now, there is a feature called "Patch Compliance." Basically, patch compliance allows us to determine the patch status associated with the specific instance. So in the earlier lecture, we installed the SSM agent in one of the EC two instances.

And now within the patch compliance you see that it is showing that one instance is missing the update. Now, how did this appear? Now, in order for all of these things to appear, what you need to do is run a document named AWS Run Patch baseline. So let's try it out. Let's see if we can find it out from here. It seems it doesn't work via search, so let's quickly find it out. Yeah, so this is the one that is the AWS Run Patch baseline. So this is the document name and you have to select the instances by default, since we only have one instance. This is the instance which is selected. So once you've selected it, you can just click on "Run" and this will be executed. So it might take a little time, and once this patch baseline gets executed, you can go to the patch compliance and it will show you the missing updates. Now you can definitely update the packages as well from the systems manager. Maybe it can be done by the "Run" command itself. In the exam, you might be asked, "How can you tell which instance is missing which patch?" And the answer to this should be patch compliance only. So there can be multiple options. But just remember that Patch compliance from Systems Manager allows you to find which instance is missing updates, and in case you want to update the system, you can do it again with the systems manager, with the Run command also. So, a small lecture. I hope this has been informative for you and I look forward to seeing the next lecture.

15. EC2 Systems Manager - Parameter Store

Hey everyone, and welcome back. In today's video we will be discussing the Parameter Store. Now, Parameter Store is a fantastic feature included in AWS's Systems Manager that allows us to offload secrets from development code. So let's go to and understand more about the Parameter Store. Now, going by the definition of AWS Systems Manager ParameterStore, it provides a centralised store to manage the configuration data, whether it is plain text or can be a secret such as tokens or passwords. So let's understand this with a simple diagram where on the left hand side you have an application code and within the application code you have created a function. Within the function, you have now defined two values. One is a username and you have a password. So this is something that I'm sure most of you might be familiar with.

The problem with this kind of approach is that most developers will probably commit this code within the Git repository and it will get leaked. And the second problem is that once the developer commits the code, all the people or all the team members will be able to see the username and password. And in case someone is leaving the organisation, he will take this username and password as a parting gift with him. So this is definitely not a recommended practice. Now, the way in which you can improve upon this kind of scenario is to use a Parameter Store. So on the right hand side, again, you have an application code. Now within this function, the password, instead of hardcoding the password, here you are having a variable where you are getting the password from the Parameter Store. So you have SSN GETPERON. So what you ask your developer to do is ask them to fetch the password from the Parameters Store. So when the application gets built within the EC two instances during the buildtime, this value will be populated. So not only is it good practice, but the developer will not be aware of this specific secret.

So this is a great thing that should be done in the organization. So let's go ahead and do the practical, which will give us a much more clear visibility. So I'm in my EC to console and at the bottom there is an option for Parameter Store. I'll click here and I'll click on Get Started. Now, so this will take us to the option of creating a parameter. Let me create a parameter. I'll name it "RDS password." Within the description, I'll say this is the RDS password, and within the value, let me give a random value. All right, so this is some random value that I have given, and I'll click on "create Parameter." So our first parameter is created, and its name is RDS password, and the value associated with it is the one we specified. So, when the application is deployed within the EC two instance, you could ask the developer to retrieve the value associated with this specific parameter store. So as far as the CLI is concerned, let's look into how we can fetch the value from the AWS CLI. In order to do that, I'll do a double SSM CLI in Google, and it will take us to the systems manager CLI documentation. We are more interested in the Parameter Store service. So I'll just do a Get Parameter and I'll click here. So this is the CLI command that we are interested in, AWS SSN get parameter. And within this, there is a recommended or mandatory value of the name that you need to give. So let's go ahead and look into how we can work on the CLI aspect. So I'm in my CLI and let's do AWS SSN get parameter.

And the mandatory value was the parameter name. Our parameter name was RDS password. If I press Enter, you will see it will give us the value associated with this parameter. And the same thing you can ask developers to do, as we've already discussed, you should give them the parameter name and they will have an SDK or they will go through a CLI to fetch the value which the application will use. So basically, the application will not really have any secrets; it will in turn fetch them from the Parameter Store. So this is the basic about Parameter Store. There is one more part that I wanted to show you, so let's go to create the parameter name. This time I'll give RDS Secure and within the type you'll see there are three types which are available. One is strings. The second type is a string list, and the third type is a secured string. So a secure string is something that secures the storage of your passwords or secrets. So whenever I click over here, it will give us the KMS key ID. So basically, whatever value that you will be putting in, it will be encrypted with the KMS. So, by default, it will take the defaultAWS SSM kms, the value associated with this. Let me give some random values. Now, the difference that you will see over here is that whatever value that you are typing, it is not being shown in plain text, it is actually encrypted.

So if I go ahead and create a parameter within the RDS parameter which is of type string, you'll see the value is directly shown to us. However, if I type on RDS Secure or if I select this, the value is not shown as plaintext by default. However, if you have proper permission, you do have an option in which you can get the plaintext value. So if I click on show, you see it has given us the plain text value over here. So let's look into the difference that it would make us when it comes to the AWS CLI or even the AWS SDK. So within the AWS CLI I'll run the same command, which is AWSN get parameter. The name would be RDS secure and the output that it has given us is the value. Now, if you'll see, this is thevalue, which is encrypted with the KMS. So this is not the plain text value. When you get the parameter associated with thestring, it will now return the plaintext value directly. However, if you do a secure string, it will not return as the plaintext value. This is the encrypted value. Now, in order to have a decrypted value, there is an option within the AWS CLI and within the CLI, if you see, there is the option of with decryption. So with decryption, we will basically tell parameters to give us the decrypted value. You also have no idea with decryption, which is that it will give us the encrypted value. So this is the default choice. So let's do one thing. I will do this with the decryption description. This time it gave us the plain text value. So this is what the parameter store is all about.

16. Understanding CloudWatch Logs

Hey everyone, and welcome back to the Knowledge Pool video series. So, continuing a journey with Cloud Watch Today we'll be looking into the Cloud Watch logs aspect. So let's understand it with a simple example. So generally, if you talk about a typical server, be it Linux or even Windows, each and every server has its own log files. So a server can contain a lot of log files, which can range from system logs to even application logs if an application is running. So whenever you want to debug something, it is necessary that we have access to the log files. Now, in the default behavior, since the log files are stored within the system, if anyone wants to debug a specific thing which is not working, that person would need access to the server. So let's take an example, so you have an application running, a PHP application running on a Linux server.

So for some reason, the PHP application is not running properly as expected and the developer wants to look into the log file. So what you'll have to do in normal behavior is give him SSH access to the developer, and then he will be able to go through the log files. So that is one which is not considered good security practice. Ideally, if you go into an organization that deals with sensitive information, none of the developers have access to the server. By default behavior, no developer will have access to the server. Now the question is, you might ask, if the developer does not have access to the server,how will he debug the log files? And the answer is to centralize the log solution. So, ideally, you'd like to pull the log files from the server and place them in a central location where the developer can examine them. So let me give you one of the examples in order to understand it better. So I'll just log into the server and if you go into the wire log, you'll see there are a lot of log files. Now, let's assume that you want to debug a log file called "viral messages." So one of the approaches to this is that you manually log into the server. You run a tail in the messages file and investigate the troubleshooting aspect.

However, the second and most ideal use case is when you push all of these log files to a central location where one can query them. So in my case, what I have done is, since we are speaking of the Cloud Watch log,I have pushed these files to a central solution. So if you look into the Cloud Watch console, you will see I have a log group named "wire log messages." So if I go here I have the instance ID and now you see I have all the messages which are part of the warlock messages log file. So, similarly, you can even push all the application logs to a central log server. It can be Cloud Watch, RSYS log, elastic search, etc., but the main point is that if you push all log files to a central log server, you don't need to give anyone inside the system access. So this is what the concept related to the Cloud Watch log group is all about. So what we'll be doing is we'll wrap up this lecture and in the next lecture we'll go ahead and look into how we can push the log files from the EC2 instance to a Cloud Watch log group. So that concludes this lecture; I hope you found it informative, and I hope to see you in the next one.

17. Pushing Linux system logs to CloudWatch

Hey everyone and welcome back to the second lecture of Cloud Watch logs. So in this lecture we'll do the practical session and we'll look into how we can push the logs from the Linux servers to the Cloud Watch group. So in order to do that, what we will do is switch to the Oregon region where I have my EC Two instance up and running. So let me just quickly show you. So we have one EC2 instance which is up and running in the Oregon region. And what we'll be doing is we'll be pushing the logs that are generated in this ECTwo instance to a central Cloud Watch log group.

Perfect. So the very first thing that you would need to do is you would have to allow this EC2 instance to create the log group and push the logs there. So let me just show you an example of what I mean by this. So if you go to the Cloud Watch console and go to the logs, you will see there is a log group which is created by the name "Wire log messages." And within this log group, there are a lot of log messages that are created. So in order for the EC2 instance to create the log group and push the logs to the log group which is created, we need to allow that EC2 instance to do these things. So the very first thing that we have to do is to create an im role policy that allows EC Two to achieve those use cases. So let's go ahead and do that. So if I go to the immoral, let's create a new inline policy.

Over here I'll select the Jason, and from the documentation itself, they have already given a policy document. So within the policy document you have seen, the first action is to create a log group. So this is the first thing that it needs to do. Then there is one more action, like putting in log events. So this allows putting the log events from the system into the log group which is created. So we'll use this policy. I'll be pasting this in the resource section, so you can just copy it as well. So we'll take this policy. I'll review the policy quickly, and I'll name it Cloud Watch logs. quickly Click on "Create Policy. Perfect. So now we have a policy which allows ECTwo instances to create a log group and push the events to that newly created log group. Perfect. So now that we have done that, let's go to the Cloud Watch consoles again. This time, since we are working in the Oregonregion, we'll be looking into the logs here. So now you see there are no log groups which are created. Perfect. So what we'll do is create our first log group. Now before we do that. We have to install a Cloud Watch agent on the server and that agent is basically responsible for pushing the logs, so if you do yam install AWS logs, this is the agent which we need to install.

I am running Amazon Linux, so this agent is directly available from the young repository itself. If you're using some different operating system, you can go through the documentation and they have a different approach to achieving the same. So now that I have AWS logs installed, let's quickly verify the status of AWS logs are perfect So the very first thing that we'll do is go to the configuration directory of AWS logs and there are two important configuration files that we need to work into. The first is awscli con f and this is the place where we can specify the region where the log group will be created. So what I'll do is let me perfect solet me change the region from US east one to USwest two, which is the Oregon region where you're working. Once you have configured the Awsli con f, let's quickly also explore the AWS logs con f and if you go a bit down here, you will see that there is one configuration store which is configured, which is for wire log messages. So we can add more log files here so what I'll do. Let's leave it to the default configuration and I'll do service So now that AWS logs have started, you can look into the progress related to AWS logs within the varlog directory where you can do tlsawlogs log.

So this is the log file for the AWS log agent which is running in the easy to instance. Once the configuration file has been configured, you see that you have a new log group which is created which is virloog messages. And within this log group you have all the log files which belong to the files which are specified within the A slogs sooner important One thing that I'd like to show you is that generally when you specify various log files, you have wire log messages, you might even have wire log applications as well, so generally it is recommended to have a different log group name.

Now once you have a different log group name, what you can actually do is restrict the permission associated with each log group, so this viral message is not required for developers. This is more required for the system administrator, so you can create a policy where only the system administrator can read the messages within the wire log messages log group similarly. If you have some application-specific log group, you can create a policy where only certain developers who are in that application team can access the log files within that log group. So these policies can be defined if you have separate log groups that are created. So this is it. About this lecture I hope you found this information useful, and I hope to see you at the next lecture.

Prepared by Top Experts, the top IT Trainers ensure that when it comes to your IT exam prep and you can count on ExamSnap AWS Certified Security - Specialty (SCS-C01) certification video training course that goes in line with the corresponding Amazon AWS Certified Security - Specialty exam dumps, study guide, and practice test questions & answers.