Vídeo de la charla de este año en rootedcon2013: ¿Y si la seguridad afectara al valor contable de la empresa?

Me he dado cuenta de que no lo había publicado, aunque sí twitteado...

Antonio Ramos - ¿Y si la seguridad afectara al valor contable de la empresa? [Rooted CON 2013] from rootedcon on Vimeo.

Charla: "Gobernando la Seguridad hacia los objetivos corporativos"

(Este artículo se publicó originalmente en n+1 tiende a infinito, el blog de n+1 Intelligence & Research)

Vídeo de la charla impartida dentro del ciclo de conferencias TASSI de 2013 titulada "Gobernando la Seguridad hacia los objetivos corporativos":

Ciber-armas

Leyendo acerca de la detención en España del (¿presunto?) autor del mayor colapso en Internet (enlace) [aunque, al fin y al cabo, tampoco fue para tanto, ¿no?], y supongo que debido a que ando estos días dándole vueltas al texto para la reforma de la Ley de Seguridad Privada, me surgen algunas reflexiones:

• ¿Qué deberíamos entender por una ciberarma?
• Considerando que la posesión de armas está regulada, ¿no debería estar regulada también la posesión de esas ciberarmas?
• Dado que todos los equipos pueden ser utilizados como zombies de una red de ataque, ¿no se deberían pedir medidas de protección mínimas a todos aquellos que gestionen equipos (y más cuántos más gestionen o más potentes sean)?
• ¿Por qué seguimos aplicando leyes territoriales a algo que no lo es? Quiero decir, para atacarme en el mundo físico, el atacante tiene que acercarse... ¿o no? Me explico, ¿puede atacar Corea del Norte a EE.UU.? Sí, por supuesto, puede lanzarle misiles. Entendido. ¿Y EE.UU. puede defenderse? Claro, también puede lanzarle misiles. OK. Entonces [y os pido perdón por adelantado por lo que voy a decir], si alguien me lanza un ataque desde sus equipos en forma de "pseudo-paquetes TCP/IP malintencionados", ¿no podría yo devolverle la moneda de la misma forma sin suponer ningún tipo de vulneración de no-se-qué-legislación?
• Y, finalmente, ¿qué legitimación tiene una empresa privada para enfrascarse en este tipo de incidentes? Quiero decir, si alguien intenta robar, atacar, o atentar contra otro son las Fuerzas y Cuerpos de Seguridad las que están habilitadas para actuar, sin embargo, en este mundo online, dos empresas se pueden enfrascar en una pelea que... ¿"afecte a Internet"? ¿Quienes son estas empresas para permitirse semejante lujo? ¿En qué se fundamentan? ¿Os imagináis que trasladamos esto al mundo "físico"? Ya me veo a las compañías de seguridad privada persiguiendo por las calles de la ciudad a unos atracadores que han intentado robar una oficina bancaria disparando sus armas sin control... En fin, creo que hay que poner coto a este tema antes de que se nos vaya de las manos.

... ¿todavía no me sigues en twitter.com/antonio_ramosga?

El Gobierno de la Seguridad y la Protección de las Infraestructuras Críticas

(Este artículo se publicó originalmente en n+1 tiende a infinito, el blog de n+1 Intelligence & Research)

El modelo de gobierno propuesto por Cobit5 se basa, como principio fundamental, en lo que ha denominado la cascada de objetivos. Lo que propone esta cascada, en esencia, es que nuestras acciones tienen que estar relacionadas con las necesidades de todas las partes interesadas (stakeholders) de nuestra organización.

Si aplicamos este modelo a la seguridad de la información, adaptando el modelo de Cobit5 para las TICs, tendríamos una cascada como la que vemos en la figura adjunta. Es decir, partiendo de las necesidades de las partes interesadas, se fijan los objetivos empresariales, que son los que determinan los objetivos en materia de seguridad de la información y, a partir de ellos, se establecen las metas para los catalizadores de gobierno identificados por ISACA en el mencionado marco de gobierno (políticas, cultura, organización, procesos, información, herramientas y capacidades).

Pero, ¿cuál es la relación con la protección de las infraestructuras críticas?

Si se aplica este modelo a las infraestructuras críticas, lo primero que hemos de hacer es identificar a todas las partes interesadas y sus necesidades. Y si hablamos de proteger las infraestructuras críticas, una de las partes interesadas somos los ciudadanos que podemos vernos afectados por una fallo en dichas infraestructuras. El paso siguiente sería identificar nuestras necesidades y una necesidad sería, lógicamente, que se salvaguardara la seguridad de las mismas para que ningún incidente pudiera llegar a suponer un riesgo para nosotros.

Por tanto, aplicando esta lógica, los objetivos de seguridad del operador de dicha infraestructura reflejarían la necesidad de protección de los ciudadanos solucionando así uno de los grandes handicaps de la protección de las infraestructuras críticas: Que se protejan adecuadamente a pesar de ser gestionadas por operadores privados (en su mayoría) que se rigen por criterios económicos.

Por tanto, ¿debería abordarse seriamente la implantación de marcos de gobierno de la seguridad como medida de protección de las infraestructuras críticas?

... ¿todavía no me sigues en twitter.com/antonio_ramosga?

Lectura: "The Cuckoo's Egg"

Creo que fue una recomendación de @lostinsecurity, aunque no lo recuerdo bien... el caso es que es la demostración de que se puede hacer una novela sobre seguridad informática sin caer en estridencias ni en la ciencia ficción, al menos esa es mi opinión.

Personalmente, me ha parecido entretenida, se lee bien (incluso en inglés) y, a pesar de tratarse de una obra publicada inicialmente en 1989 [¡¡¡hace 24 años!!!] mantiene toda su actualidad y aborda las grandes dificultades existentes  para perseguir a los que comenten algún delito informático principalmente por dos aspectos principales a mi juicio:

• La no-territorialidad de Internet. Mientras que las legislaciones y los instrumentos policiales están ligados a un territorio, los accesos y las comunicaciones permiten las conexiones desde cualquier punto del globo.
• La incomprensión de la informática por parte de los legisladores y la mayoría de los nacidos no-digitales que hace que se inventen cosas nuevas para los aspectos informáticos cuando, por ejemplo, los delitos son los mismos aunque utilicen medios técnicos "nuevos".

Pero quizás el pasaje que mas me ha gustado ha sido cuando el protagonista (informático hippy) habla con su pareja y ésta le hace ver que lo que está haciendo, intentando atrapar al que ha accedido a su sistema, es actuar cómo un policía cuando se supone que el es un administrador de sistemas. Y, en realidad, hay que reconocer que tiene toda la razón... Somos conscientes de que nadie se puede tomar la justicia por su mano y que hay que recurrir a los cuerpos y fuerzas de seguridad para denunciar y que a ellos le corresponde la investigación, pero sin embargo, en lo que se refiere a la seguridad informática, estamos acostumbrados a técnicas que rozan, si no sobrepasan, la línea roja de lo que se podría entender por defenderse (acceso a equipos de los atacantes, interceptación de comunicaciones, etc.) y se realizan acciones que, en teoría, corresponderían a esos cuerpos y fuerzas de seguridad.

Para finalizar, os dejo con algunas frases extraídas de la novela que han llamado mi atención por algún motivo:

"Pregunté que policías estaban a cargo de Internet"

"No me gustó el sistema de White Sands. No soy capaz de recordar contraseñas generadas por ordenador, por eso las apunto en mi cartera o junto a mi terminal"

"Esto es cada vez más extraño", dijo Martha. "Empezó como un hobby, persiguiendo a un bromista y ahora estás hablando con esos militares con trajes y sin sentido del humor. Cliff esto no es lo tuyo [...] ¿Quieres emplear tu tiempo siendo un policía?"

"¿Cómo mantenéis vuestros sistemas [de la CIA] seguros?" "Estricto aislamiento. No hay cables conectando con el exterior"

"Mi trabajo es hacer funcionar un ordenador. No atrapar criminales"

"La gente pone más atención para cerrar sus coches que para asegurar sus datos"

"Mi salario se desvió del soporte de sistemas al contraespionaje"

"Eran dolorosamente conscientes de que la seguridad interfiere las operaciones. Equipos de alta-seguridad son difíciles de penetrar, y poco amigables en su uso".

"Cualquier sistema puede ser inseguro. Todo lo que tienes que hacer es administrarlo de manera estúpida"

"La cuestión no es "qué equipo es más rápido," no, ni siquiera "cuál es mejor". En su lugar, preguntar "¿Cuál es más adecuado?" o "¿Cuál hará que el trabajo se haga?"

"La red de la NASA [...] es una autopista conectando equipos por todo el país. Un ladrón podrá usar naturalmente esa carretera, pero eso apenas puede ser el fallo del fabricante de la carretera. La NASA solo es responsable de mantener la carretera intacta. La seguridad de cada equipo recae en las manos de la gente que los ejecuta."

"Para tener las redes como nuestro lugar de juegos, tenemos que preservar nuestra sensación de confianza; para hacer eso, tenemos que tomárnoslo en serio cuando la gente rompe esa confianza."

"Ese es el problema de hablar sobre problemas de seguridad. Si describes como hacer una bomba [...], el próximo niño [...] se pude convertir en terrorista. Pero si suprimes la información, la gente no será consciente del peligro."

"La ciencia y el progreso social solo tienen lugar en abierto. [...] Sí, puedes hacer equipos y redes seguros. Pero serán normalmente difíciles de usar y poco amigables."

... ¿todavía no me sigues en twitter.com/antonio_ramosga?

Estrategia de Ciberseguridad de la Unión Europea

Una gran noticia para todos los europeos: Se ha publicado la Estrategia de Ciberseguridad de la Unión Europea (pdf).

Y dado que en su día comenté la Estrategia Española de Seguridad no iba ahora a no comentar la europea de ciberseguridad, ¿verdad?

Lo primero que tengo que decir [como alguno que me conoce supondrá] es que no me gusta que la ciberseguridad sea tratada como algo diferente. En mi opinión: La ciberseguridad es parte integrante de la seguridad.

Y una vez hecha esta salvedad, destacar las piezas principales de la misma:

• Se establecen cinco principios:
• Los valores esenciales de la UE aplican tanto en el mundo físico como en el digital [como si hubiera dos mundos, ¿Fringe?]
• La protección de los derechos fundamentales, de la libertad de expresión, de los datos personales y de la privacidad.
• Acceso para todos.
• Gobierno de multi-grupos de interés democrático y eficiente.
• Una responsabilidad compartida para asegurar la seguridad.
• Se identifican cinco prioridades (algunas de ellas descompuestas en varias):
• Conseguir "ciber-resiliencia"
• Proponiendo legislación
• Elevando el nivel de concienciación
• Reducir drásticamente el cibercrimen
• Con legislación fuerte y efectiva
• Mejorando la capacidad operativa para combatirlo
• Mejorando la coordinación a nivel europeo
• Desarrollar una política y capacidades de ciberdefensa
• Desarrollar recursos industriales y tecnológicos para la ciberseguridad
• Promocionando un mercado único para los productos de ciberseguridad
• Impulsando las inversiones en I+D y la innovación
• Establecer una política de ciberespacio coherente a nivel internacional y promover los valores fundamentales de la UE
• Se clarifica que los estados son los que deben asumir el liderazgo de la ciberseguridad, aunque se deben establecer los mecanismos de coordinación y colaboración adecuados, tanto a nivel nacional, como europeo como internacional puesto que las amenazas no entienden de fronteras.

De todas formas, he preparado este mapa mental que recoge de manera más exhaustiva lo principal de la estrategia:

Finalmente, aunque es un gran avance (sin lugar a dudas) siguen existiendo aspectos que no han sido recogidos como consecuencia de seguir considerando que el ciberespacio es un espacio disjunto al espacio físico, cuando son parte de un mismo espacio. Me refiero a aspectos que ya he comentado antes, como:

1. La obligación de planes de seguridad para empresas que hagan uso de sistemas TIC (al estilo de lo que exige la Ley de Riesgos Laborales).
2. La necesidad de contar con planes de contingencia para aquellos que puedan afectar a la población (en línea con la Ley de Protección Civil).

... ¿todavía no me sigues en twitter.com/antonio_ramosga?

Cómo cumplir con PCI DSS si utilizo cloud computing

(Esta entrada se publicó originalmente en n+1 tiende a infinito)

En esta entrada vamos a analizar el recién suplemento informativo publicado por el PCI Security Standards Council relativo a la computación en la nube (PDF).

En primer lugar, destacar que es un documento bastante exhaustivo (52 páginas) que incluso, en nuestra opinión, va un poco más allá de lo que se esperaría de un suplemento informativo del PCI SSC, puesto que dedica todo un apartado (el sexto) a "otras consideraciones" sobre la computación en la nube que, como su propio nombre indica, no afectan a la cuestión a cubrir: Servir como punto inicial de discusión para proveedores de servicios en la nube y clientes (especialmente centrado en los casos de nubes públicas).

Desde nuestro punto de vista, el documento gira entorno a tres ideas principales que gobiernan todo el contenido:

1. Los servicios en la nube suponen una pérdida de control, por lo que es necesario delimitar claramente las responsabilidades de las partes antes de utilizarlos y llevar a cabo un proceso de due diligence previo que permita verificar el cumplimiento del proveedor con los requisitos de PCI DSS.
2. Es necesario establecer un adecuado aislamiento de los datos en los entornos en la nube mediante mecanismos de segmentación que permitan limitar el alcance de las evaluaciones de cumplimiento.
3. El proveedor y el cliente deben contar con mecanismos para asegurar que el cumplimiento se mantiene de manera continuada.

Respecto a la primera idea nos gustaría destacar que:

• Se proporciona una guía muy útil (no prescriptiva) de cómo se pueden distribuir las responsabilidades entre cliente y proveedor (Anexos A y C) para cada una de las modalidades de servicios en la nube (SaaS, PaaS e IaaS) puesto que se considera indispensable que conste por escrito (a ser posible en los SLAs del servicio) quien se responsabiliza de la implantación y ejecución de cada control, cómo se va a informar sobre su estado y su gestión y que el cliente entienda qué responsabilidad acepta el proveedor para cada control.
• Se refuerza la idea de que una pérdida de control sobre los controles no supone una pérdida de responsabilidad del cliente de que dichos contrales deben ser efectivos y, por tanto, debe asegurarse un nivel de visibilidad y de monitorización de los mismos adecuado.
• Por dicho motivo, se recomienda a los clientes que trabajen con proveedores que cumplan PCI DSS pero que, antes de contratar un servicio, se informen de:
• Desde cuándo cumple el proveedor con PCI DSS y cuándo fue su última evaluación.
• Qué servicios y requerimientos fueron incluidos en dicha evaluación.
• Qué sistemas e instalaciones fueron evaluados.
• Si algún componente del sistema necesario para la prestación del servicio no fue incluido en la evaluación.
• Cómo evita el proveedor que los clientes no introducen componentes que no cumplan con PCI DSS o eviten los controles existentes.
• Con independencia de utilizar servicios en la nube, el cliente tiene que seguir demostrando su cumplimiento con los requisitos de PCI DSS.

Respecto al segundo concepto sobre la necesidad de aislamiento mediante segmentación, lo más destacable, a nuestro juicio es que pone realmente difícil utilizar servicios de nube pública que no hayan sido pensados para cumplir con PCI DSS. Decimos esto porque obliga (en línea con lo establecido en el estándar para proveedores de servicio) a una total segmentación entre entornos de distintos clientes y con el propio proveedor sin ninguna conectividad entre ellos; es decir, no se puede compartir ningún elemento del sistema, ni aplicación, ni bases de datos, ni comunicaciones... en definitiva, realmente complejo pensar en una aplicación SaaS que pueda ser eficiente si tenemos que aplicar todas estas medidas de segmentación. Como mucho, podremos ver servicios de plataforma o infraestructura. En cualquier caso, en relación a este concepto nos gustaría destacar las siguientes ideas recogidas en el suplemento:

• La segmentación debe proporcionar un aislamiento equiparable al que obtendríamos con una separación física de redes.
• Sin una adecuada segmentación, todos los clientes de la infraestructura compartida, así como el propio proveedor, tendrán que cumplir con PCI DSS para que cualquiera de sus clientes pueda ser considerado como que cumple con el estándar. Es decir, todos ellos estarán considerados en el alcance de la evaluación de cumplimiento de cualquiera de ellos, haciendo prácticamente imposible alcanzar el cumplimiento.
• El proveedor debe asumir la responsabilidad de establecer los mecanismos de segmentación adecuados entre clientes y con el propio proveedor, evitando que incluso el hypervisor o cualquier otra sistema subyacente puedan suponer una vía de comunicación entre ellos.
• Los mecanismos de segmentación a utilizar serían los mismos que los utilizados en un entorno no virtualizado: cortafuegos y segmentación de red a nivel de infraestructura, cortafuegos, IPS, DLP a nivel de hypervisor y máquina virtual, uso de VLANes, aislamiento de procesos y recursos, almacenes de datos segmentados, autenticación fuerte de doble factor, segregación de tareas...
• La segmentación implementada debe ser validada, como siempre, por el QSA.
• Es importante entender las relaciones del proveedor con terceros, puesto que añaden complejidad a la delimitación del alcance y al objetivo de cumplir con el estándar.
• Las recomendaciones para reducir el alcance serían:
• No utilizar servicios en la nube (¡¡¿?!!)
• Utilizar una infraestructura dedicada (¡¡¿?!!) solo para el entorno incluido en el alcance
• Minimizar la dependencia en el proveedor para cumplir con los requerimientos (es decir, utilizar servicios en los que el cliente mantenga más el control: IaaS o, como mucho, PaaS).
• Tratar de evitar que los datos estén en claro en la nube [Esta es la única recomendación como tal]
• En relación a la propia evaluación, si el cliente no ha sido evaluado, debe ser incluido en la evaluación de cumplimiento del cliente y, entonces, deben establecerse SLAs que claramente identifiquen el permiso del proveedor a ser auditado y la parte de las tareas que van a ser realizadas por cada uno de ellos.

Finalmente, en relación a la tercera idea de mantenimiento a lo largo del tiempo, obviamente el documento recoge la necesidad de que el cumplimiento se mantenga durante la prestación del servicio y el proveedor debe demostrar cómo se mantiene dicho cumplimiento en el tiempo.

Como último punto de nuestro análisis, destacar también que el documento incluye un apartado final (el séptimo) con la guía que sugiere a los clientes antes de adoptar un servicio en la nube (ENTENDER, COMPARAR, EVALUAR, CONOCER...), así como un apéndice (el D) con preguntas a realizar al proveedor como orientación para todo este proceso de due diligence.

En definitiva y como resumen, una guía que desalienta bastante la utilización de servicios en la nube  (especialmente los de SaaS públicos) para aquellos que se lo estuvieran pensando...

... ¿todavía no me sigues en twitter.com/antonio_ramosga?

Mega, la nueva generación de servicios cloud. Casualidad o visión

Este artículo se publicó originalmente en el blog de INTECO.

Mucho se ha escrito sobre MEGA, el nuevo servicio de Kim Dotcom y sucesor de Megaupload, desde que lo lanzara el pasado 20 de enero, justo al cumplirse un año de su detención. El objetivo de esta entrada es reflexionar sobre las características de dicho servicio pero desde una perspectiva ligeramente distinta, o al menos, eso es lo que se pretende.

En primer lugar, me gustaría llamar la atención sobre el aspecto de la fragmentación y dispersión de los contenidos puesto que creo que no ha sido tratado con la suficiente relevancia. Una de las características del servicio es que, del mismo modo que hace Google, fragmenta la información que el usuario sube a la nube y la dispersa por múltiples localizaciones, además de manera reiterativa, de forma que actúa como mecanismo de contingencia. De esta forma, Mega lo que custodia son los índices que apuntan a dichos fragmentos, de manera que cuando el usuario quiere acceder a esa pieza de información sabe dónde tiene que ir a buscar los fragmentos que lo componen para recomponerla y, además, como tiene varias copias de cada fragmento, puede acceder a la unidad que más rápido responda a la petición. En definitiva, un mecanismo que asegura que en el caso de que un centro de procesamiento se caiga, el servicio podría seguir funcionando o que si alguien accede a una de esas unidades de almacenamiento no va a poder recuperar ninguna pieza de información completa solo fragmentos "sin sentido".

Como digo, me parece un mecanismo tremendamente resiliente y que, aunque ha sido pensado para evitar que un país pueda "desenchufar" el servicio de manera unilateral (como le ocurrió a Megaupload), tiene derivadas para la seguridad del sistema que lo hacen increíblemente seguro (evidentemente la pieza clave, son los índices y quién puede acceder a ellos). Pero, lo que me gustaría destacar es su importancia en lo relativo al cumplimiento de la legislación en materia de protección de datos. Actualmente, la legislación nos obliga a saber en qué país se encuentran nuestros datos, pero… si utilizamos este sistema, ¿en qué país o países se encuentran? ¿en todos en los que Mega tiene almacenamiento? ¿en algunos? Y lo que me parece más importante, ¿realmente podemos considerar que lo que tiene Mega son datos de carácter personal? Me refiero a que si subo mi nombre (Antonio Ramos) a Mega y lo que hace el servicio (perdonad la simplificación de este ejemplo) es fragmentar esta pieza de información y almacenar la cadena ’Anto’ en Singapur y EE.UU., ’nioR’ en España y Nueva Zelanda y ’amos’ en Alaska y en Noruega… ¿realmente está ese dato en todas esas ubicaciones? ¿sólo dónde estén los índices? Creo que es una cuestión realmente relevante, porque este tipo de almacenamiento podría llegar a simplificar el cumplimiento tremendamente.

Además, si a esto le unimos, el segundo aspecto, el cifrado de la información controlada por el usuario (y observar que digo cifrado, por favor), al margen de las mejoras que dicho mecanismo puede tener técnicamente y suponiendo que hace realmente lo que dice, es decir, que Mega no tiene acceso a la información porque está cifrada con una clave que tiene el usuario que sube la información, ¿realmente podemos considerar esa información como un dato de carácter personal? Aquí he de decir que comparto la postura de PCI-DSS en relación a este tema: Si el proveedor custodia información cifrada de la cual no tiene la clave de descifrado, no se considera que es un dato de titular de tarjeta y, por tanto, queda fuera del alcance del estándar. Por tanto, ¿no podríamos considerar que la información cifrada, siempre que no haya acceso a la clave de descifrado, no se considera dato de carácter personal y por tanto no hace falta cumplir las medidas en dichos casos?

Al igual que en el caso previo, una medida que se ha pensado para exonerar a Mega de responsabilidad sobre los contenidos, tiene una implicación de gran relevancia: La responsabilidad sobre los contenidos es únicamente de quien siempre es, de su propietario. Es decir, estamos acostumbrados a que existan dudas sobre quién debe hacer qué en los servicios en la nube y el reparto de tareas es siempre algo dudoso. Pero además de esto, incide sobre otro aspecto que a mi juicio es aún más importante. En estos días, son muchos los que hablan insistentemente sobre la necesidad de confiar en los proveedores de servicios en la nube, pero yo defiendo otra postura, directamente no confiar en el proveedor. ¿A qué me refiero? Me refiero a que cuando queremos garantizar el suministro eléctrico de nuestro CPD, contratamos dos acometidas de distintos proveedores. Esto mismo hacemos cuando queremos garantizar las comunicaciones. Y es lo mismo que hacemos con las copias de respaldo… y si lo hacemos en tantas ocasiones, ¿por qué no lo hacemos en la nube? ¿por qué ponemos todo en el mismo proveedor y pretendemos que sea infalible? ¿Desde cuándo tener un solo cliente / proveedor no es un going concern en un informe de auditoría? Evidentemente, debemos esperar una calidad de servicio razonable y tener mecanismos de penalización en caso de que no sea así y, aún más, debemos tener mecanismos que garanticen la interoperabilidad de los servicios, pero, no debemos perseguir quimeras: No podemos pretender que nuestro proveedor sea infalible.

En definitiva, pienso que Mega ha puesto el dedo en la llaga y no sé si lo han hecho por casualidad o porque son unos visionarios, pero, en mi opinión, han acertado de pleno.

... ¿todavía no me sigues en twitter.com/antonio_ramosga?

Análisis: PCI DSS Risk Assessment Guidelines

Este artículo se publicó originalmente en n+1 tiende a infinito, el blog de n+1 Intelligence & Research.

El pasado mes de noviembre, el PCI Council publicó el suplemento informativo titulado "PCI DSS Risk Assessment Guidelines" (pdf) orientado a ampliar detalles para cumplir con el requerimiento 12.1.2 que exige que las políticas de seguridad "incluyan un proceso anual que identifique amenazas y vulnerabilidades y concluya con un análisis de riesgos formal".

La estrategia propuesta por el Council es incorporar este análisis de riesgos al programa de gestión de riesgos corporativo e incluir en el mismo los procesos externalizados o gestionados por terceros.

Pero lo más relevante desde nuestro de vista es que la guía responde a la pregunta: Si el estándar PCI-DSS ya establece los requisitos mínimos de protección para los datos de titulares de tarjeta, ¿para qué es necesario llevar a cabo un análisis de riesgos? Pues bien, la respuesta es clara:

• Los resultados del análisis de riesgos no pueden ser usados como un medio de evitar el cumplimiento de los requisitos incluidos en PCI-DSS.
• PCI-DSS incluye el conjunto mínimo de requisitos para proteger los datos de titulares de tarjeta.
• Pero, estos requisitos pueden ser complementados por controles adicionales para mitigar riesgos que hayan sido detectados por dicho análisis de riesgos.

Al margen de esto, pocas novedades dignas de destacar para cualquiera que haya realizado antes un análisis de riesgos:

• Fases típicas: Identificación de activos críticos y de las amenazas sobre dichos activos, identificación de vulnerabilidades y desarrollo de una estrategia de riesgos y un plan de mitigación del riesgo.
• Elementos habituales: Preparación de un equipo para el análisis, elaboración de una metodología adaptada a la cultura de la organización, identificación del riesgo (establecer el contexto, identificación de activos, de amenazas y de vulnerabilidades), caracterización del riesgo cuantitativa o cualitativa y plan de tratamiento del riesgo.
• Quizás la parte más interesante sea el enfoque para la gestión de riesgos de procesos subcontratados por terceros donde caben varias opciones:
1. Evaluación del cumplimiento con PCI-DSS realizada por un QSA y el correspondiente ROC o Cuestionario de Auto-Evaluación.
2. Realización de un análisis de riesgos del tercero con recursos propios o de manera compartida para saber si se están tratando los riesgos a satisfacción de la organización.

En definitiva un documento que, en realidad, aporta muy poca información adicional a lo ya establecido en el propio requerimiento del estándar PCI-DSS.

... ¿todavía no me sigues en twitter.com/antonio_ramosga?

PCIP - Payment Card Industry Profesional

(Publicación cruzada en n+1 tiende a infinito)

El pasado mes de septiembre, el PCI SSC publicó los requisitos para su nuevo programa PCIP - Payment Card Industry Profesional es decir, Profesional de la Industria de Tarjetas de Pago que viene a cubrir el espacio que no cubren los QSA, ASV, ISA, PFI y QIR... es decir, básicamente consultoras/es que no trabajen en QSAC (compañías homologadas por el Council).

Esta credencial (que permite usar las siglas en las firmas y el logotipo correspondiente) tiene una gran ventaja y es que no depende de la empresa en la que el profesional trabaje, es decir, es personal y puede "viajar" con la persona si esta cambia de compañía, siempre que cumpla con los requisitos de renovación establecidos, lógicamente.

Fundamentalmente los requisitos para obtener la acreditación (pdf) son:

1. Abonar la cuota correspondiente [995 USD por la solicitud]
2. Aprobar el examen (se realiza online en las instalaciones de Pearson VUE y no se puede llevar ningún tipo de material de apoyo)  [395 USD por los derechos de examen]
3. Tener al menos 2 años de experiencia y no haber tenido alguna conducta en el pasado que el Council considere incompatible con la acreditación.

Por cierto, si eres QSA o ISA solo tienes que cumplir con el primer punto, puesto que los restantes los has tenido que cumplir previamente.

Esto quiere decir que esta acreditación tiene un coste inicial de 1.390 USD y decimos inicial porque, si quieres recibir la formación diseñada al efecto, hay que añadir, otros 1.250 USD, es decir, nos iríamos a 2.640 USD. Por suerte, el mantenimiento no es muy caro, el mantenimiento solo cuesta 99 USD y los éxamenes de renovación (que son bienales) cuestan los mencionados 395 USD.

Para  finalizar, mencionar que el examen consta de 60 preguntas de elección múltiple, de momento, sólo en inglés y el tiempo para responderlo es de 90 minutos (1,5 minutos por pregunta).

¿Qué? ¿Os animáis?

... ¿todavía no me sigues en twitter.com/antonio_ramosga?

Resumen de comentarios a la versión de PCI DSS

En estos momentos nos encontramos en la etapa 6 del ciclo de vida de PCI DSS, "Feedback Review" o revisión de comentarios y el PCI Security Standard Council ha publicado un resumen de los comentarios que ha recibido (pdf) que me ha parecido interesante porque, se supone, que la nueva versión del estándar incluirá modificaciones y/o aclaraciones, sobre todo, en esos puntos.

Los puntos más comentados (suponen más de la mitad del total, el 54%) han sido los siguientes:

• Requerimiento 11.2 [13%] - Prescribir el uso de herramientas específicas, solicitar a los ASV la realización de escaneos internos y definir que supone un "cambio significativo".
• Alcance [10%] - Proporcionar una guía detallada para definir el alcance y la segmentación.
• Requerimiento 12.8 [8%] - Clarificar los términos "proveedor de servicios" y "compartido" y proporcionar unos requerimientos más prescriptivos para los acuerdos escritos que aplican a los proveedores de servicio.
• SAQs [8%] - Considerar actualizar los SAQs; son, o bien, demasiado complejos (difíciles de comprender) o bien no son suficientemente detallados.
• Requerimiento 3.4 [8%] - Los requerimientos de gestión de clave y de cifrado son complejos; proporcionar una mayor claridad. El truncado / tokenizado / hashing no es un método conveniente para almacenar y recuperar datos; proporcionar mayor guía.
• Requerimiento 8.5 [7%] - Considerar actualizar los requisitos de las contraseñas (expandir la autenticación más allá de las contraseñas). Los requisitos actuales sobre contraseñas son muy o poco estrictos; ser más o menos prescriptivos.

Ya veremos como queda la nueva versión del próximo verano...

... ¿todavía no me sigues en twitter.com/antonio_ramosga?

¿Cuál es la madurez de los servicios cloud?

(Publicación cruzada con el blog de INTECO)

Pues si hacemos caso a CSA e ISACA habría que decir que se encuentran en su más tierna infancia. Efectivamente esta ha sido la conclusión del estudio que han realizado ambas organizaciones y en el que he tenido el placer de colaborar. Sobre la base de una encuesta en la que han participado 252 organizaciones de 48 países (principalmente en Norteamérica - 48% - y Europa - 23% - y usuarios de SaaS - 62%) se ha concluido que, considerando cuatro niveles de madurez (infancia, crecimiento, madurez y declive), los servicios de infraestructura y plataforma como servicio (IaaS y PaaS, respectivamente) se encuentran en la etapa inicial y los de software como servicio (SaaS) están entrando en la fase de crecimiento.

Y, aunque la conclusión es que el mercado piensa que los servicios en la nube están cumpliendo las expectativas estratégicas y de servicio y que los problemas serán superados, no es menos cierto que se identifican ciertas preocupaciones:

• Que la computación en la nube sea considerada un aspecto técnico (una nueva versión del típico outsourcing) y que, como está pasando, sus riesgos sean analizados como riesgos tecnológicos más que como riesgos de negocio, puesto que este tratamiento limitará el potencial la nube.
• Las dificultades existentes para especificar los riesgos técnicos y de negocio en los contratos.
• La longevidad del proveedor.
• La comprensión de las responsabilidades del propietario de datos y del custodio.
• Los aspectos legales.
• El lock-in en los contratos.
• La disposición de estrategias de salida en caso de querer volver a un tratamiento in house o ir a otro proveedor.
• Las regulaciones gubernamentales porque sigan una evolución muy diferente al mercado.
• Y, en definitiva, que los usuarios necesitan confiar en los servicios por lo que los mecanismos de garantía y de transparencia deben mejorar.

Frente a esto, los participantes en el estudio también han identificado los aspectos que están siendo adecuadamente contemplados por la computación en la nube:

• La disponibilidad
• La continuidad del negocio
• La recuperación en caso de desastres
• El rendimiento del servicio
• Los cortes en el servicio
• La resolución de problemas

Finalmente, destacar que los factores que inciden en la toma de decisiones son, por orden de importancia:

1. Los facilitadores de negocio (principalmente, fiabilidad y disponibilidad)
2. Las consideraciones financieras (especialmente, la reducción de costes)
3. La reducción de la huella en el medio

Como se puede ver, un estudio que nos ayuda a entender la situación actual, que dibuja un futuro esperanzados para la computación en la nube y que nos ayuda a identificar los retos para los próximos años… veremos si somos capaces de superarlos…

... ¿todavía no me sigues en twitter.com/antonio_ramosga?

¿Entran los datos de pre-autorización en el alcance de PCI DSS?

(Publicación cruzada en n+1 tiende a infinito)

El asunto de los datos sensibles de autenticación antes de la autorización de la operación siempre ha sido una cuestión delicada... básicamente, porque PCI DSS establece requerimientos para estos datos post-autorización pero deja los datos pre-autorización en una nebulosa. Concretamente, el requerimiento 3.2 reza: "No almacenar los datos sensibles de autenticación después de la autorización (ni cifrados)". 

Pero, efectivamente nada sobre estos datos antes de la autorización, por tanto, ¿qué hacemos con ellos? ¿Están incluidos en el alcance de PCI-DSS o no? 

Pues, para solventar estas dudas, como siempre, lo mejor es recurrir a la sección de preguntas frequentes del PCI Security Standard Council, en este caso al artículo 12917, que reproducimos de manera íntegra por su interés y claridad:

"Sí, PCI DSS aplica siempre que se almacenen, procesen o transmitan datos de titulares de tarjeta (CHD) y/o datos sensibles de autenticación (SAD) con independencia de que sea pre-autorización o post-autorización. No existen reglas específicas en PCI DSS sobre cuánto tiempo pueden almacenarse este tipo de datos (CHD o SAD) antes de la autorización, pero necesitan ser protegidos de acuerdo a PCI DSS. El uso de dispositivos de pago validados PTS y aplicaciones de pago validados PA-DSS pueden ayudar al cumplimiento de PCI DSS para la protección de estos datos antes de la autorización.

En relación a los SAD, el requerimiento 3.2 prohíbe el almacenamiento de los SAD DESPUÉS de la autorización, incluso cifrados. Si se permite almacenar los SAD antes de la autorización lo determinan las marcas de tarjetas de manera individual, incluyendo cualquier uso relacionado y los requisitos de protección. Adicionalmente, varias marcas de tarjetas tienen reglas muy concretas que prohíben cualquier almacenamiento de SAD y no hacen ninguna excepción. Para determinar los requisitos de las marcas de tarjetas, contacte directamente con las marcas de tarjeta directamente." 

En resumen, debemos preguntar a las marcas si se nos permite almacenar estos datos antes de la autorización y, en ese caso, qué medidas de seguridad debemos aplicarles para su protección... o como suelen decir: "Depende".

... ¿todavía no me sigues en twitter.com/antonio_ramosga?

Lectura: "El sueño del celta"

Acabo de terminar la obra de Mario Vargas Llosa (Premio Nobel de Literatura, 2010) que cuenta la historia del héroe independentista irlandés, Roger Casement. Según el propio autor, "héroe y villano, traidor y libertario, moral e inmoral".

Como siempre después de acabar un libro, me gusta compartir las cosas que más me han llamado la atención. En este caso, hay tres fragmentos que me gustaría compartir.

El primero trata sobre esa resistencia al cambio con la que tienes que luchar algunas veces que te hace sentir como sumergido en miel... todo el mundo parece que está en línea, pero la cosa no acaba de cambiar [recuerdo alguna etapa pasada de mi vida profesional en la que me he sentido así]:

"Todo era así. Roger se sentía mecido en un remolino adormecededor, dando vueltas y vueltas en el sitio, manipulado por fuerzas tortuosas e invisibles. Todas las gestiones, promesas, informaciones, se descomponían y disolvían sin que los hechos correspondieran jamás a las palabras. Lo que se hacía y lo que se decía eran mundos aparte. Las palabras negaban los hechos y los hechos desmentían a las palabras y todo funcionaba en la engañifa generalizada, en un divorcio crónico entre el decir y el hacer que practicaba todo el mundo."

El segundo, es una reflexión del protagonista sobre la idoneidad de invertir en recuperar un idioma perdido:

"... comenzó a preguntarse si era realista, si no resultaba una quimera [...], creer que se podía resucitar la lengua que el colonizador persiguió y volvió clandestina, minoritaria y casi extinguió y convertirla de nuevo en la lengua materna de los irlandeses. ¿Era posible que en la Irlanda futura el inglés retrocediera y, gracias a los colegios, a los diarios, a los sermones de los párrocos y discursos de los políticos, lo reemplazara la lengua de los celtas? [...] Sin embargo, en la soledad de su escritorio [...], se decía que aquél era un empeño inútil. La realidad había avanzado demasiado en una dirección para torcerla [...] y querer renunciar a ello era un capricho político del que sólo podía resultar una confusión babélica y convertir culturalmente a su amada Irlanda en una curiosidad arqueológica, incomunicada con el resto del mundo. ¿Valía la pena?"

Y, el tercero, la reflexión final del propio Mario Vargas Llosa sobre la personalidad del protagonista, del héroe de su obra:

"Lentamente sus compatriotas se fueron resignando a aceptar que un héroe y un mártir no es un prototipo abstracto ni un dechado de perfecciones sino un ser humano, hecho de contradicciones y contrastes, debilidades y grandezas, ya que un hombre, como escribió José Enrique Rodó, "es muchos hombres", lo que quiere decir que ángeles y demonios se mezclan en su personalidad de manera inextricable."

... ¿todavía no me sigues en twitter.com/antonio_ramosga?

Al César lo que es del César y al cloud lo que es del cloud

Es comprensible que existan dudas en relación a nuevas tecnologías o a nuevos modelos de servicio, más aún, cuando el éxito de éstos supone una modificación sustancial del status quo.

Por si todavía teníais alguna duda, os lo confirmo, nos referimos a la informática en la nube, o el más conocido, cloud computing. Efectivamente la nube supone un cambio en la provisión de servicios TIC que, pasan de algo que se fabrica internamente a algo que se nos suministra como un servicio por un tercero, lo que conlleva el cambio de rol de los departamentos TIC de las organizaciones.

Además, la difusión del cloud computing supone la más que posible concentración de servicios en un puñado de proveedores en detrimento de muchos otros.

Por eso podemos entender, porque es humano, que pongamos el énfasis en aquellos aspectos que nos hagan pensar detenidamente antes de adoptar soluciones en la nube, para intentar mantener el status quo.

En definitiva, el cloud computing no deja de ser un caso particular de un outsourcing informático, algo que lleva con nosotros más de una decada y que se encuentra perfectamente integrado en la operativa habitual. De hecho, si analizamos cualquier estudio sobre el cloud nos encontraremos con muchos retos, amenazas... frenos en definitiva, que NO son específicos de la nube, sino comunes a cualquier proceso de externalización.

Cogiendo como ejemplo el reciente informe publicado por el ONTSI (Observatorio  Nacional de las Telecomunicaciones y de la Sociedad de la Información) sobre el estado del cloud computing en las PYMEs (pdf) que fue presentado el pasado día 28 de mayo, nos encontramos con preocupaciones que serían comunes a cualquier proceso de outsourcing:

• Confidencialidad
• Seguridad
• Pérdida de control sobre los procesos
• Dependencia adquirida con el proveedor de servicios
• Disponibilidad de los servicios
• Integridad de los servicios
• Temor acerca de la falta de conexión a Internet / latencia
• Costes del proceso de migración
• Impacto organizativo y de adaptación y gestión del cambio del personal propio
• Contar con modelos contractuales ajustados
• Integración de servicios contratados

En mi opinión creo que deberíamos ser justos con el cloud computing y al analizarlo deberíamos considerar de manera diferente los frenos que son iguales que en otros casos de outsourcing de los que son más "específicos" de la nube (bien porque sólo se den en este caso o porque los exagere) como, por ejemplo:

• Riesgo de seguridad adicional por la concentración de activos tecnológicos
• Nueva capa en la que pueden surgir vulnerabilidades (hipervisor)
• Riesgos asociados a la multi-tenencia

... ¿todavía no me sigues en twitter.com/antonio_ramosga?

El Hormiguero: Concienciación en seguridad de la información

Lo reconozco: Soy fan de El Hormiguero desde sus comienzos... me ayuda a desconectar. Desde que oía la frase: "¡Relájate!"... pues eso, me relajaba y me ayuda a desconectar del día a día.

Y para mi alegría, hace un par de semanas, durante la visita de Macaco, asistimos a 90 segundos sobre concienciación en seguridad en prime time. Ya sé que es un tema muy sencillito: La necesidad de hacer copias de respaldo, pero bueno, algo es algo...

Os dejo con el vídeo. La parte interesante comienza en el 1:30...

Más vídeos en Antena3

... puedes seguirme en twitter.com/antonio_ramosga

Mi haiku

Me gustó una entrada que leí hace algún tiempo en the [non]billable hour en la que proponen a modo de haiku, un ejercicio de simplicidad para contar a lo que nos dedicamos.

Ya sabéis que un haiku es ese poema breve japonés de tres versos de cinco, siete y cinco sílabas respectivamente (definición de la Wikipedia), pero el ejercicio propuesto cambia las sílabas por palabras. En concreto, lo que nos proponen es responder a tres preguntas utilizando cinco, siete y cinco palabras, respectivamente.

Las tres preguntas que tenemos que responder para crear el haiku de lo que hacemos son las siguientes:

• ¿A quién ayudo? (responder con 5 palabras)
• ¿Qué hago por ellos? (responder con 7 palabras)
• ¿Por qué me necesitan? (responder con 5 palabras)

Me ha parecido un ejercicio interesante e innovador para el típico elevator pitch, ¿qué? ¿Os animáis?

Yo os dejo aquí el mío como consultor en seguridad...

Ayudo a organizaciones con información 

a resolver problemas de seguridad en sistemas

con soluciones eficaces y eficientes

... puedes seguirme en twitter.com/antonio_ramosga

Comentarios al Estudio de Seguridad Privada de Fundación ESYS

El pasado 29 de febrero, la Fundación ESYS presentó en el marco de SICUR su "Estudio de Seguridad Privada en España. Estado de la Cuestión 2012" (pdf). Gracias a ISACA Madrid, he tenido la oportunidad de seguir de cerca la elaboración de este estudio y me parecía interesante analizar sus conclusiones como continuación a entradas anteriores relacionadas con la convergencia de la seguridad.

Antes de entrar en materia, creo que deberíamos aclarar que tradicionalmente se consideran tres tipos de apellidos para la seguridad: la seguridad física, la seguridad de la información y la ciberseguridad. La primera se encargaría de los activos físicos (edificios, personas, instalaciones...), la segunda protegería la información en sus distintos formatos (donde los sistemas de información tienen un peso relevante pero no exclusivo) y la última se centraría en las amenazas ciber. Considero este aspecto importante porque ayuda a entender mejor la situación:

• La seguridad de la información incluye la seguridad informática pero también ciertos aspectos de seguridad física (protección de la información en papel, protección de los servidores...)
• Se producen ciertas áreas de solape, por ejemplo, a la hora de proteger la información en papel, ¿quién es responsable?

Por este motivo, habría preferido que en el estudio se hiciera referencia a la ciberseguridad en lugar de a la seguridad informática, creo que hubiera sido más acertado.

Entrando en materia, lo primero que llama la atención es que, al margen de los problemas que puedan existir en la seguridad física, 8 de las 14 conclusiones hacen referencia a la ciberseguridad y 2 de ellas son comunes.

En relación a estas conclusiones, me gustaría comentar lo siguiente:

• No considero que la ciberseguridad requiera de una regulación específica, más bien la regulación en materia de seguridad debe contemplar todas sus perspectivas, no solo la seguridad física (como ocurre actualmente).
• Coincido, por tanto, en que debe realizarse desde una perspectiva integral, pero entendiendo las diferencias que existen entre ambos ámbitos y, lógicamente, sin que ninguna perspectiva tenga ninguna prevalencia sobre la otra.
• Se me antoja complicada la elaboración de baremos que permitan valorar la calidad del servicio prestado de manera general dadas las múltiples variantes de servicio que existen pero, bueno, es cuestión de trabajarlo, tampoco es imposible.
• También coincido en la necesidad de contar con información estadística sobre incidentes de ciberseguridad, para que sea posible aprender y entender lo que está pasando y la evolución de las amenazas.
• Respecto a la formación reglada, es cierto que existen múltiples posgrados y másteres en seguridad de la información por lo que el asunto no es tanto que no exista una formación reglada adecuada sino que, más bien, sea reconocida u homologada la existente.
• Finalmente, en cuanto a la responsabilidad, no sé si debe existir una sola persona o no que aglutine toda la responsabilidad en materia de seguridad, lo que desde luego es obligatorio en el mundo actual es que ambas funciones estén coordinadas.

Por otra parte, las propuestas de actuación se han clasificado en: Marco legal, relación público-privada, profesionalidad y formación y reconocimiento social. En relación a estas propuestas, también me gustaría comentar algunos aspectos:

• La regulación que se establezca para la ciberseguridad debe contemplar / entender las particularidades de la misma y no tratar de replicar los mismos conceptos porque es posible que algunos no tengan mucho sentido.
• La coordinación, en caso de incidentes, entre los ámbitos públicos y privados es fundamental. En este sentido todo lo que se pueda avanzar en colaboraciones entre CSIRTs públicos y privados será de agradecer.
• Las titulaciones oficiales no deben tratar de regular las funciones de las personas en las organizaciones (Director, Jefe, etc... ) más bien, deben centrarse como en cualquier otra práctica en garantizar unos conocimientos mínimos y luego, cada organización decidirá lo que hace falta para cada puesto.
• Finalmente, el tratar de hacer avanzar la seguridad a través del canal de la Responsabilidad Social Corporativa lleva siendo explotado durante bastante tiempo por la ciberseguridad con unos resultados bastante escasos. Desde mi punto de vista, me parece mucho más adecuado que se integre en el ámbito de la protección civil.

En cualquier caso, me parece un primer acercamiento a la situación que vivimos actualmente y que puede servir para empezar a caminar en una mejora de la protección gracias a la colaboración entre seguridad física y lógica. Ya veremos lo que nos depara el futuro.

... ¿todavía no me sigues en twitter.com/antonio_ramosga?

Aplicar velocidad a la seguridad

Tras la lectura de "Velocidad" que comentamos la semana pasada, me hice la pregunta de si podrían aplicarse estos principios al mundo de la seguridad.

Y desde luego, hay una lectura que creo que puede ser de mucha utilidad para los profesionales de la seguridad. Derivado del principio de TOC de que lo que importa es la maximización del rendimiento del sistema en su totalidad y no los óptimos locales [y que, precisamente, es la causa principal del fracaso de Lean en la mencionada novela], los profesionales de la seguridad deberíamos preguntarnos si las medidas que estamos proponiendo contribuyen a un mayor rendimiento del sistema global (es decir, la organización en todo su conjunto) o si, por el contrario, nos estamos limitando a generar óptimos locales.

Es decir, tendríamos que centrarnos en la organización en su conjunto, identificar la limitación del sistema y:

• trabajar para que dicha limitación siempre esté operativa. Es decir, implantar los mecanismos preventivos para que dicha limitación no sufra percances, pero también medidas detectivas para identificar la materialización de incidentes y, finalmente, medidas reactivas para que el impacto sea el menor posible. Lo que en terminología TOC se denominaría subordinarse a la limitación.
• valorar las nuevas medidas en función de si contribuyen a un mayor rendimiento o a menores costes operativos o inventarios. Estas son las tres principales medidas utilizadas por TOC para la contabilidad y que, en el fondo, afectan a todas las decisiones empresariales.

En este contexto, habría que considerar que:

• Posiblemente, la limitación no estará aislada y puede ser que se vea afectada por un fallo de seguridad de algo que, no siendo propiamente la limitación, esté conectado a ella. Por ejemplo, si la limitación fuera nuestra página web, quizás podamos tener una intrusión no directamente sobre el servidor web, sino cualquier otro sistema en la misma DMZ (por ejemplo). Por tanto, tendremos que analizar vías para reducir los elementos que pueden afectar al correcto funcionamiento de la limitación del sistema.
• Existirá legislación que tengamos que cumplir y que, como condición necesaria para operar en un mercado haya que cumplir, con independencia de su relación con la limitación.

Por otra parte, es interesante como los principios de lean hablan de minimizar el despilfarro, como la "eliminación de todas las actividades que no son de valor añadido y redes de seguridad", es decir, que por aligerar los procesos no debemos hacerlos inseguros...

Finalmente, se pueden aplicar todos los principios lean a los procesos de seguridad que diseñemos, eliminando todo tipo de desperdicio: movimiento, sobreproducción, espera, transporte, procesado extra, corrección, inventario y el conocimiento desconectado. Pero sin olvidar que todo lo hacemos subordinados a la limitación del sistema...

¿Qué os parece el planteamiento? ¿Arriesgado?

... ¿todavía no me sigues en twitter.com/antonio_ramosga?

Lectura: "Velocidad"

Esta es la última obra que he leído de las novelas de gestión sobre la temática de TOC. En este caso, los autores (Dee Jacob, Suzan Bergland y Jeff Cox - el mismo que escribió La Meta) abordan la problemática de emplear a un mismo tiempo el sistema Lean, Seis Sigma y la propia Teoría de las Limitaciones.

Se trata de una obra de lectura fácil que aborda bastantes de los elementos de TOC: la multitarea en contraste con el sistema de delay, los árboles de la realidad actual y futura, la subordinación de la producción a la limitación, la elevación de las limitaciones o no... aderezada por algunas perlas como la explicación de cómo la facturación por horas es un incentivo a la ineficiencia (algo que ya hemos tratado antes por aquí).

En este caso, no tengo citas preparadas (como de costumbre) pero, a cambio, tengo un concepto que me parece que puede resultarnos muy útil: poka-yoke. Este término que se utiliza en el sistema Lean, es un término que proviene del japonés y significa literalmente "a prueba de errores". Un ejemplo claro, como nos dice la Wikipedia es el conector USB ya que no permite conectarse al revés, solo de la forma correcta.

Y, ¿por qué digo que puede ser útil? Bueno porque muchos fallos de seguridad se producen por errores y si adoptáramos la filosofía poka-yoke podríamos, en teoría, evitarlos... vamos algo así como "seguro por defecto".

Puedes seguirme en twitter.com/antonio_ramosga