FIT1047 Chap.14 Vulnerabilities, Attacks, Privacy and Project Synthesis
Vulnerabilities, Attacks, Privacy and Project Synthesis
A vulnerability is a weakness in a specific asset, version, configuration, process or trust relationship; an attack is a sequence that meets prerequisites and uses weaknesses to produce impact. Evidence about applicability, exposure and attacker capability is therefore essential before prioritisation.
This chapter uses attack paths and trees to map social engineering, malware, credential abuse, software flaws, denial-of-service, insider and supplier branches. Vulnerability management covers discovery, risk-based assessment, safe patch/containment, verification and monitoring. Privacy broadens confidentiality by asking purpose, necessity, retention, sharing and individual impact; minimisation reduces breach consequences.
Enterprise analysis links each asset, threat event, weakness, control mechanism, owner and residual risk, then builds a staged portfolio spanning prevention, detection and recovery. The published Project purpose supports real-world vulnerability/attack investigation and controls for a medium enterprise, but no other task structure or deliverable is invented here. Prioritisation is an evidence argument, not a scanner ranking.
Applicability, exposure, attacker prerequisites, business impact, existing controls and uncertainty must be connected before recommending action. Privacy adds purpose, minimisation, retention, sharing and individual impact, while resilience requires tested recovery and operational ownership.
The current A4 evidence supports only the Project's broad purpose; it does not reveal the live organisation, asset list, task structure, word count, required control categories, sources, rubric, presentation or submission mechanics.
What this chapter covers
- 01
Vulnerability applicability and exposure
- 02
Attack paths, trees and prerequisites
- 03
Social engineering, malware and credential abuse
- 04
Patch, configuration and dependency management
- 05
Availability attacks and graceful degradation
- 06
Privacy purpose, minimisation and metadata
- 07
Enterprise control matrices and priorities
- 08
Residual risk, roadmap and operational proof
- 09
Observation-versus-inference claim ledgers
- 10
Remediation verification and monitoring
- 11
Shared dependencies across a control portfolio
AskSia-authored practice weighting (not an official mark scheme): Fresh medium-enterprise file-service analysis
- assetName assets, owners, confidentiality/integrity/availability and retention needs.
- pathsMap stolen credentials, ransomware, excessive groups, public links, insider and supplier branches.
- evidenceConfirm weaknesses such as password-only entry, unmanaged devices and reachable backups.
- portfolioChoose MFA, role reviews, managed access, alerts, minimisation and isolated tested backups.
- operateAssign owners, dependencies, tests and staged implementation.
- residualState residual authorised-endpoint, insider and supplier risks.
Key terms
- Attack path
- A sequence of preconditions and actions connecting a threat to harmful asset impact.
- Exploit prerequisite
- Access, version, configuration, user action or privilege needed before a vulnerability can be used.
- Compensating control
- A temporary or alternative mechanism reducing risk when primary remediation is unavailable.
- Residual risk
- Risk remaining after selected controls operate under their assumptions.
- Data minimisation
- Limiting collection and retention to information necessary for a defined purpose.
- Control portfolio
- A coordinated set of preventive, detective and recovery mechanisms with owners and dependencies.
- Applicability evidence
- Evidence that a reported weakness actually affects the identified asset, version, configuration or trust path and is exposed under the scenario. A generic vulnerability label or scanner result is not yet a complete risk claim.
- Operational proof
- Repeatable evidence that a control is deployed, enforced, monitored and recoverable under authorised tests. A policy statement or configuration screenshot is weaker than a recorded control outcome with an owner and response path.
Vulnerabilities, Attacks, Privacy and Project Synthesis FAQ
Does a scanner finding prove exploitable risk?
No. Confirm affected product/version/configuration, reachable path, prerequisites, asset impact and existing controls. Preserve evidence and false-positive handling.
Is patching the only vulnerability control?
No. Disable features, isolate services, restrict access or monitor as compensating controls while patching is tested. Verify deployed remediation afterward.
Why are backups not enough for ransomware?
They support recovery but do not address data theft, credential compromise or repeat intrusion. Backups must be isolated, protected and restore-tested.
How is privacy different from confidentiality?
Confidentiality limits unauthorised disclosure. Privacy also concerns legitimate purpose, collection, transparency, use, retention, sharing and individual impact.
What is safely known about the Project?
Its published purpose is to investigate real-world vulnerabilities/attacks and propose security controls for a medium enterprise. Verify all current structure and submission requirements in Moodle.
What makes a vulnerability priority defensible?
Connect asset value, applicability, exposure, attacker prerequisites, likely impact, existing controls and uncertainty. Then explain why the proposed treatment changes that path and how deployment will be verified. A severity label alone does not provide this reasoning.
Which A4 details must remain outside this study chapter?
The live organisation and assets, required evidence sources, deliverables, section structure, word count, control categories, presentation, rubric and submission mechanics. Only the published medium-enterprise Project purpose is carried here; current Moodle controls the task.
Assessment move
Create one claim–evidence ledger with date, affected system, authoritative reference and observation/inference label. Map each asset through attack paths with explicit prerequisites; add alternative insider, supplier and recovery branches. For vulnerabilities, confirm applicability/exposure, choose patch or containment, define owner/deadline, verify deployment and monitor for exploitation.
For privacy, list every personal field, purpose, user, copy, retention and deletion path. Build a control matrix covering prevention, detection and recovery, then mark shared dependencies such as identity provider, administrator account or backup repository. Prioritise transparently with uncertainty, cost and impact; stage containment, remediation and architecture.
Every recommendation needs mechanism, owner, operational test and residual risk. Follow the live Project brief independently rather than using these headings as a predicted template. Use the supplied textbook to confirm concept scope, not to copy attack diagrams, vulnerability descriptions, control tables, wording or solutions. Build every evidence ledger and portfolio from original or properly cited authorised material.
Follow the current A4 brief independently and do not convert this study workflow into a forecast of required sections.
Working through Vulnerabilities, Attacks, Privacy and Project Synthesis in FIT1047? Sia is AskSia’s AI Computer Science tutor — ask any FIT1047 Vulnerabilities, Attacks, Privacy and Project Synthesis question and get a clear, step-by-step explanation grounded in how FIT1047 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
