1.2.5. Remove debug for all interfaces

[cetome]

Enabled debug interface do not only apply to FPGAs. For example how many devices feature a JTAG port that allows you to dump and rewrite the firmware without authentication?

[scriptingxss]

Unsure if I am following the question. There are several secure JTAG implementations (platform / board dependent) that do require authentication and sometimes have the ability to monitor the JTAG bus for electrical pulses to disallow debugger connections. The problem is that there is not a secure JTAG standard that is followed.

FPGAs do have debug capabilities. See the following: https://www.xilinx.com/products/intellectual-property/debug-bridge.html https://www.xilinx.com/products/design-tools/vivado/debug.html#remote

[cetome]

I wasn't clear: I suggest that the clause 1.2.5. applies to all debug capabilities, and not only FPGAs. This includes "administrative backdoors". The authentication part should be covered by 1.2.4.

From what I understand, the current requirement only targets FGPAs. We can imagine a device externalizing the development of its web panel to a 3rd party that leaves HTTP Trace enabled.

Again: the suggestion is to extend the clause to all interfaces beyond FPGA :)

[scriptingxss]

Ah, I see. Debug capabilities or features may always exist in some form. 2.2.4 and 1.4.1 overlap a bit but cover security controls around debug functionality beyond hardware.

I think we would want to add a little more to this FPGA requirement such as: Verify that debug capabilities in FPGAs are disabled on production PCBs.

Other thoughts: Add a level 3 requirement around FPGA bitstream encryption. Verify that FPGA bitstreams are encrypted.

Might make sense to move 1.2.4 and 1.2.5 out to chapter 5. @cbassem Thoughts?

[scriptingxss]

Applied updates to 1.2.5 and added an L3 in chapter 5 for FPGA bitstream encryption