Friday, April 21, 2023

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.




Sunday, March 26, 2023

Role of a Solution Architect in Modern Organizations

This week came across a topic of how the market lacks good Solutions Architects and how the role of a Solution Architect is often misused in the IT industry, especially with the advent of cloud certifications. With Agile Organizations, the role of the Solution Architect also seems to be diminishing. It has also led to organizations creating other different Architecture titles doing specific tasks.

Having played the role of Solution Architect for about a decade now, I feel the title typically requires years of experience designing and implementing complex software solutions in different projects and domains. 

Solution Architect Mindset

It involves a deep understanding of Business requirements, Technical constraints, Architecture Design and Principles, and staying up-to-date on Emerging Technologies. Solution Architects must also possess strong communication and leadership skills to work effectively with Stakeholders, Developers, Business Architects, and other team members.

With the rise of cloud certifications, many individuals get the title of Solution Architect without the necessary experience and expertise. It is probably the main reason that has led to a proliferation of Solution Architects who lack the required skills to design and implement complex solutions. 

Also, Organizations do not clearly define the roles and responsibilities of a Solution Architect. The role has evolved in the past decade with emerging technologies and ways of working, but the fundamentals have always remained the same. 

By definition, a Solution Architect's role is to design and oversee the implementation of software solutions that meet business requirements. To think like a modern Solution Architect, for any project, one has to mold in the below five areas. 



a) Understanding Business Requirements

b) Evaluate the requirements based on the abilities

c) Define the Architecture principles of the solution

d) Define the Architecture and design the overall solution

e) and Participate in the development of end-to-end solution


Conclusion

In conclusion, to have a successful Solution Architect mindset, one needs to ensure they have the problem-solving ability, love having strategic thinking proficiency, have proper communication to collaborate, and have the urge for continuous learning. 


Wednesday, March 15, 2023

Choosing between Azure function App or Azure App Service for your application

This week for building a client-facing mobile app, I had a choice of using either a PaaS or a Serverless implementation on Microsoft Azure This week to create a client-facing mobile application, I had a choice of using either a PaaS or a Serverless implementation on Microsoft Azure Cloud. 


One of the development teams wanted to use an Azure Function, and the other wanted to go with the simple Azure App service plan. It was not the first use case wherein I had to choose between the two services. Serverless technology has evolved and is no longer used just for independent worker-based functionalities. I have used it for several different use cases, including building a part of an e-commerce site running purely on serverless technology. 


I had to take in all the pros and cons and take a logical view to choose between the two. 


Step 1


I started to understand the abilities based on the granularity of the business requirements


What are the requirements?

a.    Business logic - Does the application require a full-fledged middleware with data and business logic?

b.   Lightweight system - Is the application more of a lightweight web API system?

c.    Expected Traffic - What will be the dedicated traffic towards the application?

d.   Code complexity - Does the application require a small piece of code or function for every request?

e.    Performance - Does the application require quick responses?

f.    Scalability- What are the scalability requirements?

g.   Ease of Development/Deployment - What is the level of ease of deployment and development?

h.   Security - What are the security requirements?

i.     Cost - What are the budget or cost requirements?

j.     Application Design - Complexity of the application design?

k.   Governance - Is governance an issue? Are there multiple teams owning and deploying modules to production regularly?

l.     Maintenance - Who will maintain the application, and what are the SLAs?

m. Redundancy- What are the application redundancy requirements?

n.   Technology - Is there a technology restriction?

o.   Learning curve – Technology adaption and learning curve requirements?



Step 2: 


As the requirements are understood, the next step is to understand and map the capabilities and challenges and compare the two services in the context of the development teams.


The Azure function has Three plans -> 1. Consumption 2. Premium, and 3. App service plan


a.    Plan fitment: The consumption plan has cold start issues, less security, and less cost. So, this has to be considered before going with this plan for a production-ready product. Neither cold starts nor security is an issue in building applications with App service.

b.   Cost Issue: Premium and App service plans can avoid cold starts. They also provide better security (with VNET) but at a higher cost. The cost is the same as the App service plan. 

c.    Complexity: With Azure functions, if several moving parts are created, and limited people are maintaining it, then it can get complex. 

d.   Governance issue in the future: If we are building independent decentralized functions, standardization can be an issue in the future.

e.    Latency: If a function in the future needs to wait for another function to execute, then the latency becomes an issue and complexity as well.

f.    Future Business logic: If writing business logic requires building several functions or classes, then an app service integration will be the way to go.

g.   Learning curve and support: It can become a learning curve issue for someone new to maintain and support the applications with multiple functions.


Concluding, both services offer several similar features, In our case, the application was simple and had some future business requirements that required processing with no end-user impact, so the App Service seemed to be an apt fit. However, the choice could be totally different for another set of requirements. 


                                                     

Thursday, March 9, 2023

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


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. 

Tuesday, March 7, 2023

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.


Building Microservices by decreasing Entropy and increasing Negentropy - Series Part 5

Microservice’s journey is all about gradually overhaul, every time you make a change you need to keep the system in a better state or the ...