Noticia de hoy, calentita: un fallo en la web del Ministerio de Vivienda daba acceso a datos personales de solicitantes de la renta de emancipación, permitiendo al parecer acceder incluso a información fiscal de otros solicitantes (datos de nivel medio). Pero no, no voy a entrar en la desgastada discusión de que si esto pasa o no pasa porque las administraciones públicas no tienen una especial sensibilidad ni concienciación en cuanto a sus responsabilidades en el tratamiento de los datos de carácter personal, de si esto pasa porque no están sujetas al régimen sancionador de la LOPD, etc.
Quiero ir por otro lado. A mi juicio este incidente es un ejemplo práctico y claro que hace patente la necesidad de que el Esquema Nacional de Seguridad (ENS) pase de ser una mera declaración de intenciones a una obligación real y efectiva. El servicio de gestión, consulta y seguimiento del estado de tramitación de las citadas solicitudes de renta de emancipación ante el Ministerio de Vivienda es un servicio sujeto, se mire por donde se mire, al cumplimiento de la Ley 11/2007 de acceso electrónico de los ciudadanos a los servicios públicos. El artículo 42 de esta ley decía que se establecerían unos criterios para definir el marco en materia de seguridad, normalización de la información y de las aplicaciones a utilizar para que este acceso electrónico se desarrolle de manera segura. Por eso en enero de este año se publicaron el Esquema Nacional de Seguridad (RD 3/2010) y el Esquema Nacional de Interoperabilidad (RD 4/2010).
El principal objetivo del ENS es definir el marco de confianza necesario para que se desarrolle adecuadamente el intercambio de información entre las administraciones públicas y los ciudadanos y terceras empresas a través de estos medios electrónicos, determinando las medidas de seguridad necesarias que deben cumplir los sistemas de información que les dan soporte. Porque el ENS habla de la seguridad integral, y de que debe ser una función segregada, y de lo importante que es la formación y la profesionalidad, y del marco operacional en el que se deben mover los servicios externos, y de medidas de seguridad sobre sistemas, sobre aplicaciones…
Y esto entronca con la necesidad imperiosa (lo estamos viendo casi a diario en muchos de los proyectos en los que trabajamos) de que se implanten metodologías de desarrollo de software seguro, que integren los criterios de seguridad desde la etapa del diseño de requerimientos de cualquier aplicativo (véase el art. 19 del ENS), y con la necesidad imperiosa de que las empresas de desarrollo acrediten que efectivamente tienen en cuenta estos criterios al desarrollar sus servicios —de hecho el ENS viene a contemplar una reacción en cadena en cuanto a que las administraciones públicas deberán solicitar a sus proveedores evidencias de que gestionan de manera segura los servicios que prestan (ISO 27001, etc.)—.
Y esto —a mi modesto entender— no tiene nada que ver con si eso pasa porque no hay un colegio de ingenieros en informática que ejerza como tal, que si eso pasa porque los telecos están invadiendo las competencias de los informáticos, que si eso pasa porque estas empresas son “cárnicas” o no lo son… (reconozco que este último párrafo casi orienta el post a la sección GOTO…).
No tengo tiempo para extenderme más. Sólo quería compartir con ustedes esas dos o tres ideas que me han venido a la cabeza al leer la noticia que les he referido.
(N.d.E.: El error en la web de la DGT del que Samuel Parra se hacía eco justo ayer va por los mismos derroteros)
Hola Fernando:
Gracias por abrir debate sobre desarrollo seguro y el ENS. No parece que diga gran cosa relativa a seguridad en el ciclo de vida de desarrollo.
El artículo que mencionas (art. 19) parece más enfocado a __hardening__ que a desarrollo seguro.
Tenemos las breves medidas de seguridad sobre desarrollo:
* Desarrollo de aplicaciones [mp.sw.1]
* Aceptación y puesta en servicio [mp.sw.2]
Aunque son un punto de partida, creo que se podrían especificar más, ya que esta ambiguedad y generalidad frente a otras medidas mucho más concretas genera unas diferencias de alcance en las medidas similares a las que se presentan en la ISO 27002 (y es por eso que la odio, por cierto).
En esta línea, os animo a leer [este artículo][1] sobre las promesas rotas en cuanto a la ingeniería de la seguridad que justo he visto cuando leía tu artículo.
[1]: http://lcamtuf.blogspot.com/2010/05/security-engineering-broken-promises.html
Por cierto, que el ENS hace mucho hincapié en productos certificados (hay que promocionar los CC, supongo). ¿Os hace un GOTO sobre este punto? ¿Es la certificación la panacea? ¿Son los productos certificados mejores o sólo los que tienen detrás una empresa capaz de pagar la certificación? ¿Y los perfiles de protección, hasta qué punto pueden ser limitantes y, por lo tanto, reducir la efectividad de la certificación? ¿Y qué pasa con los productos de software libre que no pueden acceder a esta certificación?
Es cierto chmeee, el citado artículo del ENS está más orientado a la seguridad en la operación y explotación de los sistemas de información que a la seguridad en su desarrollo, tan solo el apartado a) parece querer insinuar que en su diseño se deben tener en cuenta criterios de seguridad que garanticen que el sistema tenga exclusivamente las funcionalidades previstas, y no otras.
En cualquier caso, y aun estando contigo en que tanto el ENS como la norma ISO 27002 son mejorables (¿qué no lo es?), es lo que tenemos, y como decía aquél, peor sería una patada en un ojo. Son referenciales, en un caso de obligado cumplimiento y en el otro no, pero son eso, referenciales y puntos de partida a partir de los cuales se puede construir. Es cierto que sobre todo el ENS pasa de puntillas por el tema del desarrollo seguro, y en este ámbito hay que buscar otros referentes como OWASP.
Interesante el artículo que propones. Por cierto, y al hilo de escribir un GOTO sobre el tema: ¿por qué no te animas? Estaremos encantados de recibir tu colaboración, no tienes más que ponerte en contacto con Manuel Benet, el editor de SecurityArtWork.
Un saludo.
Una violación de estas leyes:
[…]
Belén,
Como verás, he editado uno de tus comentarios y borrado los otros dos, por no tener absolutamente nada que ver con el post ni con la temática del blog. Creo que este no es el foro para presentar las reivindicaciones y protestas que comentas, justas o no, por lo que te ruego desistas de continuar en ello.
Gracias y un saludo.