Okay, so let me first start by saying that this is a step in the right direction. I firmly believe that embedded system manufacturers who are looking for improved security and forming partnerships with security companies is a good thing. However, and this is a BIG however, look at the track record. I wouldn’t be doing this justice if I didn’t mention the freakin’ huge gaping security hole that HD Moore found in just about all VxWorks devices because they left debug functionality turned on! I’m sorry, but there are just some things that cannot be helped by security companies, and thatâs poor security practice. Oh, and furthermore, so many embedded systems vendors give you a backdoor in your firmware, which gives administrative control, where I can turn off any extra layers of protection. And don’t get me started on Mcafee, “Oh look, /proc is a virus, I will just delete it!” Great, thanks for that. Security is not about add-ons and features, itâs about processes and controls. Wind River came out and said, “But our operating system is secure” yet it wasn’t, not even close. Security is culture, not products, and I sincerely hope embedded device manufacturers adopt a more security-focused culture.
To make matters worse, we constantly run into issues where companies have very poor patching polices for these devices. The reason? Itâs an “embedded device,” not a “computer.” Look, we can point the finger at a number of different vendors, and there is plenty of blame to go around. However, we feel there are limits to that blame. Sure, debug by default is dumb. Sure, having simple buffer overflows in your product is laughable. But, we as security professionals should assume these types of vulnerabilities exist. Once we accept this simple fact, you can architect your environment so that if these eventual vulnerable applications/systems/devices/people are exploited or exploitable you can quickly react and contain the incident.
-PaulDotCom and strandjs
Originally on episode 231.