¿Son aceptables las fallas de seguridad si no se puede derivar mucho daño de ellas?

Su pregunta es: ¿Son aceptables las fallas de seguridad si no se puede derivar mucho daño de ellas?

La respuesta es sí , si así lo deciden las empresas y al mismo tiempo entiende las consecuencias.

Lo que estás haciendo se llama evaluación de riesgo. Para cada riesgo, debe resaltar las consecuencias para su empresa cuando se crea una instancia. En base a esa evaluación, usted (usted = alguien que tiene el poder de tomar la decisión negocio ) tiene tres opciones:

• puede aceptar , asumiendo que los costos de solucionarlo no valen las consecuencias
• puedes mitigar : arréglalo hasta el punto en que puedas aceptar las consecuencias
• usted puede asegurarse contra esto, descargando efectivamente el riesgo a otra persona.

Como puede imaginar, hay varias áreas importantes en una evaluación de riesgos.

El primero es la evaluación de las consecuencias y la probabilidad. Hay numerosos libros y artículos sobre cómo hacer eso; al final del día, esto se basa en el vigoroso movimiento de la mano y la experiencia. La salida nunca es como la de los libros

  

tenemos un 76% de probabilidad de que esto ocurra, lo que nos costará 126,653 €

sino más bien

  

bueno, creo que este es un riesgo que debemos cuidar

Tenga en cuenta que la parte de "consecuencias" a veces puede ser cuantificable (por ejemplo, la pérdida de ganancias para el comercio en línea), pero generalmente no lo es (pérdida de imagen para su compañía, por ejemplo).

Además de los dudosos aspectos teóricos de las evaluaciones de riesgos, hay una gran ventaja que siempre debería aprovechar: usted pone un riesgo en la mesa y debe tratarse de alguna manera.

Este no es solo un lugar donde el que pierde la espalda es su nombre noble, es la herramienta correcta para resaltar dónde deben ir los esfuerzos de seguridad de la información. También aumenta su visibilidad (no hay tantos casos proactivos en los que puede aumentar su visibilidad) y lo obliga a tener una mirada dura, profunda y pragmática sobre lo que es importante y lo que no lo es.

Sí. Este es un problema, un gran problema. Últimamente encontré una falla de diseño en la tienda web de una empresa que me permitió insertar notas inocentes en los gráficos de otros visitantes.

Parece inocente, y solo molesto, hasta que busqué más y descubrí que también podía insertar el código Javascript (XSS) en esas notas. En otras palabras, podría explotar XSS en el gráfico de cada visitante. Hice un PoC rápido mostrándoles cómo podía hackear fácilmente la computadora de cualquier visitante (en este caso, era un PoC) usando ese defecto de diseño, XSS, BeEF y Metasploit.

Así que incluso el defecto más pequeño puede resultar en un gran riesgo, después de todo.

Además, ¿quién dice que el error que encontró es el único que cometió el desarrollador de ese sitio web? Tal vez también cometió muchos otros errores.

Los informes serían lo mejor que podría hacer, incluso si parece innecesario.

El problema que veo con un esquema de restablecimiento de contraseña tan simple es que sugiere más vulnerabilidades en la plataforma. Un concepto defectuoso de seguridad rara vez se aísla tan solo como una vez, ya que estos defectos suelen estar relacionados con las prácticas de un desarrollador con respecto a la seguridad. Como mínimo, sospecho que sus procedimientos de inicio de sesión internos también podrían ser susceptibles a la misma falla, lo que podría permitir a los atacantes acceder a bases de datos, códigos y procesos a los que normalmente no deberían tener acceso.

A partir de ahí, podría ser posible modificar el código del servidor para informar las contraseñas de texto claro, o recopilar información privada adicional, y posiblemente permitir ataques en otros sistemas. Después de todo, a pesar de que es 2016, todavía hay muchas personas que todavía usan la misma contraseña para sus cuentas bancarias que Facebook, a pesar de los riesgos obvios asociados con hacerlo. Incluso si no es así, el hecho de poder asociar un apodo con una dirección de correo electrónico también puede poner en riesgo otras cuentas que el usuario tiene; Cuanta más información sepa un atacante sobre una cuenta de usuario, más podrá aprovechar intentando subvertir otras cuentas que son propiedad de la misma persona.

Como mínimo, le sugiero que se ponga en contacto con el propietario del sitio para ver si solucionan el problema y, en caso contrario, considere no utilizar su aplicación a menos que sea absolutamente vital. También recomendaría cambiar su correo electrónico en la cuenta de usuario a una cuenta desechable que no esté conectada a una dirección de correo electrónico que le interese. Ya no estamos en una época en la que podemos suponer que fallas aparentemente menores no volverán a atormentarnos más tarde.

Si veo correctamente este escenario, pueden cambiar la dirección de correo electrónico y la contraseña de cualquier cuenta, luego iniciar un formulario de reparación y continuar el proceso de reparación por correo.

El equipo de soporte probablemente asumirá que la dirección de correo electrónico es legítima y que la información confidencial se puede intercambiar con el destinatario, y si se trata de un cliente conocido, es posible que incluso comience a trabajar en un pedido recibido a través del sitio web / correo.

¿Otro problema podría ser si puede acceder a un historial de contactos o al historial de sus pedidos de reparación? ¿Tal vez un cliente haya escrito información confidencial en sus pedidos de reparación, o incluso el número y tipo de pedido es algo que podría revelar problemas en su negocio?

Otro problema podría ser el envío masivo de correo no deseado a las direcciones de correo electrónico de los clientes. Si invoco su restablecimiento de contraseña un millón de veces, enviará un millón de correos a sus usuarios, no solo llenando su bandeja de entrada, sino que también lo enviará a varias listas de filtros de correo no deseado ... donde puede ser una molestia conseguir su servidor eliminado de estas listas después.

Por supuesto, el DoS es muy fácil, si solo tengo que enumerar los apodos y puedo restablecer todas las contraseñas de las cuentas.

Pero el mayor problema es una falsa sensación de seguridad

Podría ser que estemos pasando por alto algún ángulo o problema que existe en este momento. Pero incluso si no hay ningún problema ahora, ¿qué sucede si alguien decide implementar una nueva funcionalidad en esta página el próximo año? Tal vez para los clientes para ordenar / pagar en línea. - Proporciona un contexto al que solo se puede acceder con nombre de usuario y contraseña, y la gente y los desarrolladores confiarán en eso. Todos pensarán que "esta es una parte segura de la aplicación a la que solo pueden acceder los clientes, de modo que puedo hacer X y confiar en Y"

Si una aplicación es prácticamente accesible al público, debe parecer que lo es. Si la aplicación parece segura, ¡debería ser segura!

Hay dos perspectivas aquí:

• Como usuario, sí, me preocuparía, le avisaría al propietario y me abstendré de compartir cualquier información confidencial en ese sitio.
• Como propietario / desarrollador del sitio, es su responsabilidad evaluar si algún riesgo potencial de seguridad es lo suficientemente grave como para justificar el esfuerzo. No todos los riesgos serán lo suficientemente graves como para justificar una acción, a juzgar por la probabilidad de ocurrencia, el impacto de una infracción y el esfuerzo requerido para controlar el riesgo.

En este caso, tienes (en una conjetura):

• gravedad: baja
• probabilidad: moderada
• esfuerzo: bajo

y por lo tanto, probablemente deberían hacer algo al respecto; hay muchas posibilidades de que simplemente no se den cuenta del problema.

En el caso general , en respuesta a su pregunta "¿Son aceptables las fallas de seguridad si no se puede derivar mucho daño de ellas?" - Sí, pueden ser. Debe determinar si la compensación de severidad / probabilidad / esfuerzo hace que valga la pena solucionar un problema. "Aceptar el riesgo" es una respuesta perfectamente razonable en muchos casos.

Como ejemplo extremo, "los extranjeros que pueden romper una criptografía fuerte visitando la Tierra" es un riesgo que enfrenta mi negocio. Elijo no controlar ese riesgo ya que la probabilidad de que ocurra es tan baja que no vale la pena.

Esta es una buena pregunta y no es fácil de responder.

Cada riesgo de seguridad es solo eso, un riesgo . Y abordar ese riesgo debe sopesar el costo, la confusión y los peligros del riesgo, en comparación con la solución propuesta.

En cuanto a su pregunta específica, tiene una parte "privada" del sitio, que contiene información, pero no puede haber un daño real si alguien accede a esa parte del sitio. Su agujero de seguridad también requiere que el pirata informático tenga que saber que todas las contraseñas se restablecen en la misma cosa, y en qué consiste esa cosa.

Así que ahora mismo, hoy, su mayor riesgo es nada o al menos bajo.

Mañana su mayor riesgo es que la sección privada pueda tener información confidencial.

El costo de "arreglar" parece bastante pequeño. Especialmente si ya está enviando la nueva contraseña "fija". Esencialmente, simplemente cambie la asignación de la contraseña a una aleatoria y el problema está "solucionado" por ahora. Puede que no sea lo mejor, pero es mejor.

Por lo tanto, tiene un bajo costo de reparación, pero un bajo riesgo de seguridad. Debe comparar eso con las necesidades del negocio y determinar si vale la pena.

Tenga en cuenta que la empresa puede contar con esa contraseña fija. Por ejemplo, el personal de soporte puede haber sido entrenado para restablecer la contraseña y luego decirle al usuario por teléfono la nueva contraseña, y permanecer con ellos hasta que puedan ingresar, y luego ayudarles a cambiarla. Es necesario tener esto en cuenta al calcular los costos.

Lo que hago:

Cuando encuentro un error o un problema de seguridad, lo documento y calculo un costo de desarrollo para solucionarlo. Luego lo agrego a una lista y se lo hago saber a las personas adecuadas. Nunca se puede quitar de esa lista, pero una vez al año (o cada 6 meses) reviso esa lista con los propietarios del sitio y abordo los problemas que puedo.

Con este riesgo, es probable que no se solucione muy rápidamente. Pude ver que muchas necesidades de negocios están primero, y eso está bien. Pero al menos está documentado, y cuando alguien me dice que quiere poner información "secreta" en esa parte del sitio, puedo informarle sobre el riesgo.

También es importante tener en cuenta que este tipo de riesgo puede llevar a otros tipos de riesgos. Cuando esto fue codificado se tomó una mala decisión de seguridad. El sitio debe ser revisado para otras malas decisiones.

Recuerde que, como desarrollador, puede tener una mejor idea de los riesgos de seguridad reales que un usuario. Si un usuario descubre que su cuenta ha sido secuestrada, podría asumir que el usuario no autorizado podría haber accedido a más información de la que realmente puede. Incluso si no se expone en realidad información confidencial, su empresa aún puede tener un impacto de reputación.

También considere el hecho de que es posible que no sepa qué información es inofensiva para filtrar. Por ejemplo, ¿qué sucede si el usuario tiene un nuevo proceso de fabricación revolucionario que una empresa competidora está tratando de resolver? Si es necesario reparar un equipo especial utilizado en el nuevo proceso y cambiar su correo electrónico, la orden de reparación podría dar a la otra empresa una idea de cuál es su nuevo proceso.

Suena como una solución simple, y en última instancia, tendrá que hacer esa evaluación para ver si el riesgo vale la pena arriesgarse a solucionarlo.

Hacerse pasar por un usuario legítimo de un cliente (a quien se considera que es de confianza hasta cierto punto) es una buena manera de comenzar un ataque basado en ingeniería social.

Un formulario de reparación - > El proceso de correo electrónico es ideal para esto dado que usted controla la dirección de correo electrónico. Tal vez podría comprar un dominio similar y cambiar la dirección de correo electrónico "[email protected]" - > "[email protected]", que encaja perfectamente con "Me acabo de transferir a nuestra subsidiaria canadiense, por lo que no tengo Mis registros, ¿podrían recordarme ...? "

Si puede obtener un poco de información sobre el historial del cliente / proveedor, puede hacerse pasar por el proveedor al cliente. A menudo, esto es tan simple como preguntar "¿Cuál era el nombre del ingeniero de servicio que visitó hace unos meses? Aparentemente fueron muy útiles en un tema específico, pero yo estaba fuera y mi colega los trató"

No, si el usuario tiene acceso a ese sitio, podrá acceder al correo electrónico de alguien utilizando su apodo que es datos confidenciales , en algunos países esto es suficiente para obligarlo a < fuerte> NOTIFICAR A TODOS LOS USUARIOS que alguien pudo penetrar la base de datos y que hubo una fuga de información. Esto daña la credibilidad y está abierto a demandas.

En general, las fallas de seguridad son aceptables, pero esto podría no ser una falla de seguridad aceptable. También está abierto a todo tipo de spam que sus usuarios puedan comenzar a recibir malware y spam a través de correo electrónico .

Los piratas informáticos siempre son creativos para utilizarlos (para ellos) los defectos que encontraron. Usted asume que la identidad de los usuarios no es una información crucial, pero podría serlo si se trata de un sitio web engañoso. Además, ¿qué pasaría si un usuario estuviera promoviendo activamente en contra de una secta / culto y un miembro de cultos repentinos pueda descubrir su identidad? ¿Qué sucede si se divulga a una víctima de acoso y gracias a eso el acosador puede encontrarlo nuevamente?

La pérdida de identidad sin advertir a los usuarios es una violación de la privacidad, así que ten cuidado. Las fallas deben corregirse y analizarse en cuanto se encuentren.

En el ejemplo, preferiría que todas mis publicaciones en el foro se eliminaran en lugar de permitir que alguien acceda a mi dirección de correo electrónico.

Depende, señalaré los escenarios extremos.

Escenario A - ¡no te preocupes! Por lo que está diciendo, no hay mucha preocupación verdadera por los datos disponibles. Si bien puede haber sido público y toda la configuración de seguridad es solo un esquema de marketing / lealtad, entonces no hay mucho de qué preocuparse. También puede explicar el procedimiento descuidado, si fue realizado por alguien que no tenía la experiencia, solo por el bien de él. Siempre que esa persona haga bien su trabajo habitual, debería estar bien.

Escenario B - ¡preocupación! Si esto es solo un indicio de cómo van las cosas en algunas partes de la organización, entonces es posible que encuentres un agujero de seguridad aún peor. Si el servidor es vital para el negocio, primero considere verificar que las copias de seguridad adecuadas estén en su lugar y luego comience una auditoría exhaustiva.

Luego, por supuesto, está el resto del alfabeto.