TECHNICAL

Access Control - Cloud vs Traditional (Part 2)

The second in a series of articles from Security Chief Francesco Cipollone of NSC42 that deep dives into the subject of access control, authentication and compliance.

Francesco Cipollone

Dec 9, 2018 • 11 min read

This article is the second of a series of articles where I’ll illustrate some of the challenges my team and I have faced and the solutions we proposed to our clients to achieve a cost-efficient implementation of access control and compliance.

In the previous article, I’ve resumed a short history of network security appliances and native controls. In this Second, I describe the individual solution patterns we’ve used to create secure solutions and environments compliant to requirements and standards. The article walks you through the various use-cases and patterns.

Conscious of length I made a selection of the patterns that I came across more often and that can be replicated easily. There might be some specific use cases that will not fit into the specific patterns discussed in this part; please feel free to comment or get in touch. A caveat we’d like to stress: these solutions are, by no mean, finished products as the security controls and the cloud architecture are ever changing.

The rest of NSC42 team and I are well known to be whiteboard man hence some of the pictures will be drawn in the form of whiteboard sketches.

Let me know if you don’t find them clear or don’t like the style.

Use cases and common pitfalls

Security appliance vendors are still updating their appliances to include typical cloud architecture and integrate into the cloud provider fabric more efficiently. Some other instead are coming up with customized and managed set of rules for cloud provider specific controls (e.g., managed WAF rules).

The patterns in this section refer to the traditional multi-tier architecture (sometimes referred to as 3 tier model). The patterns explored here will refer to IaaS cloud deployment. The patterns can be adapted to hybrid models (e.g., IaaS and SaaS), but for the sake of time this part will focus only on IaaS deployments. The reference that I use in those hybrid environments is usually web API: whenever a service in IaaS needs to communicate with another cloud implementation (external IaaS, SaaS, PaaS), I’ll secure the communication as I would do between two API traversing public internet.

The deployment blueprints of traditional Firewalls and Web Access Firewalls (WAF) appliance are similar to traditional DC implementation with few exceptions.

Nonetheless please note that an access control relying only on firewalls struggles already in an IaaS model as it limits the capability of the cloud too.

Traditional firewall access control will struggle in a more modern hybrid integration between SaaS, PaaS and IaaS/Data Center.

The location of the ACL shall be carefully considered when one or more layer is exported outside the traditional IaaS infrastructure. I’ll provide some considerations on those hybrid scenarios.

Management Problem

The role of a central ACL rule manager becomes crucial, for operational processes and ease of use, as otherwise, the deployment of the rules is mostly atomic (e.g., inside one or more scripts). A typical scenario that requires a manager is when a cloud deployment has two or more firewall appliances.

A central rule manager enables the automatic synchronization of rules as most of the systems do not currently support synchronization of rules/sessions to an individual application level.

Usually, the management of ACL together with other key managing components should be deployed in an ad-hoc environment; I’ll refer to this as the management layer.

Patterns

In this section, I am going to illustrate some of the patterns NSC42 has used in some use cases. Be mindful that different cloud providers have different technical implementations.

Full native stack

AWS:

The picture below displays a full stack deployment in an IaaS cloud environment.

The pattern display on the left a classical 3 tier with the integration of different native AWS services like:

IP access control rules - for port-based filtering and as compensating control
ELB/ALB for load balancing and SSL offloading
WAF for specific WEB Layer 7 rules

The organization can decide to tip the scale of integration one way or another leveraging more on the cloud.

In this pattern, the controls are fully native and integrated with the fabric of the cloud.

This has the advantage that a deployment or redeployment can be automated.

The disadvantage is that the rules are distributed across various controls and not centrally managed. This could be quite complicated from a management perspective.

Usually, the managing elements of an infrastructure are deployed in an isolated environment (Azure subscription or AWS account).

Access to these management environments should be restricted to as the top security level. Any attack brought to this level of administration and control impacts and lowers the overall security posture of the environment.

The above diagram is derived from the reference AWS architecture.

References: https://aws.amazon.com/blogs/aws/building-three-tier-architectures-with-security-groups/

Azure:

The above diagram displays the cloud controls in Azure. The diagram is equivalent in AWS with some variation on the controls.

In Azure, the following are the equivalent controls, with few comparisons with the AWS equivalent:

Access controls via Network Security Groups (NSG)
Load balancers (even though they are not as mature as the AWS)
The WAF is not as mature and does not have the same level of managed rules as in AWS
The WAF does not have central rule management like the AWS equivalent.

References:

Alternative Azure SQL three-tier stack blueprint:

The above is an extract of the AWS blueprint available here: https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/n-tier/n-tier-sql-server

Full appliance stack

Azure

The following provides a high level and detailed implementation of a Full-stack Network virtual appliance in a three tier. The whiteboard presents a couple of options:

Single Firewall between web and Internet (usually in Small and Medium Business deployment)
Multiple firewalls at multiple tier (usually in Enterprise organizations)

Azure Blueprint:

Note: in the blueprint, there is a mix of NSG (network security groups) and NVA (Network virtual appliances). The NSG can be left empty unless you’d like to implement a hybrid approach. As in the previous section for AWS, the organization needs to decide how much they want to use the native controls (WAF/NSG…) and how much they want to use traditional appliances (Firewalls/WAF…).

Single firewall detailed deployment:

The above diagram displays a deployment with multiple subscriptions.

The deployment leverage on the Azure subscriptions to enforce isolation of networks.

The NVA can be deployed as an individual and single appliance if the enterprise does not require high availability.

This spares the enterprise in deploying script to update UDR, but the UDR would still need to point to the southern interface of the firewall

The UDR informs the various virtual networks (vNETs) where to point as the default gateway, the firewall southern interface.

For more information refer to https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview and https://docs.microsoft.com/en-us/azure/virtual-network/tutorial-create-route-table-portal

Multiple firewall scenario detailed deployment:

The above is just a simplified scenario with a number of controls. It is just an example of how to connect an enterprise (On-Prem) with a cloud deployment. The networks are divided into Prod Dev and UAT subscriptions (on the left) as in a similar way to the on-prem system (bottom right part of the picture).

Multiple firewall scenario detailed deployment:

The table below displays the steps and the controls in various areas

Step

Control

Description

Traffic Manager

The user requests traffic manager the website and it receive the current available region

DNS

DNS resolution of the website

DDoS (Azure)

Without any particular deployment Azure has network DDoS but they might not be sufficient for applications

Load Balancing

Azure Load Balance the traffic across multiple instances

WAF (appliance)

The Load Balancer redirect traffic to the active NVA for WAF inspection.

This pattern is different with the integrated Azure WAF

Firewall

The Traffic gets directed to the active NVA (Firewall, via the Load balancer in front) and inspected by the various module

6/7

Web Frontend

The webfrontend processes the request in the subscription and request the information to the application middleware (in the subscription)

Firewall (again)

The NVA (Firewall) inspect the traffic from the Web Frontend to the database using the configured modules

NSG

The Network Security Group could filter additional port in the subscriptions

Host Controls

The host could filter traffic using different controls (e.g. host firewall)

Connection to database

[Not displayed] the application to database connect either directly or passing via additional NSG or a second layer of firewalls

The above is just a simplified scenario with a number of controls. it is just an example of how to connect an enterprise (On-Prem) with a cloud deployment. The network are divided in Prod Dev and UAT subscriptions (on the left) as in a similar way to the on-prem system (bottom right part of the picture).

The numbers displays the flows of traffic from an external request to internal system with the various controls.

The one that follows will provide some more level of details

The deployment leverage on the Azure subscriptions in order to deploy isolation.

This blueprint requires peering on the southern interface of the firewall NVA with Load balancer on the northern side.

this picture (prettier than the above sketch) displays one method of deployment in Azure. Please note that the various subscription needs to be equipped with UDR as the south part of the firewall does not have a load balancer. This deployment will persist up until the point when Azure will develop the Load balancers to enable persistent sessions.

As an alternative to the UDR the firewall could have Load balancers on the north side.

For the reason explained above the southern part of the firewall is peered to multiple subscriptions. In order to have a route to the firewall, and hence internet, the vnets needs to have User Defined Routes (UDR). In order to achieve load balancing and high availability the various subscriptions need a script to dynamically update the default gateway in the UDR to be the active firewall souther’s interface. The script guarantees high availability in case one of the instance goes down.

The script would probe dynamically the interface and update the default gateway on the UDR.

for more information refer to https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview and https://docs.microsoft.com/en-us/azure/virtual-network/tutorial-create-route-table-portal

AWS:

Following a couple of examples for NVA deployment in AWS

the scenario is similar to Azure with some difference in the peering, Custom routes and probing.

Firewall and Datacenter scenarios:

The above displays a deployment of two appliance inside a single VPC with multiple availability zones.

The Firewall is deployed in front of the WAF.

The VPC is also peered with an on-Prem (or could be another VPC/Account).

The appliances will be located behind ELB/ALB shielded by the Firewall and WAF.

As with the previous case the NVA appliance (Firewall) could cover multiple VPC in AWS.

Detailed Firewall scenario:

The following represent the deployment of firewall with multiple VPC in a similar model as Azure.

Each VPC will have a VPN gateway that will be peered with both firewalls.

The active Firewall will peer with the VPN gateway and form a BGP peering. Being peered with BGP to the AWS VPN gateway the active Firewall will inject a default route. In case the primary system fails the other firewall will become active and start advertising the default route.

As previously discussed the Firewall could be deployed in standalone mode or with the aid of a WAF. The WAF could be deployed as cloud front-end filtering service (e.g. AWS WAF) or an external SaaS service (e.g. Imperva or similar).

Hybrid Approach

The hybrid approach makes use of some the models described above and layers them up with the use of cloud native controls (WAF, IP Filtering etc…)

The major difference in hybrid is how many rules do you want to implement in the cloud access controls (NSG/ACL/NACL) and how many you want to implement in the Firewalls.

The reason behind this approach are multiple: the cloud immaturity of an organization or the alternative rationale is to keep most of the access control rules in one place. A hybrid use of the rule could be a useful migration approach but is not recommended as the rules are scattered around multiple access control point and would make the management of those ultimately more complicated.

Conclusions

As we’ve explored there are multiple deployed patterns. As NSC42 we’re committed to deliver what our customers wants to achieve and guide them to the best solution that will fit their needs, budget and level of maturity.

The organization shall have a clear and solid strategy and idea as the the pattern above are difficult to change once the deployment are underway.

Infrastructure as a code enables “easy” re-deployment of various component but this would always imply testing and additional effort.

My recommendation on the back of NSC42 experience is to have a series of workshop with the key stakeholder and agree a deployment model that makes everyone comfortable (operation, management, compliance, security).

Out of my experience having a solid foundation results in a happier or less painful cloud journey.

Depending on the organization’s appetite for cloud readiness and the level of cloud maturity of the operation team a cloud first from control prospective could be more or less recommended.

For organizations that are more traditional the firewall appliances remains, with exceptions, operationally easier to maintain.

For cloud first organizations with more modern skilled team team native access controls.

To get in touch with us, please drop me a note on LinkedIn, Twitter @Franksec42 or to my e-mail Francesco.cipollone (at) Nsc42.co.uk

Acronyms used:

We all hate them but we can’t live without them, for sake of clarity I’ll list the meaning of the terms that I’m going to use in the article:

• AD – Microsoft Active Directory

• AWS - Amazon Web Services

• ACL - Access control List (AWS)

• NACL - Network Access control list (AWS)

• NSG - Network Security Group (Azure)

• EU GDPR – European Union General Data Protection Regulation (in force May 2018)

• EU – European Union

• FW - Firewall

• HA - High Availability

• IDS/IPS - Intrusion Prevention/Detection System

• L3 - ISO/OSI Layer 3 - Network Layer

• L2 - ISO/OSI Layer 2 - Data Layer

• NAT/PAT - Network/Port Address Translation

• NVA - Network Virtual Appliances

• WAF – Web Application Firewall

• SMB – Small and Medium businesses

• MS – Microsoft