Recientemente, un artículo en The Wall Street Journal reveló que las empresas de outsourcing de TI en la India habían reducido el número de solicitudes de visas H1B (trabajador) hechas a las autoridades en los Estados Unidos incluso antes de que el presidente Trump expresó su preocupación por el impacto negativo de tales visas en el mercado de trabajo de los Estados Unidos.1 Mirándolo desde un alto nivel, esto no debería ser una sorpresa. La prestación in situ de proveedores de servicios especializados se sustituyó por servicios extraterritoriales. Ahora, gran parte del servicio de TI extraterritorial se ha trasladado a la nube. Más barato, mejor y más eficiente, son los factores que han impulsado las métricas de los servicios informáticos de hoy.
La reducción en las solicitudes de visas H1B apunta al origen fundamental de los cambios en la informática, el cual se apoya en la vista física y lógica del sistema. Una sola vista física puede admitir múltiples vistas lógicas. Aprovechando esta idea, el primer movimiento fue de archivos de datos a bases de datos; el siguiente fue la transición de activos físicos propios hacia recursos físicos compartidos del proveedor de servicios, para soportar las vistas lógicas del adquirente de servicios. Pasar a la nube significaría no tener que preocuparse tanto por la vista física y centrarse en las vistas lógicas, el verdadero valor del procesamiento de la información. Por supuesto, este desacoplamiento entre lo físico y lo lógico es un factor clave en el lanzamiento de la computación en la nube.
Los servicios en la nube han crecido dramáticamente recientemente y continúan aumentando su popularidad.2 Entre 2015 y 2020 se pronostica que la computación en la nube alcanzará una tasa de crecimiento anual del 19 por ciento. La nube implica compartir, lo que significa una eficiencia potencial porque un recurso compartido puede ser optimizado a través de muchos clientes. Por el lado del proveedor, compartir significa escalar para satisfacer las necesidades de un número creciente de clientes para mover más datos y aplicaciones a la nube. El crecimiento sin precedentes de esta idea se evidencia claramente en el mágico aumento en el mercado de servicios en la nube de Amazon, ¡no es de extrañar que el precio de sus acciones sobrepasó la marca de US $1.000 recientemente!
Curiosamente, la idea de no tener poseer una infraestructura propia y, en cambio, confiar en un recurso centralizado (como en la nube) o uno descentralizado (como en el caso de Airbnb) tiene un gran atractivo para la innovación y el crecimiento, mientras dramáticamente disminuye costos. El experimento actual de Google con Waze, una aplicación de navegación y tráfico basada en cooperación comunitaria en el área de la Bahía de San Francisco (Estados Unidos), tiene que ver con el compartir sin poseer: Si la persona A va al mismo lugar donde la persona B está conduciendo hoy, ¿por qué no conectar en Waze y planificar un viaje compartido? En los próximos 10 años, podría ser que los vehículos sin conductor combinados con las plataformas de viajes, impliquen no tener que poseer un vehículo o tener un garaje en el hogar.
Este emocionante desarrollo de servicios en la nube viene con riesgos nuevos o adicionales. Para citar un artículo de ISACA Journal, “Los beneficios de la computación en la nube se ven moderados por el potencial extremo de introducir riesgos incontrolados o imprevistos y amenazas a la información de una organización”.3 Si hay una tercera parte en la gestión de riesgos que el auditor de TI debería examinar a fondo, sería el proveedor(es) de servicios en la nube (CSP, según sus siglas en inglés cloud services provider). Cuando una empresa vive en la nube, está a merced de un tercero que puede tomar decisiones sobre sus datos y plataforma, de formas nunca vistas antes en la computación.4
Puntos ciegos
Mientras que sería difícil, si no imposible, identificar cada punto ciego en la plataforma de la nube, hay algunas categorías que ilustran el hecho de que, de hecho, tales puntos ciegos existen, y hay que buscarlos para que puedan ser abordados para mitigar cualquier riesgo oculto detrás de ellos. Cuatro fuentes principales de puntos ciegos son:
- Interoperabilidad entre la nube y los sistemas internos
- Asignación de responsabilidades entre el proveedor y el adquirente
- Una nueva definición de usuarios
- En algunas áreas de la nube, la naturaleza colaborativa del trabajo
La capacidad de los sistemas informáticos para intercambiar información, o interoperar, es cada vez más crítico en los ecosistemas de la nube dado que esa parte del sistema de la organización ahora reside en otra parte, con el CSP. Y, sin embargo, los flujos lógicos de datos y las interacciones entre los usuarios tienen que ser soportados como si el sistema nunca hubiera sido dividido. Por la naturaleza misma del acuerdo, la interoperabilidad es básica en los servicios en la nube. Sin embargo, muchos usuarios no son conscientes de si su trabajo está sucediendo en la nube o en su sistema (local). Dependiendo de la escala y complejidad de la subcontratación, la gestión de la interoperabilidad puede ser un desafío importante, incluso cuando se ha tenido el debido cuidado en la selección del CSP. A menudo, la confusión surge de la falta de conocimiento acerca de la aplicación, como si la versión en uso es independiente de la nube (por ejemplo, Office 2010), es soportada en la nube (por ejemplo, Office 2013) o está integrada en la nube (por ejemplo, Office 2016).
Un punto relacionado es que, en esencia, ahora hay dos custodios de todo (sistema), y un seguimiento exhaustivo de quién hace qué es difícil, especialmente si es probable que cambie dinámicamente. El destino del adquirente está profundamente relacionado con los acontecimientos que se desarrollan en el espacio del proveedor. Por ejemplo, cuando el proveedor es hackeado, la información confidencial de la organización está en riesgo sin importar la rigurosidad de la seguridad de la organización. Depender únicamente de los acuerdos de nivel de servicio (SLA) es impráctico, ya que hay muchos detalles minuciosos que necesitan ser identificados e incorporados en la asignación de deberes. Podría ser incluso necesario para el adquirente hacer que el proveedor se comprometa a cumplir con las políticas claves del cliente y hacer una auditoría de las áreas críticas por parte del cliente. La falta o el mal manejo de una tarea en cualquiera de los lados puede tener consecuencias graves, por lo tanto, es importante saber quién es responsable de la tarea.
En el pasado, los usuarios finales estaban dentro de la empresa y estaban sujetos a estrictos protocolos y requisitos. No todos eran usuarios finales y las tareas de gestionar la cadena de valor del procesamiento de información pertenecían a unos pocos. No más. De alguna manera, la división entre las vistas físicas y lógicas empoderan a la organización a hacer más con la información para crear riqueza. La definición tradicional de usuarios finales ahora se amplía para incluir prácticamente todos los que utilizan la información, creando nuevos datos o ejecutando aplicaciones desde sus dispositivos. Esta vasta expansión del universo de usuarios es diferente en su cultura. Los usuarios finales incluso tienen la expectativa de que pueden comenzar a trabajar en una tarea en la oficina, y luego retomarla de vuelta en casa más tarde en la noche, sin notar diferencia entre los dos. Quieren trabajar con sistemas (en cualquier lugar, en cualquier momento y desde cualquier dispositivo), mientras que a menudo tienen poca conciencia o comprensión de la exposición a riesgos relevantes. Es posible que no sepan dónde están guardando sus documentos, por ejemplo, o qué tan seguros son estos documentos.
Finalmente, debido a que la nube facilita compartir, el trabajo colaborativo ha florecido en las plataformas de nube. Cuando dos o más usuarios comparten conjuntamente los deberes de un proyecto o una tarea, el mejor escudo protector que existe es representado por el eslabón más débil de la cadena. Esto crea incertidumbre sobre cuál podría ser la exposición. Incluso gente experta en tecnología, a veces no están plenamente informada sobre el riesgo y puede o no considerar prestar atención a ella como algo importante. Un grupo colaborativo normalmente se enfoca en el resultado principal del proyecto y podría no ver más allá de los requerimientos centrales del proyecto.
Protección/mitigación
La interoperabilidad implica muchos canales de comunicación y acceso frecuente a datos y sistemas a través del perimetro de la nube. La autorización de acceso, la encriptación de los datos almacenados y en tránsito y los privilegios de usuario basados en roles, son algunos de los medios más utilizados para asegurar la comunicación entre cliente y proveedor. En cuanto a las aplicaciones soportadas por cualquiera de los lados, proveedor o adquirente, se debe seguir un proceso riguroso de control de cambio orientado hacia el entorno de la nube. Recientemente, el proceso de control de cambios ha recibido un creciente escrutinio por parte de los auditores. El nivel y la cantidad de información requerida para hacer incluso cambios simples, se han multiplicado después de este escrutinio. Y documentar un simple cambio podría tardar hasta 30 minutos, en comparación con menos de un minuto hace unos años.
Al definir las responsabilidades entre el proveedor y el adquirente, una auditoría periódica a los SLA (acuerdos de nivel de servicio) y los documentos relacionados, podría sugerir vulnerabilidades derivadas de utilizar un lenguaje vago, entendimientos implícitos o promesas no documentadas. Sin una revisión de cómo los dos socios solucionan las diferencias en tareas críticas, se hace difícil modificar los compromisos existentes y, por lo tanto, mejorar las expectativas.
En un entorno de sistemas donde la presencia en la nube es significativa, no solo es necesario exigir a los usuarios finales que completen con éxito un entrenamiento adecuado, sino que también lo hagan regularmente para la mayoría de los entrenamientos, incluidas las actualizaciones. Si bien esta es un área blanda debido al elemento humano involucrado, potencialmente ofrece la mejor esperanza para cualquier tipo de prevención de accidentes o incidentes. Incluso un blog de lo que salió mal y cómo se abordó, podría ayudar a los usuarios a entender la gravedad de la tarea y cómo cosas aparentemente triviales generan fallas en el comportamiento normal. La instancia de entrenamiento de usuarios finales no puede ser exagerada. Por ejemplo, en el caso del Banco de la Reserva Federal de Bangladesh, aproximadamente 90 millones de dólares fueron robados por piratas informáticos; la razón fue que mientras el sistema SWIFT5 parecía bastante seguro, el entorno en el que estaba operando en Bangladesh generó vulnerabilidades.6 El sistema permaneció logueado incluso después de horas de trabajo, claramente un error de usuario, haciendo factible para los hackers explotar el banco.
En las instancias de trabajo colaborativo, es importante fortalecer el eslabón más débil de la cadena. Esto se puede hacer exigiendo un entrenamiento riguroso y haciendo que el grupo discuta respecto de la exposición y las vulnerabilidades, o simplemente, respecto de qué podría salir mal y cómo evitarlo. Este enfoque blando debe estar soportado por controles de software, hardware y comunicaciones apropiados para crear una defensa en profundidad para el entorno colaborativo.
En resumen, las nubes (públicas) dividen las tareas del sistema en organizaciones independientes. El riesgo, por lo tanto, casi se duplica, como si los dos grupos de toma de decisiones actuaran al unísono como una sola entidad. Un tsunami en la ubicación del proveedor también es para todos los efectos prácticos, un desastre importante para el adquirente. Cualquier interrupción en la nube de Amazon podría significar interrupciones para sus clientes, como Netflix, lo que a su vez, afectaría a millones de clientes de Netflix. El más débil de las dos entidades probablemente generará más preocupaciones sobre los riesgos de seguridad. Los objetivos de confidencialidad, integridad y disponibilidad en el entorno de la nube son producto de esfuerzos conjuntos, con requerimientos a menudo especificados por el adquirente de servicios en la nube. En este esfuerzo conjunto, todos los proveedores importan. Una encuesta de febrero del 2017 realizada por Intel Security llegó a la siguiente recomendación: Las organizaciones deberían buscar soluciones de seguridad especializadas que proporcionen una capa de control equivalente en todos los proveedores.7 La identificación y mitigación de puntos ciegos en todas las plataformas en la nube que estén en uso, es un paso crítico para la fiabilidad y sostenibilidad tanto del proveedor como del adquirente de servicios en la nube.
Notas finales
1 Meckler, L.; N. Purnell; “Use of H1B Visas Fell Before Donald Trump’s Critiques of Program,” The Wall Street Journal, 5 June 2017, www.wsj.com/articles/use-of-h1b-visas-fell-before-donald-trumps-critiques-of-program-1496682157
2 Columbus, L.: “Roundup of Cloud Computing Forcasts, 2017,” Forbes, 29 April 2017, www.forbes.com/sites/louiscolumbus/2017/04/29/roundup-of-cloud-computing-forecasts-2017/#29787c3131e8
3 Cadregari, C.; “Every Silver Cloud Has a Dark Lining,” ISACA Journal, vol. 3, 2011, www.isaca.org/resources/isaca-journal
4 Trapani, G.; “The Hidden Risks of Cloud Computing,” Lifehacker blog, 29 July 2009, http://lifehacker.com/5325169/the-hidden-risks-of-cloud-computing
5 SWIFT, https://www.swift.com/
6 Burne, K.; R. Sidel; “Hackers Ran Through Holes in SWIFT’s Network,” The Wall Street Journal, 30 April 2017, www.wsj.com/articles/hackers-ran-through-holes-in-swifts-network-1493575442
7 Greengard, S.; “Why Cloud Security Is Still a Concern,” Baseline, 3 March 2017
Vasant Raval, DBA, CISA, ACMA
Es profesor de contabilidad en Creighton University (Omaha, Nebraska, EUA). Coautor de dos libros sobre sistemas de información y seguridad, sus áreas de enseñanza e investigación incluyen la seguridad de la información y el gobierno corporativo. Puede ser contactado en vraval@creighton.edu.
Don Lux, MSITM
Es MTS 1, ingeniero de software en PayPal y estudiante de doctorado en Creighton University. Tiene casi dos décadas de experiencia en TI en varios roles como programador, probador automatizado, ingeniero de lanzamiento, gerente de lanzamiento y ingeniero de soporte. Puede ser contactado en donlux@creighton.edu.