Software


🟦 BOX 1 — LESSON 1: ORGANISATIONS

KEY DEFINITIONS

Organisation = people working together for a purpose.

Mission = why organisation exists / what it does now.

Vision = what organisation wants to become in future.

Goal = BIG, broad, long-term achievement.

Objective = SMALL, specific, measurable step toward goal; has NUMBER + DEADLINE.

Strategic plan = long-term plan setting out organisation's goals.

⭐ ORDER

MISSION → VISION → GOALS → OBJECTIVES

Why → Future → Big → Small/measurable

GOAL vs OBJECTIVE

GOAL: big + long-term + broad
→ “Become most trusted bank in Australia.”

OBJECTIVE: specific + measurable + number + deadline
→ “Reduce app crashes by 30% by June.”

CASE STUDY

Software exists because organisation wants something to change/improve.

Coles → shorter queues
Myki → no paper tickets
School → attendance tracking

Question: Does software support/damage organisational goals?

→ Goal → software practice → effect → supports/damages goal

SPOTTING

increase / become / maintain / keep → often GOAL

NUMBER + TIME → OBJECTIVE

🟩 BOX 2 — LESSON 2: DEVELOPMENT

DEFINITIONS

In-house = organisation's own employees build software.

External / outsourcing = another company is paid to build software.

Contractor = person/company paid to work but not employed by organisation.

NDA = contract restricting use/sharing of confidential information.

Due diligence = carefully checking risks/liabilities before trusting another company.

Least privilege = give users ONLY the access needed, nothing more.

Open source = source code freely available + can be modified.

Cloud = internet-based storage/processing.

IN-HOUSE

✅ more control over data
✅ organisation controls developers/access
✅ sensitive information stays internal
❌ may lack specialist skills
❌ security expertise may be limited
❌ expensive/time-consuming

EXTERNAL

✅ specialist skills
✅ up-to-date security tools
✅ potentially cheaper/faster
❌ data leaves organisation
❌ third party needs system access
❌ third party may have vulnerabilities
❌ legal responsibility must be clear

🚨 GOLDEN RULE

EXTERNAL → LEAST PRIVILEGE

Give JUST ENOUGH ACCESS.

❌ NEVER real customer data
✅ FAKE/TEST DATA

Use:
NDA + due diligence + encryption + least privilege + test data

CASE STUDY: COURT TRANSCRIPTS

Sensitive legal data sent offshore.

Vulnerability: inadequate protection/access controls
Control: NDA + encryption + least privilege + due diligence
Principle: privacy/confidentiality
FIRST: secure/restrict access + investigate exposure

SCENARIO ANSWER

Choose in-house/external → reason 1 → reason 2 → security/data impact

🟥 BOX 3 — LESSON 3: VULNERABILITIES

🚨 MOST IMPORTANT

THREAT = something that could cause harm.

VULNERABILITY = weakness a threat can exploit.

RISK = likelihood + severity of harm.

⭐ FORMULA

THREAT uses VULNERABILITY → IMPACT/RISK

Example:

Hacker = threat
No MFA = vulnerability
Unauthorised access = risk/impact

API

API = allows programs to communicate/request data.

Think DOOR.

Authentication = WHO are you?

Authorisation = ARE YOU ALLOWED?

Rate limiting = HOW MANY requests?

OPTUS

Vulnerabilities:

  • ❌ no authentication

  • ❌ no authorisation

  • ❌ no rate limiting

  • ❌ exposed test environment

→ customer IDs could be manipulated
→ unauthorised access to personal data

Control: authentication + authorisation + rate limiting + secure test environment.

MALWARE

Malware = malicious software that damages/infiltrates systems.

Virus → attaches to files/spreads

Worm → self-replicates across network

Trojan → looks legitimate / creates backdoor

Ransomware → locks/encrypts data + demands payment

Exploit → takes advantage of vulnerability

PATCHES

Patch = update fixing known vulnerability.

Unpatched → known weakness → attacker exploits → compromise

IAM

IAM = Identity & Access Management

Controls WHO can access + WHAT they can access.

Weak IAM:

  • shared accounts

  • no MFA

  • old accounts active

  • excessive permissions

MFA = 2+ verification factors
e.g. password + code.


🟨 BOX 4 — LESSON 4: PEOPLE + ENVIRONMENTS

INSIDER THREAT

Threat involving someone with legitimate access.

Accidental → mistake

Malicious → intentionally causes harm

Compromised → their account is stolen

🚨 CONTRACTOR ACCOUNT = INSIDER ACCESS

SOCIAL ENGINEERING

Social engineering = tricking people into giving access/info or performing unsafe action.

Phishing → fake email/message

Smishing → phishing via SMS

Pharming → redirects to fake website

Tailgating → follows authorised person through secure door

Credential stuffing → reused/stolen passwords used on other accounts

CONTROLS

Phishing → training + verify sender/links
Tailgating → don't allow unknown people through
Credential stuffing → unique passwords + MFA

MITM

Man-in-the-middle = attacker intercepts communication between parties.

Defence → encryption in transit

THIRD-PARTY RISK

Your software uses someone else's code/service.

Their vulnerability → YOUR software may be vulnerable.

Controls:

  • due diligence

  • security reviews

  • updates

  • access controls

DEV / TEST / PRODUCTION

DEV = build software

TEST = test software

PRODUCTION = live system/real users

🚨 KEEP SEPARATE

If combined:

  • developers may access real customer data

  • untested code can reach users

  • mistakes affect live system

  • harder access control/tracking

YES 😭 cutting it WAY down. This is what you actually put on the sheet.

🟪 LESSON 5 — SECURITY CONTROLS

6 CONTROLS:

  1. Version control → records WHO/WHAT/WHEN; rollback → prevents bad/unauthorised changes

  2. IAM → controls WHO accesses WHAT → prevents unauthorised/excessive access

  3. Encryption → protects data at rest + in transit → prevents data being read/stolen

  4. Code review → checks code before release → catches security bugs

  5. Patches/updates → fixes known weaknesses → prevents exploits

  6. Separate Dev/Test/Production → prevents test code/real data affecting live system

SAST = checks code without running it
DAST = tests running app
CI = frequently merge tested code
Backdoor = hidden way around security

CASE STUDY:

Vulnerability → Control → Law/principle → FIRST action

🟧 LESSON 6 — THREAT MODELLING

Threat modelling = identify weaknesses BEFORE attackers do.

3 PRINCIPLES ⭐

  1. Define security requirements

  2. Identify + mitigate threats

  3. Confirm threats are mitigated

ASK:

What could go wrong? → Who? → How bad? → How fix?

UPDATE THREAT MODEL IF:

  • New feature

  • Security incident

  • Organisation/infrastructure changes

PEOPLE:

Developers + managers + testers + support → different people see different risks.

SCENARIO:

Threat → vulnerability → impact → mitigation

KEY:

Old threat model + new changes = OUTDATED