As mentioned earlier:
Last night I gave a talk on UEFI firmware security for a sysadmin POV. This presentation was my first attempt at trying to gather the various hardware lifecycle models into one place, and start adding NIST firmware-centric platform lifecycle as well as currently-available firmware vulnerability assessment an forensic tools to accomplish these new tasks. The models are not well integrated yet. I’ll be giving an improved version of this talk next month at SeaGL.org, and will try to have the model section more clearly written.
On the QEMU/OVMF slide, I say “no danger of bricking hardware”. …I should clarify that. 🙂 By that I meant using fully virtualized environment, there’s no hardware to break. However, you can also use QEMU/OVMF to debug actual hardware (eg, USB devices, PCI cards, etc.), since QEMU can proxy some requests to direct hardware. ….so, you could potentially ‘brick’ some hardware (eg, USB devices, PCI cards, etc.) with QEMU/OVMF, if you’re doing tricky things, and not careful.
NISTs 147 has basic guidance, as well as some ‘extra’ guidance for organizations that want to do more, like keeping a ‘golden image’ of the firmware. (When I first read the 147 spec, I thought the Provisioning stage was a stage for the OEM/IBV and their CAs, not for an enterprise sysadmin…) As I understand it, any ‘golden image’ would be source code, not precompiled firmware ROM binaries. I presume NIST spec was written in to an abstract model, where firwmware sourcecode is fully-available. I presume some governments and large companies would be able to obtain the full source of their firmware from the ISA/OEM/IHV vendors, and do a ‘golden image’. For the rest of world, we have nearly 100% closed-source IBV code, so you can’t do this ‘golden image’-based extra level of guidance.
On Intel systems, the Intel Firmware Support Package (FSP) contains binary-only code (‘blobs’) that UEFI and coreboot use to work on modern Intel systems; unless you have the FSP source, I don’t think an org could do the NIST 147 ‘golden image’ stuff. Some ARM systems, and perhaps AMD with it’s AGESA firmware package, might have more chance at fewer blobs. Fully Open Source Hardware/Firmware/Software-based stacks would enable ‘golden image’, so FOSS has one advantage at NIST 147 support than closed source HW/FW/SW. So Novena and any Libreboot-based system would be good, any modern Intel-based system (including Purism) will not be able to do ‘golden image’ provisioning. Pragmatically, I think the best most of us can do today for the NIST 147 Provisioning stage is run CHIPSEC/FWTS tests against it, and use CHIPSEC or other tools to capture the ROM, and that ROM.bin will be as close as you can get to a ‘golden image’.
Similarly, in the Recovery phase, I’m not sure that most orgs would be able to restore a system with a ROM dump today, without more tool documentation. Instead, I presume any ROM updates are going to be coming from your vendor, using the UEFI update mechanism. If your vendor’s update tools has the ability to ‘roll-back’ to an old image, you’re lucky.
I’d love to get feedback from sysadmins and other vendors about errors in the presentation, hopefully before SeaGL.org, for next revision.
Beyond this talk, LegbaCore has great advise for sysadmins using MITRE Copernicus for Windows enterprises. Copernicus, unlike CHIPSEC, scales, see the LegbaCore talk from RSA 2015.