Operational Complexity: The Biggest Security Threat to Your AWS Environment

transcript

Security is kind of a big deal… We’ve all got them. Are we doing the right thing to secure them?

ON-PREMISESIN THE CLOUD HYBRID ENVIRONMENTS

And it’s no different in AWS

Managing tightly-controlled user access in AWS is too complex.

But it’s hard.

And complexity leads to errors and sloppiness.

Why is it so complex?

There are 6 main reasons

User access is IP-centric, and their IP addresses change

Predicting where those users are going to be when accessing your network is a very big challenge; and almost impossible if you have a mobile workforce.

1Think office to home, to mobile, to a coffee

shop, to a plane…

Dynamic environments cause extra administrative burdens 2

As virtual machines and services within AWS are spun up, expanded or contracted, being able to dynamically allocate security policies to these resources becomes a real challenge.

Complexity leads to shortcuts 3

A lot of the time shortcuts are taken that compromise the security posture in the footprint of a particular environment.

Forced use of VPN connectivity to manage access control 4

And it can create performance issues for your end users and force unnecessary hops from environment to environment just to ensure that people are coming at the environment from appropriate locations.

If you’re at all into the networking space within your organization, you know that the use of VPNs is also not a trivial task.

Logging correlation complexities 5

So when it comes to audit and compliance, you have a tremendously difficult task on your hands to correlate these logs and figure out who is doing what, who is accessing which application, what time of day and under what context they are doing it.

All of this hopping around and all of these different technologies lead to logging correlation issues.

Shared AWS responsibility model 6

Do you know where AWS’s responsibility for the cloud ends – and yours begins?

Compute Storage Database Networking

AWS Global Infrastructure

Regions Availability Zones Edge Locations

https://aws.amazon.com/compliance/shared-responsibility-model

AWS Shared Responsibility Model

AWS is responsible for this…

Responsible for security ‘of’ the cloud

Customer Data

Platform, Apps, Identity & Access Management

OS, Network & Firewall Configuration

Client-Side Data Encryption and Data

Integrity Authentication

Server-Side Encryption (File

System and/or Data)

Network Traffic Protection

(Encryption/ Integrity/Integrity)

CustomerResponsible for security

‘in’ the cloud

And you’re responsible for this…

Anytime you take advantage of the resources and build virtual machines, deploy data into S3 buckets or use a feature like AWS Snowball to push data into the environment, security becomes your responsibility.

Anything in the cloud is your responsibility

AWS gives you tools, but you have to implement them.

AWS’s responsibility ends with the physical components of the cloud…the data center, the servers, the storage.

You are responsible for everything that leverages those physical components – all the configured services, data, deployed applications. This includes network access security.

Security Groups

So we turn to

You can use Security Groups,

but they introduce operational complexitywith negative consequences.

We either give wide-open access and end up with this…

No accountability/visibility

Increased risk of

security breaches

Managing compliance is

virtually impossible

Ortightly controlled access and end up with this…

Reduced business

agilityFriction for

DevOpsInefficient approval process

Consider this scenario

Security Groups

Four users access the Amazon environment from a known source.

73.68.25.22124

Their public IP address is the known source. The security

groups are configured appropriately.

Security Groups

Four users access the Amazon environment from a known source.

73.68.25.22124

The challenge is when users try to access

from other locations.

73.68.25.22124

Security Groups

Do you:

Allow wide open

access from

anywhere?

73.68.25.22124

Or tightly control access – force

users to VPN into a known office and

through a 73 dot IP address?

There’s a better way to do it.

It’s called a Software-Defined

Perimeter

A Software-Defined Perimeter gives every user on your network –

whether an internal employee or a third-party working for you – an individualized

perimeter around themselves and the network resources that they’re allowed

to access.

And it’s a big deal

Industry experts suggest using it

Legacy, perimeter-based security models are ineffective against attacks. Security and risk pros must make security ubiquitous throughout the ecosystem.”

“ It is easier and less costly to deploy than firewalls, VPN concentrators and other bolt-in technologies.”

SDP enables organizations to provide people-centric, manageable, secure and agile access to networked systems.

A Software-Defined Perimeter gives you:

Individualized perimeters for each user – a Segment of One

Fine-grained authorization to on-premises and cloud

Context-aware driven authentication, then access

Simpler firewall and security group rules

Dynamic authorization adjusting to the user to access new cloud server instances

Consistent access policies across heterogeneous environments

A Software-Defined Perimeter puts the person back into the security model.

… by taking the source IP concept out of the equation.

The person, their identity, the device they’re on, the network they’re connected to, and just about anything else you could think of to analyze before you allow access resources on your network, is checked.

73.68.25.22124

Once a person is authorized to view resources, everything else on the network becomes invisible.

Cryptzone delivers a

Software-Defined Perimeter Solution for AWS

DigitalIdentity

AppGateImagine a user wants to access the company’s ERP system

Managed NetworksCloud, On-premises or Hybrid

Secured Email

CRM Group File Share

Executive Files

Enterprise Finance

\\EXEC_SER

SharePoint

AppGate

DigitalIdentity

First we look at both context and identity.

DEVICE TIME

CUSTOMATTRIBUTES

ANTI-VIRUS

LOCATION: OFFICEAPPLICATIONPERMISSIONS

AppGate

DigitalIdentity

We confirm it matches your policies before granting access.

DEVICE TIME

CUSTOMATTRIBUTES

ANTI-VIRUS

Managed NetworksCloud, On-premises or Hybrid

Secured Email

CRM Group File Share

Executive Files

Enterprise Finance

\\EXEC_SER

SharePoint

DigitalIdentity

We then create a dynamic Segment of One

(1:1 firewall rule).

DEVICE TIME

CUSTOMATTRIBUTES

ANTI-VIRUS

ENCRYPTED & LOGGED

AppGate

And make everything else (the applications and the

rest of the network) invisible to the user.

DigitalIdentity

DEVICE TIME

CUSTOMATTRIBUTES

ANTI-VIRUS

APPLICATIONPERMISSIONS

ENCRYPTED & LOGGED

AppGateManaged Networks

Cloud, On-premises or Hybrid

LOCATION: OFFICE

DigitalIdentity

And if the user goes home and wants to continue working, AppGate

automatically checks “user-context” again, and applies the correct “home-

based” policy.

DEVICE TIME

CUSTOMATTRIBUTES

ANTI-VIRUS

LOCATION: HOMEAPPLICATIONPERMISSIONS

ENCRYPTED & LOGGED

AppGateManaged Networks

Cloud, On-premises or Hybrid

The result?

Locked-down secured access to AWS resources that is operationally simple to manage and maintain.

Let’s look at this more closely…

Current Model

AWS Security Groups

We all know about AWS Security Groups. The current Security Group model is complicated and unpredictable.

AWS Security Groups & AppGateUsing AppGate, there are multiple gateways, protecting multiple cloud providers with split functionality.

Current Model

AWS Security Groups & AppGateAppGate defines protected destinations, called Entitlements and protects simple IP addresses and ports, but also ranges of IP addresses and Ports, AWS Tag and Values as well as AWS Security Group names.Current Model

AWS Security Groups & AppGateAppGate offers a new Security Model inside AWS, redefining the Security Group so that protected destinations allow traffic only from the AppGate Gateway, ensuring all users access those resources through the contextual controls provided by AppGate.

AppGate Model

AWS Security Groups & AppGate

Authentication Policy• If users are on corporate

network allow Single-Factor Authentication

• If users are not on corporate network require Multi-Factor Authentication

POLICY

Device Policy• Allow access if Anti-Virus

is running• Allow access if Device

Firewall is enabled• Allow access if OS patch

level is current

POLICYPOLICY

Developer Access Policy• Allow TCP Access

• On Port 22

• For all servers tagged Dev-Project

• If users are in group Development

Users are tied to the entitlements through Policies where we can enforce contextual awareness before allowing specific users access to specific entitlements. This combination allows us to get very granular on who can access what and under what circumstances.

Because there is just one IP address, managing security just got easier.

AppGate Model

Access policies across hybrid

environments are consistent

Access is tightly secured with a

Segment of One

Compliance reporting is easier and

faster

Operational agility is boosted

DevOps can work

faster

Infrastructure changes are dynamically protected

AppGate from Cryptzone provides user control, operational agility and compliance

Sally MDeveloper

Project Eagle

Charlie SDB Admin

Joe RDeveloper

Project Hawk

Coffee Shop

Consultant

Enterprise Headquarters

AWS Security… Simplified!

User-centric security policies…because people are not IP addresses

Learn more about AppGate

AWS SecuritySimplify, Scale, & Secure User

Access

WEBINAR

The Zero Trust Model of

Information Security

WHITEPAPER

Forrest ReportNo More Chewy Centers:

AppGateVIDEO

FREE TRIAL | START NOW

Email: info@cryptzone.com

Twitter: @Cryptzone

LinkedIn: linkedin.com/company/cryptzone

GET IN TOUCH

Get access to a 15 day free trial on AWS marketplace.

Would you like to know more?

Paul CampanielloChief Marketing OfficerCryptzone