Cybersecurity *IS* "Defense in Depth".

I'm not any kind of security expert.  I'm just a real-time/embedded instrumentation developer who needs, from a security perspective, to Lock Shit Down.

No matter how much you know about your hardware and software, you really know very little of use until you get down to "Formal Proofs of Correctness" for all parts of the system.  Which are scarce, to say the least, presently limited to academic exercises or special-case military-type implementations.

When I came across anything that could use a network to affect the boot process, I'd ask IT to firewall it in our routers (in case the on-system configuration of that capability failed or was overridden), and write a test to show that the firewall was at least trivially working to meet that need (which the customer would also run to help ensure system security).

Then we came across firewall vendors who explicitly prevented closing such channels, or didn't explicitly show they were open.  We needed to assume our external firewalls would lie to us.

So I started preparing for "Defense in Depth", to have a series of simple firewalls present at every opportunity that wouldn't destroy latency or throughput (such as within network interface hardware and drivers). This worked well enough when on a wired interface, but proved inadequate when our systems started supporting wireless interfaces.

I finally had to move my embedded applications into VMs (at a significant increase in platform hardware cost), and implement firewalls at every opportunity both within the VM and between the VM and the host OS/hypervisor.

All these firewalls primarily concerned blocking traffic that wasn't related to the instrument functionality itself, traffic that was out-of-band relative to the application.  To keep things small and fast, we avoided stateful firewalls.

As the platform hardware capabilities grew (to multicore ARM), we shifted from tiny "secure" RTOSes to Embedded Linux, which meant we also needed to address hundreds of CVEs on our platform if we wanted to sell into certain markets.  This pushed us to consider using stateful firewalls.  Not to detect traffic related to a CVE, but instead to block everything that wasn't valid application traffic.

From a black-box perspective, our system eventually became immune to all know attacks, including fuzzing.  What it took to finally get us there was a formal, provable specification of ONLY our instrumentation application protocol.  This specification took the form of a lightly modified version of the firewall rule syntax: Our specification was executable!  We used it not just to initialize the firewall, but also to generate the application interface code.  A completely separate version of the specification was used for testing and validation.

Best of all, this made the instrument interface-agnostic and also agnostic to higher-level protocols: We no longer cared where the application traffic was coming from, wired or wireless LAN, even including everything from serial interfaces to cellular gateways (including SMS!).

Bottom line:  1) Use simple firewalls to block all-but-application traffic from the platform.  2) Use stateful application protocol firewall(s) to permit only valid application traffic.

Unfortunately, while this works well for "simple" M2M instrumentation interfaces, it is extraordinarily difficult to scale to more complex and versatile environments, such as a web browser on a PC (or even a Raspberry Pi).

However, it SHOULD scale well to the IoT world.  But it MUST do so in a way that consumers will accept, which means keeping security holes small in both number and duration, especially for conveniences like DHCP and semi-automated WiFi configuration.

To do this, the common internet protocols relevant to IoT must be recast in minimal forms that will support the required IoT functionality and nothing more, and sets of stateful firewall rules must be generated for these protocols.  Then every IoT device must include internal stateful firewalls to execute them.

To do so with any hope of both system-level and application-level security, the IoT application itself  must run in a VM. Which means only processors capable of VM support will be useful for "Secure IoT".  At present this rules out the tremendously popular ARM Mx family of embedded processors, but there is hope that upcoming members of this family will inherit the VM capabilities of their larger brothers.