Planificación de pruebas de seguridad de la información—Un enfoque práctico

Una vez que la aprobación para llevar a cabo una auditoría de seguridad de la información y, muy probablemente, una prueba de penetración (pen-test) de las redes y sistemas de una organización ha sido obtenido, entonces, ¿qué? ¿Por dónde empezar? Planearlo requiere una gran cantidad de trabajo y consideración y, para los principiantes, esta tarea puede ser bastante intimidante. La mala planificación puede tener graves consecuencias para la red, provocando la interrupción del negocio no deseado y, en el peor de los casos, un daño permanente. Dependiendo del apetito de riesgo de la organización, el alcance de la prueba podría ser drásticamente diferente.

Lo primero que hay que entender es que la auditoría de seguridad de la información no es una talla única para todo tipo de contrato. Es razonable empezar poco a poco y así progresivamente pasar a compromisos más complejos. También es importante señalar que las diferentes redes y aplicaciones pueden progresar en diferentes etapas.

Por ejemplo, si una organización tiene un sistema de supervisión de control y adquisición de datos (SCADA) que nunca se ha probado, ni escaneado para vulnerabilidades, uno podría querer no considerar partir las pruebas de seguridad de la información mediante la implementación de una prueba de penetración completa. Sería prudente comenzar con una evaluación de vulnerabilidades para probar las aguas y utilizar los resultados para endurecer el sistema para una futura prueba de penetración.

El modelo de la figura 1 propone una guía de madurez de las actividades de prueba mediante la correlación de diferentes combinaciones de las “reglas de contrato”, que se tratarán en detalle en este artículo, con la tolerancia al riesgo. Estas combinaciones predeterminadas se pueden utilizar como punto de partida.

Antes de considerar las reglas del contrato, es importante conocer los tipos de pruebas de seguridad de la información:

• Escaneo de Vulnerabilidades—Esta exploración examina la seguridad de los computadores individuales, los dispositivos de la red o aplicaciones para vulnerabilidades conocidas. Las vulnerabilidades son identificadas mediante la ejecución de un escáner, sniffers, la revisión de configuraciones, etc. Las vulnerabilidades identificadas no son explotadas. Esta prueba tiende a ser menos perjudicial y también menos costosa cuando es externalizado.
• Evaluación de Seguridad—Este se basa en la evaluación de la vulnerabilidad mediante la adición de verificación manual de los controles para confirmar la exposición mediante la revisión de ajustes, políticas y procedimientos. Eso tiene una cobertura más amplia. Evaluación de medidas de seguridad físicas serían cubiertos aquí.
• Prueba de Penetración—Esto sucede un paso por delante de una evaluación de vulnerabilidad. Se aprovecha de vulnerabilidades conocidas y desconocidas (por ejemplo, ataque de día cero). También hace uso de ingeniería social para la explotación del componente humano de la seguridad cibernética. Tenga en cuenta que la evaluación de vulnerabilidad se incluye en la prueba de penetración. La evaluación de vulnerabilidad es el punto de partida para buscar vulnerabilidades. Se llama la fase de descubrimiento (o reconocimiento) del ciclo de prueba. Los probadores (testers) de penetración deben ejecutar un escaneo de vulnerabilidades para identificar los puntos débiles a ser explotado.
• Ingeniería Social—A pesar que la ingeniería social es actualmente una técnica de las pruebas de penetración, muchas empresas, sin embargo, no están listas para una prueba de penetración y podrían optar por solo desplegar una campaña de correo electrónico de suplantación de identidad, por ejemplo, para verificar cuántos de sus usuarios son vulnerables a esta técnica y requieren una formación complementaria. Sus resultados son reportados, pero la información recopilada nunca es utilizada para penetrar la red.

Una evaluación no es mejor que una prueba de penetración o vice versa. Estas proporcionan resultados y valores diferentes. Su aplicabilidad dependerá de la tolerancia al riesgo, la sensibilidad y madurez de los sistemas de seguridad de la infraestructura. Pero, idealmente, las pruebas de penetración pueden ser ejecutadas sólo una vez al año, mientras que las evaluaciones de vulnerabilidad pueden llevarse a cabo con mayor frecuencia. Ambos el análisis de vulnerabilidades y pruebas de penetración, se pueden realizar en los sistemas internos y externos y dispositivos de red. Ambos pueden ser de alcance general o centrado en áreas específicas. La figura 2 muestra las áreas de enfoque y su aplicabilidad.

Reglas del contrato

Estas reglas deben ser considerados como las perillas de ajuste del sonido en un sistema de cine en casa. Una combinación podría ser mejor para una habitación más pequeña que está observando TV por cable, mientras que otra combinación podría ser mejor para una habitación más grande donde se reproduce un DVD. Una vez que estas reglas son entendidas, se hace más fácil para decidir los objetivos y el alcance de la prueba.

Un conjunto diferente de combinaciones se puede aplicar a cada sistema dentro del alcance. En una red muy sensible, uno se puede realizar solo un escaneo de vulnerabilidades y en otras redes, más robustos, se podría ejecutar una prueba más real de penetración. O bien, el sonido se puede ajustar de según se van ejecutando a las pruebas. Por ejemplo, cuando la prueba no tiene éxito en la penetración de la primera línea de defensa, la prueba se puede considerar completada o información adicional, o aún el acceso, se puede proveer para que el probador pueda prescindir de ella y reiniciar la prueba desde ahí. De esta manera, las vulnerabilidades adicionales pueden ser identificadas en caso que un atacante futuro pudiese violar el primer nivel de defensa.

La combinación elegida depende de la tolerancia al riesgo y la madurez de los procesos de seguridad cibernética de una empresa. Sin embargo, estas reglas permiten flexibilidad para ajustar el plan de pruebas de acuerdo con los sistemas y redes dentro del alcance.

Es importante tener en cuenta que el siempre mundo evolucionando de la seguridad de la información, es el alcanzar el nivel de madurez más alto y, como consecuencia, caer en la autocomplacencia puede ser peligroso.

A pesar de que se requiere un mayor nivel de madurez para realizar una prueba más realista, este viene con un precio ya que puede dar una falsa sensación de seguridad. Una prueba de caja negra completa permite al probador evaluar sólo la primera línea en la defensa en el momento de la prueba. ¿Pero qué pasa si ocurre un ataque de día cero que explota vulnerabilidades detrás de la primera línea de defensa? ¿Cómo responderían los sistemas internos? La cita de Andy Grove en la complacencia es muy aplicable a la seguridad de la información: “El éxito alimenta la complacencia. La complacencia engendra fracaso. Sólo los paranoicos sobreviven”.¹

Es esencial aplicar un enfoque cíclico a las pruebas de seguridad de la información como se sugiere en la figura 3.

Estrategia: Interna vs. externa

La estrategia determina si la prueba debe ser realizada desde fuera de la red como de la Internet, o desde dentro de la red o ambas.

• Externa—Esta es, quizás, la forma más ampliamente usada de prueba de penetración. Se dirige a la capacidad de un atacante remoto para llegar a la red interna. El objetivo de la prueba de penetración es a servidores específicos y a las “joyas de la corona” dentro de la red interna explotando servidores expuestos externamente, clientes y personas.
• Interna—Contrariamente a lo que piensa la administración que es esto, no es una estrategia de trabajo aplicable a la evaluación de vulnerabilidades solamente. Las pruebas de penetración se pueden ejecutar internamente cuando el objetivo es simular lo que sucedería si el propio empleado de una empresa está intentado llevar a cabo un ataque desde dentro o si un atacante logró obtener acceso a una red. El objetivo es típicamente el mismo que la prueba de penetración externa, pero la diferencia principal es el “atacante” o bien tiene algún tipo de acceso autorizado o está empezando desde un punto dentro de la red interna. Las pruebas internas pueden ayudar a las empresas a identificar debilidades en sus líneas de segunda o tercera defensa, considerando que un ataque interno pasará por alto las salvaguardas del perímetro. Las pruebas internas pueden responder preguntas tales como, “¿Qué tan bien esta segregada la red?” “¿Es la gestión de parches efectiva?” Si el atacante está en un segmento de red, las pruebas internas pueden determinar si él/ella puede ver los otros segmentos, lo que él/ella puede ver en esos otros segmentos, y cuáles son las actividades que él/ella puede llevar a cabo.

Anuncio: Encubierto vs. no encubierto

Esta sección de las reglas del contrato se utiliza para documentar si se darán a conocer las pruebas o no.

• No encubierto—Estas pruebas de penetración se llevan a cabo con el conocimiento y el consentimiento del personal de TI y, por supuesto de la administración superior. La siguiente decisión es la posibilidad de defender la red contra los probadores. Esta opción, también conocido como el enfoque del equipo azul vs. el equipo rojo, se puede terminar la prueba si el equipo defensor puede simplemente apagar la red una vez que se ha detectado a los probadores. En orden para maximizar la prueba de penetración, se recomienda que se den instrucciones específicas para no realizar ninguna acción para detener los probadores mientras se efectúa la prueba de penetración en el momento y la duración acordado. Esto puede ser una gran oportunidad para que el equipo defensor pueda aprender la forma de pensar de los piratas informáticos monitoreando el ataque y documentar que sistemas y sensores activan alarmas durante el ejercicio.
• Encubierto—Esta opción también se conoce como el Equipo Rojo, e implica la realización de una prueba de penetración sin el conocimiento del personal de TI, pero con el consentimiento de la administración superior. No anunciar la prueba de penetración ayuda la organización para comprobar las amenazas de seguridad que puedan surgir debido a errores humanos y la ignorancia. También examina la agilidad de la infraestructura de seguridad y la capacidad de respuesta del personal de TI.

Tipo: Gris vs. blanca vs. caja negra

Las organizaciones deben decidir el compartir o no información sobre el sistema y red con la organización evaluando (probadores). Esas decisiones son tipificadas como:

• Caja Negra—Ninguna información es compartida con el probador. Esto simula un ataque externo donde los probadores utilizaran más tiempo en la fase de reconocimiento y, debido a eso, tomas más tiempo y cuesta más.
• Caja Gris—Cierta información es entregada al probador—de la cual los hackers podrían, tal vez obtener al utilizar herramientas de reconocimiento o después de obtener acceso a la red de área local (LANs). Esto disminuye el tiempo ocupado por los probadores y, por lo tanto, también costos. La información entregada no compromete la validez de la prueba de penetración Ejemplos de tales informaciones sería una lista de servidores fuera del alcance o una versión más simple de la topología de la red.
• Caja Blanca—Toda información que los probadores necesiten para explotar vulnerabilidades es entregada. Esta opción es preferible cuando:
  • La tarea de definir el alcance se les deja a los probadores a determinar
  • Una auditoria completa de seguridad se está ejecutando
  • Organizaciones quieren simular un ataque desde una amenaza interna, como ser un empleado de ti descontento el cual ya tendría acceso a cierta información

No existe un tipo correcto o errado, y todas las opciones se pueden efectuar con o sin el conocimiento del personal de TI. Caja negra ofrece una prueba más realística desde la perspectiva de un hacker externo, pero la prueba caja blanca tiene el potencial de ser más devastadora porque los probadores tendrán el conocimiento de lo que es importante dentro de la red y donde están localizados—algo que los atacantes externos usualmente desconocen desde un inicio. Un enfoque de un ataque interno no siempre va requerir un tipo de prueba de caja blanca. Por ejemplo, si el objetivo es probar lo que un hacker podría hacer si él / ellas solo ingresaran a las oficinas de la compañía y conectaran un computador, entonces una estrategia interna de prueba con un tipo de prueba de caja negra podría ser seleccionada.

Técnica: No destructiva vs. destructiva

Es importante informar a los probadores que técnica será permitida durante el compromiso. Cuando métodos no destructivos (NDT) son seleccionados, probadores pondrá sus herramientas para evitar causar una negación de servicio (DoS), por ejemplo, o cualquier otro ataque que pudiese interrumpir las operaciones normales del negocio. NDT provee una prueba de concepto, pero no lo demuestra. Figura 4 lista técnicas comúnmente utilizadas. Estas técnicas deben ser discutidas con los probadores anticipadamente cuando la organización notifique a los probadores que tipo de pruebas pueden ser utilizadas durante el compromiso. Independientemente de la técnica seleccionada, es recomendable de explícitamente definir que herramientas y técnicas serán permitidas y cuales no serán permitidas. Por ejemplo, hay ataques y herramientas que pueden ser destructivas por naturaleza, pero pueden ser “sintonizadas a la baja” por el probador para que no causen un DoS, desbordamiento de memoria o que cualquier sistema se apague.

Un punto muy válido a ser considerado es el uso de herramientas de fuente abierto o desarrollado internamente por el probador para la evaluación de vulnerabilidades y pruebas de penetración. Ambos tipos de software vienen con riesgos y beneficios. Fuente abierto significa que el código fuente está disponible a todos los potenciales usuarios, y son gratis para utilizar, modificar y redistribuir el código fuente. Considerando que el código fuente es accesible, probadores usualmente pueden retocar el software, conectar exploits y remover características innecesarias. Esto puede mejorar eficiencia, velocidad y seguridad. El software de fuente abierto comúnmente utilizado para pruebas de seguridad de la información es Linux Backtrack and kali, el cual viene con una gran comunidad de soporte y, por lo tanto, desarrollan mejoras y adiciones versátiles.

En cuanto a las herramientas desarrolladas internamente, es muy probable que la mayoría de los probadores experimentados desarrollen herramientas ellos mismos para cubrir la brecha entre herramientas comerciales y de código abierto. Un ejemplo seria el desarrollo de una herramienta para escanear la red sin bloquear cuentas SQL (Structured Query Language) lo cual puede suceder al utilizar un scanner comercial.

El riesgo de que estas herramientas interrumpan el negocio o causen la propagación de malware puede ser controlado por:

• No permitir la instalación en el sistema objetivo
• Ejecutar las herramientas contra sistemas no productivos o sistemas de prueba primero
• Cerciorarse que el probador adquirió las herramientas de fuente abierto de sitios de confianza y efectuó un Secure Has Algorith 2 (SHA2) checksum para verificar integridad
• Cerciorarse que el probador ha utilizado un marco de desarrollo de software que pueda incluir una revisión por pares, para software interno
• Cerciorarse que el probador ha parcheado y actualizado el software apropiadamente

Y para técnicas de ingeniería social como es el identificador de llamadas y spoofing de direcciones de correo electrónico, uno puede escoger que se permita su implementación pasivamente, eso es, solo con el propósito de recolectar información durante la fase de reconocimiento. Otras consideraciones incluyen si los probadores serna permitidos ingresar a las oficinas de la organización, ingresar a las casas de los empleados y/o hackear las cuentas de redes sociales de los empleados.

Estas herramientas y técnicas pueden ser identificadas como permitidas solo con consentimiento previo y pueden ser manejadas en una base de caso por caso.

Declaración de trabajo

Además de asignar profesionales calificados y con experiencia para efectuar la prueba y conociendo las reglas del compromiso, también es esencial que un plan de pruebas sea desarrollado para establecer parámetros como es ser los objetivos, alcance, supuestos y riesgo.

Utilizando un modelo como se muestra en la figura 5, está la provee al probador con claras expectaciones para la prueba y transparencia y delinea el plan en una forma no técnica para que la alta gerencia la apruebe.

Antecedentes

Al desarrollar la prueba, es crítico mantener en mente que va requerir la aprobación de la alta gerencia (es preferible los ejecutivos senior) y, por lo tanto, los antecedentes debiesen proveerles con contexto detallando la necesidad de efectuar este tipo de trabajo, resumen de pruebas previas, razón fundamental para el objetivo y el alcance seleccionado, cambios efectuado al entorno de TI, nuevas amenazas, y así. Aquí es donde la justificación para utilizar una organización de evaluación de terceros puede ser previsto.

Metas

¿Cuál será el área de enfoque (referirse a figura 2) para la prueba? O, ¿será general? ¿Existe una amenaza particular contra la cual la empresa necesita probar sus controles? Por ejemplo, una organización puede escoger probar contra una vulnerabilidad particular como ser el bug Heartbleed, o puede escoger probar si es posible que hackers o un empleado disgustado obtenga acceso no autorizado al sistema ERP (Planificación de Recursos Empresariales) y transferir dinero en forma electrónica a una cuenta bancaria offshore. Pero para la mayoría de las compañías, buenas metas iniciales pueden simplemente ser: ¿Esta la organización segura? ¿Está la organización en cumplimiento?

Para asegurar que las pruebas agregan valor a la organización, es crucial identificar y entender las áreas de riesgo y/o el link potencial más débil en defenderse de los ciber ataques. Los marcos de evaluación de riesgos pueden ser útiles en identificar las metas para las pruebas. Organizaciones que han efectuado un análisis de impacto del negocio podrían utilizar esto como input para identificar áreas específicas de riesgos de negocio y ajustar la prueba de acuerdo. Por ejemplo, una organización que identifica datos de investigación y desarrollo como sus activos más importantes, podrían desarrollar un plan de pruebas que incluya intenciones de obtener acceso no autorizado a los datos. Organizaciones pueden desear involucrar a probadores de terceros en esta fase, ya que ellos pueden sugerir tendencias de la industria actuales.

Objetivos

Es aconsejable proveerles a los probadores con objetivos específicos. ¿Qué deben hacer los probadores una vez obtengan acceso a la red? ¿Debiesen dejar migajas? ¿Debiesen los probadores encontrar una aplicación específica y crearle cuentas de usuarios? Esos objetivos se tornarán claros y fácil definir según la organización se familiarice con sus sistemas y ciber riesgos. Un buen lugar para empezar es definir objetivos relacionados con la primera y/o segunda línea de defensa como ser los cortafuegos.

Alcance/fuera de alcance

El criterio de las pruebas puede ser a gran escala para la red entera y los sistemas o definida más estrechamente de dispositivos específicos como servidores web, ruteadores, SCADA, cortafuegos, servidores DNS, servidores de correo electrónico, y servidores de protocolo de transferencia de archivos (FTP) como se lista en figura 2. Para determinar la extensión a lo cual la prueba debe efectuarse, estas preguntas se debiesen hacer:

• ¿Que será probado?
• ¿En caso de solo ingeniería social, cuales empleados están en el alcance?
• ¿Desde dónde se va efectuar la prueba?
• ¿Cuándo no debiese efectuarse la prueba?
• ¿Están los sistemas productivos fuera del alcance?
• ¿Que hosts están fuera del alcance/restringidos?
• ¿Por quién será probado?

La mayoría de las organizaciones de evaluación utilizaran el número de hosts, usuarios, IPs externos y ubicaciones del alcance para calcular el costo del compromiso.

Ayuda tener un diagrama no técnico que muestra la red en el alcance y los puntos de inicio de la prueba (puertas) (figura 6). Esto le proveerá a la alta gerencia con contexto adicional y un entendimiento visual del alcance.

Factores de éxito

¿Cuándo se considerará la prueba un éxito? ¿Es cuando el probador ingresa a la red o cuando una violación no es posible? ¿Es suficiente el penetrar la red como prueba suficiente de la necesidad de endurecer los controles?

Las mediciones definidas en la sección de metas de este artículo pueden repetirse aquí para determinar, en detalle, que actividades deben efectuarse por la organización evaluadora o aun por el personal de TI para considerar la prueba exitosa.

Programar

Si el tema de tiempos no se resuelve apropiadamente puede ser catastrófico para una organización. Es fácil de imaginar el escandalo si una prueba de DoS fue efectuada en una universidad el día en que los estudiantes están programados para tomar sus exámenes en línea. Esto es un ejemplo de una pobre programación cómo también una mala comunicación entre el probador de penetración y la universidad. Una buena planeación y preparación ayudara evitar dichas malas prácticas.

Una prueba de penetración no dura para siempre y, por lo tanto, es importante ser explicito en el plan del periodo finito para la prueba. El plan debe también solicitarle a los probadores que notifiquen a las partes interesadas de la organización cuando ha iniciado las pruebas según el día acordado para comenzar.

Contactos

Una lista de contactos debiese desarrollarse para identificar todas las personas clave (incluyendo los nombres, roles, direcciones de correo electrónico y números de teléfono) participando en la planeación, coordinación y ejecución de las pruebas. Aquellos a los cuales hay que contactarlos primero en caso de preocupaciones, cambios y emergencias debiesen ser definidos claramente. La lista no debiese incluir personal que no necesita conocer acerca de las pruebas; el incluirlos puede confundir a la organización evaluadora.

Riesgo y contingencias

Todos los posibles factores de riesgo y su probabilidad de ocurrir durante el periodo de pruebas deben ser especificados. Un ejemplo de un riesgo puede ser que las actividades de las pruebas pueden inadvertidamente apagar la red causando interrupción de las funcionalidades del negocio. Una vez que los factores de riesgo han sido listados, una tabla puede prepararse con los controles preventivos y estrategias de mitigación en caso se materialice el riesgo (figura 7).

Entregables

Es importante proveer contexto y antecedentes a los resultados. Por ejemplo, si el número de vulnerabilidades reportado se ha duplicado en comparación al año pasado, es importante incluir el número total de los puntos escaneado a los resultados.

El reportar a la gerencia debe ser parte del compromiso de la prueba de penetración. Los probadores usualmente juntan un detalle y una presentación muy técnica resumiendo los resultados de la prueba. Las mejores prácticas es de tener una presentación técnica detallada para el equipo de TI (Director de TI [CIO] y gerentes clave) y una presentación corta separada para los ejecutivos que resuman las pruebas y se enfoquen en impacto de riesgo del negocio y planes de mitigación. Las mejores prácticas es de tener un resumen ejecutivo creado por auditoria interna.

Ejemplos de entregables a ser considerados incluyen:

• UN reporte técnico detallado sobre las vulnerabilidades del sistema explicado de una manera que sea comprendido por la alta gerencia. El reporte también debiese incluir, pero no esta limitado a:
  • Resultados de la prueba en términos técnicos de riesgos
  • Indicación de las habilidades necesarias para explotar vulnerabilidades (script kiddies, desarrolladores de virus/gusanos, investigadores de seguridad, hackers profesionales o hacktivistas)
  • Explicación de falsos positivos
  • Recomendaciones a corto plazo (tácticas)
  • Causa raíz, recomendaciones a largo plazo (estratégico)
  • Planes de acción de mejoras de seguridad
• Un reporte listando los controles de ciberseguridad (procesos y/o tecnologías) actualmente implementadas que estén funcionando efectivamente y su categoría contra las mejores practicas de la industria (débil, moderada, fuerte)
• Un reporte mostrando los métodos de ingeniería social utilizada y el factor de éxito en la compañía siendo evaluada

Aprobaciones

El obtener consentimiento de la alta gerencia antes de conducir las pruebas de penetración es vital. Dependiendo de requisitos legales de la organización, un formulario de autorización por separado puede ser requerido (además de las reglas del compromiso) que establezca que la organización evaluando no será penalizada ni penalmente responsable por interrupciones no intencionadas y perdidas o daños a los equipos.

Otras consideraciones

También se recomienda que los planes explícitamente expongan detalles relacionados con los siguientes temas:

• Alcance—Empleados/ubicaciones fuera del alcance para las actividades de ingeniería social
• Sanitización del Reporte—Existe un riesgo en la potencial circulación de una versión no sanitizada del reporte que incluya los IPs de la compañía u otras informaciones importantes. Organizaciones pueden considerar tener dos versiones del reporte para diferentes audiencias y métodos de distribución.
• Método de Distribución—Organizaciones pueden considerar utilizar solo métodos seguros para comunicar planes no sanitizados u otras informaciones suministradas sobre los sistemas y redes.
• Confidencialidad—La organización evaluadora debe hacérsele entender que cualquier información o datos obtenidos durante la prueba de penetración será tratada como confidencial y tendrá que ser devuelta o destruida en forma adecuada después de la prueba.

Referencias

• EC-Council ECSA, LPT Courseware Manual, v4, vol. 2
• Scarfone, K.; M. Souppaya; A. Cody; A. Orebaugh; Technical Guide to Information Security Testing and Assessment, National Institute of Standards and Technology, NIST Special Publication 800-115, USA, September 2008, http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf
• Tipton, H. F.; M., Krause; Information Security Management Handbook, 6^th Edition, CRC Press, USA, 2007
• Chan Tuck Wai, “Conducting a Penetration Test on an Organization,” SANS Institute InfoSec Reading Room, 2002, http://www.sans.org/reading-room/whitepapers/auditing/conducting-penetration-test-organization-67
• SANS Institute, “Guidelines for Developing Penetration Rules of Behavior,” InfoSec Reading Room, 2001, http://www.sans.org/reading-room/whitepapers/testing/guidelines-developing-penetration-rules-behavior-259
• SANS Institute, “Security Concerns in Using Open Source Software for Enterprise Requirements,” InfoSec Reading Room, 2009, http://www.sans.org/reading-room/whitepapers/awareness/security-concerns-open-source-software-enterprise-requirements-1305

Notas Finales

¹ Grove, A. S.; Only the Paranoid Survive: How to Exploit the Crisis Points That Challenge Every Company, Crown Business, USA, 1999