Study Guides/AWS Cybersecurity Notes/Logging and Monitoring - Revision history

Mflavell: /* AWS Cloud Trail Lake */

2026-06-03T00:48:19Z

AWS Cloud Trail Lake

← Older revision		Revision as of 00:48, 3 June 2026
Line 477:		Line 477:

	:* Provides the ability to query multiple accounts.		:* Provides the ability to query multiple accounts.


			What format does it use:

			:: Uses an Apache based ORC format - not JSON!

			:: These re row-based - columnar format is effiecent (like SQL!)

Mflavell: /* Logging API Activity with CloudTrail */

2026-06-03T00:46:23Z

Logging API Activity with CloudTrail

← Older revision		Revision as of 00:46, 3 June 2026
Line 435:		Line 435:

	:* Prevents somone accessing a bucket turing off or deleteing logs.		:* Prevents somone accessing a bucket turing off or deleteing logs.


			== Event history in CloudTrail ==


			:* You can query 90 days maximum.

			:: Beyond this you will need to use a third party tool or extact the compessed logs to S3.


			== AWS Cloud Trail Lake ==


			This enables large scale ananyls of AWS cloud trail logs.

			This uses three tools:

			:: S3

			:: Athena

			:: AWS Glue

			Together they create a data lake that can store logs for an extented period.


			Important point for the exam: Cloud trail limits to 90days - you can use Cloud Trail Lake to go beyond this.


			Why use Cloud Trail Lake:

			:* Deeper insights - more data.

			:* Auditing and compliance.

			:* Provides a central log storage location.

			:* Easier to perform ad-hoc queries.

			:* Easier to create custom repots.

			:* Provides the ability to query multiple accounts.

Mflavell: /* Logging API Activity with CloudTrail */

2026-06-03T00:17:26Z

Logging API Activity with CloudTrail

← Older revision		Revision as of 00:17, 3 June 2026
Line 401:		Line 401:

	::* Tails can only be viewed in the AWS regions where events are logged.		::* Tails can only be viewed in the AWS regions where events are logged.


			== Creating new trails ==


			by Default could trail is enabled in accounts.

			:: It's important to ensure the integrity of all cloudtail logs.

			:: Creating an additional trail is a mitigation tactic:

			::: If something happens to the data in the original trail - you have another.


			:: This could be useful if both security and developers need access to could trail data.

			::: Two seperate tails can be created that are isolated.


			== Data events in s3 buckets ==


			:* These are much like S3 access logs.

			:: They are stored in CloudTrail instead of S3


			This setup is useful when using multiple accounts:

			:* All cloud trails flow to a seperate logging account.

			:* This can use a central account to track all s3 activity.

			:* Prevents somone accessing a bucket turing off or deleteing logs.

Mflavell: /* Logging API Activity with CloudTrail */

2026-06-01T00:48:55Z

Logging API Activity with CloudTrail

← Older revision		Revision as of 00:48, 1 June 2026
Line 371:		Line 371:

	::* Activity filters - These provide a search function when checking API history.		::* Activity filters - These provide a search function when checking API history.


			== Types of CloudTrail Events ==


			::* Management events - Capture management operations.

			::* Data events - Events reproted as part of a specfic trail.

			::: There are costs associated with capturing data events.

			::: Best to develop a statergy concerning the about of data and retention period.

			::* Insight events - these are not logged by default but can be turned on.

			::: When on these capture rate alarms & error rates.

			::: These help determine what is normal and abnormal on the account.


			== Default CloudTrail Settings ==


			::* Enabled for the AWS account when you create it.

			::* Logs are encrytptred with SSE (Server side encryption) / Can be changed to KMS key encrypted.

			::* Logs are published about every 5 minutes.

			::* Tails can only be viewed in the AWS regions where events are logged.

Mflavell: /* Logging API with CloudTrail */

2026-06-01T00:26:19Z

Logging API with CloudTrail

← Older revision		Revision as of 00:26, 1 June 2026
Line 340:		Line 340:


	= Logging API with CloudTrail =		= Logging API Activity with CloudTrail =


			This allows for compliance, governance and auditing though the logging of API calls.

			Logs calls made via:

			::* AWS Management console

			::* AWS CLI

			::* AWS SDK's

			::* Third party tools using the AWS CLI


			Can be used in multiple regions if needed.

			When AWS Organizations is used - logs from all accounts flow up into the audit account.


			== Components of cloudtrail ==


			::* Trails - Contain the options you want monitor to track.

			::* Events - When an API call is made this is an event in CoudTrail.

			::* Logs files - Logs are saved every 5 minutes to a S3 bucket.

			::* Activity filters - These provide a search function when checking API history.

Mflavell: /* Publising logs to Kinesis Data Firehose */

2026-06-01T00:04:25Z

Publising logs to Kinesis Data Firehose

← Older revision		Revision as of 00:04, 1 June 2026
Line 329:		Line 329:

	=== Publising logs to Kinesis Data Firehose ===		=== Publising logs to Kinesis Data Firehose ===


			When sending data to the Kinesis Data Firehose the following permissions must be enabled:

			::* logs:CreateLog Delivery

			::* firehose:TagDeliverySystem

			::* iam:CreateServiceLinkedRole


			= Logging API with CloudTrail =

Mflavell: /* Cloudwatch Logs */

2026-05-30T22:16:18Z

Cloudwatch Logs

← Older revision		Revision as of 22:16, 30 May 2026
Line 277:		Line 277:

	= Cloudwatch Logs =		= Cloudwatch Logs =

			Most AWS services can send thier logs to CloudWatch Logs

			It's important to remember what services cannot send to CloudWatch, these are:

			::* CloudFrount

			::* AWS Global Accelerator

			::* Route 53 query resolver

			::* VPC Flow logs


			What do these have in common: Network related / Accellerator related.


			CloudFront is limited to S3 logging only.


			== Required IAM permissions ==

			=== Publising logs to CloudWatch ===


			The user or service must have these IAM permissions:

			::* logs:CreateLogDelivery

			::* logs:CreateResourcePolicy

			::* logs:DescribeResourcePolicies

			::* logs:DescribeLogGroups


			If logs are been sent to a log group the ''logs:CreateLogDelivery'' is important.


			=== Publising logs to S3 ===


			For sending to S3 the following IAM permissions are required:

			::* logs:CreateLogDelivery

			::* s3:GetBucketPolicy

			::* s3:PutBucketPolicy


			=== Publising logs to Kinesis Data Firehose ===

Mflavell: /* Web Application Firewall logs */

2026-05-30T21:58:01Z

Web Application Firewall logs

← Older revision		Revision as of 21:58, 30 May 2026
Line 248:		Line 248:

	::* Metrics will still be captured when the WAF is is blocked / count mode		::* Metrics will still be captured when the WAF is is blocked / count mode


			=== WAF Full logs ===

			This provides details about the type of request that came in - more than just metrics.

			Benfits of full logs:

			::* JSON format

			::* Sensative infomation can be removed.

			::* They can be streamed - Amazon Kinesis Data Firehoze

			::* All request headers are recorded along with the ID of the rule that matching the request.


			These are used for comprehsive infomration.

			Siplified requests don't paint a full picture:

			::* They are limited to 500 logfiles and 5000 requests

			:::* This is not enough imofmration to diagnose a busy firewall

			::* Security often means examining all traffic to gain full understanding.


			= Cloudwatch Logs =

Mflavell: /* Elastic Load Balancer Access Logs */

2026-05-30T20:34:41Z

Elastic Load Balancer Access Logs

← Older revision		Revision as of 20:34, 30 May 2026
Line 235:		Line 235:

	* Target response code		* Target response code


			== Web Application Firewall logs ==

			Cloudwatch is usefull here:

			::* Will provide real time metrics about the AWS WAF and rule matching.

			::* Metrics are published for every rule.

			:::* This includes AWS managed rules and rules you define.

			::* Metrics will still be captured when the WAF is is blocked / count mode

Mflavell: /* Elastic Load Balancer Access Logs */

2026-05-30T20:21:25Z

Elastic Load Balancer Access Logs

← Older revision		Revision as of 20:21, 30 May 2026
Line 209:		Line 209:

	::* Capacitiy planning.		::* Capacitiy planning.


			=== Load Balancer log files ===

			All requests are captures - even if they never hit the desintation.

			::This includes malformed requests.

			:::Malformed requests can be security related - directory traversal attacks


			==== What the logs contain ====

			* Type of request

			* Time of the request

			* The ELB that took the request

			* Cilent port / Target port

			* Processing time - how long the target took to process the request.

			* Status code for the ELB

			* Target response code