ISACA Journal
Volume 5, 2,017 

Translated Articles 

Abordando riesgo compartido en las evaluaciones de vulnerabilidad de aplicaciones de productos 

Michael Werneburg, CIA, PMP 

Las organizaciones de servicios con una aplicación a medida en una industria regulada tienen retos especiales al abordar las vulnerabilidades de las aplicaciones. En un proveedor que alojó una aplicación que contenía datos confidenciales, las correcciones no se implementaron en los sistemas de los clientes de manera oportuna a pesar de que no había impedimento técnico. Cuando el equipo de riesgo del proveedor de servicios encontró en última instancia la clave para obtener correcciones de seguridad aceptadas, fue en una apreciación matizada del riesgo, específicamente, el riesgo de aparecer negligente.

El problema

Las vulnerabilidades de las aplicaciones tienen factores de riesgo cercanos y secundarios. Los factores de riesgo cercanos son evidentes: las infracciones de los datos afectan a las personas afectadas cuya información personal está comprometida. Pero el riesgo secundario radica en la exposición legal a la organización del cliente, es decir, el riesgo para la organización de servicios tecnológicos, cuyo producto permitió el incumplimiento, sería responsable. Las infracciones de datos con frecuencia dan lugar a acciones legales, es decir, acciones que a menudo están arraigadas en la negligencia. A partir de 2016, el 75 por ciento de los casos derivados de una violación de datos incluyen la negligencia.1 En un sentido legal, la negligencia se define como “un incumplimiento del deber de cuidar adecuadamente”.2 La negligencia se puede determinar con algunas preguntas simples:

  • ¿Existe una obligación de cuidar entre las partes?
  • ¿Ha sido violada esa obligación de cuidar por la parte infractora?
  • ¿Ha resultado el daño de esa violación?

La definición de “deber de cuidado” cambia en función de la jurisdicción. En la mayoría de la Commonwealth, es una prueba de tres partes. “El daño debe ser razonablemente previsible como resultado de la conducta del acusado, las partes deben estar en una relación de proximidad, y debe ser justo, justo y razonable imponer responsabilidad”.3 En algunas jurisdicciones de los Estados Unidos, la primera prueba determina el deber de cuidado; en otros, está ausente.4 Si bien una revisión exhaustiva de cómo se aplica este tema en diferentes jurisdicciones está más allá del alcance de este artículo (y, francamente, del autor), el punto más destacado es este: Sin embargo, el deber está legalmente definido, un proveedor de servicios tiene la responsabilidad de asegurar la información, y un incumplimiento de esa responsabilidad abre al proveedor a una responsabilidad basada en la negligencia. Durante años, los reguladores han estado activos en la aplicación de la debida atención en caso de incumplimiento de los datos. La Comisión Federal de Comercio de los Estados Unidos, por ejemplo, habla de presentar unas 60 acciones contra “compañías que ponen los datos personales de los consumidores en riesgo irrazonable”.5 Por lo tanto, es imperativo que los proveedores de una aplicación que contenga cualquier forma de datos sensibles en un entorno regulado entiendan las implicaciones legales y regulatorias locales.

En el caso del proveedor de servicios de tecnología en este artículo, los reguladores relevantes incluyen la Oficina Canadiense del Superintendente de Instituciones Financieras (OSFI), que considera estas relaciones materialmente importantes para la estabilidad de las instituciones financieras reguladas federalmente.6 La legislación específica de la industria, como la Ley Gramm-Leach-Bliley (finanzas) de los Estados Unidos y la Ley de Responsabilidad y Portabilidad del Seguro Médico de los Estados Unidos (HIPAA) dictan explícitamente los controles y prácticas por los cuales se pretende asegurar los datos. En 2016, la Procuraduría General de California aclaró un conjunto específico de controles como su estándar para la seguridad razonable.7

Llevando de nuevo a una vulnerabilidad de la aplicación, los requisitos normativos y los regímenes de auditoría de servicios (como el omnipresente Service Organization Control [SOC] 2) dictaminan que se realiza una exploración de vulnerabilidades de la aplicación no menos de una vez al año. También requieren que el informe se comparta con el cliente. En el momento en que se ha producido una infracción, el proveedor de tecnología y sus clientes, todos tienen estos informes anuales en la mano. En ese momento, es difícil evitar la apariencia de negligencia si las vulnerabilidades documentadas en esos informes no han sido tratadas de manera oportuna, especialmente cuando se demuestre que esas vulnerabilidades ponen en peligro los activos de información confidencial.

¿Quién no quiere arreglos a las aplicaciones?

Si suena extraño que las partes interesadas en la aplicación no quieran arreglos de seguridad, vale la pena mirar cómo se comportan las industrias reguladas. En este ejemplo, el proveedor de servicios estaba activo en el sector de gestión de patrimonios. Ese sector típicamente tiene un enfoque conservador del cambio, una fuerte supervisión reguladora y, cuando se trata de liberar software, un enfoque en las características del negocio sobre factores no funcionales. En un entorno de este tipo, el proveedor de servicios no puede dictar la naturaleza o el momento de un lanzamiento de seguridad, independientemente de quién hospeda la aplicación.

En primer lugar, no siempre es fácil para un proveedor de servicios explicar la necesidad de arreglos de seguridad para la parte interesada del cliente responsable. Las partes interesadas del cliente que suelen manejar la relación con un proveedor de servicios y que deciden y programan costosos procedimientos de prueba y liberación no pueden apreciar o comprender arreglos de seguridad en primer lugar. Con frecuencia, las partes que toman estas decisiones tienen prioridades con relación a requisitos funcionales—lo que la aplicación hace para la organización—y no son recompensados por aventurarse en actividades que se ocupan de requisitos no funcionales. Eso hace que los responsables de la toma de decisiones difícil de motivar a través de la descripción de los arreglos de seguridad en términos de escenarios abstractos y vulnerabilidades recientes. El equipo de riesgo de una organización de servicios puede encontrarse haciendo grandes esfuerzos, discutiendo los puntos más finos de los hallazgos de prioridad media versus altos o críticos. O si finalmente convencen a las partes interesadas de la urgencia de una solución, podrían descubrir que se ha introducido una congelación o que el presupuesto del cliente para las pruebas y el despliegue no está allí. Incluso dentro de una organización de servicios, no siempre es fácil obtener permiso para acercarse a un cliente con respecto a las soluciones de seguridad necesarias. Muchas de las partes interesadas dentro de la organización de servicios tienen objetivos contradictorios, tal vez involucrando la entrega de nuevas características, conteniendo los costos de soporte o la gestión cliente que están en una fase sensible. En casi todos los casos, la organización de servicios considera los presupuestos de sus clientes como finitos y muchas prioridades compiten por el mismo presupuesto y no todas las demandas pueden ser satisfechas. El propietario del producto, el representante de la cuenta, los equipos de desarrollo y equipos de evaluación de la calidad del software sobrecargados, la supervisión presupuestaria e incluso el equipo de soporte que fue quemado por la implementación de un parche de seguridad fallido de años anteriores puede detener los parches de seguridad de dirigirse a los clientes y lo hacen a menudo.

Suponiendo que el equipo de riesgo supera la resistencia interna y encuentra las partes adecuadas para trabajar con el cliente, todavía tendrá que lidiar con la naturaleza lenta de los clientes regulados. Universalmente, los clientes sólo aceptarán un lanzamiento una vez que hayan realizado sus propias pruebas de aceptación. Cualquier prueba de liberación de la aplicación puede requerir mucho esfuerzo, programación y gastos por su parte. Sin embargo, los arreglos de seguridad, con su naturaleza no funcional, pueden ser notoriamente difíciles para una función de aseguramiento de calidad de software para una prueba de regresión adecuada, y las correcciones a veces requieren un entorno de prueba que coincide meticulosamente con el entorno de producción. El proceso de liberación en empresas cautelosas y reguladas es, asimismo, altamente adverso al riesgo y exige notas de lanzamiento exhaustivas. Y de nuevo, las soluciones de seguridad pueden ser difíciles de explicar a satisfacción para las partes interesadas—especialmente cuando se trata de demostrar que no hay efectos secundarios que permanecen inactivos.

Y sin embargo, ese riesgo compartido de ser descuidado después de una violación no desaparece por sí solo.

Aprovechando el riesgo

Después de intentar durante años usar la lógica para programar arreglos de seguridad, el equipo de riesgo finalmente encontró una manera de abordar la seguridad usando la cultura de aversión al riesgo de la industria a su favor. Trabajando con el equipo ejecutivo de la organización de servicios, el equipo de riesgo desarrolló un proceso de tres pasos que se centró no en vulnerabilidades e impactos, sino en el riesgo subyacente inherente a la relación: los impactos legales y regulatorios potenciales y la importancia de la negligencia en la conversación.

La implementación de este proceso de tres pasos comenzó tan pronto como el informe anual de evaluación de vulnerabilidad de aplicaciones de terceros estuvo en manos del proveedor de servicios. Los tres pasos son:

  1. Trabajar con los desarrolladores de aplicaciones de la organización de servicios, la oficina de administración del proyecto y el equipo de entrega para desarrollar estimaciones de:
    • La complejidad de los arreglos técnicos
    • Posibles impactos para los usuarios de las correcciones, si se implementan
    • Posibles horarios para la entrega fija
    En la empresa mencionada anteriormente, este paso ayudó a asegurar la participación de las partes interesadas internas. También ayudó al equipo de riesgo a filtrar los problemas que no pudieron ser solucionados por razones técnicas, falsos positivos y problemas para los cuales ya se estaban preparando correcciones. Y ayudó a los clientes a entender el contexto del informe de terceros.
  2. Escribir una interpretación del informe de evaluación que es rica en contexto de aplicación y, por lo tanto, fácil de entender para los clientes; incluir evaluaciones de impacto y calendarios potenciales; y enmarcar las vulnerabilidades en términos de las pérdidas conjuntas que podrían derivarse de la negligencia si las correcciones no se abordan de manera oportuna. Un informe personalizado debe ir a cada cliente que incluya sólo aquellas partes del informe de análisis que afectan a su versión de la aplicación personalizada. Esto permite que las partes interesadas del cliente, aparte del personal de riesgo de información, comprendan los problemas, sopesen adecuadamente las prioridades y participación en la conversación como partes informadas.
  3. Comente el informe del proveedor de servicios con cada cliente y solicite una firma que reconozca el informe.

Fue este paso final lo que llevó a casa el riesgo para el propietario de la aplicación en el lado del cliente: Se les pidió que reconocieran el riesgo en nombre de su empleador. Reconocer el riesgo no es lo mismo que aceptarlo, como demostró la conversación que siguió. En esa conversación, el cliente interpretó la firma del informe como un acto de búsqueda activa de asesoramiento sobre el riesgo que sentían que tenían que vivir y que debe ser mitigado con arreglos. Esto llevó a una discusión de qué arreglos para darle prioridad y que tan pronto la organización de servicio podría programarlos.

En este escenario, el equipo de riesgo había normalizado el proceso de seguridad de las revisiones de correcciones de seguridad. Como resultado, lo que seguiría sería una adición de nuevas versiones a la carga de trabajo de la organización de servicios.

Este proceso no es uno que debería ser desarrollado después de que el servicio haya entrado en producción. Debería quedar consagrado en el contrato entre el proveedor de servicios de tecnología y sus clientes. Fuentes como el Open Web Application Security Project (OWASP)8 han publicado una guía exhaustiva sobre el lenguaje contractual relacionado con la inclusión de la seguridad del producto en el ciclo de desarrollo de software y entrega. Algunos de estos requisitos incluyen:

  • Un reconocimiento por parte del cliente de que están obligados a participar en el proceso de aprobación de correcciones derivadas de las exploraciones de vulnerabilidades de aplicaciones
  • Un reconocimiento de que esas correcciones se publicarán de acuerdo con un calendario acordado

Hacerlo desde el principio elimina las objeciones, cualquier ambigüedad en la terminología y todo el otro arrastre experimentado por la organización de servicio.

Conclusión

El vendedor en el sector de la gestión de patrimonios discutido en este artículo tomó años para encontrar una manera de asegurar la liberación de exploración de vulnerabilidades de aplicaciones. En cuestión estaba la cultura del sector en el que estaba comprometido. La cultura tenía:

  • Un enfoque conservador al cambio
  • Una fuerte supervisión reguladora que pone un fuerte énfasis en el riesgo de terceros que surgen de las relaciones con proveedores de servicios tecnológicos
  • Un fuerte enfoque en las características empresariales sobre factores no funcionales como la seguridad

El equipo de riesgo encontró en última instancia una manera de aprovechar la primera característica contra los dos últimas. Incluso en los entornos más adversos para el cambio, las partes responsables se dan cuenta de que es difícil justificar la aceptación de un incremento del riesgo de ser descuidados con el propósito de ahorrar a la organización algunos inconvenientes y gastos de rutina asociados con resolver problemas de seguridad de aplicaciones.

1 Bryan Cave LLP, 2016 Data Breach Litigation Report, 6 April 2016, https://www.bryancave.com/en/thought-leadership/2016-data-breach-litigation-report.html
2 Duhaime’s Law Dictionary, “Negligence Definition,” www.duhaime.org/LegalDictionary/N/Negligence.aspx
3 e-lawresources.co.uk, “Negligence—Duty of Care,” http://e-lawresources.co.uk/Duty-of-care.php
4 Ibid.
5 Federal Trade Commission, Privacy and Data Security Update (2016), USA, January 2017, https://www.ftc.gov/reports/privacy-data-security-update-2016#how
6 Canadian Office of the Superintendent of Financial Institutions, Outsourcing of Business Activities, Functions and Processes, May 2001, www.osfi-bsif.gc.ca/Eng/fi-if/rg-ro/gdn-ort/gl-ld/Pages/b10.aspx
7 Harris, K.; California Data Breach Report 2012-2015, February 2016
8 Open Web Application Security Project, “OWASP Secure Software Contract Annex,” https://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex

Michael Werneburg, CIA, PMP
Es un practicante de riesgo tecnológico en Toronto, Ontario, Canadá. En una carrera de 23 años que abarca tres continentes, ha trabajado con empresas que van desde empresas start-up hasta algunas de las mayores instituciones financieras del mundo. Su pasión es apalancar el riesgo de efectuar cambios a través de las organizaciones tecnológicas.

 

Add Comments

Recent Comments

Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and from opinions endorsed by authors’ employers or the editors of the Journal. The ISACA Journal does not attest to the originality of authors’ content.