¿Cómo puedo argumentar en contra de: "El sistema no es compatible, así que ¿por qué parchear las vulnerabilidades?"

El problema con la situación (como usted lo informa) es que se hacen muchas suposiciones con muchas opiniones. Tienes tus opiniones y quieres que compartan tus opiniones, pero tienen sus propias opiniones.

Si desea que todos estén de acuerdo con algo, necesita encontrar puntos en común. Debe desafiar y confirmar cada suposición y encontrar datos sólidos para respaldar su opinión o la de ellos. Una vez que tengas puntos en común, todos pueden avanzar juntos.

1. Tienes listas blancas: genial, ¿qué significa eso? ¿Hay maneras de evitarlo? ¿Se puede corromper una aplicación de la lista blanca?
2. ¿Qué hace el firewall? ¿Cómo se configura? Los firewalls significan puertos bloqueados, pero también significan puertos permitidos . ¿Se pueden abusar de esos puertos permitidos?
3. ¿Nadie tiene acceso? ¿Quién tiene acceso al dispositivo? ¿Confía usted en un experto o en la ignorancia de un usuario para mantenerlo seguro?
4. ¿Qué sucede si alguien obtiene acceso local al dispositivo? ¿Qué tan probable es eso?

Como profesional de seguridad de la información, su trabajo no es vencer a las personas con las "mejores prácticas", sino realizar análisis de riesgos y diseñar una forma de avanzar que limite los riesgos por debajo del umbral de riesgo de una manera rentable. Debe justificar no empleando las mejores prácticas, pero si la justificación es válida, entonces es válida.

Si alguien me dice que su máquina no es hackeable y debo creerlo, de inmediato concluyo que

• La máquina se mantiene protegida bajo las condiciones de la prisión de Fort Knox / High security, con guardias 24/7 y cámaras de seguridad,

y también uno de los siguientes:

• La máquina no tiene intercambio de información de ningún tipo (no usb, ethernet, firewire, serial, paralelo, etc. de cualquier tipo)

• La máquina está apagada permanentemente.

Porque desea una estrategia de seguridad de múltiples capas con defensa en profundidad. Tiene un firewall, pero ¿qué sucede si existe una vulnerabilidad de seguridad en su firewall? ¿Qué sucede si algún exploit de la aplicación otorga acceso al sistema operativo a nivel de usuario, y luego una vulnerabilidad de sistema operativo sin parches permite que se extienda al acceso raíz? Para una seguridad adecuada, necesita parchear todas las vulnerabilidades conocidas, no solo las que usted cree que pueden ser explotadas en su sistema, debido a una combinación de una vulnerabilidad desconocida y una vulnerabilidad conocida que cree que no puede ser explotado puede permitir un compromiso donde cualquiera de ellos no lo haría, y no puede parchear contra las vulnerabilidades desconocidas.

El motivo es simple, la seguridad se aplica en capas. Por ejemplo, para conectarse a una base de datos importante, primero debe ingresar a la red de la base de datos (pasar firewall), agregar su propia dirección IP a la lista de clientes que pueden conectarse y luego iniciar la conexión con nombre de usuario y contraseña. Cualquiera de las capas hace que las otras dos sean redundantes. El problema es "qué pasa si". Pensemos en el inicio de sesión predeterminado de scott / tiger del antiguo Oracle o de un empleado que involuntariamente reenvía un puerto a Internet público. El servidor de seguridad puede estar bloqueando solo TCP, mientras que el servidor también escucha en UDP, o IPv6 está mal configurado y la seguridad solo se aplica a IP4. Esta es la razón por la cual la seguridad viene en capas, los intentos se monitorean y los expertos en seguridad aprenden de los intentos de ataque (ojalá no), o inspeccionan la actividad en los honeypots. Además, las explotaciones de día cero (las que se aplican incluso al último parche) tienen menos probabilidades de tener éxito en un entorno de capas, ya que el atacante necesitará una vulnerabilidad para cada capa.

Ningún dispositivo no es hackeable, simplemente no ha sido hackeado antes. O bien hay poco interés en su dispositivo y / o la recompensa es muy baja. Las explotaciones de día cero todavía pueden existir.

Además, algunos dispositivos Android simplemente no pueden actualizarse más allá de una versión específica. Saber que un adversario tiene un dispositivo de este tipo es una invitación abierta para la piratería, ya que el nombre / la marca del dispositivo contiene la receta exacta de cómo piratearlo.

Mantener un dispositivo sin soporte activo también es peligroso desde la perspectiva funcional.

La seguridad no es necesaria para proteger a personas externas (firewall) sino también a personas internas. No sé el contexto en el que se está ejecutando tu dispositivo, pero dado lo que escribes, puede ser vulnerable a alguien que ya esté dentro del firewall.

No hay sistemas que no puedan ser resueltos. Para aquellos que mencionan Airgapping, hay muchos ejemplos de hacks reales o posibles hacks en sistemas con airgapped. Stuxnet es probablemente el ejemplo más famoso (y más extremo). Algunos otros incluyen phreaking van eck, análisis acústico u otros ataques de canal lateral.

Hay formas de mitigar las vulnerabilidades que no implican parches. Por ejemplo, si el sistema es vulnerable a KRACK, ¿es posible simplemente desactivar WiFi? Si WiFi está deshabilitado permanentemente, no debería ser necesario aplicar ninguna actualización relacionada con WiFi. Del mismo modo, si hay aplicaciones específicas en el sistema que presentan una vulnerabilidad (como Java, .NET, Flash, navegadores, etc.), simplemente podría desinstalar esas aplicaciones. No hay necesidad de actualizar Java si ni siquiera está instalado.

Con las actualizaciones del sistema operativo, esto es más difícil. Debe ser consciente de las vulnerabilidades potenciales y, a continuación, debe mitigarlas. El beneficio de usar un sistema operativo compatible es que otra persona (presumiblemente) ya está haciendo la primera parte y la mitad de la segunda parte por usted.

Un sistema completamente actualizado / actualizado no es un sistema seguro o que no se pueda rastrear. Pero tiende a minimizar el riesgo de vulnerabilidades CONOCIDAS. Para hacernos eco de Schroeder, el análisis de riesgos es más importante que 'endurecer / bloquear' o 'actualizar' a ciegas y con la esperanza de que eso lo haga más seguro.

Ningún sistema es realmente "imposible de rastrear". Sin embargo, una vez que decidimos que un sistema es "no apto para su instalación" lo suficiente, no tenemos que mantener un canal para los parches de seguridad.

Para un ejemplo concreto, nuestro sistema "no apto para el alojamiento" controla una cámara de seguridad. El trabajo de la cámara es mirar una ubicación fija. Cada ajuste es constante o el sistema es lo suficientemente inteligente como para ajustarse por sí mismo. El sistema transmite datos de video y no necesita ninguna entrada del usuario.

Podríamos hacer que el sistema ejecute ssh para que podamos iniciar sesión periódicamente y aplicar parches de seguridad, pero eso realmente abre un agujero de seguridad (muy pequeño). Un atacante podría usar ssh para hackear la cámara. (Buena suerte hackeando ssh).

Así que es una compensación. Si crees honestamente que nunca necesitarás aplicar un parche de seguridad, entonces puedes decidir que dejar ese canal abierto no vale la pena.

Obtuve esta idea de una presentación a la que asistí, donde alguien describió los sistemas que estaban construyendo para el gobierno. Los componentes del sistema eran máquinas virtuales de corta duración (generalmente menos de un día). Cada máquina virtual era inmutable y desechable. El plan era que si necesitaban aplicar un parche de seguridad, simplemente desecharían las máquinas de manera ordenada y crearían otras nuevas. Las máquinas virtuales no tenían ssh.

El auditor de seguridad del gobierno hizo explotar una junta y los hizo instalar ssh para que pudieran aplicar los parches de seguridad. El servidor ssh no proporcionó ningún valor de seguridad y, de hecho, era un agujero.

Sin embargo, pensando en ello, este ejemplo (y mi cámara) son solo actualizaciones de seguridad a través de un canal no tradicional.

¿Qué pasa con

1. una cámara desplegada en Marte ... todos conocen la cámara y todos pueden ver los datos de la cámara
2. una cámara que existe en secreto detrás de las líneas enemigas (si el enemigo conociera la cámara, podría tomarla fácilmente ... queremos mantener un canal para las actualizaciones de seguridad).

El hecho de que no puedan pensar (en este momento) en una forma de piratearlo, no significa que sea "insostenible". Es por eso que, como principio, aplicamos todos los parches de seguridad, incluso si se trata de un componente que no debería ser accesible (por ejemplo, ¿por qué parchear una vulnerabilidad de escalada de privilegios si un atacante ni siquiera tuviera acceso de usuario?). p>

Ahora, pueden estar en lo cierto, y no parchearlo podría ser la decisión correcta en su caso. Pero hay pocas personas por las cuales aceptaría eso abiertamente. Y es probable que esos ingenieros no tengan un conocimiento especial en realizar auditorías de seguridad.

Como un argumento para convencerlos, les pediría que proporcionen acceso a uno de estos dispositivos a cualquier persona interesada con una recompensa jugosa (por ejemplo, ¿apuestan a su casa?).

Si se sienten incómodos al hacer eso, bueno, entonces en realidad no creen que sea descifrable. Y si piensan que hacerlo revelaría información importante, eso significa que dependen de la seguridad por la oscuridad. Un verdadero sistema que no se pueda descifrar sería aún hackeable si el atacante supiera todo sobre su funcionamiento.

PD: Incluso si no terminan apostando en sus casas, realmente se beneficiaría con la implementación de un programa de recompensas por errores.

  

los ingenieros que diseñaron el producto original sienten que la máquina   no es hackeable

Los ingenieros que diseñaron el Titanic sintieron que era insumergible.

El problema en TI es que las personas no ven la necesidad de actualizar un sistema, ¿por qué cambiar un sistema que funciona? Estas compañías luego aparecen en los titulares: "4 fábricas se cerraron debido al brote de x" o "La compañía x ha sido violada, los datos personales de y millones de clientes expuestos".

Imagínese, la nube de IBM recientemente movió a todos los clientes con fuerza a TLS 1.1 (SÍ, la versión ya obsoleta) y algunos clientes se quejaron ... ESOS CLIENTES DEBEN PREPARARSE PARA TLS 1.3, no sé lo que están haciendo, y yo No importa cuáles sean sus excusas, ¡deberían estar ejecutando TLS 1.2 EN TODAS PARTES! IBM vendió de nuevo, ¡INACEPTABLE!

Ahora puede decirme que el unicornio negro en el establo le impide mover todo a TLS 1.2, lo que sea, deshágase de él y no haga negocios con la compañía que vende el unicornio negro ... Nosotros, como industria, lo hacemos no hagas esto y las brechas son titulares, las brechas continuarán haciéndolo hasta que aprendamos la lección.

  

siente que la máquina no es hackeable

Los sentimientos no importan. Los hechos hacen.

Vuelva a su evaluación de riesgos y / o modelo de amenaza. Observe si el parche o la actualización del software formaban parte de su plan de tratamiento de riesgos. Observe si el software obsoleto era parte de su análisis de riesgo o modelo de amenaza.

Vuelva a los ingenieros con estos datos y discuta con ellos cómo cambia el riesgo o qué amenazas ahora no se tratan, ya que el software ya no está desactualizado. También tenga en cuenta que este riesgo particular aumentará con el tiempo a medida que crezca la posibilidad de que se descubra un defecto explotable. Así que mire hacia el futuro hasta el final razonable de la vida útil de su producto.

Tenga en cuenta que sus acciones de mitigación pueden hacer que el riesgo sea aceptable. Pero esto necesita ser discutido y el plan de riesgo actualizado. También podría ser que haga el riesgo aceptable hoy, pero en algunos años ya no. ¿Entonces que? En lugar de buscar argumentos en contra de los ingenieros, póngase en la misma página con ellos. Al menos, se da cuenta de que podrían ser necesarias acciones de mitigación.

"El sistema no se puede procesar, ¿por qué parchar las vulnerabilidades?" ¿Crees que como no puedes hackearlo, nadie más puede hacerlo? "). Sin embargo, al final, creo que se tratará de una discusión sobre la aceptabilidad del riesgo y quién está dispuesto a aceptar ese riesgo. Intenta explicárselo a ellos de esta manera

"Tenemos una lista blanca de aplicaciones, ¿por qué necesitamos parchear las vulnerabilidades?"

La lista blanca de aplicaciones es tan buena como la lista blanca en sí misma, las herramientas para bloquear aplicaciones que no están en esa lista blanca, y asume que no existen fallas o vulnerabilidades en la propia herramienta de lista blanca de aplicaciones. También protege solo contra aplicaciones desconocidas / no confiables. ¿Qué sucede si el atacante decide "vivir fuera de la tierra" y usar las herramientas propias del sistema contra sí mismo? ¿Qué sucede si una de las aplicaciones que ha incluido en la lista blanca como parte del sistema operativo tiene una vulnerabilidad

"Tenemos un firewall, ¿por qué necesitamos parchear las vulnerabilidades?" Este es, efectivamente, el mismo argumento que el anterior. ¿Está seguro, absolutamente, positivamente, al 100%, sin duda alguna de que no hay vulnerabilidades en la pila de la red y / o en el propio firewall, ni en ninguna de las aplicaciones o servicios que pueden estar escuchando o accesibles a través de esa pila de red?

Si sus respuestas a lo anterior son que son 100% positivas sobre sus elecciones y decisiones, entonces redactaría un documento que detalla su aceptación de ese riesgo y lo firmará su equipo de liderazgo hasta el final. El CIO. En última instancia, es su (el nivel de CxO) el que está enganchado con el problema cuando el sistema se rompe y es el que podría ser convocado ante el Congreso (o cualquier organismo de supervisión gubernamental al que esté sujeto) a los ejecutivos En Equifax fueron. Cuando se les explica a los ejecutivos que no están haciendo todo lo posible para mantener un sistema actualizado y parcheado (como lo requieren muchos grupos / leyes diferentes de acreditación y supervisión) y que ellos (el CxO) podrían ser considerados responsables, las actitudes muchas veces cambiará.

Me parece simple. Volviendo a la pregunta de cómo expresar un punto en una discusión en contra de no parchar un sistema que se cree que no es compatible. ¿Cuál es el peor de los casos que puede ocurrir si ese sistema es violado? Supongamos que todas las protecciones en su lugar fallan o son igualmente violadas. No sesgue este ejercicio al revelar las consecuencias porque no cree que se pueda violar o no lo será.

Ahora, ponga ese caso peor en términos de costo de impacto comercial en forma de pérdida de ingresos, multas legales / regulatorias o daños a la imagen de la empresa en la industria.

Si ese impacto es severo, mire a sus ingenieros a los ojos y diga "¿está dispuesto a poner su trabajo, y posiblemente toda su carrera, a la línea de que esto nunca sucederá? Porque si lo hace, en las consecuencias de explicar cómo sucedió, la decisión consciente de continuar utilizando el sistema operativo EOL y considerar que no es necesario aplicar parches estarán cerca, si no en la parte superior, de la lista ".

Por otro lado, si el impacto en el negocio no es tan impactante, podría tener sentido continuar usando un sistema operativo EOL. Pero la mejor manera de hacerlo de una manera bien gestionada por el riesgo es otro tema completo.

Si su dispositivo tiene una conexión wi-fi, entonces puede ser atacado a través de la red. ¿Tendrá éxito ese ataque? Es una cuestión de los beneficios de atacar el dispositivo, versus el nivel de esfuerzo requerido. Basarse en un sistema operativo obsoleto y no compatible definitivamente simplifica el método de ataque.

La inclusión en la lista blanca de aplicaciones no es una protección, solo un obstáculo menor. ¿Crees que un hacker no puede desarrollar una aplicación que se hace pasar por una lista blanca de la aplicación? Por supuesto que pueden ... algo que podrían analizar si su primer intento no se ejecuta.

Equifax tenía un firewall bastante instalado. No impidió que los hackers explotaran el agujero de Struts que los administradores de TI de Equifax no pudieron parchar, a través de un puerto que se dejó abierto por necesidad. Un firewall simplemente detiene algunos de los ataques más antiguos y obvios.

Vuelva a pensar en el pirateo de Target: el CEO y el CIO perdieron sus trabajos por ese, y fue perpetrado por un experto, ayudado por el uso de Target de una versión más antigua de Windows, que ya no se actualiza, más conectividad no segura. Métodos en sus dispositivos de punto de venta. Sin duda, el CIO llegó a la conclusión de que actualizar la versión Win en sus dispositivos POS era demasiado costoso, un juicio que resultó ser muy incorrecto.

¿Crees que el firmware incorporado es inmune al pirateo? Considere el hack de la impresora HP. HP tuvo la inteligente idea de actualizar el firmware de su impresora a través de un trabajo de impresión, fácil de iniciar. Hasta que ... a alguien se le ocurrió una versión de firmware que convirtió la impresora en un repetidor de correo no deseado y la entregó a través de un trabajo de impresión de malware.

¿Cómo se hacen las actualizaciones de firmware? ¿A través de wi-fi? Sí, un hacker puede replicar eso ... si tienen una razón suficientemente buena.

Un dispositivo en red puede ser pirateado para convertirse en parte de una red de bots ... una forma común de lanzar un ataque de DOS. Un pirata informático podría encontrar la vulnerabilidad y, sabiendo que dañaría la reputación de la empresa, lanzará el ataque al mismo tiempo que está acortando las acciones de su empresa. Eso ha sucedido ... Robar información de PII y CC no es la única manera de sacar provecho de un hack.

Ahora, pregúntate, ¿cuál es el riesgo para ti personalmente? Si su sistema fuera pirateado, ¿puede demostrar a los ejecutivos de su empresa que ejerció la diligencia debida para identificar y mitigar amenazas potenciales, especialmente porque está basando el sistema en un sistema operativo que ya no se está actualizando? Sugerencia: tomar la palabra de los ingenieros que dicen que el sistema es "no apto para el tratamiento" probablemente no califica como diligencia debida.

En este sentido, si sus ingenieros dicen que no es compatible, probablemente ni siquiera estén buscando posibles vulnerabilidades, y mucho menos mitigándolas.

Cualquiera que diga que un sistema no es compatible no está siendo realista. No en este día y edad.

Esto puede no ser una decisión técnica en absoluto. El uso de cualquier componente de origen externo generalmente significa que tiene que usar ese componente estrictamente de acuerdo con las directrices del fabricante, o correr el riesgo de quedarse con all las consecuencias y responsabilidades derivadas de cualquier falla en la que pueda estar implicado.

Entonces, si el dispositivo se comporta mal y alguien se lesiona (o se incurre en alguna otra responsabilidad), el fabricante original del sistema operativo dirá "software no compatible, no es nuestro problema". Y la aseguradora de su empresa dirá "el uso de software anticuado fuera de soporte: eso es negligente y, por lo tanto, no es nuestro problema".

Por lo tanto, desde su perspectiva personal, asegúrese de que aquellos que toman la decisión afirmativa de continuar utilizando componentes obsoletos y no compatibles:

• se ha demostrado que lo están haciendo (y usted lo tiene por escrito)
• afirmaron afirmativamente que la actualización es innecesaria (y lo hicieron por escrito)

Hay una gran brecha entre las personas que dicen "no necesitamos hacer esta actualización" y "Yo personalmente acepto la responsabilidad de no hacer esta actualización".

En la práctica, a menudo hay actualizaciones de los componentes que son obligatorias por el hecho de que se hayan convertido en EOL, incluso si no hay necesidades técnicas reales para hacerlo. Esa es una parte necesaria de la ingeniería de un producto complejo.

Dependiendo de los recursos disponibles para usted, la forma "a prueba de tontos" (con el debido respeto de sus colegas) sería demostrarles que el sistema es hackeable. Contrate a alguien que pueda y permítale demostrar las debilidades del sistema. Mi conjetura es que con WLAN no debería ser terriblemente difícil. WLAN y firewall? Eso es un contradictio in adjecto .

Pensamiento posterior: Tal vez sea posible acordar el pago para que sea exitoso (mi diccionario lo llama "tarifa de contingencia"); de esa manera el servicio (de hacking) siempre valdría la pena.

Todos los días tenemos titulares que dicen que algún sistema ha sido pirateado. No es porque no estén al día ni protegidos con ametralladoras, sino porque alguien está invirtiendo tiempo para piratearlas.

Lo más importante es que aquellos que están bien jugados no están hechos por IQ power sino por ingeniería social simple. Así que se nos dice que mantengamos el sistema actualizado porque si de alguna manera caemos en ese hoyo de hoyos, les damos la información que no les ayuda.