Funnel-based Architecture for application Security on the Cloud - Part 1 - The Framework

As a Solution Architect, I've got a few opportunities to work with organizations facing security challenges on the cloud, especially with public facing applications. One of the most common issues I've encountered is a lack of visibility and control over their cloud environments.

To solve these security issues I've implemented a funnel-based framework for enhancing security on the cloud. This framework involves identifying the data flow within the cloud platform and implementing funnel points, which act as choke points at each layer for security controls. The last steps of the framework include increasing observability and continuous security improvements.

Below are the different steps :-

Step 1: Identify the Data Flow within the Cloud Platform

The first step in implementing a funnel-based framework for security on the cloud is to identify the data flow within the platform. It concerns understanding the data types processed through the platform and identifying the various stages in the data flow. It also includes getting to know every service or layer through the data flows.

Step 2: Implement Funnel Points

Based on the data flow, the next step involves implementing funnel points throughout the platform. Funnel points are choke points in the data flow where security controls are added at each layer to protect from threats. These funnel points are part of the Network, Transport, and Application Layers. These funnel points in the system may include network gateways, data storage, web and application services, and other components. 

Step 3: Implement Security Controls at Each Funnel Point

At each funnel point, security controls at each layer or service protect the cloud environment. It includes access controls, encryption and decryption processes, network security controls, monitoring and logging mechanisms, vulnerability management, and incident response processes. Each security control design addresses a specific threat or vulnerability and works together to provide comprehensive protection for the cloud environment.

Step 4: Regularly Monitor and Update the Security Controls

Once the security controls are implemented in each layer, it is critical to regularly monitor and update them to ensure they are working effectively. It involves monitoring the platform for suspicious activity, regularly reviewing access controls, updating software and security patches, and testing the security controls to identify any weaknesses or vulnerabilities.

Step 5: Continuously Improve the Framework

Finally, to continuously improve the funnel-based framework for security on the cloud, it is critical to stay ahead of emerging threats and vulnerabilities. It involves staying up-to-date on the latest security trends and best practices, regularly reviewing the security controls to identify areas for improvement, and working with clients to identify new threats and risks.

By following these steps, I was able to implement a comprehensive funnel-based framework for security on the cloud that provided good protection against a wide range of threats and vulnerabilities. I will deep dive into the Funnel based Architecture with examples in Part 2.

Funnel-based Architecture for Website Security on the Cloud - Part 2 - Using Microsoft Azure Services

In Part 1 of the article, I described the Funnel-based framework and various steps to improve web application security on the cloud. In this article, I will cite a real-world example of how I used the funnel-based framework and designed a Funnel-based architecture to filter and analyze malicious traffic for a web application.

The layered approach of Funnel-based Architecture is essential in providing multiple levels of security to web applications. By having multiple layers of security, each layer is responsible for detecting and blocking various attacks, making it more challenging for attackers to breach several layers at once. If an attacker bypasses one layer of defense, the other layers can still provide protection, making it harder for them to compromise the web application.

Below is an example of a multi-layered funnel that blocks malicious web requests. As each layer provides an increased level of security. The diagram illustrates 

a) The data or request flow from the browser, DNS, across edge layers, and all Azure services in the background. 

b) All layered funnel points have independent layers to choke malicious traffic by ip filtering, Geo-blocks, custom WAF rules, rate limiting, content caching, etc. 

c) Security controls at each layer or funnel point where access controls and restrictions using user authentication, authorization, audit trails, data encryption at rest, transit, via Intrusion Detection and Prevention System.

d) Deep Monitoring and Alerting of each layer and creating custom automated ways to update infrastructure and WAF rules, log analysis, auto threat detections, triggering application protection via scaling, captchas, static sites, etc. 

e) Finally, continuous improvement by providing regular security assessments and benchmarking, performing penetration testing, security awareness training, incident response planning, etc.

Here are some examples of security tools that we used to create a Funnel-based Architecture on Azure:

1. Azure Firewall: A network layer security tool that provides a managed, cloud-based firewall service to protect Azure virtual networks and resources from network-based threats.
2. Azure Front Door: A global, scalable, and secure entry point that provides routing, caching, and load balancing of web traffic at the network layer.
3. Azure Application Gateway: A layer-7 load balancer that provides WAF and SSL termination capabilities to protect web applications from application-layer attacks.
4. Marketplace WAF: An Advanced WAF that provides robust in-house web application firewall protection by securing applications against layer 7 DDoS attacks, malicious bot traffic, all OWASP top 10 threats, and API protocol vulnerabilities.
5. Azure DDoS Protection: A layer 3/4 protection service that protects against DDoS attacks by automatically mitigating them in the Azure network before they reach the targeted resource.
6. Azure Key Vault: A cloud-based service that provides secure storage and management of cryptographic keys and secrets used by cloud applications and services.
7. Azure Sentinel: A cloud-native SIEM and SOAR solution that provides intelligent security analytics and threat intelligence across the enterprise.

Securing Public Website Domain - Part 3 - DNSSEC

The third part of this series is regarding DNSSEC. Every time the browser requests a website, it goes via a DNS. Since DNS is mostly an outsourced component, we hardly ever worry about its scalability and security. On evaluating a clients website for modern and reliable internet standards for DNS security, the first error had the following information:-

Too bad! Your domain is not signed with a valid signature (DNSSEC). Therefore visitors with enabled domain signature validation, are not protected against manipulated translation from your domain into rogue internet addresses. 

What is DNNSEC?

The Domain Name System Security Extensions (DNSSEC) is a critical technology to secure the Domain Name System (DNS). DNSSEC provides a layer of authentication and integrity checking to the DNS, ensuring that the information transmitted is trustworthy and has not been tampered with. 

To enable DNNSEC, the domain registrar or the hosting provider should do that. 

Vulnerabilities due to a domain not being signed with a valid signature?

While DNSSEC has been available for many years, it is surprising that many known websites still need this signature from the DNS provider. These include major cloud providers like https://www.amazon.com, https://www.microsoft.com, and DNS providers like https://www.godaddy.com. 

As per https://internet.nl/faqs/dnssec/, some real-world incidents that DNSSEC could have prevented include

• "Cache-poisoning attack snares top Brazilian bank"
• "Eircom reveals ‘cache poisoning’ attack by hacker led to outages"
• "DNS cache poisonings foist malware attacks on Brazilians"
• "Probable Cache Poisoning of Mail Handling Domains"
• "Neither Snow Nor Rain Nor MITM... An Empirical Analysis of Email Delivery Security

One of the primary issues with not implementing DNSSEC is DNS cache poisoning. It occurs when an attacker can manipulate the DNS lookup process and direct users to a fraudulent website that looks identical to the legitimate site. It is achieved by intercepting DNS queries and responding with fake records modified to redirect the user elsewhere. DNSSEC prevents this attack by providing a mechanism to verify the authenticity of DNS records.

Another issue is DNS spoofing, which is similar to DNS cache poisoning but occurs when an attacker can inject false DNS records into the cache of a DNS resolver. It can allow the attacker to redirect traffic to malicious servers and intercept user communication. DNSSEC mitigates this by adding a layer of validation to the DNS records returned to the resolver.

Furthermore, DNSSEC can prevent man-in-the-middle (MITM) attacks by ensuring that the DNS records are authentic and have not been tampered with during transit. MITM, explained in Part-2 of this series, is when an attacker intercepts communication between the client and the server and alters the data. DNSSEC can prevent this by adding digital signatures to the DNS records.

Conclusion

Why several websites do not implement this feature may range from lack of awareness, cost factor, and risk of breakage to a complex setup.  But, the adoption of DNSSEC seems essential for ensuring the security and integrity of the DNS. 

Securing Public website domain - Part 2 - Implementing HSTS

Most of the time, the HTTP to HTTPS redirection for a website happens at the DNS, Edge, or Application layer. So by typing the naked domain (non-www) of the website, there is still a vulnerability between the user’s browser and these layers. The browser does not have the intelligence to redirect the URL to HTTPS. 

SSL ensures an encrypted connection between the browser and the website. HSTS forces web browsers to become intelligent and use an encrypted HTTPS connection at the Browser layer.

The first thing to understand is what kind of vulnerabilities are present if HSTS (HTTP Strict Transport Security) is not implemented. These are very fundamental and similar to vulnerabilities without HTTPS implemented.

Vulnerabilities without HSTS

a) Man in the Middle attack is when attackers can intercept traffic between a user's browser and the website and manipulate the connection to use an unencrypted HTTP protocol instead of a secure HTTPS protocol. This way, attackers can read or modify the content of the communication, leading to potential data breaches, session hijacking, or phishing attacks.

b) Cookie hijacking: Without HSTS, attackers can intercept or tamper with session cookies sent over an unencrypted HTTP connection. This way, attackers gain access to user accounts and steal sensitive information, such as personal data or financial details.

c) SSL stripping: Attackers can use SSL stripping attacks to devaluate the communication from HTTPS to HTTP and intercept sensitive data sent over an insecure connection. This technique is often combined with phishing attacks, where users are redirected to fake websites designed to steal login credentials or other personal information.

d) DNS hijacking: Attackers can perform DNS hijacking attacks to redirect users to a malicious server instead of the intended website. It allows the attacker to intercept and manipulate the communication between the user's browser and the fake website, leading to potential data theft or malware infection.

e) SSL certificate fraud: Without HSTS, attackers can use fraudulent SSL certificates to impersonate a legitimate website and deceive users into sharing sensitive information. It is an issue when users are not aware of the legitimate website's SSL certificate or security indicators, as they may unknowingly trust a fraudulent certificate.

Implementing HSTS

To implement HSTS, the response header just needs to be sent as part of the website's HTTP responses. The header should include the HSTS policy, which specifies how long browsers should remember to use HTTPS instead of HTTP when communicating with the website. 

A simple example of a code snippet that needs to be added to the header is as below: -

HTTP-Strict-Transport-Security: max-age=31536000; includeSubDomains

The max-age parameter specifies the number of seconds that the HSTS policy will be in effect. In this case, it is set to one year (31536000 seconds). The includeSubDomains parameter tells the browser to apply the HSTS policy to all subdomains of the website as well.

Once you've added the response header to the website's HTTP responses, any time a user visits the site, their browser will remember to use HTTPS instead of HTTP for a specified period of time, 1 year as per the above example

In summary, without HSTS, websites are vulnerable to a wide range of attacks that can lead to data breaches, identity theft, and other serious consequences. Implementing HSTS is the first crucial step in ensuring the security and privacy of website users.

Securing your public-facing website domain - Part 1

One of the unknown facts about a website or domain is how it implements proper SSL standards, leaving it insufficiently secure. Casually browsing through free online tools like https://www.ssllabs.com/ssltest/, and https://www.internet.nl/ made me realize how outdated we were from the realities of modern website security and privacy. 

Having the website as SSL does provide a secure layer that provides encryption between the web server and the browsers. However, we need to stay updated to keep us away from newer vulnerabilities.

The result of the free online tool gave our website a RED rating, and I had to take the entire report and address each item. Below are all the vulnerabilities that we started and eventually addressed. I will go through each of them in detail in subsequent posts.

1. Implement HTTP Strict Transport Security (HSTS) 

2. Implement Domain Name System Security Extensions (DNSSEC) 

3. Avoid mixed content: Ensure that all resources on your website, including images, scripts, and stylesheets, are served over HTTPS. Avoid including content from non-HTTPS sources.

4. Implement secure cookie settings: Use the Secure and HttpOnly flags on cookies to ensure that they are only transmitted over HTTPS and cannot be accessed by malicious scripts.

5. Use security headers: Implement security headers, such as Content Security Policy (CSP) and X-Frame-Options, X-Content-Type-Options, and Referer-Policy to protect against cross-site scripting (XSS) and clickjacking attacks.

6. Ensure websites have the latest TLS version enabled. Also, all old ciphers that are not supported are deleted.

7. Proper redirection from HTTP to HTTPS on the same domain in both of www. as well as for naked domains.

Tackling and Mitigating a Distributed Network attack

A Distributed Denial of Service (DDoS) attack on a public website can have severe consequences for businesses, including lost revenue, reputational damage, and even legal liability. DDoS attacks involve overwhelming a website with traffic from multiple sources, making it inaccessible to legitimate users.

There was a high-volume DDoS attack recently on one of the public sites that I am responsible for. I was in the midst of all the action around the clock and helped mitigate this issue. There was an initial glitch, but the site has been running stable for the customers, with a lot of work done behind the scenes.

We did have a finely tuned WAF layer, but this was a pure layer 7 volumetric attack from across the Globe and was purposely targeting the application layer. The attack was staggered with throughput in millions of requests per minute. Most well-known WAFs available in the market with Advanced DDoS protection and ML-based pattern detections have limitations at such high volumes.  

Some of the  best practices to prevent a DDoS attack includes

Implement DDoS protection measures

The first step in tackling a DDoS attack is to implement DDoS protection measures. These measures can include firewalls (WAF), load balancers, and intrusion prevention systems (IPS). Additionally, businesses can use cloud-based DDoS protection services, which can automatically detect and mitigate attacks. The protection needs to be done at different layers of OSI design. Also, most modern WAF products have managed rules along with advanced Bot protection that needs to be fine-tuned.  

Develop a response plan

Organizations should have a plan in place for how to respond to a DDoS attack. This kind of attack can happen at any time and a proper plan should include a response team, communication protocols, and steps to address the attack. Additionally, another key element is that teams should regularly test their plan to ensure it is effective. 

Monitor network traffic

Monitoring network traffic is critical in identifying a DDoS attack on a public website. This can be achieved by using network traffic analysis tools that can identify spikes in traffic and alert the security team in real time. Capturing logs along with ready-made queries can help identify and monitor malicious traffic. 

Block malicious traffic

One of the most effective ways to mitigate a DDoS attack is to block malicious traffic. This can be achieved by using access control lists (ACLs) and firewalls to block traffic from known malicious IP addresses or Geo Locations. Additionally, teams can use rate limiting, geo-blocks, automatic pattern detection, and URL blocks to limit the amount of traffic coming from specific sources.

Use Content Delivery Networks (CDNs)

CDNs can help to mitigate the impact of a DDoS attack by distributing traffic across multiple servers. This can help to absorb the attack and keep the website online. Additionally, CDNs can offer DDoS protection services that can automatically detect and mitigate attacks.

Tooling and Testing

Having appropriate alerts and notifications along with pattern detection can help identify malicious traffic from time to time. Performing a shadow DDoS test along with timely load testing the infrastructure can help to size the application appropriately. 

Educate users

Finally, teams should educate their users about the risks of DDoS attacks and how to prevent them. This can be achieved through regular training and awareness campaigns. Additionally, businesses can encourage users to report any suspicious activity or traffic they observe.

In conclusion, a DDoS attack on a public website can have significant consequences for businesses. There is no one solution to prevent an attack and the mitigation plan varies from application to application. But the key here is to understand the events of malicious traffic and address specific attack vectors. Also, having a WAF and continuous tuning of the WAF is required to maximize app protection without causing false positives. 

Distributed Denial of service attacks on different OSI layers - Part 3

A Distributed Denial of Service (DDoS) attack is a malicious attempt to make a network or website unavailable to its users by overwhelming it with traffic from multiple sources. These attacks can occur at different layers of the Open Systems Interconnection (OSI) model, and each layer presents different challenges for mitigation. In this article, we will discuss DDoS attacks on different OSI layers with examples.

Layer 3 (Network Layer)

DDoS attacks at the network layer target the routing of IP packets. These attacks aim to consume network bandwidth, making the targeted service unavailable to legitimate users. An example of a network layer DDoS attack is the Ping of Death attack, where an attacker sends oversized ping packets to a target, causing the system to crash or become unavailable.

Mitigation strategies for network layer DDoS attacks include implementing access control lists (ACLs) to filter out unwanted traffic and deploying routers with built-in DDoS protection features.

Layer 4 (Transport Layer)

DDoS attacks at the transport layer target the transport protocol, such as Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). These attacks aim to consume server resources, making the targeted service unavailable to legitimate users. An example of a transport layer DDoS attack is the SYN flood attack, where an attacker sends a flood of TCP SYN requests to a server, consuming server resources and causing the service to become unavailable.

Mitigation strategies for transport layer DDoS attacks include implementing rate limiting and implementing SYN cookies to prevent SYN flood attacks.

Layer 7 (Application Layer)

DDoS attacks at the application layer target the application protocol, such as HTTP or HTTPS. These attacks aim to consume server resources, making the targeted service unavailable to legitimate users. An example of an application layer DDoS attack is the HTTP Flood attack, where an attacker sends a large number of HTTP requests to a server, consuming server resources and causing the service to become unavailable.

Mitigation strategies for application layer DDoS attacks include implementing web application firewalls (WAFs) to filter out unwanted traffic, implementing rate limiting, and using CDN services to distribute the load across multiple servers.

In conclusion, DDoS attacks can occur at different layers of the OSI model, and each layer presents unique challenges for mitigation. Mitigation strategies for DDoS attacks include implementing ACLs, deploying routers with built-in DDoS protection features, implementing rate limiting, using SYN cookies, implementing WAFs, and using CDN services. By being prepared and implementing these strategies, businesses can mitigate the risks of DDoS attacks and ensure their systems remain available to legitimate users.

Fine Tuning a WAF to avoid False Positives - Part 2

 This week has been an action-packed week with some high-volume DDoS attacks on one of the web applications. We have been spending a lot of time understanding the importance of having a WAF for all our client-facing public domains. In today's Cloud architecture Web Application Firewalls (WAFs) is a crucial part of any organization's security posture. They protect web applications from DoS, DDoS, and attacks, such as SQL injection, cross-site scripting (XSS), and other malicious activities. However, WAFs need to be fine-tuned regularly to ensure they provide maximum protection without causing false positives. In this article, we will discuss some best practices we followed to fine-tune a WAF and prevent multiple attacks on our application.

1.  The first step in fine-tuning a WAF is to understand the web application it is protecting. This includes identifying the application's components, such as the web server, application server, and database. Additionally, it is essential to identify the web application's behavior, including the type of traffic it receives, the HTTP methods it uses, and the expected user behavior. Understanding the web application will help to identify which rules should be enabled or disabled in the WAF.

2. Configure WAF logging WAF logging is a critical component of fine-tuning. It allows security teams to analyze WAF events and understand which rules generate false positives. WAF logs should be enabled for all rules, and log data should be retained for an extended period, such as 90 days or more.

3. Start with a default configuration WAFs come with a default configuration that provides a good starting point for fine-tuning. Start with the default configuration and enable or disable rules as necessary. Additionally, some WAFs have pre-built templates for specific applications, such as WordPress or Drupal. These templates can be an excellent starting point for fine-tuning.

4. Test the WAF Once the WAF is configured, it is essential to test it thoroughly. The WAF should be tested with a variety of traffic, including legitimate traffic and malicious traffic. This will help identify any false positives or negatives generated by the WAF.

5. Tune the WAF Based on the results of testing, the WAF should be fine-tuned. This may include enabling or disabling rules, adjusting rule thresholds, or creating custom rules to address specific attack vectors. Additionally, WAFs may have machine learning or AI capabilities that can help to reduce false positives.

6. Monitor the WAF After fine-tuning, the WAF should be monitored regularly to ensure it is providing maximum protection without causing false positives. WAF logs should be analyzed regularly, and any anomalies should be investigated immediately.

In conclusion, fine-tuning a WAF is a critical component of any organization's security posture. It requires a thorough understanding of the web application, careful configuration, and extensive testing. Additionally, WAFs should be regularly monitored and fine-tuned to ensure they provide maximum protection without generating false positives. By following these best practices, organizations can ensure their WAFs provide maximum protection against web application attacks.

Choosing the right WAF for your Enterprise wide Applications - Part 1

 This is a multi-part series on how to protect a web application using a WAF. To start with this part explains how to choose the right WAF for an Enterprise-wide web application. 

Web Application Firewalls (WAFs) are a crucial part of any organization's security infrastructure, protecting their web applications from cyber threats. With so many WAFs available in the market, choosing the best one can be a daunting task. I have been reading Gartner reports, along with performing POCs and trying to choose a tool that best suits the client, Below are the different criteria to consider when choosing the best WAF for your organization.

Security Features

When choosing a WAF, the first and most crucial criterion is its security features. The WAF should have strong protection against various cyber threats, including  DDoS, SQL injection, cross-site scripting (XSS), and other common OWASP web application vulnerabilities. Additionally, the WAF should offer threat intelligence services that provide continuous updates on the latest security threats and attack patterns.

Customization and Configuration

The WAF should be easily customizable and configurable to suit an organization's specific security needs. It should allow for custom rule creation, custom signature creation, and other customization options that allow you to fine-tune the WAF's security policies according to an organization's requirements. The ability to perform extensive rate-limiting or geo-blocking features is some of the common requirements of a WAF.

Performance and Scalability

The WAF should offer excellent performance and scalability, especially for high-traffic websites or applications. It should be able to handle a large number of concurrent connections without compromising performance or introducing latency. Additionally, the WAF should be scalable, allowing an organization to expand and grow without requiring a complete WAF overhaul. In simple words, it should not be a single point of failure. 

Integration with Existing Security Infrastructure

The WAF should be easy to integrate with the organization's existing security infrastructure, including firewalls, intrusion detection and prevention systems (IDPS), and Security Information and Event Management (SIEM) systems. This integration should also allow for seamless communication and collaboration between the different security systems, providing a holistic approach to security.

Compliance and Regulations

The WAF should comply with various regulatory standards, such as the Payment Card Industry Data Security Standard (PCI DSS) or the General Data Protection Regulation (GDPR). Additionally, the WAF should be auditable, providing detailed logs and reports allowing compliance verification and audit trails.

Ease of Use and Management

The WAF should be easy to use and manage, with a user-friendly interface that allows security administrators to monitor and manage the WAF effectively. Additionally, the WAF should offer automation and orchestration capabilities, allowing for seamless deployment and management of the WAF across different environments.

In conclusion, choosing the best WAF for an organization requires careful consideration of various criteria, including security features, customization and configuration, performance, and scalability, integration with existing security infrastructure, compliance and regulations, and ease of use and management. Selecting the right WAF that meets an organization's specific security needs can protect web applications from various cyber threats and ensure your organization's continued success.