Joven hacker sonriendo

Hackeamos su software

cero falsos positivos

Inteligencia experta + tecnología especializada

Preguntas frecuentes

A continuación, se encuentran múltiples preguntas que surgen comúnmente cuando hablamos de Hacking Continuo.

  1. ¿Qué es hacking continuo?

    Es el servicio que permite a una organización realizar Ethical Hacking en etapas tempranas en el ciclo de vida de desarrollo de software. Teniendo como objetivo garantizar el 100% de cobertura sobre la aplicación.

  2. ¿Qué beneficio tiene aplicar hacking continuo sobre una aplicación?

    1. Minimizar el costo de reparación ya que se realiza cuando la aplicación aún se encuentra en desarrollo, no en ambiente productivo.

    2. Reducir el tiempo de certificación de seguridad a cero ya que el Ethical Hacking se ejecuta en paralelo al proceso de desarrollo.

    3. Obtener información clara y detallada sobre las vulnerabilidades detectadas en la aplicación para que todos las personas involucradas en el proyecto estén sincronizados acerca de las vulnerabilidades encontradas, atendiendo todas las inquietudes presentadas por los desarrolladores sobre las vulnerabilidades reportadas de forma que puedan trabajar en su remediación sin contratiempos.

  3. ¿Cuáles son los insumos necesarios para la prestación del servicio?

    El servicio se puede desarrollar en fases de forma complementaria:

    1. Fase 1: El insumo fundamental para el servicio es el acceso a la rama de integración del repositorio de código donde se almacena la aplicación. En esta fase aún no se cuenta con una aplicación desplegada por lo que el Ethical Hacking se enfoca en el código fuente.

    2. Fase 2: Sumado a lo anterior y cuando el proyecto cuenta con una aplicación desplegada (Ambiente de Integración), el Ethical Hacking aumentan su cobertura incluyendo Ethical Hacking sobre la aplicación.

    3. Fase 3: Esta fase es transversal a las anteriores. En ésta se incluye la infraestructura dentro del Ethical Hacking. Solo aplica si la infraestructura que soporta la aplicación se encuentra definida como código. Ademas de estar almacenada en el repositorio mencionado en la fase 1.

  4. ¿Cuales son las condiciones técnicas que debo cumplir para tener hacking

    continuo?

    Se requiere acceso a Git y al ambiente de la rama en monitoreo, mediante Linux automatizable. Es decir no se soporta ambientes que por ejemplo:

    1. Acceso al ambiente mediante una VPN que solo funcione en Windows

    2. VPN en Linux que requieren interacción manual como un token OTP.

    3. VPN Site to Site

  5. ¿Qué tipo de Ethical Hacking incluye el servicio de Hacking Continuo?

    El servicio incluye análisis de código fuente, Ethical Hacking de aplicación (Ver pregunta 3) y Ethical Hacking de infraestructura (Ver pregunta 3).

  6. ¿Qué es una vulnerabilidad?

    Es cualquier situación que representa un riesgo de seguridad (Integridad, Disponibilidad, Confidencialidad, No repudio) sobre una aplicación.

  7. ¿Que es un autor activo y como lo identifican?

    Un autor activo es el usuario con acceso al repositorio Git que realizó cambios sobre código almacenado en el repositorio durante el mes analizado.

  8. ¿El servicio es automático mediante herramientas

    o es el resultado de un proceso manual?

    Las herramientas son incapaces de extraer información de negocio como información de clientes o empleados que le den sentido y peso a la vulnerabilidad. Fluid Attacks presta sus servicios con personal experto usando un conjunto de herramientas de asistencia al ataque adquiridas y otras desarrolladas por Fluid Attacks. Usamos este método pues las herramientas automáticas de detección de vulnerabilidades presentan los siguientes problemas:

    1. Fuga de vulnerabilidades (detectan un porcentaje mínimo de las existentes).

    2. De aquellas que reportan, muchas son falsos positivos.

    3. Las herramientas no están en la capacidad de relacionar vulnerabilidades para aumentar el nivel de explotación.

  9. Si el hacking es manual, ¿Cómo un proyecto grande puede escalar

    a medida que se tienen más y más autores activos (desarrolladores)?

    Los niveles de servicio estándar permiten cubrir las necesidades del 95% de las aplicaciones empresariales en desarrollo, ya que la suscripción se toma de acuerdo a los desarrolladores activos en el proyecto y esto es lo que define la cantidad de recursos asignados al proyecto.

  10. Si el hacking es manual, ¿Cómo se escala cuando se tiene

    un portafolio de aplicaciones grande y en constante crecimiento?

    De acuerdo a nuestros históricos, capacidad de reclutamiento y formación. Fluid Attacks está en capacidad de incluir entre 5 y 10 aplicaciones nuevas cada mes en el servicio de hacking continuo.

  11. ¿El costo del servicio varía de acuerdo al alcance o fases desarrolladas?

    Si. El costo del servicio varia a la cantidad de autores activos identificados en el proyecto cada mes

  12. ¿Por qué es necesario el acceso al código almacenado en el repositorio?

    El servicio de Hacking Continuo se basa en ejecutar el las pruebas de Hacking de forma continua. Siempre sobre la última versión del código.

  13. ¿Cuándo inicia la prestación del servicio?

    Desde el momento que se recibe la orden de compra.

  14. ¿Porque existe un mes 0 y como funciona el setup?

    La mensualidad 0 es una mensualidad de inicio que se paga para comenzar el setup de la prueba, en este setup se asigna un líder de proyecto y este es el encargado de gestionar la conexión de ambientes, perfilamiento, creación de usuarios, asignación de permisos y todos aquellos insumos necesarios para iniciar la revisión sin contratiempos.

  15. ¿Es posible prestar el servicio de hacking continuo OnPremise?

    Dado el modelo operativo que soporta el servicio este solo se puede prestar de forma remota.

  16. ¿Es posible agendar reuniones para realizar seguimiento sobre el servicio?

    Todas las aplicaciones suscritas al servicio de hacking continuo cuentan con un líder de proyecto atento a atender las reuniones requeridas, coordinando previamente la disponibilidad para la realización de ésta.

  17. ¿Cómo se determina el avance del proyecto?

    Se ofrecen métricas que permiten determinar el estado actual del proyecto como lo son:

    1. Índice de cobertura sobre el código fuente.

    2. Porcentaje de vulnerabilidades remediadas.

  18. ¿Cuándo finaliza la prestación del servicio?

    El servicio es contratado por un mínimo de 12 meses. Renovables automáticamente tras ese periodo. La finalización se da en común acuerdo por medio de una solicitud escrita por los canales definidos.

  19. ¿Puedo cancelar la suscripción en cualquier momento?

    El servicio puede ser cancelado en cualquier momento a partir del cuarto mes. Se puede solicitar la cancelación por cualquiera de los medios de comunicación definidos en el proyecto.

  20. ¿Si la cobertura sobre mi aplicación llega a 100% se suspende el servicio

    hasta que se agregue nuevo código al repositorio?

    No. Aunque se alcance una cobertura del 100%, realizamos múltiples verificaciones sobre el código ya revisado con el fin de descartar la presencia de falsos negativos. Incluyendo dentro de nuestras verificaciones las vulnerabilidades a componentes de terceros que van siendo publicadas día a día.

  21. ¿Cómo se califica la criticidad técnica de una vulnerabilidad?

    Usamos el estándar internacional CVSS para obtener una calificación cuantitativa que va de 0 a 10, donde 0 es la más baja y 10 la más alta.

  22. ¿Cómo obtengo información sobre las vulnerabilidades

    encontradas en mi aplicación?

    El servicio de Hacking Continuo cuenta con una plataforma de reporte e interacción llamada Integrates. Así todos los actores de la cadena de valor de un proyecto tienen acceso al detalle de las vulnerabilidades reportadas por Fluid Attacks en la prestación del servicio.

  23. ¿Qué tipo de informes son generados durante la prestación del servicio?

    Desde Integrates es posible generar un informe técnico en formato Excel y otro en PDF disponibles durante toda la ejecución del proyecto. También se puede generar un informe ejecutivo tipo presentación en formato PDF una vez se finaliza el proyecto.

  24. ¿Qué pasa luego de que Fluid Attacks reporta una vulnerabilidad?

    Una vez se reporta la vulnerabilidad el objetivo es que esta sea solucionada. Para esto los desarrolladores cuentan con acceso a Integrates, permitiendo obtener de primera mano la información, aplicando las correcciones necesarias para remover las vulnerabilidades de la aplicación.

  25. ¿Cómo se entera Fluid Attacks que una vulnerabilidad está remediada?

    A través de Integrates cualquier usuario con acceso al proyecto podrá solicitar la revisión de las vulnerabilidades corregidas. Una vez se solicita, recibimos una notificación que incluye un comentario sobre la solución aplicada, realizamos la verificación de cierre confirmando la efectividad de la solución, procediendo a notificar a todo el equipo del proyecto sobre los resultados de la verificación a través de correo electrónico.

  26. ¿Cuántas verificaciones de cierre están incluidas en el servicio?

    El servicio cuenta con verificaciones de cierre ilimitadas.

  27. ¿Por qué debo anunciar el cierre de una vulnerabilidad si Fluid Attacks

    tiene acceso al repositorio de código?

    Uno de los objetivos del servicio de Hacking Continuo en conjunto con Integrates es mantener una comunicación clara y fluida entre todos los actores del proyecto. Al dar aviso sobre la remediación de una vulnerabilidad se está informando no solo a Fluid Attacks sino a todo el equipo del proyecto.

  28. ¿Qué pasa si considero que algo no es una vulnerabilidad?

    Dentro de Integrates contamos con una sección de comentarios donde se podrá dar a conocer las razones por las cuales considera que no es una vulnerabilidad. Allí Fluid Attacks y los demás integrantes del proyecto podremos establecer un diálogo que nos lleve a determinar la validez de una vulnerabilidad.

  29. ¿Todas las vulnerabilidades reportadas deben ser remediadas?

    La remediación de una vulnerabilidad es una decisión que queda a discreción del cliente. En Integrates se cuenta con la opción de tratamiento donde se define si la vulnerabilidad va a ser remediada o asumida por el cliente.

  30. ¿En caso de asumir una vulnerabilidad, se excluye de los informes

    de Integrates?

    Dentro de los informes se encuentra el tratamiento definido para las vulnerabilidades. Teniendo esto en cuenta esto las vulnerabilidades asumidas permanecen en los informes con la aclaración sobre su tratamiento.

  31. ¿Si la aplicación está almacenada en múltiples repositorios

    pueden ser revisados todos?

    Es posible realizar la verificación de múltiples repositorios con la única condición de que se hace sobre la misma rama en cada uno de ellos. Si se define que la rama sobre la que se ejecutará el Ethical Hacking es QA esta misma rama debe estar presente en todos los repositorios incluidos dentro del servicio.

  32. ¿Si ya tengo código desarrollado hace tiempo es posible usar el servicio?

    Si es posible. En este escenario se tienen dos opciones:

    1. Se realiza un Health Check en el que se revisa todo el código existente hasta la fecha. Posteriormente se continúa con la ejecución normal del servicio con los alcances definidos (ver pregunta 11). Esta opción aplica mejor sobre aplicaciones que se encuentran en desarrollo.

    2. Comenzar la suscripción con los límites estándar (Ver pregunta 10) donde mensualmente iremos aumentando la cobertura hasta alcanzar el 100%. Esta opción aplica mejor para aplicaciones donde no se está desarrollando constantemente.

  33. ¿Que procedimiento tiene Fluid Attacks para desatrasar la revisión

    del código ya existente antes de iniciar el Ethical Hacking?

    Fluid Attacks recomienda que tanto el desarrollo de la aplicación como el Ethical Hacking de seguridad comiencen al mismo tiempo. Sin embargo, esto no siempre ocurre así. Para ello, tenemos una actividad llamada HealthCheck que permite poner al día (desatrasar)​ las inspecciones de seguridad cuando el desarrollo ha comenzado con anterioridad.

  34. ¿Que pasa si no se realiza el health check, pero igual quiero tomar el

    servicio de hacking continuo?

    Esto es una decisión de riesgo, ya que va existir un código que nunca se va ha probar por ende no es posible saber que vulnerabilidades existen ahí y no se van a identificar. Fluid Attacks garantiza que se prueba el 100% del volumen de cambio del código, pero lo que ya esta hecho no lo puedo probar nunca, porque no alcanzo.

  35. ¿Los repositorios deben estar en un sistema de control

    de versiones específico?

    El servicio de Hacking Continuo se basa en desarrollos que usan GIT como control de versiones. De esta forma se hace necesario el uso de este sistema para la correcta prestación del servicio.

  36. ¿Fluid Attacks guarda la información de las vulnerabilidades encontradas?

    La información se almacena únicamente durante la prestación del servicio. Una vez finalizado el servicio se conserva la información por 7 días hábiles tras los cuales es borrada de todos los sistemas de información de Fluid Attacks.

  37. ¿El servicio de Hacking Continuo requiere algún tipo

    de metodología de desarrollo?

    No. El servicio de Hacking Continuo es independiente a la metodología de desarrollo utilizada por el cliente. Los resultados entregados por el servicio se convierten en un insumo en la planeación de los ciclos de desarrollo. Por lo tanto no es impedimento para continuar con los desarrollos.

  38. ¿Fluid Attacks realiza demostraciones en teleconferencia de forma periódica?

    ¿Cuál es el procedimiento para programarlo?

    Si, hacemos demostraciones frecuentemente. Para tal fin solo debe indicarnos los emails de los asistentes y 3 opciones de horario de 1 hora de duración, con esto enviaremos la invitación en los horarios de nuestra conveniencia.

  39. ¿El desarrollo del Ethical Hacking en el modelo continuo

    depende del tipo de repositorio donde tengo el código?

    ​No, el cliente puede usar el repositorio que estime conveniente siempre que esté basado en GIT. Fluid Attacks solo requiere ingreso a la rama de integración y a su respectivo ambiente.​

  40. ¿Se pierden los derechos patrimoniales

    si Fluid Attacks revisa el código fuente?

    No, el permitir revisar una creación u obra como lo es un código a un tercero​ ​ no le da ningún derecho sobre la misma.​

  41. ¿Fluid Attacks cuenta con alguna herramienta que permita automatizar

    las pruebas de cierre de las vulnerabilidades encontradas?

    Si, Fluid Attacks cuenta con Asserts, un motor que permite automatizar​ verificaciones de seguridad una vez éstas han sido encontradas en una fase exploratoria. Asserts opera directamente en el JOB de integración continua y tiene la capacidad de romper el build enviado por el programador en caso de incumplir requisitos de seguridad. ​

  42. ¿El Hacking Continuo está enfocado únicamente sobre el código fuente?

    ¿Es posible incluir la infraestructura asociada a la aplicación?

    *Es posible incluir la infraestructura asociada a la aplicación? Fluid Attacks ha evolucionado el modelo de Hacking Continuo y ahora se puede incluir dentro del Target of Evaluation (TOE) ​​los puertos y las entradas​ de la aplicación. De hecho, en esta evolución, se puede suscribir una infraestructura tecnológica (puertos) o una aplicación bajo el modelo de Hacking Continuo.

  43. ¿Donde se ejecuta Integrates?

    La plataforma Integrates se ejecuta en la nube​.

  44. ¿Fluid Attacks gestiona las credenciales de acceso a Integrates?

    No, usamos el concepto de autenticación federada, es decir, que tanto Google como Azure (Microsoft 360)​ ​son quienes en realidad hace la validación de tus credenciales.​

  45. ¿Es posible activar doble token de autenticación?

    Si es posible, de hecho, lo sugerimos para aumentar el nivel de seguridad de tu credenciales y así evitar accesos no autorizados a tu información por parte de un tercero. Esta característica se habilita desde Gmail o Azure según sea tu caso.​

  46. ¿Si hago un commit, ¿en cuanto tiempo Fluid Attacks lo revisa y prueba?

    El compromiso es ir con cobertura 100%, por lo que tienen resultados de vulnerabilidades todo el tiempo. Fluid Attacks tiene en cuenta los push a la rama que se este revisando, los cuales son monitoreados por scripts automatizados (robots) que se encargan todas las noches de extraer el código y analizar los cambios realizados sobre el código fuente.

  47. ¿Es decir que fluid attacks prueba cada que hago un push a la rama

    de la suscripción?

    Durante la ejecución de un proyecto se pueden presentar los siguientes escenarios:

    1. Aplicación en desarrollo sin código atrasado (cobertura 100%): Los robots detectan el cambio y generan archivos de control actualizados, esto hace que uno de los hackers tome la aplicación y ataque la aplicación considerando los cambios. Es decir, no se audita un commit o un archivo especifico, se toma el análisis de cambios del robot para que el hacker tome el ambiente y la rama, e intente atacar dados los cambios.

    2. Aplicación en producción sin código atrasado (cobertura 100%): Incluso cuando no hay cambios, la aplicación se planifica para ser hackeada. Internamente tenemos procesos que nos permiten identificar cuando a una aplicación no le hemos encontrado vulnerabilidades en 7 días, 14 y 21 días. Esto con el fin de tomar acciones como rotación de hackers o aumentar el numero de hackers asignados al proyecto para lograr nuevas vulnerabilidades.

    3. Aplicación en desarrollo con código atrasado (cobertura <100%): Igual que A pero se ataca lo relacionado con el cambio realizado, no se ataca superficie de ataque realizada antes de la suscripción.

    4. Aplicación en producción con código atrasado (cobertura <100%): Igual que B, solo que si en dicho mes no hay código nuevo, se hackea lo equivalente a lo hecho por 1 autor activo en 1 mes anterior.

  48. ¿Es posible conocer el cronograma de actividades de las pruebas en hacking

    continuo?

    Una vez realizado el setup y se tiene todo listo para realizar el servicio, comienzan las pruebas de seguridad. Las actividades realizadas dentro del servicio son: . Aprobación del pedido (Orden de compra confirmada) . Asignación de líder para el proyecto . El líder programa la reunion de inicio (teleconferencia) . Validación de las condiciones del servicio . Solicitud de insumos (acceso a ambientes y código) . El líder recibe los insumos y programa la configuración de los robots de verificación y acceso

    1. El líder crea un usuario admin para el cliente en Integrates

    2. El usuario admin invita a todos los interesados del proyecto incluyendo los desarrolladores (deben tener Google Apps u Office365)

    3. Nuestros hackers reportan las vulnerabilidades en Integrates

    4. Los interesados acceden a las vulnerabilidades y comienzan a remediar

    5. Si tienen dudas las pueden escalar por la sección de comentarios o el chat disponible en Integrates

    6. Una vez remediado el cliente solicita la verificación por Integrates

    7. Nuestro hacker realiza la verificación de cierre y actualiza el reporte

    8. Los puntos 3 - 7 se repiten hasta finalizar la suscripción

  49. Si quiero usar Asserts dentro de mi integrador continuo

    ¿Cuales son las condiciones técnicas que debo cumplir?

    Asserts se ejecuta en cualquier plataforma de integración continua que soporte Docker (Docker engine 18.03.1) y cuente con acceso a internet.

  50. ¿Existe documentación de Asserts?

    La documentación esta disponible en: Asserts

  51. ¿Es posible agrupar aplicaciones en una sola suscripción?

    ¿Como reconozco las vulnerabilidades por aplicación?

    Según el modelo de autores activos, se puede crear una célula grande con todos los desarrolladores o dividirla por aplicación según lo desee el cliente. Cuando se maneja una sola célula es importante tener en cuenta:

    • Todos los usuarios dentro del proyecto podrán ver todas las vulnerabilidades de las diferentes aplicaciones dentro de la misma célula.

    • En caso de que varias aplicaciones tengan la misma vulnerabilidad la única forma de identificarlas es revisando dentro de la vulnerabilidad el campo donde se especifica el lugar de la vulnerabilidad.

  52. ¿Es posible cambiar de ambiente cuando tengo una suscripción activa?

    Si es posible con la condición de que el ambiente a revisar debe ser el mismo ambiente de la rama en la que se revisa el código fuente, así Fluid Attacks puede probar de forma estática y dinámica una misma versión del cambio.

  53. ¿Que pasa si quiero revisar diferentes ambientes de una misma aplicación?

    El servicio incluye el ambiente del código revisado (Ver pregunta 52), es posible incluir ambientes diferentes por un valor adicional.

  54. ¿Si hago una pregunta por el sistema de comentarios, en cuanto tiempo tengo

    respuesta?

    Las consultas que se hacen via los comentarios de las vulnerabilidades, tienen un SLA de 4 horas hábiles. L-V de 8AM a 12M y de 2PM a 6PM. (UTC-5 Colombia) El SLA no esta definido contractualmente, simplemente es nuestra promesa de valor.


Estado de los servicios - Términos de Uso