Another think-piece, follow up to my previous post on threat modeling firmware versus attacker time:
https://firmwaresecurity.com/2018/10/11/hardware-firmware-attacks-versus-time-threat-modeling/
Many more, and smarter people than myself are talking about viewing data, particularly PII as a liability.
https://www.techrepublic.com/blog/tech-decision-maker/is-data-an-asset-or-a-liability/
https://boingboing.net/2015/09/11/data-is-a-liability-not-an-as.html and https://www.richie.fi/blog/data-is-a-liability.html
https://www.schneier.com/blog/archives/2008/01/data_as_polluti.html
I believe, on the corporate books, things can be both assets and liabilities, and the pollution metaphor is a great one in this regard – a factory is generally a (depreciating) physical asset. It would cost $millions to replace, and can produce $millions in capital gains over time. But, depending on what it is producing, it may also be a massive liability. eg: Union Carbide https://en.wikipedia.org/wiki/Bhopal_disaster
While people may not generally be dying over data leaks, the scale of some of the leaks that have already happened is enormous, and the pending liability is much bigger.
In the world of firmware – hardware, really, we’ve got remote management systems. At this point it is very clear that everyone in the supply chain considers these to be major selling points – assets, if you will. For the most part, nobody seemed to consider that an end customer might want to disable Intel ME, Intel AMT, or AMD PSP. Some IPMI based systems actively dodge attempts to work around them – if you avoid plugging ethernet into the dedicated management NIC, the IPMI system will simply hop onto the next (onboard) NIC, and the only way to avoid it is to pay extra for an additional NIC! Because, obviously, they are SO USEFUL, why would you want to work around them?
But – as illustrated in this graphic, remote management systems, unlike most other types of firmware /hardware attack allow for continuous, cheap (low risk, low skill) attacks, and grant an extremely high level of power. I should perhaps have drawn the “power” column for Remote attacks as high as the “Hands on for days” attack implant requiring a lab. A lab implant is still less powerful than something baked in from the beginning – in the supply chain itself… as a feature!
Really the only technical difference between BMC and management features, is that (presumably) a supply chain implant is designed for some specific attacks (eg: data exfiltration) whereas remote management features were simply designed to… control the entire system remotely.
I assert that if a customer doesn’t want or need remote management features, they are solidly a liability, not an asset. As in the IPMI “jumping onto any active onboard NIC” example, active countermeasures need to be taken – money spent, by the end customer just to avoid the the risk involved. Such features should be disabled completely from the factory and only enabled when wanted or needed.
Even when they are needed by the end customer, they are both an asset and a liability, like that factory. Sure they help with managing systems – a great deal! But they also inherently add very desirable, and cheap/easy attack surface.
Firmware Security 