Dos propuestas de pentesting pueden tener el mismo título y evaluar realidades completamente diferentes. Una puede limitarse a revisar exposición pública con herramientas automáticas; otra puede verificar permisos entre usuarios, lógica de negocio, integraciones y posibilidades de abuso con pruebas manuales controladas. Si una empresa compara ambas únicamente por precio, probablemente no está comparando el mismo servicio.
Esta guía está dirigida a organizaciones que buscan pentesting, ethical hacking o auditoría de seguridad técnica en Colombia y necesitan contratar con un alcance defendible. Explica qué probar, qué autorizar, cómo proteger la operación durante el ejercicio y qué entregables deben permitir corregir hallazgos. También aclara cuándo conviene empezar por un análisis de vulnerabilidades y cuándo hace falta comprobar escenarios de explotación bajo autorización expresa.
En Insylux, el servicio de Ethical Hacking se plantea sobre activos y objetivos acordados. Una prueba técnica no demuestra seguridad absoluta ni habilita a intervenir sistemas de terceros. El valor está en convertir hipótesis de riesgo en evidencia proporcionada, accionable y comprensible para quienes deben aprobar cambios.
Fraude digital en Colombia: una señal para revisar recorridos completos
En su publicación del 28 de mayo de 2026, TransUnion informó que el 2,3 % de las transacciones digitales intentadas con origen en Colombia durante 2025 fueron señaladas como sospechosas de fraude en su red de análisis. El desglose por etapas mostró 7,2 % en creación de cuentas, 3,5 % en inicio de sesión y 0,3 % en transacciones financieras. Fuente: TransUnion, análisis de fraude digital 2025.
| Etapa | Tasa publicada | Pregunta de verificación sugerida por Insylux |
|---|---|---|
| Creación de cuentas | 7,2 % | ¿Qué limita altas abusivas y manipulación del registro? |
| Inicio de sesión | 3,5 % | ¿Cómo se controlan autenticación y recuperación de acceso? |
| Transacciones financieras | 0,3 % | ¿La autorización valida usuario, operación y contexto? |
Estas tasas no son porcentajes de aplicaciones vulnerables ni un censo de empresas colombianas atacadas. Describen actividad observada en una red comercial y clasificada como sospechosa. Las preguntas de la tabla son recomendaciones editoriales, no conclusiones del proveedor sobre una aplicación concreta. Su utilidad es recordar que revisar únicamente el pago puede dejar fuera el registro, la recuperación de cuenta o los privilegios que permiten llegar a él.
Pentesting y análisis de vulnerabilidades: qué cambia
Un análisis de vulnerabilidades ayuda a identificar y priorizar debilidades en un conjunto de activos. Combina descubrimiento, herramientas de evaluación y validación de resultados según el alcance. Es especialmente útil para conocer exposición, versiones, configuraciones y acumulación de correcciones pendientes. No implica necesariamente intentar explotar cada debilidad.
El pentesting añade la comprobación controlada de caminos de ataque autorizados y su impacto. Puede demostrar que un rol accede a una función que no le corresponde, que una integración confía indebidamente en datos externos o que varios controles débiles permiten un resultado más serio que cada hallazgo aislado.
No existe una competición entre ambos servicios. La revisión de vulnerabilidades permite mantener visibilidad y priorización; una prueba de penetración profundiza en escenarios relevantes. La secuencia depende de madurez, cambios, exposición y obligaciones contractuales. Si ni siquiera existe un inventario razonable, empezar por delimitar activos puede aprovechar mejor la inversión posterior en pruebas manuales.
Empezar por objetivos de negocio, no por una lista de direcciones IP
El alcance técnico debe responder una pregunta empresarial. “Comprobar que un cliente no puede consultar pedidos de otro” define un objetivo más útil que “revisar el portal”. Lo mismo ocurre con la modificación de cuentas bancarias de proveedores, la aprobación de reembolsos o el acceso de un contratista a recursos internos.
Describa funciones, datos y consecuencias que desea evaluar. Después identifique interfaces web, API, aplicaciones móviles, identidades, infraestructura y conexiones que intervienen. Un dominio puede contener varios negocios y roles; cientos de direcciones IP pueden alojar una operación sencilla. El número de activos por sí solo no mide la complejidad de la prueba.
Defina además el resultado que quedará fuera. Una revisión de aplicación no incluye automáticamente ingeniería social, dispositivos de empleados, denegación de servicio o plataformas de un proveedor de nube. Establecer exclusiones no reduce la calidad: evita ambigüedades y permite que la autorización coincida con el trabajo realmente realizado.
Caja negra, gris o blanca: elegir según la pregunta
En una prueba de caja negra se parte de información limitada, aproximando una perspectiva externa acordada. En caja gris se facilitan ciertos conocimientos o credenciales de prueba. En caja blanca puede existir acceso amplio a documentación, arquitectura o código. Ninguna modalidad es superior para cualquier objetivo: cambia la cobertura alcanzable con el tiempo disponible.
Si interesa comprobar separación entre clientes o permisos de varios perfiles, proporcionar cuentas controladas puede ser más eficiente que dedicar gran parte del ejercicio a conseguir un acceso inicial. Si interesa examinar exposición desconocida, una perspectiva externa tendrá otro valor. La decisión debe figurar en la propuesta y relacionarse con entregables concretos.
Una combinación también es posible. Por ejemplo, revisar superficie externa y después profundizar en una API con documentación y usuarios de prueba. Esto debe presupuestarse de forma explícita para que el equipo técnico, compras y gerencia entiendan qué se verificará y qué limitaciones seguirán existiendo.
Qué debe incluir una revisión de aplicaciones y API
El proyecto OWASP API Security destaca familias de riesgo como autorización incorrecta sobre objetos y funciones, autenticación deficiente, consumo de recursos e inventario incompleto. Son referencias para organizar verificaciones, no una lista que sustituya el conocimiento del negocio. Una aplicación puede cumplir una comprobación básica y conservar un flujo comercial abusivo.
La matriz de prueba debería cruzar roles y operaciones: consultar, crear, modificar, aprobar, exportar o eliminar. También conviene diferenciar usuarios de organizaciones distintas y objetos que pertenecen a cada una. El objetivo es comprobar que el servidor aplica las decisiones de autorización, sin confiar en que una opción esté oculta en la interfaz.
Los flujos sensibles requieren contexto adicional. Cambiar el destinatario de un pago, reutilizar una aprobación o repetir una operación puede tener consecuencias distintas según el proceso. Las pruebas deben diseñarse con datos controlados y límites seguros, evitando transferencias reales o cambios irreversibles que no se hayan autorizado.
OWASP ASVS aporta requisitos de verificación que pueden incorporarse a compras y desarrollo. Cuando se use como referencia contractual, indique versión y cobertura: mencionar el nombre sin precisar controles evaluados no demuestra que se haya revisado una aplicación de forma completa.
Autorización y reglas de ejecución: una condición imprescindible
La autorización debe proceder de quien tenga capacidad para permitir la evaluación de los activos. Ser cliente de una plataforma no significa tener derecho a probar su infraestructura. Antes de comenzar, identifique propietarios, condiciones del proveedor y posibles restricciones sobre servicios compartidos. Cualquier duda sobre autoridad debe resolverse antes de la ejecución.
Las reglas de actuación deben recoger objetivos, activos, ventanas, técnicas permitidas, exclusiones, contactos y criterios de parada. Una degradación inesperada, el acceso a información real sensible o la aparición de un tercero fuera del alcance requieren una decisión coordinada. La presión por completar una prueba no justifica ampliar sus permisos informalmente.
También debe acordarse cómo manejar evidencias: cifrado, acceso restringido, retención y eliminación al finalizar el período contratado. Es preferible demostrar el impacto con la mínima información necesaria. Un informe no necesita contener una base de datos completa para justificar que un control de acceso falló.
Los entregables que hacen útil una prueba de penetración
| Entregable | Contenido mínimo útil | Señal de debilidad |
|---|---|---|
| Resumen ejecutivo | Riesgos, impacto y decisiones prioritarias. | Solo gráficos sin explicación del negocio. |
| Informe técnico | Activo, condición, evidencia controlada, impacto y recomendación. | Salida automática sin validación. |
| Cobertura | Roles, superficies, escenarios evaluados y limitaciones. | Afirmación genérica de revisión completa. |
| Plan de corrección | Acciones sugeridas, dependencias y criterio de cierre. | “Actualizar” sin explicar qué resolver. |
| Reprueba | Resultado posterior y riesgo residual observado. | Cierre basado únicamente en una declaración. |
El informe técnico debe permitir al equipo autorizado comprender y reproducir el hallazgo de manera segura. Las evidencias pueden redactarse para no revelar secretos o información personal. Un apéndice restringido puede ser adecuado cuando el detalle de explotación no debe circular con el resumen de gerencia.
La clasificación de severidad también necesita contexto. Una puntuación técnica ayuda a comparar, pero no sustituye el valor del proceso afectado, la exposición o los controles existentes. El proveedor debería explicar por qué una debilidad requiere atención prioritaria y qué condiciones modificarían esa valoración.
De un hallazgo a una corrección verificable
Al recibir el informe, asigne propietario, fecha y dependencia de cada acción. Un equipo puede corregir código; otro debe cambiar privilegios; un tercero necesita acordar una modificación con el proveedor. Si cada área conserva una copia diferente del listado, resulta difícil saber qué está realmente cerrado y qué permanece pendiente.
El cierre debe comprobar la causa, no solo ocultar el síntoma. Si una API permitía operar sobre recursos ajenos, conviene revisar otros endpoints con el mismo patrón de autorización. Corregir una pantalla y dejar intacta la regla compartida puede hacer reaparecer el problema en otra función.
La reprueba verifica el comportamiento corregido dentro del alcance pactado. No equivale automáticamente a repetir la evaluación completa ni a buscar cada posible efecto colateral. Insylux contempla retest en su servicio publicado de Ethical Hacking; las condiciones, activos y ventana aplicables deben precisarse en la propuesta particular.
Qué influye en el precio de un pentesting en Colombia
No hay una tarifa universal defendible para una aplicación que todavía no se ha delimitado. El esfuerzo depende de interfaces, roles, integraciones, lógica de negocio, conocimiento disponible, restricciones operativas y profundidad solicitada. La urgencia, las ventanas especiales o los requisitos de reporte también pueden influir.
Para comparar cotizaciones, entregue una ficha equivalente a cada proveedor. Incluya objetivo, dominios o redes aproximadas, funciones sensibles, cantidad de roles, ambientes disponibles, tecnologías relevantes y necesidad de reprueba. No envíe credenciales en esa ficha. Esos accesos deben gestionarse después de acordar autorización y canales de intercambio.
Pregunte qué porcentaje del trabajo corresponde a análisis manual, cómo se validan falsos positivos y cómo se comunica un hallazgo urgente. No es necesario exigir una proporción idéntica para cada proyecto, pero sí entender qué actividad está comprando. Un precio bajo no demuestra mala calidad; una descripción ambigua impide evaluarla.
Cómo preparar a desarrollo, infraestructura y negocio
Antes del inicio, confirme que las cuentas de prueba funcionan, que existen datos controlados y que el equipo conoce los contactos de contingencia. Si se usa un ambiente previo a producción, documente diferencias relevantes: autenticación, configuraciones, integraciones y controles perimetrales. Un entorno demasiado distinto puede limitar las conclusiones.
Durante la evaluación, gestione cambios de versión. Desplegar nuevas funciones sin coordinación puede invalidar una evidencia o introducir comportamientos que no estaban incluidos. Una ventana de estabilidad ayuda, aunque no siempre sea posible congelar cambios. Lo importante es conservar trazabilidad y acordar cómo tratar lo que se modifique.
Después, reserve capacidad de corrección. Contratar la prueba sin disponibilidad de desarrollo o infraestructura suele convertir hallazgos conocidos en pendientes crónicos. La inversión tiene más sentido cuando incluye una decisión sobre quién corregirá, cómo se priorizará y en qué condiciones se comprobará el resultado.
Identidades y nube: delimitar la responsabilidad compartida
Cuando una aplicación utiliza nube, la evaluación debe distinguir lo que configura la empresa de lo que administra el proveedor. Revisar permisos de una cuenta, almacenamiento o secretos de despliegue no equivale a probar el servicio subyacente del fabricante. La propuesta debe identificar esa frontera y respetar las políticas del proveedor.
Las identidades técnicas merecen atención propia. Una integración puede mantener permisos más amplios que los necesarios, conservar credenciales después de un cambio o compartir un secreto entre ambientes. La revisión debe comprobar responsabilidades, acceso y uso previsto con evidencias controladas, sin publicar valores sensibles en informes de circulación amplia.
También conviene evaluar cómo se concede y retira el acceso temporal del equipo de pruebas. Al cerrar el ejercicio deben desactivarse cuentas y permisos creados para él, y documentarse la entrega o eliminación acordada de evidencias. La evaluación no debería dejar una exposición nueva por una cuenta olvidada.
Indicadores que reflejan mejora técnica
El número total de vulnerabilidades no describe por sí solo la calidad de una aplicación ni la del proveedor. Depende de alcance, tiempo, cambios y agrupación de hallazgos. Un resultado con pocas debilidades puede ser positivo o indicar cobertura insuficiente; el informe debe permitir distinguir ambas situaciones.
Resulta más útil seguir cobertura de funciones críticas, hallazgos prioritarios corregidos, causas repetidas y tiempo de tratamiento por severidad y contexto. El denominador debe permanecer claro: corregir nueve de diez hallazgos no explica la exposición si el único pendiente permite modificar información sensible.
Cuando la organización necesita coordinar el programa de pruebas con presupuesto y riesgos, un CISO externo puede ayudar a ordenar el ciclo. La dirección de seguridad no reemplaza el trabajo del equipo que desarrolla o administra los sistemas; aporta prioridades y seguimiento transversal.
Preguntas frecuentes sobre contratación de pentesting
¿Un escaneo automático sirve como pentesting?
Puede formar parte de una evaluación, pero no demuestra por sí mismo la revisión manual de autorización, lógica de negocio o cadenas de ataque. Antes de aceptar la propuesta, pida actividades, alcance y entregables. El nombre comercial es menos importante que la evidencia de lo que realmente se verificará.
¿La prueba puede afectar la operación?
Existe riesgo operativo, por lo que deben acordarse límites, técnicas, ventanas y criterios de parada. Una evaluación controlada busca reducir ese riesgo, no prometer que será imposible cualquier impacto. Las pruebas destructivas o de denegación de servicio requieren un acuerdo específico y no deben presumirse incluidas.
¿Cada cuánto hay que repetirla?
La frecuencia depende del riesgo, los cambios y las obligaciones aplicables. Un lanzamiento importante, una modificación de autenticación o una integración sensible pueden justificar una revisión fuera del calendario habitual. La repetición periódica aporta valor si se combina con correcciones y verificación de causas recurrentes.
¿Una prueba sin hallazgos garantiza que no habrá ataques?
No. Las conclusiones están limitadas por tiempo, alcance, información y condiciones observadas. El software cambia y aparecen nuevas técnicas o configuraciones. Un informe responsable describe esas limitaciones y evita transformar una evaluación puntual en una garantía de seguridad futura.
¿Puedo evaluar una plataforma contratada a un tercero?
Solo cuando existan permisos suficientes y se respeten sus condiciones. Tener una cuenta de cliente no concede autorización sobre la plataforma completa. Identifique quién es propietario de cada componente y gestione la aprobación antes de cualquier prueba que pueda alcanzarlo.
¿Qué diferencia una buena propuesta de una lista de herramientas?
La buena propuesta conecta objetivos, escenarios, cobertura y decisiones de corrección. Identifica responsables, restricciones y tratamiento de evidencias. Las herramientas pueden ser necesarias, pero su listado no explica si se revisarán las funciones que sostienen los ingresos o los datos más sensibles del negocio.
Solicitar una evaluación con alcance claro
Si necesita proteger un portal, una API o infraestructura empresarial, solicite una cotización de pentesting a Insylux con revisión de alcance. Indique qué operación quiere verificar, sus roles y las restricciones de ejecución. Nuestro punto de partida comercial debe ser una necesidad delimitada, no una promesa genérica de encontrar cualquier vulnerabilidad.
Insylux cuenta con presencia en Medellín para acompañar a empresas en Colombia según el alcance acordado. Para reforzar la comprensión de riesgos y controles entre equipos, Insylux Academy puede complementar el programa de seguridad con formación. Aprender ayuda a prevenir repeticiones; no sustituye una prueba autorizada ni una corrección técnica comprobada.
Fuentes y alcance de esta guía
- TransUnion Colombia, publicación del 28 de mayo de 2026 sobre datos de 2025.
- OWASP API Security Project.
- OWASP Application Security Verification Standard.
Fuentes revisadas el 9 de septiembre de 2026. Las preguntas de compra, ejemplos y recomendaciones son análisis editorial de Equipo Insylux. No constituyen autorización para probar activos ni describen incidentes de clientes reales.
