En esta entrada me gustaría repasar algunas aproximaciones al respecto del concepto de Trusted Computing, y como lo lógico es empezar con la definición, por Computación Confiable nos solemos referir a sistemas completos e integrados hardware+software, en los que todo lo que se ejecuta se encuentra bajo el control del sistema y hay muy poca flexibilidad para la ejecución de otras cosas; enseguida veremos algunos ejemplos. Así pues, podría decirse que disponemos de una caja “blindada” que no puede en teoría ser manipulada ni por software ni por hardware, de modo que sólo realizará las funciones para las que esta diseñada siguiendo las directrices marcadas por el fabricante, sin que pueda ser manipulada o alterada.

Para evitar dichas manipulaciones el propio fabricante intenta proteger el sistema para que incluso el “propietario” del hardware (en el sentido de dueño del hierro) pueda utilizarlo para lo que guste. Este tipo de protecciones se usan de manera habitual para proporcionar contenidos con restricciones de uso (DRM), aplicar comisiones a los productos software, sistemas incopiables, etc. En algunos casos, los motivos aducidos serán razonables y en mi opinión otras veces abusos, la pregunta es: ¿Obedece el ordenador a su dueño? ¿U obedece a otra organizacion como Microsoft, Apple , Sony, Nokia, etc.? ¿Somos propietarios de nuestro propio hardware? ¿Quién manda en nuestra propia casa?

Aparte de la conocida seguridad por oscuridad, o la inseguridad de sentirse seguro, podemos hablar de la “seguridad por código binario”, y me explico. Hay muchos proyectos en los que todo es auditable, inspeccionado y revisado… excepto el código binario. Es muy habitual que éste se considere como algo seguro, inescrutable y secreto, ya que se considera que la ingeniería inversa es algo así como una tarea inabordable y de demasiada complejidad para ser llevada a cabo, si acaso por superexpertos.

Como ejemplo de este tipo, hoy en día existen numerosos binarios cerrados por diversas razones como DRM, licencias de producto, aplicaciones cliente servidor, o programación cerrada en sí misma. Ni que decir tiene que la mayor parte de ellos no son a día de hoy tan cerrados como a las empresas responsables de su desarrollo les gustaría. Para desmontar esa creencia de que la ingeniería inversa es para superdotados, en este post me gustaría repasar algunas de la herramientas existentes que permiten a no tan expertos el averiguar qué y cómo lo hacen los programas cerrados.

Está a punto de salir el nuevo “megaproyecto” web de la compañía y como desgraciadamente sucede en algunas ocasiones, los aspectos de seguridad no han sido revisados previamente a la puesta en producción. Para solventar esto, a última hora recae sobre el equipo de explotación la responsabilidad de auditar el sistema, detectar las posibles vulnerabilidades y decidir si se pueden arreglar, o si por el contrario son de tal magnitud que impiden la salida a producción del proyecto. La presión por parte de la organización en estos momentos es alta frente al equipo de explotación, por lo que las recomendaciones y decisiones que se tomen deben ser firmes y estar fuertemente razonadas.

El equipo técnico auditor mediante la utilización de ciertas herramientas automáticas y otras manuales entrega el informe, en el que aparecen tres vulnerabilidades de criticidad “grave”, cinco de criticidad “media” y tres de vulnerabilidad “baja”. ¿Qué hacemos ahora?

Uno de los problemas a los que nos enfrentamos en organizaciones con una complejidad de red media o alta es la gestión de los permisos que implican a elementos de comunicaciones (switches, cortafuegos, routers, etc.); me gustaría esbozar algunas de las cosas hay que tener en consideración para que la gestión sea posible.

Primero de todo, ante la solicitud de una petición de acceso desde un servidor a otro por parte de algún responsable técnico de algún proyecto TIC de la compañía, hay que tener en consideración dos tipos de aspectos bien diferenciados:

• Aspectos funcionales: Si alguien solicita por ejemplo acceso al puerto de Oracle de un servidor de BBDD, lo primero que hay que evaluar es si desde el punto de vista de negocio, ese permiso debe de ser concedido. Este tipo de accesos deben ser validados por un responsable o autorizador funcional, que puede o no coincidir con el propietario del activo dentro de la organización. Es muy habitual que por agilidad en las gestiones, compañerismo mal entendido, o ausencia de procedimientos formales, este punto se pase por alto y se pase a los aspectos técnicos directamente, sin entrar a considerar la conveniencia de la solicitud desde el punto de vista del negocio.
• Aspectos técnicos: Una vez la autorización funcional ha sido concedida, hay que revisar los aspectos técnicos de los permisos solicitados, para detectar sus implicaciones técnicas sobre otros servicios, el perímetro de la red, problemas de seguridad, etc. Algunas de las cuestiones son: ¿la red origen esta controlada por la organización, o es una dirección externa ajena sobre la que no tenemos información? ¿El protocolo utilizado para la conexión es seguro? ¿Va cifrado? ¿Implica este acceso abrir accesos con redes no confiables? ¿Afectan a la DMZ? ¿Es posible utilizar soluciones alternativas? En cualquier caso, la recomendación es que si el cambio es de cierta relevancia, tiene que haber una auditoria, tanto de caja blanca como de caja negra; esto debería ser obligatorio para cualquier acceso externo a la red corporativa, como por ejemplo el de un nuevo proveedor.

Como todos los veranos, este año se ha celebrado la Black Hat, un conjunto de conferencias donde se desvelan las ultimas tendencias en seguridad, cubriendo con detalle la parte técnica aunque también cada vez mas la parte organizativa y social. Aunque desgraciadamente no he podido asistir a estas charlas, tantos los papers comos los slides están disponibles en la web en la parte de archivos Blackhat.

Muchos equipos investigadores esperan a este evento para desvelar sus descubrimientos, por lo que creo que son de lectura obligatoria para aquellos que quieren ver por dónde van las ultimas tendencias y el “state of the art” en el mundo de la seguridad.

Tras echar un vistazo a las presentaciones, uno tiene la impresión que nada es seguro, ya sean teléfonos móviles, parquímetros, infraestructuras eléctricas, medidas antihacking, certificados SSL, la virtualización, la nube, o cualquier tipo de hardware que puedan imaginar. Los malos pueden incluso leer tu teclado desde el enchufe de tu ordenador, así que la única opción parece ser volver a las cuevas. En fin, que para cualquier “maldad” que puedan imaginar ya hay quien se dedica a aplicarla… y en estas charlas se pueden ver muchas de ellas.

Después de ver los enemigos de los parches, esta vez toca hablar de los enemigos de la seguridad perimetral. En principio, todo apunta a que esto debería de ser una tarea muy sencilla, basada en la regla “sólo se deben de habilitar los permisos que sean necesarios”. Sin embargo, con rascar un poco sobre la superficie, es habitual ver grandes errores en la configuración y problemas en la gestión perimetral de las organizaciónes. En esta entrada vamos a comentar los enemigos técnico, estructurales y organizativos que hacen que aparezcan problemas en la seguridad perimetral de las organizaciones. En otras palabras, cómo es posible que se llegue, sin darse cuenta, a situaciones en las que la arquitectura de la red, o la reglas y ACLs implantadas no son correctas desde el punto de vista de la seguridad.

— Las prisas. Este es un problema típico de la seguridad en todos los niveles, y por tanto, también de la seguridad perimetral, que produce situaciones como “Esto tiene que salir a producción ya”, “Tú abre los puertos para que funcione para ver si es eso y luego ya veremos”, “Tú dale usuario y contraseña de la VPN y luego lo gestionamos como toca”, etc.

Solución: Debe considerarse la parte de comunicaciones y seguridad perimetral como una parte de cualquier proyecto de implantación.

El parcheado de los sistemas informáticos es una de las medidas mas importantes de seguridad que deben seguirse e implantarse en cualquier organización. Recientemente hemos podido ver como grandes organizaciones gubernamentales han sufrido incidentes de seguridad por propagación de gusanos, que podían haberse evitado en gran parte de una manera sencilla simplemente aplicando los parches. Si están pensando lo mismo que yo, se preguntarán cómo es posible que cualquier usuario domestico mantenga actualizado su equipo siempre que sale una vulnerabilidad y en estas organizaciones no apliquen el parcheado de manera correcta.

Francamente, no tengo la respuesta a la pregunta, pero en esta entrada pretendo hablar de cuáles son los problemas a los que los administradores TIC se deben enfrentar cuando tratan de implantar políticas de parcheado. A estos problemas los voy a llamar “Los enemigos de los parches”, que les detallo a continuación:

Desde hace un tiempo, es de notoria actualidad la problemática que supone la pérdida y robo de equipos portátiles, con los consiguientes problemas al respecto de la información corporativa albergada en ellos; hasta una organización como el FBI llega a perder más de un centenar y medio, y aun peor, el Departamento de Energia de EEUU cifra en aproximadamente 1,400 los portátiles perdidos durante 6 años. En base a esto, hoy vengo a comentarles una técnica de protección presente en muchos portátiles, pero desconocida, y destinada a proteger la información de sus discos duros.

Todos los discos duros (según el estándar ATA de la Wikipedia) disponen de un mecanismo de protección mediante contraseña, que bloquea el acceso al disco si éste no recibe la contraseña adecuada al arrancar. Dicha opción está disponible en la BIOS del ordenador, normalmente identificada como HDD Password.

La semana pasada cogí el autobús de línea para ir a visitar un cliente, vehículos que vienen equipados con diversos sistemas informáticos que generan o cancelan los billetes electrónicos. En concreto, este autobús tenía una canceladora automática de bonos de transporte y una impresora de los billetes individuales, pero sin embargo ninguno de los dos sistemas funcionaba, y estaban completamente “muertos”.

La empresa de transporte dispone de un plan para estas ocasiones, con el cual se asegura que las “cosas” sigan funcionando. En este caso, el conductor dispone de una troqueladora manual de bonos, y de un taco de billetes preimpresos, preparados para una situación como la que nos ocupaba. Esto implica que una caída total de los elementos informáticos no impide que se puedan cobrar los viajes del autobús.

Hace unos días en una reunión con la familia lejana, comenté que me dedicaba a temas de seguridad, y como suele ser habitual, los interesados tardaron poco en preguntar que les recomendaba para sus equipos caseros personales. Entonces tuve que ver cual era la medida de seguridad más importante que les iba a recomendar.

Dado que todos los presentes eran usuarios de Microsoft, lo primero que se me vino a la cabeza fue el “escudito” que Microsoft incluye en sus sistemas operativos de escritorio. Seguro que muchos de ustedes lo han visto alguna vez en la esquina derecha de la pantalla, y que de una manera semafórica le indica al usuario si su sistema es “seguro” (verde), “no es seguro del todo” (amarillo), o “no es seguro” (rojo). Hay que que reconocer que aunque sea una simplificación y las cosas no tiendan a ser tan simples, a un usuario doméstico puede ayudarle bastante. Las tres cosas que este sistema comprueba en un Windows XP son las siguientes: