No te defiendas. Recupérate

Reconozco que últimamente no me prodigo mucho en el blog. La verdad es que llevo una temporada bastante ocupado... pero hoy quiero compartir con todos vosotros uno de los temas que me están manteniendo ocupado estos últimos tiempos.

Los que leéis el blog habitualmente ya sabréis que llevo bastante tiempo dándole vueltas a la idea de que la seguridad, tal y como se plantea a día de hoy, está condenada al fracaso. A lo largo de la historia hemos levantado muros, portado escudos, instalado firewalls o desplegado antivirus con el fin de protegernos frente a los ataques... sabiendo que, tarde o temprano, nuestras defensas iban a ser inevitablemente vulneradas. Día tras día comprobamos eso de que la seguridad total es imposible... y pese a todo nos seguimos empeñando en tratar de alcanzarla.

Frente a este planteamiento, un poco ilógico si lo pensamos fríamente, quiero abogar por un cambio total de paradigma. Sabemos que los incidentes de seguridad son inevitables. Algunos serán leves, otros más graves, y unos pocos requerirán, por su extrema gravedad, la activación de nuestros planes de contingencias. ¿Y si tomamos esta situación como punto de partida para nuestro planteamiento frente a la seguridad?

La propuesta se resume en el título del post: dejemos de centrar nuestros esfuerzos en evitar lo inevitable, y enfoquémoslos en minimizar su impacto. Asumamos que vamos a tener incidentes de seguridad, y tratemos de garantizar que, pase lo que pase, el daño que provoquen sea mínimo. Orientemos nuestras medidas de seguridad hacia la reducción de la criticidad de los propios activos, en lugar de dedicar recursos a preservarla.

La teoría dice que los incidentes de seguridad pueden afectar a la disponibilidad, a la integridad o a la confidencialidad de nuestros activos. Pero en la práctica esto se reduce a una casuística muy sencilla: podemos perder (porque se paran) nuestros servicios, podemos perder (porque desaparece o porque se corrompe o modifica incorrectamente) la información o se puede difundir (de forma no autorizada) esa información. Si el objetivo es minimizar la gravedad de que eso ocurra, el planteamiento pasaría por:

• Tener servicios replicados, de forma que la caída de uno no suponga un problema ya que hay un servicio idéntico funcionando. Esto no sería estrictamente tener servicios en alta disponibilidad, sino tener múltiples servicios idénticos. 
• Que la información sea lo más volátil posible, que tenga "fecha de caducidad". 
• Que la información sea lo más abierta y pública posible.

No obstante, mi propuesta es ir un paso más allá. No propongo que dejemos de protegernos de los incidentes, sino que los provoquemos intencionadamente. Frecuentemente. Qué pasaría si todas las semanas tiramos nuestros servicios? Si todas las semanas eliminamos nuestra información? Si todas las semanas divulgamos en Internet nuestra información? Cómo actuaríamos? Qué cambiaríamos en nuestra seguridad para lidiar con estas situaciones?

Si nos acostumbramos a gestionar incidentes graves de manera habitual nuestras medidas de seguridad nos garantizarán no sólo que nuestros servicios (y por tanto nuestro negocio) son resilientes, sino que acabaremos centrando nuestros recursos en aquello que realmente es lo importante, y seremos capaz de lidiar de manera tan habitual con este tipo de incidentes que dejarán de ser graves. Siendo menos seguros habremos conseguido ser más seguros. Contrasentido? Un poco. Arriesgado? Por supuesto. Utópico? Puede ser. Pero... Y si funciona?

Publicada la nueva ISO/IEC 27001:2013

Tras un cierto tiempo ausente de este blog (espero recuperar mi ritmo de publicación habitual ahora que prácticamente he terminado con el Master que estaba cursando) me alegra poder comunicar que ayer se publicó la esperada nueva versión de la norma ISO 27001, varios días antes de lo previsto.

Esta nueva versión, pese a no introducir cambios demasiado significativos, puede suponer un nuevo impulso al desarrollo de la seguridad de la información, sobre todo desde el punto de vista de su integración y aceptación por parte de áreas típicamente alejadas del mundo de la seguridad. Esto se debe a que esta nueva versión de la norma está adaptada a los requisitos del Anexo SL, la nueva referencia de ISO para cualquier sistema de gestión. Esta adaptación supone que un SGSI tendrá exactamente la misma estructura que cualquier otro sistema de gestión normalizado por ISO, y por tanto será más fácilmente integrable con cualquier otro sistemas de gestión ya implantado en la organización.

Más allá de estos cambios, la versión 2013 de la norma ISO 27001 incorpora una nueva versión del anexo de medidas de seguridad,  en el que se ha modificado sobre todo la organización de los controles más técnicos y se han incluido dominios específicos para la criptografía y la relación con proveedores, a la vez que se ha reducido el número total de controles hasta los 113 (gracias sobre todo a la eliminación de controles redundantes).

En definitiva, un nuevo lavado de cara para una norma con bastante éxito y mucho potencial, que esperemos que sirva para que poco a poco las organizaciones se animen a mejorar la seguridad de su información.

Publicada ISO/IEC 27013:2012 - Integración de ISO 20000 e ISO 27001

Esta semana se ha publicado la nueva norma ISO/IEC 27013:2012, una guía de implementación integrada de un SGSI (Sistema de Gestión de Seguridad de la Información) y de un SGS (Sistema de Gestión de Servicios) según las normas ISO 27001 e ISO 20000, respectivamente.

La norma sirve tanto para integrar ambos sistemas de gestión cuando ambos ya existen como para implementar uno de ellos aprovechando la existencia del otro, e incluso para la implementación inicial conjunta de ambos. Una herramienta bastante útil para organizaciones que quieren buscar la eficiencia y eficacia de la integración de ambos sistemas de gestión...

ISO 20000 y ENS

En mi último post sobre el ENS y la mejora continua incluía al final un breve apunte para la reflexión, acerca de los estándares de referencia que podrían ser utilizados para cumplir con las exigencias del Esquema Nacional de Seguridad. ¿Es necesariamente la ISO 27001 la mejor referencia para su implementación?

La verdad es que las analogías entre la ISO 27001 y el ENS son tantas que parece obvio tomar este estándar como referencia para la implantación de un "buen" ENS. Sin embargo, creo que esa facilidad en el paralelismo ha hecho que no nos preocupemos en buscar alternativas, en ser críticos y plantearnos seriamente la existencia de otras opciones. ¿Qué supondría basar una implementación de un ENS en la implantación de un SGSTI (Sistema de Gestión de Servicios TI) que cubra los servicios electrónicos prestados por una administración pública?

Uno de los procesos que forman parte de un SGSTI que cumpla con la ISO 20000 es el proceso de gestión de la seguridad. Por lo tanto, el desarrollo de un proceso de gestión de la seguridad de la información tal y como establece el ENS estaría directamente contemplado. Este hecho supone, además, que podemos articular a través de él todas las medidas de seguridad que requiere el ENS. Aunque... son realmente tales las medidas de seguridad del Anexo II?

Desde mi punto de vista, una gran cantidad de medidas de seguridad propuestas por el ENS no lo son estrictamente hablando. O dicho de otra forma (antes de que los más puristas se lleven las manos a la cabeza), son antes medidas de "gestión correcta de las TIC" que medidas de seguridad. Actividades como la gestión de la capacidad, la gestión de la configuración,  el mantenimiento de los sistemas, la gestión de cambios, la gestión de incidentes, el acondicionamiento de los locales, la formación al personal, la gestión de medios removibles u otras de similares características no son patrimonio exclusivo de la seguridad. Todas estas actividades son necesarias en cualquier organización que quiera prestar servicios TIC de calidad, independientemente de que la seguridad sea o no una preocupación expresa. Y la ISO 20000 establece un modelo general de gestión de servicios TIC mucho más completo que el propuesto por la ISO 27001. ¿No sería, por tanto, mejor opción utilizar el modelo de gestión propuesto por la ISO 20000 como referencia para el cumplimiento de los requisitos del ENS?

Por supuesto, en términos de eficiencia es fácil encontrar una objeción a este planteamiento. Dado un mismo alcance, desplegar un SGSI (Sistema de Gestión de la Seguridad de la Información) conforme con ISO 27001 es más sencillo, fácil y rápido que desplegar un SGSTI que cumpla con ISO 20000. En los tiempos que corren, la premisa general de reducción de costes vigente en todas las administraciones públicas es un argumento contundente a favor del modelo basado en ISO 27001. No obstante, también es habitual encontrar en los objetivos de muchas administraciones públicas una gran cantidad de iniciativas relacionadas con la búsqueda de la excelencia, de altas cotas de calidad en los servicios ofrecidos, etc. Si ofrecer servicios de calidad es uno de los eslóganes más repetidos, por qué no utilizar como modelo de referencia el estándar más completo? Quizás no sea tiempo de correr, y la ISO 27001 pueda ser un primer paso, pero... por qué no utilizar la sistemática de mejora continua para que la evolución cubra no sólo las propias medidas de seguridad, sino también el modelo de gestión seleccionado?

ENS y la mejora continua

Hace algunos años era habitual que existieran empresas que vendían "malas adecuaciones" a la ISO 27001. Empresas que lo que hacían era diseñar proyectos de implantación sistemática de los 133 controles que componen el Anexo A de la norma, es decir, implantaban la ISO 27002. Eran proyectos que se olvidaban de la parte fundamental de la ISO 27001, del cuerpo de la norma: la gestión de riesgos, la mejora continua, el compromiso de la dirección... Afortunadamente, en la actualidad esa situación prácticamente ha sido desterrada por completo (aunque ahora existan casos en los que se da el caso contrario, pero bueno, eso es otra cuestión).

Sin embargo, a veces tengo la sensación de que en la actualidad se está dando una situación similar con el Esquema Nacional de Seguridad. En cierto modo, tengo una sensación de deja-vu al ver que, en muchos casos, cuando se habla del ENS se piensa automáticamente en su Anexo II, en el catálogo de medidas de seguridad que incorpora, obviando (al igual que en el caso anterior) la parte fundamental del documento, el cuerpo del Real Decreto: los principios básicos y requisitos mínimos que debe cumplir la política de seguridad de cualquier administración pública. ¿No aprendemos de los errores del pasado?

Digo esto porque una de las carencias que se le suelen achacar al ENS, desde mi punto de vista de manera completamente errónea, es que no contempla la mejora continua. Es más, yo creo que la contempla de manera explícita y bastante completa:

• Uno de los principios básicos de la seguridad es su reevaluación periódica (Art.9), donde establece la necesidad de reevaluar las medidas de seguridad hasta replantear la seguridad de forma completa si fuera necesario.
• Uno de los requisitos mínimos de la seguridad es la mejora continua del proceso de seguridad (Art. 26), donde se exige la actualización y mejora continuas del proceso integral de seguridad, aplicando para ello mecanismos reconocidos a nivel nacional e internacional.

¿No es suficiente con esa referencia? Está claro que no establece ningún tipo de sistemática de mejora continua, ni regula la gestión de mejoras mediante la articulación de acciones preventivas y/o correctivas como hacen los estándares ISO de gestión, pero... es necesario?

Y como tema adicional de reflexión, por si alguien le quiere dar una vuelta: el citado artículo 26 habla de mecanismos reconocidos relativos a gestión de las tecnologías de la información, no relativos a gestión de riesgos o gestión de la seguridad. ¿Qué lectura hacéis de este hecho?

El resumen de tu seguridad

Hace más de un mes que no publico nada. Sigo aquí, aunque por diversos motivos me he tenido que mantener off-line más tiempo del que me hubiera gustado. No obstante, espero que este alejamiento temporal pueda concluir dentro de no demasiado tiempo, y sobre todo que merezca la pena. Ya os contaré...

Hoy quiero referenciar un artículo que he leído en estos últimos tiempos, y que me ha parecido un estupendo alegato acerca de la utilidad de la declaración de aplicabilidad. No es muy extenso, y en cambio es tremendamente acertado, así que animo a todos a leerlo.

En resumidas cuentas, la declaración de aplicabilidad es el resumen de tu seguridad. Es un documento mediante el cual se puede realizar una aproximación sencilla, apta "para todos los públicos", del "tamaño" de tu seguridad. Hace ya mucho tiempo que hablé en el blog de las dimensiones de un SGSI, y sin embargo creo que a día de hoy su vigencia sigue intacta.

La ventaja que tiene este documento es que puede servir, sin comprometer demasiado la confidencialidad de la información asociada, para orientar a los clientes u otras partes interesadas sobre la "fortaleza" de tu seguridad, algo que puede ser muy útil a la hora de firmar acuerdos en los que la seguridad sea un factor importante a considerar. ¿Pediríais vosotros la declaración de aplicabilidad a un proveedor, por poner un ejemplo concreto, de servicios en la nube? ¿Qué otra documentación os parece importante solicitar (y pensáis que puede ser "conseguible"?

ISO 27001 en España - 2009

Como todos los años, a finales de Octubre ISO publicó su informe anual sobre certificaciones a nivel mundial, su ya famoso ISO Survey of Certifications, correspondiente al año 2009. En él se analiza la evolución mundial de los principales certificados ISO, y de dicho análisis se extrae un resumen general que se puede consultar en abierto. Por su parte, también AENOR como representante español en ISO ha publicado una nota de prensa al respecto, y puede servir para complementar las principales conclusiones del estudio si no se tiene acceso a él.

Las principales conclusiones que se pueden sacar de dicho estudio en torno al estado de las certificaciones ISO 27001 en España son las siguientes:

• De los 12934 certificados ISO 27001 que había a nivel mundial en 2009, 483 (un 3,7%) estaban emitidos en España, convirtiéndose en el 5º país del mundo y 2º en Europa (después de Reino Unido, el país en el que se gestó el estándar, con 946) con mayor número de certificados.
• En el año 2009 se emitieron en España 280 certificados ISO 27001, lo que le convierte en el primer país europeo y tercero del mundo con mayor crecimiento en números absolutos.
• A nivel mundial la certificación ISO 27001 creció en el año 2009 un 40%, mientras que el incremento anual que se produjo en España en el número de certificados emitidos fue del 72,5%.

En resumidas cuentas, creo que la conclusión que se puede extraer de este informe es que el negocio de la certificación ISO 27001 goza de muy buena salud en todo el mundo, y en España avanza viento en popa a toda vela. No obstante, después de ver estos números tan grandilocuentes no puedo evitar que me surja siempre la misma pregunta: ¿Cuantos de todos estos certificados han servido para que las organizaciones que los poseen hayan visto mejorada la seguridad de su información? ¿Cuántos de todos estos certificados han impactado de forma positiva en el negocio de las respectivas organizaciones? Porque no olvidemos que el objetivo último es ése...

El valor de una certificacion ISO 27001

Cada día es más habitual encontrarse con organizaciones certificadas en ISO 27001 o con intenciones de hacerlo. Y ya no son sólo las pequeñas o medianas empresas que quieren incrementar el valor de su marca con una certificación de este tipo, sino que inmensas organizaciones cuyo nombre prácticamente eclipsa el brillo de cualquier certificado también están empezando a ver su valor. O al menos es lo que parece al leer la noticia de que Microsoft quiere certificar su plataforma Business Productivity Online Suite bajo ISO 27001. Visto lo visto, parece que cada vez hay más organizaciones que aprecian el valor de una certificación de este tipo.

No obstante, hace unos días tenía una conversación acerca del valor de esta certificación con una persona cuya organización acaba de certificarse en ISO 27001 (en realidad, todavía ni siquiera es oficial la concesión del certificado) en la que se cuestionaba el valor real que el SGSI había aportado a su organización. No se ponía en duda el valor comercial y de negocio que aporta "el sello", pero sin embargo sí que se cuestionaba, al menos en parte, la utilidad real del SGSI en una organización madura en términos de seguridad. ¿Qué aporta un SGSI a una compañía cuyo "nivel de seguridad" es elevado?

Desde mi punto de vista, el principal argumento de un SGSI para empresas maduras tanto en gestión como en seguridad se centra en la utilidad del análisis y gestión de riesgos como herramienta para racionalizar las inversiones en materia de seguridad. No obstante, también es cierto que en muchas ocasiones si las medidas de seguridad ya están implantadas y se determina que son excesivas, como puede pasar, su eliminación puede ser más costosa que su mantenimiento, de modo que los ajustes asociados pueden no ser tan rentables a la hora de la verdad. También existe una serie de elementos clave que aporta un SGSI que pueden suponer un salto cualitativo diferencial en la gestión de la seguridad de una organización, aunque ese diferencial se verá atenuado en función de los elementos que la organización ya posea debido a su madurez.

En definitiva, creo que el valor de un certificado ISO 27001 no está sólo en su reconocimiento comercial, sino que existe una buena cantidad de factores clave de un SGSI que aportan valor a la organización por sí mismos, más allá del valor del certificado. No obstante, cuanto mayor sea el nivel de madurez de la organización en relación a la gestión de la seguridad menor valor diferencial aportará el SGSI, ya que ciertas prácticas ya estarán interiorizadas. ¿Puede ser este un argumento válido para que una organización madura en seguridad descarte una certificación de este tipo? ¿Qué prima en las organizaciones, el valor comercial aportado por un "sello" o los beneficios internos que proporciona? Y por último... ¿Se os ocurren más elementos que proporcionen valor a una certificación ISO 27001?

Integrando Sistemas de Gestión

En este blog he hablado muchas veces de los requisitos comunes a cualquier sistema de gestión "tipo ISO", y de las ventajas que puede tener la integración de todos ellos. Sin embargo, últimamente me he encontrado con algunos casos que, usando la integración como slogan, lo único que pretendían era aprovechar la existencia de un sistema de gestión (normalmente de calidad, ISO 9001) para reutilizar algunos de sus elementos en el nuevo sistema de gestión que estaban montando, ya sea de gestión medioambiental (ISO 14001), de seguridad de la información (ISO 27001) o cualquier otro. No es que me parezca mal (de hecho, me parece algo lógico y recomendable, dado que sirve para optimizar recursos), pero con lo que no estoy en absoluto de acuerdo es con que a éso se le llame Sistema de Gestión Integrado. Y como no me ha gustado que en un blog me hayan eliminado un comentario esbozando este planteamiento (aunque lo entiendo, ya que es un blog corporativo, y puede ser comprensible que la organización no quiera que aparezcan posturas críticas en una herramienta de marketing), he decidido presentarlo aquí.

Como decía, existen ciertas prácticas que pueden ser recomendables a la hora de solapar o superponer (creo que cualquiera de estos dos términos sería más apropiado) sistemas de gestión. Es conveniente reutilizar las prácticas de gestión desarrolladas, lo que a nivel tangible se convierte en reutilizar la documentación, usando, por ejemplo, los mismos procedimientos de gestión documental y/o de registros o los mismos procedimientos de auditoría. No obstante, no hay que olvidar la especificidad de cada sistema de gestión, y por tanto habrá que ampliar el ámbito de actuación de dichas prácticas a los diversos entornos, de la forma que corresponda en cada caso. Eso nos puede llevar, entre otras cosas, a fusionar en un único documento textos equivalentes en distintos sistemas de gestión, consiguiendo, por poner un ejemplo, un documento único que recoja la política de calidad y seguridad de la información. Del mismo modo podremos acabar teniendo documentos únicos para ambos sistemas de gestión en los que se hable de responsabilidades de la dirección, mejora continua, gestión de no conformidades, ... Si pensamos en el apartado de roles y responsabilidades, algo que también suele ser habitual a la hora de solapar sistemas de gestión es intentar aprovechar las estructuras de gestión existentes (Responsable, Comité, etc.) para el nuevo sistema de gestión. Aunque claro, aquí puede no ser tan sencilla la reutilización, dado que en cada caso se requieren una capacitación y conocimientos específicos y diferenciados, y saber gestionar, por ejemplo, la calidad, no implica saber hacerlo con el medioambiente o la seguridad de la información.

Llegados a este punto es cuando hay que ver qué hemos conseguido al solapar distintos sistemas de gestión: tener una manera común de gestionar cosas distintas. Y ese creo que es precisamente el problema. Si buscamos el término integrar en el diccionario, vemos que hace referencia a la constitución de un todo, de algo global que sintetice las partes. Por lo tanto, creo que no basta con "integrar" la sistemática de gestión (que en realidad ya era la misma), sino que la clave para conseguir un sistema de gestión integrado es ser capaz de integrar aquello que se gestiona, es decir, poder gestionar de manera integrada la calidad, la seguridad o lo que corresponda en cada caso.

Para mí el primer requisito (necesario, pero no suficiente) de un Sistema de Gestión Integrado es, sin duda, que el alcance de ambos sea coincidente. Es más, no creo que se pueda hablar de que cosas distintas puedan estar integradas si su ámbito de aplicación no coincide. A partir de ahí, creo que para hablar de integración de verdad (permitidme que me centre en calidad y seguridad de la información, que es lo que mejor domino) tenemos que ser capaces de considerar de forma simultánea la calidad y la seguridad, y poder entender la una como parte de la otra (y viceversa). No creo que se pueda hablar de integración entre ambos sistemas de gestión si no consideramos la seguridad de la información en en nuestros procesos productivos, si la seguridad no es un factor intrínseco en la selección de proveedores, o si en nuestros análisis de riesgos no consideramos factores de riesgo relacionados con la calidad. En definitiva, creo que para hablar de un Sistema de Gestión Integrado tenemos que centarnos fundamentalmente en integrar aquello que se gestiona (que es lo difícil, obviamente). Y creo que esto es mucho más importante que tratar de que el responsable de calidad y el de seguridad sean la misma persona, ya que incluso se podría hablar de sistemas de gestión integrados en el caso de que sean distintos responsables.

En definitiva, creo que a veces las organizaciones pierden un poco el norte con tanto sistema de gestión normalizado, y se olvidan de que las empresas lo que deberían tener es un único sistema de gestión, el de la organización, independientemente de que el sistema cumpla o no los requisitos de más o menos sistemas de gestión normalizados, o de que ese cumplimiento esté o no certificado por alguien. La preocupación de cualquier organización debe ser el negocio, y negocio no sólo es calidad, o seguridad, sino la suma de todo ello y de mucho más. Así que estaría bien pensar un poco más en tener un sistema de gestión del negocio, que integre la gestión de todos los elementos que lo componen, y no preocuparnos tanto por modas o certificaciones que, si hacemos las cosas bien, se acaban integrando "solas"...

Modelos para la gestion de incidentes de seguridad

A raíz de unos comentarios en relación al último post sobre incidentes de seguridad se me ha ocurrido extender un poco más mi respuesta en forma de post. La idea es, sencillamente, presentar un par de modelos que pueden ser utilizados para la gestión de incidentes de seguridad.

El primero de ellos, como sugieren en los citados comentarios, es seguir el modelo de gestión de problemas de ITIL para llevar a cabo la gestión de incidentes de seguridad. En dicho modelo se habla de monitorizar y ejecutar revisiones preventivas en busca de problemas, que en el ámbito de los incidentes de seguridad se podrían asimilar a las auditorías (técnicas de seguridad y la monitorización de los sistemas de seguridad, pudiendo llegar a considerar incluso las consolas SIM. Por otra parte, ya dentro de la gestión reactiva, la gestión de problemas en sí misma habla de registrar los problemas, diagnosticarlos, identificar las causas del mismo (convirtiendo el problema en un error conocido), definir la solución más apropiada y generar la RFC (petición de cambio) correspondiente. Si sustituimos el término problema por el de incidente de seguridad, el modelo de gestión es perfectamente válido.

El segundo de los modelos que se suele utilizar para la gestión de incidentes de seguridad es el correspondiente a la gestión de no conformidades y acciones correctivas asociadas. Podemos sustituir el incumplimiento de las normas y/o procedimientos establecidos (la no conformidad) por la ruptura de las condiciones de seguridad establecidas (el incidente de seguridad), y a partir de ahí seguir la sistemática de registro y análisis estándar para las no conformidades aplicada al mismo. A partir de la no conformidad se definirán alas cciones correctivas necesarias para resolver la no conformidad, que en nuestro caso supondría identificar las acciones a acometer para solucionar la causa del incidente de seguridad.

Como se puede ver, ambos modelos son equivalentes, y perfectamente válidos para la gestión de incidentes de seguridad. No obstante, tienen algunos matices que no está de más tener en cuenta, por si las moscas.

En primer lugar, la gestión de problemas según ITIL tiene un carácter técnico. Esto supone que los incidentes de seguridad asociados a las personas (y muchos del ámbito de la confidencialidad lo son) van a tener dificultades para ajustarse al modelo. Por otra parte, también es necesario tener en cuenta que la gestión de problemas requiere de la gestión de incidentes y la gestión de cambios y versiones para completar el ciclo de gestión, ya que los incidentes de seguridad requieren tanto de la corrección instantánea de la situación que provoca el incidente (gestión de incidentes) como de la aplicación efectiva de la corrección (gestión de cambios y versiones) para poder considerar que el incidente de seguridad está cerrado. Y por último es necesario considerar, dentro de la gestión de cambios, que el carácter eminentemente operativo que subyace en este proceso puede ser insuficiente para tratar determinados incidentes de seguridad cuyas causas y/o consecuencias puedan llegar a ser de carácter estratégico.

El segundo modelo es complementario al anterior. Es un modelo de caracter más estratégico, de modo que tienen mayor cabida situaciones de carácter menos técnico u operativo, pero al mismo tiempo es un modelo mucho más vago y menos detallado. Tiene la ventaja de que, al exigir la participación activa de la dirección, las decisiones que se adopten van a contar con su "bendición", lo que desde el punto de vista de recursos y prioridades puede ser importante. No obstante, si restringimos el modelo a la gestión de no conformidades y acciones correctivas también sería un modelo incompleto, y para terminar de completarlo deberíamos considerar también ltanto a gestión de acciones preventivas (en relación a las debilidades de seguridad) como la realización de auditorías y el seguimiento de indicadores y cuadros de mando que exige cualquier sistema de gestión normalizado, de modo que también queden contemplado en el modelo el apartado preventivo de la gestión de incidentes de seguridad.

En definitiva, lo importante es que cada organización desarrolle su propia sistemática de gestión de incidentes de seguridad y que, independientemente del modelo que elija (alguno de estos dos o cualquier otro) sea un modelo completo, que contemple todos los apartados necesarios para una gestión efectiva de los incidentes de seguirdad.

AENOR acreditada para certificar SGSIs

Parece que esta vez los rumores sí eran ciertos, y finalmente AENOR ha recibido la acreditación de ENAC para certificar SGSIs bajo ISO 27001. Por lo tanto, todas las certificaciones en 27001 que lleve a cabo AENOR a partir de noviembre contarán con la correspondiente acreditación. Además, todas las certificaciones utilizadas para la concesión de la acreditación también se considerarán acreditadas, lo que supone que la mayor parte de los certificados en 27001 emitidos por AENOR pueden considerarse como certificados acreditados (aunque es posible que no sean el 100% si todas las certificaciones no han seguido idénticos procesos de certificación). Ahora queda en manos de ENAC firmar el MLA (acuerdo multilateral) que permita homologar los certificados acreditados por ENAC con el resto de certificados acreditados por otras compañías, con el fin de que todos los certificados emitidos por las empresas acreditadas por ENAC puedan subir al registro internacional de certificados.

Sistemas de Gestion

A veces resulta difícil transmitir qué es un sistema de gestión. Así, a secas, sin ningún añadido por detrás. Porque si cosas aparentemente tan distintas como un sistema de gestión de la calidad, un sistema de gestión de la seguridad de la información, un sistema de gestión de la continuidad del negocio o un sistema de gestión de los servicios IT tienen dos de sus términos en común, en algo tendrán que parecerse, no?

Lo primero que se me ocurre es ir al diccionario y buscar el significado de esos dos términos:

• Sistema: Conjunto de reglas o principios sobre una materia racionalmente enlazados entre sí.
• Gestión: Acción y efecto de hacer diligencias conducentes al logro de un negocio o de un deseo cualquiera.

Es decir, que por su significado un Sistema de Gestión sería un conjunto de reglas y principios interrelacionados cuya intención es el lograr el éxito en un asunto concreto. ¿Y Cuál es ese asunto? Sencillamente, el término que venga detrás: calidad, seguridad, ...

Vale, el significado está claro, pero... ¿Qué supone eso en la práctica? ¿Cuáles son esas reglas y principios interrelacionados? La verdad es que en este caso la simple definición no da ninguna pista. ¿Solución? Analizar los distintos sistemas de gestión normalizados existentes y buscar sus elementos comunes. ¿Cuáles son? Yo diría que los siguientes:

• Compromiso de la dirección: Para cualquier sistema de gestión normalizado es imprescindible que la dirección de la organización se comprometa formalmente con el asunto en concreto, y que ese compromiso se traduzca en la práctica en la asignación de los recursos necesarios.
• Ciclo PDCA: Todo sistema de gestión normalizado debe estar estructurado en forma de proceso de mejora continua, de modo que se garantice la filosofía de que primero se piensa, luego se actúa, después se revisa la actuación y finalmente se corrige y optimiza, volviendo a empezar.
• Formación: Otro de los elementos imprescindibles de un sistema de gestión normalizado es que se garantice la capacitación y concienciación de todos los implicados en el asunto en cuestión.
• Gestión documental: Una de las exigencias de todo sistema de gestión normalizado es garantizar una adecuada gestión documental, tanto en lo referente a la propia documentación "descriptiva" del sistema de gestión (esas reglas y principios que lo determinan) como a los registros que se generan durante su aplicación práctica.
• Auditoría interna: Uno de los aspectos más importantes es garantizar que el sistema de gestión normalizado se evalúa de forma independiente y objetiva, por lo que las auditorías son imprescindibles, y por lo tanto las internas son obligatorias.
• Revisión por la dirección: Todo sistema de gestión normalizado debe garantizar su continuidad en el tiempo, y eso supone que no basta con la asignación inicial de recursos y la puesta en marcha de las prácticas que correspondan. La garantía de esa validez contínua supone que la propia dirección sea la que revisa los objetivos y resultados globales del sistema de gestión y sus principales parámetros de funcionamiento, con el fin de conocer de primera mano los principales aspectos del sistema de gestión y poder ir adaptándolo a las necesidades cambiantes de la organización.
• Mejora continua: Por último, todo sistema de gestión normalizado deberá garantizar su continua evolución y mejora. Por ello, no sólo deberá estar estructruado en forma de ciclo PDCA; sino que se deberá llevar a cabo un seguimiento de todas las desviaciones que pueda sufrir y establecer las acciones correctivas y preventivas necesarias para cumplir con ese precepto.

No tenemos que perder de vista que estas son las características de todo sistema de gestión normalizado. Esto no quiere decir que un conjunto de reglas y principios interrelacionados que carezca de alguna de estas características no pueda ser un sistema de gestión, sino que no cumplirá los preceptos de uno estandarizado (o estandarizable) en forma de norma de gestión.

Por último, sólo recordar que el sistema de gestión es sencillamente el marco en el que hay que encajar todas las reglas y principios encaminados a lograr ese determinado asunto. Y que esas reglas y principios no tienen por qué ser similares, ni siquiera tienen por qué estar establecidas de la misma forma. Algunas de esas reglas y principios pueden estar establecidas en forma de políticas, otras en forma de controles, otras en forma de procesos... Y obviamente cada una de ellas podrá hablar de un asunto totalmente distinto.

Escribiendo Políticas de Seguridad

Hoy quiero referenciar una serie de post sobre Políticas de Seguridad que nos ofrece apokalyptica79 en su blog, que aprovecho para recomendar.

El primero de ellos es una introducción a las políticas de seguridad, en el que trata de definir exactamente qué es eso de las políticas de seguridad y cuáles son sus connotaciones más importantes. Como ya he comentado en otras ocasiones, no estoy de acuerdo en la simplificación que se hace al reducir la seguridad de la información a un concepto más acotado como es el de la seguridad informática, pero aun así sigo considerando que la introducción es muy instructiva.

El siguiente post trata de justificar la necesidad de las políticas de seguridad, desde el punto de vista de herramienta regulatoria ya presentado en el post anterior, y además presenta una estructura típica de políticas de seguridad, basada en el índice propuesto por la serie 27000 y con un listado muy interesante de elementos que debe contener una buena política de seguridad en cualquiera de los citados ámbitos.

Y el último (al menos, por el momento) de los post sobre políticas de seguridad es el referido al propio proceso de elaboración de las políticas de seguridad, en el que detalla distintos elementos a tener en cuenta durante la elaboración de las políticias (aspectos a considerar, participantes, etc.). En conjunto, una excelente tripleta (y ójala que siga evolucionando en cuarteto, quinteto o más) de artículos que puede servirnos de gran ayuda a la hora de enfrentarnos a la dura tarea de escribir políticas de seguridad para nuestra organización.

Buceando en la certificacion ISO 27001

Hace unos días un compañero me reenvió un documento que, la verdad, había pasado por alto. El documento en cuestión es una traducción realizada por el ISMS Forum Spain de un documento de Fabrizio Cirilli, presidente de ISO 27001 ISMS IUG ITALY, sobre la implementación y certificación de los SGSI. Como creo que el documento sólo es accesible para socios de ISMS Forum, paso a realizar un brevísimo comentario de los aspectos más destacables, desde mi punto de vista, del documento:

• Orígenes de la ISO 27001: Las recomendaciones de la OCDE y la BS 7799.
• Requisitos definidos por la ISO 27001: Un estupendo esquema donde identifica las fases del ciclo PDCA con cada apartado del estándar y un claro listado de los requisitos de la norma a todos los niveles (documentos obligatorios, obligaciones de cada apartado, etc.).
• Cambios y evolución de la BS7799-2 a la ISO 27001 (y proceso que siguieron todas las organizaciones certificadas en la norma británica para "homologar" internacionalmente sus certificados).
• Certificación de un SGSI: Por qué certificar el SGSI y pasos a seguir para lograrlo, incluyendo las exigencias en relación a cada apartado de la certificación y una explicación de cómo se lleva a cabo una certificación.
• Acreditación de un certificado: Por qué las empresas certificadoras deberían también "certificarse" a su vez, y en qué normas se basa dicha certificación (como listado de referencia, y sin pararme demasiado a analizar las implicaciones de cada una de ellas, podemos decir que en el caso concreto de los SGSIs son de aplicación en mayor o menor medida las normas ISO17021, ISO 19011, EA7/03, ISO 27006 y EN 45012).

Y en resumen esos son los aspectos más destacables del documento. Una lectura más que recomendable para todo aquél que quiera adentrarse un poco más en los vericuetos de las certificaciones, y sobre todo una buena guía de profundización para todos aquellos que quieran certificar un SGSI.

Empleado descontento

Hace unos días día leía una noticia sobre un ex-empleado que borró la información de su antigua compañía, al parecer furioso con su organización por hacer recibido un informe laboral desfavorable.

Más allá de los típicos comentarios que se puedan hacer al respecto, de los cuales tenemos una buena representación asociados al propio artículo, creo que es necesario prestar atención a algunos aspectos que creo que pueden ser significativos:

• La persona en cuestión parece que tenía problemas de relación inter-personal. Si el hecho ya estaba en conocimiento de RR.HH., como parece, vamos a la segunda derivada. ¿Se habían analizado las posibles consecuencias más allá de el propio hecho? ¿Existía una especial atención al comportamiento de esta persona desde otros puntos de vista, como podría ser el de seguridad de la información?
• Estamos ante una persona con importantes privilegios dentro de la organización, ya que se trata del director de servicios técnicos. Alguien que de hecho tenía que poder realizar las acciones que desarrolló si hubiera seguido formando parte de la organización. ¿Cuál era la estructura de control interno de la compañía? ¿Cómo se supervisaba o auditaba la actividad de las personas con mayores privilegios, que son precisamente las que tienen el mayor riesgo potencial asociado?
• Tras su dimisión se pudo conectar a los sistemas para llevar a cabo las acciones ilegales. ¿Por qué no funcionó el procedimiento de bajas? ¿No hubiera sido necesaria una especial atención dado el perfil del sujeto, de altos privlegios, y las condiciones de la baja, en forma de "dimisión airada"?

El hecho que quiero destacar es que, en este caso, no es que se produjera un fallo concreto en un elemento específico de la organización, sino que la pérdida de casi medio millón de dólares estuvo producida por la concurrencia de fallos de seguridad en distintos ámbitos (seguridad ligada al personal, monitorización, procedimiento de bajas, ...). Es un claro ejemplo no sólo de que los mayores riesgos de seguridad están dentro de casa, sino de que sin una estrategia que trate la seguridad de forma global es probable que aparezcan casos en los que una conjunción de factores de riesgo sean capaces de desencadenar graves pérdidas para la organización. ¿Hubiera sido posible evitar el incidente con un buen SGSI? Yo creo que sí...

Publicada ISO/IEC 27005:2008

La semana pasada se publicó la norma ISO/IEC 27005:2008, bajo el título Information technology - Security techniques - Information security risk management. Como dice su nombre, esta norma supone una guía para la gestión de riesgos de seguridad de la información, de acuerdo con los principios ya definidos en otras normas de la serie 27000. Sustituye (y actualiza) a las partes 3 y 4 de la norma ISO TR 13335 (Técnicas para la gestión de la seguridad IT y Selección de salvaguardas, respectivamente), y se convierte en la guía principal para el desarrollo de las actividades de análisis y tratamiento de riesgos en el contexto de un SGSI. Constituye, por tanto, una ampliación del apartado 4.2.1 de la norma ISO 27001, en el que se presenta el análisis de riesgos como la piedra angular de un SGSI, y supone una excelente ayuda para todo aquél que quiera profundizar en el desarrollo práctico de un proceso de gestión de riesgos de seguridad de la información.

A vueltas con los términos

Cuanto más te vas adentrando en el mundo de la gestión (en general) y más fuentes diversas de información vas consultando, más problemático se vuelve eso de definir correctamente aquello de lo que estamos hablando. Sobre todo, si son términos que no sólo no se aclaran suficientemente, sino que mismos términos en entornos distintos pueden significar cosas distintas y, lo que es peor, distintos términos en entornos diferentes pueden tener el mismo significado. Y claro, cuando lo que importa son los detalles el trabajo se puede complicar...

Hoy símplemente quiero aclarar cuatro términos (auditoría, control, gestión y gobierno) que suelo utilizar y que para mí significan cosas distintas. Seguro que todos tienen matizaciones, y si alguien tiene distintos puntos de vista desde ahora le animo a que los critique libremente.

• Auditoría: Para mí es el de "menor nivel" de los cuatro, el más cercano a los niveles operativos. Lo entiendo como una labor de revisión sistemática y exhaustiva, en la que lo que se busca son las "pruebas", las trazas concretas y específicas de las actividades desarrolladas. Si la actividad consiste en repetir 20 veces una misma tarea, la labor de auditoría trataría de verificar que efectivamente se ha repetido esa tarea 20 veces una por una, examinando todos los registros que ha dejado dicha actividad y verificando, además, que su resultado ha sido el correcto. No creo que esta definición sea incompatible con el concepto de auditoría de un sistema de gestión, ya que considero que la coletilla añade todas las matizaciones correspondientes: la selección (y no revisión completa) de trazas, la aleatoriedad de dicha selección, ... De todos modos, no olvidemos que en la auditoría de un sistema de gestión lo que verificamos exhaustivamente es el sistema de gestión, y ahí nunca se permitirá que algún apartado de dicho sistema de gestión queden sin examinar. Lo que sí será permisible es no verificar todos los controles que forman parte de ese sistema de gestión, pero el sistema de gestión en sí mismo deberá ser completamente auditado.
• Control: Yo entiendo este concepto en un nivel superior al de auditoría. Si el anterior era una revisión exhaustiva, este supone la comprobación a modo de check-point de la actividad anterior. Para mí, el control no persigue verificar todos y cada uno de los resultados, sino establecer una tarea de revisión periódica de cierta actividad, con el fin de detectar desviaciones. En un caso ideal esta tarea de control iría ligado a una gestión por procesos, en la que dicho control constituye el parámetro que realimenta al proceso. Podríamos entender el control, visto de otro modo, como la tarea encargada de conseguir una determinada métrica asociada a la actividad en cuestión, y por tanto se podría entender este concepto como la base para el desarrollo de indicadores asociados a la actividad. Y, por supuesto, el caracter táctico u operativo del control iría ligado al caracter de la propia actividad controlada. Creo que es necesario señalar que el concepto de control visto como actividad no cubre completamente la definición que la serie 27000 ofrece en torno a dicho término, ya que en este caso no sólo lo contempla como actividad sino también como medida de caracter técnico, organizativo u operativo.
• Gestión: Este quizás sea el concepto más complejo de definir. No por el término en sí, sino por la dificultad que supone acotarlo y separarlo del control y del gobierno. Yo entiendo la gestión como el conjunto de tareas encaminadas a definir las propias actividades a desarrollar, administrar los recursos asociados a dichas actividades y articular las medidas necesarias para que dichas actividades alcancen los objetivos designados. El control sería una de las partes de la gestión, la de chequeo, y tendría por encima el concepto de gobierno. Considero que el carácter de la gestión es eminentemente táctico, y desde el punto de vista de una gestión por procesos se podría identificar fácilmente asociado a la articulación práctica de un proceso dado.
• Gobierno: Bajo este término yo suelo englobar las actividades de dirección asociadas a un nivel estratégico. Palabras como guiar y dirigir las entiendo íntimamente ligadas a este concepto. Si la gestión articula actividades, administra recursos y trata de conseguir los resultados definidos, el gobierno es quien define el marco de dichas actividades, proporciona o designa dichos recursos y establece los resultados a conseguir. En definitiva, el gobierno sería la dirección estratégica, el componente de planificación de alto nivel en un sistema de gestión. En resumidas cuentas, los aspectos que podríamos encontrar dentro del apartado de compromiso de la dirección de cualquier norma ISO de gestión.

Estas cuatro definiciones, no obstante, no son la panacea. Existen conceptos asociados, mezclas entre ellos, y la posibilidad de encontrárselos articulados en distintos niveles o repetidos en distintos grados de zoom dentro de cada organización. Será labor de cada uno utilizarlos de forma adecuada, y sobre todo requisito imprescindible tener claro qué uso hace nuestro interlocutor de estos cuatro términos si queremos mantener una conversación útil en relación a ellos. Aunque, pensándolo bien... ¿Quién iba a querer hablar de estos temas con otra persona? :-)

Gobierno de la seguridad

De vez en cuando, y sin tener muy claro cómo, llego a artículos realmente interesantes. Unos por su profundiad, otros por su concreción, otros por la claridad de ideas que presentan... El artículo de hoy es uno de ellos: Hacia un gobierno de seguridad de información. Un artículo no muy extenso pero muy claro en el que se explican los principios del gobierno de la seguridad, y cómo desarrollarlo.

El punto de partida del artículo es que el gobierno de la seguridad se basa en la gestión de riesgos, y que su éxito radica en alcanzar y mantener un nivel aceptable de riesgo. Y para ello, el gobierno de la seguridad debe basarse en 4 principios básicos: alineación estratégica, reducción de riesgos, uso eficiente de recursos y mediciones para verificar los resultados obtenidos.

Según el artículo, el gobierno de la seguridad empieza por el desarrollo de un plan estratégico de seguridad y la articulación funcional de las responsabilidades de seguridad. Una vez desarrollada esta parte, se indica que hay que desarrollar el modelo de gestión asociado, y se propone como referencia el modelo de SGSI que presenta la ISO 27001. Una vez establecido el modelo de gestión, el artículo pasa a analizar la tarea de análisis y gestión de riesgos propiamente dicha , y por último el artículo señala como necesario el desarrollo del SGSI y por tanto el consiguiente desarrollo de indicadores y métricas que permitan desarrollar la gestión de riesgos en forma de ciclo de Demming. Y por último, por supuesto, mantener este funcionamiento.

Así leído la verdad es que parece un proceso lógico y sencillo. Y realmente no tiene por qué dejar de serlo: al fin y al cabo, todo el mundo gestiona riesgos de forma habitual en su vida cotidiana sin prácticamente percatarse, pero cumpliendo perfectamente con todos los pasos que aquí se identifican. ¿Alguien es capaz de poner algún ejemplo? El mío queda pendiente para un próximo post...

Clasificación de la información

Hoy sigo con la serie de post acerca de aspectos prácticos de un SGSI, y le toca el turno a la clasificación de la información. Es, posiblemente, uno de los aspectos más delicados de un SGSI, y teniendo en cuenta que debe ser uno de sus pilares, hacer un buen trabajo en este campo nos puede condicionar mucho el éxito del resultado final.

Lo primero que tenemos que pensar es én base a qué dimensiones queremos clasificar la información. Es habitual una clasificación basada en la confidencialidad, pero quizás puede ser conveniente tener en cuenta también la disponibilidad, la integridad o su trazabilidad (de los accesos a ella o de su tratamiento). El objetivo es tener las mínimas dimensiones posibles pero sin que la reducción nos obligue a perder criterios. ¿Es importante para mi negocio saber quién ha accedido a un campo de una base de datos (tanto desde el punto de vista de "negocio" puro como desde el punto de vista de exigencias legales, contractuales o de imagen)? ¿Tenemos con cierta información necesidades específicas de integridad de datos (por ejemplo, en máquinas de control numérico o en una casa de subastas on-line)? ¿Es clave que la información de nuestra web esté disponible, siendo una empresa de venta por internet?

Una vez que tenemos claras las dimensiones que tenemos que tener en cuenta, tenemos que ver el rango que queremos usar. El mínimo en cada dimensión es 2 (podríamos denominarlos como necesidad "normal" y necesidad "especial"), y el máximo el que queramos, pero lo mejor es ir al mínimo (quizás ampliar el rango en la dimensión de confidencialidad a 3 niveles puede ser aceptable), porque luego tendremos que parametrizar cada umbral.

Y a partir de ahí, establecer los criterios para cada umbral. Aquí viene lo difícil, porque deben ser criterios "a priori". No me vale decir que toda la información que está en la web debe ser pública (mínima confidencialidad), porque... ¿Cuál es la información que puedo colgar en la web? ¿Cuál es la que debe recibir esa categoría de pública? Lo que necesito saber es, precisamente, cuál es la información que debo colgar en la web porque es pública... Un criterio podría ser, por ejemplo, que lo sea toda la información comercial que genera la empresa (datasheets, marketing, etc.). A partir de ahí, cuál es la información privada (confidencialidad media)? Por ejemplo, toda aquella que no sea ni pública ni confidencial. Y entonces, qué información debe ser confidencial (confidencialidad máxima)? Pongamos que toda aquella información que sólo debe ser conocida por la persona que la genera u obtiene (por ejemplo, claves de acceso). Ya tendríamos el criterio para clasificar toda la información de la empresa en la dimensión de confidencialidad. Y deberíamos hacer lo mismo con el resto de las dimensiones que hayamos elegido.

Y para qué sirve esto? Sencillamente, para habilitar con lógica los controles de seguridad. La "intensidad" de un control, o el número de controles a aplicar sobre cada activo, dependerá de la clasificación de la información asociada a él (por éso hablamos de SGSI y no de SGS). No vamos a establecer controles de cifrado para información pública, pero sin embargo sí que podría ser conveniente usarlos para información confidencial. Y si tenemos información con especiales necesidades de disponibilidad nos tendremos que plantear la posibilidad de que esté redundada y en alta disponibilidad, por ejemplo.

En definitiva, la clasificación de la información debe ser el criterio de base que guíe nuestra aplicación de controles de seguridad de esa información, y tendremos que aplicar mayores controles cuanto mayor sea la necesidad de seguridad. Sin embargo, con un análisis de riesgos bien hecho puede que no haya mayores problemas en este apartado, ya que si hemos hecho los deberes correctamente no sólo tendremos ya esos niveles establecidos numéricamente, sino que los criterios de clasificación ya los habremos tenido en cuenta para asignar la numeración, y la única tarea será pulir esos criterios para que queden redondos.

De todo un poco

Hoy tenía pensado hablar un poco de la "continuidad" ligada a las personas, y en particular comentar este artículo. Pero como veo que Javier Cao se ha adelantado :-) prefiero no ser repetitivo y comentar otras dos referencias.

La primera debería ser conocida, y sin embargo tengo la sensación de que no todo el mundo se pasea por la web de RedIRIS (¿quizás porque es un poco "gris"?). En ella, bajo el título de definición de una política de seguridad, dan un repaso bastante completo a la gestión de la seguridad de la información en términos globales. No es específicamente una guía de implantación de un SGSI, pero precisamente por éso me gusta. Contempla todos los aspectos de la seguridad desde un punto de vista práctico, pero sin encorsetarse a una norma específica. Una fantástica referencia para todos aquellos que realmente se interesen por la seguridad pero estén un poco "escaldados" con las normas.

Y la segunda referencia, que no tiene nada que ver con la anterior, es una pequeña introducción al origen y necesidades que resuelven los dispositivos UTM (Unified Threat Management, o gestión unificada de amenazas). Para los que no los conozcan, y espero que sean una minoría, son un tipo de dispositivos (creo que el término tecnología no es adecuado aquí) que aúnan en un solo dispositivo distintas funcionalidades de protección perimetral de red (Firewall, Antivirus, VPN, IPS, ...) en tiempo real y con gestión unificada de todas ellas. Creo que estos dispositivos tienen un futuro muy prometedor, sobre todo desde el punto de vista de la sencillez que supone la administración unificada de la seguridad perimetral. Seguro que tienen sus detractores, sobre todo entre aquellos que opinan que es mejor un equipo dedicado para cada función de seguridad, pero desde mi punto de vista la superior usabilidad de estos equipos terminará decantando la balanza a favor de la unificación. Y que no se preocupen aquellos que piensan que puede haber problemas de rendimiento o throughput, que si hay negocio los fabricantes ya se preocuparán de dar solución a este aspecto, que en realidad no es tan crítico a día de hoy.

Y por hoy, eso es todo...