This draft white paper identifies seventeen technical trust-related issues that may negatively impact the adoption of IoT products and services. The paper offers recommendations for mitigating or reducing the effects of these concerns while also suggesting additional areas of research regarding the subject of “IoT trust.” This document is intended for a general information technology audience, including managers, supervisors, technical staff, and those involved in IoT policy decisions, governance, and procurement. Feedback from reviewers is requested on the seventeen technical concerns that are presented, as well as suggestions for other potential technical concerns that may be missing from the document.
NIST has released Draft NIST Internal Report (NISTIR) 8221, “A Methodology for Determining Forensic Data Requirements for Detecting Hypervisor Attacks”, which analyzes recent vulnerabilities associated with two open-source hypervisorsXen and KVMas reported by the NIST National Vulnerability Database. The document develops a profile of those vulnerabilities in terms of hypervisor functionality, attack type, and attack source. The objective is to determine the evidence coverage for detecting and reconstructing those attacks and subsequently identify the techniques required to gather missing evidence. The methodologies outlined can assist cloud providers in enhancing the security of their virtualized infrastructure and take proactive steps toward preventing such attacks on their operating environment in the future.
A public comment period for this draft document is open until October 12, 2018.
The National Cybersecurity Center of Excellence (NCCoE) at NIST recognizes the need to address security and privacy challenges for the use of shared cloud services in hybrid cloud architectures, and has launched this project. This project is using commercially available technologies to develop a cybersecurity reference design that can be implemented to increase security and privacy for cloud workloads on hybrid cloud platforms. This project will demonstrate how the implementation and use of trusted compute pools not only will provide assurance that workloads in the cloud are running on trusted hardware and are in a trusted geolocation, but also will improve the protections for the data within workloads and flowing between workloads. This project will result in a NIST Cybersecurity Practice Guide—a publicly available description of the solution and practical steps needed to implement a cybersecurity reference design that addresses this challenge.
NIST’s Cybersecurity for IoT Program supports the development and application of standards, guidelines, and related tools to improve the cybersecurity of connected devices and the environments in which they are deployed. By collaborating with stakeholders across government, industry, international bodies and academia, the program aims to cultivate trust and foster an environment that enables innovation on a global scale. This workshop will help the program through the development of the Cybersecurity for IoT Program and Privacy Engineering Program’s publication on an introduction to managing IoT cybersecurity and privacy risk for federal systems. This will include work to date identifying typical differences in cybersecurity and privacy risk for IoT systems versus traditional IT systems, considerations for selecting and using technical controls to mitigate IoT cybersecurity and privacy risk, and basic cybersecurity and privacy controls for manufacturers to consider providing in their IoT products. A pre-read document has been posted to help guide conversation.
Date Published: June 2018
Supersedes: SP 800-125A (January 2018)
The Hypervisor platform is a collection of software modules that provides virtualization of hardware resources (such as CPU, Memory, Network and Storage) and thus enables multiple computing stacks (made of an operating system (OS) and application programs) called Virtual Machines (VMs) to be run on a single physical host. In addition, it may have the functionality to define a network within the single physical host (called virtual network) to enable communication among the VMs resident on that host as well as with physical and virtual machines outside the host. With all this functionality, the hypervisor has the responsibility to mediate access to physical resources, provide run time isolation among resident VMs and enable a virtual network that provides security-preserving communication flow among the VMs and between the VMs and the external network. The architecture of a hypervisor can be classified in different ways. The security recommendations in this document relate to ensuring the secure execution of baseline functions of the hypervisor and are therefore agnostic to the hypervisor architecture. Further, the recommendations are in the context of a hypervisor deployed for server virtualization and not for other use cases such as embedded systems and desktops. Recommendations for secure configuration of a virtual network are dealt with in a separate NIST document (Special Publication 800-125B). [This revision includes additional technologies for device virtualization such as para-virtualization, passthrough and self-virtualizing hardware devices as well as associated security recommendations. Major content changes in this revision are in: Section 1.1, Section 2.2.2 and Section 5.]
SP 800-125A: Security Recommendations for Hypervisor Deployment on Servers
The Hypervisor is a collection of software modules that provides virtualization of hardware resources (such as CPU/GPU, Memory, Network and Storage) and thus enables multiple computing stacks (made of an operating system (OS) and Application programs) called Virtual Machines (VMs) to be run on a single physical host. In addition, it may have the functionality to define a network within the single physical host (called virtual network) to enable communication among the VMs resident on that host as well as with physical and virtual machines outside the host. With all this functionality, the hypervisor has the responsibility to mediate access to physical resources, provide run time isolation among resident VMs and enable a virtual network that provides security-preserving communication flow among the VMs and between the VMs and the external network. The architecture of a hypervisor can be classified in different ways. The security recommendations in this document relate to ensuring the secure execution of baseline functions of the hypervisor and are therefore agnostic to the hypervisor architecture. Further, the recommendations are in the context of a hypervisor deployed for server virtualization and not for other use cases such as embedded systems and desktops. Recommendations for secure configuration of a virtual network are dealt with in a separate NIST Special Publication (SP), SP 800-125B.
Keywords: Virtualization; Hypervisor; Virtual Machine; Virtual Network; Secure Configuration; Security Monitoring; Guest OS
SP 800-125B: Secure Virtual Network Configuration for Virtual Machine (VM) Protection
How can platform firmware be protected from attacks?
by Judith Myerson
The NIST published guidance on building up platform firmware resiliency. Expert Judith Myerson looks at the NIST guidelines and the major takeaways for enterprises. The National Institute of Standards and Technology, or NIST, published a draft version of the Platform Firmware…
You have to give TechTarget.com your email addres to read the article.
Application Containers are slowly finding adoption in enterprise IT infrastructures. Security guidelines and countermeasures have been proposed to address security concerns associated with the deployment of application container platforms. To assess the effectiveness of the security solutions implemented based on these recommendations, it is necessary to analyze those solutions and outline the security assurance requirements they must satisfy to meet their intended objectives. This is the contribution of this document. The focus is on application containers on a Linux platform.
Keywords: application container; capabilities; Cgroups; container image; container registry; kernel loadable module; Linux kernel; namespace; TPM
Last Modified: 08/25/2017
This vulnerability is currently awaiting analysis.
The acpi_ps_complete_final_op() function in drivers/acpi/acpica/psobject.c in the Linux kernel through 4.12.9 does not flush the node and node_ext caches and causes a kernel stack dump, which allows local users to obtain sensitive information from kernel memory and bypass the KASLR protection mechanism (in the kernel through 4.9) via a crafted ACPI table.
I thought I got all the appropriate NIST announcements, but missed this, found it in Vincent’s recent blog post:
Very exciting to see this NIST document!
Draft NIST Special Publication 800-193
Platform Firmware Resiliency Guidelines
This document provides technical guidelines and recommendations supporting resiliency of platform firmware and data against potentially destructive attacks. The platform is a collection of fundamental hardware and firmware components needed to boot and operate a system. A successful attack on platform firmware could render a system inoperable, perhaps permanently or requiring reprogramming by the original manufacturer, resulting in significant disruptions to users. The technical guidelines in this document promote resiliency in the platform by describing security mechanisms for protecting the platform against unauthorized changes, detecting unauthorized changes that occur, and recovery from attacks rapidly and securely. Implementers, including Original Equipment Manufacturers (OEMs) and component/device suppliers, can use these guidelines to build stronger security mechanisms into platforms. System administrators, security professionals, and users can use this document to guide procurement strategies and priorities for future systems.
NIST just released some guidance for electical grid …and it includes one entry on securing firmware!
“The NCCoE released a draft of the NIST Cybersecurity Practice Guide, SP 1800-7 “Situational Awareness for Electric Utilities” on February 16, 2017. Public comments on the draft will be expected through April 17, 2017. Submit your comments.”
“To improve the security of information and operational technology, including industrial control systems, energy companies need mechanisms to capture, transmit, analyze and store real-time or near-real-time data from these networks and systems. With such mechanisms in place, energy providers can more readily detect and remediate anomalous conditions, investigate the chain of events that led to the anomalies, and share findings with other energy companies. Obtaining real-time and near-real-time data from networks also has the benefit of helping to demonstrate compliance with information security standards.”
“220.127.116.11PR.DS-6: Integrity checking mechanisms are used to verify software, firmware, and information integrity”
NIST has a new IoT-related document, focusing on the “Network of Things”. Abstract:
System primitives allow formalisms, reasoning, simulations, and reliability and security risk-tradeoffs to be formulated and argued. In this work, five core primitives belonging to most distributed systems are presented. These primitives apply well to systems with large amounts of data, scalability concerns, heterogeneity concerns, temporal concerns, and elements of unknown pedigree with possible nefarious intent. These primitives are the basic building blocks for a Network of ‘Things’ (NoT), including the Internet of Things (IoT). This document offers an underlying and foundational understanding of IoT based on the realization that IoT involves sensing, computing, communication, and actuation. The material presented here is generic to all distributed systems that employ IoT technologies (i.e., ‘things’ and networks). The expected audience is computer scientists, IT managers, networking specialists, and networking and cloud computing software engineers. To our knowledge, the ideas and the manner in which IoT is presented here is unique.
Greg Otto has a new story on FedScoop about NIST and IoT security, with NIST’s 2nd edition of SP 800-160:
“This one is unique, it is special because it addresses the fundamental things that they need to do to build security into these systems from the start,” said NIST Fellow Ron Ross in an interview with FedScoop at the Public Sector Innovation Summit. “It’s a different approach. It doesn’t come at the security from the bottom-up, it comes at it from the top down. That’s the number one priority because if we do that right, everything else falls into place.”
There are MANY references to firmware in this spec!! Public comment period for this spec is now through July, so PLEASE send them firmware-centric feedback!
Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems
NIST Special Publication 800-160
Second Public Draft
Public comment period: May 4 through July 1, 2016
This publication addresses the engineering-driven actions necessary to develop more defensible and survivable systems—including the components that compose and the services that depend on those systems. It starts with and builds upon a set of well-established International Standards for systems and software engineering published by the ISO, the IEC, and the IEEE and infuses systems security engineering techniques, methods, and practices into those systems and software engineering processes. The ultimate objective is to address security issues from a stakeholder requirements and protection needs perspective and to use established engineering processes to ensure that such requirements and needs are addressed with appropriate fidelity and rigor, early and in a sustainable manner throughout the life cycle of the system.
I had an email interview with Andrew Regenscheid of NIST, one of the authors of the SP800 BIOS security documents.
Q1: Can you clarify NIST SP80-147’s reference to ‘golden images’ during various platform lifecycle phases? Specifically, does that imply source access to firmware, or is binary-only (‘blob’) ok?
A1: Golden Images
In SP 800-147 and SP 800-155 we end up referring to “golden images” a couple different ways. They’re related, but a bit different.
In SP 800-147, the idea was simply to store and use BIOS update images that you trust. The term “image” is perhaps a misnomer, as we were effectively just talking about saving BIOS updates from the OEM, which tend to include both the firmware image itself and the update utility.
We certainly weren’t imagining that you’d obtain sources. We weren’t even imagining that you’d be able to cleanly separate the firmware code from the update code.
In SP800-155, we referred to golden measurements. The idea here was to have “known-good” measurements for your firmware. An easy example here would be the OEM telling you what you should expect to see in PCR-0 (in the TPM) for each system/BIOS version. If vendors don’t supply this data, you could provision a couple boxes yourself and see what’s in PCR-0. More generally, you could use other tools to do this from the OS (or a UEFI shell). Obviously there’s security implications of taking these measurements from an untrusted environment like the OS, but it still might be a useful check.
Q2: What about the need for updating the trust in the keys baked into the keys? How does a system administrator verify the keys are still valid, using CRL/OSCP or other methods?
Key management will largely be driven by the OEM. System administrators will simply trust whatever trust anchor is baked into the BIOS. I wouldn’t expect most implementations to make it easy to find the trust anchor. Theoretically, you might be able to find the public key that’s embedded in the firmware by searching the contents of the system flash, but that’s not going to be easy without knowing where to look. There’s no API for that.
The idea of blindly trusting the embedded public key might be troubling to anyone that’s followed some of the security incidents at publicly-trusted CAs on the web. But, I’ll note this is a very different use case.
Your BIOS likely just has a single public key embedded for verifying signatures on BIOS updates. That key pair should be held exclusively by your OEM, and only used to sign
updates for its BIOS updates. Your browser, on the other hand, has a couple hundred CA certificates, each of which could issue other CA certificates or web server certificates for any domain online. The odds of a CA compromise or a need to revoke keys/certificates is much, much higher in the case of Web PKI.
That’s not to say we didn’t think about revocation for BIOS signing keys. We thought about it, but ultimately decided the best way to revoke a signing key is simply to replace the public key in the next BIOS update. How else would the BIOS get revocation information? Online certificate status checking using OCSP seems impractical, since you’re not necessarily going to have network access from the BIOS layer. Something like a CRL could work, but how would you download it, where would you store it, and how would you protect it?
To support UEFI Secure Boot (which is completely different from signed BIOS updates), UEFI has its own key store. That key store includes what is essentially a revocation mechanism (DBX- the forbidden signatures database). DBX is intended to be updated from the OS, so revocation makes a bit more sense in that case.
You could imagine using something like the DBX for revocation of BIOS update signing keys, but it’s probably a lot easier simply to replace the trust anchor.
Q2.5 – Question on organizational control over BIOS updates
A: OEMs, as the source of BIOS updates, were the natural choice to sign updates, but we thought some organizations would want to authorize updates for their own equipment in addition to verifying those updates came from the definitive source. To accommodate that use case, we discussed the idea of countersigning in SP 800-147. The idea was that the OEM would sign the update, as well as the organization. The update process would verify the authenticity of the BIOS update by verifying the OEM signature, and verify that is authorized by verifying the organization signature.
Support for countersigning, or other mechanisms to allow organizations to authorize BIOS updates, was never a require part of SP 800-147. However, we included it because we thought some end users in high-assurance environments would want that level of control. For most organizations, I suspect the need for administrative access to apply a BIOS update is sufficient.
I’m not aware of any major OEMs shipping products that support countersigning. If they did, they would need to provide a way to allow end-users to configure a new trust anchor, and tools for countersigning BIOS updates. End-users would be responsible for securely managing the signing key used to countersign updates.
Q3: What does it mean to say a vendor is ‘complaint’ to NIST SP800-147?
For a vendor to say they are “compliant” with SP800-147, all they really need to be able to assert is their BIOS implementation meets all of the “SHALL” statements in Section 3.1. The guidelines also include a number of “SHOULD” statements, which are recommended, but not required. For example, rollback protection is included as a “SHOULD” statement.
Note that there isn’t a formal certification or validation process for testing that BIOS implementations meet the requirements in SP 800-147. However, there are tools that can provide some assurances, like MITRE’s Copernicus tool, or Intel’s CHIPSEC tool.
Q4: If you could re-write SP80-147 today, how would you change it?
I’ve learned a lot about firmware security since working on the original SP800-147. Some of this came when we were rolling out BIOS updates across NIST when our OEMs started offering BIOS updates that added support for BIOS protections. If I were writing SP 800-147 today, I think my guidance on managing BIOS (Section 3.2 in the current document) would be quite different. I think it overemphasizes certain aspects of provisioning, and doesn’t emphasize enough the importance of applying BIOS updates.
Researchers are finding problems, and vendors are patching vulnerabilities. But, a lot of people don’t seem to bother pushing out updates. Why? Because it is relatively complicated, compared to pushing out OS/app updates. It’s gotten a bit better- you ought to be able to just push out a BIOS update utility using whatever patch management tool you have deployed. Still, it isn’t done very often.
But, at this point I consider SP 800-147 quite stable. We submitted NIST SP 800-147 to ISO SC27 for standardization under their Fast Track process. It’s now an international standard as ISO/IEC 19678:2015.
Q5: One of the three NIST BIOS guidance documents is “DRAFT”. When might we see a final draft of that, and/or more BIOS security advise from NIST?
A5: Soon, I hope. I know NIST SP 800-155, BIOS Integrity Measurement Guidelines, has been stuck as a draft for several years now. I do intend to publish a final version, but before the document goes final I intend to put out a new draft that includes updates based on public comments on the 2011 draft, as well as new material for server architectures. That should go out sometime early next year.
In addition, I’m working on firmware security guidelines with a broader scope than what’s in SP 800-147, which only targets the “system BIOS.” There’s a lot of other security-relevant firmware in computer systems, and I’d like to see that protected as well. We’re still in the early stages of this work, but I hope to get a new draft document out in the first half of next year.
End of email-based interview with Andrew. THANKS Andrew!
Note my comments on NIST ‘golden images’ were incorrect, I was thinking they needed blob-free full source, which is not what Andrew clarifies above.