Network Security Firewall & VPN Case Study Paper
You are playing the role of a security consultant hired by a credit card processing startup with zero security infrastructure and a CEO who does not know what a firewall is. Four sections, 4–6 pages, and the professor wants to see that you actually understand this material — not that you can reword a textbook. Here is how to approach every section without faking it.
The scenario puts you in a real professional position: a 30-day engagement with a company that handles credit card transactions, has remote users, no security infrastructure, and an empty CISO seat. The CEO wants a 4–6 page report. The professor wants to see that you understand the material well enough to make original recommendations — not reworded definitions. That distinction is in the instructions themselves. Keep it in mind from the first sentence you write.
What This Guide Covers
Reading the Scenario Before You Write Anything
The company profile is specific, and every part of it matters for your recommendations. Medium-sized startup. Processes credit card transactions daily. Remote users exist. No current security infrastructure. No CISO. Leadership has no security background. That is a lot of exposure packed into one paragraph.
Credit card data is regulated. That means PCI DSS — the Payment Card Industry Data Security Standard — is directly relevant to this company whether or not the assignment mentions it by name. Working PCI DSS into your paper is not padding. It is the actual compliance framework that governs exactly what this company is required to do. Any security recommendation you make should be linkable to either a technical best practice or a PCI DSS requirement.
The CEO and business staff have no knowledge of network security. Your report is written for them. That does not mean you dumb it down — it means you explain technical concepts in plain terms, always connecting them to business risk. Do not write “stateful packet inspection filters TCP headers at the transport layer” without explaining what that means for the company. “This prevents attackers from sending malicious traffic disguised as legitimate connections” is what the CEO actually needs to hear.
Section 1.0 — Introduction: Setting the Stage Without Wasting Space
The introduction is not a summary of your paper. It is the context-setting section that tells the reader what situation you walked into, why security matters for this specific company, and what the report will cover. One to two paragraphs. Get to the point fast.
Four Things the Introduction Must Establish
First, state who you are in this scenario — a contracted network security consultant brought in for a 30-day engagement. Second, describe the company’s profile: a credit card processing startup, remote users, no existing security posture, and no CISO. Third, explain why this matters — companies handling payment data face specific legal and technical obligations, and the current state represents significant risk. Fourth, preview the structure: the report covers the threat landscape, firewall and VPN recommendations, implementation guidance, and long-term security practices.
Do not open with a dictionary definition. “Network security is the practice of protecting computer networks from unauthorized access…” is how every weak paper starts. Open with the scenario. “As a contracted security consultant engaged by [company], this report addresses the immediate network security risks facing an organization that processes credit card transactions daily with no existing security infrastructure.” That is a stronger first sentence.Section 2.0 — Network Security Fundamentals, Threats, and Issues
This section has two jobs. First, give the CEO a working understanding of network security fundamentals — just enough to understand why the recommendations in Section 3.0 exist. Second, identify the specific threats this company faces given its profile. A generic list of cyber threats is not what this section is asking for. Every threat you name should connect to the company’s specific exposure: payment data, remote users, startup-scale IT, no current security.
Frame It Around What the Company Needs to Understand
Cover the basics: what a network is in this context, what it means to secure one, the idea of defense-in-depth (layered security rather than a single control), and the concept of the network perimeter. Introduce the CIA triad — Confidentiality, Integrity, Availability — not as textbook terms but as the three things this company needs to protect about its transaction data. Then explain that firewalls and VPNs are two of the primary tools used to enforce those protections.
Keep this functional. The professor is not asking for a 500-word glossary. Cover enough for the CEO to understand why the recommendations exist. Two to three paragraphs on fundamentals is appropriate. The bulk of Section 2.0 should be the threat landscape.For the threats section, work through each relevant threat category and connect it explicitly to this company. Here is how to structure that:
Phishing and Social Engineering
The most common entry point for attackers at any organization size. Staff without security training — which describes the entire company right now — are highly susceptible. A phishing email to a remote employee with access to payment processing systems could result in credential theft and unauthorized access to cardholder data. This threat is elevated here because there is no security awareness program in place.
Man-in-the-Middle (MitM) Attacks
Remote users connecting over unsecured networks — public Wi-Fi, home networks without proper controls — are vulnerable to traffic interception. If transactions are not encrypted end-to-end, an attacker positioned between the remote user and the company’s systems can intercept and manipulate data in transit. For a company processing credit card transactions, this is a direct PCI DSS concern.
Unauthorized Network Access
Without a firewall, the company’s internal network has no enforced perimeter. Any device or user that can reach the network — intentionally or accidentally — can potentially access internal systems. In a startup environment where access controls have not been designed from the ground up, this is a significant structural vulnerability.
Malware and Ransomware
A single infected endpoint — a remote employee’s laptop, for example — can introduce malware into the network if proper segmentation and endpoint security are not in place. Ransomware targeting financial services companies has increased significantly. For a company with no current security tooling, an infection could halt payment processing entirely and expose cardholder data.
Insider Threats
In a startup with no established access controls, employees often have broader access than they need. An insider — whether malicious or simply careless — can expose or exfiltrate payment data without any detection mechanism in place. The principle of least privilege (giving users only the access they need to do their jobs) has not been implemented here because no policy exists yet.
PCI DSS Non-Compliance Risk
This is not a cyberattack — it is a regulatory exposure. Any company that stores, processes, or transmits cardholder data is subject to PCI DSS requirements. The current state of the organization — no firewall, no VPN, no documented security policies — is non-compliant on multiple requirements. Non-compliance can result in fines, loss of payment processing privileges, and liability in the event of a breach. This belongs in Section 2.0 as a named risk.
Section 3.0 — Detailed Network Security Recommendations
This is the meat of the paper. It has four distinct components, and the assignment even suggests using subsections (3.1, 3.2, 3.3, 3.4). Use them. They make the paper easier to read and they signal that you followed the instructions carefully.
Suggested Subsection Structure
- 3.1 — Fundamentals of Firewalls and VPNs
- 3.2 — Recommended Firewall and VPN Solutions
- 3.3 — Implementation Recommendations
- 3.4 — Long-Term Security Practices (if hired as CISO)
What the Professor Is Actually Testing Here
The instructions say the key is demonstrating your understanding, not rewording the text. That means your recommendations need to be grounded, specific, and justified — not just definitions followed by “therefore we should implement a firewall.” Each recommendation should explain what it does, why it fits this company’s profile, and what it protects against.
Section 3.1 — Firewall Fundamentals and Recommendations
Start with a clear, functional explanation of what a firewall does — written for a non-technical CEO. Then explain the types of firewalls and why one type is more appropriate than another for this company’s situation.
From Packet Filtering to Next-Generation: Why It Matters Here
Packet-filtering firewalls operate at the network layer, examining IP addresses and port numbers. They are fast but cannot inspect the content of traffic — an attacker can craft traffic that passes port-based rules while carrying a payload. Stateful inspection firewalls track the state of connections — they know whether traffic is part of an established session or an uninitiated probe. Application-layer (proxy) firewalls can inspect traffic at the application level, understanding protocols like HTTP or DNS. Next-generation firewalls (NGFWs) combine all of these with deep packet inspection, intrusion prevention, and application awareness.
Your recommendation: A next-generation firewall is appropriate for this company. The reasons are specific to the scenario — the company processes payment data (requiring application-layer inspection of transaction traffic), has remote users (requiring VPN integration), and needs intrusion detection without a dedicated security team to manage complex multi-device infrastructure. NGFWs consolidate these capabilities into a single platform that a small IT team can manage. Name a product family — Cisco Firepower, Palo Alto Networks PA-Series, and Fortinet FortiGate are all widely cited in academic network security papers.| Firewall Type | What It Inspects | Appropriate For | Fit for This Company |
|---|---|---|---|
| Packet Filtering | IP headers, port numbers | Simple perimeter filtering, low-overhead environments | Insufficient — cannot detect application-layer attacks or inspect transaction traffic |
| Stateful Inspection | Connection state, packet context | Medium complexity networks needing session tracking | Better than packet filtering but still lacks application visibility |
| Application-Layer / Proxy | Full application protocol content | Environments needing deep HTTP, DNS, FTP inspection | Good for specific protocols but less flexible as a standalone solution |
| Next-Generation Firewall (NGFW) | DPI, application identity, IPS, user identity | Organizations needing layered inspection with manageable overhead | Recommended — combines perimeter defense, IPS, VPN support, and application control in one platform |
Your recommendation should address not just what type of firewall to deploy, but where it goes. A perimeter firewall between the internet and the internal network is the baseline. Depending on your architecture, you might also recommend a DMZ — a demilitarized zone — where public-facing systems (any web-facing payment processing components) sit between two firewall layers, isolating them from the internal network. This is a meaningful addition that shows you are thinking about the architecture, not just the product.
Section 3.1 (continued) — VPN Fundamentals and Recommendations
The scenario specifies remote users. That makes VPN non-optional — and it also means your VPN section needs to address what type of VPN fits the use case. There are two main options to discuss.
IPsec VPN
Operates at the network layer. Typically used for site-to-site connections — linking two fixed networks over the internet securely. Encrypts all IP traffic between endpoints. Strong for connecting branch offices or partner networks. Requires client software or hardware configuration. Less flexible for individual remote users working from varying locations.
- Best for: fixed office-to-office connections
- Protocol: operates at Layer 3 (Network)
- Encryption: AES-256 with IKEv2 is current best practice
- Management: higher overhead for individual remote users
SSL/TLS VPN
Operates at the application layer through a web browser or lightweight client. Remote users authenticate and connect without complex client configuration. More flexible for a mobile or home-based workforce. Can be configured for full-tunnel (all traffic routed through VPN) or split-tunnel (only company traffic routed through VPN). Full-tunnel is more secure for a company handling payment data.
- Best for: individual remote users from variable locations
- Protocol: SSL/TLS at Layer 7 (Application)
- Access: browser-based or thin client — lower friction for users
- Recommendation: full-tunnel mode for cardholder data environments
SSL/TLS VPN for Remote Users — With a Note on Split vs. Full Tunnel
For a startup with remote employees accessing payment systems from variable locations, SSL/TLS VPN is the right fit. It is easier to deploy, requires no complex client configuration per device, and works through standard browsers. Your recommendation should specify full-tunnel mode — routing all remote traffic through the company VPN — because split-tunnel leaves non-company traffic unmonitored and can create a pathway for threats originating outside the tunnel. Address multi-factor authentication (MFA) as a required control alongside VPN access. A VPN with only a username and password is significantly weaker than one requiring a second factor.
Tie it to PCI DSS explicitly. PCI DSS Requirement 8 mandates strong authentication for all users accessing cardholder data environments. Requiring MFA for VPN access is not just a best practice — for this company, it is a compliance requirement.Section 3.2 — Implementation Recommendations
This section answers “how do we actually do this?” It is not enough to say “deploy an NGFW and an SSL VPN.” The CEO needs to understand the steps involved and the sequence that makes sense. Think of it as a phased rollout.
Phase 1 — Network Assessment and Architecture Design
Before any hardware or software is deployed, document the current network state. Identify all endpoints, map data flows (especially where cardholder data moves), and establish baseline connectivity requirements. Design the target architecture — perimeter firewall placement, DMZ configuration for any public-facing systems, VPN gateway placement, and internal network segmentation. This phase should produce a network diagram that accompanies the final security plan.
Phase 2 — Firewall Deployment and Rule Configuration
Deploy the NGFW at the network perimeter. Establish a default-deny baseline rule set — all traffic is blocked unless explicitly permitted. Then add permissive rules only for required services. This is critical: many organizations deploy firewalls with overly permissive rules that undermine the security benefit. Document every rule with a justification. Enable intrusion prevention signatures appropriate for a payment processing environment. Configure logging — every allowed and denied connection should be logged for review.
Phase 3 — VPN Deployment and Remote Access Policy
Deploy the SSL/TLS VPN solution, integrated with the NGFW where possible (many NGFW platforms include built-in VPN capabilities, reducing complexity). Configure full-tunnel mode. Enforce MFA for all VPN connections — integrate with an authentication platform such as Microsoft Azure AD or Duo Security. Define and document the remote access policy: which users can access the VPN, what systems they can reach, and what they cannot access remotely. Distribute the policy to all remote staff before enabling access.
Phase 4 — Testing and Validation
Before declaring the implementation complete, test the controls. Attempt connections that should be blocked and confirm they are. Test VPN connectivity from external networks. Review firewall logs to confirm logging is working. Conduct a basic vulnerability scan of the external perimeter to confirm no unintended services are exposed. Document the test results. This phase also supports PCI DSS compliance evidence requirements.
Section 3.3 — Long-Term Security Practices (If Hired as CISO)
The scenario asks what practices you would implement if hired long-term. This is your chance to show understanding beyond the firewall-and-VPN scope of the immediate engagement. Frame these as the practices you would put in place over the first six to twelve months in the CISO role.
Acceptable Use and Security Policy
Document acceptable use of company systems, remote access rules, data handling requirements, and incident reporting procedures. Without written policies, enforcing any security control is difficult and legally complicated.
Security Awareness Training
All staff — not just IT — should complete annual security awareness training covering phishing recognition, password hygiene, and reporting suspicious activity. The human layer is the most targeted entry point at this company’s current maturity level.
Least Privilege and Role-Based Access
Audit every employee’s access to internal systems. Grant only the minimum access required for their role. Review and revoke access when roles change. This directly reduces insider threat exposure and limits the blast radius of a compromised account.
Log Management and SIEM
Centralize logs from the firewall, VPN, and internal systems into a Security Information and Event Management (SIEM) tool. Configure alerts for anomalous activity — multiple failed VPN logins, traffic to unusual destinations, after-hours access to payment systems.
Patch Management Program
Establish a regular cadence for applying security patches to all systems — firewall firmware, server operating systems, endpoint software. Unpatched vulnerabilities are among the most exploited attack vectors. PCI DSS Requirement 6 specifically addresses this.
PCI DSS Compliance Program
Initiate a formal PCI DSS compliance program: determine the company’s merchant level, identify scope (all systems that touch cardholder data), and work toward completing a Self-Assessment Questionnaire or engaging a Qualified Security Assessor. Compliance is not optional for payment processors.
Section 4.0 — Summary: Short and Purposeful
The instructions are clear: a paragraph or two. Do not restate the entire paper. Summarize what was found and what you recommended — at the executive level. Think of it as the last thing the CEO reads before deciding whether to implement your recommendations.
Three Points, Two Paragraphs
Paragraph one: The company currently operates with no security controls around a network that handles sensitive payment data and supports remote users. The risks are immediate and significant — both from a technical attack standpoint and from a PCI DSS compliance standpoint. Paragraph two: The recommended solution — deploying an NGFW and an SSL/TLS VPN with MFA — addresses the most critical gaps and provides a foundation to build on. Implementing these controls, combined with the longer-term practices outlined in Section 3.3, positions the company to protect its data, its customers, and its payment processing capabilities.
Do not introduce new information in the summary. No new recommendations, no new threats, no new technical concepts. This section should feel like a close — not an appendix.Mistakes That Cost Points
Writing for a Technical Audience Instead of the CEO
Technical precision matters, but if your paper reads like a Cisco certification guide rather than a consultant report for a non-technical executive, it misses the assignment’s core premise. Every technical term should be explained in functional terms the first time it appears.
Translate Every Technical Point to Business Risk
After naming any technical concept or recommendation, connect it to what it means for the company. “Stateful inspection tracks active connections — this prevents attackers from injecting traffic that appears to be part of a legitimate session, which matters because your payment system maintains ongoing connections with card processors.”
Generic Threat Lists Not Tied to the Scenario
“Common threats include malware, phishing, and denial of service attacks.” That is a textbook sentence. It does not engage with the specific profile: credit card data, remote users, no existing controls. Every threat needs to be framed around this company’s actual exposure.
Anchor Every Threat to the Company’s Specific Profile
Name the threat, then say why it is particularly relevant here. Remote users on unsecured networks and no VPN makes MitM attacks a realistic and immediate risk. No security awareness training and no phishing controls makes social engineering especially dangerous. Context makes the analysis meaningful.
Recommending a Firewall Without Explaining Why That Type
“The company should implement a firewall” is not a recommendation — it is a placeholder. If you recommend a next-generation firewall, you need to explain what that means, why it is better suited than a simpler packet-filtering firewall for this environment, and what capabilities it provides that matter for this use case.
Justify Every Recommendation with Scenario-Specific Reasoning
Recommend the NGFW and explain: deep packet inspection catches application-layer attacks that simpler firewalls miss; built-in IPS reduces the need for a separate appliance the company cannot staff; VPN integration simplifies the remote access architecture. The reasoning is as important as the recommendation itself.
Missing PCI DSS Entirely
A credit card processing company has a specific regulatory framework governing its security obligations. Not mentioning PCI DSS when writing a security report for exactly this type of company is a significant gap — it suggests you either did not know about it or did not connect the dots.
Reference PCI DSS at Relevant Points Throughout
You do not need to summarize the entire standard. But reference it when your recommendations align with its requirements: firewall deployment (Requirement 1), VPN and encryption (Requirement 4), MFA (Requirement 8), patching (Requirement 6). It demonstrates that you understand the compliance context of this company’s specific industry.
Frequently Asked Questions
Need Help With Your Network Security Case Study Paper?
From firewall and VPN recommendations to full 4–6 page consultant reports, our cybersecurity and IT writing team handles network security assignments across undergraduate and graduate programs.
Computer Science Help Get StartedOne More Thing Before You Start Writing
The scenario puts you in a role, not in an exam. That framing matters. A consultant writing to a CEO writes differently than a student answering a test question. Your language should be direct and professional. Your recommendations should be grounded in the specific context — this company, this data, these users — not in abstract best practices that could apply to any organization.
Read the scenario again before you write Section 1.0. Then read it again before Section 3.0. Every recommendation you make should connect to something in that scenario. Remote users? That is why the VPN matters. Credit card data? That is why the NGFW needs application-layer inspection and why PCI DSS applies. No CISO? That is why the implementation phase needs to be practical and manageable for a small IT team.
Write the summary last, after the rest of the paper is done. It should be a true summary of what you found and what you recommended — two paragraphs, no new material. If you write it first, you will spend the paper trying to match a summary you have not earned yet.