AWS Workshop Automating Security in the Cloud in Denver: Day 1

When I found out AWS was going to be doing a two day Security class in my home town at the end of April, I took no chances and simply requested two days PTO so I could go to this event.

Day one CORE content was taught by Tim Sandage , Senior Security Partner Strategist, AWS. Tim knows his world very well and relayed the material in a clear and concise way, keeping the audience engaged at all times.

There were a slew of Cloud Security Vendors there as well, my favorite vendor presentation was by Aaron Newman, CEO Cloudcheckr. Aaron is a very passionate and dynamic speaker – and the Cloudcheckr Product is gives solid, Security centric view of your AWS assets.

Some of the ideas presented below carry over from standard on-prem Infrastructure Security, such as Principle of Least Privilege; and some are unique to Cloud – CloudFormation Templates.

Below are my notes, transposed here from furiously fast handwritten catch during the event. Please excuse any brevity; partial sentences, etc.

Tim Sandage Notes: DevOps is Rising. Shortage of individuals to maintain Security.  DevOps needs Security engrained into their process. Focus on Continious Risk Treatments (CRT). Need to bring Security Risk treatment into DevOps Lifecycle. Technology drives governance. Governance is shared between AWS and end customer. Security Automation is key to Successful Governance.  API is the common language through which Policy can be automated.

AWS is a SHARED Security model. Security by Design ( SbD ) is an AWS assurance approach that formalizes account design and automates control and auditing. Cloud Templates / Cloud formation is key.

Continuos monitoring is not enough, it does not catch bad guys; we need to create a workflow to help with tech governance.

Security is top priority at AWS. AWS has over 1800 accreditation/ certifications geared toward being a compliant provider for its customers.

When moving to the Cloud, consider the boundary extensions and how they can affect compliance. Before moving to the Cloud, first look at dependencies and traffic flows, to ensure you are not moving something into the Cloud that is not compliant.

[SHORT BREAK]  VENDOR PRESO Okta Did presentation on Securing Cloud. Tools for Cloud Compliance.

Back to Tim: Talked about a slide that showed Rationalizing Security Requirements / Standards; a framework for building internal polices based on Industry standards, Common Practices, Laws and Requirements. Talked on Share Responsibility Control Models. 1. Inherited Control, Hybrid Control, Shared Control and Customer Control.

Tim: Talked about Defining Data Protection; laid out Problem statements  1. Most orgs don’t have Data Classification scheme, 2 most orgs don’t have Authoritative Source for Data, most orgs don’t have Data LifeCycle Policy.

Topic change; Breaches: Breaches that involve actors obtaining Data from stolen laptop / or cell phone is because the world has moved to a mobile workforce and employer has not caught up with that; e.g., still storing data on employee devices and not in central location, protected by predefined automated policies. Nothing should be on local laptop or phone.

Make sure least privilege is always used – No human should ever have admin ( at least for very long); instead, user gets promoted to admin role; and then STS token expries and Role goes away.

Topic change Assets: Everything in AWS is an asset; instance IDs are unique , Security Group IDs are unique. Customers choose to track and decide how these assets are protected. ID’s by Amazon Resource Name; ( ARN )  Enable a Data Protection Architecture – a Methodology to lock down assets launched in AWS; using Cloud Formation templates with pre-defined polices. [ no EC2 launched in root, no S3 buckets with World read ]

CLOUD SECURITY TIP: CloudTrail needs to be enabled for all Regions; to mitigate against internal people spinning up instances in regions you don’t operate in; mitigate against external threats; expose any badness in your account.  Show Activity in a space in which you do not operate.

CLOUD SECURITY TIP: AWS root account – Delete Admin ROOT API Key. Never use root to do any task. No repudiation in logging  – Instead,  log in, create two admin accounts, turn on Cloud trail and MFA 

AWS Security Architecture Recipes using CIS Benchmarks – Tactical Control rules for hardening.  CIs Benchmarks have been “templatized” for CloudFormation  current on GITHUB  –

Use Tag in assets – mapping correlation for proof of documentation for which CIS template was used to meet compliance.

[ My thoughts on day one ] This is HUGE! Basically, AWS assets, EC2 instances, S3 buckets, RDS instances can all be deployed with these CIS based templates; ensuring that all assets have the same Security controls/permissions on them each time they are deployed; and then mapped back to an audit control with the naming in the TAG. Basically, hand the auditor a paper and say “bye bye now” This compliments custom, secure AMI ( Amazon Machine instances ) that are deployed from the original AMI that was built.

Great Security tips included and woven into each presentation. My notes did not capture all of this; but I did the best to get the main points – I have things in my notebook that may appear in later blogs – Also, Amazon does a fantastic job of documenting this

https://aws.amazon.com/documentation/

See you all tomorrow at Day2!

 

This entry was posted in Cloud Security. Bookmark the permalink.

Leave a comment