¿Cómo mitigar los riesgos de usar accesorios electrónicos importados de terceros?

Question

¿Cómo mitigar los riesgos de usar accesorios electrónicos importados de terceros?

#1 de safesploit (0 votos)

1

Como alguien que es naturalmente bueno en reconocer riesgos y que se esfuerza por mantener una visión integral de la seguridad, me pregunto cómo evaluar y reducir los riesgos de los accesorios de hardware (es decir, la carga de complementos, los cables Thunderbolt), específicamente dispositivos periféricos o genéricos importados de una empresa que no sea la fabricación del dispositivo principal (es decir, Apple).

Obviamente, cada vez que use hardware de terceros, existe un pequeño riesgo de que contengan spyware físico o digital. Esto es cierto el 100% del tiempo a menos que usted mismo haya construido el hardware. Hay casos de software espía físico y digital, tanto en fabricantes estadounidenses reconocidos como en fabricantes extranjeros.

Por lo general, es más seguro pedir un accesorio electrónico, como un cargador de iPhone, directamente del fabricante, y el riesgo aumenta cuando se usan terceros y más con los revendedores.

No estoy seguro de qué tan grande es el riesgo al usar un cargador de iPhone de terceros, pero es un riesgo suficientemente grave si se toma en serio la seguridad, al menos debería reconocerlo, ya que tendrá acceso físico a su teléfono, y potencialmente a su computadora y toda la red. El riesgo obvio es que podría instalar rootkits, estoy seguro de que podría haber más.

¿Cuáles son los riesgos de usar accesorios electrónicos de terceros y cómo los mitigamos?

hardware hardening spyware threat-mitigation opsec

pregunta dopeideas 25.08.2018 - 09:45

fuente

1 respuesta

Lea otras preguntas en las etiquetas hardware hardening spyware threat-mitigation opsec

Protección CSRF y aplicaciones de una sola página alojadas en S3 (sin backend). ¿Es esta una defensa viable contra los ataques de correlación?

score 0 · Answer 1

¿Cuáles son los riesgos de usar accesorios electrónicos de terceros y cómo los mitigamos?

Sin ser demasiado excéntrico y desalentador para evitarlos a todos juntos. Yo sugeriría utilizar soluciones de terceros de código abierto, cuando sea posible. Ahora, se deben aplicar ciertas precauciones aquí ya que el sistema operativo puede decidir administrar el firmware de los accesorios de terceros automáticamente. Si las actualizaciones se implementan de esta manera, se debe realizar la validación de la suma de comprobación, pero esta es la situación menos deseable, por lo que terminaré aquí. Usted debe administrar las actualizaciones de firmware de forma manual y, si hay soluciones de código abierto disponibles, puede revisar y evaluar el uso del código antes de implementarlo en el dispositivo.

Los riesgos asociados con los componentes de software de terceros discute algunos puntos:

¿Se podría colocar el código en un entorno de desarrollo o de prueba y comprobar si existen fallas de seguridad antes de que entre en producción?
¿Se ha incluido alguna vulnerabilidad en el diccionario CVE o en una base de datos de exploits?
¿Puede probar los módulos de terceros una vez que estén en su lugar? ¿Qué recurso tiene si se encuentra una falla de seguridad?
Si se explota algo, ¿qué es lo peor que puede pasar? ¿Qué información sensible (si existe) podría estar expuesta? ¿Qué sistemas podrían desconectarse?

Cómo hacen los hackers ¿Encontrar vulnerabilidades en sistemas operativos de código cerrado? Puede darnos una idea de cómo encontramos vulnerabilidades que no se han divulgado anteriormente. Otro punto sobre la mitigación de los riesgos es reconocer "¿qué es lo peor que puede pasar?". Muchos cometen este error de tratar de hacer que un sistema sea impenetrable, pero luego no entienden cómo manejar una brecha de seguridad. ¿Cómo trato con un servidor comprometido? dio Tengo una visión amplia para abordar un sistema comprometido de manera diferente, y el plan de acción diseñado a partir de un modelo de amenaza (auditoría de la seguridad de la infraestructura).

Nunca es agradable prepararse para cuando su sistema se verá comprometido, pero salir adelante es mucho mejor para OpSec a largo plazo. La comunicación deficiente y la planificación del modelo de amenaza a menudo se pueden ver cuando se produce una fuga en la base de datos, lo que ocurre por una inyección de SQL.