Secure By Default: Platforms
Computing platforms contain vulnerabilities that can be exploited for malicious purposes.
Often exploitation does not require a high degree of expertise, as tools and advice are readily available online. It is now common to see announcements of new vulnerabilities uncovered in widely deployed products, or new malware identified.
Finding vulnerabilities and fixing them is a critical element of our efforts to secure systems, however the scale of the problem is increasing. The reactive approach deals with each new symptom as it emerges, but fails to address the root cause of the problem.
Security mechanisms in today’s computing platforms are often not enabled, or are bypassed to increase performance, improve usability, or to allow maintenance. Platforms are not designed to be secure by default; hence extensive (and expensive) effort must be devoted to managing the risks to our systems.
A new approach is needed to reduce the harm caused by common and emerging classes of threat.
Platforms that are not secure by default cannot represent commercial good practice, and should not be relied upon to protect sensitive data
The rest of this paper will discuss desired characteristics of secure platforms; showing some ideas on how a concerted effort might be made to drive fundamental improvements in platform security. We aim to reduce the risk of a single vulnerability allowing a platform to be exploited. We will also suggest a practical example of how some of these characteristics could be provided.
Desired Characteristics of Secure Platforms
The term ‘platform’ covers a huge range of computing environments and their underlying software and hardware. Examples include a conventional laptop/smartphone with a full OS and underlying chipset features, or a single processor chip onto which bespoke firmware can be loaded and executed. A single hardware device may also be thought of as multiple platforms, each with varying capabilities and security controls.
The following characteristics are intended to be applied to any of the above examples,
Processor Security Controls Limit Access and Cannot be Bypassed
Modern processors have evolved over time, and security mechanisms have been added to defend against or limit the scope of an attack. These measures are hampered or rendered irrelevant by the requirement to support modes of operation which bypass the security features.
For example, x86 architectures provide legacy support for ‘real mode’, and also for
‘System Management Mode’ (SMM). Both of these are required on some platforms (e.g.
SMM code often performs power management functions), but both allow code to run outside the privilege restrictions normally enforced on the chip.
New types of platforms do not require these mechanisms, and so we are at a point where it is feasible to deprecate them where they are not needed. New versions of existing platforms may require legacy support today, but a medium term deadline should be identified beyond which they will not be supported by default.
The elimination of bypasses has long been a core objective of security design, as has
‘least privilege’; limiting the access of a component to that required to do its job (in the above example, power management functions should not be given arbitrary memory access). A secure platform should have a clear hierarchy of control, and limit unnecessary access to system resources.
Direct Memory Access (DMA) is Limited and Controlled
Peripheral devices on a platform can be anything from graphics cards to wireless
networking devices; as such they can require direct access to memory and can potentially access/alter data on the core platform.
Any of these devices could be malicious (attached to the platform by an attacker), or compromised (a vulnerability in an existing peripheral allows an attacker to gain control of it). It is therefore good practice to limit access to areas of memory required for
operation, and to deny access completely to untrusted peripherals. These controls will limit the potential for an attack on the core platform via a peripheral device.
A secure platform should be able to limit the direct memory access granted to peripherals, and to report which restrictions are in place.
DMA from External Devices is Additionally Protected
Some external interfaces (such as Firewire or Thunderbolt) also offer DMA capabilities;
hence privileged access to the core platform is exposed outside the physical casing. This raises the possibility of an attack via this interface requiring only the briefest physical access to the platform.
A secure platform exposing an external DMA-capable interface must mitigate the impact of unauthorised access, e.g. by requiring authentication of all attached devices.
Central Processor Access From Other Processing Elements is Minimised and Controlled
There can be performance or efficiency benefits to allow processing elements such as graphics processors access to main processor resources. It is important to realise that these accesses can potentially be used to attack the main processor.
Again the principle of ‘least privilege’ should apply in this situation; access should be limited to the resources required to do the job.
A secure platform should ensure that external accesses to the main processor from other processing elements are strictly limited to those required for operation. Ideally it should be possible to disable them when sensitive data is being processed.
Processes Consuming Platform Resources can be Identified and Controlled
The owner of a computing platform may (depending on the deployment scenario) be the user, the enterprise, or a service provider. This entity should be able to determine which processes are running, and to prevent unwanted software from executing.
A secure platform should not permit arbitrary resource consumption in an opaque manner.
Debug Functionality Does Not Compromise Security
Most platform components incorporate test circuitry such to enable product testing during development and on the production line, for example using JTAG functionality to probe
On a secure platform, debug features should be controlled once production testing is complete. Debug features should not allow unprivileged access to protected resources.
I/O Control
Even if it is not possible to attack a process directly, malware can potentially hijack the input or output paths. A passive attack could capture sensitive data (e.g. voice traffic passing from the microphone to a VOIP encryption application), while a more active
‘man-in-the-middle’ attack could alter or insert data (e.g. entering commands to subvert the system, or overwriting alert messages with more benign alternatives).
A secure platform should treat control of input/output paths to/from applications processing sensitive data as a security function, and limit access accordingly.
Secure Device Identity
In addition to strong user authentication (such as a smartcard or other token-based mechanism), a secure platform should be able to strongly identify itself to the network.
Most widely deployed systems today use port or MAC address-based device
authentication, which is easy to spoof and can be inflexible in a mobile environment.
Strong, reliable device identification allows access control decisions to be made on a per- device basis, as well as per-user (e.g. some platforms may be able to access data not available to less protected hardware). Additionally such mechanisms can automate asset management processes and keep track of valuable devices. For example, log files would show when and where each device has been used, and by whom. It becomes unnecessary to manage bureaucratic processes to document where devices have been deployed.
Secure Credential Storage
A secure platform should provide a mechanism for storing private keys such that the keys themselves are not directly accessible to applications. The platform can then make use of these keys (for signing or encryption) without exposing them to theft and use on another platform.
Such a mechanism offers a degree of protection for sensitive keys such as authentication credentials for a web service; potentially a malicious process on that platform can still produce valid signatures, but it cannot steal the credentials to later access the service from elsewhere.
Measured/Verified Boot
An unauthorised entity should not be able to modify the boot process of a secure platform, and any attempt to do so should be detected.
During the boot process, highly privileged code is executed which has access to most of the platform’s resources. Malicious implants at this level are difficult if not impossible for the Operating System to detect; protection in hardware is required.
Verified Boot is a mechanism which only allows authorised code to be executed during boot, e.g. only code signed by the platform manufacturer.
Measured Boot is a mechanism by which the platform can record which code is loaded during boot, and provide this information to a remote entity in an authenticated manner.
The remote entity can then use this data to make access control decisions based on the state of the platform.
A secure platform should implement both of these mechanisms, continuing as far as possible into the boot process.
Secure Update/Recovery
Modern software and firmware is designed to be updated ‘in the field’ (post-production).
This can be to fix a bug or security vulnerability, or to allow a corrupted system to be re- initialised into a usable state. Potential threats arise both from malicious updates and also from slow deployment of security updates leaving platforms in a vulnerable state.
A secure platform should only accept updates and other executable code from an authenticated source. Security updates should be made available and deployed onto platforms as rapidly as practical following discovery of a flaw.
Control Flow Integrity
The control flow of software describes the order in which commands are executed. A common attack vector is to target critical memory locations which direct the control flow.
Typically these should not be accessible; however software bugs can expose them. A buffer overflow in which the return address of a function is overwritten is a example of such an attack. Reducing the harm caused by these bugs requires a platform to either prevent dangerous memory corruptions from occurring, or to reduce the chances that an attacker can gain control as a result.
Security Primitives
Many platforms provide features designed to enable/improve security within
applications: controls on execution of code in arbitrary memory, stack protections, and implementations of common crypto functions (including entropy generation) are all good examples.
While the secure development of applications is outside the scope of this paper, we observe that including these primitives and encouraging their use is hugely beneficial to platform security. Re-use of standard components and technologies simplifies security design and also the assurance process.
A Practical Example
Having described the characteristics of a secure platform, we should now show how some of these might be realised using technological primitives that exist today. Further work is still required to deprecate legacy features and implement robust I/O control; however there are grounds for optimism that the overall goal is achievable.
Robust Domain Isolation on a Secure Platform
A computing platform will process sensitive data; in a connected world it is likely also to be required to process untrusted data in a secure manner. For example, email access usually shares a platform with a web browser; web-based malware can compromise corporate and/or personal data.
Limiting/monitoring web access reduces the risk, but some users require access to untrusted data (e.g. if they work with untrusted 3rd parties, or conduct research using potentially untrusted sources) in order to carry out critical tasks.
Improvements to platform security require effort and resources, and may break existing insecure/legacy implementations. We believe that confronting these issues is not only important but necessary in order to deliver the next generation of secure computing platforms.
A secure platform can be used to isolate sensitive and untrusted domains such that data/code running in one trust domain cannot interfere with or leak into another. This includes minimising the level of information which can pass between domains via a
‘side-channel’, e.g. timing information.
One approach to implementing this is to use virtualisation combined with the other characteristics described above:
• A purpose built baremetal hypervisor designed to isolate virtual machines (VMs) from each other.
• Trusted/Verified Boot ensuring that the system (up to and including the hypervisor) boots up in a known state, and that this can be verified remotely.
• Hardware-level controls exist to limit access to/from peripherals on a per-VM basis; legacy modes of operation which bypass these controls do not operate on the platform.
The result is a higher degree of confidence that processes/Operating Systems running in different virtual machines can be effectively isolated from each other.
Several of the above features are implemented in some platforms today: the Trusted Platform Module (TPM) is capable of implementing Secure device Identity; Secure Credential Storage, and of storing/reporting measurements of the platform state during boot.
NIST, the US technology standards agency, has produced guidelines1 for implementing measured boot and firmware signing at the BIOS level of a PC platform.
TPMs are deployed in a significant proportion of laptops as well as desktops and servers.
Input/Output Memory Management Units (IOMMUs) exist which support access controls for peripheral devices.
These features should be activated and used where available (even if not all are available) and implemented across the range of existing computing platforms, from servers to mobile devices.
Summary: Secure Platform Characteristics
1. A secure platform should have a clear hierarchy of control, and limit unnecessary access to system resources.
2. A secure platform should be able to limit the direct memory access granted to peripherals, and to report which restrictions are in place.
3. A secure platform exposing an external DMA-capable interface must mitigate the impact of unauthorised access.
4. A secure platform should ensure that external accesses to the main processor from other processing elements are strictly limited to those required for operation.
Ideally it should be possible to disable them when sensitive data is being processed.
5. A secure platform should not permit arbitrary resource consumption in an opaque manner.
6. On a secure platform, debug features should be controlled once production testing is complete. Debug features should not allow unprivileged access to protected resource.
7. A secure platform should treat control of input/output paths to/from applications processing sensitive data as a security function, and limit access accordingly.
8. A secure platform should be able to strongly identify itself to the network.
9. A secure platform should provide a mechanism for storing private keys such that the keys themselves are not directly accessible to applications.
10. An unauthorised entity should not be able to modify the boot process of a secure platform, and any attempt to do so should be detected.
11. A secure platform should only accept updates and other executable code from an authenticated source. Security updates should be made available and deployed onto platforms as rapidly as practical following discovery of a flaw.
12. A secure platform will defend against memory corruption events which could affect the control flow
![[Y707.Ebook] Free PDF Food Security And Development Country Case Studies From Nagothu Udaya Sekhar Edt.pdf](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==)