®Seguridad ofensiva / Pentesting de software y SaaS
Los lanzamientos rápidos necesitan una verificación de seguridad que entienda su aplicación. OTOKO® analiza productos SaaS, API, aplicaciones que funcionan sobre PaaS y software legacy desarrollado con el paso del tiempo. Nos centramos en el impacto alcanzable: datos de otros inquilinos, acciones no permitidas, lógica de negocio utilizada de forma indebida y los límites entre roles de usuario. Los hallazgos reproducibles proporcionan a su equipo de desarrollo una base para la corrección.
Servicios en detalle
Análisis, integración y traspaso documentado
Su encargo a OTOKO®
Los paquetes de trabajo se derivan de su situación de partida. Su equipo conoce el alcance acordado, la colaboración necesaria y los resultados que deben estar disponibles en el traspaso.
Definimos juntos los procesos de negocio importantes y los roles de prueba. A continuación, examinamos si una función puede utilizarse más allá de los límites previstos. Las verificaciones automatizadas se complementan con un análisis manual de la aplicación.
Hallazgos evaluados con impacto en el negocio y evidencia verificable.
La asignación de inquilinos, los accesos a objetos y las funciones privilegiadas se verifican dentro del alcance autorizado. Un conjunto de pruebas propio permite evaluar los efectos sin tener que utilizar datos de otros clientes como evidencia.
Verificación documentada de los límites acordados entre roles e inquilinos.
En las aplicaciones PaaS analizamos las configuraciones e interfaces que están bajo su responsabilidad. En los sistemas legacy, los límites operativos conocidos y las dependencias se incorporan a la planificación de las pruebas. Las plataformas de terceros quedan fuera del alcance mientras no exista una autorización.
Alcance de prueba delimitado con procedimientos adecuados desde el punto de vista técnico y operativo.
Los hallazgos se priorizan y se comentan con su equipo de desarrollo. El retest acordado comprueba si la causa concreta se ha corregido en la nueva versión. Los resultados se refieren al alcance y al momento realmente verificados.
Informe técnico, valoración para la dirección y resultados documentados del retest.
Planificación e implementación
Un producto SaaS no consiste solo en endpoints accesibles públicamente. Distintos roles, invitaciones, exportaciones, tareas en segundo plano y funciones de administración conforman en conjunto la lógica de negocio. Por eso, antes de la prueba aclaramos qué procesos necesitan una protección especial y qué límites debe hacer cumplir la aplicación. Esta perspectiva complementa las verificaciones técnicas clásicas. Una función puede responder de forma formalmente correcta y, aun así, permitir una acción que no está prevista para la persona que ha iniciado sesión o su inquilino.
Sobre esta base se define un alcance de prueba coordinado. La combinación de pruebas black box, grey box o white box se elige según el objetivo y la información disponible. Si se facilitan el código fuente o la documentación de arquitectura, las observaciones pueden clasificarse de forma más precisa. La verificación se centra en la aplicación autorizada y utiliza las cuentas y los datos acordados. Un hallazgo de una herramienta no se considera una vulnerabilidad confirmada sin una evaluación previa; el impacto y los requisitos previos deben ser comprensibles para su equipo.
En SaaS y PaaS, el límite de responsabilidad resulta decisivo. La verificación de su aplicación o configuración no constituye automáticamente un permiso para atacar la infraestructura de un operador de plataforma. Se fijan conjuntamente los objetivos, los procedimientos permitidos y las autorizaciones necesarias. Las API y las integraciones se verifican en función del alcance previsto de datos y permisos. Se presta especial atención a si los distintos roles e inquilinos permanecen separados de forma fiable en las rutas reales de la aplicación.
El software legacy suele exigir un enfoque distinto. La documentación puede tener lagunas, los entornos de prueba solo reflejan parcialmente el entorno productivo y algunos componentes son sensibles a la carga. Estas condiciones deben incorporarse a la planificación antes de empezar. Acordamos las ventanas de prueba, las personas de contacto disponibles y los criterios de interrupción. Cuando una verificación no pueda realizarse de forma responsable, ese límite se hace visible en el resultado. De este modo queda claro qué conclusiones permite extraer la prueba y dónde sería necesario un análisis adicional.
Un informe debe permitir tomar una decisión y ayudar al equipo de desarrollo en la corrección. Por eso, un hallazgo confirmado describe la versión afectada, los requisitos previos necesarios, la evidencia acordada y el posible impacto. La dirección y el equipo técnico necesitan distintos niveles de detalle. La priorización tiene en cuenta el contexto de la aplicación, en lugar de generar solo una lista larga de avisos con el mismo peso. Las evidencias se limitan a lo necesario y se comparten con las personas de contacto autorizadas a través de vías acordadas.
La corrección se comenta con su equipo; un retest acordado evalúa el cambio concreto. Sin embargo, un hallazgo corregido no significa automáticamente que toda la aplicación esté libre de vulnerabilidades. Los nuevos lanzamientos y los cambios de configuración pueden modificar la situación de partida. Si se desea, esto puede convertirse en una verificación periódica de los cambios importantes. Para objetivos adecuados y claramente delimitados también puede acordarse Result as a Service: en ese caso, la remuneración depende del resultado definido y demostrado previamente.
Escenario de proyecto ilustrativo
Dos inquilinos de prueba independientes representan a los usuarios habituales y a la administración. Antes del lanzamiento se examinan los procesos de negocio acordados y los límites de permisos. El equipo recibe evidencias priorizadas y comprueba las correcciones en el retest, sin necesitar datos de otros clientes para la demostración.
Antes de empezar
Sí. Las aplicaciones legacy se planifican teniendo en cuenta sus límites operativos, los entornos de prueba disponibles y las dependencias. Las verificaciones que no puedan realizarse se indican en el informe como limitación.
Los escáneres son un apoyo para el trabajo. Sin embargo, la lógica de negocio, los roles y el contexto real de la aplicación requieren una evaluación experta y una verificación manual específica.
Para proyectos adecuados puede acordarse una evidencia de resultado definida por escrito junto con un importe fijo. Sin esta evidencia no se genera la remuneración de pentest acordada en función del éxito. Encontrará más detalles en la página Result as a Service.
No. La conclusión se refiere al alcance acordado, la versión verificada y la ventana de tiempo. La ausencia de evidencias no constituye una garantía general de seguridad.
Servicios relacionados
Pentesting de software y SaaS con OTOKO®
Indique los sistemas afectados y el objetivo de su consulta. En la primera reunión, delimitamos juntos el alcance, los requisitos previos y los próximos pasos.
Hablar sobre Pentesting de software y SaaS
