Mostrando entradas con la etiqueta Esquema Nacional de Seguridad. Mostrar todas las entradas
Mostrando entradas con la etiqueta Esquema Nacional de Seguridad. Mostrar todas las entradas
viernes, 4 de mayo de 2012 2 comentarios

La Informática es ley

Este post lleva unos meses ya cocinándose en mi cabeza desde que en una reunión de amigos informáticos nos pusimos ha hablar del rol de nuestra profesión en el siglo XXI. Las discusiones filosóficas sobre si la informática es un arte, una ingeniería, una ciencia derivaron en comentarios respecto al papel regulador de la actividad humana en nuestro día a día. A quien no le suena familiar ya la frase de "Disculpe pero el programa informático no me deja hacer esto o lo otro". 

Y realmente empieza a ser cierto que en muchas situaciones mandan los criterios de un ordenador que muestra un resultado o una decisión en una pantalla salvo que olvidamos o ignoramos que la máquina no toma decisiones, las tomó en su momento el desarrollador del código que programó esa aplicación para presentar esos resultados.

Como ya he comentado antes, estos meses ando liado con temas vinculados al Esquema Nacional de Seguridad y por ende la Administración electrónica. En estos momentos en los departamentos de TI de todas las Administraciones Públicas se andan cocinando proyectos que tienen por objetivo facilitar al ciudadano su relación con la Administración permitiendo interactuar telemáticamente con ella. Algo que ya vemos natural en el sector financiero es ahora un derecho establecido por la Ley 11/2007 que supuestamente debe suponer un impulso a la introducción de las tecnologías de la información en la Administración Pública.

Sinceramente debo ver este avance con cierta preocupación porque al menos por lo que voy encontrando a mi paso parece que ahora el derecho quedará definido por el código de programación de las aplicaciones con las que vayamos a tener que tramitar. Es cierto que los reales decretos de desarrollo de la Ley 11/2007 se han ido publicando de forma tardía pero ello no debiera justificar la ausencia de cumplimiento de todos ellos. Siempre hemos oído que el desconocimiento de la ley no exime de su cumplimiento. Sin embargo, parece que la Informática como tal, está por encima del bien o del mal y que puede obrar con libertad saltándose las restricciones que el mundo del derecho ha establecido mediante las regulaciones oportunas. De nada sirve que la legislación hable de cosas tan concretas como la firma electrónica, el expediente electrónico, regule cómo debe ser un documento electrónico para que sea considerado una copia auténtica de uno equivalente en papel, etc si no se le hace ningún caso. Y reflexionando al respecto creo que estas circunstancias se dan principalmente por cuatro factores:

  • Las áreas TI y sobre todo, el mundo del desarrollo no incorpora siempre los requisitos legales establecidos porque ignora en muchos casos cual es la reglamentación que afecta a la aplicación en concreto que se está desarrollando. Es cierto que en estos años el número de leyes y reales decretos es abundante pero nuestra profesión, como las demás, no es ajena al cumplimiento de la ley. En el caso del ingeniero en informática además la cosa se agrava cuando es precisamente el que debe tomar las decisiones respecto a la implementación de programas que obviamente también deben garantizar ese cumplimento legal. En consultoría en materia de seguridad uno de nuestros ejes sobre el que orientar lo que se debe garantizar es el cumplimiento de la legislación respecto a la protección de información. Y el espectro de leyes que pisan ya muy seriamente al área TI no es pequeño. Por nombrar las más relevantes, tenemos al menos estas leyes y reales decretos que tener en mente en todo momento:
    • Directiva 1999/93/CE del Parlamento Europeo y del Consejo, de 13 de diciembre de 1999, por la que se establece un marco comunitario para la firma electrónica.
    • Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal.
    • Ley 59/2003, de 19 de diciembre, de firma electrónica.
    • Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos.
    • Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal.
    • Real Decreto 1671/2009, de 6 de noviembre, por el que se desarrolla parcialmente la Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los servicios público.
    • Real Decreto 3/2010, de 8 de enero, por el se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica.
    • Real Decreto 4/2010, de 8 de enero, por el que se regula el Esquema Nacional de Interoperabilidad en el ámbito de la Administración Electrónica.
  • En los equipos de desarrollo normalmente no participan áreas de perfil jurídico que puedan asesorar o apoyar al área de programación a entender o interpretar correctamente las regulaciones establecidas. Esta ausencia de criterios por parte de personal especializado se suple con la buena intención o hacer del personal técnico de desarrollo que "interpreta a su manera" lo que la ley expresa, siendo muchas veces una visión distorsionada o no ajustada al objeto de protección establecida por la legislación. A ello también contribuye bastante que la redacción de la legislación anteriormente nombrada es en muchos casos ambigua e imprecisa en las definiciones de términos o en la propia redacción permitiendo todo tipo de licencias a la hora de programar lo regulado. Es necesario que estos proyectos son multidisciplinares y al menos en las fases de diseño y análisis de requisitos es necesario la visión del ingeniero en informática que sabe lo que se puede programar, la del jurísta que entiende lo que la ley pretende salvaguardar y la del bibliotecónomo que conoce bien los entresijos de la gestión y organización de la información para hacer un uso eficiente de los datos. Todos con un objetivo único y común, hacer que la aplicación proporcione la funcionalidad deseada con la máxima eficiencia posible, el menos consumo de recursos y sobre todo y fundamentalmente, garantizando la seguridad jurídica de la gestión en base a la robustez de la implementación por el nivel de cumplimiento de las regulaciones del ámbito tecnológico.
  • La gestión de proyectos TI cuando las decisiones técnicas se ven condicionadas por factores políticos son un lodazal que pringa a los buenos profesionales y donde ven a diario como son ignorados sus consejos o criterios. Para ejemplificar esta situación quiero recomendar leer el post Como el agua: ¿son las TICs una utility? de alguien que habla con conocimiento de causa y desde dentro de la casa.
  • La ausencia de supervisión y verificación del cumplimiento mínimo de garantías. A nadie nos sorprende que el más vulgar electrodoméstico o producto deba superar unas pruebas mínimas que  verifiquen la seguridad industrial del proceso de fabricación. Algo que exigimos a cualquier tipo de objeto ni por asomo se nos pasa por la cabeza que sea atribuible al mundo del software. ¿Y por qué no? Obviamente enlentecería el proceso de desarrollo pero ¿para que queremos hacer las cosas rápido si las hacemos mal y luego hay que rehacerlas y empezar de nuevo? 

Y aunque el tono del post sea algo pesimista, quiero destacar que si hay gente que está haciendo las cosas bien, gente que piensa mucho primero, diseña y define lo que es necesario establecer, lo documenta y después se pone manos a la obra a poner ladrillo tras ladrillo hasta lograr el resultado final. El problema es que esos ejemplos son "poco conocidos" y su labor poco entendida. Es necesario tener completamente identificado cual es el problema a solucionar para poder resolverlo de forma correcta. Y como lo mejor siempre es un buen ejemplo, quiero referenciar el excelente trabajo de Nacho Alamillo en lo que denomina su "gestión documental segura" donde ha establecido un mapa conceptual con todas las piezas del puzzle que hay que resolver para poder hacer real que las aplicaciones efectivamente garanticen la seguridad jurídica establecida por las leyes. Tal como pinta en su Web, las elementos que hay que relacionar con cohexión y consistencia son los siguientes:


Nacho, creyente del modelo de licencia Creative Common, ha colgado su formalización de la política de gestión documental segura en este enlace y nos permite a todos consultar cada una de las piezas que forman parte de la complejidad regulatoria y técnica que hay que definir para tener un puzzle consistente y robusto, de forma que no quede ninguna duda de cumplimiento legal. Las piezas del puzle que toda solución de e-Administración debe implementar debe definir, documentar y resolver cuestiones de diferentes ámbitos y dominios, vinculados a la seguridad, a la criptografía, a la gestión documental, al derecho administrativo de forma que en su conjunto, todos los mecanismos proporcionen el cumplimiento legal y la garantía de que el trámite en soporte electrónico proporcionará un nivel de confianza similar al trámite en soporte papel. 


Os animo a recorrer el mapa conceptual que he referenciado en el enlace y a leer las normas e instrucciones técnicas que lo componen. Y aquellos que leáis esto y estéis metidos en proyectos de e-Admin, hacedse la siguiente pregunta ¿Cuantas piezas del puzzle habéis identificado y definido?
 Como he leído hoy en un blog, "“Si no puedes pagar el coste de hacer las cosas bien, espera a que te llegue la factura por hacerlas de forma mediocre”. 





viernes, 3 de febrero de 2012 6 comentarios

¿Una nube para la AGE? Con Google Apps hay que pensarlo dos veces.

Hoy a través de Twitter he leído dos post que han iniciado el título de este artículo. El primero titulado ¿Y si los funcionarios usaran Google Apps? plantea tras noticia del BBVA y su migración a Google Apps si la Administración General del Estado podría plantearse un escenario similar. En este artículo se referencia a su vez a otro más extenso titulado Una nube para la Administración General del Estado (AGE), un análisis más exhaustivo de los pros y contras que puede tener la unificación mediante la cloud computing de los recursos de la Administración General del Estado. 
Mi post pretende complementar y completar este análisis aportando algo de luz en las cuestiones que afectan a la seguridad de la información y en este caso, el papel crucial que puede tener esta cuestión en la decisión de externalizar hacia una nube "pública" pero propiedad de una empresa "privada" basada en Google Apps.

En primer lugar aclarar que en cierta forma comparto los argumentos principales que llevan a pensar en la homogeneización y centralización de recursos TI para dar servicio a la AGE, por las cuestiones planteadas en el propio blog y que a continuación cito:
  • Ubicuidad: el acceso a los servicios está disponible desde cualquier terminal: PC, SmartPhone (iPhone incluido), Tablet (iPad incluído), …. Se puede usar en cualquier momento y lugar en el que exista una conexión a Internet/Intranet.
  • Inmediatez: El despliegue de la solución es muy rápido, no requiere reformas o adaptaciones de los sistemas existentes, y el periodo de formación y adaptación de los usuarios es muy corto, pues muchos de ellos ya conocen y usan las herramientas de Google
  • Flexibilidad: una de las características más interesante del SAAS es que el servicio y el cliente está constantemente actualizado de forma completamente transparente. Las nuevas versiones aparecen automáticamente al usuario cuando están disponibles, generalmente con la opción de “seguir con la versión antigua” si en ese momento tenemos prisa y no queremos aprender la nueva funcionalidad.
  • Seguridad: Los servicios contratados se acogen a la legislación sobre protección de datos española y europea mediante el acuerdo de “Puerto Seguro” (Safe Harbor) a la cual está actualmente adherido Google. Para proceder a implementar este proyecto, el BBVA ha recibido la autorización del Banco de España, como es preceptivo.
  • Y, por supuesto, Coste. Diversos estudios fijan en torno a los 100 dólares por año el coste de cada buzón de correo corporativo cuando se implementa con medios propios, pero para volúmenes de usuarios a partir de 10.000. Sin embargo, si el número de usuarios desciende por debajo de 10.000, los costes aumentan rápidamente. Así, para 100 usuarios un estudio calcula un precio de más de 300 dólares al año. Frente a ello, la solución de correo corporativo de Google tiene un coste de alrededor de 40 € por usuario y año.
  • Y no olvidemos que esta solución no es sólo correo. Incluye también todas las herramientas de ofimática en línea de Google: Documentos, Hoja de cálculo, Presentaciones. A la hora de comparar costes, debemos poner en el debe de la solución in-house el coste de adquisicion y amortización de las herramientas ofimáticas usadas en la casa. Por no hablar también de otras posibilidades como el chat, audio y video conferencia en línea incluidas en la solución.
De todos estos puntos a favor, el que posteriormente cuestionaré es el de la seguridad tratando de justificar el por qué. En el mismo texto y cuando se reflexiona sobre los contras de esta solución, de nuevo la seguridad aparece en el centro de la cuestión.
  • En primer lugar, están las cuestiones de la seguridad de la información y de la disponibilidad del servicio. Estos son las principales pegas que se pueden poner a esta solución basada en nube pública, y precisamente los principales argumentos a favor de una nube privada.
  • Con respecto a la seguridad de la información, ¿es suficiente con la que proporciona “Safe Harbor”?. En otras palabras, ¿podemos dormir tranquilos los responsables de informática sin saber exactamente dónde están los datos?. No soy un experto, pero parece que la cobertura legislativa de puerto seguro es o debería ser suficiente también para la aplicación de estos servicios en la Administración Pública española.
  • Además, la gestión, control y validación de usuarios no se externaliza: puesto que se utiliza un servicio LDAP interno de la AGE, el proveedor de servicios no podrá, aunque quiera, crear o modificar cuentas de usuario. Todo el acceso está bajo el control de los sistemas de información propios de la AGE.
  • Con respecto a la disponibilidad y continuidad del servicio, estamos hablando fundamentalmente de un SLA y del grado de confianza que nos ofrece la empresa proveedora del servicio de cumplir un SLA. A este respecto, no olvidemos que cualquier solución de nube privada va a depender también de los SLA que se contraten y de cómo esos SLA se aplican en la práctica. De modo que, en este aspecto, para mí, hay empate.
  • Existe también la cuestión del archivo y la recuperación de los datos, y, llegado el caso, de la transición del servicio a otro posible proveedor. Aquí también nos encontramos con que, tanto en las soluciones de nube privada como en las de nube pública, son cuestiones a resolver. No es que estén muy claras, pero no veo en ellas un argumento de peso a favor de una u otra solución.
  • Pero por otro lado, las soluciones de nube privada son por lo general más caras y más lentas de poner en marcha, y sobre todo, menos escalables. El momento en el que empiezan a ser efectivas las ventajas de la nube privada llegan mucho más tarde en el cronograma proyecto que en el caso de l nube pública, la cual resulta eficaz y es escalable desde la primera instalación. Por ello, el riesgo técnico/económico para el proyecto de adoptar una nube pública es muy inferior al de la nube privada, lo que para mi decanta definitivamente el peso de la decisión a favor de la nube pública.


Hecha la introducción ahora voy a intentar expresar mi punto de vista al respecto. 

Primera cuestión: ¿por qué Google debe tener acceso a datos de funcionarios y españoles?

Creo que uno de los elemento esenciales que hay que plantearse en este asunto es qué ocurre con la información cuando se procesa en un entorno tradicional ofimático y qué ocurre cuando se procesa en Google Apps. En un entorno ofimático tradicional los datos se recogen, procesan, generan unos resultados, se almacenan o se envían hacia otros agentes relacionados con el tratamiento. Los procesos de transformación operan simplemente sobre los datos en cuestión afectados por el trámite administrativo. Cómo mucho se generan otros metadatos vinculados a la propia gestión pero todo queda en el Organismo responsable de la tramitación.
Sin embargo, cuando la información se procesa con Google Apps las cosas son diferentes. En el discurso filantrópico de la empresa americana se insiste en la necesidad de mejorar el servicio al usuario, de facilitarnos la vida y tanto soniquiete parece hacernos olvidar un aspecto muy importante del asunto: EXAMINAN E INDEXAN TODOS LOS DATOS PROCESADOS. Obviamente antes de hacer una afirmación así te tenido que buscar un poco cuales son las condiciones del servicio en este caso de Google y dado que esta empresa en esta materia es transparente, podemos encontrar en la FAQ de Google Apps la respuesta.
Privacy
Who owns the data that organizations put into Google Apps? 
When can Google employees access my account?
Who can gain access to my Google Apps administrative account? 
Who can gain access to my end-users' accounts? 
Does Google give third parties access to my organization's data? 
What kind of scanning/indexing of user data is done? 
In order to provide some of the core features in Google Apps products, our automated systems will scan and index some user data. For example:
  • Email is scanned so we can perform spam filtering and virus detection.
  • Email is scanned so we can display contextually relevant advertising in some circumstances. (Note that there is no ad-related scanning or processing in Google Apps for Education or Business with ads disabled)
  • Some user data, such as documents and email messages, are scanned and indexed so your users can privately search for information in their own Google Apps accounts.
In other words, we only scan or index user content in Google Apps in order to provide features that will directly benefit users, or to help us maintain the safety and security of our systems. Except when your users choose to publish information publicly, Google Apps data is not part of the general google.com index.
It's important to note that our scanning and indexing procedures are 100% automated and involve no human interaction. For complete information, see our detailed Privacy Policy, Privacy Principles, and our Google Apps Terms of Service (Google Apps, Google Apps for Business, Google Apps for Education).
Por tanto, primera cuestión ¿Debe el Estado Español permitir meter las narices a una empresa extranjera en la información que procesa para satisfacer sus gestiones administrativas? Además, acabamos de sufrir estos días, con el cambio de política de privacidad de Google otro hecho relevante. De forma unilateral se modifican las políticas de privacidad y se imponen como las lentejas: "si quieres las tomas y si no, las dejas". Sin embargo, moverse de sistema de información o cambiar los hábitos del usuario no es tarea fácil ni que pueda ser asumida de un día para otro. Y esta vez nos dan un mes de plazo porque "La nueva Política de privacidad y las nuevas Condiciones de servicio de Google entrarán en vigor el 1 de marzo de 2012. Si decides seguir usando Google una vez que se haya producido el cambio, lo estarás haciendo con arreglo a la nueva Política de privacidad y a las nuevas Condiciones de servicio."


Segunda cuestión: ¿Incumple Google la legislación en materia de protección de datos?

Esta segunda pregunta afecta esencialmente a la privacidad de los ciudadanos pero en esta cuestión, Google tiene resuelto el problema con la firma del acuerdo Safe Harbour. Sin embargo, ¿qué supone firmar ese acuerdo? De nuevo hay que rebuscar un poco para encontrar la página del Ministerio de Comercio americano y hallar los términos a los que se refiere dicho acuerdo. Básicamente que se respetan los principios generales de protección de datos del marco europeo, es decir, se cumplen y garantizan los siguientes derechos:
Organizations must comply with the seven Safe Harbor Privacy Principles, which require the following: 
Notice 
Organizations must notify individuals about the purposes for which they collect and use information about them. They must provide information about how individuals can contact the organization with any inquiries or complaints, the types of third parties to which it discloses the information and the choices and means the organization offers for limiting its use and disclosure.
Choice 
Organizations must give individuals the opportunity to choose (opt out) whether their personal information will be disclosed to a third party or used for a purpose incompatible with the purpose for which it was originally collected or subsequently authorized by the individual. For sensitive information, affirmative or explicit (opt in) choice must be given if the information is to be disclosed to a third party or used for a purpose other than its original purpose or the purpose authorized subsequently by the individual. 
Onward Transfer (Transfers to Third Parties) 
To disclose information to a third party, organizations must apply the notice and choice principles. Where an organization wishes to transfer information to a third party that is acting as an agent, it may do so if it makes sure that the third party subscribes to the Safe Harbor Privacy Principles or is subject to the Directive or another adequacy finding. As an alternative, the organization can enter into a written agreement with such third party requiring that the third party provide at least the same level of privacy protection as is required by the relevant principles. 
Access 
Individuals must have access to personal information about them that an organization holds and be able to correct, amend, or delete that information where it is inaccurate, except where the burden or expense of providing access would be disproportionate to the risks to the individual's privacy in the case in question, or where the rights of persons other than the individual would be violated.
Security 
Organizations must take reasonable precautions to protect personal information from loss, misuse and unauthorized access, disclosure, alteration and destruction. 
Data integrity 
Personal information must be relevant for the purposes for which it is to be used. An organization should take reasonable steps to ensure that data is reliable for its intended use, accurate, complete, and current. 
Enforcement 
In order to ensure compliance with the safe harbor principles, there must be (a) readily available and affordable independent recourse mechanisms so that each individual's complaints and disputes can be investigated and resolved and damages awarded where the applicable law or private sector initiatives so provide; (b) procedures for verifying that the commitments companies make to adhere to the safe harbor principles have been implemented; and (c) obligations to remedy problems arising out of a failure to comply with the principles. Sanctions must be sufficiently rigorous to ensure compliance by the organization. Organizations that fail to provide annual self certification letters will no longer appear in the list of participants and safe harbor benefits will no longer be assured.
To provide further guidance, the Department of Commerce has issued a set of frequently asked questions and answers (FAQs) that clarify and supplement the Safe Harbor Privacy Principles.
Realmente el cumplimiento de todos estos principios garantizan los requisitos establecidos por la LOPD pero sólo amparan a Google a tener nuestros datos con determinadas garantías y condiciones.  Aun así, la cuestión principal es que Google tendría los datos de los funcionarios que acceden a los sistemas y de los ciudadanos españoles que aparezcan en los documentos que éstos intercambien.

Google en este caso ejerce con un gran encargado de tratamiento que garantizará al Responsable del fichero, en este caso la AGE, todas aquellas cuestiones exigidas por la LOPD. Pero aquí la pregunta es, ¿Debe un ciudadano, por el hecho de tener que realizar un trámite con la AGE tolerar que Google tenga acceso a cierta información sobre su persona porque van a ser empleados en su tramitación recursos de la empresa americana? ¿Debe un funcionario tolerar lo mismo? 
No debemos confundir cumplir con la LOPD con el hecho de que el tratamiento de la información sea pertinente. Imaginemos que un Ayuntamiento usa Google Apps para la gestión de las multas de coche. En el manejo de los documentos ofimáticos necesarios para la gestión administrativa, aparte de la propia información sobre el infractor, el vehículo, la cuantía, la notificación, en los servidores de Google se van a indexar palabras vinculadas al dueño de la cuenta (el funcionario que tramita) y no sabemos si también asociadas al posible infractor (aquí no puedo ir más allá porque desconozco si Google puede vincular los datos escaneados a usuarios identificados en los propios documentos)

En este caso, este "encargado de tratamiento" va a hacer cosas que no están justificadas por la finalidad principal del fichero declarado pero que son intrínsecas al uso del servicio. Como hemos visto antes, toda documentación procesada es escaneada e indexada de forma automatizada. Y esa cuestión, vinculada al hecho de pensar que son tramites de la Administración General del Estado no me hace mucha ilusión. No entiendo por qué una empresa extranjera debe conocer tanta meta-información de los procesos internos de gestión administrativa de un país aunque cumpla con la legislación en materia de protección de datos. Y mucho menos con la nueva política de privacidad, donde lo que pretenden es reunir información parcial de cada uno de los servicios que emplea un usuario para hacer un único cubo que permita "inferir" o "anticipar" hábitos de consumo, productos o compras que potencialmente el usuario esté pensando hacer.


Tercera cuestión: ¿Garantiza la seguridad de la información?

Esta es quizás la pregunta mas compleja. ¿Qué debemos entender por garantizar la seguridad? ¿Protección de las infraestructuras? ¿En qué plano de la seguridad, el operativo? 
La infraestructura de Google estoy seguro que resuelve los aspectos más básicos de la seguridad de la información en relación a la protección de ubicaciones físicas, seguridad lógica, prevención de intrusiones, continuidad de negocio, etc. Es más, como se comenta en el blog eFuncionario, cumple con FISMA que es más exigente que ISO 27001.

La cuestión aquí no es la seguridad operacional sino la seguridad estratégica de un País que pone en manos de un tercero (externo y americano) parte de los recursos TI esenciales para proporcionar servicios básicos considerados estratégicos para el buen funcionamiento del estado. Y aquí es también curioso el planteamiento de Google. Efectivamente, se han preocupado de cumplir FISMA porque es la normativa del Estado Americano para poder garantizar los requisitos del Gobierno americano en materia de seguridad. Obviamente esta normativa está pensada por su Gobierno para la protección de sus intereses. Además, es muy curioso ver como en la explicación de los temas de seguridad para "Google Apps for Government" se dicen cosas como esta:
Meeting unique government requirements
Google Apps for Government provides segregated systems for our US government customers. Government customer data is stored in the US only. This "community cloud" – as defined by the National Institute of Standards and Technology – is available now to any federal, state or local government in the United States.
Google, como empresa americana que es, está diseñando y pensando en salvaguardar los intereses de su país, y por tanto, satisface completamente las necesidades específicas garantizando que para el Estado Americano, esa "Nube es privada" pero gestionada por Google. 

¿Qué ocurre cuando es el Estado Español el que usa esa infraestructura? Pues seguramente que nuestros datos no se almacenan en nuestro país sino en el suyo. Por tanto, la gran cuestión es ¿Por qué el Gobierno Español debe aceptar una protección inferior de la que el Gobierno americano exige a sus propios datos?
¿Por qué ellos no permiten que los datos del estado salgan de su país y los españoles tenemos que tolerarlo? ¿Qué me importa a mi SU FISMA si lo que aquí necesitamos que se cumpla es NUESTRO R.D. 3/2010 del Esquema Nacional de Seguridad?

Por tanto, en este tercer punto no debemos confundir que las instalaciones estén bien protegidas y adecuadamente gestionadas con que eso sea suficiente para garantizar los requisitos de seguridad que un Estado. Se debe tener en cuenta el plano estratégico  a medio y largo plazo antes de hacer un movimiento como el de migrar la AGE a Google Apps, porque además el camino de retorno no debe ser nada fácil. El BBVA como empresa privada puede hacer lo que sus dueños, accionistas y clientes toleren o permitan. El Estado debe atender al bien común de sus ciudadanos y en ese contexto, las decisiones no son tan sencillas.

Cuarta cuestión: ¿Y qué ocurriría en caso de conflicto España-EEUU?

Esta es quizás la pregunta menos relevante pero los que nos dedicamos a seguridad siempre debemos posicionarnos en los escenarios donde las cosas no funcionan bien, donde lo que se plantean son amenazas holísticas de cualquier ámbito y envergadura. Aquí para contestar sólo hay que leer lo que los propios americanos explican en su manual de operación de información (information warfare). Tal como explicó el blog Aeropago21 que cito a continuación, su estrategia está segmentada en diferentes niveles y estrategias que comprenden los siguientes puntos:
Dentro de la Guerra de Información esta doctrina define cinco núcleos básicos de capacidades, entre los que se encuentra tanto las ciberoperaciones como otras operaciones de corte más tradicional. Son las PSYOPS, la OPSEC, el MILDEC, la EW y las CNO.


Las PSYOPS, Operaciones de Guerra Psicológica (Psychological Operations), suponen el uso de propaganda para influir en las opiniones y comportamiento normalmente del enemigo pero también de aliados o elementos neutrales. Operaciones clásicas de PSYOPS son el uso de panfletos, transmisiones de radio o TV, etc. con el objetivo de desmoralizar al enemigo.


La OPSEC, Seguridad Operativa (Operations Security), se dedica a identificar que acciones propias pueden ser observadas por el enemigo y hasta qué punto este puede obtener inteligencia de las mismas. Así mismo la OPSEC también se encarga de definir y adoptar medidas para impedir esa recolección de inteligencia.


El MILDEC, Engaño Militar (Military Deception), engloba las tareas encargadas de facilitar al enemigo indicadores falsos que le hagan llegar a conclusiones erróneas sobre la fuerza, intenciones y capacidades propias. Un ejemplo histórico de MILDEC seria la Operación Fortitude durante la segunda guerra mundial con el objetivo de desviar la atención del desembarco sobre Normandía hacia un supuesto desembarco en el Paso de Calè.


La EW, la Guerra Electrónica (Electronic Warfare), implica el dominio del espectro electromagnético. Que incluye tanto la monitorización de las emisiones del enemigo como el uso de medios que van desde perturbadores a misiles anti-radar para limitar su utilización al contrario. Un ejemplo histórico de Guerra Electrónica seria la conocida como Battle of the Beams, también ocurrida durante la segunda guerra mundial, y que se centro en la utilización de sistemas de navegación aérea para facilitar el bombardeo alemán sobre Inglaterra, y los exitosos esfuerzos por interferir y falsear estas emisiones por parte de los ingleses.

  

Las CNO, Operaciones en Redes de Computadoras (Computer Network Operations). Las CNO se derivan de la creciente utilización de computadoras en red y sistemas de información por parte de organizaciones civiles y militares. Las CNO, junto con la EW, se utilizan para atacar, engañar, degradar, interrumpir, denegar, explotar la infraestructura del enemigo y defender la propia.
En un escenario de Ciberguerra estaríamos jodídos porque les hemos simplificado su actuación llevándonos todo a su país y sus infraestructuras.

La gente de PSYOPS podría "envenenar contenidos" modificando los documentos ofimáticos depositados en Google Apps. No debemos olvidar que es una empresa americana y que en caso de conflicto se someterá por completo al Estado. Y si se incumple alguna legislación, articulan rápido una Patriot Act y ajustan lo que sea necesario.

La gente de OPSEC se dedica a vigilar el tráfico de red cuyo origen sea España y destino los servicios de Google Apps.

La gente de MILDEC se dedica a jugar con los anchos de banda en la red, cortando y restableciendo el suministro cuando les apetece.

La gente de EW no tiene mucho que hacer porque ellos tienen ya el control de todos los recursos.

La gente de CNO sólo tienen que cortar el canuto de conexión desde España hacia sus servidores y estamos todos incomunicados y sin acceso a la información (Y ni siquiera su backup).

¿Muy paranóico y excéntrico, verdad? Que se lo cuenten a la empresa petrolera PDVSA cuando fue bloqueada a través de ataques informáticos provocando el "caos total" en Venezuela por el corte del suministro de petróleo al país. Los venezolanos elaboraron un documental conocido como "El cerebro de PDVSA" donde con demasiada carga política cuentan la realidad de unos hechos verídicos, el boicot americano mediante el sabotaje de los sistemas de información de la empresa más importante de Venezuela. El documental puede verse en Youtube en estos tres enlaces:

Conclusión final
El presente texto no quiero que sea visto como una oposición frontal a la cloud en la Administración General del Estado, todo lo contrario. Nube SI pero bajo control completo del Gobierno. Tenemos un grave problema en el área TI y es que nos estamos quedando atrás en la competencia por hacerse con los servicios tecnológicos en la Nube a nivel mundial. Lo que está en juego cuando hablamos de subcontratar Google es también parte del PIB, son puestos de trabajo que se van hacia el pueblo americano en vez de quedarse aquí, es mano de obra cualificada que no encontrará empleo porque se habrán elegido a empresas extranjeras con empleados con similar calificación pero que invirtieron en las infraestructuras en el momento adecuado. Por tanto, los motivos por los que aparece la "nube" en el contexto de la AGE son muy "loables" y "deseables" pero los medios para lograrlos deben ser controlados y controlables. El problema para poder pensar en la centralización y unificación de recursos es simplemente político. La filosofía aplicada hasta la fecha no ha pasado por un pensamiento estratégico, unificador y de interoperabilidad completa porque cada "reino" ha querido mantener su cuota de poder. No tiene sentido que las aplicaciones destinadas a atender a ciudadanos iguales sean diferentes por regiones, pero el problema previo es que las gestiones administrativas no son idénticas tampoco. Esa filosofía de por cada problema, determinar como mínimo 17 soluciones es un sinsentido y una perdida de productividad y operatividad a toda cosa, que lastra nuestro futuro.

Sin embargo, un Estado, por la importancia estratégica que tiene el area TI no puede pensar en poner toda esa gestión en manos de terceros países  porque además hemos visto que los propios americanos no lo hacen. Además, me llama mucho la atención el cambio de pensamiento que se observa y la inocencia con la que se juzga a Google frente a otras empresas. Si poníamos hace años el grito en el cielo por emplear tecnologías Microsoft en los sistemas operativos y aplicaciones porque era "código propietario cerrado" que podía tener cualquier cosa, ¿Por qué ahora tenemos que ser menos desconfiados con Google que pone también código pero que además te dice claramente que va a escanear e indexar toda la información? ¿Por qué es Google más inocente que Microsoft? ¿Porque claramente lo cuenta y lo explica?





miércoles, 25 de mayo de 2011 0 comentarios

Cumplimiento del Esquema Nacional de Seguridad con tecnologías Microsoft

Hoy tengo buenas noticas. Vía el twitter de Hector Montenegro me he enterado que Microsoft, como viene siendo tradicional respecto al cumplimiento legal, ha publicado un excelente libro (Descargable de forma gratuita en la Red en este enlace ) sobre cómo garantizar el cumplimiento del R.D. 3/2010 de desarrollo del Esquema Nacional de Seguridad mediante tecnologías Microsoft.



A falta de poder realizar una lectura en profundidad que ya es mi primera tarea en el To-do de estos días, por lo que he podido mirar por encima, tiene muy buena pinta. Precisamente llevo este último mes completamente sumergido con el ENS elaborando un plan de adecuación y hoy habíamos terminado el diagnóstico diferencial del grado de cumplimiento siguiendo la guía 808 - Verificación del cumplimiento de las medidas en el Esquema Nacional de Seguridad. Este libro va a ser de gran ayuda seguro porque muchas de las medidas que son completamente razonables siempre plantean problemas de implementación. Suele ser habitual encontrarse en AA.PP. también que la gestión de usuarios y equipos esté delegada en Directorio Activo por lo que el libro va a resolver muchas cuestiones técnicas a muy bajo nivel.

En mi caso, entiendo que para elaborar el informe de deficiencias es necesario que la Organización valore, siguiendo la guía de auditoría y no la guía de implantación, cual es el porcentaje de cumplimiento, con el objetivo de generar un plan de actuación que logre implantar las medidas al 100% generando así las evidencias suficientes para justificar el cumplimiento. La sensación general cuando hablamos de seguridad de la información en AA.PP. es que falta un largo camino por recorrer. En general, cuando cuentas las medidas de seguridad todo el mundo las valora como razonables, deseables, etc... pero son consideradas más deseos que requisitos. Además, por desgracia, la seguridad de la información no cuenta como área con personal propio y estas movidas o caen a la gente de sistemas o a la gente de comunicaciones, personas que ya de por si tienen a sus espaldas bastante trabajo. A ello se suma la actual coyuntura económica que pone bastante dificultades a la viabilidad de los proyectos necesarios para que el cumplimiento sea garantizado.

En cualquier caso, hoy toca alabar a Microsoft por esta excelente iniciativa que va a facilitar mucho a los responsables de TI de muchas organizaciones el resolver la problemática relacionada con el cumplimiento. Por desgracia los consultores les decimos lo que habría que hacer y les asesoramos en cuales son los motivos y los objetivos a lograr. Microsoft como fabricante además les va a decir en este libro cómo lograrlo y hacerlo real.

Quien a estas alturas no tenga muy localizado de qué estoy hablando, os dejo también el enlace a la Web del Centro Criptológico Nacional donde se están publicando las diferentes guías de ayuda a la puesta en marcha del CCN.

Al Centro Criptológico Nacional también hay que alabarle el esfuerzo por concretar y asesorar a las AA.PP. en el duro camino de implantar seguridad de la información. En este caso además, el CCN no ha permitido con la publicación de estas guías que exista ambigüedad interpretativa y ha marcado unas directrices claras respecto al qué hacer y por qué. En algunas organizaciones se ven estos temas como de otra galaxia pero al igual que la LOPD, esto es legislación y por tanto, de obligado cumplimiento.
 
;