2. Overview
• Cloud - Responsibilities
• AWS Reference Model
• Architecture
• Two Sides of the Cloud
• Securing the Cloud Fabric
• Securing the Assets in the Cloud
• Some Use Cases
3. Reference Documents:
Cloud Security Alliance (CSA) – Security Guidance for Cloud Computing
V3.0
Amazon Web Services – AWS Security Best Practices
Amazon Web Services – Risk and Compliance
Amazon Web Services – Operational Checklists for AWS
Amazon Web Services – Auditing Security Checklist for Use of AWS
PCI DSS – Cloud Computing Guidelines
Netflix Open Source Simian Army for AWS
4. Responsibilities – Provider vs. Customer
CUSTOMER
Reference: PCI Security Standards Council PROVIDER
LESS
C
U
S
T
O
M
E
R
MORE
MORE
P
R
O
V
I
D
E
R
LESS
5. AWS Reference Model - High Level Overview
Customer Virtual Private Cloud (VPC)
AWS Cloud
Customer Network
6. Amazon VPC (Virtual Private Cloud) Concept
virtual private cloud
Security Group 1
EC2
VM Instances
VPC subnet 1
Security Group 2
EC2
VM Instances
VPC subnet 2
Availability Zone Availability Zone
Security Group 4
VPC subnet 4
Availability Zone
Security Group 3
VPC subnet 3
Availability Zone
AWS Region 1
EC2
VM Instances
EC2
VM Instances
Cloud Provider is Responsible
For providing Infrastructure
And Security
Multiple Availability Zones are
Available in each region
Customer is Responsible for Creating
Assets and Security
7. Architecture using VPN Tunnels
AWS Region 1
(Oregon) Availability
Zone
Availability
Zone
Availability
Zone
Customer
DMZ 1 (City 1)
Customer
DMZ 2 (City 2)
Redundant VPN Connections
With BGP for Network Routing
Desired regional redundancy
AWS Region 1
(Virginia) Availability
Zone
Availability
Zone
Availability
Zone
AWS Internet Gateway
Firewall Rules
For IN and OutBound
Firewall Rules
For IN and OutBound
This design is different from Direct Connect
8. Two Sides of AWS Management
• Managing the Cloud Fabric (SDN and Data Center Layer)
VPCs, Subnets, Security Groups (Firewalls)
S3 Buckets (Storage)
Managing and Monitoring Access to the SDN Layer
API Keys
Network Encryption
Route 53 (DNS) etc.
• Managing the Assets built in the Cloud
EC2 instances (Operating System)
Applications, Databases and Related Resources
User and Service Accounts
Client and Server side Encryption
Operations/Monitoring
9. Securing the Cloud Fabric
Network Segmentation
Security Auditing and Monitoring
10. Securing the Cloud Fabric – Access Controls
• Users
• Put away AWS “ROOT” Account of AWS Console and use AWS IAM
• Create Unique AWS Credentials with password policies using AWS IAM
• Create appropriate Groups, Roles (Read Only, Admins etc.)
• Enable MF authentication using Soft Token (using Google Authenticator)
• Restrict access to S3 buckets and CloudTrail
• API Keys (Access Keys)
Access Keys are needed for automation to make programmatic calls.
• Secret Key from the Access Key pair must be secured by the assigned user
• Restrict Access Keys to IP address (e.g. Ansible Tower or Bastion Host)
• Enable Multi Factor for API calls with high risk
• Identify high risk API calls
• e.g. creating or deleting Subnets, ELBs etc.
• Develop Access Key Rotation Policies and Procedures
• Develop a ‘Central Server with Access Keys’ approach
11. Securing the Cloud Fabric
Access Control
Security Auditing and Monitoring
12. Securing the Cloud Fabric – Network Segmentation
• Isolate all Cloud Assets from direct Internet access
• Restrict Public facing subnets to ELBs and instances with need for fixed IPs
• Create Private subnets for EC2 instances
• All customer application access communication happens through ELBs
• Restrict all EC2 asset management access to Customer Network
• Route all traffic initiated from EC2 instances through Customer Network OR
• Use NATed instances to route internet traffic
• Use Virtual Firewalls (Security Groups) for individual Business Apps
• Create Security Groups for individual Apps
• Create a standard for future Apps
• Use Network ACLs to provide high level network security
• Control traffic between AWS Cloud and Customer Network
• Create firewall policies on the VPN tunnel terminating point
• Enable IDS on VPN End Points
13. Current Architecture – Network Segmentation
Public Zones
ONLY Elastic Load Balancers (ELB)
Private Zones with VM instances
Customer
DMZ 1 (City 1)
Customer
DMZ 2 (City 2)
AWS Internet Gateway
Redundant VPN Connections
With BGP for Network Routing
Current Setup
Public Zones
ONLY Elastic Load Balancers (ELB)
Private Zones with VM instances
AWS Region 1
(Oregon)
AWS Region 2
(Virginia)
15. Securing the Cloud Fabric – Security Auditing
• Tag assets - Tag metadata consisting of up to 10 key/value pairs
• Create Tags to identify asset functionality
• Required Tags
• Business Owner
• Application
• Public or Internal App
• Data Classification
• Use Tags to identify usage cost structure
$2,000.00
$1,800.00
$1,600.00
$1,400.00
$1,200.00
$1,000.00
$800.00
$600.00
$400.00
$200.00
$0.00
3/1/14 4/1/14 5/1/14 6/1/14 7/1/14 8/1/14
Series1
16. Securing the Cloud Fabric – Security Auditing
• Enable Cloud Logs
• CloudTrail (Logs all API calls made to AWS to create high level services using
AWS Console, API keys etc)
• Create Procedures for Logs on New Objects
• Restrict Access to CloudTrail
• Monitor Logs for suspicious activity at Cloud Layer
• Create Alerts on High Severity Activities
• Enable AWS Trusted Advisor Alerts
• Monitor Billing for Suspicious Activity
• Audit Scan reports to monitor changes (e.g. Nessus has a best practices plugin)
• Implement Monitoring Tools
• Open Source
• Commercial
• Create Procedures
• Operationalize
17. Securing the Cloud Fabric – Monitoring Challenges
• Mapping traditional Security Stack to Cloud Architecture
• Need Data Analytics
• In-House efforts on using BigData for Analytics (not much progress)
• Commercial options (Dome9, Splunk and Others)
• No single point solution for monitoring changes to Cloud
• Netflix Open Sources (Edda and Security Monkey)
• Trusted Advisor
• Monitor API Keys
• Develop an automated process
19. Securing the Assets – The Traditional Controls
• System Hardening (Build Secure Base AMI)
• Application Hardening
• System & Application Access Control
• Network Segmentation
• Data Protection at Rest and In Transit
• Data Classification
• Vulnerability Scanning
• Patch Management
• Software Licensing
• Asset Tracking
• Change Control
• DR
• Security Monitoring & IR
• System Decommissioning
How do these map into Cloud?
What is covered under Traditional
Processes?
What is covered under Automation?
What else is needed?
20. Securing Assets – Mapping Traditional Security
• System Hardening (Build Secure Base AMI)
• Application Hardening
• System & Application Access Control
• Network Segmentation
• Data Protection at Rest and In Transit
• Data Classification
• Vulnerability Scanning
• Patch Management
• Software Licensing
• Asset Tracking
• Change Control
• DR
• Security Monitoring & IR
• System Decommissioning
• Packet inspection at all egress points
• Security Event and Incidents (SIEM)
• Firewalls
• Network and Host based IDS/IDP
• Encryption
• Proxies
• Forensics & Malware Analysis
• Vulnerability Scanning
• Other in-line protection (e.g. FireEye)
• Monitoring
21. Securing Assets – Mapping Traditional Security
• Packet inspection means either
routing all the traffic back to
customer location or building
another stack in the cloud
• Network scans require pre-authorization
from the cloud
provider
• Not easy to map current day in-line
solutions to cloud
• Packet inspection at all egress points
• Security Event and Incidents (SIEM)
• Firewalls
• Network and Host based IDS/IDP
• Encryption
• Proxies
• Forensics & Malware Analysis
• Vulnerability Scanning
• Other in-line protection (e.g. FireEye)
• Monitoring
23. Encryption – Use Case
• Encryption – Rentable CloudHSM for Single Tenant
• Centralized Key Management Solution – NIST 800-57 and Oasis Key
Management Interoperability
• Pre-Boot authentication for EC2/EBS
• Client-side object encryption for S3
• File encryption for EC2 and S3 – available but need to be investigated
• Proxy based encryption
• Any future workloads with sensitive data should evaluate this first
• Key Management (ssh and API)
26. Enterprise Logging Architecture - Kafka
• Enterprise Log Management (Beyond Security Logging)
• Create logging strategy (e.g. KAFKA, ELK etc.)
• Log Analysis Tools (Analytics)
• Kafka - Developed by LinkedIn and now part of Apache project
• Distributed system, easy to scale
• Multiple Producers and Consumers
• Producer
• Publishes messages to a Topic
• Topic
• Message of a particular type
• Consumer
• Can subscribe to one or more Topics
27. Enterprise Logging Architecture – ELK
• Integrated Stack - Elastic Search, LogStash & Kibana (ELK)
• Supports
• Many Log Structures
• Fast Searching
• Scalability
• Customizable Visualization
• Commercial Support Available
Notas do Editor
We live in a connected world and the foundation for these connections is the network.
Broadband Internet traffic is doubling each and every year (according to IDC) [or] Internet traffic worldwide will grow three-fold by the year 2017. (Internet Trends, Mary Meeker (KCPB)
Today we have 2.5 billion Internet users in the world – roughly one-third of the Earth’s population. In the next decade, the number of Internet users will double to 5 billion (Mary Meeker, KPCB)
That means that two-thirds of the world will be connected by 2023.
When you add in the big trends of cloud, mobility, video and security, the combined rate of acceleration is placing unprecedented demands on the network.
[Optional stats/factoids]
100 hours of video uploaded every single minute to YouTube (YouTube)
Mobile video traffic exceeded 50 percent for the first time in 2012. (Cisco VNI)
Mobile network connection speeds more than doubled in 2012. (Cisco VNI)
In 2012, a fourth-generation (4G) connection generated 19 times more traffic on average than a non-4G connection. Although 4G connections represent only 0.9 percent of mobile connections today, they already account for 14 percent of mobile data traffic. (Cisco VNI)
[NOTE: Consider finding alternate source for above stats to avoid siting Cisco]
As you just described (refer to pain points from previous slide), you are living in this world and feeling the pressure every day.
Pradeep Sindhu founded Customer 17 years ago on the belief that we should solve technology problems that matter most to our customers and that make a difference in the world. He recognized the importance of the network and the impact it would have on our world.
Our mission is simple, but powerful; to connect everything and empower everyone.
In today’s connected world, this mission is more relevant than ever.
Here at Customer we are focused on helping alleviate those pain points through our portfolio of high performance networking products.
[T] And we do this by listening to our customers and helping them address their challenges and capitalize on their opportunities.