Lecture Transcript

Hello and welcome to this lecture covering users. I want to define how Amazon Macie classifies users and the different user types available that I briefly mentioned in the previous lecture when looking at the CloudTrail User identity types within the dashboard. Let me first start out by talking about the users section within the console. You may recognize the platinum, gold, silver, and bronze categories which are always present on the dashboard. But this users screen provides additional information surrounding this metric. This screen essentially shows the different users that have been identified via CloudTrail data when linking to API calls. Depending on the history of those users will dictate how Amazon Macie classifies them between these four category ratings which ultimately reflect the level of perceived risk that those users pose. Let me define the differences between these categories a bit further. 

Platinum. A user or role placed within this category is considered to make regular high risk API calls such as DeleteFlowLogs or UpdateTrail. These can often be contributed to users with administrative privileges, such as the root account. Due to the amount of control and elevated permissions these users pose, you should monitor their activity for any signs of compromise. 

Gold. Users or roles categorized as gold will have been identified through their use of calling and making API requests relating to infrastructure changes, such as CreateRouteTable or RequestSpotinstances. Again, due to the permission level of these power users, they should also be monitored to ensure that they are not compromised in any way. 

Silver. As we progress down the track, users or roles in the silver category are identified as performing medium level risk API calls. Remember, these risk levels are managed by Amazon Macie and automatically assigned these risk levels to the API calls. As an example, a medium level risk API could be DescribeRouteTables or ListObjects. 

Bronze. Users or roles in this category provide the lowest level of risk due to history of their API call usage, which may include API calls such as DescribeSubnets and DescribeHosts. 

These categories give you a very quick visualization as to how many users are operating with potentially over-elevated permissions. This allows you to drill down into these users further to ascertain exactly what tasks they are performing. On the main page of the user screen, you'll see a list of users that Amazon Macie has identified. These users are categorized under the DLP, data loss prevention value column. It also provides a high level overview of the most recent activity, total events, errors, and unique IP addresses that have been attributed to that particular user. However, should you wish to investigate a particular user and gain further insight into events surrounding them, then you can click on their name within the user column. This will then provide you with a condensed version of the dashboard discussed in the previous lecture, with metrics and data that only relate to that user in question.

In this example, you may recognize the dashboard icons at the top where we have views relating to high-risk CloudTrail events, high-risk CloudTrail errors, activity location, CloudTrail events, activity ISPs, and CloudTrail user identity types. Again, these metrics in each view will only relate to events and data associated with that specific user. The last point I want to discuss in this lecture is how Amazon Macie defines user identity types, which is used in the main dashboard and the condensed dashboard for each specific user. 

Amazon Macie identifies user identity types from the CloudTrail logs that it monitors and analyzes. Specifically using the user identity element from the events in the logs. The different user types are defined as follows. 

• Root. This means that the request was initiated by the root account of your AWS account. 
• IAM user. Here the request was made by an IAM user. 
• Assumed role. This identity type defines that the request was made by credentials that were temporarily assumed having been obtained by calling the assumed role API for the security token service. 
• Federated user. Here the request, again, was made with temporary credentials but this time from calling the AWS STS GetFederationToken API. 
• AWS account. This simply defines that the request of the API was made by a different AWS account. 
• AWS service. Here the request was made by an AWS service rather than a particular user. 

That now brings me to the end of this lecture. Coming up next I will be discussing the research functionality of Amazon Macie.