An architectural evaluation of identity impersonation across the network, application, and biometric layers, examining protocol design flaws, defense mechanisms, and implementation limits.

Identity impersonation remains one of the most pervasive threat vectors in modern cybersecurity. At its core, spoofing occurs when an attacker deliberately falsifies identity information within digital communications to impersonate a trusted entity. By manipulating identity parameters across both network- and application-level protocols, malicious actors bypass traditional perimeter defenses, gain unauthorized access to systems, and execute multi-stage attacks, including phishing, Denial-of-Service (DDoS), Man-in-the-Middle (MITM) interception, and financial fraud.

The persistent effectiveness of spoofing attacks stems from a fundamental design reality: many core Internet protocols were engineered primarily for performance, scalability, and operational reliability, frequently omitting built-in authentication mechanisms. As a result, these protocols inherently trust the identity claims contained in packet headers, message envelopes, and signaling fields.

While modern cryptographic standards and defensive frameworks — such as DNSSEC, DMARC, BCP 38, and STIR/SHAKEN — exist to mitigate these risks, their effectiveness is regularly undermined by partial adoption, legacy system backwards compatibility, configuration mistakes, and human trust factors.

The Architecture of Digital Deception: Layer-Based Classification

Spoofing attacks target specific operational layers of the computing and networking stack. Categorizing these techniques by their targeted layer provides a structured foundation for evaluating defensive capabilities and structural protocol vulnerabilities.

+-----------------------------------------------------------------------------------+
|                        LAYER-BASED CLASSIFICATION TAXONOMY                        |
+-----------------------------------------------------------------------------------+
| 1. Biometric / Presentation Layer                                                 |
|    - Face Photo/Video Replay • Fake Fingerprints • AI Voice Synthesis • Iris Printouts|
+-----------------------------------------------------------------------------------+
| 2. Application Layer (Layer 7)                                                    |
|    - Email Header Forgery • DNS Cache Poisoning • SMS Sender ID • Caller ID Spoofing  |
+-----------------------------------------------------------------------------------+
| 3. Network & Link Layers (Layers 2 & 3)                                           |
|    - IP Source Falsification (L3) • ARP Cache Poisoning (L2) • MAC Address Cloning    |
+-----------------------------------------------------------------------------------+

Figure 1: Layer-Based Classification Taxonomy of Digital Identity Spoofing

1. Network-Layer Spoofing (Layers 2 & 3)

• IP Spoofing: Alters packet source headers to hide origin nodes or redirect response traffic.
• ARP Spoofing: Corrupts local Layer-2 address resolution tables to map an attacker’s MAC address to a legitimate gateway IP address.
• MAC Spoofing: Modifies the physical media access control address assigned to a network interface card to bypass hardware filtering or hijack active sessions.

2. Application-Layer Spoofing (Layer 7)

• Email Spoofing: Manipulates SMTP message headers to impersonate organizational senders.
• DNS Spoofing: Injects fraudulent mapping entries into domain name resolvers to misdirect client traffic.
• SMS & Caller ID Spoofing: Modifies originating telephony identifier attributes across SS7 networks or VoIP gateways.

3. Biometric & Physical-Layer Spoofing (Presentation Attacks)

• Presentation Attacks: Subverts hardware sensors (e.g., facial recognition cameras, optical fingerprint readers, iris scanners) using physical or digital artifacts like 3D masks, silicone molds, high-resolution photographs, or AI-generated synthetic voice signals.
• GPS Spoofing: Broadcasts high-power forged Global Navigation Satellite System (GNSS) signals to override genuine satellite transmissions and alter calculated spatial coordinates.

Technical Breakdown: Attack Mechanics and Real-World Evidence

1. IP Spoofing

IP spoofing occurs when an attacker creates and sends IP packets containing an altered, fake source address field. Because standard Internet Protocol routing relies primarily on destination addresses to deliver traffic, any device connected to the network can insert arbitrary source values into custom packets.

[Attacker Node]               [Reflector / Server]               [Victim Target]
  (IP: 1.1.1.1)                   (IP: 2.2.2.2)                     (IP: 3.3.3.3)
        |                               |                                |
        |--- 1. Request Packet -------->|                                |
        |    Src: 3.3.3.3 (SPOOFED)     |                                |
        |    Dst: 2.2.2.2               |                                |
        |                               |--- 2. Amplified Response ----->|
        |                               |    Src: 2.2.2.2                |
        |                               |    Dst: 3.3.3.3 (FLOODED)      |

Figure 2: IP Spoofing & Reflection DDoS Amplification Flow

If a target system (2.2.2.2) processes a packet from an attacker (1.1.1.1) claiming to originate from 3.3.3.3, the response is routed to 3.3.3.3. Attackers leverage this mechanism to mask their identity and execute reflection or amplification Distributed Denial-of-Service (DDoS) attacks.

Real-World Case: In the 2018 GitHub DDoS attack, which reached a peak volume of 1.35 Tbps, threat actors sent spoofed requests to thousands of publicly exposed Memcached servers. By configuring GitHub’s IP address as the false source address, the attackers caused the Memcached servers to send amplified response floods directly to GitHub’s infrastructure.

2. ARP Spoofing (ARP Cache Poisoning)

Address Resolution Protocol (ARP) translates Layer-3 IP addresses into Layer-2 MAC addresses within a local area network (LAN). Because ARP is stateless and completely unauthenticated, network endpoints accept and process unsolicited ARP reply packets.

[Victim System]              [Attacker (MITM)]               [Default Gateway]
IP: 192.168.1.10             IP: 192.168.1.50                 IP: 192.168.1.1
MAC: AA:AA:AA...             MAC: BB:BB:BB...                 MAC: CC:CC:CC...
       |                            |                                |
       |<-- Fake ARP Response ------|                                |
       |    "192.168.1.1 is BB:BB"  |                                |
       |                            |------ Fake ARP Response ------>|
       |                            |       "192.168.1.10 is BB:BB"  |
       |                            |                                |
       |==== All Traffic Routed Through Attacker (Interception) =====|

Figure 3: ARP Cache Poisoning Man-in-the-Middle Attack Architecture

An attacker broadcasts forged ARP responses stating: “IP X is at MAC M”. When a victim endpoint updates its internal ARP table with this fraudulent mapping, all outbound network traffic intended for the local default gateway is routed through the attacker’s network interface card, establishing a Man-in-the-Middle (MITM) condition.

Real-World Case: ARP spoofing is widely executed in unencrypted or open public Wi-Fi environments to intercept unencrypted traffic, enabling attackers to harvest plain-text session cookies and user credentials passing over the local segment.

3. DNS Spoofing (DNS Cache Poisoning)

DNS cache poisoning alters the IP address mappings cached within a recursive DNS resolver. Because the User Datagram Protocol (UDP) lacks connection handshake states, attackers send malicious response packets that predict and match the transaction IDs of recent queries.

[Client User]              [Recursive DNS Resolver]           [Attacker Server]
       |                               |                               |
       |--- 1. Query: bank.com ------->|                               |
       |                               |<-- 2. Inject Forged Record ---|
       |                               |    (bank.com = 6.6.6.6)       |
       |<-- 3. Returns Spoofed IP -----|                               |
       |    (6.6.6.6)                  |                               |
       |                                                               |
       |================ Misdirected to Phishing Site ================>|

Figure 4: DNS Cache Poisoning Sequence

When successful, queries for legitimate domain names resolve to an attacker-controlled IP address instead of the genuine destination server.

Real-World Case: During the 2018 MyEtherWallet domain hijacking incident, attackers compromised DNS resolution to secretly redirect domain traffic to a replica phishing interface. Users attempting to log in unknowingly exposed their private cryptographic keys, resulting in the theft of approximately $152,000 in cryptocurrency.

4. MAC Spoofing

MAC spoofing involves changing the assigned hardware address of a network interface card using tools like macchanger or Ettercap. This technique allows an attacker's computer to impersonate a legitimate host already authorized on the switch or access point.

Real-World Case: During the 2016 Bangladesh Bank cyber attack, attackers spoofed the MAC address of an authorized employee workstation to gain elevated internal access, compromise the bank’s SWIFT system infrastructure, and initiate illegal financial transfers.

5. Email Spoofing

The Simple Mail Transfer Protocol (SMTP) lacks intrinsic sender verification protocols. As a result, senders can specify arbitrary values within header fields, such as the From: and Reply-To: directives.

+-----------------------------------------------------------------------------------+
|                        STRUCTURE OF A FORGED EMAIL HEADER                         |
+-----------------------------------------------------------------------------------+
| Envelope Sender : attacker@external-domain.com  (Actual TCP Routing Origin)       |
| From Header     : CEO Boss <ceo@company.com>    <-- SPOOFED (Displayed to User)   |
| Reply-To Header : ceo-phish@external.com        <-- ATTACKER INBOX (Captures Reply)|
| Subject         : URGENT: Executive Wire Transfer Required                        |
+-----------------------------------------------------------------------------------+

Figure 5: Structure and Annotation of a Forged Email Header

Attackers exploit this by sending emails that display a trusted contact or corporate domain in the client inbox, while directing responses to an external inbox.

Real-World Case: In 2015, executive impersonation via email spoofing misled corporate staff into making unauthorized wire transactions, accumulating total corporate losses of $17.2 million.

6. SMS and Caller ID Spoofing

Telephony protocols lack native message-origin authentication. Attackers exploit SS7 network vulnerabilities or unverified VoIP/SMS web gateways to forge sender IDs, causing incoming messages or phone calls to appear as though they originate from trusted financial institutions or service providers.

Real-World Case: Smishing campaigns targeting mobile users in the Philippines impersonated the telecommunications brand “Globe”. Fake SMS alerts warned recipients of account issues and directed them to credentials-harvesting web forms.

7. GPS Spoofing

GPS spoofing involves generating artificial Global Navigation Satellite System (GNSS) signals using terrestrial transmitters. By gradually increasing the signal strength relative to legitimate satellite signals, the spoofer forces receiver modules to lock onto fake Pseudorandom Noise (PRN) codes, corrupting spatial and timing calculations.

Real-World Case: Researchers from the University of Texas demonstrated that broadcast GPS spoofing signals could hijack the automatic navigation system of an $80 million superyacht in open waters, altering its course without triggering system alarms.

8. Biometric Spoofing (Presentation Attacks)

Biometric spoofing subverts physical authentication sensors using cloned biological physical characteristics:

• Facial Recognition: High-definition printed photographs, video playback on screens, or 3D masks.
• Fingerprint Recognition: Artificial molds (“gummy fingers”) produced using silicone or gelatin.
• Voice Recognition: AI-synthesized deepfake audio models or recorded samples of a victim’s voice.
• Iris Recognition: High-resolution printed iris images positioned in front of infrared scanners.

Deep-Dive: Defensive Frameworks and Structural Limits

Network-Layer Defenses

• Ingress/Egress Filtering (BCP 38 / RFC 2827): Edge routers validate packet source IP addresses. Ingress filtering drops incoming traffic carrying source IPs outside authorized ranges; egress filtering blocks outgoing traffic with source IPs that do not belong to the internal network address space.
• Unicast Reverse Path Forwarding (uRPF): Edge routers check whether an incoming packet’s source IP matches the best reverse path route in the Routing Information Base (RIB). If the interface check fails, the packet is discarded.
• Dynamic ARP Inspection (DAI): Managed switches intercept and validate all ARP messages against a trusted database built via DHCP Snooping. Unmatched ARP packets are dropped before they can poison local caches.

Application-Layer Defenses

• SPF, DKIM, and DMARC:
• SPF (Sender Policy Framework): Publishes authorized sending IP addresses in DNS records.
• DKIM (DomainKeys Identified Mail): Uses public-key cryptography to digitally sign outbound messages, verifying content integrity.
• DMARC: Connects SPF and DKIM through DNS policies. Domain owners can set enforcement policies (p=reject or p=quarantine) and receive automated abuse reports.
• DNSSEC (DNS Security Extensions): Cryptographically signs DNS resource records using private keys within authoritative zones. Resolvers validate responses against published public keys, preventing cache poisoning.
• STIR/SHAKEN: Uses digital certificates to authenticate caller ID numbers across IP-based telephony networks. Originating providers sign the call metadata, and receiving carriers verify the signature before displaying a verified caller status to the user.

Physical & Biometric Defenses

• Presentation Attack Detection (PAD / Liveness Detection): Biometric sensors evaluate physiological characteristics to confirm live targets. Mechanisms include measuring micro-blood flow, sub-surface light reflection, dynamic pupil responses, 3D depth mapping, or involuntary eye blinking.
• GPS Cryptographic Verification & Sensor Fusion: Systems implement encrypted GNSS signals (e.g., Galileo OS-NMA) alongside multi-sensor fusion algorithms, cross-referencing GPS data with Inertial Navigation Systems (INS) and atomic clocks to detect position anomalies.

Comparative Analysis of Countermeasures

Critical Evaluation: Edge-Case Failures and Structural Gaps

A critical analysis of cybersecurity research highlights two major systemic challenges in modern spoofing defenses:

1. The “Composition Kills” Phenomenon (Chen et al.)

Research demonstrates that adhering to security standards like DKIM and SPF is insufficient if downstream components — such as secure email gateways, spam filters, and Mail User Agents (MUAs) — parse and render message headers differently.

When an intermediate server interprets message boundaries or header fields differently from the final client email software, an attacker can craft payloads that pass SPF and DKIM validation checks while displaying a completely forged address to the end user. This structural disconnect highlights that adding security extensions on top of insecure protocols fails if underlying parsing logic remains inconsistent across software implementations.

2. STIR/SHAKEN Implementation Realities

Despite regulatory mandates requiring telephony providers to implement the STIR/SHAKEN framework, operational data reveals ongoing gaps in call authentication coverage. Because STIR/SHAKEN relies on trusted Certificate Authorities (CAs) managed by telecommunication providers, deployment costs remain a barrier for smaller operators.

Furthermore, because STIR/SHAKEN is primarily deployed across North American IP networks, international calls entering via legacy TDM or non-compliant foreign gateways bypass cryptographic signing. Attackers exploit these fallback pathways to route unverified spoofed calls through legacy interconnects, bypassing modern authentication controls.

Key Takeaways for Security Practitioners

• Protocols Inherently Trust Identifiers: Core network and communication protocols (IP, ARP, SMTP, DNS, SS7) were created without identity verification mechanisms, making identity validation necessary at higher layers.
• Layered Defense is Mandatory: Single-point security controls are easily bypassed. Effective spoofing defense requires combining perimeter filtering, cryptographic protocol extensions, host-level monitoring, and strict access controls.
• Configuration and Parsing Alignment Matter: Deploying cryptographic protocols (e.g., DKIM, SPF, DNSSEC) is ineffective if edge security devices and user-facing clients parse header standards inconsistently.
• Legacy Compatibility Weakens Security: Attackers actively exploit backward-compatibility features in communications networks (e.g., non-STIR/SHAKEN international phone routes) to bypass modern security mechanisms.
• Enforcement Policies Are Required: Defensive frameworks like DMARC and BCP 38 only prevent spoofing when configured with strict enforcement policies (e.g., DMARC set to p=reject).

Conclusion

Spoofing attacks have evolved from basic network header manipulation to complex campaigns targeting identity verification systems across every layer of the computing stack. While the cybersecurity community has developed robust cryptographic defenses — such as DMARC for email, Dynamic ARP Inspection for local networks, DNSSEC for domain resolution, and STIR/SHAKEN for telephony — their real-world effectiveness remains limited by partial adoption, inconsistent software parsing logic, and the need to support legacy infrastructure.

Addressing these vulnerabilities requires moving away from implicit protocol trust and adopting Zero Trust architecture principles, where every packet, query, and message envelope is continuously validated. Until cryptographic enforcement policies are universally applied, spoofing will remain a primary tactic for cybercriminals exploiting weak points in digital communications.

References

1. Aardvark, A.T.3., 2017. How to prevent internal email spoofing in Exchange.
2. Beschokov, M., What is DNS Spoofing and Cache Poisoning? Wallarm.
3. Chen, J., Paxson, V. and Jiang, J., 2025. Composition Kills: A Case Study of Email Sender Authentication.
4. Grue, R., 2020. What is DNSSEC and Why Is It Important?
5. Meghana, J.S., Subashri, T. and Vimal, K.R., 2017. A survey on ARP cache poisoning and techniques for detection and mitigation, pp. 1–6.
6. Nemeroff, B., The Robocalling Crisis: How We Got Here, Numeracle.
7. Schuckers, S.A.C., 2002. Biometric Spoofing and Anti-Spoofing Measures. Information Security Technical Report, 7 (4), pp. 56–62.
8. Teodoro, N.M., 2025. Biometric spoofing isn’t as complex as it sounds. Help Net Security.
9. Vlajic, N., Chowdhury, M. and Litoiu, M., 2019. IP Spoofing In and Out of the Public Cloud: From Policy to Practice. Computers, 8 (4), p. 81.

Modern organisations don’t run on a single network anymore. A branch office, a factory floor, and a corporate headquarters are all expected to talk to each other and to the public internet without interruption — and the moment one link in that chain breaks, whole departments lose connectivity. This piece walks through two connected pieces of work: first, a systematic diagnosis and repair of a simulated enterprise network built in Cisco Packet Tracer, where several independent faults had knocked out cross-site and internet connectivity; and second, a technical review of the tools and frameworks organisations are turning to as they move workloads into hybrid and multi-cloud environments — Secure Access Service Edge (SASE), Cloud-Native Application Protection Platforms (CNAPP), and Confidential Computing.

The two halves share a common thread: security and reliability both come down to configuration discipline, whether that’s a missing ip nat inside statement on a router interface or a gap in a compliance control mapping. What follows is a rewrite of that project's documented findings, evidence, and conclusions — nothing added, nothing exaggerated.

Background

Enterprise networks increasingly rely on a mix of physical sites — branches, factories, headquarters — stitched together through a shared cloud or WAN backbone. When that backbone experiences even small misconfigurations, the effects cascade: hosts can’t reach their gateways, address translation breaks down, or routing protocols simply never advertise a subnet. Diagnosing these problems requires working methodically through the OSI model, from physical link state up through routing and NAT.

At the same time, the underlying protocols used for everyday business communication — email, file transfer, remote device management — carry very different security guarantees. Some, like FTP and Telnet, were never designed with encryption in mind. Others, like SSH, were built specifically to close that gap. Understanding why one protocol leaks credentials in plaintext while another doesn’t is a foundational skill that connects directly to the higher-level cloud security architecture discussed later in this article.

Finally, as workloads move into hybrid and multi-cloud environments, the attack surface changes shape entirely. Traditional perimeter-based thinking doesn’t map cleanly onto distributed, containerised, and ephemeral infrastructure. New categories of tooling — SASE, CNAPP, Confidential Computing — have emerged specifically to address that shift, but each comes with its own trade-offs and blind spots.

The Environment

The simulated corporate infrastructure used a hybrid star-mesh design built around a central Network Cloud, connecting seven PCs to a public internet server at 203.0.113.27 (www.netacad.pt). The setup spanned multiple physical/logical boundaries: remote branch locations, a factory floor, and a central headquarters, all tied together through the shared cloud infrastructure.

The addressing scheme across the seven hosts was as follows:

Before any repairs began, this environment had suffered widespread communications degradation — a mix of interface activation issues, missing NAT statements, incomplete host configuration, and OSPF routing mismatches, all of which combined to break internal routing and cut off external internet visibility.

Purpose: Recreate the network topology so readers can visually follow which host maps to which fault domain.
Elements: Central “Network Cloud” node; Internet Server (203.0.113.27 / www.netacad.pt); PC1 through PC7 connected via a star pattern to the cloud; Hub router; Branch-2 router; Factory router (only these devices are explicitly named in the source material).
Layout: Internet server at the top, Network Cloud in the centre, PCs radiating outward — mirroring the original topology map.
Style: Clean, professional, modern, minimal, suitable for Medium, no unnecessary decoration.

Methodology

The network-repair work followed a consistent diagnostic pattern: a ping matrix was run from every host to its local peers and to the external web server, isolating which hosts could reach which segments. Once a fault domain was identified, the relevant device’s running configuration was audited using Cisco IOS privileged EXEC commands (show ip interface brief, show ip ospf interface, show running-config), the specific misconfiguration was corrected, and the fix was verified with a follow-up ping or traceroute.

For the communications exercise, network traffic was intercepted using a packet-sniffing tool referred to in the assignment as the “Cyber Criminals Sniffer,” which allowed direct visual comparison between plaintext protocols (FTP, Telnet) and an encrypted protocol (SSH).

The cloud security portion of the work took the form of a critical literature review, structured around three research questions covering supply-chain protection, compliance-framework alignment, and the suitability of existing risk-assessment methodologies for cloud-native workloads. This is a desk-based literature synthesis, not a hands-on lab test — a distinction worth keeping in mind as we get into that section’s findings.

Technical Analysis

A. Network Fault Isolation and Remediation

The initial ping matrix identified four distinct fault domains:

1. PC1 could reach other local subnets (PC2, PC4) but could not reach the external internet server — pointing to a NAT problem on the perimeter link.
2. PC3 couldn’t even reach its own default gateway (192.168.4.1), isolating it entirely from the rest of the network.
3. PC5 couldn’t leave its local subnet at all; an audit showed its default gateway wasn’t configured.
4. PC6 and PC7 had no external connectivity whatsoever, suggesting a routing adjacency failure between the Branch-2 router and the core Hub.

PC1 — Missing NAT statement. A traceroute from PC1 showed packets successfully reaching the Hub’s perimeter interface (192.168.0.1) before dropping with repeated timeouts. Auditing the Hub’s running configuration revealed that while Serial0/1/1, Serial0/2/0, and Serial0/2/1 all carried the ip nat inside command, Serial0/1/0 — the interface connecting directly to Branch 1 — lacked it entirely. Traffic arriving from the Branch 1 LAN had no matching source translation entry, so it was dropped at the border. Adding the missing ip nat inside statement to that interface restored full internet reachability for PC1.

PC3 — Disabled interface, then a missing OSPF statement. A traceroute showed PC3 couldn’t reach its gateway at all, pointing the investigation toward the Factory router. Running show ip interface brief on that router revealed GigabitEthernet0/0/1 was explicitly administratively down. A no shutdown command brought the interface back online — but a subsequent ping to the internet server still failed, even though the gateway itself was now reachable. A deeper look with show ip ospf interface revealed the network statement for 192.168.4.0/24 had never been added to OSPF process 10. Once the correct wildcard network statement was entered under global configuration to inject that subnet into Backbone Area 0, PC3 regained full connectivity to both the internet and other PCs on the network.

PC5 — Missing default gateway. PC5’s IP configuration showed the default gateway field left at 0.0.0.0. With an empty ARP table, a ping to the subnet broadcast address (192.168.5.255) revealed two other hosts: 192.168.5.129 and 192.168.5.252. Given that PC5 sits on the 192.168.5.128/25 subnet, 192.168.5.129 was identified as the correct gateway. Manually setting that address resolved the fault, and a subsequent ping test confirmed both internet and inter-PC connectivity.

PC6 & PC7 — IP address mismatch between Hub and Branch-2. Both hosts used Branch-2 as their default gateway, and Branch-2 connected to the Hub over a point-to-point serial link. Inspection showed the Hub’s Serial0/1/1 interface used the subnet 192.168.0.4/30, with the Hub itself configured at 192.168.0.5 — but Branch-2’s corresponding interface was set to 192.168.0.17, an address outside that subnet entirely. Reconfiguring Branch-2’s Serial0/1/0 interface to 192.168.0.6 (the correct remaining host address in that /30) restored the link, and both PC6 and PC7 were confirmed able to reach the internet and other PCs on the network afterward.

A consolidated view of every fault and its resolution:

Each of these faults sat at a different layer — physical (interface shutdown), network-layer addressing (gateway, NAT), and routing protocol (OSPF) — which is exactly why a layer-by-layer diagnostic approach was necessary rather than guessing at a single root cause.

B. Secure vs. Insecure Communication Protocols

The second part of the work looked at how different application-layer protocols handle sensitive data in transit, using a packet sniffer to observe traffic directly.

Email (SMTP/POP3). Sending a corporate email between two users first required bringing both PCs online — both had been left with static IP configurations but no actual address assigned, so switching each to DHCP let them pick up an address, subnet mask, and gateway automatically. Once online, the email was sent successfully using SMTP (Simple Mail Transfer Protocol) and later retrieved by the recipient using POP3 (Post Office Protocol).

FTP. Uploading a file to a central FTP server completed successfully, but a packet capture told a more concerning story: FTP operates entirely in clear text. The sniffer revealed the username (mary) in one captured packet and the password (cisco123) in another — both fully readable, because FTP is inherently insecure and transmits all control and authentication data unencrypted.

Telnet. The same clear-text problem showed up when remotely accessing an enterprise router via Telnet. The sniffer captured the administrative login character-by-character — literally splitting the word “admin” across individual packets, each showing a single letter (data: a, data: d, and so on) until the full credential could be reconstructed. Telnet applies no encryption or cryptographic encapsulation to the administrative session, making it unsuitable for managing production infrastructure.

SSH. The same router-access task was repeated using SSH instead, and the difference in the packet capture was immediate: rather than readable characters, the sniffer showed only an “Encrypted WAN Data” field with no discernible content. SSH sends session data encrypted, meaning a hacker or malicious actor intercepting the traffic cannot retrieve the underlying data. After authenticating over SSH, the router’s password was further hardened using the enable secret command, which — unlike the older enable password command — stores the credential as a strong hash (MD5 or SHA-256) rather than in plaintext.

C. Emerging Cloud Security Technologies

Hybrid and multi-cloud adoption has reshaped enterprise risk surfaces, pushing organisations to rethink assumptions built for traditional, perimeter-based networks, as hybrid and multi-cloud systems have redefined enterprise risk surfaces and made standard perimeter security frameworks obsolete. Three technology categories were reviewed against that backdrop.

Secure Access Service Edge (SASE) / Security Service Edge (SSE). SASE converges SD-WAN capabilities with cloud-delivered security services such as Zero Trust Network Access, Cloud Access Security Broker, and Secure Web Gateway into a single architecture, an idea first put forward by Gartner in 2019 and reaching vendor maturity by 2021. SSE is the security-only subset of that model, treating the security stack independently of network transport. However, deployment isn’t seamless in practice: enterprises running multiple SaaS services face inconsistent policy enforcement across distributed Points of Presence, particularly in high-latency WAN conditions. There’s also a structural blind spot — SASE doesn’t address east-west traffic inspection inside containerised workload clusters, which represents an architectural shortcoming.

Cloud-Native Application Protection Platforms (CNAPP). CNAPPs combine Cloud Security Posture Management, Cloud Workload Protection Platforms, and Cloud Infrastructure Entitlement Management into one category. The deeper a CNAPP is embedded into a CI/CD pipeline, the more effective it becomes — but that depth comes at a cost: deeper integration lowers the signal-to-noise ratio of alerts, increasing the risk of alert fatigue among DevSecOps teams. Alignment with formal compliance frameworks is also inconsistent, particularly in the Data Security and Privacy control domain.

Confidential Computing. This category addresses a long-standing blind spot: data-in-use has historically been exposed, and confidential computing resolves this by introducing cryptographic isolation in hardware-supported Trusted Execution Environments such as Intel SGX, AMD SEV, and ARM TrustZone. Workloads run inside memory-encrypted enclaves inaccessible even to privileged software like hypervisors or cloud administrators, offering real protection against insider threats. But the trade-off is steep: latency penalties from context switches between enclaves make TEE adoption cost-prohibitive for latency-critical, high-throughput microservice architectures, and cache-timing or power-consumption side-channel attacks continue to challenge these implementations.

The comparison matrix from the review:

D. Emerging Threat Trends

Two trends stood out in the review. First, automation and AI have industrialised offensive cyber operations, with adversarial LLMs already shown capable of automatically exploiting vulnerabilities, generating spear-phishing content, and enabling dynamic malware polymorphism, including through jailbroken commercial models. According to the material reviewed, credential-based attacks against cloud management-plane APIs increased by 47%, driven partly by automated reconnaissance combined with exploit chaining against misconfigured IAM policies.

Second, software supply-chain compromise has moved from a peripheral concern to a systemic risk following high-profile incidents like SolarWinds and the XZ Utils backdoor. The SLSA framework offers a maturity model for build provenance, but adoption remains low: fewer than 12% of Fortune 500 organisations were SLSA Level 2 compliant in 2023. Cryptographic signing (via Sigstore) and SBOM generation, now required under US Executive Order 14028, are described as incomplete but improving mitigations.

E. Compliance Framework Alignment

CSA Cloud Controls Matrix v4 and ISO/IEC 27017:2015 are the most widely adopted compliance reference architectures for cloud-native organisations, with CCM v4 spanning 197 control specifications across 17 security domains, and ISO/IEC 27017 adding 37 cloud-specific controls on top of ISO/IEC 27002.

Mapping the three technologies onto these frameworks: SASE architectures address CCM v4’s IAM-01 through IAM-09 identity and access-brokering controls and IVS-09 network segmentation, along with ISO/IEC 27017 clauses on network access and segregation. CNAPPs cover data classification, change management, and application security controls, while a residual gap remains around data-in-use controls — something the Confidential Computing Consortium is working to formally address through technical specifications.

F. Risk Assessment Methodologies: STRIDE vs. FAIR

STRIDE — Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege — is Microsoft’s threat taxonomy, commonly used for structured threat identification during system design. Applied to cloud workloads, it can classify a container escape as Elevation of Privilege or misconfigured object storage as Information Disclosure, but it stops short of quantitative prioritisation, limiting its usefulness for enterprise risk governance where budget decisions need justification.

Factor Analysis of Information Risk (FAIR) takes a quantitative approach instead, using probabilistic modelling to break risk into Loss Event Frequency and Probable Loss Magnitude, allowing risk to be expressed in financial terms useful for board-level reporting or insurance decisions. Its weakness is data availability: FAIR’s outputs depend on empirical loss data that’s still sparse for novel cloud attack vectors, and its static probability model struggles to capture cascading failures typical of microservice architectures.

The literature suggests a complementary approach — using STRIDE during design-phase threat modelling to build a qualitative threat catalogue, then feeding those scenarios into FAIR for quantification — though this adds tooling complexity and requires both security-architecture and actuarial skill sets.

Key Findings

• The simulated network suffered from five distinct, independently diagnosable faults: a missing NAT statement, an administratively disabled interface, a missing OSPF network statement, a missing default gateway, and a subnet mismatch between two routers.
• All five faults were resolved using standard Cisco IOS diagnostic and configuration commands, with each fix verified through ping or traceroute evidence.
• FTP and Telnet both transmit credentials in clear text and were shown, via packet capture, to expose usernames and passwords directly.
• SSH encrypts session data end-to-end, and its captured traffic showed no readable content, in contrast to FTP and Telnet.
• SASE, CNAPP, and Confidential Computing each address different layers of the cloud security stack (access edge, workload/posture, and hardware-level data-in-use protection respectively), but none fully replaces the others.
• Fewer than 12% of Fortune 500 organisations had reached SLSA Level 2 supply-chain maturity as of 2023.
• STRIDE and FAIR serve complementary but distinct purposes — qualitative threat elicitation versus quantitative financial risk modelling — and neither alone is sufficient for dynamic, multi-tenant cloud workloads.

Recommendations

The review’s recommendations centre on three research priorities. First, developing hybrid STRIDE–FAIR threat quantification pipelines that work against microservice dependency graphs — addressing the gap where STRIDE’s qualitative output needs a bridge into FAIR’s financial modelling. Second, empirically benchmarking CNAPP alert quality across heterogeneous multi-cloud topologies, directly responding to the alert-fatigue problem identified in deep CI/CD integrations. Third, optimising TEE performance through hardware-software co-design to bring enclave context-switching overhead down to operationally acceptable levels, addressing the 15–40% computational penalty that currently limits Confidential Computing’s practicality.

At an organisational level, the assignment’s conclusions point toward pursuing SLSA Level 3 supply-chain provenance, adopting a policy-as-code approach to enforce CSA CCM v4 control mappings during annual risk governance cycles, and applying policy-as-code enforcement across all production CI/CD pipelines.

Practical Takeaways

The network-troubleshooting exercise demonstrates that connectivity failures in enterprise environments rarely stem from a single cause — instead, they tend to be layered, with each fault requiring isolation at the correct level of the OSI model before a fix can be applied confidently. The findings also highlight a familiar imbalance: legacy protocols like FTP and Telnet remain functional and widely used, but a single packet capture is enough to demonstrate why they should not be used for anything sensitive.

On the cloud security side, the analysis indicates that no single emerging technology — SASE, CNAPP, or Confidential Computing — offers complete coverage on its own. Each maps to a different part of the compliance and threat landscape, and the practical implication for security architects is a layered strategy: access-edge controls for north-south traffic, workload posture management for east-west and pipeline security, and selective use of hardware-based isolation for the most sensitive data pipelines.

Conclusion

This project investigated two connected problems: restoring connectivity across a simulated multi-site enterprise network, and evaluating how emerging cloud security technologies measure up against current compliance frameworks and risk-assessment methods. The network side identified and resolved five independent faults — a missing NAT statement, a disabled interface, an absent OSPF network statement, a missing default gateway, and a router subnet mismatch — each traced through systematic layer-by-layer diagnostics and confirmed through verification testing. The communications testing reinforced the practical difference between clear-text protocols like FTP and Telnet, both shown leaking credentials directly, and encrypted alternatives like SSH.

The literature review found that SASE, CNAPP, and Confidential Computing each target different layers of cloud-native risk but leave residual gaps when used in isolation, that compliance frameworks like CSA CCM v4 and ISO/IEC 27017 map unevenly across these technologies, and that existing risk-assessment methodologies — STRIDE and FAIR — each solve half of the problem: qualitative threat identification on one side, quantitative financial modelling on the other. Taken together, the work supports a broader conclusion that neither network security nor cloud security is well served by single-tool solutions; both depend on layered, verifiable controls applied consistently across every level of the stack.

References Used

• ENISA (2023) ENISA Threat Landscape 2023. Heraklion: European Union Agency for Cybersecurity.
• Bermbach, D. et al. (2021) ‘A Research Perspective on Fog Computing’, Internet of Things, 14, 100101.
• Gartner (2022) Market Guide for Security Service Edge. Stamford, CT: Gartner, Inc.
• Costan, V. and Devadas, S. (2021) ‘Intel SGX Explained’, IACR Cryptology ePrint Archive, 2016(086).
• Ladisa, P. et al. (2023) ‘SoK: Taxonomy of Attacks on Open-Source Supply Chains’, in 2023 IEEE Symposium on Security and Privacy.
• Xiong, W. and Lagerström, R. (2022) ‘Threat Modeling — A Systematic Literature Review’, Computers & Security, 84, pp. 53–69.
• Arnautov, S. et al. (2021) ‘SCONE: Secure Linux Containers with Intel SGX’, in Proceedings of the 12th USENIX Symposium on OSDI.

Education is not just a fundamental right; it is the cornerstone of empowerment and progress. At Hamari Pahchan NGO Name, we firmly believe in the transformative power of education. Our journey is driven by the vision of creating a world where every individual, regardless of their background or circumstances, has access to quality education.

*Breaking Barriers, Building Futures*

In a world where opportunities are often unequally distributed, education stands as the great equalizer. Our NGO is committed to breaking down barriers and ensuring that education reaches every corner of society. Whether it's providing resources to underprivileged communities, offering scholarships to deserving students, or advocating for inclusive educational policies, we are dedicated to building a future where everyone has the chance to thrive.

*Holistic Approach to Education*

At [NGO Name], we understand that education goes beyond textbooks and classrooms. It's about nurturing the whole individual – mind, body, and spirit. That's why our programs encompass a holistic approach to education, incorporating elements such as skill development, mental health support, and community engagement. By addressing the diverse needs of learners, we empower them to reach their full potential and become agents of change in their communities.

**Impact in Action**

Our work is not just about rhetoric; it's about tangible impact. Over the years, we have seen lives transformed, dreams realized, and communities uplifted through our education initiatives. From helping students excel academically to equipping them with the tools to pursue their passions, every success story is a testament to the power of education to create positive change.

**Join Us in the Journey**

Education for all is not just a goal; it’s a collective responsibility. As we continue our journey at Hamari Pahchan NGO , we invite you to join us in making a difference. Whether through volunteering, donating, or spreading awareness, your support can help us reach more individuals and amplify our impact. Together, let’s empower lives and build a brighter future through education.

**Conclusion**

In a world where inequalities persist, education remains the most potent force for change. At Hamari Pahchan NGO, we are committed to championing the cause of education for all, one student, one community at a time. Join us in our mission, and together, let’s transform lives and create a more inclusive and equitable world through the power of education.