We believe that security *IS* a shared responsibility, - when we give developers the power to create infrastructure, security became their responsibility, too.
During this meetup, we'd like to share our experience with implementing security best practices, to be implemented directly by development teams to build more robust and secure cloud environments. Make cloud security your team's sport!
1. 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 International
Practicing multi-cloud & cloud cyber security since 2010.
4. DoIT International confidential │ Do not distribute
● Customer Operations Engineer
● Big Data Engineering
● Cloud Sales Rep.
Looking for Talent
5. 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 Practices
Shay Kirshenboim - Cloud Cyber Security // DoiT International
10. 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” rules
Many to many relationship
10
Network ACL’s
Affects an entire subnet (2nd
protection layer)
Support “Allow” & “Deny” rules
Stateless (You must explicitly allow
return traffic
Evaluates rules in number order (like
traditional firewall)
Security Groups & Network ACL’s
11. 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
12. Monitor changes to SG (Demo)
Identify your critical SGs (sg-8f9ee8f7)
Create Lambda execution role and policy
Create 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 calls
that may cause SG changes
● Modify SG and look for CloudWatch
phrases : ‘This permission must be authorized’
‘This permission must be revoked’
13. 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 subscription
aws 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
14. 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
15.
16. 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 role
Create an instance profile
aws iam create-instance-profile
Add a role to an instance profile
aws iam add-role-to-instance-profile
List instance profiles
aws iam list-instance-profiles
aws iam list-instance-profiles-for-role
Remove a role from an instance profile
aws iam remove-role-from-instance-profile
Delete an instance profile
aws iam delete-instance-profile
18. Securing (at least) your Bastion Host with MFA
1. Install and launch Google Authenticator
sudo yum install google-authenticator –y ⇒ google-authenticator
1. 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
1. 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”
1. Restart SSH daemon
sudo /etc/init.d/sshd restart
19. Enable MFA Protection on Your AWS API
1. Author an IAM policy to grant “Allow” access for MFA-authenticated users
1. Using aws:MultiFactorAuthPresent
"Sid": "AllowActionsForEC2WhenMFAIsPresent",
"Effect":"Allow",
"Action":"ec2:RunInstances",
"Condition":{
"Bool":{"aws:MultiFactorAuthPresent":"true"}
1. <Demo> Preventing AWS API calls from left open consoles
1. 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) !
20. 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)
1. 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>
1. <Demo> ec2 describe-instances only to MFA enabled users using “AWS CLI"
2. Check out AWS Security Blog for very useful guides (an excellent example:
How to Record SSH Sessions Established Through a Bastion Host)
22. AWS Trusted Advisor Security Checks
● Upgrading your Support plan will enable many more security best
practices checks
23. 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
24. 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-
benchmark
Collection of resources related to security benchmark
currently: CIS AWS Foundations Benchmark 1.1
How to Remediate Amazon Inspector Security Findings Automatically
27. Rules
AND / OR
Allow, Block or
Count
Ordered
conditions
AWS WAF
Web ACLs contain rules
Rule#1: Block Bad User-
Agents
IP match
Suspicious IPs
&
String match
Bad bots
OR
Rule#2: Block SQLi
SQLi match
SQLi checks
ELSE
Default Action: Allow
Conditions
IP match
Suspicious IPs
192.0.2.0/24
String
User-Agent
header matches
Bad bots
SQL injection
URI contains SQL
injection
Recommended Order
1. WhiteListed iPs-
Allow
2. BlackListed IPs-
Block
3. BlackListedSignat
ures- Block
4. SQLInjection-
Block
5. SuspiciousActivity-
Count
Default: Allow
28. AWS WAF Security Automations
http://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.
29. 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
30. 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?
31. 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.
Notas do Editor
Before we talk about the next generation stack, let’s look at the principles that underlie it.