White Paper

WHITE PAPER 7 Tenets of Layered Security in Embedded Design mrcy.com 4 security approaches, as it 's hard to address everything. Constraining software workloads to particular hardware components leads to a cleaner, more straightforward system configuration. If your software stack is allowed unconstrained access to every hardware component on your system, then an attacker can potentially leverage that same access to catastrophic effect. It is like building a boat without bulkheads — a single leak can compromise the whole ship. Containerization of code helps to mitigate attacks by preventing an exploit in one component from affecting another. Many developers fail to imagine how a malicious attacker may intentionally craft malformed inputs that are designed to cause the software to malfunction. Inputs from a variety of external sources such as sensors, radios, networks, etc. should be subject to data input validation before use. Even validation of user input (where user means an actual human user, a peripheral user, or a machine operator) is required. Devices should inspect the conformance of messages to a prescribed data standard. Build options can be set to warn you (or error out) on many types of potential security issues and provide security enhancements. 97% of risk management professionals stated that they believed that unsecured loT devices could be open to a "catastrophic" security breach. Secure and Immutable Configuration The secure configuration of the system needs to apply to all aspects of our system, from the hardware to the applications. We need to ensure the hardware is configured to limit the interfaces / peripherals / memory ranges used by our application, so they aren't even available to an attacker. One area of hardware that is often neglected is various test and debug ports used during manufacturing. Guess what? These interfaces can be used by an attacker with physical access in order to bypass your secure configuration. Configuring the OS in a secure fashion is no small feat, and there are lots of nooks and crannies to investigate. We need to ensure the kernel is configured securely, access to hardware is limited, ensure system services are started in jails where possible and with restricted permissions, and make sure containers in use are configured securely. With the OS configured securely, we need to look at the system's applications. Did we build the applications securely? Do the applications drop unnecessary privileges? A secure configuration requires iteration over multiple components and requires careful identification of the threat model and other tenets. The next step is ensuring that the secure configuration remains immutable on the deployed system. The options for this are really only limited by your imagination, but include: ▪ Using hardware debug / manufacturing interfaces to change the boot image ▪ Replacing the contents of the root filesystem ▪ Modifying kernel command line The potential attacks used to change the secure configuration should be defined by the threat model. Test and debug ports used during manufacturing can be used by an attacker to bypass your secure configuration. Just like one rotten apple can spoil the whole bunch, one insecure piece of code can, if not properly isolated, compromise the entire system.

• Cover