Seis ideas tontas en seguridad informática (2005)

• La seguridad informática es un campo donde siguen aumentando los productos, conferencias, libros y proyectos de ley, pero en la raíz de los fracasos repetidos hay supuestos básicos erróneos como Default Permit y Enumerating Badness
• El problema central es una estructura que no define de forma estrecha “qué permitir”, sino que persigue sin fin “qué bloquear”; si no se elige Default Deny en firewalls, ejecución de código y respuesta a gusanos, se cae en una carrera armamentista con los atacantes
• Enumerar lo malo implica rastrear más de 75.000 virus y entre 200 y 700 nuevas amenazas cada mes, por lo que es menos eficiente que Enumerating Goodness, que gestiona alrededor de las 30 aplicaciones legítimas realmente necesarias
• Buscar vulnerabilidades y parchearlas, una cultura que consume el hacking como algo atractivo y las estrategias que dependen de educar a los usuarios llevan a repetir una respuesta posterior al incidente más que a reducir fallas de diseño
• Con las nuevas tecnologías puede ser más seguro esperar y validarlas antes de adoptarlas de inmediato; los profesionales de seguridad deberían priorizar el diseño con sentido común y una actitud escéptica por encima de las modas

---

Las “anti-buenas ideas” que generan fracasos de seguridad

• En seguridad informática siguen apareciendo nuevos productos, nuevas conferencias, nuevos libros y nuevos proyectos de ley, pero los problemas se repiten
• Una “idea tonta” es un enfoque que está del lado opuesto de una buena idea, y surge cuando se intenta hacer algo imposible o se ignora la realidad
• Estos enfoques a veces nacen de malentendidos bienintencionados, y otras veces de productos bien empaquetados para ganar dinero rápido
• Las seis ideas están ordenadas según la frecuencia con que aparecen; si puedes evitar especialmente las tres primeras, se considera que perteneces al pequeño grupo de profesionales de seguridad sobresalientes

1. Default Permit: permitir por defecto

• Default Permit es el enfoque que permite todo lo que no esté explícitamente prohibido, y se reconoce con más facilidad en las reglas de firewall
  • Los primeros administradores de red bloqueaban solo telnet, rlogin y FTP entrantes, y permitían el resto
  • Cada vez que se descubría una nueva vulnerabilidad, el administrador tenía que decidir si bloquearla, y debía alcanzarla antes de que lo hackearan
  • Debería haber desaparecido con la llegada de los gusanos en la década de 1990, pero muchas redes todavía tienen una estructura de núcleo abierto sin segmentación
• El mismo problema se repite en la ejecución de código
  • Si el usuario hace clic, básicamente se ejecuta cualquier cosa, y la ejecución solo se niega cuando un antivirus o bloqueador de spyware la detiene
  • Aunque las aplicaciones usadas con frecuencia son unas 15 y las usadas ocasionalmente unas 20 a 30, el sistema operativo permite por defecto la ejecución de virus o spyware
• Un proyecto de seguridad para e-banking usó el enfoque opuesto
  • En lugar de que el balanceador de carga enviara a un agujero negro solo los ataques conocidos, enviaba todo el tráfico que no coincidiera con una lista de URL correctas a un servidor bloqueado que servía imágenes y páginas 404
  • No era Default Permit, que bloquea solo ataques conocidos, sino un enfoque que rechaza solicitudes fuera de la estructura normal
• Si estás en una carrera armamentista con los atacantes, es una señal de que caíste en Default Permit
• El concepto opuesto, Default Deny, requiere compromiso, reflexión y comprensión para implementarse, pero es un mejor enfoque

2. Enumerating Badness: enumerar lo malo

• Enumerating Badness es el método de listar todo lo malo conocido y luego detectarlo o bloquearlo
• Al principio parecía posible porque había pocos agujeros de seguridad conocidos, pero hacia 1992 las “cosas malas” de Internet ya eran muchas más que las “cosas buenas”
  • Un producto antivirus típico conoce más de 75.000 virus
  • Se estima que en una computadora personal hay unas 30 aplicaciones legítimas instaladas
  • Si se rastrean esas 30 aplicaciones legítimas y se impide ejecutar todo lo demás, se pueden reducir a la vez los problemas de spyware, virus, troyanos de control remoto y exploits ejecutables contra código preinstalado que rara vez se usa
• Según algunos análisis de la industria, cada mes aparecen en Internet entre 200 y 700 nuevas “cosas malas”
• Ante la objeción de que una red corporativa es demasiado compleja para identificar las aplicaciones legítimas, se responde que si el CTO ni siquiera sabe a grandes rasgos qué hace la tecnología, no puede hacer planificación de capacidad, de desastres ni de seguridad
• El análisis de logs de un producto de firewall de 1994 inicialmente buscaba condiciones malas, pero la segunda versión usó Artificial Ignorance
  • Descarta los logs que sabe que no son interesantes
  • Considera interesantes los logs restantes
  • Este enfoque detectó condiciones operativas y errores que no se habrían imaginado
• Antivirus, detección de intrusiones, prevención de intrusiones, seguridad de aplicaciones y firewalls de inspección profunda de paquetes suelen apoyarse en este método
• Si un sistema requiere actualizaciones de firmas periódicas o deja pasar un gusano nunca antes visto, es señal de Enumerating Badness
• La cura es Enumerating Goodness, pero se considera que los sistemas operativos casi no ofrecen soporte para este tipo de control a nivel de software

3. Penetrate and Patch: penetrar y parchear

• Penetrate and Patch es un ciclo que consiste en atacar desde afuera firewalls, software, sitios web, etc., encontrar fallas, corregirlas y volver a buscar
• Este método no produce sistemas mejor diseñados, sino sistemas endurecidos por ensayo y error
• Personal Observations on the Reliability of the Space Shuttle, de Richard Feynman, es una lectura que muestra cómo debería alcanzarse la confiabilidad en sistemas complejos
  • El mensaje central se acerca a “si no diseñaste el sistema para que sea hackeable, no debería ser hackeable”
• La moda de publicar vulnerabilidades y actualizaciones de parches también se basa en este enfoque
  • El investigador de vulnerabilidades cree que ayuda a la comunidad porque encuentra agujeros antes que los hackers y permite corregirlos
  • El proveedor cree que hace lo correcto porque lanza parches antes de que los hackers y autores de gusanos los aprovechen
  • Pero si el código hubiera sido diseñado desde el principio para ser seguro y confiable, descubrir vulnerabilidades sería una tarea aburrida y poco recompensada
• Si en Internet Explorer aparecieron 2 o 3 bugs de seguridad por mes durante 10 años, es difícil decir que Penetrate and Patch haya sido efectivo
• Se considera que algunas aplicaciones como PostFix y Qmail fueron diseñadas para modularizar y compartimentar permisos y procesamiento, y por eso tienen un historial muy reducido de bugs de seguridad
• Las pruebas de penetración tienen el mismo límite
  • Las redes con diseños de base o prácticas de seguridad incorrectas siguen siendo hackeadas aunque reciban varias pruebas de penetración
  • En redes diseñadas desde el principio para permitir solo ciertas direcciones, cierto tráfico y servidores configurados con cuidado, una prueba de penetración general puede no tener sentido
• Si cada “bug de la semana” te vuelve vulnerable, estás atrapado en Penetrate and Patch
• El software y los sistemas deben ser secure by design, y diseñarse teniendo en mente el manejo de fallas

4. Hacking is Cool: la idea de que hackear es genial

• Hacking is Cool es una crítica a la cultura que recompensa o glorifica a los hackers con stock options, libros, cursos y pruebas de penetración muy bien pagadas
• Donn Parker considera que la computación remota eliminó la necesidad de proximidad física en el delito, y que el anonimato y la ausencia de contacto cara a cara con la víctima redujeron la barrera emocional del crimen
• El hacking se parece más a un problema social que a un problema técnico
  • Internet ofrece un nuevo espacio de actividad para personas con poca sociabilidad
  • Cuando los profesionales de seguridad convierten a los hackers en héroes, terminan alentando el hacking de manera implícita
  • Los medios a veces retratan a los hackers como “whiz kids” o “brilliant technologists”
• Que los profesionales de seguridad aprendan técnicas de hacking también se considera parte de esta idea
  • Los exploits y su uso se vuelven obsoletos apenas se parchea el agujero correspondiente
  • La competencia profesional termina dependiendo de la carrera armamentista de Penetrate and Patch
  • Es más razonable aprender a diseñar sistemas de seguridad resistentes al hacking que aprender a encontrar sistemas hackeables
• Se predice que “Hacking is Cool” desaparecerá en 10 años, pero no se ven señales de que lo reemplace su opuesto, “Good Engineering is Cool”

5. Educating Users: educar a los usuarios

• Educating Users se parece a Penetrate and Patch aplicado a las personas
• La educación en sí parece buena, pero si hubiera funcionado ya debería haber mostrado resultados
  • Se dice que varios estudios encontraron que una proporción considerable de usuarios entrega su contraseña a cambio de un dulce
  • El gusano Anna Kournikova se usa como ejemplo de que casi la mitad de la humanidad hace clic en cualquier cosa que parezca contener fotos desnudas de una mujer medianamente famosa
  • Si se adopta la educación de usuarios como estrategia, puede que haya que “parchear” a los usuarios cada semana
• La verdadera pregunta no es “¿podemos educar a los usuarios para que sean más seguros?”, sino “¿por qué tenemos que educar a los usuarios desde el principio?”
  • ¿Por qué los usuarios reciben adjuntos ejecutables?
  • ¿Por qué los usuarios esperan recibir correos de un banco donde ni siquiera tienen cuenta?
• La respuesta a adjuntos y phishing también es un problema de Default Permit
  • Si permites que todos los usuarios reciban adjuntos de correo, estás permitiendo por defecto todo lo que se envía
  • Un mejor enfoque sería aislar todos los adjuntos, eliminar los ejecutables y conservar solo los tipos de archivo permitidos en un servidor de staging
  • Los usuarios podrían iniciar sesión con un navegador compatible con SSL para recoger los archivos, y el requisito de contraseña debilitaría de inmediato muchos mecanismos de propagación de gusanos
• Herramientas gratuitas como MIMEDefang pueden usarse para separar los adjuntos de los correos entrantes, guardarlos en directorios por usuario y reemplazar los adjuntos dentro del correo por la URL correspondiente
• Cuando dirigía una pequeña startup de seguridad, los empleados que querían usar Windows tenían que saber instalarlo y administrarlo por sí mismos; de lo contrario, no eran contratados
• Se predice que, en 10 años, los usuarios que necesiten educación saldrán del mercado laboral de alta tecnología o se entrenarán por su cuenta en casa para mantenerse competitivos

6. Action is Better Than Inaction: la creencia de que actuar es mejor que no actuar

• Los ejecutivos de IT se dividen en “early adopters” y “pause and thinkers”, y se considera que quienes han creado sistemas exitosos y seguros de misión crítica se parecen más al segundo grupo
• Cuando aparece una nueva tecnología, puede ser más seguro esperar en lugar de instalarla de inmediato, observar los resultados de otros adoptantes tempranos y desplegarla después de que ya haya personas con experiencia
  • Un alto ejecutivo de IT planteó su plan de adopción de una red inalámbrica corporativa como “esperar 2 años y luego contratar a alguien que haya desplegado con éxito una red inalámbrica en una empresa más grande que la nuestra”
  • Mientras tanto, la tecnología se ordena mejor y los precios bajan mucho
• La proposición secundaria clave es: “a menudo es más fácil no hacer cosas tontas que hacer cosas inteligentes”
• También se aconseja postergar el outsourcing de seguridad 1 o 2 años y escuchar las recomendaciones y opiniones de las organizaciones que sobrevivan
• En un caso de un cliente que estaba por gastar mucho dinero sin validación, se sugirió enviar personal a la conferencia relacionada LISA para encontrar usuarios con experiencia real
  • Ese empleado pudo invitar a cenar a personas con experiencia en el producto y escuchar evaluaciones informales
  • El gerente de IT informó que una cena de 200 dólares redujo más de 400.000 dólares de sufrimiento técnico
• El “kung fu” profesional consiste en evitar hacer tonterías no haciendo nada, y lograr que el jefe reconozca el mérito de esa evitación

Otras pequeñas tonterías

• “No somos un objetivo”
  • Los gusanos no son lo bastante inteligentes como para decidir si un sitio web o una red doméstica son interesantes
• “Si todos usan cierto sistema operativo de seguridad de moda, estaremos seguros”
  • Los sistemas operativos tienen problemas de seguridad porque son complejos, y la administración de sistemas todavía no es un problema resuelto
  • Cambiar siguiendo la moda puede dificultar que los administradores adquieran la experiencia que se acumula con el tiempo
• “Tenemos buena seguridad en los hosts, así que no necesitamos firewall”
  • Si no puedes confiar en el tejido de red, toda aplicación que pase por la red es un objetivo potencial
  • Se da como ejemplo el Domain Naming System
• “Tenemos un buen firewall, así que no necesitamos seguridad en los hosts”
  • Si el firewall deja pasar tráfico hacia hosts detrás de él, también hay que considerar la seguridad de host de esos sistemas
• “Subámoslo a producción ahora y hagamos la seguridad después”
  • Si no hay tiempo para hacerlo bien ahora, hay que preguntarse si habrá tiempo para volver a hacerlo después de que se rompa
  • No dedicar los primeros días puede llevar a pasar años corrigiendo continuamente
• “Los problemas ocasionales no se pueden evitar”
  • Esto lleva a preguntar si uno se subiría a un avión comercial si la industria aérea adoptara ese enfoque con vidas humanas en juego

La actitud que se exige a los profesionales de seguridad

• Se considera que la seguridad informática está demasiado obsesionada con “la nueva tecnología de la semana” y ha abandonado el sentido común
• El trabajo del profesional de seguridad es cuestionar la sabiduría convencional y el estado actual, y enfrentarlos de lleno si hace falta
• Cierra con la preocupación de que, si la sabiduría convencional fuera efectiva, la tasa de compromisos de sistemas debería estar bajando

[GN⁺]

Opiniones de Hacker News

• Otra vez con esto, parece: https://hn.algolia.com/?q=six+dumbest+ideas+in+computer+secu...
  Este texto tiene muchos puntos para desmenuzar, pero lo que siempre quiero señalar es la postura de fondo de Ranum contra la investigación de vulnerabilidades. A fines de los 90 y principios de los 2000, Marcus Ranum y Bruce Schneier eran intelectuales representativos de la idea de que divulgar vulnerabilidades hacía más daño que bien, y que ese trabajo debían hacerlo los vendors, no investigadores externos. Esa postura terminó siendo equivocada: en 2002 tal vez se podía meter la investigación externa con divulgación completa de vulnerabilidades bajo la etiqueta de “hacking”, pero hoy ya no es así en absoluto. Las cuatro grandes conferencias de seguridad tratan investigación ofensiva, y lo mismo ocurre incluso en la literatura de criptografía

  • En aquel momento quizá tenían razón. Para racionalizar decisiones pasadas a posteriori, hay que mirarlas según la evidencia disponible entonces. Después, la escala de las redes y la cantidad de participantes explotaron
  • Me da curiosidad saber a cuáles se refiere con las “cuatro grandes conferencias” de seguridad
  • Es cierto que la investigación ofensiva se volvió un tema central en las principales conferencias. Como resultado, seguimos viendo la externalidad negativa de la explotación real después de la publicación, y muchas veces los vendors no tienen la capacidad o la voluntad de responder adecuadamente a lo que publica la academia. La academia también tiene margen para mejorar, y es más probable que las conferencias principales establezcan expectativas más concretas para reducir el daño de la divulgación, en lugar de que la dirección se revierta. Por ejemplo, ampliar el alcance de “vendor” para incluir a actores de mitigación como vendors de sistemas operativos o firewalls

• No sé si se le pasó, pero me sorprendió que no hablara de contraseñas. Considero inherentemente tontas las reglas obligatorias de composición salvo la longitud mínima, los cambios periódicos y los intentos de “reemplazar las contraseñas”. Las reglas de composición llevan a escribirlas en papel, reutilizar la misma contraseña o agregar un 1 al final; y los sustitutos tienen una UX horrible o confusa y al final se vuelve a las contraseñas. Si simplemente me dejan crear una contraseña de X o más caracteres con los caracteres que yo elija, puedo recordarla de verdad aunque no tenga el celular o la computadora, o esté en el extranjero

  • El cambio periódico de contraseñas quizá fue una buena idea en su momento. Hace décadas, las prácticas de seguridad eran muy malas, como enviar contraseñas en texto plano, y tomó mucho tiempo corregirlas. Además, hay gente que comparte contraseñas como si fueran caramelos; no me refiero a compartir una cuenta de streaming, sino a compartir con colegas el acceso a recursos importantes dentro de una organización. Por eso no estoy de acuerdo con descartar la capacitación de usuarios finales. Algunas cosas se pueden resolver técnicamente, pero problemas sociales como compartir contraseñas no se resuelven bien solo con tecnología
  • Los lugares que recomiendan cambios obligatorios de contraseña cada mes o cada dos meses ni siquiera siguen las prácticas de seguridad más recientes de los reguladores. Tanto el NIST de EE. UU. (https://pages.nist.gov/800-63-FAQ/) como el NCSC del Reino Unido (https://www.ncsc.gov.uk/collection/passwords/updating-your-a...) publican guías bastante buenas que no incluyen ese requisito
  • Llevo años diciendo este mensaje. Los generadores de contraseñas crean claves que, en la práctica, son imposibles de recordar; eso dio lugar a los gestores de contraseñas, y todo eso queda protegido por una sola contraseña. Ahora el punto único de falla es una contraseña, y si un atacante la consigue, puede acceder a todas las contraseñas. De todos modos, la regla de bloquear después de n intentos corta en la mayoría de los casos la vía de ataque por fuerza bruta, así que es mucho más efectiva. No soy especialista en seguridad, así que puede haber casos en los que una contraseña larga y compleja marque la diferencia, pero con autenticación multifactor la mayor parte de esta discusión se vuelve irrelevante
  • Iba a mencionar también las contraseñas, pero ahora creo que las passkeys parecen una candidata aún más tonta. Creo que van a generar una confusión interminable para el usuario promedio
  • Las políticas de contraseñas parecen un chiste. Si usas 5 sitios web, tienes 5 políticas. En lugares como bancos bloquean caracteres especiales como si fueran un “intento de hackeo”, así que ni el generador de contraseñas de Firefox funciona, y el usuario termina esquivándolo e ingresando algo como suckmyDICK123!!. Aun así, normalmente no las roban porque no hay suficiente capacidad de fuerza bruta o porque la cuenta se bloquea tras 5 fallos. Hoy la mayoría ya sabe algo del estilo “los bots prueban contraseñas a velocidad sobrehumana”, y ninguna política de contraseñas evita que se elijan contraseñas malas. Es un caso en el que personas “responsables” desperdician una cantidad enorme de tiempo intentando resolver la realidad. Salvo uno o dos sitios sensibles como bancos, dan ganas de usar la misma contraseña en servicios que exigen cuentas a la fuerza, como 80 juegos que probaste un minuto. Muchas veces tienen una GUI separada que ni siquiera permite pegar, y podría usar un gestor de contraseñas, pero no hay motivo para molestarme

• Hackear puede ser genial. No me refiero a acceder a datos y sistemas ajenos, sino a entender profundamente un sistema que poseo y encontrar formas de hacerlo funcionar mal a mi favor. Forzar la cerradura del vecino no tiene mucha gracia, pero forzar mi propia cerradura sí es genial; manipular una computadora remota para obtener acceso indebido no está bien, pero hacer que mi propia computadora haga algo que originalmente no me dejaba hacer sí es genial. La actitud de explorar los bordes de lo posible mueve el mundo hacia adelante, y casi no debe haber sociedades humanas exitosas que hayan celebrado quedarse dentro del molde

  • Se puede decir que el delito no es genial, pero sin duda hay atractivo en conocer cosas subversivas como abrir cerraduras, arrancar un auto haciendo puente, fabricar armas o ejecutar John the Ripper. Tiene el efecto de convertirte en una especie de mago que no está atado a las reglas en las que todos creen
  • Si una computadora remota estaba siendo usada por una organización de vishing para guardar información personal de numerosas víctimas ancianas, el acceso no autorizado también puede ser genial. Si con ese acceso se interrumpe el negocio de la estafa, puede ser muy genial e incluso gracioso. Técnicamente sería ilegal y una forma de justicia por mano propia, pero aquí no hablamos de legalidad sino de “ser genial”. Los justicieros suelen verse geniales cuando actúan desde un sentido personal de justicia

• Este texto contiene muchos juicios muy malos. Una frase del tipo “diseñé, implementé y configuré cuidadosamente mi sistema, así que no necesito probarlo” puede ser una de las peores perspectivas de seguridad que he oído. Decir que “el hacking es un problema social, no técnico” también se parece mucho a depender de la seguridad por oscuridad, y tampoco es siempre un problema social. Basta ver el espionaje corporativo o a los actores estatales para notar que no es así

• El problema central suele ser el desafortunado compromiso entre usabilidad vs. seguridad, y la mayoría de las cosas mencionadas aquí como ideas tontas son el resultado de sacrificar seguridad para reducir la incomodidad del usuario promedio. Por ejemplo, permitir por defecto es lo peor para la seguridad y es causa de muchos problemas de Windows, pero a los usuarios no les gusta tener que autorizar explícitamente cada programa nuevo. Incluso cuando Microsoft agregó cuadros de confirmación, mucha gente lo consideró un mal diseño que hacía que el software fuera mucho más molesto. Por eso “permitir por defecto”, “enumerar lo malo” y “parchar después de la intrusión” terminaron siendo los valores predeterminados. Personalmente, creo que las contraseñas en sí son una de las ideas más tontas en seguridad. La definición de una buena contraseña implica que sea difícil de recordar, difícil de ingresar en dispositivos sin un teclado adecuado y, en casi todos los sentidos, incómoda para el usuario. Pero tampoco hay alternativas realistas. Los enlaces por correo electrónico hacen que, si te comprometen el acceso al correo, te comprometan todo, y el restablecimiento de contraseñas suele ser igual. Los dispositivos físicos de autenticación hacen que el usuario no pueda iniciar sesión fuera de casa o tenga que llevar siempre un accesorio encima, y casi todos los métodos exigen buenos hábitos de seguridad, pero al 99.9% de la población no le interesa demasiado

  • De esa intuición surgieron las passkeys, que incorporan inicio de sesión único y autenticación de dos factores como factores para iniciar sesión. Apple integró por completo las passkeys con sincronización en la nube, y en dispositivos Apple funcionan dentro del propio dispositivo; si tienes un dispositivo Apple, basta con la autenticación de dos factores. Chrome también puede actuar como passkey, y BitWarden también. No se pueden engañar, no se pueden eludir, puedes elegir el proveedor y el sitio puede indicarte el nombre del proveedor registrado, así que no hay nada que recordar
  • Recomiendo usar un gestor de contraseñas basado en el navegador de buena reputación, protegido con una contraseña fuerte, y dejar que genere contraseñas fuertes que no vayas a memorizar. Los sitios web que bloquean esto con JavaScript en los campos de contraseña deberían responder por daños y perjuicios y sanciones agravadas. Especialmente los bancos
  • Las contraseñas fueron una buena idea durante mucho tiempo. Durante los primeros 10 años, quizá 20, no había dispositivos sin un teclado adecuado. El problema mayor fue la idea de que las contraseñas debían ser complejas y largas, del tipo mezclar caracteres alfanuméricos aleatorios con símbolos y tener 12 caracteres o más; habría sido mejor usar algunas palabras. A menudo se subestima cuánto cambió el entorno tecnológico después de la llegada de los smartphones, pero en el entorno anterior de computadoras y laptops, las contraseñas eran una buena opción

• La frase “aprender varios exploits y cómo usarlos es gastar tiempo aprendiendo herramientas y técnicas que quedarán obsoletas cuando se parchen” es incorrecta. En realidad se aprende el aspecto práctico junto con la teoría, y eso es muy útil

  • También veo un problema en esta parte. No puedes convertirte en escritor sin aprender a leer. Publicar un libro no reduce la utilidad de la lectura. Hay que aprender cómo funcionan los exploits conocidos para poder descubrir también exploits desconocidos. Aunque se parchee una vulnerabilidad conocida, el valor del conocimiento sobre cómo surgió no disminuye. Puede que ya no se pueda usar, pero usarla no habría sido el objetivo del aprendizaje en primer lugar
  • No necesariamente. Hay muchos script kiddies que no tienen idea de qué es TCP ni de cómo se ve una solicitud HTTP, pero sí saben bajar un sitio con LOIC

• De esta lista quitaría “hackear es cool” y pondría confiar en el cliente. Últimamente ha habido más intentos de confiar en el cliente. Por ejemplo, apps móviles que exigen una prueba de que el sistema operativo no fue modificado, o el intento de Google de meter un DRM similar en la web. Si el modelo de seguridad de red depende de confiar en el software del cliente, ya está roto

  • Eso no es un problema de seguridad, sino de control. Un sistema modificado puede usarse para fines malvados como bloquear anuncios, y a Google no le gustaría eso

• Sobre “bloquear por defecto”, se dice que “no es mucho más difícil que permitir por defecto y te deja dormir mejor por la noche”; quizá el responsable de seguridad de TI duerma mejor, pero el resto de la empresa se irrita muchísimo porque no puede hacer nada sin ir y venir tres veces con el departamento de TI. Y cuanto más irritada está la gente, más probable es que use atajos que destruyen el concepto de seguridad. Si obligas a cambiar la contraseña todos los meses, usarán cosas como password1, password2, password3. Una buena seguridad de TI no consiste simplemente en desconectar el cable de red; debería ser algo invisible y no intrusivo, casi mágico para el usuario

  • Una app de un proveedor muy importante para el departamento de un amigo dejó de funcionar de repente y abrieron un ticket con TI; era tan complejo que al final le autorizaron ejecutar una captura de paquetes de Microsoft. Aunque hizo la captura, TI no pudo resolverlo y, frustrado, me la envió. Como soy desarrollador, en mi laptop tengo permisos de administrador y MSDN, así que descargué las herramientas de Microsoft y revisé la captura. Resultó que esa app era una implementación cliente/servidor dentro de la máquina local. El frontend se comunicaba con el backend por un puerto de red, y el backend se comunicaba con el servidor del proveedor. Cuando la empresa empezó con “bloquear por defecto”, también rompió mi flujo de desarrollo de varias maneras, y yo también encontré atajos que TI no conocía. Le expliqué a TI qué decir y cómo podían ponerlo en la lista blanca, pero él sigue teniendo problemas. Difumino los detalles no solo por confidencialidad, sino también porque mi amigo trabajó con TI durante más de un año para llegar a este punto, y eso fue hace dos años, así que he olvidado muchos detalles. Cuando una empresa manufacturera legacy empieza con “bloquear por defecto”, “tres idas y vueltas adicionales” se queda corto
  • Ojalá más administradores de TI tomaran los cinturones de seguridad y las bolsas de aire como modelo de seguridad. En el uso normal del auto causan una incomodidad muy pequeña, pero cuando hay un accidente su valor es enorme. En cambio, muchos administradores consideran normal bloquear el trabajo en sí para ocultar su ignorancia y falta de profesionalismo
  • Una buena seguridad de TI no es invisible. Existe para impedir el despliegue de aplicaciones deficientes que exigen acceso ilimitado saliente a Internet. Debe impulsar la autenticación multifactor y trabajar con las partes interesadas desde el principio para asegurar las cosas desde la etapa inicial. En gran parte se trata de identificar y mitigar riesgos de negocio. Vale la pena considerar que cada aplicación se trata como un elemento de responsabilidad, y que cada nueva aplicación que se salga del estándar debe evaluarse caso por caso
  • Creo que una política de “bloquear por defecto” es buena idea para la infraestructura de seguridad alrededor de las estaciones de trabajo. La molestia de que TI cambie el perfil de seguridad cuando entra una herramienta nueva que usa puertos nuevos, etc., es mucho menor que el costo de que se filtre el contenido de una estación de trabajo específica. Dicho eso, los servidores de aplicaciones y la infraestructura pública deben operar necesariamente con bloqueo por defecto. No se me ocurre fácilmente una situación en la que no deba ser así
  • El área de TI corporativa existe para la empresa. Sus costos no deben superar sus beneficios. Hace falta equilibrio. Abrir un puerto no debería tardar una semana, pero tampoco quieres que la gente corra servidores web en el escritorio de la empresa y que, por accidente, al lado queden archivos con planes propietarios

• Los textos centrados en seguridad suelen estar escritos por personas que le dan una importancia extrema a la seguridad, y muchas veces ignoran las dificultades que un enfoque puramente centrado en seguridad les causa a los usuarios de software seguro. Siempre veo la seguridad como un control deslizante entre seguridad y comodidad. Un diseño completamente seguro es tan incómodo que casi nadie lo usa, y un diseño completamente cómodo tampoco es lo suficientemente seguro, por lo que puede terminar llegando al mismo resultado. Aun así, en general vale la pena leer este texto, pero discrepo fuertemente con la idea de que sea tonto que un experto en seguridad escriba exploits o aprenda a abusar de un sistema específico. Aprendí mucho más de seguridad estudiando vulnerabilidades y exploits, e implementándolos yo mismo de forma white hat, que estudiando “diseño seguro”. Es parecido a eso de “para conocer al enemigo, hay que convertirse en él”.

  • Esta analogía quizá sea más accesible, pero yo suelo decirlo de forma un poco más agresiva. Cuando discuto con gente que solo habla de seguridad, empiezo con algo como: “Lo más seguro sería cerrar la tienda mañana, pero supongo que eso sería difícil de aprobar”. Después de reírnos juntos, podemos hablar de qué compromisos hacer. También me ha funcionado hacer que cambien su postura base diciendo: “Si dicen que no, simplemente lo haremos sin ustedes, y entonces la seguridad será solo la que yo le agregue. Siempre podemos encontrar una forma, así que me gustaría que nos guíen hacia un camino más seguro”. Dicho eso, intento evitarlo porque es fácil generar rechazo.

• Esta es, en su mayor parte, una lista pésima de hace 19 años. Decir que “el software y los sistemas deberían ser seguros desde el diseño y estar diseñados teniendo en cuenta el manejo de fallas” significa “en un mundo perfecto, todo habría sido seguro desde el principio”. Eso nunca va a pasar, así que hay que usar técnicas de descubrir y luego parchear, y han funcionado bien para empresas que efectivamente parchean las vulnerabilidades descubiertas y aprenden de sus errores para mejorar sus prácticas de programación futuras. Además, la mayoría de los sistemas no son estáticos. No se lanza un sistema seguro una vez para luego no actualizarlo nunca más; la mayoría de las aplicaciones y sistemas se actualizan con frecuencia, y ahí entran nuevas vulnerabilidades.

  • Interpretándolo de la forma más favorable posible, parece que lo que el autor intenta señalar es el problema de aplicar “parches” demasiado acotados sin corregir las malas prácticas de diseño que crearon la vulnerabilidad. Por ejemplo, “arreglar” una vulnerabilidad de cross-site scripting en una aplicación web bloqueando solicitudes que contengan palabras clave como script u onclick.
  • Es un ejemplo de cómo, si dices tonterías con confianza, mucha gente pensará que eres inteligente.
  • El texto en sí también es abiertamente tonto. La frase “una persona tímida puede convertirse en delincuente” malentiende el hacking, la criminalidad y la naturaleza humana. Los delincuentes van donde está el dinero, y no hace falta ser un luchador enorme para apuntarle con un arma a alguien frente a un cajero automático y quitarle su dinero, ni hace falta ser el estereotipo de nerd para entender de computadoras. Es una tontería del nivel de la peor comedia de los años 80. También es absurdo decir que “la computación remota eliminó para los delincuentes el requisito histórico de estar cerca de la escena del crimen”. Basta pensar en lo que permitió el correo. La estafa del prisionero español existe desde hace siglos y tiene la misma estructura que las estafas 419. También es exagerado decir que el anonimato y la falta de contacto cara a cara con la víctima reducen la dificultad emocional del delito. Los delincuentes pueden estafar o usar violencia incluso viendo la cara de la víctima, y amenazarla para vaciarle la cuenta. Por último, “hazlo completamente bien desde el principio, idiota” no es un plan ejecutable.
  • Las actualizaciones frecuentes tienden en gran medida a ocultar prácticas de ingeniería inadecuadas y a fomentar productos inadecuados. El mundo no es estático, pero en la mayoría de los casos hay patrones que deben identificarse y manejarse. Si vas corriendo de arreglo rápido en arreglo rápido para un MVP, no puedes hacerte ese tiempo.
  • Aunque hay algunos puntos valiosos, al menos la mitad se lee como una diatriba vergonzosa que podrías oírle a un pasante nuevo y borracho de help desk hacia el final de la fiesta de fin de año de la empresa. Sorprende que lo haya escrito un experto en el tema, que lo haya tenido 20 años en su sitio web y que además lo hayan recomendado tanto.