El problema del Cloud Computing

Que el cloud computing es algo más que una moda es evidente. Ha nacido para quedarse, y haríamos mal en intentar negarlo o no darle la importancia que se merece. Muchas organizaciones lo están adoptando o acabarán haciéndolo, nos guste o no a los que trabajamos en el ámbito de la seguridad. Quizás los profesionales del sector de la seguridad hayamos pecado a veces de idealistas, de precavidos, maximizando unos inconvenientes que desde el punto de vista del negocio van a ser en muchos casos asumibles. Pero lamentablemente también es cierto que el negocio se ha dejado impresionar más veces de las que debería por un planteamiento que en ningún caso es la panacea que nos quieren vender los proveedores de servicios cloud. Y es que, en el fondo, el problema del cloud computing no es un problema de seguridad, sino de negocio.

El planteamiento, como vais a ver, es muy simple. El negocio de un proveedor de servicios cloud son, obviamente, esos servicios: infraestructuras TIC, plataformas, aplicaciones... Su objetivo será maximizar el beneficio que le proporcionan esos servicios, tratando de ofrecérselos al mayor número de clientes posible. Por lo tanto, el objetivo será diseñar servicios lo más completos y universales que sea posible, manteniendo obviamente unos niveles de servicio aceptables.

Por el contrario, el negocio de un cliente de servicios cloud es... aquello a lo que se dedique cada cliente. Fabricación, transporte, energía, servicios públicos... Lo que sea. Para ello hará uso de los mejores medios tecnológicos que pueda conseguir. Y entre estos medios aparecerán, como no, diferentes servicios informáticos. Algunos los implementará el departamento TI de la propia organización, y otros tratará de conseguirlos en forma de servicios cloud. Y aquí es donde se produce el problema.

El cliente va a requerir que los servicios informáticos que utiliza estén lo más alineados posible con su negocio. Dicho de otro modo, que sean lo más a medida posible. Sin embargo, el proveedor cloud va a tratar de ofrecer los servicios cloud que más encajen con su propio modelo de negocio, es decir, lo más genéricos y estándares posible. Y obviamente esto va a producir un importante desencuentro entre ambos planteamientos.

En este punto, y no antes, es donde entra en juego la seguridad. Cada cliente, dentro de su modelo de negocio, va a tener unos requisitos de seguridad específicos. Si en su actividad trata datos de carácter personal de nivel alto, requiere que los servicios informáticos cumplan con las medidas de seguridad definidas por el RDLOPD. Si gestiona datos de tarjetas de crédito necesita que los servicios implementen las medidas de seguridad exigidas por PCI-DSS. Si es una administración pública, necesitará que los citados servicios cumplan con las medidas de seguridad exigidas por el ENS para el nivel que corresponda en cada caso. Sencillamente, porque su negocio se lo exige.

Lamentablemente, los actuales proveedores de servicios cloud no suelen ser capaces de responder adecuadamente a estas exigencias. Cada vez podemos encontrar más proveedores de servicios cloud que presumen de seguridad, se certifican en ISO 27001, cumplen con la directiva europea de protección de datos... y piensan que eso es suficiente. No se dan cuenta de que es suficiente para SU modelo de negocio, pero puede no serlo para el de sus clientes. Un cliente español que trate datos personales de nivel alto mediante una aplicación SaaS necesita que el log del registro de accesos a la base de datos de dicha aplicación esté bajo el control directo del responsable de seguridad, lo cual va más allá de cualquier directiva europea de protección de datos o certificación ISO 27001. Del mismo modo, un cliente que trate información confidencial o de carácter estratégico a nivel europeo debería pensárselo mucho antes de contratar un proveedor de servicios cloud estadounidense, sujeto a la Patriot Act por mucho que sus datos no vayan a salir de territorio europeo. ¿Cuántos proveedores de servicios cloud estadounidenses podrían garantizar el suficiente nivel de confidencialidad frente a este hecho?

En definitiva, no podemos olvidar que un proveedor de servicios cloud no es ni más ni menos que una empresa, con sus propios intereses, modelo de negocio y restricciones legales. Por lo tanto, en caso de querer hacer uso de los servicios informáticos que ofrece habrá que evaluar detenidamente si todas esas particularidades son compatibles con nuestro propio modelo de negocio y con los requisitos funcionales, legales y de seguridad que sean aplicables al uso que queremos hacer de esos servicios. Que no hay inconveniente? Adelante, seguro que el modelo cloud aporta grandes beneficios a nuestra organización. Que sí que los hay? Buenas noticias para el departamento de TI, que seguro que hace todo lo posible para demostrarnos que la decisión de no externalizar el servicio ha sido la adecuada.

Autogestión de la seguridad basada en el comportamiento del usuario

Reconozco que, cuando el día a día profesional aprieta, las prioridades mandan, y ciertos temas deben quedar relegados a un segundo término hasta encontrar un momento más apropiado para retomarlos. Y la lectura de artículos y publicaciones del sector es uno de estos temas, así que esa es mi "excusa" para no haber publicado antes este post.

Hace unos días leí un artículo de Edgard Ansola en la revista SIC, cuyo título he querido replicar en el del post, que realmente me encantó. Hacía mucho tiempo que no veía aparecer ideas realmente frescas en el ámbito de la gestión de la seguridad, y la verdad es que encontrarse con planteamientos tan sencillos e innovadores al mismo tiempo es un verdadero placer. Me encanta esa sensación de que todavía no está todo inventado y de que aún queda mucho camino por recorrer...

El artículo en cuestión propone una idea sencilla pero efectiva: conseguir que el propio usuario sea consciente del nivel de riesgo asociado a su comportamiento, para que de ese modo pueda corregirlo de forma autónoma. ¿Ingenioso, verdad? Pues si te ha picado el gusanillo y quieres conocer más detalles sobre la idea, te animo a que leas tú mismo el artículo y nos cuentes qué te parece la solución propuesta. Ánimo!

Los seguros tambien cuentan

Después de realizar un análisis de riesgos todos somos conscientes de que existen 4 estrategias posibles para gestionar esos riesgos: eliminarlos, transferirlos, reducirlos o asumirlos. Lo que ocurre es que normalmente sólo nos acordamos de las dos últimas opciones, obviando las posibilidades que nos ofrecen las dos primeras.

El parámetro principal para ayudarnos a decidir cómo se gestionan los riesgos debería ser la relación coste/beneficio. Y ojo, que coste no es lo mismo que precio, aunque al final podamos llegar a traducirlo de esa forma. ¿Por qué digo esto? Porque ese es el factor clave para la eliminación de riesgos. ¿Qué beneficio aporta a mi organización el comercio electrónico? ¿Cuántos ingresos nos supone? ¿Qué futuro espero de ese canal de vantas? ¿Ese beneficio (tanto presente como futuro) compensa los riesgos que supone esa infraestructura? Ese es el análisis que hay que hacer para poder llegar a la conclusión de que podemos eliminar todos los riesgos asociados a las ventas por internet, eliminando dicho canal.

La otra opción que normalmente se suele quedar en el tintero es la de transferir los riesgos. Y aquí hay que tener cuidado, porque no es una opción sencilla, y no todos los riesgos se pueden transferir. ¿Transifero el riesgo derivado de la ejecución de un proceso por el mero hecho de subcontratarlo en modo BPO? Pongamos el caso de un banco que subcontrata por completo la gestión de ventas por Internet. Como mínimo está transfiriendo el riesgo operativo asociado a estas actividades. ¿Está transfiriendo completamente el riesgo? En absoluto. ¿Acaso no es la subcontratación en sí misma la asunción de un cierto tipo de riesgo? ¿Qué consecuencias tendría en la imagen de ese banco un incidente de seguridad en la empresa subcontratada? Es obvio que el riesgo no se puede transferir por completo. Lo que sí se puede transferir es una parte del riesgo, y esta transferencia también puede servir para transformar un tipo de riesgo en otro (en el ejemplo, un riesgo operativo lo convertimos en un riesgo contractual).

Y en este punto es donde aparecen los seguros. Su trabajo consiste precisamente capitalizar los riesgos que les transfieren sus clientes. Y los riesgos de seguridad de la información también se pueden transferir de este modo. Quizás no estemos muy acostumbrados a ellos, pero estoy seguro de que es una tendencia que va a ir al alza. ¿Cuál es el coste de adoptar una determinada medida de seguridad para reducir un determinado riesgo? ¿Y cuál puede ser el coste de adquirir un seguro que cubra ese posible incidente de seguridad? Las empresas que trabajan con "seguros cibernéticos" piensan de este modo. Al fin y al cabo, si me sale más "barato" (en términos de coste global, no sólo en términos directamente económicos) "apechugar" con el incidente y usar el dinero del seguro que reducir el riesgo asociado a él estamos ante una mejor opción en términos de coste/beneficio. ¿Por qué no hacer uso de ella?

Por supuesto, antes de terminar con el post tengo que recordar que los seguros no son la panacea. Por poner un ejemplo, podemos pensar que el perjuicio en imagen derivado del incidente vamos a poder recuperarlo invirtiendo parte del dinero del seguro en una campaña de marketing. Ahora bien... ¿Cuándo vamos a disponer de ese dinero en efectivo? ¿Podremos ejecutar la campaña en el momento en el que es necesario? ¿Existirán costes adicionales derivados de tener que litigar con el seguro porque no nos ha dado el dinero que esperábamos? En resumidas cuentas: ¿Estamos gestionando adecuadamente el riesgo de contratar ese seguro?

El riesgo como valor

Este post sigue la misma línea que el artículo Análisis de Riesgos en tiempos de crisis, cuyo objetivo es dejar de ver el riesgo como algo negativo y empezar a verlo como algo intrínsecamente ligado al negocio. Por eso quiero referenciar hoy una noticia de hace ya algún tiempo, en la que se hacían eco de un informe que asegura que las economías emergentes utilizan el riesgo para aumentar la ventaja competitiva. Un artículo muy interesante en el que se ilustra cómo el riesgo puede ser utilizado como factor de beneficio directo en el negocio.

En el artículo se plantea la inversión en gestión del riesgo como un factor de ventaja competitiva, traducido en la práctica en hechos tan tangibles como contar con un director de seguridad corporativa o de riesgo corporativo en el consejo de dirección. Parece que las empresas que apuestan por el riesgo como ventaja competitiva centran su estrategia de gestión del riesgo en las siguientes líneas de actuación:

• Usar la gestión del riesgo para promover la innovación.
• Desarrollar estrategias de gestión del riesgo para amenazas globales.
• Apostar por la colaboración (real) inter-organizaciones como factor de éxito.
• Confiar en las políticas de gestión del riesto TIC.

Desde mi punto de vista, la filosofía que subyace en estos principios es simple pero efectiva. Por una parte, se gestionan los riesgos de forma "optimista", desde el punto de vista de alguien que tiene "poco" que perder y mucho que ganar. Además, las amenazas se entienden no como algo contra lo que luchar, sino como algo cuya existencia hay que asumir y, si es posible, utilizar en nuestro beneficio. Y a partir de ahí se construyen una serie de políticas de gestión del riesgo que tratan de "obviar" los perjuicios y maximizar los beneficios, nombrando una figura cuyo cometido sea precisamente el de exprimir esos beneficios planteados. Y para que las propias limitaciones de la organización no supongan un obstáculo a las propuestas que se planteen se ligan dichas propuestas a los programas de innovación y creatividad de la compañía. A partir de ahí, las líneas de actuación sobre las que desarrollar las políticas que se definan símplemente tratarán de ser lo más eficientes y eficaces, de forma que se apoyen en programas de colaboración para reducir o distribuir costes y en el uso de las TIC para aumentar el rendmiento de las soluciones que se planteen. Quizás se pueda pensar que son estrategias arriesgadas, pero precisamente estábamos hablando de que la clave era precisamente asumir más riesgos en aquellos ámbitos en los que se puede maximizar el beneficio...

En definitiva, creo que es posible orientar la gestión de riesgos para conseguir que ese alineamiento con el negocio sea algo tangible. Sólo hace falta exprimirse un poco el cerebro, y creo que esta época empresarial que atravesamos puede ser un buen momento...

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í...

La función de seguridad

Cuando una referencia es buena, no es necesario comentarla demasiado. Ese es el caso de este post, en el que el autor describe cómo se puede articular la función de seguridad. Inicialmente describe su composición, posteriormente analiza sus posibles ubicaciones en el organigrama y finalmente estudia las ventajas e inconvenientes de su desarrollo en modo centralizado o distribuído. La verdad es que el análisis es muy completo, y creo que sólo es necesario hacer una puntualización.

La puntualización es, sencillamente, el título del artículo. En él se hace referencia a la función de seguridad informática, aunque en el desarrollo del mismo en muchos casos se excede este alcance. Este es un aspecto que a mí, personalmente, me fastidia bastante. Es cierto que la seguridad de la información recae en buena medida en el ámbito informático, pero si realmente se desarrolla por completo esta función, una parte importante de su actividad debería desarrollarse también fuera de él. Por eso en el título de mi post me he "comido" la última palabra. Porque en caso contrario los conflictos de intereses no sólo se producirían dentro del área de sistemas, sino sobre todo en el exterior, ya que desde un área técnica se deberían realizar prescripciones de aspectos que en absoluto tienen que ver con los ámbitos técnicos.

Referencias

Últimamente he recopilado y refrescado varias referencias de distinto tipo que creo que podrían ser interesantes para todos los lectores del blog, y como corro el riesgo de que se me vayan olvidando o extraviando, prefiero dejar constancia de ellas en este momento.

Las primeras tienen que ver con el control interno. En concreto son dos modelos de control interno inspirados en COSO, y que probablemente algunos ya conozcan. El primero es el modelo ECAR, un modelo de control interno y gestión de riesgos complementario a COSO, y el segundo es el modelo estándar de control interno (MECI) colombiano, vigente por decreto en las entidades del estado de ese país y perfecta referencia para complementar al modelo anterior.

El segundo grupo de referencias tienen que ver con la redacción de políticas de seguridad. En concreto, y para complementar un post anterior en el que Samuel Linares ya nos dejaba una buena referencia, creo que tanto en esta web argentina como en esta otra se pueden encontrar buenos ejemplos de políticas de seguridad. Y si no, las series del Centro Criptológico Nacional siempre constituyen una fuente de indudable calidad.

Y la última referencia que quiero dejar es este modelo de sistema integrado de calidad desarrollado por Telefónica. Muy buena referencia para todo aquél que tenga ya un alto grado de madurez en su gestión de la calidad y esté pensando en optimizarlo en base a una referencia integrada de metodologías, normas y técnicas. Ojo, sólo para empresas "realmente maduras" en temas de calidad, si es que se quieren obtener resultados útiles.

Espero que las referencia sean de interés, y sirvan para todos los interesados puedan profundizar en alguno de estos temas. Y como mínimo, como es mi caso , seguro que sirve para tener un repositorio localizado de referencias accesible desde cualquier lugar...

Control Interno

El control interno es uno de los elementos de gestión empresarial que más cambios ha sufrido en los últimos años. En sus comienzos fue un concepto prácticamente exclusivo de las áreas financieras de las grandes corporaciones. Más adelante se fue extendiendo gracias a que los auditores internos lo heredaron y desarrollaron, aunque en gran medida siguió bastante ligado a los entornos económicos. Y en los últimos años el concepto se amplió y extendió a otros ámbitos, siendo poco a poco utilizado por responsables de calidad, seguridad o tecnología informática.

En la actualidad existen una gran cantidad de modelos de control interno, pero en muchas ocasiones es difícil distinguir entre unos y otros y apreciar claramente sus diferencias y similitudes. Y más si tenemos en cuenta que entre unos y otros existen muchas influencias y puntos comunes. Por eso, creo que este documento puede ser bastante útil para todo aquél que quiera adentrarse en estos temas.

En el documento se comparan tres modelos de control interno: Cobit, SAC y COSO. Inicialmente se lleva a cabo una presentación de cada uno de los tres modelos, y posteriormente se comparan distintos atributos de cada uno de ellos, analizando a quién va dirigido, la forma de ver el control interno de cada modelo, los objetivos organizacionales que persiguen, los componentes del modelo, el ámbito de aplicación y el alcance, entre otros.

Sin pararme a resumir el contenido del documento completo, sí que quiero destacar algunas diferencias que me parecen significativas, sobre todo entre COSO y COBIT, que son los dos modelos más difundidos en la actualidad. La primera gran diferencia es que COSO está enfocado a toda la organización, mientras que COBIT se centra en el entorno IT. La segunda es que COBIT contempla de forma específica la seguridad de la información como uno de sus objetivos, cosa que COSO no hace. Y la tercera, que el modelo de control interno que presenta COBIT es más completo, dentro de su ámbito, que el de COSO, ya que contempla políticas, procedimientos y estructuras organizativas además de procesos para definir el modelo de control interno.

Como única pega que se le puede poner al documento, y a falta de una referencia clara sobre su fecha de realización, es que tengo la sensación de que el artículo no es demasiado actual, y no utiliza ni la referencia de COBIT v4 para analizar este modelo ni las aportaciones del informe COSO II para completar este otro. De todos modos, creo que la referencia es bastante útil para adentrarse en el mundillo del control interno.

Control Interno y Auditoría

En muchas ocasiones me encuentro con empresas que no tienen muy clara la diferencia entre control interno y auditoría. El objetivo de este post es, sencillamente, tratar de diferenciar ambos conceptos.

El control interno (siendo estrictos, las actividades de control interno) lo constituyen tareas y funciones inherentes a la propia actividad de la organización, y son aquellas actividades del día a día que tratan de verificar que los procesos se realizan según lo establecido. Son tareas distribuidas, que desarrollan desde los directivos hasta los técnicos y operarios. Hay actividades de control tan sencillas y acotadas como verificar que todas las piezas fabricadas están dentro del umbral permitido, y otras que pueden ser tan difusas como comprobar el grado de aprovechamiento de las acciones formativas. Ligado al control interno deberían aparecer los indicadores (tanto estratégicos como tácticos y operativos), como parámetros a evaluar dentro de esas actividades de control interno.

Por otro lado tenemos la auditoría. A diferencia de lo anterior, las auditorías son acciones puntuales y ajenas a los elementos auditados, cuyo objetivo es tratar de identificar el grado de cumplimiento de determinadas normativas y objetivos asociados. Las auditorías son análisis puntuales, cuyo objetivo es primordialmente emitir un diagnóstico objetivo y neutral sobre el estado del elemento auditado.

La confusión entre ambos conceptos nace de que ambas actividades están encaminadas a la evaluación del elemento controlado o auditado. Sin embargo, la diferencia es que las auditorías buscan más el análisis de estado y la consiguiente identificación de fortalezas y debilidades, mientras que el control interno se centra más en la identificación de tendencias. Además, las primeras son acciones puntuales, mientras que las segundas son continuas.

Está claro que existen muchas más connotaciones que habría que analizar a la hora de dar una definición y diferenciación completa entre ambos conceptos, pero espero que estas breves nociones sirvan para identificar más fácilmente las diferencias entre ambas. Al menos, para saber qué podemos exigir cuando tengamos que sentarnos frente a un auditor y pedirle que analice nuestra organización...