1

As someone who is naturally good at recognizing risk and who are striving to maintain a wholistic view on security, I’m wondering how to evaluate and reduce the risks of hardware accessories (I.e. charging plug-ins, Thunderbolt cables), specifically peripheral or generic devices imported from a company other than the manufacture of the primary device (I.e Apple).

Obviously, any time you use third-party hardware there is some small degree of risk they contain physical or digital spyware. This is true 100% of the time unless you built the hardware yourself. There are cases of physical and digital spyware in both big-name U.S. manufacturers and foreign manufacturers.

It’s usually safer to order an electronic accessory such as an iPhone charger directly from the manufacture, and the risk increases when using third parties and further with resellers.

I’m not sure how large the risk when using a third-party iPhone charger is, but it’s a serious enough risk if you’re serious about security that you should at least recognize it since it will have physical access to your phone, and potentially to your computer and whole network. The obvious risk is that it could install rootkits, I’m sure there could be more.

What are the risks of using third-party electronic accessories and how do we mitigate them?

0

What are the risks of using third-party electronic accessories and how do we mitigate them?

Without being too eccentric and discouraging towards avoiding them all together. I would suggest using open source third-party solutions, where possible. Now, certain precautions must be applied here as the OS may decide to manage the third-party accessories firmware automatically. If updates are deployed like this, checksum validation must be performed, but this is the less desirable situation, so I will end that here. Firmware updates should be managed by you, manually, and if open source solutions are available, you can review and evaluate using the code before deploying it on the device.

The Risks Associated with Third-Party Software Components discusses some points:

  • Could the code be placed in a development or test environment and checked for security flaws before it goes into production?
  • Have any vulnerabilities been listed in the CVE dictionary or an exploit database?
  • Can you test the third-party modules once they’re in place? What recourse do you have if a security flaw is found?
  • If something is exploited, what’s the worst that can happen? What sensitive information (if any) could be exposed? What systems could be taken offline?

How do hackers find vulnerabilities in closed source operating systems? May give insight into how we find vulnerabilities which have not been disclosed previously. Another point about mitigating the risks is acknowledging 'what is the worst that can happen?'. Many make this mistake of trying to make a system impenetrable, but then do not understand how to handle a security breach. How do I deal with a compromised server? gave me a broad insight into approaching a compromised system differently, and the action plan devised from a threat model (auditing the infrastructure security).

It is never pleasant preparing for when your system will be compromised, but coming out ahead is much better for long-term OpSec. Poor communication and threat model planning can often be seen when a database leak occurs, which happens by an SQL injection.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.