Module 4: Attack Surfaces, Networks, and Cloud in Plain English

Step 1 – What Is an Attack Surface (in Legal-Friendly Terms)?

Think of an organization as a building full of doors, windows, vents, and delivery slots. The attack surface is every way an attacker could potentially get in or move around.

In cybersecurity and legal work, when you hear “reduce the attack surface”, it means:

> Limit the number of ways attackers can reach sensitive data or systems, and make each way harder to abuse.

For a modern organization (even a small one), the attack surface usually includes:

1. People (Users)

• Employees, contractors, interns, board members.
• Targets for phishing, social engineering, credential theft.

1. Devices

• Laptops, phones, tablets, desktops, servers, IoT devices (printers, cameras, badge readers).
• Risk: lost/stolen devices, unpatched software, weak configuration.

1. Applications & Data

• Web apps, mobile apps, internal tools, databases, file shares, email.
• Risk: software vulnerabilities, misconfigurations, weak access controls.

1. Infrastructure (Networks & Systems)

• Routers, firewalls, VPNs, on‑prem servers, data centers.
• Risk: exposed services, poor segmentation, default passwords.

1. Vendors & Third Parties

• Cloud providers, payroll, CRM, law firms, marketing agencies, software vendors.
• Risk: they get breached and attackers pivot into your data or systems.

From a legal‑risk view, the attack surface is where:

• Duties arise (e.g., to secure data, follow standards, comply with regulations like GDPR or HIPAA).
• Breach scenarios start (e.g., compromised VPN, misconfigured cloud bucket).
• Contracts and DPAs should describe responsibilities and security controls.

Keep this mental model: Every login, device, connection, and vendor is part of the attack surface.

Step 2 – Map a Simple Attack Surface (Thought Exercise)

Imagine a mid‑size law firm (150 employees) in 2026. They:

• Host an internal file server in their office.
• Use Microsoft 365 for email and documents.
• Use a cloud‑based practice management SaaS.
• Let staff work remotely over VPN.

Your task (no right/wrong, just thinking):

1. List at least one attack surface element in each category:

• Users: Who are likely targets and how?
• Devices: Which devices matter most for security?
• Applications & Data: Which apps hold sensitive client data?
• Infrastructure: What network components could be attacked?
• Vendors & Third Parties: Which external services expand the firm’s risk?

1. Mark one item in your list that you think is:

• Most likely to be attacked (high frequency).
• Most damaging if compromised (high impact).

Write your answers in a few bullet points. You’ll reuse this mental picture in later steps when we discuss networks and cloud.

Step 3 – Basic Network Map: From Your Laptop to the Internet

To understand attack surfaces, you need a simple mental picture of how networks are wired together.

Picture this flow when you connect from a work laptop at the office:

1. Your device (endpoint)

• Laptop or phone connects by Wi‑Fi or cable.

1. Internal network (LAN – Local Area Network)

• Like the “inside” of the office building.
• Contains printers, internal servers, and other employee devices.

1. Perimeter / Edge

• Firewall and sometimes an edge router sit between the internal network and the public internet.
• They decide what traffic is allowed in or out.

1. The Internet

• A huge collection of networks run by ISPs, cloud providers, etc.
• Your traffic hops through many networks to reach a website or cloud service.

In plain English:

• Internal network = relatively trusted, private space.
• Perimeter = the security checkpoint (firewalls, sometimes intrusion detection/prevention).
• Internet = untrusted public space where attackers are assumed to be.

Why this matters legally:

• Many security policies and standards (e.g., ISO 27001 controls, NIST CSF practices) are built around protecting internal networks from the internet.
• Incident reports often say things like “the attacker gained access to the internal network via an exposed remote desktop service” — this is a perimeter failure.

Keep this simple diagram in mind:

```text

[Your Laptop] --(inside)--> [Internal Network] --(firewall)--> [Internet] --(https)--> [Cloud/App]

```

Step 4 – Quick Network Concept Check

Choose the best answer based on the simple network model.

Step 5 – Remote Access and VPNs: Extending the Perimeter

Remote work is now routine, especially since the COVID‑19 shift in 2020–2021. That changed the attack surface dramatically.

VPN (Virtual Private Network) in plain English:

• A secure, encrypted tunnel from a remote device (home laptop, phone) into the organization’s internal network.
• Makes your device logically part of the internal network, even when you’re at home or traveling.

So the simple picture becomes:

```text

[Remote Laptop] ==(VPN tunnel)==> [Internal Network] --(firewall)--> [Internet]

```

Why VPNs matter for attacks:

• If an attacker steals VPN credentials (via phishing, malware, or password reuse), they can enter the internal network as if they were an employee.
• Many major breaches reported in the last 5–10 years started with compromised VPN accounts or exposed remote access tools (like RDP).

Legal‑risk angle:

• Policies and contracts often require strong authentication (e.g., multi‑factor authentication, or MFA) for VPN.
• If an organization does not use MFA on VPN and attackers walk in with stolen passwords, regulators, insurers, or plaintiffs may argue that reasonable security was not met.
• In incident reports, phrases like “VPN access without MFA” or “legacy VPN exposed to the internet” are red flags.

When you see “remote access” in a contract, diligence Q&A, or incident report, mentally highlight it as a high‑value attack surface element.

Step 6 – Cloud 101: IaaS, PaaS, SaaS (Who Controls What?)

Cloud is everywhere, but the type of cloud service changes who is responsible for what. This matters for both security and contracts.

Three main cloud models

1. IaaS – Infrastructure as a Service (e.g., Amazon EC2, Azure VMs, Google Compute Engine)

• Provider gives you virtual machines, storage, and networking.
• You (the customer) manage the operating system, applications, configurations, and most security controls.

1. PaaS – Platform as a Service (e.g., Azure App Service, AWS Lambda, Google App Engine)

• Provider manages the underlying servers and runtime platform.
• You focus on your code and data.
• Security responsibilities are shared but you still control access, application logic, and data protection.

1. SaaS – Software as a Service (e.g., Microsoft 365, Salesforce, Google Workspace, many legal practice tools)

• Provider runs the entire application and infrastructure.
• You mainly configure users, permissions, data retention, and integrations.

Shared Responsibility Model (current view)

All major cloud providers (AWS, Azure, Google Cloud) use a shared responsibility model:

• Cloud provider is responsible for the security of the cloud:
• Physical data centers, hardware, core network, core platform.
• Compliance with many technical standards (e.g., ISO 27001, SOC 2).

• Customer is responsible for security in the cloud:
• Who can log in (identity & access management, MFA).
• How data is classified, encrypted, and shared.
• Configuration of services (e.g., whether a storage bucket is public).
• Application‑level security.

From a legal perspective, this means:

• A breach caused by your misconfiguration (e.g., a public S3 bucket exposing client data) is usually your responsibility, even if the data is on AWS.
• The provider’s contracts and Data Processing Agreements (DPAs) usually state this explicitly.
• Regulators and courts now routinely treat cloud use as no excuse for poor security.

When reviewing incidents, look for clues like “publicly exposed storage bucket,” “misconfigured security group,” or “over‑privileged SaaS accounts” — these are shared‑responsibility failures.

Step 7 – Cloud Responsibility Check

Test your understanding of who is responsible for what in cloud setups.

Step 8 – On‑Prem vs Cloud: A Breach Scenario in Two Flavors

Consider a company that stores customer data in a database.

Scenario A – On‑Premises

• Database server physically sits in the company’s office data room.
• It’s on the internal network, reachable only from inside or via VPN.
• IT team manages the hardware, operating system, patches, backups, and access controls.

Breach path:

1. Attacker phishes an employee, steals VPN credentials.
2. Logs in via VPN, now inside the internal network.
3. Scans the network, finds the database server.
4. Exploits a missing security patch to access the database.

Responsibility:

• Almost entirely on the company: it owns the infrastructure, patching, VPN security, and access control.

---

Scenario B – Cloud (IaaS)

• The same database is now on a virtual machine in AWS.
• Access is controlled by security groups and identity/access policies.

Breach path:

1. Cloud admin misconfigures security groups, leaving the database port open to the internet.
2. Attacker scans the internet, finds the exposed database.
3. Uses a known vulnerability to gain access.

Responsibility:

• AWS secured the underlying infrastructure.
• The misconfiguration was by the customer’s admin.
• Legally and contractually, the customer is still likely responsible for the data breach.

In both cases, the attack surface included:

• User accounts (phished or over‑privileged).
• Network exposure (VPN, security groups).
• Vulnerable software (unpatched database).

The location (on‑prem vs cloud) changes who manages which layers, but not the need to secure them.

Step 9 – Third‑Party and Supply Chain Risk: Your Vendors Are Part of Your Attack Surface

Major incidents in the last decade (e.g., the SolarWinds compromise disclosed in 2020, large managed service provider breaches, and multiple cloud/SaaS incidents since) have shown that attackers love to go through third parties.

Third‑party / supply chain risk means:

> Your security and legal exposure depend not only on your own systems, but also on the systems and practices of your vendors, partners, and service providers.

Examples:

• A payroll provider gets breached and attackers access employee data.
• A managed IT services company is compromised; attackers use its remote tools to access many of its customers.
• A law firm’s e‑discovery vendor misconfigures a cloud storage bucket and exposes case files.

From a contract and legal‑risk perspective, you want to know:

1. What data do they hold or access?

• Client data, employee data, trade secrets, credentials, logs?

1. What security standards do they follow?

• Certifications (e.g., ISO 27001, SOC 2), controls (MFA, encryption, monitoring), incident response procedures.

1. What does the contract say about:

• Security obligations (minimum controls, compliance with laws).
• Breach notification (how fast, what info, cooperation).
• Liability and indemnity (who pays if something goes wrong).
• Sub‑processors / subcontractors (who else is in the chain?).

In cyber due diligence or incident analysis, always ask:

> “Which vendors were involved here, and how do they expand the attack surface?”

Step 10 – Spotting Vendor Attack Surface (Thought Exercise)

Take the same mid‑size law firm from earlier. They use:

• A cloud practice management SaaS.
• A third‑party IT support company with remote access to staff laptops.
• A cloud‑based e‑discovery platform.
• An external marketing agency that manages the public website.

Your task:

1. For each vendor, answer in one short sentence:

• What kind of data or access do they have that affects the firm’s attack surface?

1. Circle or mark (mentally or on paper) one vendor you would prioritize in a contract review from a cybersecurity risk standpoint, and briefly note why.

1. Optional extension:

• Jot down one security‑related clause you would want to see in that vendor’s contract (e.g., MFA, encryption, breach notice timeframe, right to audit, etc.).

This is the same mental process used in real‑world vendor risk assessments.

Step 11 – Key Term Review (Flashcards)

Flip through these terms to reinforce the core ideas from this module.

Step 12 – Final Check: Connecting Attack Surface, Networks, Cloud, and Vendors

One last scenario to tie everything together.