El impacto potencial de esto no es bajo, independientemente de cuánta información almacene el thin client.

Específicamente, el riesgo es que un atacante instale algo como un rootkit o software keylogger en el sistema operativo del thin client, que es poco probable que pueda descubrir por inspección. (Esta es una variante del ataque de Evil Maid).

En caso de que algún administrador use ese cliente en el futuro, será un juego para la red. El thin client también se puede usar como una cabeza de playa para lanzar más ataques contra la red o para realizar reconocimientos.

La protección del BIOS evita que esto suceda, al proteger la integridad del sistema operativo del cliente ligero.

La lección más amplia aquí: La mejor práctica le ahorra el gasto y la dificultad de evaluar cada riesgo, lo que, como demuestra esta pregunta, es difícil de hacer.

Los costos son la base para evaluar los riesgos y sus mitigaciones. Si los costos (costos monetarios, costos operacionales, costos de facilidad de uso, etc.) para implementar una defensa (mejores prácticas, etc.) exceden el daño causado por el riesgo realizado, entonces está justificado elegir el aceptar el riesgo .

Este es un concepto bastante básico en la gestión de riesgos.

Las mejores prácticas no son leyes sino recomendaciones. Por lo general, vienen con una explicación de por qué se recomiendan. Si considera que la explicación no se aplica a su caso, puede ignorar la recomendación. Puede que incluso tengas razón con este sentimiento y así puedas ahorrar costos.

Pero tenga en cuenta que, dependiendo de su entorno de trabajo, no puede simplemente ignorar la recomendación, pero necesita documentar por qué cree que puede ignorarse. También podría ser que usted sea responsable en persona si algo malo sucede porque las mejores prácticas se ignoraron. Por lo tanto, a menudo es más fácil y menos riesgoso seguir las recomendaciones que ignorarlas.

Hay una serie de factores que deben considerarse aquí:

1. ¿Cuál es el costo de implementar la medida? Proteger todas las BIOS puede ser una molestia, pero no es un gasto significativo de dinero o esfuerzo.

2. ¿Cuál es el riesgo de que ocurra algo malo? Las posibilidades son bastante bajas, pero el impacto es moderado (se mencionan los keyloggers, hay varios otros problemas con alguien que ejecuta su propio código en su sistema, es decir, que ya no es su sistema). El riesgo real es de bajo a medio.

3. ¿Cuál es el impacto de la implementación? ¿Existen razones legítimas para que el usuario promedio acceda al BIOS de su thin client? En realidad no.

Tenemos algo en lo que la mitigación no cuesta mucho, no tiene un gran impacto y protege contra un riesgo bajo a medio. Yo diría que es un buen argumento para implementarlo, personalmente.

En muchos casos se reduce a una pregunta sobre lo que significa muy bajo riesgo . Si tiene un conocimiento exacto de qué tan bajo es el riesgo, puede hacer cálculos sobre el costo esperado de no mitigar el riesgo.

En realidad, rara vez se sabe el riesgo exacto. A menudo, los posibles problemas de seguridad se descartan como un riesgo muy bajo sin ningún intento de una evaluación real del riesgo.

En muchos casos, se requiere menos esfuerzo para resolver el problema de seguridad que para evaluar el riesgo con suficiente precisión para tomar una decisión informada sobre si abordar la vulnerabilidad de la seguridad. Para mí, ese es el principal argumento para abordar incluso las vulnerabilidades de seguridad de muy bajo riesgo, porque significa que se ahorra la mayor parte del costo asociado con la evaluación del riesgo.

¿Quién puede distinguir la diferencia entre un problema de seguridad que se sabe que es de bajo riesgo y uno que se supone que es de bajo riesgo?

A veces es más productivo evaluar los problemas de seguridad entre sí en lugar de evaluar cada problema de seguridad individual contra un umbral de bajo riesgo.

En su ejemplo específico, usted podría comparar el riesgo de un cambio malicioso de la configuración del BIOS con el riesgo de que la conexión de red en el dispositivo tenga un dispositivo MITM.

  

A veces, las mejores prácticas de seguridad lo protegen contra riesgos que son muy improbables. En esos escenarios, ¿cómo defiende la implementación de estas medidas de seguridad?

No deberías tener que defender nada; Deja que los números hablen por sí mismos:

1. Probabilidad de ataque X ocurriendo = P.
2. Costo total de X si ocurre = TC. (Esto debe incluir el diagnóstico y la solución del incumplimiento, la pérdida de ingresos, la reputación, los juicios, la gestión de crisis, etc.)
3. El costo de tomar medidas de seguridad para prevenir X en primer lugar = C.

La ecuación es simplemente:

  

C < P * TC

Cuando la ecuación es verdadera, se debe implementar la medida de seguridad. Por supuesto, la parte difícil es, para empezar, calcular P y TC, pero es posible que pueda ser demasiado conservador en TC y demasiado optimista en P, y aún así será una inversión valiosa. Además, también obtiene el beneficio adicional de divulgar las medidas de seguridad a los inversores y / o clientes.

Obviamente, esto es una simplificación excesiva de todos los factores a considerar, pero desde un punto de vista de retorno de la inversión (ROI), la lógica debería mantenerse.

La postura que adopte se basa en el entorno en el que está operando. Como mínimo, las políticas de seguridad que cree son proporcionales al presupuesto que tiene y los modelos de amenazas que tiene en mente. Sin una evaluación del valor en dólares que está protegiendo, pasará una cantidad exorbitante de tiempo para averiguar dónde están los agujeros. Por otro lado, los elementos criminales utilizan elementos bajos / no protegidos para buscar objetivos de mayor valor.

También tenga en cuenta que los proveedores que pretenden ayudar a mitigar el riesgo no vienen con la bala de plata para resolver todos los problemas. En última instancia, usted y la empresa son los únicos responsables de la seguridad. Desde un punto de vista comercial, podría pasar los costos de los errores / fallas de seguridad, pero a la larga no podría ayudar. Es un mundo bastante feo por el momento.

Entonces, esta es una especie de extensión de respuesta de schroeder .

Creo que hay una pequeña confusión en lo que entendemos por "riesgo". Usted está considerando el riesgo desde la perspectiva del sistema informático (contraseña del BIOS, instalación de AV, uso de un firewall, etc.). La perspectiva de la que habla Schroeder es desde la perspectiva del negocio: una vez que la máquina ha sido comprometida, ¿cuál es el costo asociado?

Cuando una empresa tiene un 'riesgo', hay algunas cosas se puede hacer :

• Acepte el riesgo: asuma que no ocurrirá nada malo, y si lo hace, no será un gran problema con el que lidiar.

• Evitar riesgos: evite la exposición al riesgo en absoluto.

• Limitación del riesgo (mitigación): reduce la probabilidad de que ocurra el riesgo.

• Transferencia de riesgo (CYA): asegúrese de que otra persona sea responsable del riesgo.

Para ser claros, los dos tipos de riesgo que se discuten en el hilo:

1. El riesgo que tiene una empresa en caso de que un sistema en particular se vea comprometido. Esto puede incluir información financiera del cliente (números de tarjetas de crédito, etc.), así como información de propiedad, secretos comerciales, información clasificada, etc.

2. El OP de riesgo está proponiendo: el riesgo de que una computadora se vea comprometida de una manera específica.

Aquí está el matiz al que me refiero: # 1 es el riesgo del negocio. La estrategia para lidiar con este riesgo es generalmente a través de limitación de riesgo (mitigación) . Ahí es donde entra el # 2. # 2 mitiga la probabilidad de que ocurra el # 1. Consideramos muchos métodos diferentes en los que una computadora puede verse comprometida en el # 2, e implementamos medidas preventivas para mitigar el # 1 tanto como sea posible. Dado que muchas de las "mejores prácticas" son baratas o no son fáciles de pensar (es decir, su costo se justifica fácilmente), tiene sentido seguirlas incluso si, en una base individual, su vector de ataque es altamente improbable.

Con respecto a tu ejemplo:

Todos los accesos a un sistema / red / bosque / cosa que contiene datos seguros, deben mantenerse seguros de punta a punta, sin importar cuán pequeño sea el fin.

Con respecto a la seguridad en general :

Todo acceso a un sistema / red / bosque / cosa que contenga datos seguros, debe mantenerse seguro.

¿Por qué?

Hay una razón para esto. Un solo punto de acceso a una red que contiene datos seguros, necesita seguridad. La información de lo que ha ocurrido en el sistema como un TODO debe ser segura para mantener la información segura en la parte más pequeña. Si un solo enlace en la cadena se rompe, la cadena se rompe.

¿Pero cómo rompo esa cadena si no hay información de seguridad en el cliente? Simple, observando la red. Si puedo ver lo que sucede en la red, puedo aprender qué claves me permitirán superar qué bloqueos, cómo y de qué manera. Entonces tengo una manera fácil de ingresar a su red y obtener sus datos. Por eso, de principio a fin, TODA la actividad debe mantenerse segura.

Vayamos al ejemplo de golpearte en la cara:

1. Crees que tu casa es segura.
2. Tiene escáneres biométricos de huellas dactilares (LIKE ON TV) que significan que solo sus dedos lo llevan adentro
3. Usted toca una perilla de la puerta en un frente de una tienda a 70 millones de millas, seis años atrás
4. Levanto esa impresión
5. Identifico su impresión (a través de un largo proceso de proceso)
6. Utilizo esa impresión para abrir tu casa mientras duermes
7. Te golpeo en la cara

A pesar de que estaba a millas de distancia, y esa impresión tenía muchas otras impresiones, y así sucesivamente, aún podría encontrar su huella allí dentro y usarla para abrir su casa. Esto es muy improbable, pero si REALMENTE quiero hacerlo, aún puedo golpearte en la cara con tiempo, esfuerzo y algo de paciencia.

Aun así, esto no hace más que presentar un ejemplo. En su lugar, vamos a declarar la verdad de la seguridad:

  

El sistema más seguro del mundo, que se encuentra bajo tierra, en un lugar desconocido, quemado y destruido.

Claro, eso es un poco irónico, pero hace entender la idea. Así que sí, esta mejor práctica de seguridad debería seguir utilizándose. Después de todo, su sistema no es el sistema más seguro del mundo, por lo que debe intentar acercarse.

Como ya se ha dicho, la seguridad es principalmente un enfoque de riesgo frente a costo.

Pero en mi humilde opinión, hay otro punto a considerar: como en la seguridad del edificio, una puerta reforzada no sirve de nada si la ventana se deja abierta. Para evaluar correctamente un riesgo, debe saber contra qué proteger. Entonces, proteger el BIOS con una contraseña porque podría ser un vector para un atacante que podría tener un acceso físico . En mi humilde opinión, si un atacante puede obtener acceso físico a una computadora, esta computadora se ve comprometida porque cualquier cosa podría tener un efecto: un registrador de teclas físicas en el teclado, un analizador de red entre el conector interno y el enchufe externo, un dispositivo USB malicioso dentro de la caja , etc.

Pero la contraseña del BIOS es una buena práctica, ya que puede prevenir una infección adicional si un ataque llega a la publicación, y principalmente porque evita que un usuario torpe o descuidado rompa o se comprometa con su propio terminal.