28 septiembre 2007
El Esquema Nacional de Seguridad
La Ley de Acceso Electrónico de los Ciudadanos a los Servicios Públicos (Ley 11/2007, de 22 de Junio) regula, en términos generales, las condiciones que deberán cumplir las Administraciones Públicas para permitir el acceso electrónico a los servicios prestados, tanto por parte de los ciudadanos como entre las propias administraciones. Sin embargo, y pese a que el contenido principal de dicha Ley se centra en regular la "interoperabilidad electrónica", esta Ley también lleva a cabo un importante esfuerzo en tratar de garantizar la seguridad de los servicios electrónicos prestados por las administraciones.
Ya en el Artículo 1. párrafo 2. podemos leer que las Administraciones Públicas asegurarán "la disponibilidad, el acceso, la integridad, la autenticidad, la confidencialidad y la conservación de los datos, informaciones y servicios". ¿A alguien le suenan esos conceptos? ¿No recuerda este enunciado al contenido de cualquier Carta o Política de Seguridad de la Información de Alto Nivel de cualquier organización que disponga de ella?
La Ley habla de las distintas dimensiones de la seguridad de la información a lo largo de todo su articulado. Sin embargo, la parte más "jugosa" la podemos encontrar en el Artículo 41. párrafo 2., en el que podemos leer que "el Esquema Nacional de Seguridad tiene por objeto establecer la política de seguridad en la utilización de medios electrónicos en el ámbito de la presente Ley, y está constituido por los principios básicos y requisitos mínimos que permitan una protección adecuada de la información". ¿Puede recordar a una articulación clásica de las Políticas o Normativas de Seguridad de cualquier organización? Por supuesto que sí.
La propia Ley indica, en el párrafo siguiente, que dicho Esquema se aprobará por Real Decreto, y señala los participantes y supervisores previstos para su elaboración. Lamentablemente, la redacción de la Ley está en futuro, y pese a que la Ley es del verano, ya se sabe que en temas legales el tiempo transcurre muy lentamente. Sin embargo, creo que la propia aparición de la Ley ya debe ser motivo de satisfacción dentro del sector, y si los plazos que marcan las disposiciones finales de la propia Ley se cumplen apropiadamente, la redacción preliminar de dicho Esquema es posible que llegue bastante antes de lo previsto.
Pese a la importancia que pueda tener la aparición de un marco regulatorio completo en materia de seguridad de la información, no debemos olvidar que dicho marco sólo es aplicable a la administración electrónica. Es cierto que puede servir de "inspiración" para la empresa privada, pero hay que tener claro que previsiblemente el futuro Esquema deje de lado muchos ámbitos de actuación. Ya nos lo recordaba en su día el director de la revista SiC, de modo que no está de más tener en cuenta que este marco regulatorio es un marco de mínimos generales, y que siempre podrán aparecer exigencias adicionales que completen y refuercen los requisitos exigibles.
24 septiembre 2007
Gestión de perfiles: la clave de la seguridad
El primer tema que quiero tratar es la gestión de perfiles como piedra angular de la seguridad ligada al personal. Pero no gestión de perfiles desde un punto de vista técnico, sino gestión de perfiles desde el punto de vista de gestión de los recursos humanos.
El término perfiles puede ser ambiguo, así que prefiero hablar de los distintos aspectos que debemos gestionar en relación a las personas: funciones, roles, responsabilidades y privilegios. Vamos por partes.
La gestión de roles (o cargos, si se prefiere) es un aspecto presente en todas las organizaciones. Al menos, en apariencia. Todas las empresas tienen sus organigramas, mejor o peor definidos, y cada persona tiene su "título" dentro de la organización. Sin embargo, poca "gestión" suele haber en relación a estos roles: en general, los organigramas no se suelen revisar ni retocar demasiado (al menos, no como consecuencia de una revisión sistemática de los mismos).
La gestión de funciones suele ser un aspecto mucho más descuidado. En general, es poco habitual encontrarse con una definición completa de las funciones asociadas a cada rol, y si ni siquiera están escritas difícilmente podrán ser gestionadas adecuadamente. Quizás sea un rasgo cultural, tal como dejaba entrever Samuel Linares en su blog, pero el caso es que la carencia es clave desde el punto de vista de la seguridad. Cómo se pueden articular las medidas adecuadas para que cada persona preserve la integridad, confidencialidad y disponibilidad de la información que maneja en su día a día, si no está definido ese día a día? La solución de "café con leche para todos" acaba volviéndose en contra de la organización, tanto por exceso de presión normativa para unos como por reglas insuficientemente estrictas para otros. Pero no se puede ser más granular si no está establecida la vase sobre la que se deben aplicar las normas de seguridad...
La gestión de responsabilidades es el eterno caballo de batalla. Cuántas veces nos hemos encontrado con "marrones" que nadie quiere asumir? Y todo por que, unido a lo anterior, no se definen los roles encargados de ratificar determinadas decisiones, o de supervisar determinadas acciones. A río revuelto... Y ni siquiera las empresas que más se preocupan por estos temas suelen tener en cuenta dos aspectos clave: las responsabilidades delegadas lo deben estar formalmente (y "aceptadas" documentalmente), y la definición de responsabilidades se debe revisar periódicamente. Cuántas personas siguen siendo "responsables" de una tarea que realizaban en un puesto en el que ya no están?
Por último, tenemos la gestión de permisos o privilegios de acceso. En realidad no debería ser algo con entidad propia, ya que estos permisos no deberían ser más que la articulación tecnológica de los aspectos anteriores, pero desde el punto de vista técnico la tarea tiene un peso específico propio nada desdeñable. Los permisos de los usuarios, o más bien los permisos asociados al identificador lógico de cada persona, deberían ir en consonancia con las funciones y responsabilidades asociadas al rol que cada uno desempeña dentro de la organización. Y su revisión no debería ser más que la constatación de que ambos coinciden. Ahora bien: si todo lo anterior no está formalmente definido, contra qué se van a contrastar estos permisos de acceso? Difícilmente podrá nadie de Sistemas verificar si los permisos son correctos o no. ¿A quién corresponde llevar a cabo esta revisión? Evidentemente, a la empresa. Pero la pregunta es: ¿A quién, dentro de la empresa? Sencillamente, a quien tenga definida esa tarea entre sus funciones. Aunque claro, si el problema es que esa definición es la que falta...
En resumen, la revisión de funciones, roles, responsabilidades y permisos debe ser una tarea propia de la gestión de los recursos humanos, no de los departamentos técnicos. Sólo debería llegar a este área cuando exista una documentación formal, aprobada, revisada y mantenida contra la que contrastar dichos permisos. Y en caso de que no exista, la validación de privilegios de acceso debería ir escalando por el organigrama hasta llegar al máximo órgano competente... siempre que esté definido.
Alguien se preguntará que por qué no he citado ninguna herramienta de gestión de identidades, ni he hablado de metadirectorios, ni he mencionado en ningún momento un LDAP. Sencillamente, porque la gestión de perfiles es previa, y excede a cualquier tecnología, como acabo de señalar. ¿En cuántos proyectos de gestión de identidades se respeta esta premisa? ¿Cuántos proyectos de gestión del conocimiento tienen en cuenta estos aspectos? ¿Cuántos de ellos tienen un trabajo exhaustivo de definición de perfiles previo a la implantación de la herramienta de turno? Y claro, luego suele sorprender que muchas organizaciones sigan teniendo problemas de gestión de perfiles y usuarios tras la implantación de la super-herramienta de turno...
19 septiembre 2007
El problema interno
Sin embargo, como dice este artículo, no son necesarios los atacantes externos para que las empresas puedan sufrir graves incidentes de seguridad. De hecho, el error humano, los ataques internos de personal descontento, los errores de programación o los fallos de hardware son causas mucho más habituales de incidentes de seguridad que los ataques externos, y en muchos casos con repercusiones mucho mayores. De hecho, tal y como afirman en este artículo, uno de los principales quebraderos de cabeza de los responsables de seguridad actuales son los pen-drives, o memorias USB. Tanto desde el punto de vista de la extracción de información corporativa para beneficio propio como desde el relativo a los riesgos que puede suponer la pérdida de estos pequeños dispositivos con tan alta capacidad de almacenamiento.
¿Cómo se pueden evitar estos problemas? En general, mediante dos estrategias complementarias. La primera de ellas trata de gestionar los riesgos derivados del eslabón humano, el más débil de la cadena. Y no sólo mediante la formación, evidente para cualquier iniciado, sino sobre todo desde el departamento de recursos humanos, que debe desarrollar políticas de personal que traten de mantener "contentas" a todas las personas de la organización.
La segunda estrategia es complementaria, ya que se encamina a la gestión de los riesgos de componente técnico. Básicamente, y en línea con lo que refleja el artículo señalado inicialmente, hay que tratar de simplifircar la tecnología y tener en cuenta la seguridad desde el principio. Divide, asegura, y vencerás. La tecnología lo permite. Entonces, cuál es el problema? El de siempre: el coste. Queremos realmente hacer el esfuerzo de diseñar e implementar sistemas seguros? Compensa la inversión?
Precisamente los costes son uno de los principales problemas de los gestores de TI en todo el mundo, tal y como dice este artículo. Pese a que la seguridad de la información sea una de las prioridades en este ámbito, parece ser que el coste es excesivo. Además, ese mismo artículo refleja la aseveración inicial de que el riesgo interno no se percibe como tal, y desde mi punto de vista esta puede ser una de las causas del insuficiente apoyo directivo a la seguridad de la información del que también se quejan los gestores TI.
Cuál es, por tanto, la vía de actuación a seguir? Ambas estrategias de reducción de riesgos de seguridad de la información son complementarias, pero con la ventaja de que hasta cierto punto una puede cubrir las carencias de la otra. Aquello que no podemos lograr con tecnología quizás seamos capaces de conseguirlo con "mano izquierda" en materia de seguridad. Por tanto, será cuestión de cada responsable, una vez conocida la cultura empresarial, decidir qué combinación de estrategias adoptar a la hora de tratar de reducir los riesgos identificados para conseguir los fines deseados. Al fin y al cabo, cocinar es algo más que mezclar ingredientes. Y todos sabemos que la cocina es un arte...
17 septiembre 2007
Fiarse del entorno
- Las necesidades de almacenamiento crecen de forma importante.
- En general, las empresas están poco preparadas en caso de pérdida de datos.
- Uno de los principales retos para una buena gestión del almacenamiento parece ser la actualización tecnológica.
- Las decisiones de compra de soluciones de almacenamiento están influenciadas por el entorno.
La verdad es que si analizamos detenidamente el informe, el resultado puede ser más preocupante de lo que parece a priori. Sobre todo, si partimos de los dos últimos apartados.
La importancia del entorno en la toma de decisiones me parece preocupante. Máxime si la conjugamos con la actualización tecnológica como solución. Que me entero de que el vecino tiene un problema y se ha comprado un nuevo "juguete" para resolverlo? Pues yo también. Parece como si el criterio de decisión fuera "lo que hacen los demás", y sobre todo "lo que compran los demás". Un panorama peligroso si ahora ponemos en juego a los avispados comerciales que tratan de vender estos nuevos "juguetes", y que vienen contándonos que "al vecino le ha funcionado". ¿Qué profundidad de conocimiento tengo del problema del vecino? ¿Y de mi problema? ¿Es realmente cierto que a él le ha funcionado la solución? ¿Por qué motivos? ¿Seguro que a mí me sirve la misma solución? Y si es así... ¿Es la mejor solución para mi? ¿La relación coste-beneficio de esa solución es la que yo necesito? ¿Tengo una opción más eficiente?
La verdad es que fiarse tanto del entorno me parece peligroso. Y fiarse del entorno para nuevas compras, más todavía. El problema de fondo es que falta una reflexión profunda sobre las necesidades reales de mi organización. ¿Es cierto que mis necesidades de almacenamiento crecen tanto? ¿Qué almaceno, datos o información? Qué información necesito almacenar, y por cuánto tiempo? Necesito salvaguardarla? La gestión del almacenamiento puede llegar a ser un arte, pero una empresa que cuente con una buena gestión del almacenamiento se puede llegar a ahorrar MUCHO dinero. Y sobre todo, seguro que se puede ahorrar muchas inversiones ineficientes e ineficaces. Si es tan beneficioso, dónde está el problema? Sencillamente, en que para conseguir una buena gestión del almacenamiento necesitamos previamente una buena gestión de la información. No podemos ahorrarnos los backups diarios de una información que sólo cambia semanalmente si quien debe configurar dichos backups no conoce esa característica. Y esa situación se debe dar con toda la información de la organización...
En resumen, fiarse del entorno puede ser peligroso si no conocemos todos los datos, y siempre es más conveniente buscar colaboración en la propia organización que en los problemas del vecino. Al fin y al cabo, además de ahorrar espacio en disco estaremos ayudando a conseguir esa deseada alineación entre las TI y el negocio, aunque sea en el ámbito concreto del almacenamiento. Y seguro que, en el fondo, todos nos agradecen no tener que ampliar nuestra cabina de discos...
12 septiembre 2007
Buscadores y Datos Personales
Supongamos que tengo un buscador. En concreto, un buscador "patrocinado con publicidad personalizada" (textualmente). Que mi página principal de acceso a ese servicio web muestra un texto que dice que, si uso el servicio, estoy declarando haber leído y aceptado las condiciones de uso del mismo. Que ese texto es un link a las condiciones de uso en las que afirmo, entre otras cosas, que voy a registrar toda la información de búsquedas asociadas a cada identificador de usuario con el fin de proporcionarle una publicidad personalizada de acuerdo al perfil que demuestren sus búsquedas. Que esa información la guardo cifrada en mis servidores por un periodo de un año desde el día de su recogida y procesamiento, y que el usuario puede dirigirse a una dirección de e-mail de contacto para ejecutar sus derechos de acceso, rectificación, oposición y cancelación.
Y la pregunta es: ¿Incumple este buscador la LOPD? Estoy informando de la recogida de datos personales, el usuario está aceptando dicha recogida, tiene capacidad para ejercer sus derechos en relación a los mismos, la finalidad de la recogida es acorde con el modo de financiación del servicio, y además estoy conservando la información cifrada por si el perfil del usuario puede ser entendido como datos especialmente protegidos (nivel alto). Supongamos que, por otra parte, cumplo con los requisitos del Reglamento para ficheros de nivel alto. Sería legal mi situación?
Yo no soy un experto en leyes, y no puedo responder con rotundidad a la pregunta. Pero a priori tiene pinta de que la respuesta es que sí. Entonces, cuál es la causa real de la polémica en torno a estos casos?
Creo que el problema es que la polémica, más allá de los términos legales, está mal enfocada. Muchos de los argumentos que se leen en relación a este caso hacen referencia al "abuso" de los buscadores, a que pueden llegar a actuar como un "gran hermano". Sin embargo, a la hora de atacar a los buscadores, se utiliza la "vía legal" como arma. Y el problema es que, desde mi punto de vista, creo que es posible seguir ejerciendo esa función de "gran hermano" dentro de la legalidad. Quizás el ejemplo que he presentado no sea completo, ni puede que el más apropiado, pero tengo la sensación de que empresas del tamaño de las que están sujetas a la citada polémica son capaces de encontrar vías para seguir actuando del modo en que lo hacen actualmente y que dicha actuación sea completamente legal en términos de protección de datos. Al fin y al cabo, es famoso el refrán de "hecha la ley, hecha la trampa". Entonces, cuál es la vía?
En caso de que se quiera conseguir que este tipo de empresas cambie su modo de actuación, creo que la única vía de "protesta" realmente consistente es la del uso de argumentos éticos. Es cierto que en la sociedad actual hay veces en las que este tipo de argumentos no tienen demasiado peso, pero también es cierto que muchas de estas empresas basan gran parte de su poder en la imagen de marca. Y si la ética de las empresas se ve públicamente cuestionada, la marca probablemente se vea afectada, y por tanto la compañía en conjunto. Al fin y al cabo, la progresión creciente de los esfuerzos de las empresas en desarrollar la Responsabilidad Social Corporativa (RSC) sólo se justifica porque este tipo de relaciones son más reales de lo que parece. Por tanto, creo que llegará el tiempo en el que la ética recupere parte del valor histórico que ha tenido, y no sólo como una moda, sino como un elemento diferencial de valor de una compañía. ¿Cuándo será éso? Probablemente deba pasar mucho tiempo antes de que lo veamos, pero por el bien de la sociedad, espero que sea antes de lo que parece...
07 septiembre 2007
Troyanos gubernamentales
Hoy quiero comentar brevemente toda la serie de noticias que han ido apareciendo durante los últimos días en relación a la existencia y utilización de software espía por parte de algunos gobiernos. Y creo que un buen punto de partida para argumentar mi posición es esta noticia, que recoge una postura crítica ante esta idea.
En primer lugar, y como puntualización, creo que es incorrecto hablar de troyanos. Aquí hay spyware, sí, pero en ningún momento se afirma que se haga pasar por software lícito. Vamos, que no hay “caballo”, sólo “soldados” que se infiltran en la “ciudad”. Pero ya que es el término que se está utilizando, lo mantengo en el título.
Por otra parte, reitero mi postura de que el software es neutral. En este caso, estamos hablando de un software que se usa para monitorizar exhaustivamente equipos remotos. De aquí a que esta monitorización se use para hacer un seguimiento de la actividad del usuario sin que este sea consciente ya va un trecho, y sólo ahora llegamos a la finalidad del software. Socialmente se considera que dicha finalidad es ilícita, y es por eso los fabricantes de soluciones de seguridad tratan de eliminarlo. Ahora bien: es realmente ilícita esta actuación? Las recientes noticias parece que lo ponen en duda, porque en realidad lo que se acaba valorando es la intencionalidad de dicha monitorización: sólo es ilícita si no se lleva a cabo por el bien de la persona monitorizada (sin entrar en si dicho “espionaje” lo realiza un gobierno o una empresa, que también existe).
Cuál es el problema? Precisamente, la neutralidad del software. Nadie asegura que las mismas herramientas se sigan usando de acuerdo a las intenciones iniciales, ni que las puertas abiertas para unos (con fines teóricamente lícitos, al menos para el gobierno en cuestión) las puedan aprovechar otros con fines ilícitos. Qué postura deben adoptar los fabricantes de software de seguridad? No introducir firmas para el spyware “legal”? Crear listas blancas de firmas? Y si algún spyware “malicioso” consigue “parecerse” lo suficiente al spyware legal? Seguro que es más fácil que ocultarse…
En resumen, el caso es que no estamos ante un problema técnico, sino principalmente legal y ético. Las mismas acciones deben ser legales o ilegales por defecto en función de quién las ejecute? Es un tema que se debería resolver en entornos legislativos y jurídicos, y permitir (e incentivar) a los fabricantes de software de seguridad que, por defecto, sigan protegiendo lo mejor posible la actividad informática de cualquier persona, sin excepciones. Al fin y al cabo, ya es suficiente con tratar de no perder mucho terreno frente al malware, como para empezar a poner obstáculos en una carrera en la que la desventaja ya es significativa… sobre todo, mientras hacer negocio con el malware siga siendo tan asequible.
Actualización: Según un juez, parece que el spyware sí es spyware, y los fabricantes hacen bien en catalogarlo como tal. Mantendrán esa misma postura si el spyware es gubernamental en lugar de privado?
06 septiembre 2007
Diferencias entre ISO 27001 e ISO 27002
Cuando hablo de las diferencias entre ellas no me refiero sencillamente al hecho de que una (27002) sea un código de buenas prácticas y la otra (27001) una especificación, sino a la filosofía y alcance que tienen una y otra.
La ISO 27002 es una guía para, en distintos ámbitos, conocer qué se puede hacer para mejorar la seguridad de la información. Expone, en distintos campos, una serie de apartados a tratar en relación a la seguridad, Los objetivos de seguridad a perseguir, una serie de consideraciones(controles) a tener en cuanta para cada objetivo y un conjunto de "sugerencias" para cada uno de esos controles. Sin embargo, la propia norma ya indica que no existe ningún tipo de priorización entre controles, y que las "sugerencias" que realiza no tienen por qué ser ni siquiera convenientes, en función del caso en cuestión.
Por su parte, y no nos olvidemos de ello, la ISO 27001 habla de los controles de forma residual. El núcleo de la norma anterior queda reducido a un listado de objetivos de control y controles incluidos en un anexo (normativo, pero anexo). No aparecen en el cuerpo de la norma, porque en absoluto son la parte más importante. Porque lo que importa en esta norma es la gestión de la seguridad, en forma de SISTEMA DE GESTIÓN. Desde mi punto de vista, los controles forman parte del anexo más por "compasión" que por necesidad. Lo que importa en la ISO 27001 es que los riesgos se analicen y se gestionen, que la seguridad se planifique, se implemente y, sobre todo, se revise y se corrija y mejore. Pero claro, a la hora de la verdad no se "atrevieron" a dejar totalmente abierto, sin ningún tipo de guía ni mínimo, el modo de implementar o mejorar la seguridad de la información, y por eso establecieron, aprovechando la norma anterior, un listado de controles sobre los que seleccionar los más apropiados. Para facilitar la gestión de riesgos tanto al implementador como al auditor, ya que la norma anterior (27002) sólo establecía sugerencias, pero no requisitos. Al menos, eso creo yo.
Por qué intento dejar claras las diferencias entre una y otra norma? Porque en muchos casos a la hora de pensar en implementar un SGSI la gente piensa rápidamente en ponerse a "cumplir" los 133 controles del anexo, y tratar de cumplir con todas las "sugerencias" que da la ISO 27002 para cada control. Y se olvidan de que el objetivo de la ISO 27001, que es la norma que define cómo tiene que ser un SGSI, es precisamente el CONTRARIO: que la empresa sea capaz de priorizar y seleccionar controles en base a sus posibilidades y a sus necesidades/riesgos de seguridad.
Qué quiero decir con esto? Que es mucho más importante asegurar el respaldo de la dirección, el establecimiento de una metodología efectiva de mejora continua o la existencia de un comité de seguridad que el cumplimiento exhaustivo y la trazabilidad del control x.y.z en no-sé-qué entorno de producción. Con la ventaja adicional de que probablemente sea más barato conseguir lo primero que lo segundo (si es más fácil o más difícil ya entra en el pantanoso terreno de la cultura empresarial... ). Qué pensais vosotros?
03 septiembre 2007
Re-pensando la estrategia de recuperacion
Hoy quiero comentar uno de estos artículos, que invita a re-pensar la estrategia de recuperación ante desastres desde un punto de vista tecnológico. En concreto, el artículo propone diseñar una estrategia de recuperación ante desastres basada en un centro de respaldo configurado en alta disponibilidad con el principal, como soporte para cinco "estrategias":
- Resolver los problemas rápidamente: Gracias a una detección temprana de los incidentes, mediante el uso de herramientas de gestión de la configuración (centralizadas y multi-consola, se sobrentiende).
- Automatizar los procesos de recuperación: Mediante la utilización de sistemas en alta disponibilidad y fail-overs automatizados entre ambos centros.
- Testear los planes de recuperación: Sin necesidad de parar el centro primario y en menor tiempo, gracias a la existencia de soluciones de alta disponibilidad y gestión centralizada.
- Sacar el valor del centro de respaldo: Gracias a su uso "en condiciones normales" como solución de alta disponibilidad o entorno alternativo multi-propósito.
- Virtualizar las soluciones de alta disponibilidad y recuperación: Como solución para lograr una infraestructura de respaldo más barata y sencilla de gestionar en situaciones de crisis.
Sin entrar a valorar los pros y contras de cada una de estas estrategias, lo que es cierto es que uno de las mayores dificultades a la hora de definir la estrategia de continuidad suelen ser los costes asociados a una solución de este tipo. Por tanto, creo que el principal requisito que debemos contemplar en la gestión de la continuidad de negocio es el famoso cost-effectiveness. Sin embargo, no debemos de perder de vista que la gestión de la continuidad debe estar integrada con el negocio (propiamente dicho), y por tanto yo resaltaría la cuarta "estrategia": dar valor al centro de respaldo.
En esta línea, sin embargo, creo que una inversión moderada puede permitir el traslado de entornos (ya existentes) de alta disponibilidad, desarrollo o pruebas a un CPD secundario y la adquisición de una solución medianamente potente de gestión de discos y backups que permita su uso "dual", como solución de continuidad, en caso de necesidad. En muchos casos, esta vía (crear un centro de respaldo con elementos pre-existentes) suele ser más sencilla (de entender) y viable que la alternativa (crear un centro de respaldo, y luego dar "utilidad" a ese equipamiento).
La solución "definitiva" para la viabilidad de este tipo de soluciones suele ser, como ya dice la quinta "estrategia", la virtualización. De hecho, la apuesta por la virtualización no es algo exclusivo de este artículo, sino que otros muchos expertos la secundan, como en este (1-2-3) artículo. Por supuesto, con sus ventajas e inconvenientes. Pero la verdad es que, a día de hoy, la virtualización es una de las mejores soluciones a la carencia de hardware idéntico...