The cloud enables users to run workloads in a more secure fashion than what typically can be done in a traditional datacenter. However, many customers are still not sure how to actually harden their AWS accounts and resources and make sure compliance is being enforced. When large customers have multiple accounts, ensuring consistency around governance can also be of concern. In this session we will review how to use automation, tools and techniques to harden and audit your AWS accounts and also how to leverage AWS Organizations to ensure compliance in your enterprise.
Geordie Anderson, Security Specialist Solutions Architect, Amazon Web Services
Sean Donaghy, Senior Cyber Security Advisor, Canadian Centre for Cyber Security, Communications Security Establishment, Government of Canada
Michael Davie, Security Engineer, Canadian Centre for Cyber Security, Communications Security Establishment, Government of Canada
59. CERRID #######
PAGE 59
UNCLASSIFIED
What is the Canadian Centre for Cyber Security?
The Cyber Centre is the Government of Canada’s single unified source of expert advice, guidance,
services and support on cyber security for government, critical infrastructure owners and operations, the
private sector and the Canadian public.
3
60. CERRID #######
PAGE 60
UNCLASSIFIED
Pillars of CCCS Cloud Security Program
Advice and Guidance
• Advice &
Guidance on the
secure use of
cloud
• Examples of
secure
Infrastructure as
Code
• Consultation with
CSP clients
Assessment
• Vendor
Engagement
• Cloud Service
Provider Security
Assessment
• Supply Chain
Integrity (SCI)
• Residual Risks
Cyber Defence
• Develop
capabilities for GC
workloads in
cloud
• Leverage existing
investment in
analytics and
cyber defence
4
61. CERRID #######
PAGE 61
UNCLASSIFIED
CSP Assessment Program
Intended to assess each enterprise cloud service provider and their ability
to handle Government of Canada information:
● Unclassified to Protected A Data.
● Protected B Data.
Program utilizes:
● An Onboarding process for interested CSPs
● Tailored Cloud Security Controls Profiles for Low and Moderate levels of information
sensitivity - can be applied by both government and industry.
● A Cloud Assessment Framework/Methodology (ITSM.50.100)
Completed Assessments provide information to help departments validate
a CSP’s ability to meet the security control profile for GC information
security requirements as they procure Public cloud services.
5
62. CERRID #######
PAGE 62
UNCLASSIFIED
Cloud Advice and Guidance Publications
The CCCS will be publishing various Cloud Security Publications:
● CSP Assessment Process
● Cloud IT Risk Management Process
● Cloud Security Profiles
● Cloud Defence in Depth
● Cloud Encryption Strategies
● Monitoring of Cloud Services
● Business Continuity Planning
● Access Control (Public, Private/Community and Hybrid Cloud)
● Secure Design/Implementation/Hardening of client IaaS/PaaS
Keep an eye on our Publications page: https://www.cyber.gc.ca/en/publications
6
65. CERRID #######
PAGE 65
UNCLASSIFIED
CSE-CIC-IDS2018 Dataset
Collaborative effort between CSE, UNB, and AWS
Communications Security Establishment
● Noted lack of high-quality, public data for cybersecurity tests (still a lot of KDD 1999…)
● Drafted problem book A problem that we would like solved
● Contracted work to UNB
Canadian Institute for Cybersecurity (University of New Brunswick)
● Previous work in dataset generation (2012, 2017)
● Generated new dataset to CSE requirements
● 500 users, realistic attacks, labelled data, feature extraction
Amazon Web Services
● Provided cloud infrastructure for virtual environment
● $80k USD academic grant of AWS credit
● Free public hosting on Open Data portal
9
66. CERRID #######
PAGE 66
UNCLASSIFIED
CSE-CIC-IDS2018 Dataset
AWS Open Data Portal
https://registry.opendata.aws/cse-cic-ids2018/
Documentation
https://www.unb.ca/cic/datasets/ids-2018.html
ARN
arn:aws:s3:::cse-cic-ids2018
10
67. CERRID #######
PAGE 67
UNCLASSIFIED
Questions/More info?
Get in touch with our Contact Centre
Communiquez avec notre centre d’appel
1-833-CYBER-88 or/ou 613-949-7048
contact@cyber.gc.ca
Or check out our web site:
www.cyber.gc.ca
11
Intro
We will also have Sean Donaghy and Michael Davie
From the Canadian Centre for Cyber Security
who will present as well.
You are in the technical track.
Just want to make sure people are in the right room.
We are going to talk about awesome stuff like this.
The Management track and the Spotlight track are in other rooms.
This is an exploded view of a Nikon F3P Camera.
(CC Image) - https://www.japancamerahunter.com/2014/11/nikon-f3-p-parts-diagram/
Let’s cover a few of the AWS security basics first.
(CC image) - https://www.flickr.com/photos/vanf/5210360116
No AWS security presentation would be complete without showing the Shared Responsibility Model.
Line is the hypervisor.
Customers can choose their OS.
AWS provides the tools for customers to secure their workloads.
The line can move up.
Examples:
- Amazon Relational Database Service
- AWS Elastic Beanstalk
Examples:
- Simple Storage Service (S3).
- Lambda – customer is responsible for code sanitization.
GUI, REST API, Command Line Interface (CLI), SDK.
Stored in Simple Storage Service (S3).
No Agents. Just Turn it on.
Like Netflow.
Stored in S3.
Let’s start looking at some automation.
Center for Internet Security.
Open source package available on AWS labs.
Does a CIS Benchmark check against a specific AWS account.
Straightforward to run, command line or in a Lambda function.
Reporting options based on use case.
This is an HTML document.
Green light / red light type dashboard that could be provided to leadership.
Raw JSON format.
Could be used in a Lambda function for some automated remediation.
Or sent to a downstream SIEM server for processing.
Or a filter of only those that failed.
Can be customized depending on the needs of the downstream processor.
Everyone should be able to download the slides after.
This picture is a training exercise that the US Navy performs on ships.
They run a competition to test who can implement the most effective “soft patch”.
Using rope, gum, band-aids, and duct tape.
So let’s talk about how to deal with automated patching at scale.
(CC Image) - https://www.defense.gov/observe/photo-gallery/igphoto/2002039597/
No charge for AWS Systems Manager, you only pay for the resources you manage (eg. EC2 instances).
AWS Systems Manager works via a lightweight agent that runs on the EC2 instances, across diverse OSes.
First step is to define a patch baseline.
This can align to whatever your organization’s security posture is.
This could be everything patched up to the moment, or a specific package at a specific version.
You get a list of hosts and whether they are compliant or non-compliant to the baseline.
This is how you can perform automated patching.
Now let’s look at Run Command.
Subtle feature.
But very powerful from a security perspective.
For an analogy here, I will take you back to the 90s.
There was a movie with some dinosaurs, in some kind of park.
It was a Jurassic type of park.
(CC Image) - https://www.livescience.com/16521-image-gallery-tyrannosaurus-rex-dinosaurs.html
One of the characters in the movie basically gives a perfect example of an insider threat.
He shows how a disgruntled employee can execute some malicious code.
And then cover his tracks.
In the movie, he types a command called “White rabbit”.
(CC Image) - https://www.maxpixel.net/Freedom-White-Rabbit-Bunny-Grass-Animal-Cute-3267568
Then suddenly every gate in the park opens up and chaos ensues.
Velociraptors are terrorizing people everywhere.
(CC Image) - https://pxhere.com/en/photo/851957
This later leads to workplace safety posters like this.
Likely pinned up in the lunchroom.
(CC Image) - https://www.amazon.com/Raptor-Dinosaur-Velociraptor-Vinyl-Sticker/dp/B073ZGVTWR
Back to the real world.
Insider threat can be a problem when you have no view into what people are doing at the operating system level.
It’s a challenge to track OS commands issued, across various OSes.
Need to think about moving away from giving developers and staff direct OS access for high security environments.
If you are a security practitioner, this should interest you.
Because everything is API-based, all OS commands issued get logged by CloudTrail.
Who/what/when/from where/what was the response.
Across diverse OSes.
Now let’s take this further.
An even better option is to store CloudTrail logs in a separate central security account, limited to the security team.
Developers and administrators cannot access or alter the CloudTrail logs.
Session Manager
Session Manager
Bash shell or PowerShell
All commands logged to CloudTrail.
Access control via IAM.
This is a GuardDuty kill chain.
First create the CloudWatch rule that defines the event source.
GuardDuty detections in this case.
Then build a Lambda responder.
This is a simple 8 line Lambda function.
Drop in a specific action.
Back to the GuardDuty kill chain.
In this case, we could shut down the compromised instance.
Or disconnect it’s Elastic Network Interface.
Back in the on-premises world, the BC-era (‘before cloud’) --> host compromised --> pull RJ-45.
Move server to isolated lab.
Even use CloudFormation for tools servers.
Cloud is API-based --> Automated incident response.
Let’s talk about networking.
I’m sure we’ve all seen a data center like this.
(CC Image) - https://peterskastner.wordpress.com/2011/02/23/cisco-the-lion-king-fights-for-data-center-fabric-leadership/
Or like this. Check out the mat over the cables.
In a traditional data center, visibility and accountability can be problematic.
There are always some unknown servers in the corner
Or network cables going somewhere unknown.
(CC Image) - https://dcbureau.files.wordpress.com/2008/08/cable-mess.jpg
VPC Flow Logs give visibility and traceability.
Lambda doesn’t have to do just one thing.
If you use a ticketing service that supports and API, have Lambda open a ticket that indicates:
- What the actor was doing
- What the resource was
- What the automated action was
- Whether the action was successful or not
All documented inside the ticket.
Threat intel feeds – could be 3rd party or based on your telemetry from security edge monitoring.
Possible to do directly from S3 to Lambda, but showing SNS for a reason, which you’ll see on the next slide.
Option would be pushing IP blacklist ranges to a WAF.
Solution can be used generically to push from a central account to multiple member accounts.
How do we make sure that people only do things that we want them to do?
(CC Image) - https://commons.wikimedia.org/wiki/File:Denver_boot.jpg
AWS Config also supports centralized multi-account management.
You can have an enterprise-wide view of your compliance status.
Even better, how can we automate remediation based on what AWS Config rules discover?
Lets talk about access control.
(CC image) - https://commons.wikimedia.org/wiki/File:Nuclear_Plant_Security-_Access_Control_Gates_(9680484758).jpg
IAM Access Advisor shows
- Service permissions granted to users and roles
- When those services were last accessed
Athena is a serverless SQL service.
Solutions from Netflix:
Aardvark - PhantomJS to login to the console and scrape Access Advisor information.
Database --> REST-based API.
Repokid (repossess), uses the data from Aardvark to analyze operations vs permissions needed over time.
It will then repossess permissions and bring roles down to least privilege.
Monitoring | testing | tuning – can significantly improve security posture if used carefully.
AWS has a global network of regions.
Your workloads can run anywhere.
A common guardrail (especially for Protected B) would be to limit workloads only to run in Canada.
How do we do this?
IAM policy. Wall of text.
Lets talk about when you have to manage a whole bunch of AWS accounts.
(CC Image) - https://www.flickr.com/photos/aquamech-utah/24778841180
SCPs – blacklist or whitelist at the service level
SCPs cannot be overridden by the local account
Analogy – similar to the concept in Windows of the Domain Admin vs Local Admin, and Group Policy Objects
No cost to the Landing Zone Solution itself.
Pay for the resources you launch and use.
Member accounts are tied in to the management structure above.
Centralized logging, security access, and authentication.
Summary --> ideas covered. Repeated theme = automation.
People --> mistakes | good intentions | credentials-locations-mfa | repeatability-high stress
Leverage automation as much as possible.
Automation --> waking up | sleep-eat-coffee
Leverage automation --> things get done consistently.
One final thought --> thinking more broadly beyond just the security benefits of automation.
By-product of automation --> becomes an Employee Retention Investment.
Think --> No longer doing --> undifferentiated heavy lifting | repetitive tasks
Opportunity to --> learn new things | innovate | experiment.
Hopefully means --> work becomes more interesting | varied | meaningful.