Secure Software Architecture (Year 12)

Data protection — Secure software protects personal, financial and business data from unauthorised access, change or loss, so users and the enterprise keep trust and avoid breach costs.

Fewer attacks — Building security in from the start minimises cyber attacks and vulnerabilities (fewer exploitable flaws such as injection or broken authentication), which is cheaper than patching after release.

Enterprise benefits — Syllabus list: improved products or services, influence on future software development, improved work practices, productivity, business interactivity.

Collaboration — Safe and secure development benefits from various points of view, delegating tasks by expertise, and a higher-quality solution.

End users — The capabilities and experience of end users shape secure design: novices need simple, guided, hard-to-misuse controls (e.g. password strength meter, clear error messages that do not leak details); experts may need advanced options.

Eight steps — Requirements definition, determining specifications, design, development, integration, testing and debugging, installation, maintenance. (Same eight steps as Year 11.)

Security in each step — Requirements: identify what must be protected. Specifications: state security and privacy requirements. Design: threat-model, least privilege, privacy by design. Development: defensive coding. Integration: check interfaces and APIs. Testing: SAST, DAST, pen test. Installation: harden and configure. Maintenance: patch and monitor.

Confidentiality — Only authorised people can read the information (e.g. encryption, access controls).

Integrity — Data is accurate and has not been changed by an unauthorised party (e.g. hashing, checksums, digital signatures, input validation).

Availability — Authorised users can access the system and data when needed (e.g. backups, redundancy, protection from denial of service).

Authentication — Verifying that a user or system is who they claim to be (password, MFA, biometrics, certificates). 2025 Q6 answer: 'Ensuring that parties exchanging information are who they claim to be'.

Authorisation — Deciding what an authenticated user is allowed to do (roles, permissions, least privilege). Authentication comes first, authorisation second.

Accountability — Actions can be traced to a user (audit logs, timestamps, non-repudiation), so misuse can be investigated.

Security by design — Security is built into the software from the beginning of development, rather than added at the end.

Cryptography — Cryptography converts plain text into cipher text using an algorithm and a key so only holders of the right key can read it. It protects confidentiality (encryption) and integrity/authenticity (hashes, digital signatures).

Symmetric — One shared secret key encrypts and decrypts. Fast, good for bulk data, but the key must be shared safely.

Asymmetric — A public key encrypts and a private key decrypts (or the private key signs and the public key verifies). Solves key sharing but is slower.

Hashing — A one-way function turns data into a fixed-length hash value; the same input gives the same hash and cannot be reversed. Used to store passwords (add a salt) and check integrity.

Sandboxing — Running code in an isolated, restricted environment so it cannot touch the rest of the system if it is malicious or faulty. Examples: browser tabs, app sandboxes, containers, testing untrusted uploads.

Why both — Cryptography protects data itself; sandboxing limits the damage of code. Together they make the software secure by design instead of relying on later fixes.

Definition — Privacy by design builds protection of personal information into the design and operation of software from the start, instead of fixing privacy problems after they occur.

Proactive not reactive — Anticipate and prevent privacy risks before they happen (e.g. threat-model what personal data you collect) rather than responding after a breach.

Embed privacy into design — Privacy is a core part of the architecture and defaults, not an add-on: collect only the data needed (data minimisation), privacy-friendly default settings, encrypt stored data, set retention and deletion rules.

Respect for user privacy — Keep it user-centric: clear consent, transparent notices, and give users control to view, correct, export or delete their data.

Scenario link (2025 Q16c) — Weather app: a process built into the design that regularly deletes identifiable live location data from the cache once it has been used to deliver the weather. Markers wanted privacy-by-design itself (proactive, embedded), not just generic privacy techniques.

Do not write — Do not just list techniques like 'use a password'. Name the approach (proactive / embedded / respect) and tie it to personal data in the scenario.

Regulatory compliance — Making sure software meets laws, regulations and industry standards (2025 Q10 goals: protecting sensitive data from unauthorised access; ensuring applications meet legal and industry standards).

Not goals — Compliance is NOT about limiting updates, letting developers bypass security, or cutting testing time (these were the wrong options in 2025 Q10).

Privacy Act — Australia: the Privacy Act 1988 (Cth) and the Australian Privacy Principles govern how personal information is collected, used, stored and disclosed. (Verified law, not named in the syllabus; the syllabus says 'regulatory compliance'.)

GDPR — The EU's General Data Protection Regulation applies to organisations handling EU residents' data, even overseas companies. (Used in the school notes.)

Copyright and IP — Syllabus social/legal issues: copyright, intellectual property, employment, data security, privacy, digital disruption. Respect licences (e.g. open-source licences like MIT) and credit/permission for code and media.

Social and ethical (2025 Q23a) — Marker sample: secure payment and address data; only authorised staff can access it; pages available in many languages; dish information accurate and representative. Always link to the scenario.

Determine vulnerabilities — Find weaknesses before attackers do (code review, SAST, DAST, vulnerability assessment, penetration testing).

Hardening — Reduce the attack surface: remove unused services and default accounts, apply patches, strong configuration, least privilege, firewalls.

Handling breaches — Have an incident response: detect, contain, investigate, notify affected people/regulators, fix the cause, learn from it.

Business continuity — Plans to keep critical operations running during and after a disruption (backup systems, alternative processes, redundancy).

Disaster recovery — Plans to restore systems and data after a major incident. Key targets: RTO (recovery time objective: how long until it is back) and RPO (recovery point objective: how much data loss, measured in time, is acceptable).

BC v DR — Business continuity keeps the business operating; disaster recovery restores IT systems and data. DR is part of the larger continuity plan.

Programmed backup — Automated scheduled copies (ideally off-site/cloud) support integrity and availability and reduce human error; set the backup frequency from the RPO.

Code review — People (peers) read the source code to find bugs, security flaws and bad practice. Manual; also shares knowledge and improves quality.

SAST — Static Application Security Testing analyses the source code WITHOUT running it, early in development (white-box). Finds issues such as unsafe functions or hard-coded passwords, but can give false positives.

DAST — Dynamic Application Security Testing tests the RUNNING application from the outside (black-box, no source code access), usually later in testing. Finds runtime issues such as injection, XSS, misconfigurations.

SAST v DAST (2025 Q13) — SAST: early (before running), has source-code access. DAST: later (running app), no source-code access.

Vulnerability assessment — Scanning and listing weaknesses, then ranking them by risk so they can be fixed. It identifies; it does not exploit.

Penetration testing — An authorised simulated attack that actively tries to exploit vulnerabilities to show what an attacker could really do.

Pen test v assessment — Vulnerability assessment = find and rank weaknesses. Penetration test = prove they can be exploited.

Defensive input — Never trust user input. Check it, clean it and handle failures so malformed or malicious data cannot crash the program or attack it.

Validation — Checking that input meets rules before use: data type, range, length, format, presence (e.g. age is an integer 0–120; email matches a pattern).

Sanitisation — Cleaning or encoding input to remove or neutralise dangerous characters (e.g. strip or escape tags to stop XSS; use parameterised queries to stop SQL injection).

Error handling — Catch problems with try/except and give a user-friendly message, log the technical detail privately, and never show stack traces or database errors to the user.

Allow-list — Better to accept only known-good values (allow-list) than to try to block known-bad values.

Consequence — Without it: SQL injection, XSS, buffer overflows, crashes and data corruption. With it: the system stays secure, reliable and available.

API — An Application Programming Interface lets one piece of software request services or data from another using defined rules (e.g. a REST API using HTTP and JSON). Stripe payments or Google Maps are third-party API examples.

Excessive data exposure — 2025 Q5 answer: 'Exposure of more data than intended'. Return only the fields the client needs, not the whole database row.

Authentication and authorisation — Require API keys or tokens; check permissions on every request (least privilege).

Validate input — Validate and sanitise all parameters and request bodies; reject malformed requests.

Encrypt in transit — Use HTTPS/TLS so requests and responses cannot be read or changed.

Rate limiting — Limit requests per user/IP to reduce brute force and denial of service.

Error responses — Return correct status codes (400, 401, 403, 404, 500) with generic messages that do not leak internals.

Why important — APIs allow modularisation and speed up development, but each endpoint is an attack surface, so they must be designed safely.

Memory management — Allocating and freeing memory properly (release objects/files when finished, avoid memory leaks, limit buffer sizes). Poor management slows or crashes the program and can be exploited (e.g. buffer overflow).

Session management — Tracking a user's state across multiple requests using a session ID stored in a cookie. Create it on login, make it random and unpredictable, set an expiry/timeout, send it only over HTTPS (Secure, HttpOnly), regenerate on login, destroy on logout.

Session and efficiency (2025 Q20) — Efficient session management limits memory by restricting session data size and lifetime. Reading, writing or storing large objects increases input/output and slows the user. Remove sessions when no longer needed to prevent unnecessary resource use; this reduces database/network bottlenecks and memory leaks and keeps the system scalable and responsive for the user.

Exception management — Anticipating runtime errors and handling them without crashing (try / except / finally). Log details, show a safe message, release resources in finally.

Exception link to security — Unhandled exceptions can reveal stack traces and system details to attackers, and leave resources locked or sessions half-finished.

Broken authentication and session management — Weak login or session handling lets attackers take over accounts (guessable passwords, no lockout, session IDs in URLs, sessions that never expire). Fix: strong password rules and hashing, MFA, lockout/rate limits, secure cookies, session timeout, regenerate session ID after login.

Cross-site scripting (XSS) — Attacker injects malicious JavaScript into a page that other users view, so it runs in their browser (steal cookies/sessions, redirect). Fix: sanitise and escape/encode output, validate input, Content Security Policy, HttpOnly cookies.

Cross-site request forgery (CSRF) — A malicious site tricks a logged-in user's browser into sending an unwanted request (e.g. transfer money) to a site that trusts the browser's cookies. Fix: anti-CSRF tokens, check the origin, SameSite cookies, re-authenticate for sensitive actions.

XSS v CSRF — XSS abuses the user's trust in a site (script runs on the site). CSRF abuses the site's trust in the user's browser (forged request).

Invalid forwarding and redirecting — An app sends users to a URL taken from user input without checking it, which can send them to phishing/malicious sites or bypass access checks. Fix: allow-list valid destinations, avoid user-supplied redirect URLs, check authorisation on the final page.

Race conditions — Two processes/threads access shared data at the same time and the outcome depends on timing (e.g. two purchases of the last item). 2025 Q8 answer: race conditions. Fix: locks, atomic operations/transactions, synchronisation.

File attacks — Attackers target files and file handling: malicious uploads (disguised executables/scripts), path traversal (../ to read other files), and tampering with or stealing stored files.

File protection — Validate file type, size and content (not just the extension), rename and store uploads outside the web root, sandbox/scan them, apply least-privilege file permissions, encrypt sensitive files, and check paths.

Side-channel attacks — Attacks that learn secrets from physical or indirect information leaking from hardware or software, such as timing, power consumption, electromagnetic emissions or sound, rather than breaking the algorithm itself.

Side-channel protection — Use constant-time algorithms and comparisons, add noise or random delays, shield hardware, limit physical access, and keep systems patched.

Example — A timing attack: password check that returns faster when the first characters are right lets the attacker guess one character at a time.

Intro — One line: secure software has benefits (data security, trust) and risks if done badly; name the scenario.

Privacy — Collect only needed data; consent; privacy by design; link to specific data in the scenario.

Data security — Protect personal/payment data with encryption and access control; consequences of a breach (harm to individuals, legal penalties).

Legal — Privacy Act / GDPR compliance; copyright and IP (licences, code reuse).

Employment and disruption — Security roles grow; digital disruption changes jobs and business models.

Judgement — Finish with an assessment: benefits outweigh costs when compliance and user consent are built in.