Traceability Loss - AWS

Need

Enhancement of traceability and logging in AWS instances

Context

• Usage of Terraform for Infrastructure as Code (IaC)
• Usage of aws-sdk for interacting with AWS services and resources

Description

Non compliant code

resource "aws_instance" "example" {
  ami           = "ami-0c94855ba95c574c8"
  instance_type = "t2.micro"

  tags = {
    Name = "example-instance"
  }
}

resource "aws_elb" "example" {
  name               = "example-elb"
  availability_zones = ["us-west-2a", "us-west-2b", "us-west-2c"]

  listener {
    instance_port     = 80
    instance_protocol = "http"
    lb_port           = 80
    lb_protocol       = "http"
  }
}

resource "aws_s3_bucket" "bucket" {
  bucket = "bucket"
  acl    = "private"
}

In the above Terraform code, we are creating an AWS EC2 instance, an Elastic Load Balancer (ELB) and an S3 bucket. However, there is no logging enabled for any of these resources.

1. EC2 Instance: The EC2 instance is created using the aws_instance resource. The ami and instance_type properties are set, and a tag is assigned to the instance. However, there is no logging property set for this instance, which means that no log files are being created for this EC2 instance.

2. ELB: The ELB is created using the aws_elb resource. It is set to listen on port 80, and is associated with three availability zones. However, like the EC2 instance, there is no logging property set for this ELB.

3. S3 Bucket: The S3 bucket is created using the aws_s3_bucket resource. The bucket is set to private, but again, there is no logging enabled for this bucket.

The absence of logging in these resources means that it is impossible to identify and trace malicious actions or anomalous behaviors. In addition, even if logging was enabled, the log files do not have a detailed level of information, which limits their usefulness.

Steps

• Set the logging property for the EC2 instances to enable logging of activities and events.
• Configure the ELB to enable access logs, which will capture information about incoming requests.
• Enable server access logging for the S3 bucket to track access to the bucket and its objects.

Compliant code

resource "aws_instance" "example" {
  ami           = "ami-0c94855ba95c574c8"
  instance_type = "t2.micro"

  tags = {
    Name = "example-instance"
  }

  monitoring = true
}

resource "aws_elb" "example" {
  name               = "example-elb"
  availability_zones = ["us-west-2a", "us-west-2b", "us-west-2c"]

  listener {
    instance_port     = 80
    instance_protocol = "http"
    lb_port           = 80
    lb_protocol       = "http"
  }

  access_logs {
    bucket  = "my-access-logs-bucket"
    enabled = true
  }
}

resource "aws_s3_bucket" "bucket" {
  bucket = "bucket"
  acl    = "private"

  logging {
    target_bucket = "my-log-bucket"
    target_prefix = "log/"
  }
}

The above code fixes the vulnerability by enabling logging for EC2, ELB, and S3 instances.

1. For the EC2 instance, the monitoring property is set to true. This enables detailed monitoring, which provides additional instance metrics and logs.

2. For the ELB instance, the access_logs block is added. This block enables access logs for the load balancer and specifies the S3 bucket where the logs will be stored.

3. For the S3 bucket, the logging block is added. This block enables server access logging for the bucket. The logs are stored in the specified target bucket with the specified prefix.

References

• 400.Traceability Loss - AWS