11-27-2020 09:41 AM
It's all about doing risk assessment in my field. Risk is the probability of an adverse event * the cost of said event. All high cost events (eg one such as this which violates underlying assumptions about hardware configuration) must be explicitly considered and mitigated, either through architecture, or through process.
So yes, while I agree the odds of this kind of attack are slim to none in the wild, we still need to think about ways in which our setup can fail, and handle them explicitly.
11-28-2020 03:29 AM
@ijustlovemath wrote:
It's all about doing risk assessment in my field. Risk is the probability of an adverse event * the cost of said event. All high cost events (eg one such as this which violates underlying assumptions about hardware configuration) must be explicitly considered and mitigated, either through architecture, or through process.
So yes, while I agree the odds of this kind of attack are slim to none in the wild, we still need to think about ways in which our setup can fail, and handle them explicitly.
So, the 8-Ball WAS correct! We are back to security.
Trained armed guards or other means of restricting UNTRAINED users from doing "stuff" to your computer in your laboratory are more effective than coding around your physical security needs.
The argument can be made that it is not the user, its the access!
Document USER transactions and training.