White Paper

WHITE PAPER 7 Tenets of Layered Security in Embedded Design mrcy.com 5 Least Privilege The principle of least privilege says that your systems' software components should only be granted the minimal privileges necessary to do their job, and nothing more. Applications (and users/operators) should only have access to the minimum set of interfaces and services necessary for their job. Too often software developers and system engineers take the shortcut – inadvertently (or even explicitly) granting excessive privileges to applications, with an assumption of trusted operator and/or application behavior. That assumption will be quickly invalidated by the attacker. Instead, embedded systems should be built using Mandatory Access Controls (MAC). Unlike Discretionary Access Controls (which can be modified at-will by users and administrators), systems built upon Mandatory Access Control quantify access grants and restriction policies during system design – controls that are always enforced in the fielded device. As such, there is no user or administrative way to bypass/disable the security controls within the fielded device. Even if an attacker is successful in compromising a subcomponent of the system or gains root-level access, they will not have a way to modify or disable security settings of the device. When combined with least privilege, Mandatory Access Controls greatly constrain the attacker 's freedom of maneuver, and blocks their ability to modify, disable, or disrupt system services. Properly implemented MAC policies do not interfere with normal system operation, and they still allow the system to work as designed and intended. The policies can also be updated in a secure and controlled manner by the system implementer. However, Mandatory Access Control intentionally prevents systems from operating in unintended ways, which is a highly desirable property in embedded computing. If you need to deploy that graphics driver for functionality, then go for it. Just be careful not to allow unauthorized components to access it if not absolutely necessary, a principle known as Least Privilege & Mandatory Access Control. Integrity Monitoring and Auditing You can't take action against an attacker if you don't know when your system is being attacked. Integrity monitoring and auditing are important techniques for knowing when a device is being attacked and/or whether it has been compromised. These warnings give you the potential to stop an attacker before it is too late, or at least learn how they exploited your system and what they were able to accomplish after the fact. Typical techniques include network and OS-level anomaly detection, system log monitoring, and scanning for known malware. They allow the system operator to recognize when some portion of the system may be compromised and take action against the attacker, revoke trust accordingly, or both. Our platforms serve as a trusted foundation so you can innovate securely and protect your device against current and future threats. Furthermore, auditing is a requirement of many compliance regulations as the techniques help organizations detect unauthorized modifications to important files, data, or other aspects of your system. HIPAA, NIST, FISMA, NERC, and PCI all require or recommend integrity monitoring and auditing for critical applications and data on distributed systems. Properly implemented, auditing and monitoring allow you to know when you've been attacked, help quantify the damage, and enable you to recover more quickly – preventing lost time, revenue, and damage to your reputation. Secure Updates Secure updates need to consider the entire stack, from hardware all the way up to the OS. Handling updates in a secure fashion is (not surprisingly) difficult and is also commonly handled incorrectly by some systems. How we handle updates is dictated by our threat model and the which case we can implement signature checking), or we use block-based updates, or update independent packages or files. Regardless of how we perform updates, it 's probably safe to assume that at some point we'll

• Cover