Unit Scenarios
Scenario 4A: Designing Secure Connected Farm Equipment
The Situation
As a security engineer at an agricultural machinery manufacturer, the task is researching vulnerabilities in internet-connected farm equipment (tractors with GPS, automated irrigation, robotic milking machines, all remotely controllable and needing periodic updates) and recommending fixes.
The Vulnerabilities
Weak or default authentication: a lot of IoT farm devices ship with default logins that never get changed, letting attackers scan the internet, credential-stuff their way in, and remotely control machinery. Likelihood is high given how common this is in IoT generally, and impact is severe, covering safety risks from remotely controlled heavy machinery, financial damage well over $100,000 per incident, and operational disruption during critical farming seasons. The Mirai botnet (2016) showed how this plays out at scale: it took over hundreds of thousands of IoT devices just by trying factory default logins.
Unencrypted communications: control signals and data sent without encryption let an attacker intercept traffic, capture and replay control commands, or eavesdrop on farm operations. Likelihood is medium since it needs proximity or network access, but impact is high, since competitors could steal operational data or maliciously control equipment, and GPS data alone could reveal crop locations and yields.
Lack of software updates: embedded systems often run for 10 to 20 years with no updates at all, leaving known vulnerabilities permanently unpatched. Likelihood is medium (equipment needs to be internet-accessible), but impact is high, potentially leading to full equipment compromise, long-term persistent access, and malware spreading across the whole farm network.
Insecure GPS systems: GPS spoofing can feed autonomous tractors false location data, sending them into obstacles, ditches, or off the property entirely, and breaking precision agriculture operations. Likelihood is low since it requires specialized equipment and physical proximity, but impact is severe, with potential equipment damage in the tens to hundreds of thousands, injury risk if an operator's present, and crop damage from bad navigation.
Physical access to devices: equipment sitting in remote fields often has minimal physical security, letting someone plug into a diagnostic port, install malware via USB, or modify firmware directly. Likelihood is low since it requires physical presence that would look suspicious out in a field, but impact is moderate, limited to a single piece of equipment but still enabling persistence and sabotage.
Network segmentation failures: farm equipment sitting on the same network as business systems means a compromised, less-secured piece of machinery can become a pivot point into financial data, customer info, or even let ransomware spread from equipment into the office. Likelihood is medium since this is a fairly common network design flaw, and impact is high given how it can compromise the whole business through an IoT weak point.
The Fixes
Strong authentication: force a password change on first startup, require unique passwords with no factory defaults, enforce at least 12 characters with complexity, add certificate-based authentication for remote access, require two-factor for critical operations, provide a physical key switch for local control that can't be remotely overridden, and force a password change whenever there's any sign a password was compromised (instead of on a fixed schedule, which just leads to predictable patterns).
Encrypted communications: use TLS 1.3 for all control traffic, require a VPN for remote access, use certificate pinning to prevent man-in-the-middle attacks, and harden GPS with receivers that cross-check signals from more than one satellite system (like GPS and Galileo), plus anomaly detection that flags physically impossible GPS movement.
Secure updates: check for updates daily automatically, digitally sign every update so authenticity can be verified, support rollback if an update fails, and deliver updates over cellular to sidestep any farm network vulnerabilities. Critical security patches should auto-install within about 7 days, while feature updates wait for farmer approval.
Network segmentation: put farm equipment on its own VLAN, fully isolated from the business network by a firewall, put a dedicated management network with MFA for admin access, and explicitly deny equipment-to-business traffic while allowing only authenticated management traffic to reach equipment.
Physical security: use tamper-evident seals on diagnostic ports, locking covers over USB ports, geofencing that alerts if equipment leaves the farm boundary, and motion sensors that flag movement when equipment shouldn't be in use. A daily cellular check-in means if a tractor goes 24 hours without reporting in, the farmer gets an alert to investigate, which might reveal something like a tampered diagnostic port seal.
Intrusion detection: establish a baseline of normal operations (typical routes, schedules, commands) and alert on anomalies like equipment running at odd hours, commands coming from unauthorized IPs, GPS routes outside the farm boundary, or rapid unexplained configuration changes, halting operations and requiring manual verification when something looks off.
Secure development practices: build security requirements in from the design phase, run code security audits before release, get third-party penetration testing done, maintain a vulnerability disclosure program for responsible reporting, verify all supply chain components, avoid hardcoded secrets in firmware, and use secure boot to verify firmware integrity on startup, preventing malware from persisting there.
The Numbers
All seven mitigations together run roughly $575 per device, against a typical tractor price of $150,000, which is under half a percent of the equipment's value. Compare that to the cost of a single compromise: equipment damage in the tens to hundreds of thousands, crop losses over $100,000 from missed planting or harvest windows, potential liability exceeding $1,000,000 if anyone's injured, and real reputational damage on top of all that. A $575 investment preventing potential losses well over $1,000,000 is about as clear an ROI case as it gets.
Bottom Line
Connected farm equipment carries real cybersecurity risk across weak authentication, unencrypted comms, missing updates, GPS spoofing, physical access, and network segmentation gaps, and exploitation could mean equipment damage, crop losses, injuries, and serious operational disruption. The recommended seven-layer approach costs a tiny fraction of the equipment's value and should be rolled out with authentication, encryption, and updates prioritized for the next product release, intrusion detection and physical security following within about six months, and secure development practices becoming an ongoing discipline. Beyond just closing security gaps, a genuinely security-first design could become a real competitive differentiator as farmers grow more aware of these risks.
Scenario 4B: Configuring Authentication Settings
The Task
As a junior sysadmin at an engineering firm, the job is configuring a new drop-in desktop for remote workers in line with company security policy.
Password Policy
Set a minimum of 14 characters with full complexity required (uppercase, lowercase, digits, symbols), remember the last 10 passwords to block reuse, require at least 1 day between password changes, and skip a maximum age requirement entirely, following current NIST guidance against forced periodic expiration. In Windows, this all gets set through Local Security Policy under Account Policies, Password Policy.
Account Lockout Policy
Lock the account after 5 failed attempts, lock for 30 minutes, and reset the failure counter after 30 minutes too. Five attempts gives room for the occasional typo while still blocking brute force, and a 30-minute lockout meaningfully slows an attacker down without being excessively punishing for legitimate users.
Additional Security Settings
Deny network and local logon access for the Guest account, disable displaying the last logged-in username at the login screen, disable the built-in Administrator account in favor of named admin accounts, disable Guest entirely, rename the admin account to something less obvious as an extra layer of obscurity, display a login warning banner stating that all activity is monitored and logged, and disable the option to shut down the system without logging in first.
Local User Account
Create a standard "DropInUser" account for remote workers with a strong initial password that must be changed at first login, ensure it's not set to never expire, and make sure it's a member of the standard Users group rather than Administrators.
Audit Policy
Enable auditing for account logon events, account management, general logon events, policy changes, privilege use failures, and system events, covering both success and failure where relevant, and forward security logs to a SIEM if one's available so this drop-in machine's events get monitored centrally alongside everything else.
Verification
Testing should confirm a weak password like "test123" gets rejected while something like "Aces!Hack@2024Secure" gets accepted, and that trying to reuse a recently-used password gets blocked by the history policy. It should also confirm that 5 consecutive wrong passwords actually triggers a lockout, that the lockout clears automatically after 30 minutes, and that the lockout event shows up correctly in the Security event log. Finally, logging in as the standard DropInUser account should confirm that installing software, modifying system settings, and accessing other users' files are all denied, while access to their own files and approved apps works fine.
Documentation
The final writeup should record the exact password policy, lockout settings, account setup (DropInUser standard, renamed and disabled default admin, Guest disabled), audit logging status, and confirmation of compliance with the company's security policy, along with next steps like securely delivering credentials to the remote worker, logging the machine in the asset inventory, and scheduling a quarterly review of the settings.
Scenario 4C: Analyzing Log Files for Indicators of Compromise
The Situation
As a forensic analyst at a manufacturing company that recently had its business network breached (contained, with the manufacturing network apparently untouched so far), ongoing suspicious activity raises concern that attackers might be trying to pivot into the manufacturing network. The task is digging through authentication and activity logs for signs of compromise.
What the Logs Revealed
Password spraying: over a span of about 60 seconds in the middle of the night, 52 different manufacturing accounts all got tried with the same password ("Winter2024!") from a single external IP, and one account, Maintenance1, actually succeeded. This is a textbook password spraying attack, and it compromised the Maintenance1 account.
Lateral movement: immediately after that compromise, the Maintenance1 account logged into a PLC controller, accessed a network diagram and a file full of PLC credentials, launched a network scan across the whole manufacturing subnet, and attempted (unsuccessfully) to RDP and SSH into other manufacturing systems, all completely unlike this account's normal 9-to-5 maintenance-task behavior. This is clearly an active adversary using stolen credentials to explore and expand their foothold.
Unusual file access: a business network account with no legitimate reason to touch manufacturing data accessed over 1,200 files in the manufacturing PLC configuration folder over about four hours, including things like assembly line configs, robot arm control settings, emergency shutdown procedures, network topology diagrams, and a large backup of PLC programs, all with no corresponding work ticket. This pattern, a huge volume of access with no legitimate justification, is a strong sign of a compromised account being used to harvest high-value data for exfiltration.
Suspicious process execution: on the SCADA server, a PowerShell process launched with an obfuscated, base64-encoded command, spawned from an unusual parent process, downloaded and ran a script from an unfamiliar external IP over an encrypted connection lasting nearly an hour, transferred 15 MB outbound, and created a new scheduled task set to run an unfamiliar executable every 30 minutes. This combination, obfuscation, an odd parent process, unexplained outbound traffic, and a persistence mechanism, points clearly to malware execution with persistence already established.
Online password attack and privilege escalation: from an already-compromised internal workstation, over 200 different passwords got tried against a single high-value admin account before one finally succeeded, granting the attacker administrative control over critical manufacturing systems. A single account getting hundreds of wrong passwords is the classic sign of an online password attack, and the fact that it ever succeeded means that admin account had no working lockout policy.
Putting the Timeline Together
Initial access came through password spraying that compromised the Maintenance1 account, immediately followed by reconnaissance and lateral movement attempts. A day later, a business account pivoted into manufacturing to exfiltrate configuration data. The next day, malware got deployed on the SCADA server with persistence established. And a couple days after that, the attacker escalated to full admin access from an already-compromised workstation. Altogether, the compromised systems include the Maintenance1 workstation, a PLC controller, the SCADA server, the manufacturing file server, and an admin workstation, and the likely objective was gaining a foothold, mapping the network, stealing control system data, establishing lasting persistence, escalating privileges, and positioning for potential operational disruption or sabotage.
What to Do About It
Immediately: disable all three compromised accounts, force a password reset across the entire manufacturing network, terminate all active sessions, isolate the SCADA server, remove the malicious scheduled task and its executable, scan everything for further indicators, block the malicious IPs at the firewall, and preserve evidence through memory dumps and log archives for the incident report.
Within the first week: run a full forensic analysis of the SCADA malware, figure out exactly what data was stolen, identify any additional compromised systems, and map out the complete attack path. Put a real firewall between business and manufacturing networks allowing only specific necessary traffic, require MFA for any cross-network access, enforce 14+ character passwords, roll out a password manager, enable MFA across manufacturing accounts, and clean up unnecessary admin privileges.
Over the following months: deploy EDR across all manufacturing endpoints, implement a SIEM correlating manufacturing logs, add behavioral analytics, and get 24/7 SOC monitoring on critical systems. Add application whitelisting on SCADA and PLC systems, block USB ports on manufacturing workstations, and implement network access control requiring device authentication before connecting. Roll out security training, phishing simulations, and incident response drills for manufacturing staff, and do a full architecture review with regular penetration testing and vendor security assessments for industrial control systems going forward.
Bottom Line
This investigation revealed an active adversary with three compromised accounts, malware running on the SCADA server, and full administrative access to manufacturing systems, all stemming from the original business network breach successfully pivoting over. This is a critical risk situation since the adversary has admin access to production control systems with real potential to disrupt operations, damage equipment, or create safety hazards, and while the incident is contained through the immediate response, it needs to be treated as an ongoing, active situation until the investigation is complete.
Unit 4 Summary
These three scenarios show device security in very different real contexts: securing internet-connected farm machinery against weak authentication, unencrypted comms, and unpatched firmware; correctly configuring password and lockout policies to balance security with usability on a shared workstation; and forensically tracing a multi-stage attack across authentication, file access, and system logs to reconstruct exactly what an adversary did.
The recurring themes: authentication (strong passwords, MFA, lockouts) is one of the most critical controls available, thorough logging is what makes detection and reconstruction possible after the fact, defense in depth avoids any single point of failure, segmentation contains breaches before they spread everywhere, and fast detection and response are what actually limit real-world damage. Good device security ultimately comes down to proactive hardening up front, continuous monitoring throughout, and a quick, well-organized response when something does go wrong.