Systems have three kinds of weakness. Software: a flaw in the app's own code (fix: update and test). User: what people do, like weak or shared passwords or being tricked (fix: training, strong passwords, MFA). Supply chain: something the app relies on, like an add-on or library, goes bad (fix: check and update what you rely on). Perfect code alone doesn't make a system safe.
Three clubs' apps went wrong this year. One had a bug, one had a password on a sticky note, and one trusted a free add-on. Which was the club's fault?
Your mission: other clubs' apps have had incidents. Learn from them, then check the Coding Club's app for the same kinds of weakness before anything goes wrong.
Engage: Commit to a prediction before you test anything. A wrong guess is fine: it shows you what to look for.
Explore: Try it on the board and compare what happens with your prediction.
Explain: Put a name to what you saw, and why it works.
Elaborate: Use the idea in a new situation.
Evaluate: Look back at your first ideas and what changed.
Make your prediction first. Help opens once you've locked it in.
EngageCommit to a prediction before you test anything. A wrong guess is fine: it shows you what to look for.
Engage: whose fault?
ExploreTry it on the board and compare what happens with your prediction.
Explore: three incidents
Was your prediction right?
Try it yourselfYour edits are saved in this browser.
Where was each weakness: in the app's own code, in what a person did, or in something the app relies on?
Use the board. This ticks when you get there.
ExplainPut a name to what you saw, and why it works.
Explain: three kinds
Worked exampleBefore each step, say what you think comes next.
SoftwareA flaw in the app's own code, such as never checking what is typed. Fix: test it and install updates.
UserWhat people do: weak, shared or reused passwords, or being tricked. Fix: training, strong passwords, MFA.
Supply chainSomething the app relies on (an add-on, a library) is out of date, taken over or a lookalike. Fix: check and update what you rely on.
why it mattersEach kind is a different way in, so each needs its own fix.
Find the mistake
Sam's team checks their app. Click the line where it first goes wrong.
ElaborateUse the idea in a new situation.
Elaborate: six incidents
Try it yourselfYour edits are saved in this browser.
Sort all six incidents and choose the fix that would have stopped each one.
Use the board. This ticks when you get there.
ElaborateUse the idea in a new situation.
Elaborate: our own app
Try it yourselfYour edits are saved in this browser.
Need a hint?
Is the problem in the club's own code, in what people do, or in something the app relies on?
Another hint
Each kind has its own fix.
Your review of the club app found three weaknesses. Name each kind and its fix.
Use the board. This ticks when you get there.
EvaluateLook back at your first ideas and what changed.
Evaluate: look back
For teachers
Students sort incidents at fictional club apps into software, user and supply-chain weaknesses with the fix for each, then review the Coding Club's own app (AC9TDI10P13 node 2). Descriptive and defensive throughout. A 5E mission lesson. About 45 minutes.
I can describe software, user and supply-chain weaknesses.
I can match each kind to a fix.
I can spot each kind in a system before it goes wrong.
Before class
Try the board yourself. The clubs and incidents are made up.
The one idea: weaknesses come from the app's own code, from people, and from what the app relies on; each needs its own fix.
This lesson stays descriptive and defensive: what each kind is and how it is fixed. Node 3 (exploring a vulnerability in the student's own software) is left to class, with the teacher, on the students' own projects.
Wider: news reports of real breaches can be sorted into the three kinds. Choose the reports yourself.
Running the lesson
Engage: ask who was at fault in each of the hook's three stories.
Explore: ask which incident was hardest to place, and why.
Explain: model naming the kind and the fix for one incident.
Elaborate: ask why the lookalike library name is supply chain and not user.
Evaluate: discuss what the school should do about the old maps library.
The hard part (on purpose)
Students call every incident software because it happened in an app. Ask: whose action, or whose code, was the weak part?
When students get stuck
A student thinks bug-free code means safe (Sam's mistake). Ask: Could a shared password let someone in, even with perfect code? Fix: Code is one kind of weakness of three.
A student puts the lookalike library under User. Ask: What did the app end up relying on? Fix: Something it relies on went bad: supply chain.
Stretch and support
Stretch: Find a news report of a real breach and sort its causes into the three kinds.
Support: A card with the three kinds, an example and a fix for each.
Where it leads
Next: The Australian Privacy Principles.
What each step is for
Engage: whose fault?: Committing to whether bug-free code is enough tests the new move: weaknesses also come from people and from what an app relies on.
Explore: three incidents: Students sort three incidents by where the weakness was and find the three kinds by contrast.
Explain: three kinds: The teacher models naming the kind and its fix for each incident. Sam trusts bug-free code, the misconception planted after the method.
Elaborate: six incidents: One change: more incidents, and now the fix as well as the kind.
Elaborate: our own app: Applying the kinds to a new system: the club's own app, before anything has gone wrong.
Now you can
Describe software, user and supply-chain weaknesses.