Auditing and notifications - Amazon Web Services (AWS) Tutorial

- [Instructor] There are a number of key AWS services that you can consider for helping you manage your security, for auditing, and for notification when things go awry. First up, AWS Config. This is a service that allows you to define parameters for what should be checked and how you should be notified. These are checks for the resources in your AWS account, your networks, your EC2 instances, your security groups, everything in your stack, i.e. infrastructure. Once you define your rules, AWS, either on a schedule or when there are changes, will check the configuration of the resources and let you know if there's an issue. So it's doing an audit of your account and will also notify you when something's awry. Now, how does it work? Well, you have to tag your resources. A tag is just a descriptor, a key value that describes the actual resource. And when you create any AWS resource, you have the opportunity of adding tags to that resource. So Config swings into action, looking at the resources for the desired settings that you've defined, such as volumes must be encrypted, S3 buckets must be encrypted, MFA must be enabled. You can also retrieve the historical configuration of the resources, because every time Config runs, it creates a report and archives that report. So perhaps you want to look at Config as just a way to find out what has happened in the past, what resources are linked; if I make a change, will I be running into trouble? So it's important to realize that the resources that you use in your AWS account are typically linked together. You might be using a particular security group to protect a number of EC2 instances. You might be using the same EBS volume and having it linked to multiple EC2 instances. So we can gather a lot of information about what's going on in our account with AWS Config. We can also use CloudWatch, the monitoring service, the logging aspect of CloudWatch, which contains all of the information that has been monitored, and CloudTrail events. A CloudTrail event occurs when an API call is carried out against a resource in your account, or somebody attempts to authenticate to your account. These events are logged by default into a generic CloudTrail event log. You can create your own CloudTrail trails, maybe for specific data events or specific regions. The events that are then logged to these custom CloudTrail trails can also be sent to a CloudWatch log. What we can do with that logged information is set alarms. So perhaps, maybe I want to set an alarm when anybody logs into a particular AWS account as the root user, and this alarm will trigger the notification service. And you can decide what the notification should be: manual, text, email, or automation. Or you could define an alarm for any API activity that is carried out by a user that isn't using multifactor authentication. Again, that alarm can be set to trigger the notification service. And in turn, the notification service can notify you in many ways. We also have Amazon inspector. Inspector is a service which can report on security issues and potential misconfigurations of the software found on EC2 instances from a security mindset. We can test the network vulnerability and reachability of an EC2 instance using what's called an assessment template. That will actually ping the ports and see what the responses are back, and see if anything is open which shouldn't be open. We can also look at the state of the applications from a security standpoint, using a rules package. The rules could include common vulnerabilities and exposures, CIS standards, the Center for Internet Security, specific operating system configuration benchmarks, and security best practices followed by the computer industry. So we can get a lot of information, whether we're looking at all the resources, particular activity in our account, or the EC2 instance itself.