Cloud Cybersecurity and the Modern Applications (part 2)

By Francesco Cipollone, Chair at Cloud Security Alliance UK Chapter and Director at NSC42 Ltd.

Use cases and common pitfalls

Security appliance vendors are still updating their appliances to include typical cloud architecture that integrates into the cloud provider fabric more efficiently. Some others are instead coming up with customized and managed sets 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 a three-tier model) and the patterns explored here will apply to IaaS cloud deployment. The patterns are 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 Firewall (WAF) appliances are similar to conventional 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. So, the location of the ACL should be carefully considered when one or more layer is exposed outside of the traditional IaaS infrastructure. I’ll provide some considerations on those hybrid scenarios later on.

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 crucial managing components should be deployed in an ad-hoc environment; I’ll refer to this as a management layer.

Patterns

In this section, I am going to illustrate some of the patterns NSC42 has used in some cases but be mindful that different cloud providers have a different technical implementation.

Full native stack

AWS Use Case:

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 controlELB/ALB for load balancing and SSL offloadingWAF 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.

Utiliing this pattern has the advantage that deployment or redeployment can be automated.

The disadvantage is that the rules are distributed across various controls and not centrally managed. The distributed rules could be quite complicated from the management perspective, as usually, the managing elements of 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 picture 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:

https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/dmz/secure-vnet-hybridhttps://aws.amazon.com/blogs/awsforsap/vpc-subnet-zoning-patterns-for-sap-on-aws-part-2-network-zoning/https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html

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 levels (usually in Enterprise organiations)

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 organisation 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 an implementation 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 deployment mode 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 southern firewall interface.

or 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 deployments:

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

The above is just a simplified scenario with some controls. It is an example of how to connect an enterprise (On-Prem) with a cloud deployment.

The network is 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).

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

The one that follows will provide some more level of detail:

The deployment leverage on the Azure subscriptions to deploy isolation.

This blueprint requires peering on the southern interface of the firewall NVA with the 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 a reason explained above, the southern part of the firewall is peered to multiple subscriptions. To have a route to the firewall, and hence the internet, the VNETs needs to have User Defined Routes (UDR).

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's southern interface.

The script guarantees high availability in case one of the instances goes down.

The script would probe the interface dynamically 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 pucture displays a deployment of two appliances inside a single VPC with multiple availability zones.

The Firewall is deployed in front of the WAF, while thetThe VPC also peers 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 the firewall with multiple VPC in a similar model as Azure.

Each VPC will have a VPN gateway that is 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 implemented 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 native cloud controls (WAF, IP Filtering etc…)

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

The reasons 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 points and would make the management of those ultimately more complicated.

Conclusions

As we’ve explored there are multiple deployed patterns. At NSC42 we’re committed to delivering what our customers want 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 patterns above are difficult to change once the deployment is underway.

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

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

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 operations team a cloud-first from a control perspective could be more or less recommended.

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

While, native access control is recommended to cloud first organizations with more advanced skilled team native access controls.