AWS Security Specialist Notes

• CloudWatch Events more real time alerts as compared to CloudTrail
• Understand Systems Manager
  • Systems Manager provide parameter store which can used to manage secrets (hint: using Systems Manager is cheaper than Secrets manager for storage if limited usage)
  • Systems Manager provides agent based and agentless mode. (hint: agentless does not track process)
  • Systems Manager Patch Manager helps select and deploy operating system and software patches automatically across large groups of EC2 or on-premises instances
• S3 Glacier Vault Lock helps you to easily deploy and enforce compliance controls for individual S3 Glacier vaults with a Vault Lock policy. You can specify controls such as “write once read many” (WORM) in a Vault Lock policy and lock the policy from future edits.
• If the KMS key policy is allowing the EC2 role to encrypt/decrypt, then even if thfe IAM role of the EC2 is not having explicit allow on the key, then also EC2 will be able to use the key since they are in same account. CHECKKKK: If a role/user doesnt have explicit allow on KMS but the KMS policy is allowing the access, is the IAM user able to use the key?
• DynamoDB and S3 uses VPC Gateway endpoint instead of VPC interface Endpoint to communicate with resources inside VPC privately. An interface endpoint is powered by PrivateLink, and uses an elastic network interface (ENI) as an entry point for traffic destined to the service. A gateway endpoint serves as a target for a route in your route table for traffic destined for the service.
• Lost Private SSH key of EC2: Solution: Amazon EC2 stores the public key on your instance, and you store the private key. Detach the root volume from the EC2, attach it to another Ec2 as data volume and edit the authorized_key file to store newly created SSH public key and attach the volume back to original EC2.
• Cognito user pool: User pool has individual profiles which you can manage to allow them to SSO via FB, Google, SAML Identify provider etc
• Organization CloudTrail : To create an organization trail in the CloudTrail console, you must sign in to the console using an IAM user or role in the management account with sufficient permissions. If you are not signed in with the management account, you will not see the option to apply a trail to an organization when you create or edit a trail in the CloudTrail console.
• VPC Peering: VPC peering can connect VPCs in same account, in different accounts and in different regions also.
• Event Bridge vs CW: Amazon EventBridge is the preferred way to manage your events. CloudWatch Events and EventBridge are the same underlying service and API, but EventBridge provides more features. Changes you make in either CloudWatch or EventBridge will appear in each console.
• Real Time Analysis: Perform Near Real-time Analytics on Streaming Data with Amazon Kinesis and Amazon Elasticsearch Service
• KMS Key rotation: Imported key materials are not auto rotated
• Lambda@Edge: Lambda@Edge provides the ability to execute a Lambda function at an Amazon CloudFront Edge Location. This capability enables intelligent processing of HTTP requests at locations that are close (for the purposes of latency) to your customers. To get started, you simply upload your code (Lambda function written in Node.js) and pick one of the CloudFront behaviors associated with your distribution.
• Instance MetaData has following info about the ec2:  AMI-id, hostName, IAM, instance-type, mac, Profile, Public-keys, secuirty-groups. To get this info, login to Ec2 and type below command:
  • curl 169.254.169.254/latest/metadata
  • We can push one-time SSH key into metadata which can be used and is more more secure.  THis is how AWS Connect works with EC2.
  • Users who have access to EC2 can make below command to fetch access key, secret access key and temp token, this can then be exploited till this temp credential gets expired:
     
     
    $ curl 169.254.169.254/latest/meta-data/iam/security-credentials/my_Instance_IAM_role
     
     
    This will return access key, secret access key and temp token and token expiry. Hence this needs to be blocked using IPTables.
  • useradd developersudo su -curl 169.254.169.254/latest/meta-data/iam/security-credentials/first-iam-role
    IPTABLES:
    iptables --append OUTPUT --proto tcp --destination 169.254.169.254 --match owner ! --uid-owner root --jump REJECT
     
  • It's not recommended to hardcode credentials using aws configure on EC2 instances, hence instead just associate an IAM role to the instance with appropriate permission and delete any hardcoded credentials. After IAM role is added and credentials are removed, we can still make CLI commands from EC2 even though nothing is present inside aws configure because instead of using those creds, the EC2 would be IAM role instead.

---

AWS Cloud Watch Agent Use Cases

1. Web server (Nginx, Apache etc ) access or error logs can be pushed to Cloudwatch logs it acts as central log management for your applications running on AWS
2. Custom application logs (java, python, etc) can be pushed to cloudwatch and you can setup custom dashboards and alerts based on log patterns.
3. Ec2 instance metrics/custom system metrics/ app metrics can be pushed to cloudwatch.

Ephemeral ports

• Many Linux kernels (including the Amazon Linux kernel) use ports 32768-61000.
• Requests originating from Elastic Load Balancing use ports 1024-65535.
• Windows operating systems through Windows Server 2003 use ports 1025-5000.
• Windows Server 2008 and later versions use ports 49152-65535.
• A NAT gateway uses ports 1024-65535.
• AWS Lambda functions use ports 1024-65535.

• If object is being uploaded from a different account, then the uploader is the owner to the objects and the bucket owner will not have access over the object.
• To give bucket owner access over the uploaded object frm different account, the uploader needs to make sure that the ObjectACL includes -grant-owner-access option so that the bucket owner becomes owner of the uploaded object as well.

• A network access control list (ACL) allows or denies specific inbound or outbound traffic at the subnet level.
• If NACL rule 100 allows all traffic and nacl rule 101 denies a particular IP, then because first the rule 100 will be evaluated due to being lower in number, the traffic will be allowed and that explicit deny would not work. Hence Deny rules should always be of lower number to be evaluated first.

• Firewall usually operate at level 3 or level 4 of OSI model ie network and transport layer. Due to this they dont read http packets leaving applications running on level 7 vulnerable such as sql-injection, cross-site scripting. These are layer 7 attacks, hence something is needed to safeguard against layer 7 for such type of attacks. We do this using rules ie WAF
• Rules are created against http request since we want protection against layer 7 requests
• Multiple rules can be used with each other with having logics between them such as OR, AND etc. We can have conditions such as “if” traffic is from “china” AND “if” IP belongs to “BlackList”, then “Block” traffic.

1. ALB
2. CloudFront Distribution
3. API Gateway

• AWS GuardDuty
• AWS Inspector
• AWS Macie
• AWS IAm access analyser
• AWS Firewall Manager

• Summary: Security Hub has ability to generate its own findings by running automated checks against certain compliance or rules but would be using info from sources . Uses config rules to check for compliance. For compliance bechmarks, enable config.
• Insted if navigating dashboard to dashboard, we get all the security related details under a single dashboard.
• Security Standards: Shows scores against CIS bechmark. Shows rules such as “Avoid use of root user”, and shows as failed if non-compliant. Gives result on individual rule to rule basis.
• Findings: shows findings frm the sources. This would be mostly from inspector
• Integrations: AWS  Security Hub integrates with lot of services such as splunk, tenable, GuardDuty etc
• It is a regional service

• Just select the EC2 and click on ‘start session’, this will start a new SSH sessions with the Ec2 instance and will open up a shell on browser to use the SSH connection established with the EC2.

• We can specify on which instance we want to run the command
• We can chose to run a shell script on instance specified

• It can be installed on Ec2 and onPrem servers as well

• We can use Ec2 connect from the EC2 service to ssh into Ec2 directly (rather using putty or something).
• Session manager also has the ability to let you ssh to your ec2 instance from Sessions Manager console
• The above comparision shows that Iam role is not required for Ec2 connect from EC2 console similarly for sessions manager to connect , it doesnt need IAM role. However for EC2 connect the security group and Public Ip needs to be open but sessions manager can let you ssh into the instance without need of public IP.
• So basically we can use Sessions Manager to ssh into EC2 instances inside private subnet. Normally since private  ec2 instance would require a bastion host to ssh into it. But its easier and cheaper to use sessions manager, but make sure the sessions manager agent is installed and running on these Ec2 instances. Also remember sessions manager requires an IAm role on ec2.

• centralized access control using IAM policy instead of normal SSH which cant be controled and anyone with the key can ssh.
• no inbound ports needs to be open
• logging and auditing session activity. This shows up on “Session History”. We can further check “General Preference” card of sessions manager which informs us about CloudWatch logging. This logging needs to be enabled from CloudWatch. But also remember to edit Ec2 role so that it has permissions on CloudWatch log group so that it can send the logs to CloudWatch, just edit the role of that EC2 and attach “CloudWatchLogsFullPermissions” IAM policy to this EC2 role.
• One-click access to instances from console and CLI
• No need of VPN to connect to instance 

• AWS-RunAnsiblePlayBook
• AWS-ConfigureDocker (installs docker on Ec2 remotely)
• AWS-InstallMissingWindowsUpdates
• AWS-RunShellScript
• many more

• It is used to centrally store configurations and credentials or even plaint text data
• we can choose secret type as ‘SecureString’ which uses KMS to encrypt our data. While viewing this, use –with-decryption to view the secret otherwise since it is encrypted it would give a random big word

• We can automate a lot of tasks using this such as stopping instances, blocking open SG etc
• These automation also supports ‘approval’ which uses SNS to send email to subscriber. Only the IAm user/role mentioned as approver of this automation will be allowed to approve and no other user can approve this automation request.

1. SSM provides a way to look into EC2 and on-premises configurations of the resource
2. It captures Application names with versions, Files, Network Configurations, instance details, windows registry and others
3. We can query our inventory to find which specific application is stored on which instance. This helps to centrally check if a particular application is present all our EC2 instances or on-prem servers which version info.
4. We can send this info further to S3 and then use athena to query this using resource data sync.
5. We will have to setup the inventory first. We can choose which instance to include, also what to include and what not to include in the inventory and also the frequency of this sync. We can also select S3 sync to sync the data to S3.

• It can fetch resource metric and also collect logs from the host. Logs for ec2 are present in log groups. metrics inside CW dashboard allows us to see Memory, CPU etc metrices.
• after installation of this agent on ec2, the process requires to run ‘configuration wizard.’ In this you will choose the host OS and also which type of metric collection you want. It has basic, medium, advanced varying in their granularity and what kind of metrics are to be collected. After this configuration is done, then CWAgent is run for the first time.

• EventBridge delivers a stream of real-time data from event sources to targets. Ex: Ec2(EC2_Terminate) –>EventBridge—-> SNS(Alert Sent regarding terminated Ec2).
• Further, we can schedule this alerts, hence use EventBridge with a source as “Schedule”. So at specific time/schedule the targets will be triggered.

• It can be used to query large dataset maybe from CloudWatch or CloudTrail logs. We can query such logs directly using Athena.

• It analyses the AWS environment and provides best practice recommendations in 5 major catergories:
  • Cost Optimation: Recommendations that allows us to save money such as “Idle Load balancers”.
  • Performance: Shows recommendations that helps improves performance such as “EBS volume causing slowdown”
  • Security: All security related advisories.
  • Fault Tolerance: Recommendations that would help us make the resource more fault tolerant. Ex: “Checks if all Ec2 are in different AZ so that if one AZ goes down the other Ec2 are not affected.
  • Service Limits: Checks limits of services and lets us know if any service is breached or will breach any limit
• Each category has number of rules, such as security will have many more rules such as “IAM Password policy”, “CloudTrail Logging”. But not all are enabled by default, but to enable these other rules, you will have to upgrade your support plan. After upgrading support plan, you will get access to all the trusted advisor checks.

• 3 Types of EventTypes are logged if selected:
  • 1. Management Events: Normal events being performed on our AWS resources
  • 2. Data Type: S3 related logging such as PutObject, Getobject, DeleteObject. We can select if we only want readEvent or WriteEvents. These Events can be seen on S3 buckets or CloudWatch Log group level. (These events wont show up on CT Dashboard, hence can only see in S3 or CW log group. OR send this trail data to Splunk and query). Preferred way would be using CloudWatch log Groups.
  • 3. Insights Events: Identify unusual errors, activities or user behaviour is your account. Ex : ‘spike in Ec2 instances being launched’.
• CT Log File Validation: This allows us to confirm if the log files delivered to S3 bucket have been tempered or not. Validation lets us know if there has  been a change in the file or not. Does this using RSA and SHA-256 hashing.
• Validation options comes under advanced settings of a trail. Download the zipped trail, and copy paste this data to convert it into SHA-256.

CloudTrail data events

• Amazon Simple Storage Service (Amazon S3) object-level API activity (for example, GetObject, DeleteObject, and PutObject API operations)
• AWS Lambda function invocation activity (for example, InvokeFunction API operations)
• Amazon DynamoDB object-level API activity on tables (for example, PutItem, DeleteItem, and UpdateItem API operations)

CloudTrail management events

• Creating an Amazon Simple Storage Service (Amazon S3) bucket
• Creating and managing AWS Identity and Access Management (IAM) resources
• Registering devices
• Configuring routing table rules
• Setting up logging

• AWS Macie uses Machine Learning to search for PII data, database backup, SSL private Key and various others in the S3 buckets and create alerts about the same.
• Checks if buckets are publically exposed, or publically writable.
• It has ‘Findings’ like guardDuty such as ‘SensitiveData:S3Object/Credentials’ , this finding comes up if macie finds credentials on S3 bucket.
• So finding sensitive data if primary function, but it also checks open S3 bucket, encryption etc
• Custom Data Identifier: We can further create custom regular express ie RegEx to mach a certain type of data present on s3 and if data present is matched, that finding type comes up. So  scanning sensitive data does not stop with preconfiugured findings rather we can create our own regEx and get custom findings.
• Scanning jobs needs to be scheduled using ‘scheduled job’ for repeatitive scanning or you can go ahea with ‘one-time job’ for just one time scanning. You can check this running job inside ‘Job’ section.
• These findings can be stored for long time but needs configuration.

• S3 event notification allows us to receive event notification when certain event happen in your bucket.
• Event Types: These are the events on which you would recieve alerts for, such as ‘all object create events’ would alert on PUt, Post, Copy and Multipart upload.
• Event notification can then triggered or send data to different destinations:
  • lambda
  • SQS
  • SNS
• So basically we can get SNS alert if someone does performs some specific tasks on s3 bucket.

---

• Record traffic information that is visiting the resource (eg EC2). Ex: If Ip 192.12.3.3 is visiting my Ec2, then it would record this detail about the IP. ie 192.12.3.3 —-> Ec2 instance
• Records data if resource connected to any outbound endpoint.   Ex: EC2—>193.13.12.2

1. CloudWatch Logs Group :By default, once setup, log streams are stored in log groups
2. S3 bucket : We can optionally push these logs into S3
3. Send to Kinesis Firehose same account
4. Send to Kinesis Firehose Different account

1. version: VPC flow logs version
2. account-id : AWS account id
3. interface-id : network interface id
4. sraddr: The source address
5. destaddr: destination IP for outgoing traffic
6. srcPort: Source port
7. dest port: Destination port
8. protocol: The protocol number
9. packets: number of packets transferred
10. bytes: number of bytes transffered
11. start: start time in unix seconds
12. end: end time in unix seconds
13. action: accept or reject traffic
14. logging status of flow log

---

1. Kinesis Stream: Kinesis stream is place for Data collection and storage. So all the logs or any data that needs to be processed and sent, first needs to be put into Kinesis Stream. All data is first collected here. Kinesis stream can receive data directly From VPC flow logs and also from CW log groups.
2. Kinesis Firehose: Firehose is the 2nd stage which is used to process the data and deliver is to destinations. Just like water is first stored in tanks, the data is stored in Kinesis Streams and just like a pipe with tap is used to give us water, the firehose is responsible for processing the data such as compressing it or filtering it and then firehose pushes it into destination. hence this is 2nd stage.
3. Kinesis Analytics: This is optional 3rd stage. Usually Firehose will deliver data into Splunk HEC but we can also choose to send the data into Kinesis analytics for analysis if we want.

• Multiple sensors could be sending continuos data, this data can be stored and processed using Kinesis.
• This requires 2 layers:
  1. Storage Layer
  2. Processing Layer
• 3 Entities are invovled in this process:
  • Producers: Data producers like sensors
  • StreamStore: Where data is gonna be stored like Kinesis
  • Consumer: This will run analytics on top of the data and give useful info
• Kinesis Agent: This is a software application that is used to send data to Kinesis stream.  Other ways could be done by using AWS SDK.
• Consumers: We can Select “Process Data in real Time” under the kinesis stream dashboard. This will make kinesis as consumer and show some processed data. Other option could be ‘Kinesis Data Firehose’ which means using firehose delivery stream to process and store data.
• After sending data to kinesis, it shares a shardID which could be used to refer to the data and fetch it.

1. Kinesis Data Stream : Captures, process and store data streams in real-time
2. Kinesis Data Firehose: Primary to move data from point A to point B. Hence FireHose can be used to fetch data from Kinesis DataStream and then use FireHose to send this data to Splunk. When setting up, we get option to choose ‘Source’ as Kinesis Stream and choose ‘destination’ as splunk or S3(S3 can also be choosen as backup to send logs for backup).
3. Kinesis Data Analytics: Analyze streaming data in real-time with SQL/Java code. So we can use SQL to make commands and analyse data here.
4. Kinesis Video Steam: capture, process and store video streams

• usually we dump data into S3 and then use Splunk HEC to fetch the data from that S3 bucket
• However, We can leverage Kinesis Firehose here. So instead of sending CW logs directly to S3, we can rather set CloudWatch logs as source for firehose and setup a stream for firehose with source as CW logs.
• Now Firehose gives a lot of options to play around with these logs, such as we can choose a lambda function to process the logs, change it, compress it, change its format etc. This can be done while setting up the stream for Firehose.
• We can also Select S3 as backup. If we select s3 as backup, then firehose will also send data to S3 and then also send data to Splunk HEC
• Splunk HEC would be selected as destination and all the logs will be pushed to splunk from Firehose.

1. Create a kinesis dataStream in receving acccount.
2. Create an IAM role for CloudWatch central log group to send data to kinese data stream. This role will be assumed by CW and will send data to kinese stream.
3. Now use CLI to create CW destination which would recieve logs from different accounts. This destination would be in the receiving central account where kinesis is setup. So use CLI to use ‘put-destination’ command and in this command we mention the Kinese stream arn. This connects CW log destinatio to Kinesis so that CWlogs destination can put data inside the Kinesis stream. This would require CWlog destination to have assume role permissions to put logs inside Kinesis. And further add permissions policy so that it can make api call and put data inside kinesis. Now CW destination will assume this role, and then make api call Kinesis:PutRecord to send data into Kinesis. Remember to add PutRecords permission into Iam policy of the role being assumed by CW.
4. Lets say we want to send CloudTrail data to splunk. So in this step setup CloudTrail trail, and in that trail, configure CloudWatch Log group to send all the trails to CW log group.  ORRR you can choose to configure VPC flow logs and send them to  particular CW log group.
5. Make put-subscription-filter cli command so that logs can be sent to the CW logs destination.

---

1. Create ssh keys on your instance (client) using ssh-keygen command. This would create 2 keys, one public and one private
2. Now cat the pub key on client and copy the content to the bation host. Basically we are trying to copy the public key fm client to bation. Hence in the ‘/authorised’ key, cat the public key.
3. Do the same with private Ec2 instance also, ie make sure to paste your public key under /authorized. All all 3 instances have same public key but only client has the private key as of now.
4. Now that all instances have public key, we can copy the private key from client to bation host and then use this private key on bation to ssh to private ec2, but storing private keys on bation hosts is not safe, hence we go with safer approach.

• Use SSH forwarding instead of pasting private keys on bation host. Use Below steps:
  • Step 1: Create Public/Private Key in Remote Client EC2
  • ssh-keygen
  • Step 2: Setup Authentication
  • Copy the contents of public key form remote-client to the ~/.ssh/authorized_keys file of both Bastion and Private EC2.
  • Step 3: Use SSH Agent Forwarding
  • Run the following commands on the remote-client EC2 instance

1. Step 4: Test the Setup
2. From remote-client EC2, run the following command:
3. ssh -A [BASTION-EC2-IP]
4. Once you are logged into Bastion, try to connect to Private EC2
5. ssh [IP-OF-PRIVATE-EC2]

• Use Systems Manager to ssh into private Ec2 (very secure).System manager now also works with on-prem resources hence hybrid deployement is also supported. So if company has onPrem instance, use SSM (SystemsManager) to ssh into those onprem resources.

• works similar to proxy
• In AWS, VPN is deployed on public subnet and can be used to connect to private subnet resource

• what if vpn fails
• patch management
• upgradation
• vpn server configuration is  a hectic job
• performance optimization

• dont need to bother about above mentioned issues
• only configuration needs to be done and it is not that complicated.

• We can use AWS Client VPN service to create our own VPN server to which we can connect from our EC2 instance and route internet safely
• First certificates are generated since client has to present certificate to VPN server for ‘mutual Authentication’. SAML authentication is also possible.
• Once we have certificate on our Ec2 instance which need VPN connection, now we can setup the VPN-Client service.
• go to VPN service and setup VPN. It asks for Client’s CIDr which is basically a CIDR range from which an anonymous IP would be giving to our client by the VPN service. This anonymous IP is what makes our Ec2 secure since VPN would not show real IP of Ec2 to anyone.
• Once Clien’t CIDR and ‘Mutual Authentication’ is setup, downloan OpenVPN software on Ec2 instance and this software would need a .OPNF file. This file is downloaded frm AWS after ClientVPN is configured. Download the file, append certificate, key to this file and upload to the OpenVPN software on your Ec2.
• Now click on connect and openVPN software would connect to our own VPN server and provide anonymous access to internet.
• Please make sure to make change to route table to the VPN server on AWS and make its route table routable 0.0.0.0 for internet access.
• Also, after VPN client is created, it shows waiting association, so you need to use the ‘Associations’ tab to add the subnet to which our Ec2 instance belongs. All the subnets mentioned under this would be able to use the VPNClient for anonymous access.
• In ‘authorization’ step, authozaition basically decided which clients have access to VPC. So setup authorization card for the same.
• ‘Connections’ card shows details about the connections like data traffered, active/disconnected etc.

• Challenge: High availability is an issues in this case since if connecting ec2 goes down, everything goes down. Hence multiple tunnels are used instead of one.
• Its like alternative to vpc peering.

• Virtual Private gateway has built-in high availability for VPN connections. AWS automatically creates 2 highly available endpoints , each in different AZ. These both act like a single connection but since there are 2 IPs(tunnels), it makes it more available architecture. This is how high availability is achieved from AWS side.

• VPC peering will not happen on overlapping CIDR ranges. Ex: 172.16.0.0/16 —–X——cant -peet—–X—-172.16.0.0/16
• Transit VPC access is not possible which means if VPC A and VPC B are connected to VPC C, then A<–>C and B<—>C is possible but you cannot reach B via C if you are A, ie A<—>C<—>B is not possible or A<—->B not possible.

• provide same usecase of NAT which doesnt allow traffic from outside to initiate a connection with  the resources behind NAT gateway.
• This is used for IPV6 mainly.

• Usually when an EC2 wants to connect to some resource such as S3, it needs to route the traffic via using internet gateway, hence we can use VPC endpoint so that EC2 to S3 connection can become private and traffic doesnt route via internet.

• High data transfer cost via internet
• Security issues
• High latency
• Can bottleneck the internet gateway

1. Gateway Endpoints: Supported by S3 and DynamoDb
2. Interface Endpoints: almost all other services expect S3 and Dynamo supports interface endpoint.
3. Gateway Load Balancer Endpoints

• Amazon EC2 instances
• Services that launch EC2 instances:
  • AWS Elastic Beanstalk
  • Amazon Elastic MapReduce
• Services that use EC2 instances (without appearing directly in the EC2 service):
  • Amazon RDS (Relational Database Service)
  • Amazon Redshift
  • Amazon ElastiCache
  • Amazon CloudSearch
• Elastic Load Balancing
• Lambda

1. Uses edge locations to deliver data faster via caching
2. We can setup rules to block traffic based on geoLocation for our CDN that we have created, restricting access to our content for some countries.
3. It can integrate with WAF and Sheild for protection
4. Need to select ‘Retrict viewer type’ to ‘yes’ and select ‘trusted key groups’. This will make all the content accessible only via CDN’s signed URL and no content can be accessed without signed URL.

---

1. Shield Standard
2. Shield Advance

• defence against sophisticated DDOs attacks
• near real-time visibility into the ongoing attack
• 24*7 access to AWS DDOS Response team (DRT) during ongoing attacks
• Bills at $3000/month per org
• Cost protection: If during the attack, the infrastructure scaled, then AWS will reimburse the amount in form of credits. This is called “Cost Protection”
• Layer 3/4 attack notification and attack forensic reports and attack historical report (layer 3/4/7)
• AWS WAF is included at no extra cost

1. Be ready to scale so that service scales up in case of attack and server doesn’t breakdown. Autoscaling can help.
2. Minimize the attack surface area ie decouple the infra like database being in private and frontend being public subnet
3. Know what traffic is normal and what is non-normal.
4. Be ready for a plan in case of DDOS attack

• We can quickly create an API using api gateway and select a method like GET and integrate it with a lambda as trigger.
• Now we can use the invoke URL given by the API gateway service, enter it in browser and hit enter. This will send a GET request to our api which would further trigger the lambda.
• Since we can select REST API also, we will also get a response sent by lambda to the api.

• We can setup our lambda and in the trigger, we get a choice to directly use S3 as a trigger. 
• This way of selecting S3 as direct trigger to lambda would not require SNS and and SQS. This would use S3 and direct trigger for lambda.

• The key pair that we select while deploying the EC2 is stored in ‘/.ssh/authorized_keys’ folder
• If we delete the keypair from AWS, that key pair still remains inside EC2 and needs to be deleted
• If we create an EC2 from existing AMI, the key present in AMI will be populated inside EC2

• Shared: The EC2 instance runs on shared hardware. Issues: Security
• Dedicated: Ec2 instance runs on hardware which will be share between resources of the same AWS account. Hence 1 acccount – 1 hardware. So all Ec2 running on our host will be ours.
  • Sometimes some license are tried to hardware such as Oracle license, so we would not want to change our hardware after start-stop, here is were dedicated hosts comes in which would let us have same hardware.
• Dedicated Hosts : Instance runs on a dedicated host with very granular level of hardware access

• The artifact port provides on-demand access to AWS security and compliance docs, also know as artifacts.
• This is required during audits when auditors asks proof if AWS services are compliant to PCI DSS, HIPA etc

• Lambda@Edge allows us to run lambda functions at the edge location of the CDN allowing us to do some processing/filtering of the data being delivered by the CDN.
• There are 4 different points in communication where the lambda can be used. Viewer Request ->Origin request->Origin response->Viewer Response. This is called cloudfront cache. At any of these 4 points we can implement a lambda.
   

• This is enabled by default in VPCs. This allows our Ec2 to get a DNS name. This is done after ‘enableDNSHostNames’.
• Enabling ‘EnableDnsSupport’ will allow a public DNS name for the ec2 and also will allow the amazon nameservers to redirect the traffic to this DNS. Disabling this will give DNS name if ‘enableDNSHostNames’ is enabled but the resolution will not happen.

• R53 Query logging enables us to log all the DNS queries made to our application. Query logging can be enabled inside our Hosted Zone settings for both public and private hosted zones. When an application makes request to reach to an external website via R53, the logs contains below fields:
  • Domain requested
  • Timestamp
  • Record Type 
  • response sent etc

• Destination of the logs: CW log group, S3 or kinesis.
• For this the ‘query logging’ has to be enabled

• These are set of lambda functions which depend upon one another.
• So maybe we want that lambda 2 should run after lambda 1, use step function to first run lambda1 and then lambda 1 will execute lambda 2.

• This is the main firewall which would protect all our resource inside a VPC. RIght now we can create only NACLs to secure our Subnets, and SGs work at network interface level, while WAF only protects ALB, CF(CDN) and API GW. Network Firewall is the actual firewall that would protect the VPC from malicious traffic.
• Filtering and Protocol Identification : Incorporate context from traffic flows, like tracking connections and protocol identification, to enforce policies such as preventing your VPCs from accessing domains using an unauthorized protocol. We can also block based on TCP flags.
• Active traffic Inspection: AWS Network Firewall’s intrusion prevention system (IPS) provides active traffic flow inspection so you can identify and block vulnerability exploits using signature-based detection. 
• Blocking Domains: AWS Network Firewall also offers web filtering that can stop traffic to known bad URLs and monitor fully qualified domain names. 
• Statefull and Statless Ip/Domain Filtering: We can also do stateless IP filtering and statefull IP filtering. We can also upload a bad domain list so that no resource from our VPC connects to the same. Both stateless and statefull are supported.
• VPC Level: Since this service associates firewall at VPC level, we can make a uniform deployment of this service such that all VPC gets uniform security. It also integrates with AWS Firewall Manager service which works at Org level. This will help in streamlining the firewall controls over VPC throughout the org. So if some IPs and domains needs to be blocked at Org level, use AWS Network firewall and associate the rule to all the VPCs. This uniform deployment of firewall cannot be achieved with any other service which could block IPs and domains both.
• Sits between resource subnet and its Internet Gateway: After you create your firewall, you insert its firewall endpoint into your Amazon Virtual Private Cloud network traffic flow, in between your internet gateway and your customer subnet. You create routing for the firewall endpoint so that it forwards traffic between the internet gateway and your subnet. Then, you update the route tables for your internet gateway and your subnet, to send traffic to the firewall endpoint instead of to each other.

High availability and automated scaling

Stateful firewall

Web filtering

Intrusion prevention

Alert and flow logs

Central management and visibility

Rule management and customization

Diverse ecosystem of partner integrations

• Content inspection
• Threat monitoring
• Troubleshooting

1. All Features:
2. Consolidated Billing: Management account pays for all child accounts

• Objects that are uploaded from a different AWS account to  a central S3 bucket in the main account, those objects might not be accessible by the users of the central AWS account due to object ownership issues. The object ownership needs to be defined so that the users/roles in the AWS account which owns the central bucket are also able to access the objects of the bucket.

• A user ‘temp’ created with no IAM policy.
• A new key created, in the key policy, first the user was not mentioned.
• The user’s encrypt and decrypt both api calls fail since non of the policies are giving him access
• then ‘encrypt’ permission was added to the IAM user policy and the KMS policy remains same with no mention of temp user. this time encrypt worked but not decrypt
• Now, decrypt permissions are added only to the kms key policy but not added to temp user. Now both encrypt and decrypt works.
• This means, like mentioned above, when AWS evaluates permissions, it sums up the permissions from IAM policy and KMS policy, and the net access depends on what both give together. So if encrypt is in IAm policy and decrypt in KMS policy, the user will have summation of both policies as permission, so it will be able to make encrypt and decrypt both calls.
• This could be bit risky since even if KMS policy mentions nothing about the IAM user, yet just by setting up its own permissions, the temp user will have complete access to the key just by mentioning them in its IAM access policy.
• One way to get rid of this would be remove the “Sid”: “Enable IAM User Permissions”, or add specific user ARN instead of “AWS”: “arn:aws:iam::456841097289:root”, since root would allow all users and roles to access the key just by using their IAm permissions.

• An external ID can be used to make cross account role assumption secure.
• IN the trust policy of the role being assumed (destination account), the condition section of that trust policy would have :

• While setting up the role, we get “Options” section while gives an option “Require External ID” and “RequrieMFA”, ticket on the needed option of “required external ID” on ‘create role’ page.AWS STS
• STS service is responsible to fetch temporary tokens to give temp access.
• STS provides Access Key, Secret Access Key and Session Token and this can be used to get gain access.

• Microsoft Active Directory: Allows us to store users at a single location. Just go to AD and click on new-> new user, this creates a new user as part of the AD
• This AD can then be associated to our AWS SSO to give these users access.
• Federation allows external Identities to have secure access in your AWS account without having to create IAM users
• These federated external identities can come from:
  • Corporate Identity Provider ex: AD, IPA
  • Web Iden Provider. Ex: Fb, Google, Cognito, OpenID etc

• So its like a Cisco employee wearing Cisco Badge goes to Amazon office and wants to enter amazon
• Cisco Employee show if cisco’s ID card and ask the   gaurd to enter into Amazon’s building
• Since the ID card is not of Amazon, Amazon’s guard will send his employee to verify with cisco if I am really a cisco employee
• Cisco would confirm, that Yes I am cisco employee trying to get into Amazon’s office for some quick work.
• Now Since this is confirm that I am cisco’s employee, the Amazon’s gaurd will create a temp Idcard for me by asking permissions from the main Amazon building which I need to enter
• Now I can enter amazon’s building using temprory credentials. This is how federated login works. If we want to login to Amazon using google’s creds, amazon’s console will first check with Google to verify my identity and then give me temporary credentials which I can use to explore amazon. The guard who does all the verifications and gives me temp Id card is Identity provider. Identity store would be Cisco’s office where my actual identity is stored.

1. users login with username and password
2. this cred are given to Identity Provider
3. Identity Provider validates it against the AD
4. If credentials are valid, broker will contact the STS token service
5. STS will share the following 4 thing

6. Users can now use to login to AWS console or CLI

1. User: This is the user trying to login to AWS
2. Identity Provider: IDP is the 2nd party which stores all the user details, and allows it to gain access over AWS
3. Service: Service is the party on which you are trying to gain access over. IN this case it would be AWS console

• AWS SSO requires Org enabled
• AWS SSO can be integrates with IAM users and groups. Also, it can integrate with external user identity pools like Microsoft AD to source the users from.
• User portal URL would be the url of the portal that users use to enter creds and login  
• Permission sets are used to setup permissions for the users logging in. Users are added to user groups and these permission sets are associated to these groups to make sure the users in group have required permissions.
• If required, we can then integrate AWS CLI with SSO. users will required to user –profile and use the SSO profile while signing with CLI.
   
  ex $ aws s3api viewBuckets — profile SSO

1. The flow starts when the user opens up the IDP URL, it can be Okta for example, and the user enters its credentials and selects the application to which it would gain access.
2. The IDP service will validate the creds at its end, so okta will cross check if creds are correct at okta end, if okta creds are entered correctly, okta will send back a SAML assertion as a SAML response
3. User now uses this SAML response to redirect to the SAAS signin page and Service provider ie AWS will validate those assertion.
4. On validation, AWS will construct relevant temp creds, and construct a user signIn temp link which is then sent to the user and the user is redirected to AWS console.

• Active Directory is like a central server to store Users in a single location.
• AD makes it easy to just manage users in a single location
• Multiple other services can use AD to fetch user information instead of having to manage them on each app
• AWS has its own called ‘AWS Directory service’

• This is AWS offering for Active Directory. It gives us 5 ways to setup or connect active directory to AWS
  1. AWS Managed Microsoft AD
  2. Simple AD
  3. AD Connector
  4. Amazon Cognito User Pool
  5. Cloud Directory
• AWS Managed Microsoft AD : Actual Microsoft AD that is deployed in Cloud. It has 2 options:
  • Standard Edition : Upto 500 users
  • Enterprise Edition: Large Org upto 5000 users
• AD Connector: AD connector works like a middle-man/bridge service that connects your OnPrem AD directory to your AWS Cloud. So when user logs in into the application, the AD connector would redirect the singin request to OnPrem AD connector for authentication.
• Simple AD: This is a compatible active directory for AWS Directory service which is similar to MicrosoftAD but not the same. Its like a similar alternate to MicrosoftAD. It provides authentication, user management and much more. AWS also provides backups and daily snapshot of the same. It does not support MFA and login via CMD/terminals. Its like a free version of AD. We can store username/password to store here and let engineers use SSH command and mention AD creds to SSH into the EC2.
   

• One-way trust: In this the direction of trust matters and access can be gained only in one direction.
• Two-Way trust: In this domains from either side can access each other.

1. Identity permissions: For AWS account access restriction. IAM policies associated to IAM users/roles can give access to S3 buckets.
2. Bucket Policy: Bucket policy not only restricts AWS entities, but also caters to the request originating from outside world such as for public S3 bucket. It can make restrictions based on:
   1. Allow access from particular IP
   2. Allow access from Internet
   3. Only allow HTTPS connection
   4. Allow access from specific IP etc

• If there is no bucket policy, and block all public access is on, obviously an object such as a pdf on S3 bucket cannot be accessed from internet. It fails with below error:

• Now if I disable block all public access, and bucket does not still have any bucket policy, then also the object would not be accessible and I would get the same error as above while trying to access the pdf from internet. Although the ‘Access’ Prompt on the bucket would start to show ‘Bucket Can be Public’. However with ‘block all public access’ as ‘off’ and no bucket policy, the objects still cant be accessed over internet. It fails with above error. This means just making ‘block public access’ as off doesnt really make the objects public. 
• However, as soon as I add below bucket policy after making ‘block all public access’ to off :

• Now lets say there is no bucket policy and the ‘block all public access’ if also off. As seen above, although this shows ‘Bucket Can be Public’ but if there is no bucket policy as above allowing access to “Principal”: “*”, this would mean the objects are still not accessible as mentioned above.
• This kinda means that without bucket policy, the objects cant be open to world, but there is a catch, here, Object ACLs can be used to give access to public.
• So if there is no bucket policy, that doesnt mean that object cannot be made public. We can use the Object ACL to make is readable to the world without having any bucket policy.
• However, if we go to the object and try to edit the ACL, it would not allow us and would show a message: 
  “This bucket has the bucket owner enforced setting applied for Object Ownership:
  When bucket owner enforced is applied, use bucket policies to control access.”
• This means, if we want to control the bucket object permissions via ACLs and not bucket policy, in that case first:
  • Go to S3 bucket —-> Permissions
  • Scroll down to “Object Ownership”. It mentions “This bucket has the bucket owner enforced setting applied for When bucket owner enforced is applied, use bucket policies to control access.” Click “Edit”
  • Now after clicking edit, you are taken to the “Edit Object Ownership” page where we can enable  object ACLs.
     
  • Here select “ACLs Enabled”. It shows “Objects in this bucket can be owned by other AWS accounts. Access to this bucket and its objects can be specified using ACLs.”. This means we are now allowing ACLs to set permissions on objects. —-> “I acknowledge”—>Choose “Bucket owner preferred” –> Click on “Save Changes”. Now your objects can use ACLs to give permissions. Hence ACLs needs to be enabled first before giving permissions to objects via ACLs.
  • After enabling, now go back to object and select the object.
  • Navigate to “Permissions” of object selected —> This time the “Access Control List” dialog box will have ‘Edit’ enabled. —> Click on “Edit”
  • Finally Choose Everyone (public access) –> Object and check the ‘Read’ option. And save. 
  • Now if you try to access the object from internet, it would be accessible without bucket policy.
• Conclusion: 

1.  Bucket Policy : The bucket policy mentioned above can be applied to the bucket after having ‘Block All Public Access’ to off. Without bucket policy, the objects cant be accessed.
2. Object ACLs: If we are not using bucket policy and ‘Block All Public Access’ is off, then we can use Object ACLs to make objects public. But this requires 2 things, first make “ACLs Enabled” in bucket permissions. Then go to object and edit its ACLs and give “read” access to Everyone (public access).
    
   So this means to make objects public, there are 2 level of security. First is “Block All Public Access” which needs to “Off” to make bucket public. And then second level access is more of object/folder specific where we can either use a bucket policy or Object ACL to give public access.

• If your central S3 bucket is in account_A and your are sending logs/files from Account_B and Account_C. The role of account_B and account_c needs to have “GetObjectACL” api call permissions in its IAM policy. And since this is cross account, the S3 bucket policy would also need to be updated to allow “GeObjectACL” api call without which the roles wont be able to send logs cross account. Ex: Like Kinesis Firehose sends  kinesis data via stream and the role attached to KInesis Firehose needs to have “GetObjectACL” permissions, further this role needs to be added to bucket policy with getObject and GetObjectACL permissions.

• ACLs actually generate and associate grants to different objects. So if we enable “bucket-owner-full-control” on an object and make the below mentioned api calls, it actually would return 2 Grants, one for the bucket owner giving him permissions and the other for Object owner.

1. 1. 1. for object owner
      2. for bucket owner

• The iam role sending the logs to destination bucket has “PutObjectACL” and “getObjectACL” permissions added to the IAM policy of the role.
• The destination bucket allows the above role to make  “PutObjectACL” and “getObjectACL” api calls in its bucket policy
• The ACL of the object being sent can be chosen while sending the object, hence in the cli command while sending the logs cross account, make sure to append –acl bucket-owner-full-control to make sure that the receiving bucket can view the objects also.

• If let’s say we created a website to download only purchased songs, singed URL can be generated and sent to customers so that they can be download the content.
• The main use-case here is that the bucket and object can remain private and not public, the signed URL would enable a guest user to access the private object even though they might not have an AWS account
• Pre-Signed URL can be generated using CLI adding ‘prefix’ to the command. It also can add requires an expiry time. 

1. It helps us recover a deleted object
2. If we upload same file but inside it has different text, the previous one gets overwritten, however with versioning, it allows us to recover the previous file as initial version.

Amazon S3 Inventory

1. Bucket level access: arn:aws:s3:::mybucketsample.com\

• Usually most companies have multiple AWS accounts to manage, maybe more than 100. The main things that are managed are:
  • Single SignOn option for users to be able to signIn to any account with single cred
  • Need single dashboard to view compliances of different AWS accounts
  • Would need CFN templates to deploy various services in different account which is manual work
• Control Tower solves these requirements and many more by integrating with these services such as AWS SSO, Config and aggregators, CF Stacks, best practices, AWS Organizations etc
• Control Tower makes sense in company who are newly deploying to AWS and want to scale env into multiple accounts without much fuss with CFN templates. Although usually companies would have their own SSO solution such as StreamlIne in Cisco and would rather choose to create a CFN that would deploy the architecture in few clicks. Why pay for extra cost.

• Service roles are used by services such as CFN to make api calls. IN case of CFN, if CFN doesnt have a role associated, then the API calls are made using permissions of the deployer. We get to choose a service role every time we are deploying a new stack.
• PassRole is a permission granted to IAM Users and resources that permits them to use an IAM Role.
  For example, imagine that there is an IAM Role called Administrators. This role has powerful permissions that should not be given to most users.
  Next, imagine an IAM User who has permissions to launch an Amazon EC2 instance. While launching the instance, the user can specify an IAM Role to associate with the instance. If the user (who is not an Administrator) were to launch an EC2 instance with the Administrators role, then they could login to the instance and issue commands using permissions from that role. It would be a way for them to circumvent permissions because, while not being an administrator themselves, they could assign the IAM Role to a resource and then use that resource to gain privileged access.
  To prevent this scenario, the user must be granted iam:PassRole permission for that IAM Role. If they do not have that permission, then they will not be permitted to launch the instance or assign the role within other services. It gives them permission to pass or attach a role to a service or resource.
   
• So basically when we choose an IAM role while deploying the stack since we want that CFN to use permissions of that IAM role, for this purpose, the IAM user which we are currently using should have PassRole permissions since its like passing a role to the resource. Also, whoever passes the role gets access to the resource and can further exploit these permissions. 
• Examples when passRole happens: 
  • While assigning an IAM role to the EC2. Now this IAM role can be used after logging into the EC2
  • While assigning role to the CFN template. Now this template can be used to create/delete resources based on passedRole permissions.
     

• Earlier it was very tough to manage your own mail server, it needs to be installed and configured
• Not that advanced, just very basic UI

• This is FIPS 140-2 Level 3 Validated
• Managed by AWS for network and overheads
• AWS CloudHSM automatically load balances the requests and securely duplicates keys stored in any HSM to all the other HSMs in the cluster
• Using atleast 2 HSM in different AZ is recommended for HA
• These clusters in which these HSMs are deployed, resides in VPC
   

• KMS uses Cloud HSM at backend intensively
• Our view/access terminates at KMS interface, behind that the KMS interface is connected to KMS hosts which are then connected to HSM and CMKs.
• Maximum 4kb of data can be encrypted by CMK, for more than data, data key is required.

• AWS KMS solution uses an envelope encryption strategy with AWS KMS keys. Envelope encryption is the practice of encrypting plaintext data with a data key, and then encrypting the data key under another key. Use KMS keys to generate, encrypt, and decrypt the data keys that you use outside of AWS KMS to encrypt your data. KMS keys are created in AWS KMS and never leave AWS KMS unencrypted.
• So to encrypt data
  1. So first a customer master key is generated
  2. From this CMK we request AWS to generate 2 keys, i. Cipher text data key ii. Plain text data key
  3. The plain text key is used to encrypt the plain text data. The data is now called Cipher text data
  4. The cipher text key is stored with the cipher text data. This Cipher text key itself is encrypted by the master key
• While Decryption:
  1. First we call the KMS decryption console/api and it returns us plain text key from our CMK
  2. This plain text key is then used to decrypt the cipher text key and then this decrypted cipher text key is used to decyrpt the data which is stored with it.

Encryption

• API request is sent to KMS to generate Data key using CMK. ‘GenerateDataKey’
• KMS returns response with Plain Data key and Encrypted Data key (using CMK).
• Data is encrypted using Plain Data key.
• Plain Data key is removed from memory.
• Encrypted Data and Encrypted Data Key is packaged together as envelope and stored.

• Encrypted Data key is extracted from envelope.
• API request is sent to KMS using Encrypted Data key which has information about CMK to be used in KMS for decryption.
• KMS returns response with Plain Data Key.
• Encrypted Data is decrypted using Plain Data key.
• Plain Data Key is removed from memory.

• First GenerateDataKey api call is made which gives 2 keys in return, both keys are same but one of them is encrypted key and the other one is the same key but encrypted which would be used to encrypt the plain text data.
• Data is encrypted using plain text data key
• Now since this plain text key is not secure, the plain text key is deleted. And the encrypted version of this key is stored with the data
• now data is encrypted using the plain text data key, and the data key is itself encrypted using our main CMK.

• Now when decryption is to happen, from the data, the encrypted data key is removed to find the details of the main CMK
• This encrypted key which was stored with the data is first decrypted by KMS using CMK. Now since this key is now decrypted, it can now be used to decryp the data
• So the data is  decrypted and then the unencrypted key is deleted.
• This is why it  is called envelop encryption since our plain data is encrypted with the plain data key, and then the plain data key is encrypted with our CMK.

• it’s irreversible after deletion.
• keys can be scheduled for deletion , default it 30 days wait period and range is 7 days to 30 days.
• It can be disabled immediately 

• Asymmetric encryption uses public and private keys to encrypt and decrypt the data
• Public key can be shared with public while private remains restricted and secret.
• So if person A has to receive a message from me. I’ll use person A’s pubic key to encrypt the data. Now this encrypted data reached Person A and only they will be able to decrypt it since decryption will require their own private key.
• Mostly used in SSH and TLS protocols. but also used in BitCoin, PGP, S/MIME
• Below are the 2 uses on Asymmetric Keys in AWS that can be done:

1. Encrypt and Decrypt     
2. Sign and Verify

• Data key is needed for every encryption operation. Now if there are several different applications/api calls requesting encryption, in that case its very tough to keep on generating and using data keys and it also shoots up the cost.
• As a solution, we can implement data key caching which would cache the data key after generating it so that it can be used in multiple different operations without every time generating it.
• However, it is not very secure since storing data keys is not recommended.

• If a key doesnt have any policy associated, then no one will have any access of that key. So basically no user, including root user and key creator have any access to the key unless specified explicitly on the key policy. This is different from S3 buckets where bucket policy can be left blank and users/roles can have access just with their own access policy.
• when default kms key policy is attached to the key, it enables administrators to define permissions at IAM level but that doesnt mean every would get access. The users will still need to be have KMS specific permissions policy attached to the user/role.
• THe KMS key policy actually has the first block which allows use of IAM policy by the users to access the key and in principal it mentions /root so that it applies to all users and roles.
•  

• Without permissions from KMS policy, even though IAM policy might give permissions to the user, the user wont be able to access/use the key if the key policy doesnt allow it. Hence permission is should be provided in both policies. This is unlike S3 where any one policy is enough to provide access.
• A CMK becomes unmanageable if the users  mentioned in the KMS key policy  gets deleted. Now even if we create another new user with the same name as mentioned in the policy, that user will also not have access and only original user has access but now its deleted.
• IN this case, just reach out to the AWS support who would help get access back to the key.
• Avoid deleting the default policy which is with /root user to make sure it doesnt become unmanageable.
   

1. using Key policy
2. Using IAm policies
3. Using Grants

• We can use our own key material while setting up the CMK. We have to use “External” in the ‘Advanced’ settings while creating the cmk first page.
• We get wrapping key and import token. Wrapping key is used to encrypt the key material.

• ALL KMS operations with symmetric CMKs have option to send encryption context while encrypting some data. Now if encryption context was provided during encryption, when you would be doing decryption, you would need to provide the same data again.
• This makes  like a 2nd security layer since each data that is encrypted might be encrypted with same key but if we provide unique encryption context, while decrypting even though same key would be used, every decryption would require that unique encryption context sent. This is called as Additional Authentication Data or AAD.
• Encryption context is provided while encrypting and it provided in key-value pair and has to be provided while decrypting the data.

• Key ID — (The Region element of the key ARN differs.)
• Key material
• Key material origin
• Key spec and encryption algorithms
• Key usage
• Automatic key rotation — You can enable and disable automatic key rotation only on the primary key. New replica keys are created with all versions of the shared key material. For details, see Rotating multi-Region keys.

1. Server Side Encryption
2. Client Side Encryption

• The destination bucket or buckets where you want Amazon S3 to replicate objects
• An AWS Identity and Access Management (IAM) role that Amazon S3 can assume to replicate objects on your behalf

• Use rate-based rules.
• Review existing rate-based rules and consider lowering the rate limit threshold to block bad requests.
• Query the AWS WAF logs to gather specific information of unauthorized activity.
• Create a geographic match rule to block bad requests originating from a country that isn’t expected for your business.
• Create an IP set match rule to block bad requests based on IP addresses.
• Create a regex match rule to block bad requests.

Benefits of AWS Shield Advanced

• Advanced real-time metrics and reports: You can always find information about the current status of your DDoS protection and you can also see the real-time report with AWS CloudWatch metrics and attack diagnostics.
• Cost protection for scaling: This helps you against bill spikes after a DDoS attack that can be created by scaling of your infrastructure in reaction to a DDoS attack.
• AWS WAF included: Mitigate complex application-layer attacks (layer 7) by setting up rules proactively in AWS WAF to automatically block bad traffic.
• You get 24×7 access to our DDoS Response Team (DRT) for help and custom mitigation techniques during attacks. To contact the DRT you will need the Enterprise or Business Support levels.

• In glacier, the data is stored as archives.
• Vault is a way through which the archives are grouped together in Glacier
• We can manage the access to this vault using IAM policies
• Resource based policy can also be enabled for vault.
• Vault lock allows us to easily manage and enforce compliance controls for vaults with vault lock policy.
• We can specify controls such as “Write Once read Many” (WORM) in vault policy and lock the policy from future edits
• Vault policies are immutable so a policy once created cant be changed.
• Creating vault lock policy gives a lock ID.
   

• AWS KMS can be used for server side encryption for encrypting data in DynamDB. This would be encryption at rest. We can either choose AWS-managed KMS key or choose our own CMK.
• We can also choose to do client side encryption which means first encrypt the data and then send.
• For Client Side encryption, DynamoDB provides a library on git called DynamoDB encryption Client.
   
   

• We can use secrets manager to store text/ keys or strings in an encrypted manner.
• Secrets manager can work with RDS database to store its creds and can be used by other databases as well.
• We can enable automatic rotation for our key or choose manual rotation.
• We also get code to use it in our SDK and retrieve the secrets.

• SM integrates with MySQL, PostgreSQL and Aurora on RDS very well to store the credentials and we can use autorotation with it.
• When we created a secret for RDS, it actually creates a lambda which would be going and changing the creds for rds when rotation is needed. So if the RDS is inside VPC, make sure to allow inbound for that lambda. Or have the lambda deployed in the same VPC.

• DNSSEC makes use of asymmetric keys via it uses private and public key.
• DNSSec creates a secure domain name system by adding cryptographic signatures to existing encrypted is provided with a signature. This creates another file sign.txt and when we use verify, the verify command will let us know if the message was tempered with.
• Verify similar to this DNSSEC works in which the website is verified. DNSSEC also uses a key which the servers use to verify if the server is actually the real server and then the website loads for the client.
• It does include more steps and hence more computational power is needed.
• We can enable DNSSEC in Route53 for our domain. we need to enable “DNSSEC singing”. this create KSK (key-signing key).
• When we request a website, we get back website IP and the website signature.

1. Dealing with exposed access keys
   1. Determine the access associate to the key
   2. Deactivate it
   3. Add explicit deny all policy
   4. review logs for see possible backdoor
2. Dealing with compromised EC2 instace
   1. Lock Down the Ec2 instance security group
   2. take EBS snapshot
   3. Take  a memory dump
   4. Perform the forensics analysis
3. GuardDuty
   1. Whitelist EIP of Ec2 if we are doing pen testing
   2. It uses VPC Flow logs, Cloudtrail logs and DNS logs
   3. It can generate alerts is Cloudtrail gets disabled.
4. We can now use “PreAuthorized scanning engine” for pen testing aws env without asking for permissions from AWS like used to be done earlier.
5. Fields of VPC Flow logs:
   1. version : flow log version
   2. account id
   3. network interface id
   4. source address
   5. destaddr: destination address
   6. source port
   7. dest port
   8. protocol number
   9. number of packets transferred
   10. number if bytes transferred
   11. start time in seconds
   12. end time in seconds
   13. action : accept vs reject
   14. logging status of flow log
6. AWS Inspector scans target based on various baselines:
   1. Common Vul and Exporsure ie CVE
   2. CIS bechmarks
   3. Security Best Practices
   4. Network Reachability
7. Systemes Manager:
   1. Run command: to run commands on Ec2
   2. patch complaince: allows us to check compliance status for theec2 with respect to patching activity
   3. Patch baseline: This determine what patches are needed to be installed in Ec2.
      we can also define the approval for the same
   4. maintainance window
   5. parameter store
8. AWS Config use cases
   1. Can be used to audit iAM policy assigned to uses before and after specific event
   2. detect is cloudtrail is disabled
   3. verify ec2 has approved ami only
   4. detect open to world security groups
   5. detect is ebs volumes are encrypted
   6. It can work with lambda for automated remediations
9. AWS AThena
   1. This doesnt require additional infra to query logs in s3
10. AWS WAF
    1. Can be attached to ALB, CLoudFront Distribution and API gateway
    2. Blocks layer 7 attacks
    3. Can also be used to block user-agent headers
11. CloudWatch Logs
    1. Steps to setup and troubleshoot logs are imp
    2. First assign appropriate role to Ec2, then install the cloud Agent and finally configure the agent to log correctly.
    3. Verify if awslogs agent is running
    4. CloudWatch metric filter can be used to get alerts
12. IP Packet inspection
    1. If we want to inspect the IP packets for anomalies, we have to create a proxy server and route all the traffic from VPC through that server.
    2. install appropriate agent on the hosts and examine at the host level
13. AWS Cloudtrail
14. AWS Macie: Can be used to find PII data in s3 bucket
15. AWS Secuirty hub: help with compliance management
16. Services that would help us in case of DDOS attack:
    1. WAF
    2. Autoscaling
    3. AWS Sheild (layer 3, layer 4 and layer 7)
    4. R53
    5. CloudWatch
17. EC2 key pair
    1. If we create ami of ec2 and copy it in a different region, and launch an Ec2 from that ami, the new ec2 will still have older .public key in the authorized_keys file. We can use the older private key to use to ssh in this new Ec2
18. EBS secure Data wiping
    1. AWS wipes the data when provisioning it for  new customer
    2. before deleting ebs, we can also wipe data manually
19. Cloudfront
    1. We can use OAI so that only the requried customer can view the content
    2. We can use SignedURLS for
       1. RTMP distribution, this is not supported for cookies
    3. We can use signed cookies when we have multiple files in same format requiring restricting access. hence used in multiple files.
    4. CFN uses custom TLS certificate.
20. VPC Endpoints
    1. gateway endpoint
    2. interface endpoint
21. NACLs
    1. Statless firewall offering
    2. max 40 rules can be applied
22. AWS SES
    1. used for emails
    2. Can be encrypted
23. Host Based IDS
    1. This can be installed manually on Ec2 for “file integrety monitoring”.
    2. Can be integrated with CloudWatch for alerting
24. IPS
    1. for intrution prevention system, this can be installed on Ec2 to scan traffic and send data to central ec2
25. ADFS
    1. Active Directory federation Service (ADFS) is a SSo solution by microsoft.
    2. Supports SAMl
    3. Imp: AD groups are associated to the IAM roles. AD GROUP ——-> IAM ROLE
26. Cognito
    1. Provides authentication, authorization and user management for web and app
    2. good choice for mobile application auth needs
    3. Catch word: Social Media website
27. KMS
    1. If we have accidentally deleted the imported key material, we can download the new wrapping key and import token  and import the original key into existing CMK
        
    2. Encrypt APi can only encrypt data upto 4KB. 
    3.  
       GenerateDataKeyWithoutPlaintext: Returns a unique symmetric data key for use outside of AWS KMS. This operation returns a data key that is encrypted under a symmetric encryption KMS key that you specify. The bytes in the key are random; they are not related to the caller or to the KMS key.
       GenerateDataKeyWithoutPlaintext is identical to the GenerateDataKey operation except that it does not return a plaintext copy of the data key.
       This operation is useful for systems that need to encrypt data at some point, but not immediately. When you need to encrypt the data, you call the Decrypt operation on the encrypted copy of the key.
       It’s also useful in distributed systems with different levels of trust. For example, you might store encrypted data in containers. One component of your system creates new containers and stores an encrypted data key with each container. Then, a different component puts the data into the containers. That component first decrypts the data key, uses the plaintext data key to encrypt data, puts the encrypted data into the container, and then destroys the plaintext data key. In this system, the component that creates the containers never sees the plaintext data key.
        
    4. To use the an expiring CMK without changing neither the CMK nor the key material, we will have to re-encrypt the CMK and import the same key materials again into the CMK, this gives new expiration dates.
    5. Import token while importing CMK key material is only valid for 24 hours

    6. Digital signing with the new asymmetric keys feature of AWS KMS

        
    7.  
28. S3
    1.     To restrict access to the bucket based on region, StringLike : {“S3: LocationContraint”: “us-west-2”}

1. KMS Key imports concepts
2. Credential report contents
3. key rotation enable/disable and frequency
4. SCP should not be applied to root account
5. How and which service does Document Signing

Rotating AWS KMS keys

• Reusing same KMS key is not encouraged and hence either create a new KMS key for your application or just rotate the existing key materials of the key.
• If we enable ‘Automatic Key Rotation’, in that case AWS would rotate the keys every year automatically.
• Also, the previous/older key material is still stored in KMS so that the data that was encrypted using previous key material can still be decrypted. The previous key material is only deleted when the KMS key itself is deleted.
• We can track the key rotation on AWS CloudWatch And Cloudtrail logs.
• When a key material is rotated, if we ask the Key to now decrypt the data, the decryption would happen automatically by the older key material which was used to encrypt the data. There is no need to specify which key material should be used, KMS transparently does this for us without any additional steps or code changes. However, the newer encryptions would use new key materials for encryption and decryption.
• i.e. When you use a rotated KMS key to encrypt data, AWS KMS uses the current key material. When you use the rotated KMS key to decrypt ciphertext, AWS KMS uses the version of the key material that was used to encrypt it. You cannot request a particular version of the key material. Because AWS KMS transparently decrypts with the appropriate key material, you can safely use a rotated KMS key in applications and AWS services without code changes.
• However, automatic key rotation has no effect on the data that the KMS key protects. It does not rotate the data keys that the KMS key generated or re-encrypt any data protected by the KMS key, and it will not mitigate the effect of a compromised data key.
• Rotation of the keys managed by AWS is automatically done by AWS and it cannot be enabled/disbaled by us.
• In May 2022, AWS KMS changed the rotation schedule for AWS managed keys from every three years (approximately 1,095 days) to every year (approximately 365 days). Ref: https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html
• New AWS managed keys are automatically rotated one year after they are created, and approximately every year thereafter.
• Existing AWS managed keys are automatically rotated one year after their most recent rotation, and every year thereafter.
• The properties of the KMS key, including its key ID, key ARN, region, policies, and permissions, do not change when the key is rotated.
• You do not need to change applications or aliases that refer to the key ID or key ARN of the KMS key.
• Rotating key material does not affect the use of the KMS key in any AWS service.
• After you enable key rotation, AWS KMS rotates the KMS key automatically every year. You don’t need to remember or schedule the update
• You might decide to create a new KMS key and use it in place of the original KMS key. This has the same effect as rotating the key material in an existing KMS key, so it’s often thought of as manually rotating the key.
• Manual rotation is a good choice when you want to control the key rotation schedule. It also provides a way to rotate KMS keys that are not eligible for automatic key rotation, including:
  • asymmetric KMS keys
  • HMAC KMS keys
  • KMS keys in custom key stores
  • KMS keys with imported key material
• KMS CMK: Automatic key rotation is disabled by default on customer managed keys but authorized users can enable and disable it. When you enable (or re-enable) automatic key rotation, AWS KMS automatically rotates the KMS key one year (approximately 365 days) after the enable date and every year thereafter.
• Multi-Region Keys: You can enable and disable automatic key rotation for multi-Region keys. You set the property only on the primary key. When AWS KMS synchronizes the keys, it copies the property setting from the primary key to its replica keys. When the key material of the primary key is rotated, AWS KMS automatically copies that key material to all of its replica keys. For details, see Rotating multi-Region keys.
• While a KMS key is disabled, AWS KMS does not rotate it. However, the key rotation status does not change, and you cannot change it while the KMS key is disabled. When the KMS key is re-enabled, if the key material is more than one year old, AWS KMS rotates it immediately and every year thereafter. If the key material is less than one year old, AWS KMS resumes the original key rotation schedule.
• While a KMS key is pending deletion, AWS KMS does not rotate it. The key rotation status is set to false and you cannot change it while deletion is pending. If deletion is canceled, the previous key rotation status is restored. If the key material is more than one year old, AWS KMS rotates it immediately and every year thereafter. If the key material is less than one year old, AWS KMS resumes the original key rotation schedule.

Rotating keys manually

• Manual rotation means creating a new KMS key which would have new key materials. Ie You might want to create a new KMS key and use it in place of a current KMS key instead of enabling automatic key rotation. When the new KMS key has different cryptographic material than the current KMS key, using the new KMS key has the same effect as changing the key material in an existing KMS key. The process of replacing one KMS key with another is known as manual key rotation.
• Manual rotation gives us power to manage when the key materials should be rotated. Because we can anytime create a new key.
• However, when we do this manual rotation of the key, we need to update references to the KMS key ID or Key ARN in our application.
• Aliases, which associate a friendly name with a KMS key, can make this process easier. Use an alias to refer to a KMS key in your applications. Then, when you want to change the KMS key that the application uses, instead of editing your application code, change the target KMS key of the alias.
• When calling the Decrypt operation on manually rotated symmetric encryption KMS keys, omit the KeyId parameter from the command. AWS KMS automatically uses the KMS key that encrypted the ciphertext.
• Use Key Alias is like the key name which we can mention in our code. Now if we did manual rotation, the KEY arn would have changed, due to which in our codes we’ll have to update the Key ARN. This is why key alias is used in codes, because Alias of the older key can be given to the newly created key. Its like naming a file with the same name so that code would pick the new file. For this, ‘update-alias’ command is used.

• We can create a KMS key without any key materials and then choose to import our own key materials into the KMS key. This feature is called as ‘bring your own key (BYOK)’.
• Create a symmetric encryption KMS key with no key material – The key spec must be SYMMETRIC_DEFAULT and the origin must be EXTERNAL
• Imported key material is supported only for symmetric encryption KMS keys in AWS KMS key stores, including multi-Region symmetric encryption KMS keys. It is not supported on:
  • asymmetric KMS keys
  • HMAC KMS keys
  • KMS keys in custom key stores
• We cannot do automatic key rotation for imported key materials. For this we’ll have to
• You must reimport the same key material that was originally imported into the KMS key. You cannot import different key material into a KMS key. Also, AWS KMS cannot create key material for a KMS key that is created without key material.

• user
• arn
• user_creation_time
• password_enabled
• password_last_used
• password_last_changed
• password_next_rotation
• mfa_active
• access_key_1_active
• access_key_1_last_rotated
• access_key_1_last_used_date
• access_key_1_last_used_region
• access_key_1_last_used_service
• access_key_2_active
• …..
• cert_1_active