ISSA Thought Leadership Webinar

Eliminating Security Blind Spots in your AWS Environments

September 19, 2018

Eliminating Security Blind Spots in your AWS Environments

Today’s web conference is generously sponsored by:

CloudPassagehttps://www.cloudpassage.com/

Eliminating Security Blind Spots in your AWS Environments

Moderator

Mikhael is Director of Information Security & Risk Management for Farmers Insurance. He is also an Advisor for Safe-T Executive Advisory Committee. In the past decade he has taken on number of information security roles including engineering, teaching, writing, research and management. His sector experience includes insurance, defense, healthcare, nonprofit/education and technology/Internet, seeing first-hand the variance in information security culture and program maturity. Felker received his M.S. in information security policy and management from Carnegie Mellon University and B.S. in computer science from UCLA. He has over 50+ publications and has been a speaker for RSAC, CSA, ISSA, ISACA, ISC2 and OWASP events.

Mikhael Felker, Director Information Security & Risk Management, Farmers Insurance

Eliminating Security Blind Spots in your AWS Environments

Speaker

Mr. Grohmann (CISSP, CISA, CISM and CIPT) is founder of Sicher Consulting and and ISSA Fellow. He is the recipient of ISSA ‘Honor Roll’ and was president of the NoVa chapter for three years, winning Chapter of Year during that time. He is a graduate of the FBI’s Citizens’ Academy and served on the board of directors for the Washington DC chapter of InfraGard for four years. Currently Mr. Grohmann serves on the board directors of Northern Virginia Community College’s Workforce Development taskforce, NOVA Cybersecurity Advisory Board and is an mentor at MACH 37, the Virginia cyber security accelerator. He also sits on the IT sector coordinating council (IT-SCC)

Alex Grohmann, CISSP, CISA, CISM, CIPT

Moving to the Cloud/AWS

➢Moving to the cloud is often a purely business decision❑ Less ownership of resources

❑ Less technical staff

❑ Overall cost savings

❑ Etc.

➢ Therefore, business impacts/benefits are assessed heavily driven by the impact to the bottom financial line

➢ This is often a financial decision

Known Issues with Cloud

➢ Issues with moving to the cloud are well known and are nothing new. ❑ Data is everywhere

❑ Applications are everywhere

❑ Users access apps and data from everywhere

➢Has the company done enough to ensure they are ready for the technical, and specifically the security, related implications? At a very granular level

➢Has the company broken down the move at an operational level? (nuts and bolts)

Know Thy Data

➢At a tactical level, has enough homework been done to know exactly❑What data will be going to the cloud

❑Where all of the interfaces

❑When data will be undergoing changes such and being encrypted and decrypted

➢ Traditional data flows for internal systems have matured but flows associated with cloud go beyond simple

Planning for the “Uh-oh”

➢Have the business risks been fully identified, measured and addressed?

➢Have legal and regulatory considerations been identified and reviewed?

➢Has specialized data been given an extra level of scrutiny?

➢Have the business risks of an unforeseen/ unfavorable event been identified / quantified / qualified?

➢Have adequate mitigations been considered with implementation plans in the event of an “issue”

The Master Plan

➢Who is on point for the master plan for moving data to the cloud?

➢Who is driving the strategy about how it will happen?

➢Who is managing all of the very well known considerations such as legal and compliance issues?

These are all very, very basic considerations. However, companies still struggle with them.

The Security Considerations

➢ To reduce the security blind spots in an environment, the business aspects must be well known

➢ Compared to the business considerations, the security considerations could be considered easier

➢However, the business landscape must be accurately depicted in order to plan for an adequate strategy

Eliminating Security Blind Spots in your AWS Environments

Speaker

Edward Smith, Product Marketing Principal,CloudPassage

Edward Smith has spent the last 5 years in the security industry and has over 20 years experience helping enterprise companies maximize the value from their technology investments. He is currently Product Marketing Principal at CloudPassage and has previously held various positions as a Marketing Leader, Systems Engineer, Sales Engineer, Support Manager, and Trainer for companies like Tripwire, Dell, Adobe, and Gateway.

AWS Security Visibility

Data Center

Athena

RDS

S3

EC2

ECS

ECR Registry

Kinesis

Traditional App Environments

• Fewer, more homogenous components

• Data center & perimeter orientation

• Total ownership, visibility, control

• Hardware appliances

• Everything “behind the firewall”

• Rate of change relatively low

• Things happened on security’s terms

Modern App Environments

• Apps use more (and more varied) components

• Cloud orientation degrades perimeters

• Less ownership, visibility, control

• Virtual, abstract, dynamic environments

• Application components widely distributed

• DevOps / CICD = more and faster changes

• Development & ops teams very autonomous

#1 headache: infrastructure visibility

AWS security visibility

Amazon EC2 Elastic Load Balancing

Amazon CloudFront

AmazonS3

AmazonRDS

AmazonRoute 53

Amazon Redshift

AWSCloudFormation

AWSCloudTrail

AWSConfig

IAMAWS KMS

• What do I have?What public cloud services are we using?

• Is it secure?Are those services securely configured?

Multiple accounts multiply pain

Amazon EC2 Elastic Load Balancing

Amazon CloudFront

AmazonS3

AmazonRDS

AmazonRoute 53

Amazon Redshift

AWSCloudFormation

AWSCloudTrail

AWSConfig

IAMAWS KMS

Amazon EC2 Elastic Load Balancing

Amazon CloudFront

AmazonS3

AmazonRDS

AmazonRoute 53

Amazon Redshift

AWSCloudFormation

AWSCloudTrail

AWSConfig

IAMAWS KMS

Amazon EC2 Elastic Load Balancing

Amazon CloudFront

AmazonS3

AmazonRDS

AmazonRoute 53

Amazon Redshift

AWSCloudFormation

AWSCloudTrail

AWSConfig

IAMAWS KMS

Multiple accounts multiply pain…and need for automation

Solution considerations

Security Functions

• Maintain asset visibility

• Control access

• Secure configurations

• Manage vulnerabilities

• Protect content integrity

• Detect compromise

• Ingest & enrich events

• Monitor compliance

Form-Factor

• Bare-metal servers

• Virtual machines

• Containers

• Cloud instances - e.g. EC2

• “Extended” cloud services e.g. S3, Lambda, ECS, IAM

Deployment Model

• Traditional data center

• SDDC / private cloud

• Public cloud

• Hybrid cloud

• Multi-cloud

Watch out for these limitations…

➢Disjointed asset inventory, piecing data from multiple tools/UIs

➢ Too many alerts, too much noise, and not enough actionable info

➢Manual remediation process, limited integration, no DevOps automation support

➢Narrow and shallow coverage, coverage for data plane (“inside-out”) or control plane (“outside-in”) but not both

About CloudPassage

➢ Founded in 2010

➢ Inventor of the automated cloud security platform architecture

➢ Fortune 1000 enterprise customer base

➢Multiple industry awards

Docker Hosts

Docker API/Client

Halo Agents

Halo RegistryConnectors

Image Registries CICD Pipeline Automation

Halo Pipeline Connector

Halo Security Automation PlatformAdmin

PortalREST API Gateway

Containers

Halo Agents

Servers / VMs / Cloud Instances

Public IaaS Services

Halo IaaS Connector

Ecosystem Integrations

Workflow Automation

{…}

Free 15 day trial of Halo Cloud Secure

www.cloudpassage.com/freetrial

Halo Cloud Secure

Eliminating Security Blind Spots in your AWS Environments

Speaker

Dr. Matthew Hicks, DM, MBA, C|CISO , CISSP, CISM, PMP/RMP

Matthew has over 30 years of Cyber Security and Technology experience in Government, Health Care, Financial, and Transpiration industries. He has worked for Presidents Bush and Clinton as a member of the White House staff. Matthew has a Doctoral Degree in Management, a Master of Business Administration degree, and a Master of Science degree in management. He holds the C|CISO (EC-Council), CISSP, CISM, CRISC, PMP, and RMP certifications. He has in-depth experience in HIPAA, PCI, NIST, FISMA, FRA, COBIT, ITIL and GDPR standards. He is employed as a Senior Principal for Amtrak and is a member of the CISO Executive Forum and the ISSA CISO Advisory Council.

AWS API Keys

Topics

➢Questions.

➢Defining AWS API Keys.

➢ Risks of AWS API Keys.

➢ Best Practices.

➢ Final Thoughts.

Questions

➢What are AWS API Keys?❑ Keys to open AWS doors.❑ Keys to authenticate API calls.❑ Keys to authenticate AWS users.❑ I do not know.

➢ Should the Root userid be assigned AWS Keys?❑ True.❑ False.

➢What are the risks of API Keys?❑ Unauthorized access to data stores.❑ Unauthorized access to root.❑ Unauthorized access to users.❑ All of the above.

Questions

➢What are the best Practice for managing the keys?❑ Rotate keys on a schedule.

❑ Disable keys when no longer needed or compromised.

❑ Protect keys as sensitive data.

❑ None of the above.

Defining AWS API Keys

➢Access keys are used to digitally sign API calls made to AWS services.

➢ The secret key portion must be secured by the AWS account holder or the IAM user to whom they are assigned.

➢Users can have two sets of active access keys at any one time.

➢ Create access keys (which consist of an access key ID and secret access key) to use when you make programmatic calls to AWS using the command line interface (CLI), the AWS SDKs, or API calls.

Risks of AWS API Keys

➢ Access keys are the weakest link.❑ Found everywhere.❑ Github.❑ Internally accessible configuration files.❑ Baked into public binaries.❑ Stored on laptops under ~/.aws/credentials.❑ Dark Web.

➢ Keys can become stale or stagnant.❑ Employees leave company.❑ APIs not being used.❑ Many developers use AWS access keys that have not been

changed in months or years. ❑ Many organizations aren’t aware that their stagnant AWS

keys could be causing major vulnerabilities.

➢ Old or not used keys become a liability.

Risks of AWS API Keys➢ So why disable outdated or no longer used keys – WebSolr

Breach

https://www.itprotoday.com/cloud-data-center/second-aws-customer-breach-two-dayshttps://cyware.com/news/5-cases-of-cyber-extortion-that-show-us-the-threat-is-real-503aeb02

Risks of AWS API Keys

➢ So why disable outdated or no longer used keys - –WebSolr Breach.

➢ The company essentially set the stage for the breach by committing a two-pronged mistake:❑First, the old API key had been mislabeled, so it

appeared to have much weaker permissions than it actually did;

❑Second, the overly powerful key was committed to source code.

➢ The API key at the root of the breach was likely leaked through an insecure system of an employee that had access to the company's private GitHub repositories.

➢ The keys were created in 2006 and basically forgotten.

Risks of AWS API Keys➢ So why disable outdated or no longer used keys - Code

Spaces Breach.

➢ The AWS breach led to the closure of the Code Spaces company. The hacker took over of firm’s Amazon EC2 control panel. The hacker deleted EC2 machines, storage volumes and backup data via the company’s AWS management console.

➢ Most of the company’s data, backup and machine configurations had been deleted resulting in the company shut down.

Best Practices – Lessons Learned

➢ Consider the following allowing users to.❑ Manage their passwords.❑ Manage their access keys.❑ Manage their MFA devices.

➢ Disable root API access keys and secret key. ❑ If a hacker has access to the access keys and secret key, the hacker has

root access.❑ Do not have all powerful keys.

➢ Delete keys from the authorized_keys file on your instances when someone leaves your organization or no longer requires access.

➢ Consider using MFA for users and API calls.❑ Multi-factor authentication (MFA)-protected API access requires IAM

users to enter a valid MFA code before they can use certain functions, which are APIs.

❑ Policies you create in IAM will determine which APIs require MFA. ❑ The AWS Management Console calls AWS service APIs, you can

enforce MFA on APIs whether access is through the console or via APIs.

Best Practices

➢ Regularly run least privilege checks using IAM user Access Advisor and IAM user Last Used Access Keys.

➢ Check the permission levels of your keys.

➢ Regularly run AWS scans to identify misconfigurations or vulnerabilities.

Best Practices

➢As a best practice, users should rotate their access keys on a regular basis.

➢Always Rotate or disable keys if compromise is suspected.

➢Consider rotating API Key on a regular schedule.

➢Keys are backup so they can be restored if issues with data or application access occurs.

Questions

➢What are AWS API Keys?❑ Keys to open AWS doors.❑ Keys to authenticate API calls.❑ Keys to authenticate AWS users.❑ I do not know.

➢ Should the Root userid be assigned AWS Keys?❑ True.❑ False.

➢What are the risks of API Keys?❑ Unauthorized access to data stores.❑ Unauthorized access to root.❑ Unauthorized access to users.❑ All of the above.

Questions

➢What are the best Practice for managing the keys?❑ Rotate keys on a schedule.

❑ Disable keys when no longer needed or compromised.

❑ Protect keys as sensitive data.

❑ None of the above

Final thoughts

➢ Protect you keys as corporate sensitive data.

➢Unmanaged, stale or stagnant keys will hurt you

➢Monitor your AWS instances.

➢Use MFA.

➢Use strong password polices.

➢Use Cloud Trails.

➢ Conduct Security assessments of the AWS environment.

➢AWS environment can be secure if you make it secure.