White Paper

WHITE PAPER 7 Tenets of Layered Security in Embedded Design mrcy.com 3 Threat Modeling Applying proper security engineering to our systems enables us to establish a security posture for our systems and ensure we're enabling the right security protections. Threat modeling guides appropriate selection of system configurations and option, determination of sufficient security measures, and determination of effective protection by those measures from actors with the given level of access. As embedded systems become more complex: forming systems of systems, or even systems of system of systems, it 's increasingly challenging to identify potential vulnerabilities. To define a threat model, start by defining: 1. The type of device or system 2. Where it is located 3. How it is used 4. What software/firmware is running From there, narrowing down what data and applications need protecting and where they are in the system further defines the potential threats and the security required to mitigate them. Some questions that may help further define the threat model include: 1. In what ways does the system interact with the outside world? 2. Does an attacker have physical access to the system/ device? 3. What level of sophistication do you believe your adversary to have? How easy will it be for them to obtain your device? 4. How do we handle fielded updates? 5. What kind of storage does this system have? Is it read-only? 6. Does the system have performance restrictions? 7. Does the system have specific security requirements? Threat modeling is the first critical step to methodically securing any system, whether it is a device to be deployed in the field, or an industrial manufacturing system. Without a defined threat model, vulnerabilities remain in the system for attackers to exploit. Data at Rest Protection Your applications, configurations, and data aren't safe if they 're not protected at rest. Period. You can protect your applications and data at rest in one of two ways: 1. Prevent the attacker from ever gaining access to this information in the first place . 2. Make it impossible for the information to be understood at all. Embedded devices are now distributed by the millions to consumers around the world. Therefore, unless you can guarantee that your system remains physically inaccessible behind guns, gates, and (trusted) guards, preventing the attacker from ever gaining access to your data and intellectual property is an exceedingly tall order. This leaves us with method two: Making it impossible to understand the information at all. Though there are many ways to obfuscate or otherwise garble your data and applications to make them more difficult to understand, most aren't worth the effort and are often trivially bypassed or subverted. When an attacker has access to your software or data, it 's only a matter of time before they figure out how your system works. However, if your applications and data are encrypted with proven cryptographic algorithms and the decryption key is not accessible to the attacker, it 's game over. At the very least, you have forced the adversary to use a more intrusive method of attack to achieve their objective. Properly implemented, encryption at rest is designed to protect the confidentiality of your sensitive data from physical access. Encryption can also protect the integrity of the software components on a device. For example, encrypted storage volumes can prevent attackers from injecting malware, modifying configurations, or disabling security features on a device. Attack Surface Reduction The more code you deploy, the more opportunity an attacker has to find an entry point into the system. Attack surface reduction is very broad and includes system- level mitigations, the software development lifecycle (SDLC), and data input verification / sanitization. Attack surface reduction is one of the areas where we need to layer multiple What data and applications need protection and where are they located in the system?

• Cover