Cloud Cybersecurity and the Modern Applications (part 1)

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

Modern enterprises tend to utilize 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 centers. 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 behavioral based)

• Specialized 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

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 centralized 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 organization, 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 depending 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).

Conclusion:

In this article, we’ve barely scratched the surface of firewalls' implementation into the cloud. So in the next articles, we’ll analyze 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