Put your subtitle here. Feel free to pick from the handful of pretty Google colors available to you.Make the subtitle something clever. People will think it’s neat.

Welcome!DoiT InternationalPracticing multi-cloud & cloud cyber security since 2010.

DoIT International confidential │ Do not distribute

DoIT International confidential │ Do not distribute

DoIT International confidential │ Do not distribute

● Customer Operations Engineer

● Big Data Engineering

● Cloud Sales Rep.

Looking for Talent

Put your subtitle here. Feel free to pick from the handful of pretty Google colors available to you.Make the subtitle something clever. People will think it’s neat.

AWS Cyber Security Best PracticesShay Kirshenboim - Cloud Cyber Security // DoiT International

Agenda

1

2

3

4

5

AWS Security Components

MFA Authentication

Logging, Audit and Monitoring tools

AWS Shield & WAF

Centralize logs using AWS Elastic6

AWS Monitoring and Security Controls

& Trusted Advisor

ElasticSearch Service

AWS Shared Security Model

AWS Security Groups and Network ACLs

Security Groups

Affects Instances (1st protection layer)

Only "Allow" rules & by default "Deny"

Stateful (Return traffic is allowed)Rules order is insignificant as all

rules are “allow” rulesMany to many relationship

10

Network ACL’s

Affects an entire subnet (2nd protection layer)

Support “Allow” & “Deny” rulesStateless (You must explicitly allow

return trafficEvaluates rules in number order (like

traditional firewall)

Security Groups & Network ACL’s

Security Groups

Avoid using the “default VPC security group” which enables inbound communication from all members of the SG and outbound communication to any destination

Delete “any to any” rules and configure specific name servers and other services rules as needed

Use easy to understand names (and naming convention)Create functional related SG (db servers, web server etc.)Create default SG for Infra services (Windows RDP or Linux ssh etc.)Try to balance simplicity of SG and amount of SG per instance to achieve

simple management.Enable VPC flow logs

Security Groups & NACL’s - Best Practices

Monitor changes to SG (Demo)

Identify your critical SGs (sg-8f9ee8f7)Create Lambda execution role and policyCreate Lambda function:

review Code, configure role and handler

"detail-type": [ "AWS API Call via CloudTrail" ], "detail": { "eventSource": [ "ec2.amazonaws.com" ], "eventName": [ "AuthorizeSecurityGroupIngress", "RevokeSecurityGroupIngress" ], "requestParameters": { "groupId": [ "<YourSGid>"

● Configure CloudWatch rule to catch API callsthat may cause SG changes

● Modify SG and look for CloudWatchphrases : ‘This permission must be authorized’ ‘This permission must be revoked’

Auto Update SG using SNS & Lambda

Use case: Update Web servers SG with AWS CloudFront IP ranges

Target SGs tagged with “Name:cloudfront” and “AutoUpdate:true”

IAM policy and role (as in previous example)

Create Lambda function using code

Configure Lambda function's trigger by SNS subscriptionaws sns subscribe --topic-arn arn:aws:sns:us-east-1:806199016981:AmazonIpSpaceChanged --protocol

lambda --notification-endpoint <Lambda ARN>

Run test Check Security Group Inbound rules⇒

Alert on IAM policy change

The process:

Logs mark “DefaultLogGroup” create metric filter:⇒ ⇒ { ( ($.eventSource = "iam.amazonaws.com") && (($.eventName = "Add*") || ($.eventName = "Attach*") || ($.eventName = "Change*") || ($.eventName = "Create*") || ($.eventName = "Deactivate*") || ($.eventName = "Delete*") || ($.eventName = "Detach*") || ($.eventName = "Enable*") || ($.eventName = "Put*") || ($.eventName = "Remove*") || ($.eventName = "Set*") || ($.eventName = "Update*") || ($.eventName = "Upload*")) ) }

Same can be done for SG, S3 bucket policy etc.Examples

Attach IAM Role to an Existing EC2

New! (Feb 2017) Attach the IAM role to an existing EC2 instance that was

originally launched without an IAM role / Replace the attached IAM roleCreate an instance profileaws iam create-instance-profile

Add a role to an instance profileaws iam add-role-to-instance-profile

List instance profilesaws iam list-instance-profiles aws iam list-instance-profiles-for-role

Remove a role from an instance profileaws iam remove-role-from-instance-profile

Delete an instance profileaws iam delete-instance-profile

Bastion Host and MFA

Securing (at least) your Bastion Host with MFA

1. Install and launch Google Authenticatorsudo yum install google-authenticator –y ⇒ google-authenticator

2. Configure the sshd PAM module to use Google Authenticator: vi /etc/pam.d/sshd

Add: auth required pam_google_authenticator.so

Comment out: auth substack password-auth

3. Configuring SSH so that Google Authenticator is called as a second factor of authentication vi /etc/ssh/sshd_config

change: “ChallengeResponseAuthentication” option to “yes”

add: to the bottom of the file: “AuthenticationMethods publickey,keyboard-interactive”

4. Restart SSH daemonsudo /etc/init.d/sshd restart

Enable MFA Protection on Your AWS API

1. Author an IAM policy to grant “Allow” access for MFA-authenticated users1. Using aws:MultiFactorAuthPresent

"Sid": "AllowActionsForEC2WhenMFAIsPresent", "Effect":"Allow", "Action":"ec2:RunInstances", "Condition":{

"Bool":{"aws:MultiFactorAuthPresent":"true"}

2. <Demo> Preventing AWS API calls from left open consoles1. Using aws:MultiFactorAuthAge and Conditions

Long-term credentials (IAM user access keys) cannot be used with MFA-protected API access because they don't expire (AWS CLI) !

Enable MFA Protection on Your AWS CLI

1. Using temporary session token $ aws sts get-session-token --serial-number arn:aws:iam::AWS-account-number:mfa/user --token-

code code-from-token (Optional: --profile user)

2. Edit the AWS CLI credentials file, which defaults to ~/.aws/credentials with returned values:[profile-name]aws_access_key_id = <Access-key-as-in-returned-output>aws_secret_access_key = <Secret-access-key-as-in-returned-output>aws_session_token = <Session-Token-as-in-returned-output>

3. <Demo> ec2 describe-instances only to MFA enabled users using “AWS CLI"

4. Check out AWS Security Blog for very useful guides (an excellent example: How to Record SSH Sessions Established Through a Bastion Host)

Inspector / Trusted Advisor (Business Support)

AWS Trusted Advisor Security Checks

● Upgrading your Support plan will enable many more security best practices checks

AWS Inspector

Prerequisites: Create Role Tag EC2 instances ⇒ ⇒Install AWS agent:

curl -O https://d1wk0tztpsntt1.cloudfront.net/linux/latest/install

sudo bash install

sudo /opt/aws/awsagent/bin/awsagent status

Auto install Agent when launching new instance

Advanced Details User Data⇒#!/bin/bash

cd /tmp

curl -O https://d1wk0tztpsntt1.cloudfront.net/linux/latest/install

chmod +x install

./install

AWS Inspector Findings (examples)Security Best Practices-1.0:Finding Instance xxxx is configured to allow users to log in with root credentials over SSH. This increases the likelihood of a successful brute-force attack.Description This rule helps determine whether the SSH daemon is configured to permit logging in to your EC2 instance as root.Recommendation It is recommended that you configure your EC2 instance to prevent root logins over SSH. Instead, log in as a non-root user and use sudo to escalate privileges when necessary. To disable SSH root logins, set PermitRootLogin to "no" in /etc/ssh/sshd_config and restart sshd

AWSLabs GitHub links: https://github.com/awslabs/amazon-inspector-agent-autodeploy Lambda job in Python to automatically deploy Inspector agent to newly-launched EC2 instances.

https://github.com/awslabs/amazon-inspector-finding-forwarder

Lambda script that receives findings from the Amazon Inspector service in AWS, via SNS, and forwards them to a destination email address.https://github.com/awslabs/aws-security-benchmarkCollection of resources related to security benchmark currently: CIS AWS Foundations Benchmark 1.1

How to Remediate Amazon Inspector Security Findings Automatically

AWS Shield & WAF

AWS Shield

Rules

AND / ORAllow, Block or

CountOrdered

conditions

AWS WAFWeb ACLs contain rules

Rule#1: Block Bad User-AgentsIP matchSuspicious IPs

&String match

Bad botsORRule#2: Block SQLiSQLi match

SQLi checks

ELSEDefault Action: Allow

Conditions

IP matchSuspicious IPs192.0.2.0/24

StringUser-Agent header matches Bad bots

SQL injectionURI contains SQL injection

Recommended Order

1. WhiteListed iPs- Allow

2. BlackListed IPs- Block

3. BlackListedSignatures- Block

4. SQLInjection- Block

5. SuspiciousActivity- Count

Default: Allow

AWS WAF Security Automationshttp://docs.aws.amazon.com/solutions/latest/aws-waf-security-automations/deployment.html

Lambda Functions:Log Parser:

parses CloudFront access logs to identify suspicious behavior, such as an abnormal amount of requests or errors. It then blocks those IP addresses for a customer-defined period of time. Default Parameters: RequestThreshold:400, ErrorThreshold:50, WAFBlockPeriod:240(min)

IP Lists Parser:checks third-party IP reputation lists hourly for new IP ranges to block. These lists include the Spamhaus Don't Route Or Peer (DROP) and Extended Drop (EDROP) lists, the Proofpoint Emerging Threats IP list, and the Tor exit node list.

BadBot Parser:intercepts and inspects trap endpoint requests to extract its IP address, and then add it to an AWS WAF block list.

AWS ElasticSearch

Forensics on logs with AWS ElasticSearch (or your own)

Create your Elasticsearch domain

Stream all relevant logs (CloudWatch)

Create Dashboards by topic

Monitor and Investigate

Section Slide Template Option 2

Put your subtitle here. Feel free to pick from the handful of pretty Google colors available to you.Make the subtitle something clever. People will think it’s neat.

Questions?

Put your subtitle here. Feel free to pick from the handful of pretty Google colors available to you.Make the subtitle something clever. People will think it’s neat.

Thank You!DoiT International

Practicing multi-cloud & cloud cyber security since 2010.