chrisjx wrote:Anyone have any thoughts on the Stuxnet malware and the implications with microcontrollers we use for our projects?
Problem No 1: The siemens SPS stuff that got used has a hardcoded default password that can't be changed easily!
To me a default password that is known to everyone (even to google) is as good as a popup with the message If you really want to enter type 'yes I want to'
chrisjx wrote:And besides the security implications, what kinds of things can we do to design more robust, resilient sensor/control networks?
Somehow it's all about requirements (which comes down to *money* surprise surprise).
For example "remote support must be possible at any time without trained persons on site"
hmpf... A manufacturer might also want this because they don't have to give there valuable knowledge
to someone else.
Possible easy counter-measures:
- Use a physical switch to change the mode of operation. For example switch the SPI CLK between ICSP and peripheral ICs. Imo it's a good idea that the system won't work as long as it's programmable because people tend to be lazy.
- Force the user to change the default password. E.g. Cut functionality if the default password is in place.
In the end you have to define against what/whom you want to defend.
If you opponent has physical access, time, skill and money (which the stuxnet authors clearly have), you need to define you security as "breakable in time X"
and take measures so that this timeframe will stand.
This is far beyond private/hobbysts projects.
"I have not failed. I've just found 10,000 ways that won't work." - Thomas Edison