AWS Summit 2017 – Well-Architected for Security: Advanced Session

Well-Architected for Security: Advanced Session : Level 300

Ankush Chowdhary, Head of Security, Risk and Compliance, Professional Services, Amazon Web Services

** Note: These are notes taken from various sessions and the keynote of the 2017 AWS Public Sector Summit held in Canberra, Australia.  The information might be slightly unstructured, and the photos might be a bit raw.

Note: The level 300 sessions were being squashed into short sessions, as a consequence the presenters were really under some pressure to zoom through the content.  As a result, I found it difficult to make notes and listen at the same time in an effective manner.

Well Architected for Security

Well Architected for Security_15

Design principles

  *   Security at all layers
  *   Visibility and traceability
  *   Least privilege (need/time)
  *   Data centric (security stays with data)
  *   Security by design (automation, policy)

Well Architected for Security_2
Identify security boundaries
InfoSec controls defined
System hygiene (patching, management)

Well Architected for Security_20
Weight or latency based routing
CloudFront implements geo rules
CDN + WAF helps traffic analysis
DDoS Shield service (pro service)
Scale out triggers on DDoS.  Evaluate legitimate users,
Web Application Security
Cloud formation template – builds WAF profile (no code)
OWASP Top 20
  *   insufficient attack protection
  *   WAF can cater for this
  *   Can identify vulnerabilities
  *   Buy time to develop patch
  *   WAF can implement temp patch (web ACLs) if you know the attack vector
Data Centric

Well Architected for Security_3Well Architected for Security_5
Classification of data (at creation)

Well Architected for Security_7
Hybrid data storage
Server side encryption
Can be policy driven
Can use 2FA/MFA device
Integrity must be maintained
Availability must stay consistent
Secure at rest

Well Architected for Security_31
Use policies to enforce security

Well Architected for Security_12
Don’t use master keys
Enforce by policy
KMS integrated

Well Architected for Security_8
Built into the platform.  Key management by platform.
Usually to NLB

Well Architected for Security_17

Well Architected for Security_26
Traditional model 🙂

Well Architected for Security_6
Allow pass through

Well Architected for Security_4
CloudFront – BYO domain & cert
SNI is cheaper
Old software doesn’t support it
Key management (no AWS access)

Well Architected for Security_10
New v2
Used for document signing, Etc

Well Architected for Security_13
No upfront payment
Built in HA
Console access

Well Architected for Security_33

Well Architected for Security_24
SSL offload, CA, Oracle

Well Architected for Security_29
EBS volumes encrypted
Requires 3rd party software
Complex.  Requires Classic

Well Architected for Security_19
DB encryption


Well Architected for Security_28
Similar to OAuth

Well Architected for Security_25
Policy, policy, policy
Resource tagging
Force tags to regions

Well Architected for Security_14
Can be used in security automation
Function based too

Automating compliance

Well Architected for Security_23

Well Architected for Security_32
One option…   use resource relationships
Check status of compliance
Use lambda:

Well Architected for Security_11

Well Architected for Security_27

Well Architected for Security_18


Config rules trigger on change
Lambda can automatically respond

Well Architected for Security_1
New: from management console
Rule repository available

Well Architected for Security_9

Automate incident response

Well Architected for Security

Well Architected for Security_22
For analysis

Well Architected for Security_30
Then bring up forensic instance

Well Architected for Security_16
Open source equivalent
Whoa; that was fast.  We’re over now.

Leave a comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.