controles

Controles para el uso de las redes sociales por parte de una empresa

1 diciembre, 2019 by mikelcolmenares Leave a Comment

Toda empresa que se precie debe tratar de controlar los posibles riesgos que puedan aparecer en sus procesos de trabajo. Para ello, se debe auditar todos esos procesos. Es decir, que se debe comprobar si se están tomando las suficientes medidas de seguridad para evitar que ocurran esos problemas, o al menos, si ocurren, que sean los menos dañinos posibles.

En esta vida no tenemos ni tiempo ni recursos para realizar todo lo que querríamos. A las empresas les ocurre lo mismo en todos los ámbitos que se te ocurran, y obviamente, la auditoría no es una excepción. Para ello se deben controlar los riesgos En el anterior articulo ya he hablado de cuales son los riesgos más importantes a la hora de escoger qué es importante auditar. En este nuevo post vamos a ver ese paso siguiente en el que se crean los controles para evitar que esos riesgos ocurran.

Perdida de reputación

La reputación y la buena imagen han adquirido mayor valor desde la aparición de las redes sociales. Eso ha llevado a las empresas a estar siempre alerta de cualquier movimiento que pueda afectar a esos factores. Para ello se han generado nuevos controles que tratan de evitar que algún pequeño percance no se convierta en una bola de nieve gigante que se lleve la reputación de la empresa por delante. Para controlar ese descontento, en un artículo de ISACA [1] nos recomiendan mantener un control proactivo de los comentarios negativos que se hagan hacia nuestra empresa. Esto quiere decir que alguien debe encargarse de revisar los comentarios que se hagan sobre algo que tenga que ver con nuestra empresa y que trate de solucionar ese descontento o que rebata las afirmaciones falsas.

También se debe definir una estrategia de contenidos con la que el encargado pueda comprobar que las publicaciones están siguiendo la estrategia elegida.

Riesgo financiero

El riesgo financiero está asociado a la incertidumbre, es decir, a la posibilidad de que ocurra algo que se traduzca en pérdidas para la compañía. Este riesgo está muy ligado al resto puesto que cualquier percance en el resto de riesgos se acaba traduciendo en perdidas monetarias. Pero dejando de lado esos riesgos extraordinarios, si se puede controlar el gasto corriente que la empresa realiza en redes sociales. Se puede comprobar la rentabilidad de este gasto o si se está siguiendo la estrategia correcta entorno a las redes sociales, si comparamos los beneficios obtenidos en comparación con meses o años anteriores.

Infringir leyes

Dentro del ámbito legal he encontrado dos normativas que se deben tener en cuenta al estar presentes en las redes sociales. Primero, se debe comprobar que al realizar acciones publicitarias se cumple con lo que exige la normativa [2]. Segundo, se debe cumplir con la nueva modificación de la ley de derechos de autor [3] publicada el 2 de marzo de este mismo año. En este punto sería interesante disponer de un experto en auditoría legal.

Ciberseguridad

Dentro de los controles de ciberseguridad lo primero es tener un plan de control de contraseñas. En este sentido, el instituto nacional de ciberseguridad hizo un documento [4] con recomendaciones y una checklist con controles para garantizar la seguridad de las contraseñas.

Además de tener controladas las contraseñas de las cuentas, se debe monitorizar desde qué dispositivo se accede a estas redes. Lo más recomendable es que esos dispositivos no tengan acceso a la red interna de la empresa. De este modo si logran hackear la cuenta, por algún fallo del personal que se encarga de gestionar las cuentas, solo tendrán acceso a ese dispositivo y no a toda la red de la compañía.

Empleados descontentos

Se debe tener mucho cuidado con el control de accesos del personal que haya sido despedido o que se encuentre descontento. Si se despide a un empleado con acceso a las cuentas de las redes sociales de la compañía, se deben cambiar esos accesos, puesto que el empleado, puede empezar a mandar mensajes negativos a diestro y siniestro dañando la imagen de la compañía. También se debe comprobar que en la lista de empleados con acceso a las redes sociales solo estén los empleados que deben trabajar en ello.

Con esto ya hemos identificado cuales son lo controles que se deben realizar para cada riesgo. Pero con esto no basta. El auditor debe asegurarse de: Primero, que los controles se han implantado de forma correcta. Segundo, que tras ver los resultados, decidir si los controles pueden necesitar ser actualizados. Y tercero, plantearse si son necesarios nuevos controles.

Referencias:

[1] << What Every IT Auditor Should Know About Auditing Social Media >>, ISACA, https://www.isaca.org/Journal/archives/2012/Volume-5/Pages/What-Every-IT-Auditor-Should-Know-About-Auditing-Social-Media.aspx

[2] << Cómo se regula la publicidad. Conoce las leyes y la normativa >>, Jesuïtes Educació, https://fp.uoc.fje.edu/blog/como-se-regula-la-publicidad-conoce-las-leyes-y-la-normativa/

[3] << Real Decreto Legislativo 1/1996, de 12 de abril, por el que se aprueba el texto refundido de la Ley de Propiedad Intelectual, regularizando, aclarando y armonizando las disposiciones legales vigentes sobre la materia. >>, BOE, https://www.boe.es/buscar/pdf/1996/BOE-A-1996-8930-consolidado.pdf

[4] << Políticas de seguridad para la pyme: contraseñas >>, INCIBE, https://www.incibe.es/sites/default/files/contenidos/politicas/documentos/contrasenas.pdf

Cloud Computing, conclusiones

28 noviembre, 2019 by unaibermejofdez 1 Comment

En este quinto y último post, me gustaría reflexionar sobre lo visto hasta ahora. Para ello, voy a destacar los conceptos más relevantes de los cuatro posts anteriores y os voy a traer una serie de opiniones y advertencias concretas que nos pueden dar mucho que pensar. En definitiva, me gustaría utilizar este post para ofrecer una visión crítica del Cloud Computing y complementar los contenidos que hemos ido viendo.

El Cloud Computing, como bien sabemos, es un modelo para facilitar u ofrecer servicios y recursos de computación (almacenamiento, procesamiento, gestión…) bajo demanda, con elasticidad, escalabilidad y de forma remota [1]. Un modelo opuesto a lo que conocemos como software on-premise.

Y recordado eso, reflexionemos, ¿por qué ha triunfado este modelo? ¿por qué se está adoptando de manera masiva por parte de las empresas? Podríamos pensar que es debido a los beneficios inmediatos que ofrece: escalabilidad, flexibilidad… Y es cierto, el Cloud Computing permite a las empresas ser más ágiles y reducir la complejidad de sus operaciones externalizando servicios y productos que no son su core de negocio [1]. Las empresas ya no tienen que desplegar infraestructuras TIC (IaaS, PaaS), y en ocasiones, ni siquiera deben desarrollar sus propias aplicaciones, pudiendo dedicarse a consumir software de terceros (SaaS). Además, los riesgos que tiene asociados este paradigma (ya sean técnicos o de gestión), como hemos podido ver, son controlables si contamos con un buen equipo de auditoría y un contrato blindado con el proveedor adecuado. Sin duda alguna, las ventajas que ofrece adoptarlo superan con creces a los inconvenientes.

Pero yo, como os decía al comienzo del post, os invito a verlo con otros ojos. Os invito a verlo con algo más de desconfianza. Si os fijáis, el Cloud triunfa no solo por lo que supone a nivel tecnológico o técnico, sino también porque es mucho más barato que tener software on-premise [1]. Al menos, de momento. Y esta última frase, pone sobre la mesa un riesgo que quizá no hayamos visto explícitamente en los posts anteriores. Y es probablemente, al menos a mi juicio, el más grave de todos.

Como vimos en el segundo post, hoy en día, el 94% de las empresas utilizan algún tipo de servicio Cloud. ¿Qué pasaría si de repente, visto que tantas empresas son dependientes del Cloud Computing, los proveedores comienzan a subir las tarifas? ¿Qué ocurriría si Amazon Web Services, Microsoft Azure o Google Cloud se dan cuenta de lo necesarios que son para otras empresas y se aprovechan de la situación?

Pensaréis, bueno, si los proveedores suben los precios, las empresas volverán al modelo de software on-premise. Así que, tampoco pasaría nada. Al final, los proveedores tendrían que ceder. En mi opinión, eso no es así. No es tan sencillo.

Una vez se adopta el Cloud, los costes que supondría volver a traer de vuelta a casa los sistemas, plataformas e infraestructuras serían la ruina de la mayoría de organizaciones. Si hemos visto que es caro, complejo y difícil migrar de on-premise a Cloud. Pensadlo al revés, imaginad un caso de repliegue. Un caso en el que una empresa se vea forzada a volver al software on-premise, ya no por no haber realizado una migración adecuada al Cloud, sino porque no puede hacer frente a los compromisos económicos con el proveedor.

Vuelve a calcular tu plan de recuperación ante desastres (DRP) [2]. Vuelve a establecer un RTO y RPO. Vuelve a comprar el hardware. Vuelve a acondicionar las instalaciones oportunas. Vuelve a contratar técnicos de sistemas (y despide a tus especialistas en Cloud). Costes, costes y más costes inasumibles para muchos negocios.

Decía Richard Stallman, un hombre sin duda polémico, que se equivoca con muchas cosas pero que acierta con muchas otras, que el Cloud Computing es una trampa elaborada para que las empresas compren sistemas cerrados y propietarios que les costarán cada vez más dinero [3]. Y si nos ponemos a pensarlo, debe ser un riesgo a considerar (más allá de lo que podamos opinar acerca del software privativo y el software libre). Al menos, yo así lo creo.

Debemos andar con pies de plomo cuando nos ponemos en manos de terceros. De hecho, ya vimos en el post de controles que el Cloud Computing es puro Outsourcing. En concreto, vimos que existe un control específico para (más o menos) lo que estamos hablando: “Asegurar que los procedimientos, capacidades y alternativas para migrar las operaciones en la nube a otro proveedor están previamente definidas al consumo del servicio en caso de que sea necesario por incumplimiento de los requisitos contractuales o cese del servicio del proveedor contratado”. Yo, personalmente, complementaria este control con la alternativa de volver al software on-premise. Y además, añadiría el riesgo de las condiciones de renovación, ya que igual no solo no encontramos otro proveedor, sino que igual procedemos a renovar contrato con el actual y nos encontramos con una subida de precios que no podemos asumir.

En relación a esto último, debemos saber que no solo existe el riesgo de no poder seguir pagando, ¡sino de pagar más de lo que creíamos que íbamos a pagar! ¿A qué me refiero con ésto? Pues que la propia elasticidad del Cloud supone un riesgo a la hora de predecir costes [2]. En otras palabras, añade complejidad y volatilidad a los presupuestos TI. De hecho, a veces acabamos pagando más de lo que pagaríamos con software on-premise [4].

Por otro lado, tal y como vimos en el post de riesgos y siguiendo esta línea de razonamiento pesimista, contratar software como servicio (SaaS) es una pérdida de control total para una organización [3]. En el futuro, veremos como empresas dependientes de proveedores SaaS se enzarzarán en batallas legales para poder seguir consumiendo servicios que han dejado de tener soporte, por acceder a datos históricos cuya existencia no estaba contemplada en el contrato o por defender que la propiedad intelectual de los resultados ofrecidos por el software les pertenece.

Con todo esto tampoco quiero dar a entender que el Cloud Computing es malo o que es peligroso. Nada más lejos de la realidad. Considero que el Cloud Computing es el futuro. Pero se suele decir que hasta que algo malo no pasa, no se toman medidas. Y en ese sentido, debemos ser críticos y, como auditores, anticiparse a la catástrofe, considerando tanto la esfera técnica como la de negocio cuando nuestra empresa quiera adoptar una nueva tecnología o un nuevo modo de hacer las cosas. Del mismo modo, no debemos caer en la trampa de que el Cloud es la solución a todos nuestros males. Quizá, nuestra organización no tenga la necesidad de adoptarlo, o incluso, no le convenga.

Asimismo, me gustaría aclarar que muchos de los problemas de los que hablamos también existen, en cierto modo, en el modelo de software on-premise. Si compramos software, infraestructuras y plataformas para meter ‘dentro de casa’, su mantenimiento y renovación conlleva muchos riesgos [5]. Pero lo que es cierto, es que aquellos relativos a la dependencia con terceros, se magnifican con el Cloud Computing. En este post, como os habréis dado cuenta, he tratado de arrojar luz sobre dicho problema.

Además, me gustaría decir que la mayoría de los riesgos que hemos ido viendo (relativos a costes, control y privacidad) son mitigables, en parte, adoptando modelos de despliegue de nube híbrida y privada. Las diferencias de estos modelos con la nube pública ya las comentamos en anteriores posts. Principalmente, lo que se logra es reducir esa peligrosa dependencia con proveedores, manteniendo muchas de las ventajas del Cloud. Esto las empresas lo saben y es por ello por lo que está ocurriendo una migración masiva de nubes públicas a nubes híbridas y privadas [4]. Al principio resultan más caras, pero a la larga, otorgan más control y seguridad. Son la opción más prudente.

Finalmente deciros que, si os fijáis, da igual lo que estemos auditando, todo se reduce a identificar riesgos (tanto técnicos como de gestión), implantar controles, lanzarse a la piscina y, periódicamente, revisar que dichos controles se cumplen. Al final, si nos fijamos, la palabra auditoría, etimológicamente, viene del verbo latino audire. Esto es, viene del verbo oír. Un auditor lo primero que debe hacer es escuchar, ver, observar, para luego revisar, informar y recomendar.

Eso es lo que he tratado de hacer a lo largo de estos posts. Espero que os hayan servido para aprender sobre el Cloud y sobre todo, para aprender acerca del mundo de la auditoría TI. Para mí, ha sido un placer escribirlos. ¡Un saludo y gracias por leerme!

[1] «Computación en la nube – Beneficios, riesgos y recomendaciones para la seguridad de la información», ENISA, acceso el 28 de noviembre de 2019, https://www.enisa.europa.eu/topics/threat-risk-management/risk-management/files/deliverables/cloud-computing-risk-assessment-spanish

[2] «How to escape the Cloud and move back to on-premise systems», TechRepublic, acceso el 28 de noviembre de 2019, https://www.techrepublic.com/article/how-to-escape-the-cloud/

[3] «Cloud Computing es peor que una estupidez», RedUsers, acceso el 28 de noviembre de 2019, http://www.redusers.com/noticias/richard-stallman-cloud-computing-es-peor-que-una-estupidez/

[4] «Cloud Repatriation: When Is it Time to Bring Workloads Back On-Prem?», GreenHouseData, acceso el 28 de noviembre de 2019, https://www.greenhousedata.com/blog/cloud-repatriation-when-is-it-time-to-bring-workloads-back-on-prem

[5] «On Premise vs. Cloud: Key Differences, Benefits and Risks», Cleo, acceso el 28 de noviembre de 2019, https://www.cleo.com/blog/knowledge-base-on-premise-vs-cloud

Cuando se habla de salud, aceptar riesgos no es una opción

28 noviembre, 2019 by anderarguinano 1 Comment

En el anterior artículo pudimos ver como los dispositivos médicos pueden manipularse para administrar dosis fatales de insulina, para robar datos de pacientes o incluso para directamente dejarlos inoperativos. Estos escenarios no son ciencia ficción. Son muy reales y cada vez son más los dispositivos médicos como marcapasos, bombas de insulina o máquinas de resonancia magnética vulnerables a sufrir ataques.

Mientras investigaba me he encontrado con un artículo [1] en el cual se recoge como varios investigadores emularon el funcionamiento de un dispositivo médico en un sistema de señuelo. En el transcurso de seis meses, los malhechores se conectaron con éxito en más de 55.000 ocasiones al sistema e instalaron más de 300 malwares. Esto refleja lo expuestos que estamos ante este tipo de ataques. Los dispositivos médicos están constantemente en peligro de ser comprometidos y es por ello que todo lo expresado hasta este post cobra especial relevancia.

Cuando hablamos de temas tan sensibles como es el caso de la salud de las personas, aceptar los riesgos no es una opción.

¿Y entonces qué hacemos?

Tenemos que gestionar dichos riesgos. La seguridad del paciente debería ser ante todo la prioridad de todos los fabricantes de dispositivos médicos.

Esta gestión, además, no resulta opcional sino que es un requisito reglamentario en todo el mundo. La FDA de los EE.UU. lo exige en el Reglamento del Sistema de Calidad. Europa, a su vez, lo requiere en el nuevo Reglamento de Dispositivos Médicos.

Asimismo, Japón, Canadá, Australia, Brasil y todos los demás mercados importantes también requieren la aplicación de la gestión de riesgos, a la cual se hace referencia en sus reglamentos nacionales o en la norma ISO 13485:2016. [2] Esta norma internacional respalda la obligación de los fabricantes de asegurarse de que los productos cumplen sistemáticamente los requisitos normativos aplicables y las exigencias del cliente. [3]

Sin embargo, todos ellos se rigen por la norma ISO 14971, norma mundial para la gestión de riesgos de los dispositivos médicos. Esta norma aprobada por la FDA, especifica el proceso de gestión de riesgos mediante el cual un fabricante puede identificar los peligros asociados con su dispositivo médico, estimar y evaluar los riesgos, controlar estos riesgos y supervisar la eficacia de los controles a lo largo del ciclo de vida del producto. [4]

Parece fácil, ¿verdad? No obstante, la realidad es que la gestión de riesgos es uno de los aspectos más complejos del cumplimiento de las regulaciones.

En este post, en concreto, nos vamos a centrar en los controles para mitigar los riesgos asociados a este tipo de dispositivos.

¿Pero qué es un control?

Un control es un proceso en cual se toman decisiones y se aplican medidas que permiten reducir los riesgos a niveles especificados.

Para cada uno de los riesgos es necesario estimar el grado de impacto así como la probabilidad de que este ocurra. A partir de estos valores se puede estimar si el riesgo resulta crítico, moderado o bajo pudiendo detectar aquellos riesgos sobre los cuales deberemos aplicar controles. [5]

¿Os acordáis de los riesgos que mencionamos en el anterior artículo?

Los hemos mencionado un poco antes: accesos no autorizados, ataques contra la disponibilidad, robo de datos, cambio de ajustes de configuración, software y firmware no probado o defectuoso …

Ahora vamos a intentar establecer una serie de controles para mitigar dichos riesgos: [6][7]

Establecer controles de acceso: Consiste en limitar el acceso al dispositivo médico conectado a través de técnicas como la doble autenticación, uso de tecnologías NFC, establecimiento de contraseñas,… Este tipo de medidas permiten reducir el número de accesos no autorizados, reduciendo de esta forma también las posibilidades de sufrir un robo de datos. Sin embargo, este tipo de medidas pueden resultar polémicas en determinados casos: ¿Establecemos una contraseña de acceso en un marcapasos? De esto hablaremos un poco más adelante.
Realizar actualizaciones periódicas: Es necesario aplicar parches de seguridad al dispositivo médico con frecuencia de acuerdo con las pautas posteriores a la comercialización emitidas por la FDA.
Aplicar estándares de codificación: Muchos ciberataques exitosos han explotado vulnerabilidades presentes en el código que no han sido probadas rigurosamente antes de su implementación en un entorno activo. Una de las normas más importantes de la industria es la emitida por la Comisión Electrotécnica Internacional (IEC), IEC 62304. Este estándar proporciona una serie de características robustas sobre cómo desarrollar mejor el código.
Aplicar la seguridad mediante el diseño: Es fundamental la gestión adecuada del ciclo de vida del dispositivo médico. Tener en cuenta la seguridad desde el primer momento en el cual se va a diseñar el dispositivo resulta fundamental.
Hacer uso de canales de comunicación cifrados: Los dispositivos deberían hacer uso de canales de comunicación debidamente encriptados a fin de comunicarse con el mundo exterior.

Pero los controles no solo se deben establecer, estos a su vez deben ser auditados. Realizar auditorías periódicas de los procesos y de la tecnología ayuda a identificar las amenazas y permite mitigar los riesgos. Esta labor recae sobre los auditores, es decir las personas responsables de velar por la cumplimentación de las regulaciones correspondientes y de evaluar los procedimientos llevados a cabo por la organización.

Cuando se trata de auditorías de dispositivos médicos, las pruebas de penetración son un enfoque recomendado. Estas pruebas ayudan a evaluar lo fácil que es para los hackers violar la seguridad de los dispositivos para obtener recursos tales como datos, interrumpir operaciones o modificar sistemas que podrían afectar la salud del paciente.

Además, establecer controles no solo implica establecer iniciativas que solucionen el problema. Debemos ser conscientes también del ámbito en el cual se aplican. El otro día me enviaron una noticia en la cual el titular decía “Investigadores muestran la relación entre las brechas de datos y las tasas de mortalidad hospitalaria”. [8] Al principio pensé que la relación entre ambos factores sería las consecuencias generadas por el ataque. Sin embargo, la relación que establecía el estudio yacía en las contramedidas aplicadas por los hospitales y su consecuente aumento en los tiempos de atención a los pacientes.

Al final intentamos blindar los dispositivos y se nos olvida que en este sector en concreto se necesita de dispositivos seguros y efectivos pero que a su vez resulten rápidos en caso de emergencia. Imaginaros un médico que tuviera que estar introduciendo una contraseña mientras el paciente se está muriendo.

¿Y qué pasaría si al profesional sanitario se le ha olvidado la contraseña?

Somos humanos, estas cosas pueden pasar. Desde un punto de vista tecnológico esto supone un reto ya que cualquier mala implementación posee como resultado lo mencionado en el artículo, un aumento en la tasa de mortalidad.

Es por ello que se debe establecer una alineación entre las medidas aplicadas y el ámbito del mismo. ¿De que sirve blindar un dispositivo si en caso de emergencia no podemos acceder a él? ¿Tal vez tengamos que hacer uso de nuevas tecnologías? Y estas tecnologías a su vez, ¿ qué riesgos presentarían?

Muchas preguntas a contestar cuyas respuestas no resultan sencillas. Sin embargo lo que sí sé es que necesitamos dispositivos seguros, efectivos y alineados con el trabajo que realizan los profesionales del sector. En el momento en que se consiga alcanzar todo ello será cuando este sector alcance su máximo esplendor, pudiendo todos los ciudadanos aprovechar las ventajas que nos aporta la tecnología sin miedo a que nuestra vida corra peligro.

Y hasta que el post de hoy.

Referencias

[1] <<Closing the Gap in Medical Device Cybersecurity>>, Knowledge Leader, acceso el día 22 de noviembre del 2019, https://www.knowledgeleader.com/knowledgeleader/content.nsf/web+content/hotissueclosingthegapinmedicaldevicecybersecurity

[2] <<ISO 14971 and the Basics of Medical Device Risk Management Explained>>, Oriel, acceso el día 22 de noviembre del 2019, https://www.orielstat.com/blog/iso-14971-basics-explained/

[3] <<ISO 13485 Certificación para los productos sanitarios>>, Lloyd’s register, acceso el día 23 de noviembre del 2019, https://www.lr.org/es-es/iso-13485/

[4] <<Case study — Risk management for medical devices (based on ISO 14971)>>, IEEE Xplore, acceso el día 20 de noviembre del 2019, https://ieeexplore.ieee.org/document/5754492

[5] <<The definitive guide to ISO 14971 risk management for medical devices>>, Green Light, acceso el día 22 de noviembre del 2019, https://www.greenlight.guru/blog/iso-14971-risk-management

[6] <<The Internet of Medical Things – Anticipating the Risk>>, ISACA, vol 4 (2019): 27-32

[7] <<Medical device cyber security guidance for industry>>, Australian Government, acceso el día 22 de noviembre del 2019, https://www.tga.gov.au/sites/default/files/medical-device-cyber-security-guidance-industry.pdf

[8] <<Researchers Show Link Between Data Breaches and Hospital Mortality Rates>>, CPO Magazine, acceso el día 20 de noviembre del 2019, https://www.cpomagazine.com/cyber-security/researchers-show-link-between-data-breaches-and-hospital-mortality-rates/?mc_cid=61cc16581e&mc_eid=5a73407028

Buena cautela, iguala buen consejo

26 noviembre, 2019 by xsarri9 1 Comment

En el post anterior hablé sobre los riesgos que entrañaba usar un dron comercial, y aunque haya muchos más, ya es hora de ponernos en el rol del auditor y establecer unos controles que deberían de llevarse a cabo. Los riesgos los habíamos dividido en dos partes, los intencionados por las personas y las que no lo son, por lo que los controles irán también divididos en los mismos grupos para confeccionar nuestra matriz de riesgo y controles.

Entre los riesgos intencionados, relacionados [1] con las personas y las oportunidades que ofrecen los drones, se pueden identificar varios controles relacionados con la seguridad informática, la privacidad y mecanismos de emergencia como último recurso.

Para verlo en sintonía con los riesgos, la siguiente tabla [2] explica con mejor detalle la relación entre los riesgos y los respectivos controles que deberían cumplirse para evitarlos, aceptarlos o minimizar impactos.

Riesgo	Impacto en el negocio	Descripción de medidas	Controles
Robo de datos	Pérdida de privacidad de la gente, desconfianza como proveedor de servicios, filtrado de información sensible de infraestructuras o credenciales.	Hacer uso de canales seguros a la hora de enviar información y evitar el acceso simultáneo de usuarios al dron.	1. Cifrado de los datos de punto a punto. 2. Utilizar protocolos seguros a la hora de la comunicación. 3. Control de accesos.
Secuestro del dron	Pérdida de un activo, retraso en el trabajo y perder tiempo y dinero en los procesos de investigación del incidente	Conseguir una manera de evitar el secuestro [3], activando protocolos de rescate para aterrizar al dron o reforzando la seguridad tanto en el programa como en los protocolos y frecuencias de comunicación usadas.	1. Control de acceso. 2. Implementar protocolos de rescate. 3. Instrucción a los pilotos sobre los peligros 4. Uso de frecuencias seguras.
Secuestro y destrucción del dron	Pérdida doble, por una parte el dron, y por la otra el objetivo del perpetrador, daños al negocio y a terceros.	Además de lo del riesgo anterior, evitar el impacto, implementar programas de evasión de choques y no poder evitarlos.	1. Implementar medidas evasivas. 2. Asegurar la integridad del software de evasión 3. Control de acceso. 4. Implementar protocolos de rescate. 5. Uso de frecuencias seguras. 6. Instrucción a los pilotos sobre los peligros.

Algunos controles se comparten debido a que los riesgos intencionados más importantes están centrados en la seguridad. Aunque los controles de robo de datos se establezcan [4], las tecnologías utilizadas para el hacking siguen creciendo, por lo que los controles planteados servirían para intentar mitigar los ataques ya conocidos. Hasta los drones se pueden usar para hackear otros drones, lo que conlleva a fortalecer las medidas de seguridad de manera enorme.

Para los riesgos no intencionados, los controles necesarios están más centrados en la decisión de pilotar y evitar el máximo los daños del entorno como del dron. En la siguiente tabla, siguiendo el modelo de la anterior se reflejan unas medidas de mitigar los riesgos generalmente debido a la naturaleza de los mismos.

Riesgo	Impacto en el negocio	Descripción de medidas	Controles
Accidente por clima	Dependiendo de la gravedad del accidente, podría llevar a la pérdida de un activo y daños en terceros por la caída del dron.	El dron no debería de operar en situaciones de vientos fuertes o granizo, ni por encima de personas.	1. Evitar su uso en condiciones climatológicas duras. 2. Planificar las operaciones respecto al tiempo. 3. Hacer un estudio de terreno y clima antes de operar con el dron.
Accidente por choque aéreo	Dependiendo de la gravedad del accidente, podría llevar a la pérdida de un activo, daños en terceros por la caída del dron e incluso daños a infraestructuras al chocar contra cables.	El dron no debería de operar en lugares de difícil acceso o concurridos por pájaros, llenos de ramas o canalizaciones de agua.	1. Hacer un estudio de terreno e infraestructuras. 2. Familiarizar a los operarios con el entorno. 3. Evitar acceder a los pájaros, limpieza de árboles, etc. en el recinto.
Ataques animales	Dependiendo de la gravedad del ataque, podría llevar a la pérdida de un activo, daños en terceros por la caída del dron y en el peor de los casos, podría matar también al ave rapaz atacante que podría estar en peligro de extinción.	Para evitar que los pájaros se acerquen, debería de llevar mecanismos que los asusten y protección adicional sobre todo en las hélices en caso fallido.	1. Refuerzo de las hélices que no sean alcanzables por garras o pico. 2. Implementar medidas ahuyentadoras como reflectantes o emisión de frecuencias de sonido molestas.
Batería vacía	Dependiendo de la zona del accidente, podría llevar a la pérdida de un activo y daños en terceros al intentar estacionar el dron con seguridad.	El dron nunca se debería de operar sin que la batería esté en buenas condiciones.	1. Revisar la batería del dron antes de operar con él. 2. Implementar aterrizajes seguros al detectar batería baja. 3. Informar a los operarios sobre los peligros del manejo con batería baja.

Aunque se implementen ciertos controles como para reducir o mitigar los desastres que pueden ocurrir, cada empresa que haga uso de los drones tendrá unos riesgos y unos controles diferentes para aplicar, por lo que no es fácil determinar un guión general. En el siguiente post, entraré con más detalle sobre si la empresa que posees tiene la imperiosa necesidad de usar drones, le ayudaría en el negocio debido a las ventajas sobre los riesgos que podría suponer o si simplemente tenerlos es un capricho.

Bibliografía:

[1]«PreView Volume 3, Issue 2», Protiviti, acceso el 21 de noviembre de 2019, https://www.protiviti.com/US-en/insights/preview-vol-3-issue-2

[2]«Trading skills & essentials,risk management», Investopedia, acceso el 23 de noviembre de 2019, https://www.investopedia.com/terms/r/risk-control.asp

[3]«Así se puede hackear un dron en pleno vuelo», As-Betech, acceso el 26 de noviembre de 2019, https://as.com/meristation/2016/10/28/betech/1477685427_331526.html

[4]«Rise of the Drones», ISACA emerging tech report, acceso el 24 de noviembre de 2019,

http://www.isaca.org/Knowledge-Center/Research/Documents/Rise-of-the-Drones_whp_eng_0217.pdf

Controles y Auditoría del IoT

17 noviembre, 2019 by unailopez1 Leave a Comment

En los posts anteriores comenté varios temas relacionados con el IoT como: una explicación de esta tecnología, tendencias dentro de la industria y riesgos que el uso indiscriminado y descontrolado de esta tecnología pueden generar. Pero, ¿cómo se pueden controlar estos dispositivos?

El hecho de que existan miles y miles de diferentes dispositivos IoT y cada uno de ellos tenga diferentes tipos de comunicaciones entre ellos, dificulta la creación de un estándar.

Al inicio del IoT, para los protocolos de autenticación usuario-dispositivo y dispositivo-usuario se utilizaron protocolos ya existentes. Más tarde, varios investigadores empezaron integrando otros protocolos de identificación y autenticación como OpenID y OAuth2 pero aunque estos permitían facilitar la comunicación entre usuarios y dispositivos, existían casos como en los de las “Smart Cities” y servicios industriales en los que estos protocolos se quedaban cortos. [1]

Este problema ha acabado creando una enorme diversidad de tipos de comunicaciones y dispositivos que dificulta enormemente la creación de un estándar para poder mantener un control generalizado de los dispositivos de IoT.

A pesar de la falta de un estándar, el gobierno de los Estados Unidos entre otros, ha dado algunos pasos para prevenir la posibilidad de brechas de seguridad en los dispositivos de seguridad. Sin ir más lejos, el Departamento de Seguridad Nacional ha creado seis principios estratégicos para proteger estos dispositivos: [2]

Incorporar la seguridad en la fase de diseño.
Actualizaciones avanzadas en la gestión de la seguridad y vulnerabilidades.
Basarse en prácticas de seguridad comprobadas.
Priorizar las medidas de seguridad según el impacto potencial.
Promover la transparencia alrededor del IoT.
Promover la conectividad cuidadosa y deliberada.

También existen algunos marcos como por ejemplo el marco de Zachman. Este marco trata de comprender ideas complejas mediante las primitivas preguntas qué, cómo, cuándo, quién, donde y por qué. [3] Al aplicar el marco de Zachman a la arquitectura IoT podemos obtener lo siguiente:

[4]

Siguiendo esta tabla es más fácil auditar y controlar un dispositivo de IoT. Además, si se le echa un vistazo a la fila “Where”, podemos ver que se le da importancia a cada componente de cada capa. Esto es algo que no siempre se tiene en cuenta, pero es algo capital para comprender la seguridad IoT. Un buen control de la seguridad debe tener en cuenta la seguridad por cada capa de la arquitectura y por cada comunicación que cada una de esas capas tienen con las demás. De esta manera también se comprenderá si este dispositivo tiene alguna capa en la nube o no y lo que ello puede significar a nivel de seguridad. [4]

Existen más instituciones las cuales se han centrado en crear marcos para la protección de los dispositivos de IoT. Por ejemplo, el Instituto Nacional de Estándares y Tecnología de EEUU [5] ha creado un informe con el objetivo de ayudar a las organizaciones a mejorar la ciberseguridad de esta tecnología tratando de abarcar los principales problemas de esta tecnología como la protección de la seguridad del dispositivo, la protección de la seguridad de la información y la protección de la privacidad del individuo, entre otros. [6]

Como conclusión final, se podría decir que la seguridad de la IoT a menudo carece de prioridad cuando se diseñan y aplican los sistemas. La seguridad de la IoT no significa solamente seguridad a nivel de dispositivo, además de esto, es necesaria aplicarla en todos los componentes y capas del sistema y para ello, es necesario abordarlo en todas las fases del ciclo de vida del sistema, incluidas las fases de diseño, instalación, configuración y funcionamiento.

Además, las contraseñas y claves de certificado sólidas, los nombres e identificadores de dispositivos o hosts difíciles de adivinar, la supervisión, el análisis de registros, la gestión proactiva de usuarios y dispositivos y las recomendaciones de seguridad de todas las organizaciones que se dediquen a este dominio, como por ejemplo, el anteriormente mencionado Instituto Nacional de Estándares y Tecnología de la EEUU, son de vital importancia para lograr una buena seguridad en un sistema IoT.

Referencias

<< Computer Cybersecurity >>, IEEE Computer Society, vol 51 nº 4 (2018): 18
<<Strategic Principles for Securing the Internet of Things (IoT)>>, U.S. Department of Homeland Security, acceso el 15 de Noviembre del 2019, https://www.dhs.gov/sites/default/files/publications/Strategic_Principles_for_Securing_the_Internet_of_Things-2016-1115-FINAL_v2-dg11.pdf
<< The Internet of Things: What Is It and Why Should Internal Audit Care? >>, Knowledge Leader, acceso el 22 de Octubre del 2019, https://www.knowledgeleader.com/knowledgeleader/content.nsf/web+content/arttheinternetofthings
<<The Concise Definition of the Zachman Framework>>, Zachman International Enterprise Architecture, acceso el 7 de Noviembre del 2019, https://www.zachman.com/about-the-zachman-framework
<<IoT necesita una mejor seguridad>>, ISACA Journal Volume 3, 2017 https://www.isaca.org/Journal/archives/2017/Volume-3/Pages/iot-needs-better-security-spanish.aspx
<<Instituto Nacional de Estándares y Tecnología>>, Wikipedia, acceso el 17 de Noviembre del 2019, https://es.wikipedia.org/wiki/Instituto_Nacional_de_Est%C3%A1ndares_y_Tecnolog%C3%ADa
<< Defensa Frente a las Ciberamenazas>>, CCN-CERT, acceso el 17 de Noviembre del 2019, https://www.ccn-cert.cni.es/seguridad-al-dia/noticias-seguridad/8336-recomendaciones-del-nist-para-proteger-los-dispositivos-iot.html

Cloud Computing, controles

16 noviembre, 2019 by unaibermejofdez 1 Comment

En el post anterior recorrimos las diferentes tipos de riesgos que presenta el Cloud Computing y terminamos diciendo que es necesario utilizar los controles adecuados para poder mitigarlos. Y estos controles, comentamos que los íbamos a encontrar en marcos de trabajo. Pues bien, dedicaremos este post a explicar lo que son los controles y qué debe hacer un auditor para asegurarlos. Asimismo, y a modo de ejemplo, estudiaremos una serie de controles que responden a riesgos concretos que he extraído de diferentes fuentes. Sin más dilación, comenzamos.

¿Qué es un control? En pocas palabras, podríamos decir que es un mecanismo que define una organización con la finalidad de mitigar un riesgo. Y con mitigar nos referimos a, por un lado, reducir la probabilidad de ocurrencia del riesgo y, por otro lado, reducir el daño que pueda causar en caso de que ocurra. Estos criterios, probabilidad e impacto, aunque no lo dijéramos en el anterior post explícitamente, suelen ser los dos ejes de análisis a la hora de priorizar los riesgos.

Para entenderlo mejor, pongamos un ejemplo. Si tenemos un riesgo concreto de privacidad y seguridad (tal y como vimos en el anterior post) con los datos que almacenamos en la nube, póngase, riesgo de que nuestros datos sean interceptados por terceros no autorizados en la red de comunicaciones que mantenemos con el proveedor, podríamos tener el siguiente control: asegurar que los datos en tránsito por las redes de comunicación oportunas entre proveedor y consumidor están encriptados con claves privadas que solo conoce el segundo [1]. Esto es, si cumplimos con lo que dice el control, logramos mitigar el riesgo.

¿Fácil? Pues en realidad es más complejo de lo que parece. En primer lugar, existen multitud de riesgos concretos que debemos tener en cuenta, y es por eso, que como decíamos en el anterior post, vamos a necesitar guías y marcos de trabajo que nos permitan considerarlos sin que se nos escape ninguno. Y además, y esto aún no lo he dicho, los controles no solo deben implementarse… Deben auditarse. En otras palabras, debe asegurarse que los controles se cumplen. Y para ello, lo normal es que cuando se define un control, se le asocien una serie de pruebas de control o acciones de auditoría.

Para ese mismo ejemplo que veíamos antes, recogido de un documento oficial de ISACA [1], se definen las siguientes acciones de auditoría: (1) obtener las políticas de encriptación y procedimientos para datos en tránsito de la organización, (2) evaluar si los procedimientos incluyen lo siguiente: clasificación de datos en función de la sensibilidad (top secret, confidential, company confidential, public), tecnologías de encriptación adecuadas, gestión de claves apropiada y una lista de organizaciones externas del consumidor que poseen las claves de desencriptado. ¿Ya es algo más concreto verdad? Parece que empezamos a tener el control, valga la redundancia, sobre el control que hemos definido para el riesgo que queremos mitigar.

Dicho esto, y ahora que entendemos lo que es un control y cómo se debe asegurar, he tratado de identificar ciertos riesgos concretos para nuestro paradigma, el Cloud Computing, con el objetivo de haceros ver algunos controles que nos pueden ayudar a mitigarlos. Con esa finalidad, he construido una tabla con tres columnas: dominio (tipo de área donde se enmarca el control), control (definición del control, lo que se debe hacer) y riesgo mitigado (problema al que responde el control).

Para construir dicha tabla, me he apoyado principalmente en el documento [1], el cual define una serie de controles para la mitigación de riesgos en el Cloud Computing haciendo uso del marco de trabajo COBIT y el marco de trabajo COSO ERM. Mi trabajo ha consistido en agrupar los controles más significativos, descartar aquellos redundantes, resumirlos, clasificarlos por dominios y relacionarlos con el riesgo que buscan mitigar. Además, he usado a modo complementario los documentos [2] [3] [4] y he considerado los contenidos del anterior post para la definición de los riesgos mitigados. La tabla es la siguiente:

Tabla. Controles y riesgos mitigados Cloud Computing.

Espero que esta tabla os haya servido para haceros una idea de qué controles necesitamos si nuestra compañía quiere adoptar el Cloud. Supongo que os habréis dado cuenta, que tal y como adelantamos en el anterior post, todo gira entorno a controlar la complejidad del paradigma y asegurar que trabajamos con un tercero que nos ofrece las garantías necesarias. Asimismo, comentaros que si os quedáis con la curiosidad y queréis ver qué acciones de auditoría concretas tiene asociadas cada control, os recomiendo acudir al documento [1].

Para finalizar, como reflexión, permitidme deciros que si os fijáis, existen muchos tipos de controles, algunos más técnicos y otros quizás más de gestión. Y que a veces, al menos yo (como estudiante de ingeniería) y con ciertas preferencias personales hacia el mundo del desarrollo, nos cegamos con los aspectos tecnológicos y no somos capaces de ver lo importantes que son los aspectos organizativos. Si no hay una política de gestión de claves bien definida, da igual lo sofisticado o puntero que sea tu sistema criptológico, vas a tener vulnerabilidades. De la misma manera, por muy buena política de gestión de usuarios que hayas definido, como no uses una tecnología robusta que permita implementar de manera segura sus directrices, tienes un problema. Lo mismo, para los contratos y cumplimientos…

Con esto simplemente os quiero hacer ver que las TIC deben estar alineadas con negocio. Que las TIC, cada vez están más afianzadas como parte de la estrategia de la organización. Y que las TIC, cada vez están más lejos de ser una simple capa de soporte. En definitiva, quería remarcar que un auditor TI no es solo un profesional que asegura con su buen criterio que todo está en orden, sino también un puente entre el negocio y la tecnología.

Hasta aquí el cuarto post. ¡Gracias por leerme y nos vemos en el siguiente!

[1] «IT Control Objectives for Cloud Computing», ISACA, acceso el 16 de noviembre de 2019, https://www.isaca.org/chapters2/kampala/newsandannouncements/Documents/IT%20contro%20objectives%20for%20Cloud%20computing.pdf

[2] «Protiviti’s View on Emerging Risks – Cloud Computing», KnowledgeLeader, acceso el 16 de noviembre de 2019, https://www.knowledgeleader.com/knowledgeleader/content.nsf/web+content/nlpreviewjuly2019

[3] Zacharias Enslin, «Cloud computing adoption: Control objectives for information and related technology (COBIT) – mapped risks and risk mitigating controls». African Journal of Business Management 6 37 (2012): 10185-10194, acceso el 16 de noviembre de 2019, https://oceano.biblioteca.deusto.es/permalink/f/193pu0n/TN_crossref10.5897/AJBM12.679, https://academicjournals.org/journal/AJBM/article-full-text-pdf/363FCF530555

[4] «Riesgos y amenazas en Cloud Computing», INTECO-CERT, acceso el 16 de noviembre de 2019, https://www.incibe.es/extfrontinteco/img/File/intecocert/EstudiosInformes/cert_inf_riesgos_y_amenazas_en_cloud_computing.pdf

Cloud Computing, riesgos a considerar

2 noviembre, 2019 by unaibermejofdez 1 Comment

En este post, y tal como adelanté en el anterior, me voy a dedicar a ofrecer una visión general sobre los riesgos asociados al Cloud Computing.

Lo primero que debemos entender, si queremos listar o categorizar los riesgos asociados a este paradigma, es que dependiendo del modelo de servicio o del modelo de despliegue que elijamos (las diferencias quedaron claras en los anteriores posts) podemos encontrarnos con diferentes tipos de riesgos [1].

Por ejemplo, no es lo mismo desarrollar una nube privada y mantener todo dentro de nuestra organización que contratar a un proveedor de servicios y externalizar nuestra capacidad de cómputo y almacenamiento a una nube pública. Igualmente, no podemos considerar que existen los mismos riesgos si estamos consumiendo un modelo de servicio PaaS (Platform as a Service) que SaaS (Software as a Service). En el primero solo tenemos fuera de la empresa el hardware y los sistemas de soporte (las aplicaciones son nuestras, o al menos las ponemos nosotros) y en el segundo, no tenemos dentro de casa ni un -maldito- trozo de código [2]. ¿Se ve a lo que me refiero?

Y si a eso le añadimos que lo normal no es adoptar un único modelo de servicio o un único modelo de despliegue (por ejemplo, la nube híbrida es la combinación de los dos modelos de despliegue principales junto a soluciones on-premise) estamos ante un escenario de riesgos complejo de analizar. ¡No sé ni por donde se va a desmontar mi negocio!

Pero bueno, no todo es tan negativo. La industria se ha preocupado por este tema y ha solucionado parte de la complejidad. De hecho, hoy en día, a 2019, contamos con categorizaciones bastante exhaustivas y tenemos a nuestra disposición marcos de trabajo que, en mayor o menor medida, nos pueden ayudar a detectar y mitigar los riesgos asociados a este paradigma de manera metódica.

Una categorización que considero suficientemente completa es la que he leído en [1]. En este artículo, se listan seis esferas o áreas de riesgo que puede llegar a presentar el Cloud. Voy a tratar de resumirlas, pero recomiendo leer el artículo original:

Autenticación. Todo lo relativo al control y el aseguramiento de la correcta autenticación de usuarios. El Cloud Computing presenta retos en este ámbito, o mejor dicho, magnifica los retos que ya existían en modelos de computación tradicionales. La confidencialidad de la información está en el punto de mira cuando todos nuestros sistemas residen en la nube. Sobre todo, si residen en la nube pública, cuya gestión y buen gobierno dependen de un tercero.
Seguridad y privacidad. Otro frente es garantizar que los datos con lo que se opera en la nube se mantienen seguros y privados. Y de nuevo, los riesgos relativos a esta esfera tienen que ver precisamente con la irrupción de un nuevo agente: el proveedor de servicios. Cuando se contrata a un proveedor, se debe asegurar que este sigue los estándares y controles oportunos, o que tiene las certificaciones necesarias.
Compatibilidad con sistemas internos. Una serie de riesgos asociados al Cloud Computing tienen que ver con que la mayoría de compañías no pueden migrar todos sus sistemas a la nube. Por ejemplo, aquellos que son parte esencial de la estrategia de la organización, que son considerados propiedad intelectual o que son tan diversos que no son compatibles con la infraestructura de ningún proveedor. Existen dificultades y peligros en la interoperabilidad de sistemas, así como en la integridad de los datos que manejan. De nuevo, debido al factor de externalización.
Disponibilidad. Existen también riesgos relativos a la disponibilidad de los sistemas que residen en la nube. Hoy en día, dicha disponibilidad debe ser garantizada en todo momento, ya que los sistemas han comenzado a ser parte esencial de cualquier organización. En la nube, dada la complejidad del paradigma, se deben realizar controles, mecanismos y procedimientos de redundancia y testing muy exhaustivos, lo que expone a una organización a mayores costes y amenazas.
Continuidad de negocio. Si una organización adopta el Cloud (principalmente si hace uso de nubes públicas), está delegando su continuidad de negocio a un tercero: el proveedor de servicios. Si el proveedor sufre un ataque o una catástrofe, la empresa cliente también.
Propiedad intelectual y aspectos legales. Hay riesgos asociados con la dificultad de decidir quién posee realmente los datos en un entorno Cloud. ¿El proveedor? ¿El cliente? Las complicaciones legales entorno a este tema deben ser un riesgo a considerar. Asimismo, el Cloud Computing presenta riesgos a nivel de cumplimiento. Por ejemplo, leyes o reglamentos tales como el GDPR obligan a las empresas a considerar aspectos relativos a la protección de datos personales. Su incumplimiento puede acarrear multas millonarias. Si el proveedor no las cumple, el cliente tampoco.

Otra categorización que he encontrado interesante es la presente en [3] (apartado: Cloud Adoption – key risks and how to mitigate them), más centrada en las preguntas que debe realizarse toda organización que quiere migrar su infraestructura TI al Cloud. No obstante, no vamos a entrar en más detalles. La categorización anterior ya nos da una visión suficiente para hacernos una idea de los riesgos que presenta el Cloud. De hecho, podemos observar que la mayoría de riesgos tienen que ver con dos factores: la complejidad inherente al paradigma y la puesta en escena de un nuevo agente, el proveedor de servicios.

Visto los tipos de riesgos, puede ser buena idea priorizarlos. Y por supuesto, esta priorización debe estar ligada a la naturaleza y objetivos de nuestra organización. Si somos una empresa de servicios, póngase Netflix, debemos considerar la disponibilidad y la continuidad del negocio como factores de máxima prioridad. Sin embargo, si somos una empresa farmacéutica con un alto número de patentes, quizá sea más prioritario para nosotros los mecanismos de autenticación de nuestros sistemas y la privacidad y seguridad de nuestros datos, así como los aspectos relativos a propiedad intelectual. La disponibilidad quizá no sea crítica, o al menos no en la misma medida. Con esto quiero decir, que la priorización debe ser relativa a nuestras necesidades y no debemos caer en el error de intentar priorizar todos los riesgos de la misma manera.

A modo de anécdota, y para que veáis que esto no es palabrería, deciros que hace apenas unas semanas, Amazon Web Services (AWS), probablemente el mayor proveedor de servicios Cloud, sufrió un ataque DDoS que tumbó durante 8 horas muchos de sus servicios (EC2, RDS, ELB…) [4]. Los clientes que dependían de dichos servicios, paralizados. Al final, si quiero atacar a una empresa, puedo atacar directamente a su proveedor de servicios Cloud. ¡Easy peasy! Por ello, es esencial elegir al proveedor adecuado.

Pero como decíamos con anterioridad, existen marcos de trabajo que nos van a permitir evitar este tipo de escenarios. Si queremos cubrir, o al menos considerar, todos los posibles riesgos asociados al Cloud (imaginad que sois el encargado de la gestión de riesgos TI en vuestra empresa), necesitamos herramientas, guías y muchas tablas. Sí, muchas tablas, si no queremos morir en el intento. Con esto quiero decir que no se debe reinventar la rueda. Podemos apoyarnos en marcos de trabajo que incluyan todos los controles y procedimientos oportunos a considerar. Y para nuestra suerte, existen muchos de ellos [5]. Además, ya existen otro tipo de esfuerzos (documentación, pautas, artículos) para permitir a los profesionales centrar el tiro [6].

En el siguiente post, trataremos de profundizar en dicho ámbito: los controles y marcos de trabajo asociados al Cloud Computing.

¡Gracias por leerme y nos vemos en el siguiente post!

[1] «Risk Landscape of Cloud Computing», ISACA, acceso el 2 de noviembre de 2019, https://www.isaca.org/Journal/archives/2010/Volume-1/Pages/Risk-Landscape-of-Cloud-Computing1.aspx

[2] «Entendiendo la nube: el significado de SaaS, PaaS y IaaS», Genbeta, acceso el 2 de noviembre de 2019, htt ps://www.genbeta.com/desarrollo/entendiendo-la-nube-el-significado-de-saas-paas-y-iaas

[3] «Moving to the cloud – key considerations», KPMG, acceso el 2 de noviembre de 2019, https://assets.kpmg/content/dam/kpmg/pdf/2016/04/moving-to-the-cloud-key-risk-considerations.pdf

[4] «AWS customers hit by eight hours DDoS attack», Info Security, acceso el 2 de noviembre de 2019, https://www.infosecurity-magazine.com/news/aws-customers-hit-by-eighthour-ddos/

[5] Alosaimi Rana, Alnuem Mohammad. «Risk Management Frameworks for Cloud Computing: a critical review», International Journal of Computer Science & Information Technology 8 4 (2016), acceso el 2 de noviembre de 2019, https://pdfs.semanticscholar.org/6c88/c8f09a734317a611d4bcc566225907cbda31.pdf

[6] «Managing Cloud Risk: Top Considerations for Business Leaders», ISACA, acceso el 2 de noviembre de 2019, https://www.isaca.org/Journal/archives/2016/volume-4/Pages/managing-cloud-risk.aspx

Qué es BYOD y su cercana relación con el Mundo Móvil

1 diciembre, 2018 by M.B. 1 Comment

Buscando información sobre el mundo móvil, encontré una presentación de ISACA («La información se mueve») relacionada con los dispositivos móviles, en la que se muestra que existen varias posibles decisiones estratégicas que pueden tomar los directivos de una empresa:

Solución de plataformas estandarizadas
BYOD “Puro”
Estrategia combinada

El punto que más me llamó la atención fue BYOD, ya que es un concepto cada vez con mayor tendencia, debido a que las nuevas tecnologías cada vez son más accesibles para todos los usuarios. Al igual que los anteriores posts, se centra directamente con los dispositivos móviles de la propia empresa, pero con un leve cambio de perspectiva que se puede intuir en el significado de sus siglas: Bring Your Own Device, cuya traducción es “trae tu propio dispositivo”.

Con BYOD, los empleados utilizan sus propios dispositivos móviles personales, portátiles y tablets para acceder al correo electrónico corporativo, la documentación, aplicaciones, etc. Básicamente consiste en utilizar los dispositivos personales de los empleados en el ámbito corporativo para el desarrollo de sus actividades profesionales. De esta forma, las personas tienen un solo dispositivos para usar tanto para fines profesionales como personales. [1]

[Read more…]

Controles para la Gestión del Riesgo Empresarial en el Mundo Móvil

1 diciembre, 2018 by M.B. 1 Comment

Con los cambios continuos en el ámbito tecnológico y empresarial, surgen nuevas amenazas creadas por las nuevas aplicaciones móviles, por ello los auditores de TI y los profesionales de la seguridad deben adaptarse a estos cambios y anticiparse a los riesgos aplicar controles apropiados.

Para seleccionar dichos controles, primero se deben de localizar las capas de riesgo, los cuales hemos desarrollado en el anterior post “Gestión del Riesgo Empresarial en el Mundo Móvil”. En este post se explicaban las principales áreas de riesgo relacionadas con Mobile Workforce, pero si nos paramos a analizarlos la mayoría tienen un factor de riesgo común que afecta directamente a la organización: la información del dispositivo. Alrededor de este factor podemos segmentarlo en cuatro categorías principales de seguridad de aplicaciones móviles como se muestra en la figura 1.

Para afrontar el reto los auditores de TI hacen uso de los siguientes puntos mostrados en la siguiente tabla, de esta forma resulta más sencillo detectar la amenaza debido a la clasificación de los riesgos en dichas categorías [1]. [Read more…]

Controles en la propiedad intelectual

30 noviembre, 2018 by jmonasterio Leave a Comment

En el post anterior hable sobre los riesgos relacionados con la propiedad intelectual, concretamente sobre las fuentes de las que pueden surgir estos riesgos. El objetivo de este post es comentar los controles que un auditor tendría que implementar para tratar los diferentes tipos de riesgos.

Como mencionamos en el post anterior los riesgos pueden proceder de varias fuentes diferentes que suelen ser internas o externas a la organización. En función de esto aplicaremos unos controles u otros.

Entre los riesgos externos encontramos como más importantes (mayor probabilidad de que ocurran y mayor impacto para la empresa) los relacionados con temas de robo de información como puede ocurrir a través de ataques cibernéticos. Para tratar estos riesgos se recomienda usar los controles del estándar ISO 27002 [1] que se encarga de temas relacionados con la protección de datos. Algunos que podemos implementar son:

10.1 Controles criptográficos: asegurar el uso apropiado y efectivo para proteger la confidencialidad, autenticación y integridad de la información.
11.2.4 Mantenimiento de los equipos: asegurarse de que los equipos tienen todas las ultimas actualizaciones para evitar brechas de seguridad.
12.2.1 Controles contra el código malicioso: implementar controles para la detección, prevención y recuperación ante afectaciones de malware.
13.1 Gestión de la seguridad en las redes: implantar estándares, directrices y procedimientos de seguridad técnicos para redes y herramientas de seguridad de red como IDS/IPS (detección y prevención de intrusiones).
13.2.1 Políticas y procedimientos de intercambio de información: Deberían existir políticas, procedimientos y controles formales de transferencia para proteger la información que viaja a través del uso de todo tipo de instalaciones de comunicación.
15.1 Seguridad de la información en las relaciones con suministradores: se debe controlar el acceso de terceros a los sistemas de información de la organización.

Otro conjunto de riesgos bastante importante son los que pueden provenir de dentro de la organización. Los riesgos más comunes aquí se producen simplemente por descuido y debido a la poca educación de los propios empleados en materia de seguridad. En este caso podemos implementar los siguientes controles del ISO 27002 [1]:

7.1.1 Investigación de antecedentes: asegurarse al contratar que la persona contratada no es un posible espía de otra organización como el caso Ferrari comentado en el post anterior. [2]
7.2.2 Concienciación, educación y capacitación en seguridad de la información: es importante presentar a los trabajadores una guía de buenas prácticas que deben lleven a cabo para asegurarnos la protección de la información.
9.1 Requisitos de negocio para el control de accesos: establecer políticas de acceso a la información para evitar que nadie que no deba acceda a información confidencial.
11.1.2 Controles físicos de entrada: evitar que personas no autorizadas accedan a lugares de acceso restringido.
11.2.9 Política de puesta de trabajo despejado y bloqueo de pantalla: evita que personas sin acceso autorizado puedan visualizar en el ordenador información confidencial cuando el responsable del ordenador no está en su puesto de trabajo.
12.3 Copias de seguridad: asegurar de tener siempre disponibles copias de la información en caso de que alguien borre de forma voluntaria o por accidente información.
12.6.2 Restricciones en la instalación del software: evitar que los usuarios puedan instalar software malintencionado con el que puedan robar información.
13.2.4 Acuerdos de confidencialidad y secreto: firmar acuerdos de confidencialidad con los empleados para evitar que puedan divulgar en el futuro información confidencial. En caso de hacerlo se podría denunciar.

Por último siempre es importante actuar de acuerdo a lo que la ley establece. En caso de empresas internacionales será necesario cumplir con la ley vigente en cada uno de los países en los que se opera, que en temas de propiedad intelectual suele variar de unos a otros. En caso de que el país está englobado dentro de una organización superior como puede ser la UE también será necesario tener en cuenta su legislación. Para este caso se pueden implementar los siguientes controles del punto 18.1 que se encarga de cumplir con los requisitos legales:

18.1.1 Identificación de la legislación aplicable: se deberá estar al corriente de todos los cambios que se pudieran producir en la legislación.
18.1.2 Derechos de propiedad intelectual (DPI): se deberían implementar procedimientos adecuados para garantizar el cumplimiento con los requisitos legislativos, normativos y contractuales relacionados con los derechos de propiedad intelectual y utilizar productos software originales.
18.1.5 Regulación de los controles criptográficos.

Referencias:

[1]http://www.iso27000.es/

[2]https://lat.motorsport.com/f1/news/analisis-nace-un-nuevo-caso-de-spygate-en-la-f1/1594861/