AWS Security Speciality - Study Notes

EXAM GUIDE https://d1.awsstatic.com/training-and-certification/docs-security-spec/AWS-Certified-Security-Specialty_Exam-Guide.pdf

General Notes

Domain 1 - Incident Response

Why do hacks happen?

  • Improper firewall config

  • Lack of WAF

  • No server hardening

  • No File Integrity Monitoring (FIM)

  • Patch Management

  • Scan code with Web Application Scanner

  • Monitor for sudden open ports and logs

  • etc.

AWS Abuse Reports

  • AWS sends abuse reports to customers when their AWS resources are being used for abusive purposed

  • In most the cases these abuse complaints are directly linked to "Hacked" servers

  • It's necessary for us to check the "AWS Acceptable Usage Policy"

Who raises the Abuse complaint

  • Can be directly filed by clients who are being affected (AWS client or other)

  • If you are receiving suspect traffic from an AWS resource you can file a (Report Amazon EC2 Abuse form)

AWS GuardDuty

  • AWS Guard Duty is a threat intelligence service from AWS which monitors for malicious behaviour to help customers protect their AWS workloads

  • Has big list of pre-set rules (Check list)

  • GuardDuty Findings (Check list)

  • Charged per GB of logs analzyed it seems

  • Check Sample Findings

  • Can Archive findings so effort is not duplicated

  • Can Supress Findings (via filters or other), give supression a Name and Description so the can be understood

  • Can see full Alert List in doc

  • Guard Duty will only monitor Route53 for DNS logs

  • Lots of orgs use AD DNS, they will not be monitored (Splunk could be used instead)

  • Does not do EC2 Logs (only ones listed above)

  • Guard Duty is quick setup, commercial solutions are long and complicated

Whitelisting Alerts on Guard Duty

  • Ex: Central security server does port scans for Prod

  • Leads to false positives

  • Customer can manage their own "Trusted IP" list, will not generate fidings for it

    • Fields: List Name, List file URL, Format (plantext, etc), Active

  • Customer can manage their own "Threat" list

Managing Guard Duty Centrally

  • Enabling Guard Duty across all AWS accounts is recommended

  • Checking findings across individual accounts is troublesome

  • Member account and Master account

    • Accounts menu, add member accounts

    • Member account will receive invitation in Guard Duty

    • New Organizations way to deal, check docs

Incident Response - Fixing it

  • Incident Response is an organized and systematic appraoch to address and manage the aftermath of a security incident in an organization

  • The goal is to handle the situation in a way that limits the damage, reduces recovery time and the costs

Challenges

  • Most of the incidents are generally reported by 3rd parties, need a robust solution for visibility

Are you ready?

Do you have a solution to:

  • Detect brute force attacks on your servers

  • Identify when someone makes changes to critical files?

  • Identify if servers are sending traffic to unexpected locations?

  • Identify if someone is trying web application based attacks?

  • Track exactly what users are doing within your network?

  • Identify when someone is scanning your network?

Incident Response - Use Cases

  • Exposed AWS Access & Secret Keys

    • Determine the access associated with those keys

      • Depending on the permissions it will determine the steps eding to be taken and in which order

      • Exposed keys has read and write access to very sensitive data

        • Deactivate immediately, prod going down is worth it

      • Exposed keys had read access to a public S3 bucket

        • Can wait

    • Invalidate the credentials

      • When we disable or delete the credentials, ay aplication using them might be affected

      • Ideally, disabling credentials is recommended instead of deleting because disabled credentails can be enabled back instead of any major Production outage

      • Add explicit deny policy to the credentials, that will stop the temp creds and main creds! or remove all policies

    • Invalidate any temporary credentials issued with the exposed keys

      • Temporary credentials can be generated from the access/secret keys. (sts get-session-token)

        • Even if credentials deleted temporary still exist

        • Add explicit deny policy to the credentials, that will stop the temp creds and main creds!

      • These credentials can have a lifetime from 15 minutes to 36 hours

    • Restore the access with new credentials

      • Consider a new pair of access/secret keys

      • Instead of using long term keys, consider using IAM roles or federation

    • Review your AWS account

      • Review all available S3 buckets as wel las CloudTrail logs to see what actions might have been performed

      • Perhaps restore data from backup from before incident if info has been dmaaged

  • Compromised EC2 Instances

Recommended steps (must know):

  • Lock down the instance

    • Isolate it so it cannot contact the outside world

    • Only access should be forensics, from forensic server

    • Automation is key

      • Cut SG, and new one for Forensic access, etc

  • Take an EBS Snapshot

    • Ensure all files in the server will be snapshotted (including malicious)

  • Memory Dump (don't need to know detailed steps technically)

    • Ensure memory is dumped, malware could be only there

  • Perform Forensic Analysis

    • Once you have dumps it is a good base for performing forensics

    • Determine RCA

  • Terminate the instance

Incident Response in the Cloud

AWS provides various visibility, security, and automation controls that can help us in the incident response process.

When we use the cloud many of the things related to proafctively detecting, reacting, and recovering can be easier, faster, and more cost effective.

Tools: AWS Config, CloudTrail, Guard Duty, and CloudWatch

Steps of an Incident Response Plan: (don't need to memorize order or anything)

  • Preparation

    • We need to ensure controls are in place that will help in anomlalie detection

    • Ensure logging is enabled with the help of CloudTrail, VPC Flow Logs, EC2 Instances

    • Using AWS Organitaion to separate accounts to reduce the blast radius

    • Detection phase won't work without preparation phase

  • Detection

    • If you don't know what is going wrong you won't be able to respond to it

    • Behavioural based rules for identifying or detecting breaches

    • Lots of console log-in failures, or if a user is logging in at 3am and launching new servers

  • Containment

    • Once incident has occurred and been detected it is preferred to use some type of automation to contain the resource

    • Use AWS CLI or SDK for quick containment, probably using predefined SGs

    • If you have identified a server infected with malware, quickly run predefined AWS CLI that will attach a restrictive ingress/egress security group (and remove old)

  • Investigation

    • Once the server is isolated, determine and anlyze logs and timelines

    • Use CloudWatch logs to determine what occured on the server

    • Use AWS Config to see infra timeline to see if anything changed

  • Recovery

    • Restoration process geings to recover things back to original state

    • Automation plays a major role here, to make things faster

    • Use pre-built AMIs for the application to launch fresh app servers

Penetration Testing in AWS

  • Vulnerability scanning a system to find known weaknesses

  • Penetration testing is running expaloits against a given system with the intention of compromising it

  • In the past it was mandatory to submit a "AWS Vulnerability / Penetration Testing Request Form" in order to pentest to or from AWS workloads

  • AWS has now removed the clause and customers can carry out security assessments or penetration tests against their AWS infra without prior approval, for 8 services (don't have to recall)

    • EC2, NAT GW, ELB

    • RDS

    • CloudFront

    • Aurora

    • API GW

    • Lambda, and Lambda Edge functions

    • Lightsail

    • Elastic Beanstalk

  • NO DNS zone walking, DDoS, Port Flooding, Protocol flooding, etc

  • Exclude the following VA/PT due to load:

    • T3.nano, T2, nano, T1.micro, M1.small

  • Lessons Learned

Section 3: Domain 2 Logging & Monitoring

Vulnerbility, Exploit, Payload

  • CVE: Common Vulnerabilities & Exposures

    • Publicly known IS vulnerabilities

    • Primary source is the "National Vulnerability Database" (NVD) managed by NIST

AWS Inspector

  • AWS Inspector is an agent based vulneraiblity scanner for specific assessment rules

  • Pre-defined Templates based on which we can scan

    • CVE

      • Scan all packages in the OS to validate if associated version have any vulnerabilities

    • CIS Benchmarks

      • Check OS to see if it's followed all best practices for hardening etc.

    • Security Best Practices (not many)

      • Disable Root login via SSH

      • Support SSH V2 Only

      • Disable Password Auth via SSH

      • Configure max pw age and min length

      • Configure password complexity

      • Enable ASLR and DEP

      • Configure permissions for system directories

    • Network Reachability

      • Shows ports that are reachable from the internet GW

      • Can help if ports are misconfigured at the SG level

      • Agent not required for this scan

  • Duration: 1 hour reocmmended, can go less or more but won't scan all standard if less

    • Also Assessment schedule, for which you want it to run

Security Hub

AWS Security Hub gives you a comprehensive view of your high-priority security alerts and compliance status across AWS accounts

  • Guardduty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, (third party tools), all have their own dashboard, Security Hub is the aggregator

  • Security Hub also has the ability to generate its own findings by running automated and continuous checks against the rules in a set of supported security standards

    • Standards supported:

      • CIS AWS Foundations Benchmark

      • AWS Foundational Security Best Practices

      • PCI DSS

  • Although can add other accounts currently can only see region by region

Web Application Firewall

  • WebACL -> Association -> Rules -> Rule Statements

  • Rule Statements

    • Define basic characteristics that will be analyzed within a web request

    • Custom-defined or ready-made by AWS and Marketplace

      • ex: 1. Block all requests from India

        1. Block requests with have a URI Path of /admin

      • Custom conditions on: Headers, HTTP Method, Query Strings, URI Path, Geo-Location, Body, in Country, IP Address in

  • Rules in WAF

    • Combine multiple statements into rules to precisely target requests

    • Regular Rule & Rate-Based Rule

      • Regular

        1. If a requests comes from 172.30.0.50

        2. Request has a SQL-like code

      • Rate-Based rule = regular rule + rate limiting

        1. If a request come from 172.30.0.50

        2. If request exceeds 1000 requests in 10 minutes

      • Rules with multiple statements can be AND, OR, NOT

  • Web ACL in WAF

    • Web ACL is a centralized place that contains the rules, rule statements, and associated configurations

    • It is used to define the protection strategy

  • Association in WAF

    • Association defines which entity the WAF is associated to

    • Cannot be associated with EC2 instances directly

    • Can be associated with: ALB, Cloudfront, and API Gateway

Pointers

  • Rule Groups can be configured which have multiple rules, that can then be used across multiple Web ACLs

  • Customers can also use ready-made AWS Managed rules or rules from AWS Marketplace

  • Every rule has a priority. If a request matches Priority 0 rule, none of the other rules will inspect the request

  • Pricing: WebACL: $5/m, Rule: $1/m, Requests: $0.60/1 mil

Systems Manager

  • High level: SSM agent install on EC2 instance, customer provides specific tasks to the agent from SSM console

  • SSM Agent is Amazon software, can be installed on EC2, on-prem, or VM.

  • Installed on Amazon Linux 2017.09+, and Linux2 by default.

Session Manager

  • Allows customers to connecto to instances through an interactive one-click browser based shell or through CLI

  • Has session history

  • Send output of commands to S3 or CloudWatch, both command and results

  • Benefits

    • Centralized Access Control using IAM Policies

    • No inbound ports need to be open

    • Logging and auditing session activity

    • One-click access to instances from the console and CLI

    • No need of VPN to connect to instances

Run Command

  • Run specific commands on instances where SSM agent is installed (multiple at once)

  • Provides granular features because of its "command document"

    • Can have ready-made documents available

      • AWS-RunAnsiblePlaybook

      • AWS-ConfigureDocker (installs docker)

      • AWS-InstallMissingWindowsUpdates

      • AWS-RunShellScript

Patch Manager

  • Scan for missing patches, create list of updates, apply patches

  • Patch Baseline service determines the list of missing patches that need to be installed in the EC2 instance

    • A Patch Basline defines which patches are approved for installation on your instances, you can specify approved or rejected patches one by one

    • Research Patch Groups and Baselines

  • Has auto-approval delay, as well as excepted (rejected) packages (like kernel)

Parameter Store

  • Offloads secrets from app to centralized location

  • Provides centralized store to manage configration data, be it plain-text like DB strings or even secret suc has passwords

  • Tiers:

    • Standard 10,000 of them, 4K size, no policies

    • Advanced, more than 10,000, 8K size, policies

  • Can be String, Secure String, String List

    • Secure must specify KMS key source (current or other account)

    • aws ssm describe-parameters on CLI

      • aws ss get-parameter -name

CloudWatch Logs

How to Push

  • Create an IAM role with appropriate policy

  • Install CloudWatch Agent

  • Modify /etc/awslogs/awslogs.conf config file to associate approproate log files

Config

Trusted Advisor

Checks

  • Core Checks and Recommendations (Basic Support Plan)

    • Security Groups

    • IAM Use

    • MFA on Root

    • Perf: Service Levels

  • Full Trusted Advisory Benefits (Biz or Enterprise support)

    • All Checks

    • Weekly Updates

CloudTrail - Log File Integrity Validator

  • CloudTrail logs form a critical asset, especially during the cases of a breach

  • Log File Integrity validation allows us to dtermine whether a log file was modified, deleted, or unchanged after CloudTrail delivered it

  • The feature is built using SHA256 for hashing and SHA256 with RSA for digital signing

  • On CLI

    • aws cloudtrail describe-trails --region whatever

      • Then validate logs from the returned trails

        • aws cloudtrail validate-logs --trail-arn whatever --time

  • Digest files are signed with pub/priv key assigned, and next file contains signature of previous

    • --aws cloudtrail list-public-key --region whatever

  • Digest files are delivered on an hourly basis so some things will not show until then

Macie

  • Macie makes use of machine larning to identify and protect sensitive data stored in AWS from breaches, data leaks, and unauthorized access

  • Macie can automatically discover as well as classify the data, after which it assigns them a business value and monitors them to detect and suspicious activity based on access patterns

  • Check have a score on 10 for DLP reisk

  • Checks are done in regex, in settings (not in new console)

  • Scans S3 and CloudTrail logs

S3 Event Notification

  • Enables you to receive notificaations when certain events happen in your bucket

  • In EVENTS

    • PUT, POST, multipart upload, permanently deleted, etc

  • Send to: SNS, Lambda, SQS Queue

VPC Flow Logs

  • Allows you to see what traffic is going through a particular interface

  • SG is associated to an Interface

    • Allows you to see if packets are accepted and rejected

  • Flow logs can be at ENI, Subnet, or VPC (Global level)

Must Know

STUDY

  • [version, accountid, interfaceid, srcaddr, dstaddr, srcport, dstport, protocol, packets, bytes, start, end, action, logstatus]

  • Description

Centralized Logging

  • Define log retention requirements and lifecycle policies early on

  • Incorporate tools and features to automate the lifecycle policies

  • Automate the installation and configuration of log shipping agent (user data or ami)

  • Make sure the solution supports hybrid environments to support all needs

  • Using AWS Managed services to build a centralized logging solution

    • ElasticSearch

    • CloudWatch Logs

    • Kinesis Firehose

    • S3

End of Section Notes

https://docs.google.com/document/d/1uv2T_huTXApm9Pu7fSz2D8Ir6gvHjC8wyiNy792LHTY/edit#

Section 6 - IAM

AWS Organizations

Getting the basics right

  • AWS offers centralized policy-based management as well as the feature of consolidated billing for multiple accounts through the feature of AWS Org

  • Two primary features:

    • Consolidated billing only (conslidated billing in billing dashboard)

    • All Features

Over view of Policy Restrictions

  • AWS Org account (master account) can "Deny disable CloudTrail" or "Deny All S3" on sub account (child account), and not even root could modify that there

OU in Orgs

  • If you have hundreds of accounts it's a pain to attach policies to each

  • Groups of accounts is a OU

  • Atach policies to OU instead

  • You get a Root OU by default, and then create other OUs

  • Can attach Service Control Policies to OUs or only to accounts

  • Cerate in Organize accounts, by default they will come under root OU, then Move to another OU

PreviousNotesNextEverything

Last updated

Was this helpful?