Day kicked off with presentation from Cloud Compliance Vendor Telos, their Solution Xacta
Again, forgive brevity, partial sentences; these are literally, my notes transcribed from as fast as I could write in my notebook.
Good stuff started when Nathan McGuirt, Public Sector Manager, AWS, took the stage for AWS Network Security; and this is where my notes begin:
Nathan opens: Almost everything is an API and can be automated. APIs automated network discovery ( things network tools used to do )
AWS Network configs are centralized. VPC is NOT a vlan or a VRF! Pressures to migrate to large, shared networks are all but gone.
Micro-segmentation allows for smaller networks; are more granular in function, reduce Application risk via isolation, reduce (effect of) deployment risks of new systems
Security Groups (SG) have become the most important piece of Security in AWS; Security groups are essentially stateful Firewalls that can be deployed per-instance / per VPC.
Two EC2 instances in the same Security Group don’t communicate by default. Security Groups are flexible and rules can be set to allow another Security Group as the source of the traffic.
The idea is Role Based Security group / permissions to communicate based on Role. Security Group traffic shows up in VPC flow logs in a netflow format.
VPC subnet ACL’s ( access control lists ) are secondary layer of protection. ACLS are NOT stateful; and ephemeral ports have to be allowed on return traffic. ACLs are better suited for solving broad problems; communication between VPCs.
Route tables are now thought of as another Security mechanism for isolation and to control permissions; route tables create an extra set of protections.
Stop thinking about filtering at layer 3,4 and focus on filtering application:
Ingress filtering tech: Reverse Proxy, (Elastic Load Balancer), Application Load balance with WAF, CloudFront CDN with WAF
Egress filtering: Proxies / NAT
Moving outside VPC – VPC Peering – inside inside routes, Virtual Private Gateway to connect to on-prem legacy VPN hardware, AWS Direct Connect( AWS on prem fiber )
No transitive VPC peering, no A – > B -> C
– some work-arounds, using proxies/ virtual router AMIs and routing to them instead of VPC ( does not scale large )
– Nathan talked about a Management Services VPC that has all needed services in it( auth, monitoring, etc. ) and connecting all VPCS to that.
VPC design; plan early, plan carefully, think about subnets and how you want to scale VPC before you implement it; since subnets cannot be removed from VPC once built.
Coud Formation and Change Control. New AWS feature called ‘ Change Sets’ allow you to stage your Cloud formation builds and assign different permissions to developers, approversand implementer.
Talked about how powerful AWS config https://aws.amazon.com/config/ is; scans envrinments, object history, change logs, given snapshots of whole AWS environment .
Logging VPC flow logs / netflows for all things – goes to CloudWatch for every instance in the VPC. Rather than watching the noisy edge; Combine tight Security Groups with VPC flow logs within / and between other VPCs and look at what is getting denied – people trying to move sideways. Watch for config changes that impair you ability to see config changes. ( e.g.., disabling of Cloud Trail ) – Automated remediation is possible thru APIs. Watch for dis-allowed configurations
Next up was Jim Jennis AWS Solutions Architect;
Jim has a solid background – worked for US Coast Guard.
Jim: Automate Deploy Monitor in Security SDLC, build in Security and verify before deployment
Using Cloud Formation to describe AWS resources, JSON templates, key value pairs
How Security in the Cloud is different:
– Everything is an API Call
– Security Infrastructure should be Cloud Aware
– Security Features as APIs
– Automate Everything
Use Federation to leverage AD accounts of existing staff to get access to AWS and lock down tasks to their specific tasks.
[ Trust required with AD/ required ]
Preso Back to Tim and Nathan McGuirk together
AWS cli matches the one in the API – live demo AWS command line ( learning AWS CLI would be a good way into learning API )
Nathan using AWS cli to:
find EBS volumes that are unencrypted
find Security Groups / with ssh allowed
give a list of instances attached to groups found from last command
( Tim said this could be used to find IAM groups with resource of * )
Tim: this demo is the base to automation to find things that are not supposed to be there; run them multiple times a day
to locate things that are happening out of scope in our environment;
USE accounts and VPCs to limit last blast radius of compromise
– Accounts are inherently isolated from one another provide isolation of both access and visibility for deployed resources
– compromise of one account limits impact
Place Hardened templates in Service catalog; and employees can only select your hardened templates / AMIs when spinning up new instances
My Thoughts: Security people that want to protect AWS need to learn to understand APIs, code to fully leverage automation, and use the amazon cli and benefit. Queries are powerful can be leveraged to tell you very specific things in an environment; I’ve seen things today that make the old network tools I used to use look like Ford model-T. Security Professionals and Network need to adapt and become application-centric thinkers. AWS has incredible built in tools to ensure proper secure design from the creation of hardened AMI / CF templates, to be able to lock down those the deployment of pre-approved instances. Security Groups and IAM make it to where you can get very granular on the permission level; as Even applications can be granted permissions through access roles.
When thinking about everything I have done in the last 20 years as a Network Engineer / Sys Admin / Security Engineer; what I experienced the last two days really reminded me the scene in ‘Dr Strange’ movie; where Strange shows up at Kamar-Taj temple – and begins his true teaching. The ancient one says tell him that what he had learned before got him far in life; but he needed to embrace a whole new and completely different way of thinking.
For me, I am not as reluctant as Strange was, but the idea of embracing the concept that an entire infrastructure is just CODE; servers, routers, firewalls are now just coded objects and APIs are the “neurons” that make it all work is just as impactful.
I am grateful to AWS Engineers and the Vendors for coming to Denver!