top of page

Cloud Cybersecurity and the modern applications (part 1)

Other articles in the series: Part 1, Part 2, Part 3


Now, I’m not a firewall purist, but I and NSC42 have spent a fair amount of time implementing them in various cloud providers and of course on-prem.

In this series of articles, I'm going to illustrate the various challenges we faced and the solutions we proposed to achieve a cost-efficient access control implementation.

As we have undertaken multiple deployments we noticed that the implementation can be quite painful and not as straightforward as initially thought. In our experience, there is also an overall lack of comprehensive blueprints and reference architecture for access control.

As a result we decided to gather the NSC42 team’s knowledge on access control and firewall's in the cloud to provide a comprehensive overview of implementations.

A caveat I'd like to add though is that this article is by no means the finished product as the security controls in the cloud are ever changing.

These articles, do though illustrate a series of access control patterns, cases and advantages and disadvantages which should prove helpful and to make the article easier to digest, we’ve broken it down into a mini-series of several articles.

As our clients will already know, here at NSC42 we are whiteboard people, so some of the pictures will be in the form of whiteboard drawings, let me know if they're not clear, or you don’t like the style.

I have also used several acronyms in this article, and I apologise for that (10 push ups for each), I’ve summed the ones used at the end of the article to clarify.

Considerations to start with

Modern enterprises tend to utilise a mix or hybrid of cloud services like IaaS, PaaS and SaaS (Infrastructure/Platform/Software as a Service) to develop cloud applications. In a hybrid situation designing of the access control should be carefully planned.

Access control can be implemented at various levels:

• At the application level — embedding access control and roles in the logic of the application

• Infrastructure — implementing access control rules at network level

• Endpoint — implementing access control rules in a firewall endpoint or process access control.

We will explore and focus mainly on infrastructure and network as the application logic could take a whole different set of articles.

Network Virtual Appliances (NVA) aka Firewall Appliances

Modern firewall appliances integrate some security controls and are commonly referred to as Next Generation Firewalls (briefly NGFW).

The firewall appliances have been introduced into the cloud platforms as recent as the virtual instance. The cloud platforms are based on different architecture (like Software Defined Networks — SDN) that are quite different from traditional data centres. This difference makes the traditional firewall patterns challenging to implement in the cloud.

Firewall as access control and its history

Firewalls as technology have been around for a while and control was deployed in the enterprise and SMB. The control originated as a simple NAT device, and evolved, like the services. As the attacks became more and more sophisticated a range of security features were integrated like:

Access Controls (as firewall Rules)

• NAT/PAT Functionalities

• Deep Packet inspection (with IDS/IPS signature or behavioural based)

• Specialised Web Controls (as WAF rules)

• And many more…

With the added security features the traditional firewall rebranded itself as the Next Generation Firewall (aka NGFW) to make it sound more trendy.

Nowadays NGFW tends to fundamental be a security control that could be used to implement some of the building blocks of several security standards (e.g. PCI-DSS, ISO 27001, Security Essentials).

This control might not be directly related with GDPR but forms a fundamental element of the due diligence for the enterprise.

The NGFW is fundamentally the same virtual appliance as the On-Premises one.

Following all of our work I have discovered that cloud appliances can present the following challenges:

  • Number of interfaces

  • VLANs and Sub-interfaces

  • Networking and default gateways

  • High-Availability configuration

  • VPN and termination of them

  • Zoning concept (a division of firewall interfaces in different logical trust areas)

  • The load balancer in high availability configurations

It took a bit of time for me to get the above elements right in the various implementation, in fact a lot longer than I expected.

Each appliance differs slightly in configuration, but the challenges mentioned above have remained quite a constant.

As there are more and more cloud platforms, I will focus on the more popular ones (Azure and AWS).

Networking, VLANs and HA

The fundamental difference in networking (layer 2 and layer 3) between on-Prem and cloud appliances is the fact that the cloud platforms implement software-based networking (SDN) and prevent the appliances interacting directly with the under-layering fabric.

This has a consequence, specifically on the high availability configuration, to prevent the more traditional IP address sharing methods (HRRP, GLBP etc…).

Going full cloud-native

Native Access control offers seamless integration between the fabric of the cloud infrastructure (networks, endpoints) and access control.

This seamless integration implies that it is possible to deploy access control lists fundamentally at any level:

- access control list at endpoints

- access control list in the network

However, “with great power comes great responsibility”.

These powers and freedom imply that deploying too many access control lists in too many locations/network/endpoints might turn out into a management nightmare.

At this point, I haven’t come across any centralised solution that enables central management of rules even if AWS is doing some great work on maintaining the rule set for web access firewalls (AWS WAF/Firewall rules manager).

Depending on the maturity of the organisation, the deployment model (infrastructure as code) and teams (DEV-(SEC)-OPS) this deployment might be more appropriate.

In a scenario where rules are deployed per stack they would be written into the deployment code (cloud formation, terraformation, azure power shell scripts). The code in the deployment stack implies that the security team would have a harder job controlling and auditing rules unless there is a reliable and ingrained process (read as dev sec ops).

Traditional Appliances

As discussed in the firewall history the traditional firewall appliances have been around for a while now and they have advantages and disadvantages in a cloud world.

The primary advantage is the widespread level of talent and knowledge available on the market (any network and security engineer had to interact with NAT firewalls etc).

The disadvantages though, are that the network appliances are not integrated into the cloud fabric and are more complicated to deploy.

The other advantage is that most of the rules from different appliances can be managed from a central location that can maintain synchronous configuration amongst various models, facilitate, redeploy, and most important of all avoid direct human interaction with production appliances.

One of the other advantages, or disadvantages dependin on your feelings on the subject, is that the vendor tends to implement some software add-ons (sometimes referred to as blades) into their appliances. But while they offer some convenience for small and medium businesses (SMB) they tend to be less effective or configurable than standalone controls. Enterprise tends to prefer standalone controls from different vendors (to avoid vendor lock-in or complete outages if something goes wrong with an upgrade).


In this article, we’ve barely scratched the surface of firewalls' implementation into the cloud. So in the next articles, we’ll analyse patterns, challenges and other details.


Acronyms used:

We all hate them but we can’t live without them, for the sake of clarity I’ll list the meaning of the terms that I've used 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 since May 2018)

  • EU — European Union

  • FW — Firewall

  • HA — High Availability

  • IDS/IPS — Intrusion Prevention/Detection System

  • SMB — Small and Medium Businesses

  • L3 — ISO/OSI

  • Layer 3 — Network

  • LayerL2 — ISO/OSI

  • Layer 2 — Data Layer

  • MS — Microsoft

  • NAT/PAT — Network/Port Address Translation

  • NVA — Network Virtual Appliances

  • WAF — Web Application Firewall


Other articles on Medium:

64 views0 comments


bottom of page