RTSS —Red Team Security Scanner— es el servicio con el que Red Sigma revisa la seguridad de una aplicacion web. Trabaja sobre un sistema que el cliente autoriza por escrito, busca por donde podria entrar un atacante, intenta comprobar si cada sospecha es real y entrega el resultado con su evidencia, su gravedad y el orden en que conviene corregir.
La diferencia con una herramienta de escaneo convencional esta en el verbo: un escaner avisa; este servicio comprueba. Una alerta sin comprobar deja el trabajo de decidir al cliente, que es justo la parte cara.
El servicio trabaja en dos profundidades distintas, y conviene no confundirlas porque responden a preguntas diferentes:
Observacion de la superficie expuesta, sin tocar el sistema por dentro. Sirve para saber si hay señales que merezcan una revision a fondo. No abre expediente y no necesita autorizacion de alcance.
El trabajo completo sobre una aplicacion web, con su alcance declarado por escrito y su expediente propio. Es lo que describe el resto de este manual.
Decirlo por adelantado vale mas que decirlo cuando alguien ya esperaba otra cosa:
El resultado no es una lista de alertas. Es un expediente cerrado, con fecha, que responde a tres preguntas en este orden: que se encontró, como se comprueba y que conviene corregir primero.
Cada hallazgo viaja con un comprobante que el equipo del cliente puede ejecutar por su cuenta. Devuelve una de dos respuestas: sigue estando o corregido.
Eso convierte la correccion en algo que se comprueba y no en algo que se declara. El equipo parchea, ejecuta el comprobante y sabe el resultado sin volver a contratar nada. Y cuando ese comprobante se guarda junto a las pruebas del proyecto, el defecto no puede volver sin que alguien se entere.
| Version | Que lleva | Para quien |
|---|---|---|
| Ejecutivo | El veredicto, el reparto por gravedad y las prioridades. El detalle de los hallazgos mas graves queda reservado. | Direccion, comite, cliente final |
| Completo | Todo el detalle tecnico, la evidencia y el analisis de riesgo. | El equipo que va a corregir |
Solo se emite con el trabajo terminado, y solo si hubo hallazgos. Un informe emitido sobre un trabajo a medias sale a medias y parece entero: lleva portada, veredicto y porcentaje calculados sobre lo que hubiera a esa hora. Y sin hallazgos no se produce un documento con la portada puesta y el cuerpo vacio: se dice que no hay.
Despues de un parcheo, la pregunta del cliente no es «que hay» sino «lo que me dijiste, sigue?». La revalidacion responde exactamente a eso: repasa los hallazgos de un trabajo anterior, uno por uno, con sus pasos originales, sin buscar nada nuevo. Cada hallazgo recibe uno de cuatro veredictos:
| Veredicto | Que significa | Obliga a declarar |
|---|---|---|
| Sigue vivo | Se reprodujo. El hallazgo esta ahi. | — |
| Remediado | No se pudo reproducir y el sistema responde de otra forma. | — |
| Mitigado parcial | Se reprodujo, pero con menos alcance o menos impacto. | La gravedad nueva |
| No comprobable | No se pudo decidir. | El motivo |
Un hallazgo puede no reproducirse por tres razones distintas: porque se arregló, porque la cuenta de prueba perdió el permiso que hacia falta, o porque no se llegó a intentar. Deducir «remediado» del silencio convierte las otras dos en un parche que nadie hizo. Y una bajada de gravedad sin decir a cuanto no es un resultado: por eso el veredicto parcial obliga a declarar la nueva.
Una prueba de intrusion es trafico real contra un sistema real. Por eso el servicio no arranca con un boton: arranca con tres permisos en serie, y los tres tienen que ceder.
Antes del primer trabajo sobre una aplicacion, el cliente declara por escrito que sistemas entran y cuales no. Ese documento es la frontera: lo que no esta declarado no se toca, y no hay forma de ampliarlo a mitad de un trabajo.
Es una limitacion buscada. Un alcance que se puede estirar durante la ejecucion es un alcance que no protege a nadie: ni al cliente, que no sabe que recibira trafico, ni al proveedor, que no puede demostrar donde estaba el limite.
El tercer permiso lo da una persona, no el sistema. Llega por correo, se contesta por correo, y queda archivado en el expediente del trabajo junto con la fecha y el alcance que se autorizó.
Si el mismo sitio que lanza el trabajo fuera el que lo aprueba, quien entrara a la consola podria autorizarse a si mismo. Separar los canales es lo que hace que la autorizacion sea una decision y no un paso del formulario.
Los tres permisos deciden si se puede y sobre que. Cuanto trabajo cabe y cuanto cuesta es un control distinto, y es el asunto de la seccion 08.
Cada cliente tiene su espacio, y dentro de el, cada aplicacion tiene el suyo. Los hallazgos, la evidencia, el alcance autorizado y las credenciales de prueba de un trabajo no existen fuera del expediente al que pertenecen.
Porque es la pregunta que cualquier responsable sensato hace antes de entregar el alcance de sus sistemas a un proveedor: «lo que encuentren en mi aplicacion, quien mas lo va a ver?».
La respuesta es que el aislamiento se verifica al cerrar cada trabajo, no se asume. Un expediente que contiene algo que no le pertenece sale señalado. Es una comprobacion incomoda —puede marcar trabajos propios— y por eso vale: una garantia que nunca falla no esta midiendo nada.
Cuando el trabajo necesita entrar al sistema con una cuenta, esa cuenta la facilita el cliente, se usa dentro del trabajo y vive en el expediente de ese trabajo. No se reutiliza en otra aplicacion ni en otro cliente.
Entregue siempre cuentas creadas para la prueba, con el privilegio que quiera que se audite y nada mas, y deshabilitelas al cerrar el trabajo. Una cuenta de prueba que sobrevive al trabajo es una puerta que nadie vuelve a mirar.
Todo trabajo recorre los mismos cinco momentos, en este orden y sin saltarse ninguno.
| Momento | Que ocurre | Quien decide |
|---|---|---|
| 1 · Solicitud | Se declara que aplicacion se audita y con que accesos. Queda registrada. | El cliente |
| 2 · Autorizacion | La persona responsable recibe la solicitud con su alcance y contesta. Sin ese si, no hay trabajo. | Una persona |
| 3 · Ejecucion | El trabajo se realiza sobre los sistemas declarados, y solo sobre ellos. | — |
| 4 · Seguimiento | El estado del trabajo y los hallazgos que ya se escribieron se pueden consultar mientras avanza. | El cliente consulta |
| 5 · Cierre | El resultado se sella con el estado real, se calcula el veredicto y se verifica el aislamiento. | — |
Los hallazgos aparecen a medida que se comprueban, asi que el cliente no espera a ciegas. Conviene saber leer esa lista a medias: una lista que todavia crece no es un resultado, y el veredicto de riesgo no se calcula hasta el cierre precisamente para que nadie tome una decision con una foto incompleta que parecia completa.
Un trabajo se puede detener. Lo que ya se hizo, hecho esta: el expediente conserva lo comprobado hasta ese momento y se sella con el estado real en que quedó. Detener evita el trabajo que faltaba; no retira el que ya ocurrió.
Cada hallazgo entra en uno de cinco grados. No pesan igual, y la distancia entre ellos es deliberadamente grande:
Asi se ven en el informe:
Critica Alta Media Baja Informativo
El informe cierra con un numero de 0 a 99 y un sello de color. No es una nota del sistema: es una estimacion de la probabilidad de que alguien logre entrar con lo que quedó expuesto.
Un trabajo sin hallazgos escritos no puntua, y su estado no es un cero. En una escala de riesgo el cero es la mejor nota que existe, y ahi significaria exactamente lo contrario de lo que pasó: que nadie llegó a mirar. Por eso ese caso se declara aparte, como «sin medir».
Cuanto del sistema se alcanzó a revisar es un dato distinto del veredicto, y viaja por separado. Si una parte del trabajo no pudo ejecutarse, salen menos hallazgos y el sistema parecera mas seguro justo cuando se le vio menos. Mezclar las dos cifras oculta ese efecto; separarlas lo hace visible.
Que un hallazgo sea inferido y no reproducido no lo degrada: lo que lo degradaria es presentarlo como probado. El informe lo marca como no confirmado y el veredicto lo cuenta igual. Quien decide si vale la pena investigarlo es el cliente, con el dato delante.
El veredicto corresponde al ultimo trabajo que escribió hallazgos, no a la suma historica de todos. Sumarlos mezclaria dos fotografias del mismo sistema: un defecto que un trabajo posterior confirma corregido seguiria contando, y el veredicto no podria mejorar nunca.
Los niveles no se diferencian en «cuanta seguridad» entregan —eso no se puede prometer— sino en cuanta superficie se revisa y hasta donde se profundiza.
| Nivel | Trabajos incluidos | Profundidad | Cobertura |
|---|---|---|---|
| Esencial | 2 al mes | Una linea de trabajo, sin delegacion | hasta 40 |
| Profesional | hasta 5 al mes | Una linea de trabajo y 1 a 2 delegadas | hasta 120 |
| Ofensivo | sin tope mensual | Hasta 2 lineas y 20 delegaciones a lo largo del trabajo | hasta 280 |
Cobertura es el numero de especialidades de revision que pueden entrar en un trabajo: cuantos tipos distintos de debilidad se buscan activamente. Profundidad es cuanto trabajo paralelo puede desplegarse para perseguir una pista hasta el final.
Detras de ese numero hay un catalogo de 107 especialidades de revision, agrupadas en 19 familias. El nivel contratado fija cuantas pueden entrar en un trabajo; y las que quedan fuera se dejan escritas antes de empezar, con una linea de lo que habrian aportado. Es lo que permite responder con honestidad a «que mas se podria haber revisado?».
| Familia de revision | Especialidades |
|---|---|
| Inyeccion y entrada no confiable | 14 |
| Revision estatica de codigo | 12 |
| Nube, contenedores e infraestructura como codigo | 11 |
| Directorio corporativo e identidad en la nube | 10 |
| Binario, desarrollo de exploits y fuzzing | 9 |
| Reconocimiento y superficie expuesta | 8 |
| Acceso inicial y post-explotacion | 7 |
| Autenticacion, sesion e identidad | 6 |
| Evasion de defensas y validacion | 5 |
| Inteligencia artificial, modelos y agentes | 4 |
| Entregables e informe | 4 |
| Autorizacion y logica de negocio | 3 |
| API y GraphQL | 3 |
| Movil | 3 |
| Cumplimiento normativo y dominio fiscal | 3 |
| Defensa, deteccion y forense | 2 |
| Metodologia y gobierno del trabajo | 1 |
| Herramienta de apoyo | 1 |
| Otras | 1 |
Total: 107 especialidades · 19 familias
Revalidar los hallazgos de un trabajo anterior cuenta como un trabajo: se ejecuta, se autoriza igual y deja su propio expediente. Es mas estrecha que una auditoria completa —no busca nada nuevo— pero no es gratis, y conviene planificarla dentro de lo contratado.
No se cobra por hallazgo, ni por hora, ni por tamaño del sistema. La unidad es el trabajo: una auditoria sobre una aplicacion, o una revalidacion de un trabajo anterior. Cada nivel incluye un numero de trabajos al mes y se pueden adquirir trabajos adicionales aparte.
El precio de cada nivel y de los trabajos adicionales se fija en el contrato de servicio. Este manual no publica tarifas: las cifras de esta seccion son costo de operacion medido, que es otra cosa, y confundir las dos llevaria a cotizar mal. Para precios, el contrato comercial vigente.
Un trabajo puede cortarse por un limite del proveedor del modelo. Cuando ocurre, el expediente conserva lo que se alcanzó a comprobar y se sella con el estado real en el que quedó: no se presenta como terminado.
El consumo, en cambio, ya ocurrió. Como se refleja en la factura un trabajo que avanzó y no concluyó se fija en el contrato de servicio, y hoy no esta publicado en este manual. Un trabajo que no llegó a ejecutarse no se descuenta de lo contratado.
En orden de peso observado:
Lo que no mueve el costo de forma apreciable: el numero de hallazgos. Un trabajo con muchos hallazgos y otro con pocos pueden costar lo mismo, porque el esfuerzo esta en buscar, no en redactar.
Un servicio de seguridad que no declara sus limites obliga al cliente a descubrirlos por su cuenta, y normalmente en el peor momento. Estos son los de RTSS.
El servicio se apoya en un proveedor de modelos de inteligencia artificial que impone limites de uso por ventana de tiempo. Un trabajo largo puede cortarse por ese motivo. Cuando pasa, se dice: el expediente se sella con el estado real y no se presenta como completo. Lo que no se hace nunca es reanudar un trabajo dias despues por cuenta propia: la autorizacion del cliente tenia una ventana, y mandar trafico a un sistema que ya no lo espera seria operar sin permiso.
RTSS esta en fase de validacion. Los resultados obtenidos hasta ahora provienen de pruebas controladas sobre sistemas propios y entornos de prueba, y se comunican como datos preliminares: la muestra sigue ampliandose y la plataforma se sigue validando en mas tipos de sistema. Ningun porcentaje interno de esa etapa se presenta como garantia de resultado para un cliente nuevo, porque no lo es.
Si algo del entregable no cuadra, lo que permite resolverlo rapido es: la fecha del trabajo, la aplicacion, el hallazgo concreto y —si lo hubo— el resultado de ejecutar su prueba reproducible. Con esas cuatro cosas se puede verificar cualquier afirmacion del informe.
RED SIGMA · Manual de RTSS · octubre de 2026
Las nueve secciones anteriores describen el servicio. Esta parte describe el uso de la consola: paso a paso, desde el primer acceso hasta descargar el informe. Si usted evalua el servicio, no necesita leerla; si va a operar, es la unica que importa.
Arriba, una banda con el nombre de la aplicacion elegida, los trabajos que le quedan del mes y un semáforo de estado del servicio. A la izquierda, sus dos herramientas y la lista de sus aplicaciones. En el centro, las pestañas del trabajo.
La banda muestra el nombre de la aplicacion elegida y un numero de trabajos disponibles. El semáforo no esta en rojo.
| Lo que ve | Que hacer |
|---|---|
| La banda dice que no hay aplicacion elegida | Elija una en la barra izquierda. Sin aplicacion elegida, las pestañas del trabajo no pueden hacer nada. |
| No tiene ninguna aplicacion en la lista | Dé de alta la primera: es el paso U2. |
| El contador de trabajos esta en rojo | No le quedan trabajos este mes. Ver el esquema de costos. |
Del nombre que escriba se deriva el identificador corto de la aplicacion, que es lo que la nombra en todas las pantallas, en el acta y en el informe. Es unico y definitivo: conviene acertar a la primera.
La aplicacion aparece en la barra de la izquierda y se puede elegir. Nace sin alcance declarado y sin trabajos: es una ficha vacia esperando el paso siguiente.
El alcance es la frontera del trabajo y no se puede ampliar a mitad de una corrida. Declararlo entero antes de empezar no es burocracia: es lo que permite demostrar despues donde estaba el limite.
La pestaña muestra la lista guardada. Desde este momento la aplicacion puede recibir solicitudes de trabajo.
Al pulsar Lanzar se crea la solicitud y se manda el correo de conformidad. Nada se toca todavia. El trabajo arranca cuando la autorizacion vuelve contestada, y ni un segundo antes.
Token, contraseña y secreto del autenticador no se guardan en el expediente, ni en el informe, ni en el registro del trabajo. Se usan durante la corrida y se olvidan. En el expediente solo queda constancia de que se trabajó con credenciales, nunca de cuales.
La pantalla dice que la solicitud quedó registrada y que espera la conformidad. El trabajo aparece como pendiente de autorizacion.
| Lo que ve | Que hacer |
|---|---|
| El objetivo no esta autorizado | Vuelva a U3: el mensaje dice que linea falta. |
| Dice que el modo y lo entregado no coinciden | Eligió un modo con credenciales y falta alguno de los campos, o al contrario. Complete o cambie el modo. |
| No le quedan trabajos | El freno actua antes de crear nada, asi que no deja un expediente a medias. Adquiera trabajos adicionales o espere al mes siguiente. |
| Ya hay un trabajo vivo en esta aplicacion | Solo corre uno por aplicacion. Cierre o detenga el anterior; dos aplicaciones distintas si pueden trabajar a la vez. |
Pasado ese plazo hay que volver a solicitar desde U4. No es un capricho: una autorizacion pedida hace horas ya no dice nada sobre lo que usted querria ahora, y una prueba de intrusion que arranca con un permiso viejo es una prueba sin permiso.
Vuelva a la consola y déjela abierta en la pestaña En curso. El trabajo arranca al comprobarse su estado desde la pantalla.
El trabajo no arranca solo en segundo plano. Con la consola cerrada, una autorizacion contestada se queda esperando. Es a proposito: una herramienta que manda trafico contra el sistema de un cliente porque llegó un correo, sin nadie delante, es exactamente lo que no se quiere.
En En curso: en que fase va el trabajo, un reloj, el registro en vivo de lo que va haciendo, el panel del segundo factor si hace falta, y los dos frenos: CERRAR y DETENER.
| Estado | Que significa | Que hacer |
|---|---|---|
| Corriendo | Trabajando con normalidad. | Nada. Deje la pantalla abierta. |
| Esperando codigo | Necesita un segundo factor para seguir. | Entréguelo. Ver abajo. |
| Inactivo | Lleva un rato sin producir nada. | Esperar un poco. Si no se mueve, detener. |
| Huérfana | Hay un proceso vivo que ya nadie vigila. No va a llegar ningun informe. | Ciérrela o detengála y vuelva a lanzar. |
| Terminado | Acabó por su cuenta. | Pase a U7. |
| Interrumpida | Se cortó antes de acabar; lo comprobado hasta ahi se conserva. | Revise lo que hay y decida si relanzar. |
| Detenido | Usted lo paró. | — |
Nunca se pinta como «en ejecucion», y es deliberado: una pantalla que anuncia un trabajo en marcha con el proceso ya muerto es peor que una pantalla que no dice nada, porque usted estaria esperando un informe que no va a llegar.
Cuando la aplicacion auditada pide un segundo factor, hay dos formas de resolverlo:
El codigo que escribe no se guarda en ningun sitio: se usa y se descarta.
Si deja un trabajo esperando un codigo y se va, la espera queda en pie y puede afectar al trabajo siguiente de esa aplicacion. Si no va a entregar el codigo, detenga el trabajo en lugar de cerrar la pestaña.
| Freno | Que hace |
|---|---|
| DETENER | Corta el trabajo que faltaba. Lo ya comprobado se conserva y el expediente se sella con el estado real. |
| CERRAR | Da el trabajo por terminado y lo sella. Si habia algo en marcha, lo aborta ahi mismo. |
Ninguno de los dos deshace lo que ya ocurrió. El trafico que salió, salió.
En Hallazgos, una fila por cada trabajo de esta aplicacion, con su fecha y su reparto por gravedad. Al abrir una fila, los hallazgos con su descripcion, su impacto, su recomendacion y los pasos para reproducirlos.
Las gravedades son las cinco de la seccion 06:
Critica Alta Media Baja Informativo
Un hallazgo que no se pudo reproducir se entrega marcado como no confirmado. Llévelo asi al cliente: pasar un hallazgo inferido como confirmado es la forma mas rapida de perder la credibilidad de un informe entero, y basta uno.
El reparto por gravedad cuadra con el numero total de hallazgos, y cada hallazgo tiene sus pasos de reproduccion.
En Resumen esta el sello de criticidad de la aplicacion: el numero de 0 a 99 y su banda de color, calculados sobre el ultimo trabajo que escribió hallazgos. La escala y lo que significa estan en la seccion 06. Recuerde la direccion: mas alto es peor.
En Hallazgos, cada trabajo terminado tiene su fila de Informe con dos botones. Son dos documentos distintos y por eso son dos botones separados:
| Boton | Que entrega | A quien va |
|---|---|---|
| Completo | Todos los hallazgos con su ubicacion y su analisis de riesgo. | Al responsable tecnico del sistema. |
| Ejecutivo | Reserva el detalle de los criticos y los altos: dice que hay, no donde. | Es el que puede circular. |
Un solo boton con un selector al lado invita a mandar el que no era. Despues del envio, lo unico que distingue los dos documentos es el nombre del archivo, y para entonces ya se mandó.
El documento se descarga. Ábralo y compruebe tres cosas antes de mandarlo: que la portada nombra la aplicacion correcta, que el veredicto coincide con el del Resumen, y que es la version que queria —completo o ejecutivo—.
| Lo que ve | Que hacer |
|---|---|
| Los botones estan apagados | El propio boton dice por que al pasar el raton: el trabajo sigue vivo, o no tiene hallazgos. |
| El veredicto no es el que esperaba | Revise el reparto por gravedad. Una critica pesa lo que seis medias, asi que una sola cambia el sello entero. |
| Falla al generar | El motivo sale al lado del boton. Vuelva a intentarlo una vez; si repite, anote la fecha del trabajo y la aplicacion antes de pedir ayuda. |
Queda un paso que no es obligatorio y casi siempre vale la pena: cuando el cliente avise de que corrigió, lance un Retesting desde su pestaña. Elija el trabajo de origen, entregue las credenciales y autorice por correo igual que en U5. El objetivo no se escribe a mano: se toma del trabajo que se revalida, para que no se pueda revalidar los hallazgos de un sistema contra otro. Consume un trabajo de los contratados y entrega un veredicto por cada hallazgo —los cuatro estan en la seccion 02—.
RED SIGMA · Manual de RTSS · octubre de 2026