Mostrando las entradas con la etiqueta seguridad. Mostrar todas las entradas
Mostrando las entradas con la etiqueta seguridad. Mostrar todas las entradas

domingo, 12 de julio de 2009

Responsable de seguridad e higiene, se busca.

…para asegurar la adecuación de las instalaciones a las normativas vigentes. Su primera asignación será la actualización del plan de evacuación.

fail-owned-evacuation-fail

Visto en… adivinaron, en FailBlog.

sábado, 7 de febrero de 2009

¿Sabemos identificar un mail fraudulento? SonicWALL Phishing and Spam IQ Quiz.

phishing2

SonicWALL Phishing and Spam IQ Quiz es un test en el que tendremos que distinguir e-mails legítimos de fraudulentos en un conjunto de 10 ejemplos. Vale la pena para saber si podemos confiar en nuestro propio criterio.

Advertencia: no se queden tranquilos con menos de 100% de aciertos, ya que son ejemplos de técnicas extremadamente comunes. En la página de resultados hay links explicando cada ejemplo.

Visto en Security By Default.

sábado, 31 de enero de 2009

Una anécdota sobre la percepción de seguridad.

La entrada Experto que acabo de sacar y el comentario que hizo en ella Senior Manager remarcando el término “percepción” me hicieron acordar de…

una anécdota: tenía… 19 o 20 años y trabajaba de “Ayudante de Sistemas de Control Operativo”. Básicamente era el que “sabía de computadoras” a la hora de elaborar informes ad-hoc y programar pequeños procesos de depuración o lo que hiciera falta.

Resulta que el gerente del que dependía ascendió en la estructura, y dedicó uno de sus últimos días a borrar sus cosas personales de la computadora y la red. En un momento me llamó –nos llevábamos bien, por suerte- y me dijo:

-¿Podrías grabarme los archivos que están en mi carpeta personal de la red –súper personal, súper secreta y privadísima del gerente- a un disco?

Se refería a un ZIP, o a algo igualmente obsoleto ahora, supongo.

-Ok –dije, di media vuelta y me fui sin más preguntas ni comentarios a hacer mi tarea... ¿Se entiende?

Y supongo que ésa fue la última vez que el tipo guardó un archivo con información privada o delicada en una red corporativa.

Saquen sus conclusiones. Yo usaría Google Apps.

lunes, 12 de enero de 2009

Errores de programación: los 25 más peligrosos.

Siguendo un twit de Matt Cutts (@mattcutts) me encontré con un interesantísimo documento, 2009 CWE/SANS Top 25 Most Dangerous Programming Errors.

Es una lista de los 25 errores de programación más peligrosos en términos de seguridad informática. Los errores están explicados tanto en forma breve y amigable como detallada y técnica y hay un montón de referencias para seguir.

Esta lista se obtuvo por consenso entre una serie de expertos de Estados Unidos y otros países (más información aquí). De acuerdo al documento, estos errores han sido los causantes de 1.5 millones de vulnerabilidades durante el 2008, que han posibilitado que muchas de las terminales utilizadas para visitar los sitios afectados se conviertan en zombis.

Algunos de estos errores son ampliamente conocidos, como los relacionados con la validación de datos ingresados por el usuario, que llevan a los ataques vía SQL-Injection o Cross-Site Scripting.

Otros son más sutiles o dependen de la actualización de los programadores involucrados en el proyecto, como por ejemplo el uso de algoritmos generadores de números pseudo-aleatorios débiles (o directamente la falta de uso, una de las claves que permitió a un grupo de investigadores y estudiantes de seguridad quebrar absolutamente la seguridad SSL hace menos de un mes).

Ésta es la lista de errores traducida (con mucho esfuerzo) por mí:

Interacción insegura entre componentes

Vulnerabilidades relacionadas con el envío y recepción de datos entre sistemas, componentes, módulos, programas, procesos o hilos separados.

  • Validación defectuosa de los datos de entrada.
  • Escape o codificación defectuosa de los datos de salida.
  • Defectos o fallas en la preservación de la estructura de las consultas SQL (SQL-Injection).
  • Fallas en la preservación de la estructura de las páginas web (Cross-site Scripting)
  • Fallas en la preservación de la estructura de comandos del sistema operativo (OS Command Injection)
  • Transmisión no encriptada de datos sensibles.
  • Falsificación de petición en sitios cruzados (Cross-Site Request Forgery)
  • Errores provocados por la interacción con el entorno de ejecución (Race Condition)
  • Información sensible volcada en mensajes de error.
Manejo de recursos

Vulnerabilidades relacionadas con manejos inapropiados durante la creación, uso, transferencia o destrucción de recursos del sistema.

  • Fallas al mantener una operación dentro de un determinado espacio de memoria.
  • Control externo del estado de la aplicación (por ejemplo al utilizar cookies para mantener el estado).
  • Control externo del nombre o la ruta a un archivo (por ejemplo al construirlo a partir de datos de entrada).
  • Ruta de ubicación de recursos no confiable (explotada por un atacante que logre que la aplicación apunte a una ubicación de recursos determinada).
  • Fallas en el control de la ejecución de código (por ejemplo el generado dinámicamente).
  • Descargas de código sin verificar.
  • Descarga o liberación defectuosa de recursos.
  • Inicialización defectuosa.
  • Cálculos incorrectos (por ejemplo fallas por desbordamiento inducidas).
Defensas porosas

Vulnerabilidades relacionados con técnicas defensivas mal o abusivamente utilizadas, o simplemente ignoradas.

  • Control de acceso impropio (autorización).
  • Uso de un algoritmo criptográfico quebrado (obsoleto).
  • Contraseñas establecidas en el código (hard-coded).
  • Errores en la asignación de permisos a los recursos.
  • Uso de valores pseudo-aleatorios predecibles.
  • Ejecución con privilegios innecesarios.
  • Seguridad implementada en el cliente (en vez de en el servidor).

Como les dije, hay mucha información en el anuncio, y en el detalle de estas vulnerabilidades. Vale la pena la lectura en profundidad.