Putting everything together for the BSSS design-solution task. Worked scenarios from blank page to defended answer.
The BSSS design-solution task is graded on (1) understanding the scenario's needs, (2) justifying every choice against threats and constraints, and (3) communicating clearly with diagrams. Use this 5-step framework for every design question: Requirements → Threats → Architecture → Controls → Justification. Never skip step 5 — most marks live there.
16.1 The 5-Step Design Framework
Every "design a secure network for X" question follows the same structure. Memorise this — it's your scaffold for the entire task.
Treat steps 1–2 like reading comprehension. Steps 3–4 are where you apply technical knowledge. Step 5 is the explanation that distinguishes a B from an A.
Step-by-step in plain English
Step 1 — Requirements. Re-read the scenario and list what the network must do. How many users? What kind of data? Remote access needed? Compliance requirements (e.g., health data → privacy laws)? Budget constraints?
Step 2 — Threats. What could realistically go wrong for this specific organisation? A dental clinic faces different threats than a software startup. Match threats to the data and operations described.
THE RISK FORMULA — use this throughout your answer:
Risk = Likelihood × Impact
A threat with high likelihood but low impact (e.g., random phishing emails to a small business) is a different kind of risk from one with low likelihood but catastrophic impact (e.g., a nation-state targeting a dental clinic). Good design focuses resources on the highest-risk threats — not every possible threat equally. When you justify a control, you're implicitly claiming "this reduces either the likelihood or the impact of a specific threat." Say that explicitly and you hit top-band reasoning.
Step 3 — Architecture. Sketch the network. Where are the zones (public, internal, sensitive)? Where do the firewalls sit? Where does Wi-Fi go? Where do servers live? A diagram is essential.
Step 4 — Controls. Pick the specific defences. Firewalls (which type), authentication (passwords + MFA), encryption (HTTPS, VPN, full-disk), backups, monitoring, segmentation. Be specific.
Step 5 — Justify. For every control, explain WHICH threat it addresses and WHY it's appropriate for this scenario. "Firewall: yes" is 0 marks. "Stateful firewall between the guest Wi-Fi and the internal network because guest devices are untrusted and could host malware that would otherwise reach our patient records server" is full marks.
THE GOLDEN RULE: Never list a control without explaining what threat it counters. The exam phrase to use: "[Control] is implemented to mitigate [threat] because [mechanism]." This sentence pattern, repeated for every choice, is what scores top marks.
16.2 Worked Scenario A — Small Business (a dental clinic)
The brief
Brightside Dental is a 6-person clinic in Belconnen. They have:
2 dentists, 2 hygienists, 2 reception/admin staff
4 treatment rooms, each with a computer for accessing patient records
1 server in a back office holding patient records, X-ray images, and billing
Wi-Fi for staff, plus they want to offer Wi-Fi to patients in the waiting room
Reception staff occasionally work from home (1 day/week)
They send appointment reminders via SMS gateway
Budget: small business — they're not paying for a dedicated SOC
Design a secure network for Brightside. Justify your choices.
Step 1 — Requirements (read the brief, write a list)
Compliance with the Australian Privacy Act + My Health Records Act
Health data — non-negotiable legal requirement
Backup and disaster recovery
Implied — clinic can't operate without records
Step 2 — Threats (specific to this scenario)
For each threat, make a quick judgment of likelihood (how often does this happen to clinics like this?) and impact (how bad is it if it does?). The highest-risk threats — high on both — are where you spend the most design effort.
Threat
Why it matters here
Likelihood
Impact
Ransomware
Healthcare is a top ransomware target — clinics often pay because they can't operate without records
High
Catastrophic
Data breach (patient records)
Privacy Act notifiable; reputational disaster; potentially identity theft for patients
Medium
Catastrophic
Phishing of staff
Small staff = no dedicated IT = high success rate for attackers
High
High (entry point to everything)
Unauthorised access via patient Wi-Fi
If guest network bridges into internal, any patient with a phone could be a threat actor
Medium
High
Stolen/lost devices
A reception laptop with patient data left in a café = breach
Medium
High
Insider mistakes
Staff accidentally emailing the wrong patient, or reusing passwords
High
Medium
Compromised remote access
WFH reception staff = a path into the clinic if their home setup is weak
Medium
High
The top-right of this table (ransomware, patient data breach, phishing) is where the design should be strongest. That's where defence in depth pays off most.
Step 3 — Architecture (the diagram)
Three separated zones (VLANs). Patient Wi-Fi is fully isolated from staff and servers — even if compromised, it can't reach anything sensitive. Records server is the most restricted zone.
Step 4 — Controls (the specific defences)
Layer
Control
Perimeter
Stateful firewall at the internet edge. Blocks unsolicited inbound traffic. Logs denied connections.
Network segmentation
Three VLANs (Guest, Staff, Server). Firewall rules between them enforce one-way trust: Staff → Server allowed; Server → Staff blocked except for replies; Guest ↔ anything internal blocked.
Wireless
Two SSIDs on the access points. Guest SSID maps to Guest VLAN with captive portal & bandwidth cap. Staff SSID uses WPA3-Enterprise tied to staff accounts.
Remote access (WFH)
VPN gateway on the firewall. Reception staff connect via VPN with MFA before they can reach the staff network. Split tunnelling disabled.
Authentication
Per-user accounts (no shared logins). MFA on all accounts. Password manager. Strong password policy.
Endpoint
Antivirus / EDR on every PC. Auto-updates enabled. Full-disk encryption (BitLocker) on all laptops.
Server
Patient records database encrypted at rest. Access logged. Only specific app servers can reach the database directly (no direct user access).
Backups
Daily encrypted backup to an offsite cloud provider. Backups are immutable (can't be deleted/encrypted by ransomware). Restore is tested quarterly.
Monitoring
Firewall and server logs forwarded to a small SIEM/log service. Alerts on anomalies (e.g., logins outside business hours).
People
Annual phishing-awareness training. Acceptable use policy signed by all staff. Incident reporting line.
Step 5 — Justification (where the marks live)
Now write a justification for each major decision. This is what an examiner reads to decide your grade. Don't shortcut this.
Network segmentation (VLANs): Three isolated VLANs are implemented to mitigate lateral movement — if a patient's phone on the guest Wi-Fi is compromised, or if a staff PC catches malware, the attack cannot directly reach the patient records server. This was a key failure mode in the Medibank breach, where flat internal networks allowed attackers to roam freely after initial compromise.
Stateful firewall + VPN gateway: A stateful firewall blocks all unsolicited inbound traffic, mitigating opportunistic scanning and exploitation attacks. The VPN gateway with MFA ensures that remote-working reception staff can access internal systems, but only after strong authentication — mitigating credential theft attacks against home users.
MFA on all accounts: Mitigates credential-based attacks including phishing, password reuse, and brute force. Even if a staff member falls for a phishing email and gives up their password, the attacker cannot log in without the second factor. MFA attacks the likelihood side of the risk formula — it dramatically reduces the probability that a stolen credential leads to a successful login. Given the small staff size and lack of dedicated IT, the high likelihood of phishing against this clinic makes MFA the single highest-leverage control.
Encrypted, immutable, offsite backups: Mitigates ransomware — the existential threat to a clinic. This control attacks the impact side of the risk formula: ransomware may still succeed, but if primary systems are encrypted, restoring from backup avoids paying the ransom and minimises downtime. Backups must be immutable so they cannot be encrypted or deleted by the same ransomware that hit production. Together with MFA (which reduces likelihood), this is defence in depth applied to the clinic's highest risk.
Encryption at rest on the records server & full-disk encryption on laptops: Mitigates data breach via stolen device and protects the clinic's Privacy Act and My Health Records Act obligations. If a laptop is stolen from a car, the encrypted disk renders the patient data inaccessible — which (in most cases) avoids triggering the Notifiable Data Breaches scheme.
Phishing-awareness training: Mitigates social engineering — the entry point for the majority of breaches. Technical controls cannot fully defend against a staff member voluntarily handing over credentials, so people must be part of the defence.
WHY THIS ANSWER SCORES: Every control is named with its threat. Every threat is plausible for THIS scenario (small clinic with health data) — not generic. Real-world incidents (Medibank) are referenced to show understanding. Australian legal context (Privacy Act, NDB) is named correctly. The diagram supports the prose. The framework is followed end-to-end.
16.3 Worked Scenario B — School Network
The brief
Your school has 800 students, 60 staff, and the following needs:
Wi-Fi across the entire campus
Student devices (BYOD laptops and phones)
Staff laptops
Computer labs with shared desktops
Servers for the LMS (learning management), student records, and administration
Library catalogue accessible from anywhere on campus
Internet access with content filtering (the school is legally responsible for what minors access on the network)
Visitor/parent Wi-Fi for events
Design the network and justify your security choices.
Requirements: ~860 concurrent users, BYOD support, content filtering legally required, separate staff/student/admin/visitor zones, public-facing services (LMS, library) need to work from outside.
Threats: students attempting to bypass filtering or attack school systems (curiosity / showing off), malware on BYOD devices, ransomware (schools are increasingly targeted), data breach (student records contain minors' personal info), DDoS at exam time, account theft (a student logging in as a teacher to change grades).
Architecture (zones):
Admin VLAN — principal, finance, student records — most restricted
Staff VLAN — teaching staff, LMS authoring
Student VLAN — student BYOD and lab desktops
Server VLAN (DMZ) — LMS and library services that need to be reachable from outside
Two firewalls: external (internet ↔ DMZ) and internal (DMZ ↔ internal VLANs) — classic "screened subnet" pattern
Web content filter at the edge (mandatory under ACMA's online safety expectations for schools)
WPA3-Enterprise on staff and student SSIDs, individual accounts (so a single shared password can't leak)
MFA for staff, especially admin accounts
Role-based access control on student records — only specific roles can read/write
Network access control (NAC) — BYOD devices must pass a posture check (OS up to date, AV running) before joining
SIEM / centralised logging
Backups of LMS and records, offsite, immutable
Mandatory cyber-safety education for students
Justification (sample): "The student VLAN is isolated from the admin VLAN by an internal firewall to mitigate the threat of privilege escalation by a curious or malicious student. Even if a student successfully compromises another student's device, they cannot directly reach the records server. This addresses both the technical risk (malware spread) and the human risk (someone trying to change their grades), and aligns with the principle of least privilege."
16.4 Worked Scenario C — A Small SaaS Startup
The brief
A 5-person startup builds a web-based project management SaaS. They have:
5 developers, all working remotely from home
Customer-facing web app hosted on AWS
Customer database with names, emails, project content
Source code in GitHub
No physical office
This is the modern reality — there's no "network" in the traditional sense. Design appropriate security.
Why this scenario is different
There's no office network to defend. Every employee is on their own home network. Every system is in the cloud. The traditional "perimeter" doesn't exist. This is called a zero-trust architecture and it's increasingly common.
Threats: compromised developer laptops (the new perimeter), credential theft (GitHub credentials = source code), AWS account takeover (= total breach), supply chain attacks (malicious npm packages), insider threats (rare in 5-person teams but still possible), the customer database itself being breached.
Controls (no network firewall — different toolkit):
Endpoint security on every laptop — encryption, EDR, automated patching, mobile device management
SSO with MFA on every business tool (GitHub, AWS, email, project tools) — preferably hardware keys (YubiKey) for high-risk admin accounts
Cloud-native firewall rules on AWS (security groups, NACLs) — only the web tier is internet-facing; database tier is reachable only from app tier
HTTPS everywhere with TLS termination at AWS load balancer
Database encryption at rest, audit logging of every query
Secrets management — no API keys in source code, use AWS Secrets Manager
Dependency scanning — automated checks of every new npm/pip package against known vulnerability databases
Backups of customer data — automated, encrypted, restored-tested
Incident response plan — even 5 people need a playbook
Notice how the controls shifted: less "firewall design," more "identity and endpoint." This is what modern security looks like.
16.5 Common Design Mistakes (don't do these)
Mistake
What to do instead
Listing controls without justifying them
For every control, name the threat it addresses
Generic threats ("hacking") with no specifics
Name the actual attack: phishing, ransomware, MITM, etc.
One firewall doing all the work
Use defence in depth — multiple controls, multiple layers
Forgetting backups (until ransomware comes up)
Backups are foundational. Always include them.
Forgetting people (no training, no policy)
The human layer is part of the design, not an afterthought
Forgetting law/compliance
If health/financial/personal data is involved, name the relevant Australian law
No diagram, or a diagram that doesn't match the prose
Diagram and explanation must agree. The diagram comes second, after you've planned the zones.
Treating the cloud as automatically secure
Cloud has shared responsibility — provider secures the platform, you secure your config and data
16.6 The Mark-Scoring Cheat Sheet
For every design question, hit these in your answer:
✅ Restate the requirements — shows you read the scenario carefully
✅ List 4–6 specific threats for THIS scenario (not generic)
✅ Diagram the architecture with zones clearly marked
✅ Name 6+ controls spanning network, identity, endpoint, data, monitoring, people
✅ Justify each control against a specific threat using the formula: "[Control] mitigates [threat] because [mechanism]"
✅ Reference real-world examples (Medibank, Optus, WannaCry) where relevant
✅ Mention Australian law if personal/health/financial data is involved
✅ Acknowledge trade-offs — cost, usability, complexity. No design is perfect.
16.7 Practice Question
A community sports club (200 members) wants a secure network. They have a clubhouse with Wi-Fi, a database of member details and credit card payment records, and a website where members book courts. Design the network and justify your choices. (Try this yourself before reading the answer below.)
Sample structure:
Requirements: ~50 concurrent Wi-Fi users at peak, member database (PII), payment data (PCI-DSS scope), public booking website.
Threats: ransomware (member data unavailable), data breach (PII + payment), phishing of staff with database access, web app attacks on the booking site, insider misuse.
Architecture: Three zones — public DMZ (booking website), internal staff zone (admin PCs), restricted data zone (member database). Guest Wi-Fi separate from any of these. Payment processing OUTSOURCED to a payment provider (Stripe / Square) so the club doesn't store card numbers itself — this drops them out of PCI-DSS scope dramatically.
Controls: Edge firewall, segmentation, WAF on the booking site, MFA for staff, encrypted member database, daily backups (immutable, offsite), HTTPS everywhere, payment processor handles card data (never touches club systems).
Justification example: "Outsourcing card data to a PCI-DSS-compliant payment provider mitigates the entire class of payment data breach threats by ensuring sensitive card information never reaches our systems. This both reduces our attack surface and removes the club from most PCI-DSS compliance obligations — the right trade-off for a small organisation without dedicated security staff."