Theory
Who else is listening to the tank?
SmartHostel put the water tank, the gate and the corridor cameras on the internet. Convenient: the warden checks them from home.
But "on the internet" cuts both ways. The same connectivity that lets the warden in could let a stranger in: watch the cameras, read when rooms are empty from the motion logs, or fling the gate open.
IoT's greatest strength: openness: is also its gravest weakness. Securing it is not a feature to bolt on; it is a concern spanning every layer, and this lesson is why.
Theory
Why IoT is uniquely exposed
IoT's attack surface is larger than ordinary computing for concrete reasons:
- sheer numbers: billions of devices, each a possible door
- constrained hardware: tiny sensors lack the power and memory for heavy encryption
- rare updates: firmware ships once and is seldom patched, so old holes stay open
- default/weak passwords: shipped credentials nobody changes
- physical accessibility: a gate sensor sits outdoors, touchable
- internet exposure: the connectivity the IoT-vs-M2M lesson prized is exactly what invites remote attack
At a glance
The security yardstick: CIA triad (plus 2)
| Goal | Question it answers | SmartHostel stake |
|---|---|---|
| Confidentiality | Can only the authorised see the data? | Camera feeds and occupancy logs stay private |
| Integrity | Is the data unaltered, untampered? | A forged 'tank full' reading cannot hide a real shortage |
| Availability | Does the system stay up when attacked? | The gate control survives a denial-of-service flood |
| Authentication | Is this device/user who it claims? | A fake sensor cannot impersonate room 214's |
| Authorization | Is this action permitted for them? | Only the warden's login may open the gate |
Theory
Threats, and the defences that answer them
Common threats: eavesdropping/sniffing (reading unencrypted traffic), man-in-the-middle (intercepting between 2 parties), DoS/DDoS (flooding a device or service until it collapses), spoofing (faking identity), physical tampering, firmware attacks.
A real, widely-documented case: the Mirai botnet enslaved thousands of IoT cameras and routers that still used default passwords, then used them to launch massive DDoS attacks.
Defences: strong unique credentials, encryption (data in transit AND at rest), regular firmware updates, device authentication, network segmentation (isolating IoT devices), and secure boot.
Quiz
What made the Mirai botnet able to enslave so many IoT devices?
- The devices used military-grade encryption that attackers cracked
- The devices shipped with default/weak passwords that owners never changed
- The devices had no internet connection at all
- The attackers had physical access to every device
Show the answer
The devices shipped with default/weak passwords that owners never changed
Mirai's power came from the most boring vulnerability imaginable: unchanged factory-default credentials, tried automatically across thousands of internet-exposed cameras and routers. It is the canonical lesson that IoT's weakest link is often basic hygiene, not exotic cryptography: which is why changing default passwords tops every defence list. Option A inverts reality (strong crypto is the DEFENCE, not the hole). Option C describes devices that could not be remotely attacked at all. Option D confuses one physical threat with the remote, at-scale attack Mirai actually was.
Think first
What does a leaked tank sensor actually reveal?
The tank level sensor seems harmless: it is just water. Yet a security review flags it. Think about what patterns in innocent data can betray, then tap.
Show the answer
Water usage is an occupancy signal. A tank that barely drains all week whispers the hostel is empty (holidays): a burglar's dream. Sudden 3 am usage patterns reveal routines. Combined with the motion logs, an outsider reconstructs when which wing is vacant. This is the quiet lesson of IoT security: even innocuous data leaks meaningful inferences, so confidentiality applies to boring sensors too, and the exam-worthy point is that IoT threats are as much about inference from aggregated data as about dramatic break-ins. Secure the mundane.
Watch out
IoT-security answer slips
Security as one layer's job: it is CROSS-CUTTING: the security functional block spans device, network, processing and application: say so.
Encryption in transit only: data at REST (stored) needs protection too; attackers target databases, not just wires.
Naming fake CVEs or exploits: cite only well-documented general cases like Mirai; never invent specific vulnerabilities, product flaws or attack details: the honest, exam-safe move.
Theory
Openness has a price and a payoff
This lesson is the shadow of the IoT-vs-M2M comparison: the internet connectivity that made IoT powerful is precisely what made it vulnerable. Good IoT engineering holds both truths at once: connect for the payoff, secure for the price. Unit 2 closes next with the other side of that coin: the ENABLING technologies (wireless sensor networks, big-data analytics, embedded systems) that give IoT its powers: the capabilities worth defending.
Summary
Key takeaways
- IoT is uniquely exposed: many devices, weak hardware, rare updates, default passwords, physical access, internet exposure.
- CIA triad: Confidentiality (encryption), Integrity (no tampering), Availability (survive DoS); plus Authentication and Authorization.
- Threats: eavesdropping, man-in-the-middle, DoS/DDoS, spoofing, tampering, firmware attacks.
- Mirai enslaved IoT devices via unchanged default passwords: basic hygiene is the weakest link.
- Defences: unique credentials, encryption in transit AND at rest, firmware updates, authentication, network segmentation, secure boot.
- Security is cross-cutting across all layers, and even innocuous data leaks inferences.
- Memory hook: the door that lets the warden in can let a stranger in.