Cloud Cybersecurity and the Modern Applications (part 3)

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

Hybrid Patterns in Azure

In new cloud deployment, it is common to see organizations using a combination of multiple cloud environments or methodologies. Managing access control in a single appliance is already a struggle on one single technology/appliance not to mention various cloud providers or cloud methodology.

PaaS web front end

3-tier high-level view (Hybrid vs PaaS)

The above picture illustrates an example of a three-tier hybrid deployment model.

The architecture displays a web front end developed in a server-less environment (in this particular case the Azure Application services). It could be implemented on a traditional IaaS web server, but for this particular article, I’ve chosen the deployment in leveraging PaaS technology.

The applications in this environment are distributed in different layers, and this might pose challenges to the deployment, location and the type of security controls.

Utilizing PaaS service has the advantage of the delegation of some elements of security to the cloud service provider; this could be advantageous for smaller organizations as they can focus on secure development of the application with the CSP securing from physical to OS Layer. A three-tier IaaS deployment, on the other hand, enables more granular controls and allow the organization to choose its controls. In PaaS or SaaS environments the organization is forced to accept the security controls and their granularity, offered from the cloud provider. The organization might not be able to utilize PaaS services due to the lack of granularity of the security controls.

This situation is where the security professional plays a vital role by either mapping the control capabilities to regulatory controls or coming up with solutions that aggregate some controls that result in compliance with organization risk appetite or regulatory requirements.

Web Frontend

It is advised to have a tighter set of controls on the Web frontend (on IaaS or serverless). The application’s web frontend is ultimately the front door to the application data, hence a lot of actors, legitimate or malicious, will knock on it.

As the number of malicious actors is increasing as well as the general availability of attackers, it is essential to have a well-tested and straightforward web front-end code, well defined and authenticated API and traffic filtering. The next section will provide some of the security controls that could be deployed to protect the front end.

Attacks on web frontend, especially DDoS, can be particularly costly as they will consume a significant amount of resources (e.g. web front end scaling out until it reaches the set limits).

The above cost for consumption is even more real for serverless environments, where the price, generally higher than IaaS, is directly linked to the number of requests.

For this specific reason, the security control, listed below, shall be enriched by controls on resource consumption, spending and billing. The resource consumption also applies to anti-DDoS controls like CDN, or DDoS front ends (to mention a few akamai, Imperva and F5 networks).

Web-Frontend Security Controls

Expanding on the previous section, the controls on the web-frontend focus on the behavioral pattern (the type of request) to distinguish legitimate and malicious requests. Also, the control is focused on WEB protocols and their correct behaviors (also known as Layer 7 controls or application specific controls).

A non-exhaustive list of control, typical for this layer, is the following:

• DDoS control (External or embedded in CSP Azure DDoS or AWS DDoS and AWS Shield )
• CDN (content distribution network) or similar traffic distribution systems (like Azure CDN or AWS CloudFront)
• DNS Protection (like Azure Traffic Manager or AWS route 53)
• Web Application Firewalls (like Azure WAF or AWS WAF)
• Access control, roles and permissions (controls like Azure NSG or AWS Security Groups)

Please note that the above is just a starter for 10 list, and is non-exhaustive. The controls and their cost shall always be linked to a risk assessment as well as an evaluation of the value of the asset they are protecting.

Web Frontend request protection:

The following provides a zoom in on the web frontend from the previous architecture and the number of controls implemented. The sequence of controls can be switched around and re-ordered depending on the risk assessment and needs. The picture provides just one of the standard patterns to expose and protect a web service. The selection is to reduce the length of the article.

A sequence of Controls for the web frontend

Cloud Provider offers a range of controls to mitigate different issues on web frontend. The controls are the following:

• CDN — the CDN is a geographically distributed network of proxy that distributes the content globally. The goal is to distribute service spatially relative to end-users, to provide high availability and high performance. This control (not traditional a security control) is generally managed by a Cloud provider (like Azure CDN or AWS CloudFront). This controls deployment method provides a less responsibility for the service user (usually the service is similar to a SaaS server with minimal configuration requirements). This choice of deployment reduces the burden for the service user (often the service is identical to a SaaS server with minimum configuration requirements). Because of the scalability being in the care of the service provider, this is an attractive control, but it also comes at a cost. Is always worth evaluating between CDN and DDoS and which one to place first (1 and 2 in the picture above).
• Traffic Manager — in the picture above it acts as a load distribution control similar to the CDN (an example of this are Azure Traffic Manager or AWS Route 53 traffic flow).
• DNS Control — together with the CDN this controls and protects the DNS entries and dynamically updates the DNS record in case the address needs to be switched to a CDN. Examples of these services are Azure DNS together with Azure Traffic manager or AWS Route 53

Following an example of the DDoS Protection with AWS from the AWS DDoS blueprint

AWS DDoS Blueprint

DDoS control — the Distributed Denial of Service control is meant to detect malicious and anomalous request rate from end users to the web front ends. The control could return some false positives, depending on the sophistication of the attack or how well trained the DDoS control’s algorithm is. The DDoS attacks aim to overload a resource and render it unusable masking the malicious stream of attacks as the number or legitimate requests. The more sophisticated the offense is, the more legitimate the malicious request looks. The main difference between a valid request and a DDoS is the rate of the requests. A high peak in the frequency of the request would lead to a detectable DDoS while more time and geographically distributed numbers of the request makes the attacker challenging to detect. The DDoS offering varies, but the following are the “easy” plugin options:

Azure DDoS Offering

• Basic Cloud DDoS — those tend to be integrated into the CSP network but are mostly to protect the account. The thresholds for those controls tends to be quite high.Azure DDoS protection or AWS DDoS protection)
• Advanced/tailored Cloud DDoS (like Azure DDoS or AWS Shield) those controls are more tailored to the application. They provide fine-tuning and monitoring suited to the application.
• External CDN/DDoS controls (like Akamai, Imperva and F5 networks) these services link their external address (on demand or permanently) to the DNS address of the web frontend. This results in the web frontend “virtually” being part of the CDN network. In this way traffic for the web frontend (or website) can be baselined. The baseline provides a significant advantage to the DDoS control’s algorithm as it can be tailored to the regular activity of the website. The tailored algorithm (or trained) will ultimately lead to more accurate results (read as more attacks blocked). Nonetheless, the DDoS control can always be vulnerable to an increased number of false positives, depending on the accuracy of the algorithm and the initial training set.

WAF zoom-in

• WAF — The Web Access Firewall (WAF) deployment and configuration in this hybrid model is slightly different from the traditional IaaS or on-premises). The picture above displays two methods of deployment with web front end controls:
• Cloud Service Provider WAF — The left displays the Native Cloud WAF with the serverless app. For more details refer to web app creation. This approach has the advantage to deliver an integrated WAF technology in the cloud fabric, hence it requires minimal configuration, and is natively integrated with security dashboards like Azure Security Center or AWS Security hub / AWS Shield monitoring. For more details on the integration refer to WAF and security centre integration.
• External WAF providers — The right displays, instead, a method of protecting the web app leveraging an external provider DDoS control and/or Web Access Firewall (an example of this are Imperva or Akamai). A cloud CDN or DDoS protection service acts as compensating controls. The rules granularity offered by those external WAF providers (e.g. Imperva cloud WAF, F5 cloud WAF or Akamai cloud WAF) can be more or less sophisticated than the Cloud Native’s one. The external WAF providers build on the experience gained from of implementing the solution on multiple customers and over time (e.g. F5 has been around since 1996 …quite a while). Because of this history, their algorithms tend to be more sophisticated and granular. Nonetheless, Cloud providers are quickly catching up with those controls and are offering more and more granular rules.
• WAF Considerations to consider in this WAF configuration are:
• The Web Application or Web Application Programmable Interface (API) is located on a managed service (with the advantages and disadvantages explained above
• The traffic would need to traverse the web to reach the application backend with all the additional, controls this might require
• Log collection and centralization of log might pose some challenges even though the integration is getting better and better: https://docs.microsoft.com/en-us/azure/app-service/web-sites-enable-diagnostic-log

IDAM/Identity Store:

One of the key elements to consider in the web frontend, and as part of the overall application, is where the user credentials reside and which component authenticates the user.

Best practice recommends hardening the web frontend, as this is the first application’s component that would get attacked. The authentication page should be simple and utilize external identity front entry as well as authorization tokens.

The above PaaS environment can be integrated with traditional “traditional” identity stores (e.g. AD) nonetheless is best practice to authenticate against an identity frontend. This pattern has the benefit of hiding and protecting the identity store. Security best practices and the cloud pattern blueprint recommend the use of federation service (like ADFS) to minimize the exposure of the identity store (e.g. Active Directory).

Building on this pattern Azure has created B2B and B2C federation services together with AAD. Each of those services can be used as a federation service with different identity stores, or they can act as an identity store themselves.

The applications developed inside azure application service can leverage AAD, B2B or B2C federation service to authenticate users (refer to Azure app service and identity store integration)

The Identity store gets protected by the use of the cloud service provider’s federation front end (AAD/B2B/B2C).

Using the CSP Identity front end removes the customer’s burden of securing and hardening the identity store OS and physical layer as it is delegated to the cloud provider (refer to Cloud service provider responsibility model).

An alternative method to the above is to utilize an external (to the CSP) identity front end like OKTA or Auth0.

Application Backend zoom-in

Application Backend

The application backend is used to process data received from the web front end. As this processing could be computationally intensive, the system is usually run on IaaS infrastructure (left picture). The application backend tends to interact with the database backend so the security controls at this layer must be more restrictive.

The following example mentions the container as a service (CaaS) model for the application tier. but the concept can also be expanded to the two other levels (web frontend and database).

In order to keep the pattern short, I’m only mentioning this methodology in this tier (with the relevant security controls).

For the application tier there are several implementation options:

• Dedicated IaaS servers (left picture)
• Server-less application leveraging cloud architecture (e.g. function in azure or lambda in AWS) — right picture (PaaS Services)
• Server-less as part of a cluster (e.g. nodes in a Kubernetes cluster) — right picture but with the cluster deployed by the enterprise customer.

As displayed above the IaaS deployment allows more control on the but also more responsibility for the enterprise customer.

The PaaS service, on the other hand, delegates some responsibilities to the CSP (like OS hardening depending on the situation, or setting up the cluster).

Application Security Controls The security control for this layer varies depending on the threat model and risk assessment.

Common control implemented at this layer are:

• IaaS deployment model: there is a range of controls for this deployment model:
• Access control (either NVA — Firewall or CSP access control like Azure NSG or AWS Security groups )
• Network or host IPS (either NVA or cloud-native like AWS Inspector)
• Host anti-malware or behavioral pattern recognition (either dedicated agents or cloud-native like AWS Inspector or Azure security centre premium)
• Serverless application using custom deployment: in this implementation, the enterprise customer will be responsible for deploying and securing the cluster. The cluster would need to be secured with the following controls:
• OS hardening (for both the nodes images and the cluster host — chassis)
• Host OS Antimalware
• Node OS Image hardening (apply CIS controls on the node image)Cluster-specific security controls (e.g. NeuVector or Aqua security )
• Serverless application using cloud services: this method could make use of a range of services. From fully managed container services (like Azure AKS or AWS ECS) or more CSP managed PaaS services (like Azure functions, Azure logic Apps or AWS Lambda). The subject could be extended in a whole range of discussions, I’ve summarized here some of the controls that could be applicable to the various scenarios:
• Logging via cloud collectors (e.g. AWS Cloudwatch, AWS Cloudtrail, AWS Insight on Azure log collector with Azure security centre)
• Access control via some methods:
• Using NSG or firewalls in ASE — Application service Environment NSG and Application service environment
• Using IP restriction in Azure App service or web config IP filtering IP restrictions on Azure application service.
• Using IP filtering, control the access to keys, and other security methods (for more details refer to Azure security when using Logic App
• Securing AWS Containers utilizing Network ACL, Security Groups Roles and Policies (Security Groups and networks ACLs with IAM roles and policies in AWS ECSSecuring the Containers and the lateral movement with container security services like NeuVector or Aqua security
• Using AWS Lambda functions with IAM Roles and policies together with Security Groups and Network ACL (or bucket policies in case the lambda needs access to an S3 bucket)
• Protecting the Identity and enforcing RBAC via native Identity and access controls (e.g. Azure IAM with permission and Azure RBAC groups or AWS IAM with AWS Policies and AWS Roles)
• Behavioral pattern recognition of malicious activity (like Azure security centre premium or AWS Inspector)
• Anti DDoS (like Azure DDoS or AWS Shield)

Database Tier Zoom-in

Database Tier

The above picture represents the IaaS and PaaS deployment options of the database:

• In the left image, the Database is deployed in a traditional IaaS environment. This deployment requires the traditional High Availability controls, together with the responsibility of the security to the organization. This deployment model relies on the organization (client) to deploy, access control, roles, hardening etc…)
• The right picture displays a deployment leveraging the Azure SQL PaaS or AWS RDS service. Either of those deployments is PaaS service. Because they are PaaS service, the CSP is responsible for securing and hardening from the physical layers all the way to the application layer. The enterprise (customer) is responsible for the security in the cloud. This means that the customer is responsible for securing the database access control plus deciding the field that shall be encrypted. The customer is also responsible for the security of the roles, users and permissions with processes like joiners, movers and leavers.

This deployment has similar advantage and disadvantages as the above web frontend layer:

• The left deployment (IaaS) relies on the customer’s control but provides the highest level of flexibility (the IaaS controls are at the discretion of the enterprise customer).
• The right deployment (PaaS) relies on the CSP controls. This provides some level of freedom (e.g. configuration of roles but not the hardening of the OS). But in a more constrained environment (the granularity of controls is dictated by the CSP). The enterprise customer would need to decide, based on a risk assessment as well as the applicable regulation, which deployment best adapts to the scenario.

Conclusions

In this article, we’ve explored several deployment patterns, and the advantage, disadvantages as well as the constraints that the various options (IaaS and PaaS) offer.

At NSC42 we’re committed to delivering the best result for what our customers want to achieve as well as guide them to the best practices and solutions.

To have a consistent deployment, the enterprise organization should have a clear and robust strategy. NSC42 can help to define the strategy, as a note is difficult to change the implementation strategy from IaaS to PaaS.

My recommendation on the back of NSC42's experience is to have a series of workshops with the key stakeholder and go through the benefits and disadvantages of the various scenarios. An agreed deployment model results in an easier deployment and a smoother transition to production.

Having a solid foundation is the enabler for a happy cloud journey.

Depending on the organization’s level of security/cloud maturity some options (PaaS/SaaS) would make sense. For more traditional organizations NSC42 recommends an approach that starts with IaaS deployments and eventually moves to PaaS.

One example of this is the approach to Firewall vs Cloud native access control: more traditional organizations choose an NVA — Firewall approach while more cloud mature organizations might implement cloud-oriented controls (Azure NSG — Network Security Groups or AWS — Security Groups).

The cloud ultimately offers several tools and deployment options, what is best for the organization is the one that adapts the most to the risk appetite as well as the cloud maturity level.

Ultimately the best solution is the one that works for your organizations.

In the next article, we will explore challenges of managing WAF or firewall rules and the options the CSP and traditional appliance implementation teams offer.