La necesaria segregación de funciones

En una ocasión tuve la oportunidad de revisar el procedimiento que asegura que en una cadena de montaje el tornillo que sujeta la barra de la dirección de un vehículo se introduce correctamente, aspecto como comprenderán de vital importancia por sus implicaciones en seguridad. Dicho procedimiento era el siguiente:

1. Un operario colocaba el tornillo.
2. Otro operario apretaba dicho tornillo con otro par de apriete.
3. Un tercer operario pintaba de blanco el tornillo, y no por una cuestión estética, sino para obligar a que alguien tuviera que hacer algo sobre el tornillo existente.
4. Finalmente, un último operario de calidad revisaba que estaba dicho tornillo y además estaba pintado de blanco, y procedía a anotar el resultado en una hoja de control de calidad; por supuesto, si el operario no encontraba el tornillo no se limitaba a apuntar que éste no estaba y dejaba el coche continuar por la cadena de montaje como si nada.

Con este procedimiento los responsables del proceso estaban razonablemente tranquilos de que todos los coches salían con su tornillo en la barra de la dirección, ya que cualquiera de los intervinientes podía levantar la alarma ante la falta del tornillo. Como pueden imaginar, otro tipo de revisiones más «ligeras» nos podrían llevar a que si el primer operario no pone el tornillo, nadie se da cuenta y el vehículo sale sin dicho elemento, con el problema evidente que eso supone.

Si extrapolamos este caso al campo de las Tecnologías de la Información, aunque en muchos casos las consecuencias del fallo de un proceso no suelen ser del mismo calibre (aunque en ocasiones, como sistemas SCADA de entornos críticos, sí que lo son), tenemos que las responsabilidades de instalación, mantenimiento y auditoría recaen a menudo sobre la misma persona/grupo o departamento en su totalidad.

Así pues, procesos como el parcheado y la configuración segura de servidores, gestión de cortafuegos, cambios de arquitectura, o seguridad perimetral deberían auditarse y revisarse con rigurosidad, por terceras partes ajenas a aquellas que han intervenido en el proceso de instalación o los mantienen funcionando en el día a día; porque además lo más probable, por un simple factor psicológico, es que una persona que tiene un fallo en una instalación o en la gestión de un servidor de producción no se percate de ello aun en el caso de tener que auditar estos elementos.

Por ello, y aquí es donde quería llegar, es imprescindible que el Departamento de Seguridad esté segregado, y revise y audite los elementos de cualquier proceso relacionado con la seguridad con total independencia y desde su propio punto de vista. Es más, en cualquier organización la posición jerárquica del responsable de seguridad debe de estar por encima o en paralelo del responsable de TI, pero nunca por debajo de éste. Eso nos asegurará que dispone de libertad para «levantar la voz» cuando lo considere necesario, y promover iniciativas propias que no son relegadas a un segundo plano por las necesidades inmediatas de TI; en otras palabras, que cuando vea que un tornillo no está donde debe, pueda anotarlo sin que se considere que un tornillo es sólo un tornillo y que es mejor que el coche siga por la cadena de montaje.

En definitiva, no tenemos que olvidar que además de operarios que ponen tornillos, es necesario tener personal que revisa que esos tornillos están donde deben estar, por lo que pueda pasar. Para acabar, les contaría por qué se estaba revisando con detenimiento el tema del tornillo, pero eso es otra historia…

Una firma digitalizada no es una firma electrónica

Es ya habitual que a la hora de pagar con tarjeta de crédito, en todo tipo de comercios, supermercados, o grandes superficies, nos sorprendan con un nuevo aparato, en forma de tarjeta digitalizadora, que nos ofrecen amablemente para que garabateemos nuestra firma manuscrita. Seguro que se han encontrado con ellos, pero a continuación pueden ver tres ejemplos de este tipo de instrumentos:

fdigital.jpg

[Read more…]

Asimetrías en las transacciones digitales futuras

El pasado mes de junio se aprobó la Ley de acceso electrónico de los ciudadanos a los Servicios Públicos, en la que se establece que la Administración no es que sólo «pueda», sino que «debe» ofrecer todos sus servicios de manera electrónica. Sin ninguna duda, esta ley acompaña de manera definitiva al DNI electronico, y a otras opciones de certificación digital como puede ser la ACCV. No hay ninguna duda de que todas estas iniciativas pueden mejorar en mucho los trámites de los ciudadanos, pero por otro lado abren una gran cantidad de incógnitas frente a las garantías que tienen los ciudadanos al realizar trámites de manera digital, entre las que queremos destacar la asimetría de las transacciones digitales en la presentación de la declaración de Hacienda.

Recientemente muchos contribuyentes han realizado su declaración de Hacienda de manera digital a través de Internet. El proceso de presentación telemático asociado tiene visos de ser bastante completo: los usuarios deben acreditarse para obtener su certificado digital (formado por una clave pública y una privada), y la clave privada es generada por el PC particular de cada uno, con lo que este certificado digital permite que el usuario «firme digitalmente» su declaración. Todo ello a traves de la Fábrica Nacional de Moneda y Timbre, una autoridad de certificación con en principio todas las garantías.

Hasta aquí, todo bien (en realidad, no esta bien «del todo» al ser un certificado software, pero la tecnología que le sucederá en breve como es el DNI digital, sí tiene características como para considerarse firma electrónica); el proceso en su conjunto parece que sigue técnicas en principio bastante robustas en cuanto a los aspectos de seguridad, tanto organizativa como técnicamente.

Ahora analicemos el proceso de presentación de la declaración: preparamos ésta con el programa PADRE y nos conectamos a la página web de Hacienda donde nos aparece un applet, mediante el cual firmamos digitalmente nuestra declaración, y puesto que la firma digital equivale a la firma manuscrita, esto constituye en última instancia el equivalente a la entrega de nuestra declaración firmada. Ahora sólo cabría esperar que Hacienda tambien nos firmara (o cuñara) nuestra declaración con la misma robustez como nosotros se la hemos firmado, mediante un documento firmado digitalmente por la Administración (por la aplicación) que justifique que hemos entregado nuestra declaración. No obstante, en su lugar lo unico que recibimos es un número de registro, no firmado digitalmente ni de ninguna manera: un simple número de serie.

Por ello la autentificación y firmado de la declaración se produce de una manera completamente asimétrica: mientras que el ciudadano se autentica con ciertas medidas criptográficas y de seguridad, el justificante que obtiene es técnicamente muy debil, y con evidentes riesgos sobre su validez en caso de problemas. Y esta es la principal razón de que año tras año no presente la declaración por Internet sino a través del banco, del que al menos recibo un documento cuñado por la oficina con el que demostrar que la he presentado en caso de presentarse problemas futuros, ya que este documento sellado es a mi entender bastante más robusto que un simple número.

Muchos de los lectores podrían pensar que el tema de la declaración no tiene al fin y al cabo demasiada importancia, y quizá tengan razón, ya que al fin y al cabo Hacienda también permite maneras poco robustas de aprobar borradores de declaración como puede ser a través de SMS o medios similares. Pero el problema reside en que es esta es la tecnología que viene, y esta es por tanto la asimetría con la que nos vamos a encontrar en los futuros desarrollos con firma digital, como por ejemplo el nuevo DNI; ¿se imaginan ustedes firmando un contrato con algun operador de Telecomunicaciones en el que el usuario firma el contrato digitalmente y el operador simplemente entrega una hoja para imprimir? No parece un procedimiento demasiado apropiado, ¿verdad?

A la vista de este tipo de problemas que van apareciendo, no cabe duda de que los usuarios tendremos que estar alerta ante las futuras transacciones basadas en firma digital, que seguro que con el nuevo DNI electrónico van a comenzar a surgir.

120,000 cuentas de un ISP hackeadas

Como saben, recientemente ha sido noticia la intrusión en un ISP español de un hacker que presuntamente ha capturado 120,000 cuentas de usuario [ElPais.com] [Barrapunto] [Kriptópolis]. Teniendo en cuenta que el problema por supuesto es preocupante para los propios clientes de esta compañía, pienso que es además de especial interés ver cuál ha sido el modelo de negocio/motivación de estos hackers en la empresa de hosting, ya que según diversos comentarios, parece que la intrusión fue utilizada para modificar los contenidos de las páginas albergadas por los clientes en el ISP, redirigiendo éstas hacia páginas con troyanos y otro tipo de malware.

Aunque entiendo la preocupación de cualquier cliente al ver que sus datos de carácter personal circulan «por ahí», y con el temor adicional de que puedan haber datos bancarios, creo que es de destacar el uso que al parecer se ha hecho de la intrusión: redirigir usuarios —visitantes— de páginas web de confianza hacia páginas web con troyanos, con lo que podemos afirmar que en última instancia los verdaderos sufridores —destinatarios y víctimas— del ataque no es el ISP ni sus clientes, sino los clientes de estos clientes. Algunas preguntas surgen a raíz de esto:

— ¿Qué imagen da una empresa que llena de virus o cosas peores a todos los clientes que le visitan?
— ¿Qué responsabilidad tiene en esto la empresa de hosting? ¿Y la empresa propietaria del dominio/contenidos?

Sin lugar a dudas, los nuevos modelos de negocio del hacking no paran de sorprendernos… ¡Ah! Y esto muestra, una vez más, que no es cierto aquello de que no les va a pasar nada por navegar por páginas web de su confianza…

0day exploits

En estos últimos tiempos están muy de moda los «0day exploits», esto es, exploits existentes y en uso, para los cuales aun no ha sido publicada la vulnerabilidad y por supuesto no existe parche al respecto.

Un administrador de sistemas puede pensar que las vulnerabilidades de seguridad siguen el siguiente patrón:

Un grupo de hackers descubren una vulnerabilidad
(pasan días)
El fabricante proporciona el parche de seguridad
(pasan meses)
El administrador de sistemas parchea sus servidores
(pasan meses)
Aparece el exploit y es explotado por gusanos y hackers
(pasan meses)
El administrador *que no ha parcheado* sufre una intrusión
y tiene un incidente de seguridad

Cuando en realidad, la secuencia que se sigue estos días con este tipo de exploits es la siguiente:

Aparece el exploit y es explotado por gusanos y hackers
(pasan días)
El administrador sufre una intrusión y tiene un incidente de seguridad

Así pues, no queda mas remedio que prepararse para el incidente, y para la segunda de las posibilidades en el ciclo de vida de las vulnerabilidades. Y en todo caso, tener presente que cualquier software de los que tenemos instalados en estos momentos puede ser vulnerable. La conclusión es que hay que tener siempre el menor número de servicios y servidores expuestos, de modo que la definición de «RED DMZ» sea la de «red en la que se ubican servidores que en algun momento van a ser hackeados«.

No por nada, la siguiente frase contradictoria tiene mucho sentido «Expect the unexpected!«.