Threat modeling is the process of identifying and mitigating potential threats and risks to your system in order to reduce its vulnerability to compromise and attack. A good threat model considers each threat during the design phase of a system to ensure that appropriate countermeasures are built in.
Threats and risks to embedded systems might include system takeover by remote control or rendering a system inoperable by extracting critical data. A design that takes these risks into account reduces the attack surface and limits the damage an attack can inflict.
Denial-of-service (DoS) can intentionally render a service or device unavailable. For example, a smurf attack is a type of distributed DOS attack where an attacker sends a network a series of broadcast Internet Control Message Protocol (ICMP) packets with a spoofed (disguised) return address. Many nodes on the network receive the broadcast ICMP request and respond to the spoofed return address, which is the target of the DOS attack.
This attack amplifies a single request from the attacker via the nodes on the network and results in a massive flood of responses from many systems. Your system could be participating in the attack on someone else's system even though you are not intentionally attacking it. The system being spoofed is left vulnerable to denial of service, depending on the number of responses that it receives.
To mitigate against this specific vulnerability, use the sysctl utility to disable a response to broadcast pings from your system. For example:
# sysctl -w net.inet.icmp.bmcastecho=0
Although it may not slow down or thwart the attacker, it does stop the amplification of attacker's broadcast requests from your node and opt you out of participating in the attack.
Mitigating the risks associated with embedded systems connecting to other systems should include at least the following countermeasures:
The following table lists some of the known classes of embedded systems vulnerabilities and an examples of each one:
Class | Example |
---|---|
Removable media | Exploited firmware update paths |
Intermodule communication intercepts | Insufficient authorization |
Man-in-the-middle attacks | Buffer overflows and unsafe use of functions like strcpy() |
Third-party applications and malware | Improper application sandboxing and OS-level privileges |
Compromised back-end | More traditional attack |