%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E67E22', 'fontSize': '13px'}}}%%
graph TB
START[Mirai Malware] --> SCAN[Step 1: Random IP Scanning<br/>Port 23 Telnet<br/>Port 2323 Alternative Telnet]
SCAN --> CRED[Step 2: Brute Force<br/>62 Default Credentials<br/>admin/admin, root/root, etc.]
CRED --> ACCESS{Login<br/>Successful?}
ACCESS -->|No| SCAN
ACCESS -->|Yes| INFECT[Step 3: Device Compromise<br/>Download Malware<br/>Run in Memory]
INFECT --> HIDE[Step 4: Persistence<br/>Delete After Loading<br/>No Disk Traces]
HIDE --> CC[Step 5: C&C Registration<br/>Connect to Command Server<br/>Await Instructions]
CC --> SPREAD[Step 6: Propagation<br/>Infected Device Scans<br/>for More Victims]
CC --> DDOS[Step 7: Attack Launch<br/>GRE/UDP/TCP SYN Flood<br/>HTTP Flood]
SPREAD --> BOTNET[Growing Botnet<br/>300,000+ Devices]
DDOS --> BOTNET
BOTNET --> TARGET[Target Websites<br/>Twitter, Netflix, Reddit<br/>via Dyn DNS]
style START fill:#e74c3c,stroke:#c0392b,color:#fff,stroke-width:3px
style SCAN fill:#E67E22,stroke:#2C3E50,color:#fff
style CRED fill:#E67E22,stroke:#2C3E50,color:#fff
style ACCESS fill:#16A085,stroke:#2C3E50,color:#fff
style INFECT fill:#e74c3c,stroke:#c0392b,color:#fff
style HIDE fill:#e74c3c,stroke:#c0392b,color:#fff
style CC fill:#2C3E50,stroke:#16A085,color:#fff
style SPREAD fill:#E67E22,stroke:#2C3E50,color:#fff
style DDOS fill:#e74c3c,stroke:#c0392b,color:#fff
style BOTNET fill:#e74c3c,stroke:#c0392b,color:#fff,stroke-width:3px
style TARGET fill:#c0392b,stroke:#e74c3c,color:#fff,stroke-width:3px
1363 Security-by-Design Principles
1363.1 Learning Objectives
By the end of this chapter, you should be able to:
- Apply security-by-design principles to IoT development
- Recognize and avoid common security misconceptions
- Understand minimum viable security for IoT products
- Analyze security failures in real-world case studies
- Implement security best practices from project inception
1363.2 Real-World Case Studies: Detailed Analysis
The following case studies provide in-depth analysis of actual IoT security incidents and successful implementations, with timelines, technical details, and actionable lessons.
1363.3 Case Study 1: Mirai Botnet Attack (2016) - What Went Wrong
1363.3.1 Background and Timeline
The Mirai botnet represents one of the most significant IoT security failures, demonstrating how poor security practices can create devastating consequences at internet scale.
Timeline of Events:
August 2016: Initial Mirai malware development begins - 16-year-old Paras Jha creates prototype botnet for Minecraft server attacks - Discovers vast numbers of IoT devices with default credentials - Malware designed to spread autonomously through internet scanning
September 20, 2016: Major attack on security blogger Brian Krebs - 620 Gbps DDoS attack, largest recorded at the time - Akamai forced to drop Krebs as customer due to attack volume - Attack demonstrated Mirai’s capability
September 30, 2016: Mirai source code released publicly - Posted to Hackforums under “Anna-senpai” pseudonym - Enabled anyone to launch Mirai variants - Triggered exponential growth in botnets
October 21, 2016: Dyn DNS attack - Multiple waves of attacks starting 7:00 AM ET - 100,000+ compromised IoT devices participating - 1.2 Tbps peak traffic (unprecedented scale) - Major websites affected: Twitter, Netflix, Reddit, GitHub, PayPal, Airbnb - East Coast USA primarily affected, 3 waves over 12 hours - Estimated $110 million in damages
December 2016-January 2017: Arrests and aftermath - FBI identifies and arrests Paras Jha and accomplices - Convictions lead to plea deals and community service (surprisingly lenient)
1363.3.2 Attack Vector Analysis
1363.3.3 Technical Details: How Mirai Worked
1. Scanning and Discovery:
# Pseudo-code of Mirai scanning logic
while(true) {
random_ip = generate_random_ip()
if (can_connect(random_ip, port=23)) { # Telnet
try_default_credentials(random_ip)
}
if (can_connect(random_ip, port=2323)) { # Alternative Telnet
try_default_credentials(random_ip)
}
}2. Default Credentials Used: Mirai contained hardcoded list of 62 default username/password combinations:
root/root
admin/admin
root/pass
admin/password
root/12345
admin/1234
user/user
# ... 55 more variations3. Compromised Device Types: | Device Category | Examples | Estimated Infections | |—————–|———-|———————| | IP Cameras | DVR, NVR, CCTV systems | 120,000+ | | Home Routers | Various ISP-provided routers | 80,000+ | | DVR/NVR | Dahua, Hikvision (vulnerabilities) | 65,000+ | | Network Devices | Switches, modems, access points | 35,000+ | | Total | Diverse IoT ecosystem | 300,000+ peak |
4. Attack Methods Employed: - GRE IP Flood: Generic Routing Encapsulation packets overwhelming routers - GRE Ethernet Flood: Layer 2 GRE flooding - UDP Flood: Volumetric attack saturating bandwidth - TCP SYN Flood: Exhaust connection tables - HTTP Flood: Application-layer attacks overwhelming web servers
1363.3.4 Root Causes and Vulnerabilities
1363.4 Critical Security Failures
1. Default Credentials (OWASP IoT Top 10: I1) - Manufacturers shipped devices with admin/admin, root/root - No forced password change on first setup - Same credentials across thousands or millions of units - Lesson: Unique per-device credentials or forced password change are essential
2. Unnecessary Services Exposed (I2) - Telnet enabled by default on WAN interface - No need for remote Telnet access in consumer devices - Should use SSH if remote access required, or disable entirely - Lesson: Disable unnecessary services; follow least-privilege principle
3. No Security Updates (I4) - Devices had no automatic update mechanism - Many devices never received firmware updates - Users unaware of security risks - Lesson: Build automated, signed update mechanisms from day one
4. Inadequate Access Controls (I3) - No rate limiting on login attempts - No account lockout after failed logins - No geographic restrictions on administrative access - Lesson: Implement brute-force protection and access controls
5. Lack of Monitoring (I8) - Devices provided no visibility into compromise - No alerting when device behavior changed - No centralized device management - Lesson: Include logging, alerting, and remote management capabilities
1363.4.1 Results and Impact
Quantified Damage:
Financial Impact: - Direct Damages: $110 million estimated (business losses during outages) - Dyn Revenue Loss: $300K+ in lost customers - Remediation Costs: Millions spent by ISPs, manufacturers - Legal Costs: Settlements and lawsuits from affected businesses
Infrastructure Impact: - 1.2 Tbps peak attack traffic – largest recorded DDoS at the time - 100,000+ devices attacking simultaneously - 3 attack waves over 12 hours - Millions of users unable to access major internet services
Long-Term Consequences: - California SB-327 (2018): First state law banning default passwords - UK PSTI Bill (2022): Comprehensive IoT security regulation - EU Cyber Resilience Act: Mandatory security requirements for connected devices - Industry Wake-Up: Major manufacturers finally prioritized IoT security
1363.4.2 Lessons Learned and Remediation
1363.5 Key Takeaways
1. Security Cannot Be an Afterthought - Mirai exploited well-known vulnerabilities that were trivial to fix - Manufacturers prioritized cost and time-to-market over security - Lesson: Security must be designed-in from initial architecture, not bolted on later
2. Default Credentials Are Unacceptable - 62 default password combinations compromised 300,000 devices - California SB-327 now bans default passwords in IoT devices - Implementation: Use per-device unique passwords or force password setup
// Proper implementation
void firstBoot() {
if (!hasCustomPassword()) {
displayMessage("SETUP REQUIRED: Create admin password");
String newPassword = getUserInput();
if (validatePasswordStrength(newPassword)) {
saveEncryptedPassword(newPassword);
} else {
displayMessage("Password too weak. Minimum 12 characters, mixed case, numbers");
ESP.restart(); // Force retry
}
}
}3. Disable Unnecessary Services - Telnet should never be exposed on consumer IoT devices - If remote access is required, use SSH with certificate authentication - Most devices don’t need any remote administrative access
// Secure configuration
void setup() {
disableTelnet(); // Never enable Telnet
disableSSH(); // Disable unless explicitly needed
enableHTTPS(); // Local web interface only via HTTPS
enableFirewall(); // Block all WAN admin access
}4. Implement Brute-Force Protection
// Rate limiting and account lockout
int failedAttempts = 0;
unsigned long lockoutUntil = 0;
bool authenticate(String username, String password) {
if (millis() < lockoutUntil) {
return false; // Account locked out
}
if (verifyCredentials(username, password)) {
failedAttempts = 0;
return true;
} else {
failedAttempts++;
if (failedAttempts >= 3) {
lockoutUntil = millis() + 300000; // 5 minute lockout
sendAlert("Multiple failed login attempts");
}
return false;
}
}5. Automated Security Updates Are Essential - Mirai variants continued to emerge after initial outbreak - Manual updates are ineffective for millions of deployed devices - Implementation: Signed automatic updates with rollback capability
6. Network Segmentation for IoT Devices - IoT devices should be on separate VLAN from trusted networks - Limit or block IoT device internet access unless required - Use firewall rules to restrict IoT device communication
7. Manufacturer Responsibility - Device makers must prioritize long-term security support - Publish security vulnerability disclosure policies - Provide security updates for device lifetime (or at least 5 years) - Include “security by design” in product development lifecycle
1363.5.1 Regulatory Response
California SB-327 (Effective January 2020):
Requires manufacturers of connected devices to equip them with "reasonable
security features" including:
1. Unique preprogrammed password for each device, OR
2. Force user to generate new password on first useUK Product Security and Telecommunications Infrastructure (PSTI) Bill: - Bans default passwords - Requires vulnerability disclosure program - Mandates minimum security update periods - Penalties up to £10M or 4% of global turnover
1363.5.2 References
- FBI Criminal Complaint: United States v. Paras Jha, Josiah White, Dalton Norman (2017)
- Cloudflare: “Inside the Infamous Mirai IoT Botnet” technical analysis (2017)
- Akamai Security Intelligence: “Mirai Botnet Attack Reports” (2016-2017)
- California Legislative Information: SB-327 Internet of Things Security Law
- OWASP: IoT Top 10 2018 - Updated based on Mirai lessons
1363.6 Case Study 2: Successful IoT Security Implementation - Smart Grid Deployment
1363.6.1 Background and Challenge
A major European utility company (10 million customers) embarked on a smart meter rollout replacing 8.5 million traditional meters with smart meters over 4 years. Learning from previous IoT security failures (including Mirai), the company designed security into the system from inception, treating it as a critical infrastructure project requiring military-grade security.
Project Scope: - 8.5 million smart meters across residential and commercial customers - 850 data concentrator gateways (fog nodes) aggregating neighborhood data - Bidirectional communication: Utility to meter (commands, firmware) and meter to utility (consumption data) - 15-year operational lifespan: Devices must remain secure for 15+ years - Regulatory requirements: GDPR compliance, energy regulations, critical infrastructure protection
Security Requirements: - Prevent unauthorized access to meter data (privacy violation) - Prevent tampering with consumption readings (fraud) - Prevent remote disconnection attacks (safety and availability) - Ensure firmware update authenticity (integrity) - Detect and respond to cyber attacks in real-time - Comply with GDPR, NIS Directive, and national regulations
1363.6.2 Solution Architecture
The utility implemented a defense-in-depth architecture with security at every layer, including hardware security modules, end-to-end encryption, and continuous monitoring.
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E67E22', 'fontSize': '12px'}}}%%
graph TB
subgraph BACKEND["Backend Systems Security"]
SIEM[SIEM<br/>Real-time Monitoring<br/>Splunk]
HSM[HSM<br/>Key Management<br/>Thales]
PKI[PKI<br/>Certificate Authority<br/>X.509]
DB[(Encrypted Database<br/>AES-256 at Rest)]
end
subgraph GATEWAY["Data Concentrator Gateways 850 units"]
GW[Gateway<br/>Hardened Linux]
FW[Firewall + IDS/IPS]
CACHE[Firmware Cache<br/>Local Storage]
end
subgraph METERS["Smart Meters 8.5M units"]
M1[Smart Meter<br/>ARM TrustZone]
SEC[Secure Enclave<br/>Private Key Storage]
BOOT[Secure Boot<br/>Signed Firmware]
end
BACKEND -->|TLS 1.3<br/>Mutual Auth| GATEWAY
GATEWAY -->|IEEE 802.15.4g<br/>AES-128 Mesh| METERS
M1 --- SEC
M1 --- BOOT
PKI -.Issues Certificates.-> M1
PKI -.Issues Certificates.-> GW
SIEM -.Monitors.-> METERS
SIEM -.Monitors.-> GATEWAY
HSM -.Manages Keys.-> PKI
HSM -.Encryption Keys.-> DB
style BACKEND fill:#2C3E50,stroke:#16A085,color:#fff
style GATEWAY fill:#16A085,stroke:#2C3E50,color:#fff
style METERS fill:#E67E22,stroke:#2C3E50,color:#fff
style SIEM fill:#27ae60,stroke:#16A085,color:#fff
style HSM fill:#27ae60,stroke:#16A085,color:#fff
style PKI fill:#27ae60,stroke:#16A085,color:#fff
1363.6.3 Technologies Used
| Component | Technology | Security Function |
|---|---|---|
| Smart Meter Security | ARM TrustZone + Secure Enclave | Hardware-isolated secure execution environment |
| Device Certificates | X.509 certificates (unique per device) | Device authentication, mutual TLS |
| Encryption | AES-256 (data at rest), TLS 1.3 (in transit) | Confidentiality of consumption data |
| Secure Boot | UEFI Secure Boot + signed firmware | Prevent unauthorized firmware execution |
| Key Management | Thales HSM (Hardware Security Module) | Cryptographic key storage and operations |
| PKI | Internal Certificate Authority | Issue, manage, revoke device certificates |
| Mesh Networking | IEEE 802.15.4g (RF mesh) + AES-128 | Low-power encrypted communication |
| Gateway Security | Firewall, IDS/IPS, hardened Linux | Protect concentrator gateways |
| SIEM | Splunk Enterprise Security | Real-time threat detection and response |
| Anomaly Detection | Machine Learning (TensorFlow) | Detect unusual meter behavior |
| OTA Updates | Signed firmware + delta updates | Secure, bandwidth-efficient updates |
1363.6.4 Implementation Details
1. Hardware Security Module (HSM) in Every Meter: - Secure enclave stores private key (never exposed to main CPU) - Cryptographic operations performed in secure element - Tamper detection triggers key erasure - Cost: +$3 per meter (total $25.5M investment)
2. Unique Device Certificates:
Certificate Chain:
Root CA (offline, air-gapped)
└── Intermediate CA (online, HSM-protected)
└── Device Certificate (unique per meter)
- Serial Number: Meter ID
- Public Key: Unique ECC-256 key pair
- Validity: 15 years
- Extensions: Key Usage, Extended Key Usage3. Mutual TLS Authentication: - Meter authenticates gateway (prevents rogue gateways) - Gateway authenticates meter (prevents rogue meters) - Both parties verify certificate chain to trusted root CA
4. Defense-in-Depth Encryption:
Layer 1: RF Mesh (802.15.4g) - AES-128 link encryption
Layer 2: Application Layer - TLS 1.3 end-to-end encryption
Layer 3: Data at Rest - AES-256 encrypted storage in backend5. Secure Firmware Update Process:
1. Firmware Build:
- Build firmware binary
- Sign with private key (offline signing server)
- Encrypt with firmware encryption key
2. Distribution:
- Upload to update server
- Distribute to gateways (TLS-protected)
- Gateways cache locally
3. Meter Update:
- Gateway pushes update to meters (encrypted channel)
- Meter verifies signature (using public key in secure boot)
- If valid, decrypt and install
- If invalid, reject and log security event
4. Verification:
- Meter reports installed firmware version
- Backend verifies successful update
- Automatic rollback if meter becomes unreachable6. Anomaly Detection and Intrusion Detection:
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E67E22', 'fontSize': '12px'}}}%%
flowchart TD
DATA[Smart Meter Data Stream<br/>Consumption, Timing, Comms] --> EXTRACT[Feature Extraction<br/>• Power consumption patterns<br/>• Communication frequency<br/>• Firmware version<br/>• Certificate status]
EXTRACT --> BASELINE[Compare to Baseline Profile<br/>Historical behavior for this meter]
BASELINE --> ML[ML Anomaly Detection<br/>Isolation Forest Algorithm]
ML --> SCORE{Anomaly<br/>Score}
SCORE -->|Normal| LOG[Log Normal Event<br/>Continue Monitoring]
SCORE -->|Anomalous| CLASSIFY[Classify Anomaly Type]
CLASSIFY --> TYPE1[Unusual Consumption<br/>Possible tampering]
CLASSIFY --> TYPE2[Abnormal Comm Frequency<br/>Possible C&C]
CLASSIFY --> TYPE3[Unexpected Firmware Version<br/>Possible compromise]
CLASSIFY --> TYPE4[Certificate Validation Fail<br/>Possible MITM]
TYPE1 --> ALERT[Generate SIEM Alert<br/>• Meter ID<br/>• Anomaly Type<br/>• Severity<br/>• Timestamp]
TYPE2 --> ALERT
TYPE3 --> ALERT
TYPE4 --> ALERT
ALERT --> RESPONSE[Security Response<br/>Investigate & Mitigate]
style DATA fill:#2C3E50,stroke:#16A085,color:#fff
style EXTRACT fill:#16A085,stroke:#2C3E50,color:#fff
style BASELINE fill:#16A085,stroke:#2C3E50,color:#fff
style ML fill:#E67E22,stroke:#2C3E50,color:#fff
style SCORE fill:#E67E22,stroke:#2C3E50,color:#fff
style LOG fill:#7F8C8D,stroke:#2C3E50,color:#fff
style CLASSIFY fill:#E67E22,stroke:#2C3E50,color:#fff
style TYPE1 fill:#c0392b,stroke:#e74c3c,color:#fff
style TYPE2 fill:#c0392b,stroke:#e74c3c,color:#fff
style TYPE3 fill:#c0392b,stroke:#e74c3c,color:#fff
style TYPE4 fill:#c0392b,stroke:#e74c3c,color:#fff
style ALERT fill:#e74c3c,stroke:#c0392b,color:#fff
style RESPONSE fill:#2C3E50,stroke:#16A085,color:#fff
Anomaly Types Detected: - Unusual consumption patterns: Possible tampering or fraud - Abnormal communication frequency: Possible command & control (C&C) activity - Unexpected firmware version: Possible device compromise - Certificate validation failures: Possible man-in-the-middle attack
1363.6.5 Results and Impact
Quantified Security Outcomes:
Zero Major Breaches in 6 Years: - 0 successful cyber attacks resulting in data breach or service disruption - 0 unauthorized access to customer consumption data - 0 fraudulent meter tampering via remote attacks - 99.997% availability (only 15 minutes downtime per year, mostly planned maintenance)
Threat Detection and Response: - 12,400 security events detected over 6 years - 238 actual threats identified and mitigated (vs. false positives) - 145 malware attempts blocked at gateway level - 58 brute-force attacks stopped (certificate-based auth prevented) - 35 DDoS attempts absorbed (rate limiting + redundancy) - Average detection time: 4.2 minutes - Average response time: 18 minutes
Privacy and Compliance: - 100% GDPR compliance throughout deployment - Zero customer data breaches or privacy violations - 15-minute data granularity vs. historical monthly billing - Customer data anonymization for analytics (k-anonymity k=1000) - Right to erasure: Automated data deletion within 24 hours of request
Operational Benefits: - $420M savings over 6 years from reduced meter reading costs - 87% reduction in estimated billing (more accurate consumption data) - 42% faster outage detection and response - Theft detection: 15,000 cases of energy theft identified ($23M recovered)
Cost Analysis: - Total security investment: $180 million over 6 years - HSM in meters: $25.5M - PKI infrastructure: $12M - SIEM and monitoring: $18M per year = $108M - Security operations center: $6M per year = $36M - Breach cost avoidance: Estimated $500M+ (based on comparable incidents) - Net ROI: 178% (avoided costs + operational benefits)
1363.6.6 Lessons Learned
1363.7 Key Takeaways
See security principles in action with the detailed case studies and practice labs below.
1363.8 What’s Next
See security principles in action:
- Case Studies - Deep dives into Mirai and successful implementations
- Practice Labs - Apply design principles in hands-on exercises
- Foundations - Review CIA triad basics if needed
Recommended next: Security Case Studies →