\section{Infrastructure Requirements and Architectural Justification}

Before describing the Sicuranext infrastructure, it is important to explain the requirements that shaped its design. Since Sicuranext is a managed WAAP (Web Application and API Protection) system, the infrastructure must meet several technical and operational needs:

\begin{itemize}
  \item \textbf{Complete TLS termination and inspection:} Sicuranext must decrypt incoming traffic to apply WAF rules, plugins, and logging. TLS termination must be secure, compliant with standards, and able to scale automatically during periods of high traffic
  
  \item \textbf{Elastic scalability and fault tolerance:} The system should adapt automatically to changes in traffic, without manual intervention. It must include automatic scaling, health checks, and failover mechanisms to guarantee availability
  
  \item \textbf{Layered security:} Security rules must act at different points of the HTTP lifecycle. L7 protections (WAF, rate-limiting, anomaly detection) must be enforced before forwarding requests, while the outgoing response must also be inspected to avoid data leaks
  
  \item \textbf{Performance and latency constraints:} Security should not create excessive delays. Cache mechanisms and geographically distributed entry points should reduce response time and avoid unnecessary computation
  
  \item \textbf{Audit and traceability:} Every request and response must be logged with enough context to allow forensic analysis, behavior tracking, and debugging. Logs should be indexed, searchable, and usable with analytical tools
  
  \item \textbf{Vendor independence and sustainability:} Cloud services simplify operations, but the infrastructure must remain portable. Sicuranext must be able to reduce cloud dependency and migrate components without redesigning the entire system
\end{itemize}
These requirements lead to a WAAP architecture based on Kong Gateway, strengthened by ModSecurity, and supported by distributed caching and centralized logging. Each element balances security, performance, and operational cost.

\subsection{Infrastructure Overview}

The diagram below shows the main components of the infrastructure and the flow of requests and responses:

\begin{figure}[H]
  \includegraphics[width=1\textwidth]{images/infra}
  \caption{Sicuranext Infrastructure}
  \label{fig:sicuranext-infrastructure}
\end{figure}
\noindent
Assuming Sicuranext protects the website \textit{example.com}, the request and response flow is as follows:

\begin{itemize}
  \item When a user visits \textit{example.com}, the request is received by the Amazon Elastic Load Balancer (ELB). ELB distributes traffic and manages TLS certificates to decrypt it. \\

  ELB was chosen for three main reasons. First, AWS handles load balancing, scaling, and health checks. This allows the infrastructure to scale without extra work from Sicuranext. \\
  Second, ELB supports AWS Global Accelerator, which provides static IPs distributed across more than 20 AWS regions. Requests are served from the closest region, reducing latency. \\
  Third, AWS Certificate Manager (ACM) integrates with ELB and allows the creation of trusted TLS certificates at no additional cost.
  
  \paragraph{Alternatives to ELB:}
  Sicuranext could use Kong Gateway, OpenResty, or Nginx for load balancing, but these options would require more engineering and maintenance. The company plans to replace ELB with Kong Gateway in the future to reduce AWS dependency and support smaller clients.

  \paragraph{Alternatives to ACM:}
  Let's Encrypt could generate certificates and import them into ACM or use them directly in Kong. Sicuranext plans to use Let's Encrypt with Kong to automate ACME challenges and manage TLS certificates per service.

  \item After TLS termination, the decrypted request is forwarded to the WAAP layer, where Kong Gateway operates. Kong integrates the ModSecurity WAF with the OWASP Core Rule Set (CRS) and custom rules. \\

  ModSecurity is one of the few open-source WAFs that reliably work with Nginx. Other open-source options such as Coraza still show stability issues. Service-based solutions such as AWS WAF exist, but they do not offer the flexibility or features required by Sicuranext.

  \item Kong Gateway also supports plugins. In this setup, one plugin blocks requests from malicious Autonomous System Numbers (ASNs). An AS controls a group of IP address ranges. Blocking individual IPs is easy to bypass since attackers can switch to another IP from the same AS. Blocking the whole AS is more effective, but it must be used carefully to avoid affecting legitimate users. Only ASes with a history of abuse should be blocked.

  \item If the request is valid, it is forwarded to the protected application (\textit{example.com}). The application generates a response.

  \item On the return path, ModSecurity inspects the response again. If the content is static, it may be stored in AWS ElastiCache (Redis) to improve performance for future requests. \\

  Sicuranext chose Amazon ElastiCache to deploy a managed Redis cluster, reducing operational complexity. In the future, the company plans to host its own Redis cluster to lower AWS costs.

  \paragraph{Alternatives:}
  Other possible technologies include Memcached, KeyDB, or Apache Cassandra. Redis was selected because of its maturity and strong Lua module support in OpenResty.

  \item When a second request for the same content is made, ModSecurity still performs its checks, but cached content may bypass some Kong plugins, such as the ASN filter. This improves performance while maintaining a reasonable level of security.

  \item All requests and responses are logged asynchronously and stored in Elasticsearch. Sicuranext uses Elasticsearch for storage and Kibana for visualization. Other valid alternatives include OpenSearch, Apache Solr, or MongoDB.
\end{itemize}
The dataset for analysis will be downloaded from Elasticsearch. Blocking based on ASNs will be important during the preprocessing described in Chapter~\ref{implementation-approach}.

\subsection{Critical Considerations on Architectural Semantics}

Even though the system meets the requirements, its behavior is more complex than a simple reverse proxy. Multiple controls are applied during the request lifecycle, which leads to some important consequences:

\begin{itemize}
  \item \textbf{Security vs performance:} Applying CRS rules on both incoming and outgoing traffic increases processing time. This is intentional, as Sicuranext prioritizes preventing data leaks over small latency gains

  \item \textbf{ASN-based blocking:} Blocking entire AS ranges is a broad measure. It is effective against botnets and abuse networks, but it relies on the reputation of the provider and may affect legitimate users. This shifts the model from per-request evaluation to evaluation based on origin networks

  \item \textbf{Cache precedence:} Cached responses may bypass certain plugins. This is safe for static assets, but risky for dynamic data such as tokens or user-specific information. Incorrect caching policies can leak data or hide signals used in anomaly detection

  \item \textbf{Cloud-dependent control plane:} By delegating TLS termination and scaling to AWS, the system adopts AWS routing, certificate lifecycle, and cost models. These simplify operations but delay full migration to a portable, Kong-centric infrastructure
\end{itemize}
The selected architecture is therefore a compromise between strict isolation, practical operation, and maintainability. Its layered design comes from real attack scenarios observed in Sicuranext deployments.

\subsection{Current Architectural Flaw: Lack of Session Aggregation}

A major limitation of the current system is the absence of session aggregation. Sicuranext processes every HTTP request as an independent event, without linking multiple requests to the same user, IP, or browser session. As a result, the architecture has a flat perception of traffic. \\[6pt]
This creates several practical issues:

\begin{itemize}
  \item \textbf{Detection quality:} Many real-world attacks are not visible in a single request. They appear only when multiple requests are analyzed as a sequence. Without session aggregation, patterns such as probing, credential stuffing, or slow brute-force attacks remain hidden

  \item \textbf{Rate-limiting accuracy:} Current limits operate per request or per IP. They do not take into account shared sessions behind proxies, VPNs, or NAT environments. This can create false positives for large corporate networks or shared mobile carriers

  \item \textbf{User profiling:} Logging focuses on individual events. There is no unified representation of a "user episode". This prevents behavioral analysis and limits the ability to detect anomalies that evolve over time, such as unusual navigation paths or repeated access to sensitive endpoints

  \item \textbf{Operational tooling:} Analysts must reconstruct attacks manually by correlating logs. This increases investigation time, introduces ambiguity, and makes incident response slower and more error-prone
\end{itemize}
In short, the system protects request boundaries but does not understand user intent or attack progression. Introducing session aggregation would allow Sicuranext to view traffic at a higher level of abstraction, enabling more precise rate control, better anomaly detection, and more informative threat models.
