Software Engineering › Notes › Secure Software Architecture (Year 12)
Secure Software Architecture (Year 12)
Describe the benefits of developing secure software
- 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.
Fundamental software development steps for secure code
- 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.
Fundamental software design security concepts (six words)
- 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.
Cryptography and sandboxing in 'security by design'
- 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.
Privacy by design (syllabus: three parts)
- 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 and legal issues
- 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.
Test and evaluate security and resilience
- 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 security strategies: code review, SAST, DAST, vulnerability assessment, pen testing
- 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 data input handling: validation, sanitisation, error handling
- 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.
Safe APIs to minimise vulnerabilities
- 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.
Efficient execution: memory, session and exception management
- 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.
User action controls: broken authentication, XSS, CSRF, forwarding, race conditions
- 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 and side-channel attacks
- 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.
Skeleton: Assess/Discuss social, ethical and legal issues of secure software (5-6 marks)
- 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.
Part 2. School notes (Canvas, 12SENX2) by syllabus dot point
Corrections are marked in the text. Anything not marked is the school wording.
Describe the benefits of developing secure software, including data protection and minimising cyber-attacks and vulnerabilities.
Developing secure software is vital in an evolving landscape of new threats. Secure software protects sensitive information against malicious activities. It safeguards users and organisations to enhance the overall trustworthiness and reliability of the product.
Data Protection
Secure software ensures data is handled and stored to prevent unauthorised manipulation and loss.
Encryption
Encryption is converting data into a code to prevent unauthorised access. It ensures that information is only accessible to those with the correct decryption key and unreadable to anyone without it.
E.g.: AES-256 encryption
Access Control
Access controls are security measures that regulate who can view or modify data within a system, ensuring that sensitive information is only accessible to authorised individuals.
E.g.: Role-based access control to limit what students/teachers can see on Canvas pages
Data Integrity
Data integrity refers to the accuracy and consistency of data over its lifecycle. It involves protecting data from being altered or corrupted.
Minimising Cyber Attacks and Vulnerabilities
Regular Security Audits
Securing Coding Practices
Securing coding practices are a set of guidelines that developers follow to write code resistant to common vulnerabilities such as SQL injection, XSS and buffer overflows
E.g.: The usages of validation and sanitisation of data before user input gets stored
Patch Management
Patch Management is the process of regularly updating software to fix known vulnerabilities.
E.g.: An automated patch management system to ensure all software is updated with its latest security patch.
Interpret and apply fundamental software development steps to develop secure code, including requirements definition, determining specifications, design, development, integration, testing and debugging, installation and maintenance.
Requirement Definition
The requirement definition involves gathering and documenting the software's functional and non-functional requirements.
Client Scenario:
Understanding the client's needs and expectations regarding security features. This involves meeting the client to discuss their requirements and the security threats relevant to their context.
Environment Specifications:
Defining the operational environment, including hardware, software, and network considerations, to ensure security compatibility. This step involves assessing the current environment to identify any security gaps that must be addressed.
List of Objectives:
Creating a comprehensive list of specific, measurable security objectives that the software must achieve. E.g.: Data encryption, access controls.
Determining Specifications
Determining specifications involves creating a detailed description of the software's functionality and technical requirements, focusing on how it will meet the defined security needs.
Technical Requirements:
Defining specific technical requirements, such as encryption standards and data handling protocols, to form the backbone of robust, effective software.
Performance Criteria:
Establishing security-related performance benchmarks, such as response times for security features and the capacity to handle security events,
Compliance Standards:
Identifying and incorporating relevant security compliance standards that the software must adhere to, such as GDPR.
Input Process Output Model [IPO]:
IPO helps understand how data flows through the system and where security controls need to be applied.
Gantt Charts:
The Gantt chart provides a visual timeline of the project, helping to ensure that each task is completed on time and security milestones are met.
Design
The design phase involves creating a blueprint for the software, including architecture, data flow, and user interfaces, while embedding security principles.
System Architecture:
Designing a secure architecture that incorporates layers of security, such as firewalls, encryption, and secure access points.
Modelling Tools:
Structure Chart:
Used to represent the hierarchy and relationships between modules in the software, ensuring that secure data flow and control mechanisms are clearly defined.
Class Diagram:
Represents the system's classes, attributes, methods, and relationships, with attention to secure data handling and encapsulation of sensitive information.
Data Flow Diagram (DFD):
Maps out how data moves through the system, identifying where data must be protected during transmission and processing.
UI Design:
Ensuring the user interface supports secure interactions, including secure login processes and protection against unauthorised access.
Storyboards:
Storyboards visually represent a user’s interaction with the system to help develop UI, focusing on secure navigation and intuitive UX.
Data Dictionaries:
Develop a data dictionary to document all the data elements. The data dictionary ensures that data is consistently, efficiently and securely handled throughout the system, such as storing text in a field meant for numbers.
Pseudocode:
Pseudocode helps ensure that security measures, such as input validation and error handling, are planned and implemented correctly.
Logbooks:
Maintaining a logbook to document decisions, design changes, and security considerations throughout the design phase.
Development
The development phase is where the software is coded, with an emphasis on secure coding practices to prevent vulnerabilities.
- Secure Coding Standards
- Version Control
- Code Review
Integration
Integration involves combining individual components into a fully functioning system and ensuring that security controls work across the system. It is tested through integration testing
Testing and Debugging
Check if the program runs smoothly and fits the requirements. It involves identifying and resolving issues, focusing on uncovering security vulnerabilities.
- SAST
- DAST
- Vulnerability scanning
- Penetration Testing
- Regression Testing
- User Acceptance Testing
Installation
The installation phase involves deploying the software in a production environment. Secure configuration applied during installation helps maintain the software’s integrity and confidentiality from the start. Tests will be performed after installation to verify the functionality of the software.
E.g.: Setting strong passwords, disabling unnecessary services, and configuring firewalls
Maintenance
Maintenance involves ongoing updates and software monitoring to address new security threats.
Security Patching
Monitoring
Continuously monitoring the software for security breaches or unusual activity, allowing for a quick response.
Incident Response:
Having a plan to respond to security incidents promptly minimises the impact of any breaches.
Describe how the capabilities and experience of end users influence the secure design features of software.
Balance is needed between usability and security.
User Capability
User capabilities refer to the technical knowledge that end users possess.
Simplified Security Controls
Security features must be straightforward to use for users with limited technical skills. E.g.: Automating complex security tasks, providing clear instructions
Guided Processes
Software should guide users through security-related processes, such as setting up 2FA or managing permissions, to ensure they do not inadvertently compromise security.
Role-Based Access [RBAC]
Implementing RBAC can help tailor security features to the user's level of expertise, granting more power to experienced users while limiting potential risks for less experienced users.
User Experience
UX levels refer to users' familiarity with similar software or security practices. Users with varying experience levels may require different approaches to secure design.
Customisable Security Settings
More experienced users may prefer customisable security settings that allow them to tailor the software to their needs. E.g.: selecting encryption methods.
Default Security Settings
For less experienced users, secure default settings can protect the user without requiring extensive configuration. These settings should be robust enough to prevent common security issues while remaining easy to use.
Training and Support
Providing training materials and support options, such as tutorials or customer support services, helps users of all experience levels understand and use the software's security features.
Usability vs. Security
While security is paramount, the software must also be usable by its intended audience.
Minimising User Friction
Security features should minimise disruption to UX.
E.g.: streamlining authentication processes
Transparency of Security Features
Providing straightforward but non-intrusive notifications about security events or updates helps keep users informed without overwhelming them.
Adaptive Security
Adaptive security measures can be adjusted based on user behaviour and risk levels.
E.g.: the software might prompt additional verification if unusual activity is detected
When developing programming code, explore fundamental software design security concepts, including confidentiality, integrity, availability, authentication, authorisation, and accountability.
Confidentiality
Confidentiality ensures that sensitive information is accessible only to those authorised to view it. In web applications, this involves encrypting data and securing communications.
Integrity
Integrity ensures that data is accurate and has not been tampered with.
E.g. hashing algorithms can verify data integrity.
Availability
Availability ensures that systems and data are accessible to authorised users when needed.
E.g. rate limiting can be implemented to prevent DoS attacks.
Authentication
Authentication is the process of verifying a user's identity.
E.g: Username and password system
Authorisation
Authorisation determines what an authenticated user is allowed to do.
E.g.: RBAC system and Attribute-based access control [ABAC] system
Accountability
Accountability ensures that actions can be traced back to the responsible user.
E.g. logging user action.
Apply security features incorporated into software, including data protection, security, privacy and regulatory compliance.
Data Protection
Data protection is an approach to safeguarding data from vulnerabilities while ensuring its confidentiality, integrity, and availability. It involves implementing various security measures to protect data throughout its lifecycle, whether stored, processed, or transmitted.
Encryption - prevents unauthorised access – e.g.: AES for data storage, TLS for data transmission.
Access Controls - Ensure only authorised personnel can access sensitive data – e.g.: RBAC
Backups
Regularly back up data to secure locations to prevent data loss due to accidental deletion, corruption, or attacks like ransomware
Security
Software security protects users from threats, ensuring their data and interactions with the software remain safe. This involves implementing various security measures, such as
- Multi-factor authentication (MFA)
- Strong Passwords
- RBAC
- Access Control List [ACL]
- Client and server-side Input Validation
- Security Audits
Privacy
Privacy in secure software protects an individual's personal data and information.
Data Minimisation
Stores only what is necessary to prevent privacy breaches.
User Consent
Obtaining a user from the user client of obtaining permissions before collecting or processing data. Creating UI that has buttons or checkboxes for a consent form.
Data Access Controls
Regulatory Compliance
Achieving regulatory compliance means aligning with legal and regulatory guidelines applicable to the region.
Compliance Audits
Regularly conduct audits to ensure that the software complies with relevant regulations.
Data Retention Policies
Implement data retention policies that comply with regulations, specifying how long data is stored and when it should be deleted.
User Consent
Ensure users consent before their data is collected, processed, or shared. This is especially important for sensitive personal data.
Use and explain the contribution of cryptography and sandboxing to the ‘security by design’ approach in developing software solutions.
Security by design
The ‘security by design’ approach involves integrating security measures into the software development process rather than adding them as an afterthought.
Cryptography
Cryptography secures information by transforming it into an unreadable format that can only be deciphered with the correct key. This technique protects sensitive data and ensures its confidentiality, integrity, and authenticity.
Contribution to ‘Security by Design’:
Confidentiality
Cryptography ensures that sensitive information remains private by encrypting data to only be accessible to authorised users.
Integrity
Cryptographic techniques, such as hashing, verify that data has not been altered during transmission or storage.
Authentication
Cryptography is used in authentication processes to verify the identities of users.
Non-repudiation
Digital signatures, a form of cryptographic evidence, provide proof of the origin and integrity of data, preventing parties from denying their actions.
Sandboxing
Sandboxing is a security mechanism that isolates running processes, limiting their access to the system and preventing them from making permanent changes. Sandbox can run applications in isolation to test untrusted code in a controlled environment, containing any malicious behaviours in the sandbox without risking the entire system’s security.
E.g.: Python subprocess module
Use and explain the 'privacy by design' approach in the development of software solutions, including a proactive not reactive approach, embed privacy into design, respect for user privacy
The main principles of privacy by design help protect users’ personal information and comply with privacy regulations.
Embed privacy into design
Embedding privacy into the design means that privacy measures are integrated directly into the software's architecture, ensuring privacy is considered at every step of the development process. Personal data collection should be minimised to reduce the risk of data exposure.
Proactive, not reactive approach
Instead of reacting to privacy breaches after they have been detected, a proactive approach ensures that potential privacy issues are mitigated before they occur. In the initial stages of the software development cycle, privacy impact assessments (PIAs) are conducted to identify and evaluate potential risks.
E.g.: data anonymisation, data minimisation, encryption
- Risk Assessment
- Prevention Over Detection
Respect for user privacy
Respecting user privacy is user-centric. It means giving users active control over their data (edit, delete, export) and ensuring transparency in handling their data. Users should know how their data are collected, processed, and stored through understandable privacy policies.
E.g.:
- Provides unambiguous consent to the use of private data
- User data sharing should be limited with external third parties, ensuring confidentiality.
Test and evaluate the security and resilience of software by determining vulnerabilities, hardening systems, handling breaches, maintaining business continuity and conducting disaster recovery.
Testing and evaluating software security and resilience ensure systems remain robust against attacks and recover quickly to maintain business continuity. This process involves determining vulnerabilities, hardening systems, handling breaches, and implementing disaster recovery plans.
Determining Vulnerabilities
Vulnerabilities are weaknesses in software that attackers can exploit.
Penetration Testing [Pen Testing]
Pen Testing involves ethical hackers attempting to exploit system weaknesses to identify potential vulnerabilities before attackers do.
Automated Vulnerability Scanning
Tools like Nessus scan systems for known vulnerabilities.
Code Audits and Reviews
E.g.: Financial institutions continuously automate vulnerability scanning to detect vulnerabilities. Periodic pen testing simulates real-world attack scenarios, allowing the organisation to discover and fix vulnerabilities before attackers can exploit them.
Hardening Systems
Hardening involves securing a system by reducing its potential attack surface.
Minimising Attack Surface
Remove unnecessary services, ports, applications, and features to reduce the points of entry for attackers.
Regular Patching and Updates
E.g.: A global tech company enforces least-privilege access control policies and regularly patches its systems using automated tools.
Handling Breaches
A security breach occurs when an attacker gains unauthorised access to a system. Effectively handling a breach involves detecting, containing, and mitigating the damage caused.
Incident Response Teams [IRTs]
Dedicated teams trained to detect, contain, and mitigate security breaches. These teams follow incident response plans, which outline procedures for addressing breaches.
Containment and Mitigation
When a breach is detected, affected systems are isolated to prevent the attacker from moving laterally within the network. Mitigation involves fixing the exploited vulnerability and preventing further attacks.
Forensic Investigation
After containment, forensic investigators analyse logs to determine how the breach occurred and what data was compromised.
Maintaining Business Continuity
Business continuity ensures that operational uptime is maintained despite system disruptions.
Redundancy and Failover
Critical systems have backups that automatically take over in a failure. Cloud-based failover systems ensure that if one server goes down, another seamlessly takes over.
Data Backups
Regular backups ensure that the organisation can restore its systems in case of a data loss. Cloud backups or off-site storage ensure that data is protected even if the physical infrastructure is compromised.
Business Continuity Plans (BCPs)
BCPs outline how to maintain operations during a system outage. These plans include steps for failover, key personnel assignments, and system recovery.
E.g.:
An e-commerce platform mirrors user data with failsafe servers, routing customers through the failsafe server in case of downtime to allow customers to make purchases during system failure.
Conducting Disaster Recovery
Disaster recovery focuses on restoring systems after a significant event, such as a security breach. The aim is to recover quickly and minimise long-term impact.
Disaster Recovery Plans (DRPs)
A DRP includes the steps needed to restore critical systems and services.
- Systems are prioritised for restoration
- Resources are allocated for recovery
Backup Restoration
Backup Restoration should be tested regularly to ensure it can be used in data loss events. Offsite or cloud backups are commonly used for redundancy.
Recovery Time Objective (RTO) and Recovery Point Objective (RPO)
Organisations set goals for how quickly services must be restored (RTO) and how much data loss is acceptable (RPO). These metrics help define recovery processes and ensure that critical services are restored within acceptable timeframes.
E.g.:
A bank performs regular disaster recovery drills to ensure it can restore operations within minutes of a failure. Data is mirrored across multiple servers, ensuring that the most recent transactions can be recovered and no critical data is lost.
Apply and evaluate strategies used by software developers to manage the security of programming code, including code review, static application security testing (SAST), dynamic application security testing (DAST), vulnerability assessment and penetration testing.
Code review
Programmers overlook errors within their code. In a professional setting, colleagues run code to identify errors or mistakes, called a Code Review. Generally, these are done in the text through comments.
SAST [Static Application Testing]
SAST is a passive testing method that examines the codebase without execution. It searches for matching vulnerability patterns it has previously identified. SAST is fast and does not require time or resources to execute the program.
E.g.: Bandit on Python
DAST [Dynamic Application Testing]
DAST is a black box testing method that evaluates an application's security while running. It simulates external attacks on the application to identify vulnerabilities that attackers could exploit by sending inputs and running the application.
E.g.: OWASP ZAP
| SAST | DAST |
|---|---|
| Source Code is Required | A running application is required |
| Vulnerabilities found earlier in development are less expensive to fix | Vulnerabilities found later in development are more expensive to fix |
| Unable to identify Timing and Environment-related issues | Can identify Run-Time and Environment-Related Issues. |
| Pre-code check-in Check | More extensive testing can be done |
| Nightly Scans | |
| High compatibility with all software |
Vulnerability assessment
The Vulnerability Assessment process involves identifying, quantifying, and prioritising vulnerabilities within a system.
E.g. automatic load testing and manual integration testing to test XSS Vulnerabilities
Design, develop and implement code using defensive data input handling practices, including input validation, sanitisation and error handling.
Input Validation
Type Checking: Ensure the input is of the expected data
Length Checking: Restrict input data length
Range Checking: Validate that numerical inputs fall within an expected range
Mandatory Fields: Ensure that required fields are not left blank.
Sanitisation
- Escaping characters: Replacing potentially dangerous characters (like <, >, ', etc.) with safe representations.
- Whitelist-based filtering: Accepting only known good input (e.g., allowing only alphanumeric characters for usernames).
- Converting Data Types: Command-line inputs are strings, and the code requires the type to be a number/integer for calculations.
Error Handling
In Python, error-handling messages can be used with the print() function to help log errors
Design, develop and implement a safe application programming interface (API) to minimise software vulnerabilities.
An application programming interface (API) is the intermediary that allows two software applications to interact. It includes a set of rules, protocols, and definitions that determine how API responses should be formatted.
Design, develop, and implement code that considers efficient execution for the user, including memory management, session management, and exception management.
Memory Management
Efficient memory management optimises system resources, preventing memory overconsumption and potential system crashes. Programmers should avoid creating unnecessary objects.
Session Management
Session management helps maintain user state across multiple requests. Efficient session management ensures that resources are not overused and user data is handled securely. Implementing session timeouts reduces memory consumption by closing inactive sessions. Only essential information should be stored in sessions to minimise the head.
Exception Management
Proper exception management ensures that an application can reliably handle errors without crashing or exposing sensitive information to users.
- Catch Specific Exceptions
- Log Errors for Debugging
Design, develop and implement secure code to minimise vulnerabilities in user action controls, including broken authentication, session management, cross-site scripting (XSS), cross-site request forgery (CSRF), invalid forwarding and redirecting and race conditions.
Broken Authentication
Broken authentication occurs when authentication mechanisms are not implemented securely.
E.g.: Weak password, password insecure storage, password reuse
Mitigation strategies: enforce strong password policies
Session Management
Session management controls how sessions are created, maintained, and destroyed. Insecure session management can lead to session hijacking and fixation attacks.
Mitigation strategies: Session expiration, randomly generated tokens, and hashed storage.
XSS
XSS is a client-side vulnerability where an attacker injects malicious JavaScript into a website or its backend storage. When the malicious script runs, the attacker can gain unauthorised access to sensitive information and the system.
Mitigation strategies: input sanitisation and validation, strict content security policy to restrict the execution of inline scripts
CSRF
Cross-site request forgery occurs when an attacker forges a request as an authenticated user with valid session tokens. The attacker can forge requests to interact with a malicious website and access sensitive information.
Mitigation strategies: CSRF tokens to verify the session and corresponding user actions
Invalid Forwarding and Redirection
Invalid forwarding and redirecting occur when attackers manipulate URL parameters to redirect users to unintended locations or bypass authentication.
Mitigation strategies: Restrict redirects to a predefined list of trusted URLs, implement user access controls, sanitise any user-controlled input like URLs and parameters
Race Conditions
Race conditions occur when multiple processes access and manipulate shared resources unsynchronised, leading to data corruption or unintended behaviour.
Mitigation strategies: Locking mechanisms (mutexes), atomic operations
Design, develop and implement secure code to protect user file and hardware vulnerabilities from file attacks and side-channel attacks.
File Attacks
File attacks exploit weaknesses in how a program accesses or handles files.
Buffer Overflow: Writing more data into a buffer than it can hold, causing memory corruption, which may lead to arbitrary code execution.
Side-Channel Attacks
Side-channel attacks exploit indirect information leakage, such as timing, electromagnetic emissions, or power consumption, to infer sensitive data.
Power Analysis: Observing power consumption during cryptographic operations to derive keys.
Apply and describe the benefits of collaboration to develop safe and secure software, including considering various points of view (POV), delegating tasks based on expertise and quality of the solution.
Considering various POV
Fostered by their unique specialisation and experiences, each developer on the team brings diverse solutions that reduce the risk of vulnerabilities.
E.g.: A frontend security developer might suggest adding multi-factor authentication for users. An encryption expert advocates for securing sensitive data during transmission. Together, they create a more secure system than either could have designed alone.
Delegating Tasks Based on Expertise
Effective collaboration involves knowing each team member’s strengths and delegating tasks accordingly. By assigning specific security tasks to those most qualified, you ensure that the work is done efficiently and with a higher skill level.
E.g.: A web development team assigns a developer with experience in cryptography to implement data encryption, one familiar with secure authentication to design the login flow.
Quality of Solution
When multiple developers review the same code, they are more likely to catch mistakes or suggest improvements, leading to more resilient software. Collaborative testing ensures that security features are tested adequately from multiple angles, reducing the risk of leaving potential attack vectors open.
E.g.: A team is developing a secure messaging app. After implementing E2E encryption, they collaborate on testing the encryption mechanism. One team member suggests testing for potential timing attacks, while another focuses on testing message integrity in case of data corruption.
Investigate and explain the benefits to an enterprise of implementing safe and secure development practices, including improved products or services, influence on future software development, productivity, and business interactivity.
Improved Products or Services
When security is proactively integrated from the beginning of the development cycle, the product is more resilient and less vulnerable to cyberattacks.
E.g.:
A cloud storage company prioritises secure development by implementing data encryption. As a result, their platform gains clients' trust, attracting more businesses seeking secure data storage solutions.
Influence on Future Software Development
Once an organisation establishes a security-first mindset, over time, this proactive approach results in more efficient, secure development processes when secure development practices are standardised and secure libraries are created for reuse.
E.g:
By developing secure authentication libraries, the company ensures that these components are used consistently across all future projects, improving security and reducing development time.
Productivity
Although integrating security into the development lifecycle may initially take extra time, it saves time and resources in the long run by avoiding costly post-release patches and security audits. Additionally, by incorporating security into software development, companies can focus more on feature innovation.
E.g.:
A SaaS company integrates security testing into its CI pipeline, catching vulnerabilities in the development process. As a result, the team avoided the frequent patches that had previously disrupted their release schedule.
Business Interactivity
Software with more secure data practices meets stringent compliance requirements like GDPR, allowing customers to build trust more easily and have a higher customer retention rate. This leads to stronger, more collaborative relationships and a competitive edge in the marketplace.
E.g:
A healthcare technology company created HIPAA-compliant software, allowing it to secure exclusive partnerships with a big hospital, as its competitors can’t offer the same level of security.
Evaluate the social, ethical and legal issues and ramifications that affect people and enterprises resulting from the development and implementation of safe and secure software, including employment, data security, privacy, copyright, intellectual property and digital disruption.
Employment (Social)
Social: New Jobs - Roles like security engineers and ethical hackers have emerged as critical to secure software development.
Ethical: Workforce Displacement –obligated to ensure fair replacement of low-level iT
roles
Legal: Workforce Displacement – fair contract discussion relating low-level IT role termination
Data Security (Ethical)
Social: Individual privacy concerns, such as identity theft, financial fraud, and reputational damage
Ethical: Ethical obligation to protect user data with encryption
Legal: Companies must comply with legal regulations such as GDPR, HIPAA, which enforce strict standards for data handling to ensure privacy and security.
Privacy (Ethical)
Ethical: Developers must implement privacy features, such as data anonymity and encryption, to prevent abuse.
Social: Secure software must prevent unauthorised personal data and give users control over how their information is collected and used.
Legal: Privacy laws that regulate how personal data is handled and store, such as GDPR.
Copyright (Legal)
Social: Impedes the dissemination of ideas
Ethical: Obligation to acknowledge others’ work and avoid plagiarism.
Legal: Developers rely on copyright under the Australian Copyright Act 1968 to safeguard their intellectual property from unauthorised use.
Intellectual Property (IP) (Ethical & Legal)
Social: Impedes the dissemination of ideas
Ethical: Obligation to control ownership of ideas and inventions, avoiding theft
Legal: The legal frameworks for software IP are not always clear-cut, particularly in cases where multiple parties have contributed to the development process.
Digital Disruption (Social)
Enterprises must adapt to new secure technologies or risk falling behind competitors. While secure software helps enterprises protect themselves against cyber threats, it can also disrupt by making certain technologies or business models obsolete.
E.g.:
A financial services company uses blockchain technology to secure transactions, disrupting traditional banking models by offering faster, secure transactions at lower costs. Competitors that fail to implement similar technology struggle to keep up.
Part 3. Where this has been examined (see ../../question_bank.md)
| ID | Marks | Source | Topic / type |
|---|---|---|---|
| hsc2025-q5 | 1 | 2025 HSC | API vulnerabilities (multiple choice) |
| hsc2025-q8 | 1 | 2025 HSC | User action controls (multiple choice) |
| hsc2025-q10 | 1 | 2025 HSC | Regulatory compliance (multi-select) |
| hsc2025-q13 | 2 | 2025 HSC | SAST and DAST (table / drag (SAST v DAST)) |
| hsc2025-q16c | 3 | 2025 HSC | Privacy by design (short answer (describe)) |
| hsc2025-q19 | 3 | 2025 HSC | Developing secure code (Python) (Python) |
| hsc2025-q20 | 3 | 2025 HSC | Session management (short answer (describe)) |
| hsc2025-q23a | 3 | 2025 HSC | Social and ethical issues (short answer (outline)) |
| hsc2025-q23c | 3 | 2025 HSC | Fundamental software design security concepts (table / dropdown) |
| sample-q3 | 1 | Sample Exam | Encryption (multiple choice) |
| sample-q8 | 2 | Sample Exam | SAST and DAST (table (classify SAST/DAST)) |
| sample-q18a | 3 | Sample Exam | Defensive data input handling (short answer (explain, max 75 words)) |
| sample-q18b | 3 | Sample Exam | Developing secure code (Python input validation) (Python (function)) |
| sample-q19 | 4 | Sample Exam | Authentication and authorisation (short answer (explain, max 75 words)) |
| sample-q22b | 3 | Sample Exam | Race conditions (short answer (example + outline, max 75 words)) |
| fam-q1 | 1 | Familiarisation | Development steps (drag into order) |
| fam-q6 | 3 | Familiarisation | Sandboxing (short answer (discuss)) |
| fam-q9b | 3 | Familiarisation | Developing secure code (Python input validation) (Python (function)) |
| fam-q11a | 1 | Familiarisation | Cross-site scripting (multiple choice) |
| fam-q11b | 2 | Familiarisation | Cross-site scripting (short answer (explain)) |
| sdd2021-q25 | 11 | Old SDD (old syllabus) | Implementation and development approach (extended) |
| sdd2022-q21 | 3 | Old SDD (old syllabus) | Social, ethical and legal responsibilities (short answer / extended) |
| sdd2023-q23 | 5 | Old SDD (old syllabus) | Security and authentication (short answer / extended) |