The document discusses the AWS Shared Responsibility Model for security, emphasizing the division of responsibilities between AWS and customers regarding cloud security. It highlights AWS’s role in managing physical infrastructure and security tools, while customers are responsible for securing their software, data, and access. Best practices for security, including the use of IAM, encryption, and DDoS prevention techniques, are also outlined to ensure applications remain secure in the cloud environment.

1. AWS Shared Responsibility Model for
Security
Akshay Mathur
@akshaymathu of @appcito

2. Let’s Know Each Other
• Do you work with AWS?
• Do you manage applications?
• What are your goals while managing application?
• Happy Users, Happy You (DevOps), Happy Servers
2@akshaymathu

3. Akshay Mathur
• 16+ years in IT industry
• Currently Product Manager at Appcito
• Mostly worked with Startups
• From Conceptualization to Stabilization
• At different functions i.e. development, testing, release, marketing, devops
• With multiple technologies
• Founding Team Member of
• ShopSocially (Enabling “social” for retailers)
• AirTight Neworks (Global leader of WIPS)
@akshaymathu 3

4. Ground Rules
• Tweet now: #AWS @akshaymathu @appcito @AWSStartups
• Disturb Everyone later
• Not by phone rings
• Not by local talks
• By more information
@akshaymathu 4

5. When an Application is Secure
• Controlled Access to Application
• Legitimate users are able to use the
application
• Illegitimate users are not able to use
the application
• No disruption of the service
• Resilient infrastructure
• Prevention from attacks
• Secure Data
• Secure communication
• Secure storage
@akshaymathu 5

6. Cloud Computing Landscape
@akshaymathu 6

7. Shared Responsibility of Security in Cloud
@akshaymathu 7
Don’t worry! AWS is there We need to take care of this
Not to worry! AWS is providing tools

8. Share Responsibility of Security in Cloud
@akshaymathu 8
Don’t worry! AWS is there
Understand the worries and
manage with the help of
partners
Not to worry! AWS is
providing tools

9. Don’t Worry!
AWS is There 

10. Security ‘of’ Cloud
@akshaymathu 10
Don’t worry! AWS is there

11. AWS Global Infrastructure
@akshaymathu 11

12. What AWS takes care
• AWS manages the security of the following assets:
• Global facilities (regions, availability zones, edge locations)
• Access to data centres
• Physical security of hardware (compute and storage)
• Network infrastructure
• Attacks at layer 2
• Virtualization infrastructure
@akshaymathu 12

13. @akshaymathu 13

14. AWS Certifications
@akshaymathu 14

15. @akshaymathu 15

16. Not to Worry!
AWS is Providing Tools 

17. Security ‘in’ Cloud with AWS Help
@akshaymathu 17
Use tools provided by AWS
to takes care of this

18. What AWS provides
• Tools
• IP firewall (Security groups)
• Subnet management (Virtual Private Cloud)
• Access to virtual resources (Identity and Access Management)
• Elastic infrastructure (Auto Scale Groups)
• Resources
• So many best practices
• AWS partner network
@akshaymathu 18

19. VPC
@akshaymathu 19

20. Security Groups
• Security groups are like IP firewall
• Configure and attach proper security
group at every level (VPC, Subnet,
Instance etc.)
• Create both inbound as outbound
rules
• Close all not-in-use ports
• Use Bastion Host for managing
infrastructure
@akshaymathu 20

21. IAM
@akshaymathu 21

22. Top 10 AWS Security Best Practices
• Disable root API access key and secret key
• Enable MFA tokens everywhere
• Reduce number of IAM users with Admin rights
• Use Roles for EC2
• Least privilege: limit what IAM entities can do with
strong/explicit policies
• Rotate all the keys regularly
• Use AWS Key Management System and store keys in CloudHSM
• Use IAM roles with STS Assume Role where possible
• Use Auto Scaling to dampen DDoS effects
• Do not allow 0.0.0.0/0 in any EC2/ELB security group unless
you mean it
• Watch world-readable/listable S3 bucket policies
@akshaymathu 22

23. Think before you Do
• Do not share access and secret keys
with anyone
• Watch if the access credentials are
part of the code you are sharing
@akshaymathu 23

24. AWS Shared Responsibility Model
@akshaymathu 24

25. Understand & Offload the
Worries!
AWS has Great Partners 

26. Share Responsibility of Security in Cloud
@akshaymathu 26
Understand the worries and
manage with the help of
partners

27. Our Responsibility in AWS
• Customer are responsible for the security of the following assets:
• Software
• Operating systems
• Applications (servers, frameworks, tools)
• Data and Access
• Data (in transit as well as at rest)
• Credentials
• Policies and configuration
• Application layer attacks
• OWASP top 10 (XSS, SQL injection etc.)
• DoS and DDoS
• Malware
• BOTs and BOTNets
@akshaymathu 27

28. Securing Software
• Start with known good base AMI
• Pick LTS OS versions
• Select a reliable provider
• Pay attention to the software you install
• Web/App Servers
• Runtime environments
• Libraries
• Avoid installing development environment
• Apply patches regularly
• Write good code
• Do not introduce vulnerability
• Scan and Fix regularly
@akshaymathu 28

29. Securing Data and Policies
• Data in transit
• Implement SSL for all communication
• Over the internet
• Within AWS network
• Implement access policies
• For users
• For applications
• For resources
• Data at rest
• Store encrypted data everywhere
• S3
• EBS
@akshaymathu 29

30. Avoiding BOT Traffic
• Traffic from bad BOTs is about 30%
• Amounts to 30% wastage of server
resources
• Various fingerprinting techniques
are there for identifying the BOTs
• IP reputation
• UA analysis
• Pattern analysis
• JS insertion
• Advance algorithms
@akshaymathu 30

31. Preventing Data Theft
• Typical ways are:
• SQL/object injection
• Cross Site Scripting (XSS)
• File include
• Malware inclusion
• Exploiting vulnerabilities of coding, framework,
language, platform
• Scan the deployment regularly
• Fix any vulnerability by applying patches
• Use elastic Web Application Firewall (WAF)
@akshaymathu 31

32. Preventing DDoS Attack
• Volumetric attack
• Many clients make connections with
server
• Clients send huge traffic to the server
• Traffic is typically bogus
• Prevention
• Rapidly increase scale to consume
connections/traffic
• Rate limit connections/requests
• Delay/Deny bogus traffic
• Blacklist BAD clients
• Protocol exploits
• Attacker crafts traffic knowing the
timeouts and limits of protocol
• Slow moving bogus traffic hogs
resources of server
• Prevention
• Setup policy to apply aggressive limits
and timeouts in case of heavy load
• Terminate connection when unusual
behavior is observed
• Blacklist BAD client
@akshaymathu 32

33. @akshaymathu 33

34. 34@akshaymathu

35. AWS Certifications
@akshaymathu 35

36. Application Compliance in AWS
@akshaymathu 36

37. Application Front-End Architecture
CDN
Custom Scripts, Rules, Alert Management Aggregation across instances
• Spaghetti of point solutions
• Multiple points of failure, redundancy difficult to setup
• Not elastic and cloud native
@akshaymathu 37

38. Application Front-End Architecture with CAFE
CDN
• All services for application under one consolidated product
• Easy Activation of capabilities closer to application
• Application policy is coordinated across services and policy enforced
@akshaymathu 38
Availability Security Performance Continuous
Deployment
Appcito Cloud Application Front-End (CAFE)

39. Cloud Application Front End
(CAFE)
Taking Cloud Applications from Good to Great

40. Appcito CAFE Service
Insights &
Analytics
Content
Optimization
Application
Security & DDoS
Prevention
Unified Functionality Available As
SaaS Delivery
Simple Activation
No Code Change
For
Dev /Ops
Cloud-agnostic
App Owner
Elastic
Continuous
Delivery
Availability &
Elasticity

41. Typical Deployment
Customer’s Cloud
Customer’s
End Users
app
server
app
server
Load
Balancer
app
server
DNS
Network Subnet
Availability Zone

42. Deployment with CAFE
Customer’s Cloud
Customer’s
End Users
app
server
app
server
Load
Balancer
app
server
Appcito Cloud
CAFE Barista
Management, Control, Analytics
DNS
CAFE
PEP
Network Subnet
Availability Zone

43. Purpose-Built Cloud Native Architecture
• Scalable architecture decouples control plane
(BARISTA) and data plane (PEP)
• BARISTA provides centralized policy control,
visibility and analytics.
• PEP (Policy Execution Proxy) provides full
proxy services for applications
• Traffic Management / Load balancing
• Application Visibility & Analytics
• Application Security
• System is DevOps Friendly
• API Driven & Programmable
• Integrates with DevOps tools & Processes
@akshaymathu 43

44. CAFE Configuration Model
• Think Out of the box (literally)
• Think in terms of
• Applications
• Traffic flow
• Request patterns
• Forget about
• Box provisioning
• Box configuration
• Networking flow
• L2/L3 access control
@akshaymathu 44

45. Application-Level Security
Web Application
Firewall (WAF)
• Protects against common attack vectors
• SQL Injection
• Cross-Site Scripting (XSS)
• Local and Remote File Includes
• One-click protection for popular web applications
• WordPress
• Joomla
• Drupal
DDoS & BOT Mitigation
• Maximize availability, even during attacks
• Minimize impact on cloud computing resources
• Analyze attack events with comprehensive metrics
• osCommerce
• vBulletin
• Microsoft SharePoint

46. App & Traffic
Metrics
Appcito CAFE Service Capabilities
46
Availability Performance Security DevOps
Advanced Load
Balancing
Content
Switching
Application
Fluency
Elastic & Self-
Scaling
Continuous
Deployment
Request
Mirroring
Request Replay
Programmable
Policies
Per Application
Control
Front-End
Optimization
Optimization for
client
Caching &
compression
Predictive caching
Application &
Server offloading
Application
Firewall
Elastic SSL
Anomaly
Detection
DDoS
BOT Protection
Trends &
Correlations
Anomalies
Detection
Policy
Recommendation
Analytics & Insights

47. Thanks
@akshaymathu 47
@akshaymathu
akshay@appcito.com