Auditorías informáticas
Audinet
Preparando el sitio…
Buscamos las fallas de seguridad antes de que las encuentre alguien más: pruebas de intrusión con autorización escrita y un informe que dice qué tan grave es cada hallazgo y cómo se cierra.
El alcance se acuerda antes de empezar y queda escrito: qué sistemas entran, en qué horario se prueban y hasta dónde se puede llegar. Lo de abajo es el catálogo de dónde miramos; los tres planes dicen cuáles de estos entran en cada uno.
Revisamos la aplicación como la revisaría un atacante y como la revisa un usuario apurado: inyección de código, control de acceso, manejo de sesiones, subida de archivos y errores que muestran de más. La base es el OWASP Top 10 —las fallas que se siguen repitiendo en la web— cruzada con lo que tu aplicación hace en particular, porque la lista sola no audita nada.
La app vive en un teléfono que no es nuestro. Miramos qué guarda en el aparato, qué manda y qué recibe por la red, qué permisos pide de más y si se puede alterar el binario para saltarse controles. Se prueba en un equipo propio y, cuando se puede, sobre la app publicada, que es el escenario real y no el de un ambiente de desarrollo.
Una PWA se instala y funciona sin conexión, y eso la vuelve distinta a una web común: hay que revisar qué queda guardado en el caché del navegador, qué se puede leer desde el service worker y qué ve el usuario cuando está desconectado. Es una de las capas donde más datos aparecen guardados de más, porque nadie los revisó nunca.
Quién puede leer qué. Revisamos permisos y roles, cifrado en reposo y en tránsito, respaldos que de verdad se puedan restaurar y consultas capaces de sacar datos de otra tabla. Una base con los permisos mal puestos entrega todo lo demás: el resto de las capas se vuelve decorado, porque el atacante no necesita pasar por ninguna de ellas.
Con autorización escrita, intentamos entrar: desde afuera como lo haría un atacante externo, y desde adentro con el nivel de acceso de una persona de la propia empresa. Es la parte que convierte una revisión teórica en una demostración: un hallazgo con evidencia y una forma de reproducirlo pesa más que cualquier informe de configuración, sobre todo cuando hay que convencer a alguien de que el problema existe. En los planes va en el Total, que es donde el alcance llega hasta la intrusión.
Leemos el código donde el análisis automático no llega: cómo se manejan las claves, qué se valida y qué se da por hecho, dónde se escribe en la base y quién puede llegar a ese punto. Sirve sobre todo cuando el sistema lo escribió otro, o cuando ya nadie recuerda por qué una parte está como está.
Autenticación de la API, límites de uso, cabeceras de seguridad, certificados, servicios internos expuestos sin querer y paneles de administración que quedaron abiertos a internet. También miramos la parte que casi nunca se revisa y casi siempre falla: cómo se despliega el sistema y quién tiene acceso a qué.
La vulnerabilidad más difícil de parchear es la persona que abre el correo. Hacemos campañas controladas de phishing, con métricas de quién cayó y quién avisó, y una capacitación que sale de esos resultados y no de un video genérico sobre seguridad que nadie mira dos veces.
Revisamos lo que exige la normativa —Ley 19.628 y 21.719 de datos personales, ISO 27001, PCI-DSS si se cobra con tarjeta— y armamos el plan de qué hacer cuando algo pase: a quién se avisa, en qué orden y con qué evidencia. Un plan que se escribe después del incidente no sirve de nada, y es el que más se olvida.
Es la nueva ley chilena de protección de datos personales, y es distinta a todas las anteriores: crea una agencia que fiscaliza, fija plazos y trae multas que se cobran. Auditamos el estado de cumplimiento de tu empresa antes de esa fecha, con las brechas priorizadas y no con un diagnóstico de doscientas páginas.
Antes de tratar un dato tiene que existir un motivo legítimo —consentimiento, contrato, ley o interés legítimo— y la persona tiene que saber para qué se usan sus datos, en un lenguaje que entienda. La mitad de los problemas de cumplimiento no vienen de un tratamiento malo, sino de uno que nadie puede explicar.
Acceso, rectificación, supresión, oposición, portabilidad y no quedar sujeto a decisiones automatizadas. La ley fija plazos para responder y un procedimiento para reclamar ante la Agencia. Si no sabes dónde está guardado cada dato, no puedes responder a tiempo, y ese es exactamente el trabajo que hacemos primero: el mapa.
Hay que poder decir qué datos se tratan, dónde están y quién puede verlos, y para los tratamientos más riesgosos la ley pide una evaluación de impacto previa. Revisamos quién tiene acceso hoy —incluidas las planillas sueltas y los sistemas que nadie recuerda— y dejamos el registro armado con lo que de verdad ocurre.
Una brecha obliga a notificar a la Agencia y a las personas afectadas, con evidencia de qué pasó. Sin registros de acceso, sin responsables definidos y sin plan, no hay forma de cumplir el plazo: se descubre el incidente el lunes y se pasa la semana averiguando a quién avisar. El plan se escribe antes, no durante.
Nómina, contabilidad, marketing, el hosting, el que manda los correos. La ley pide que quien trata datos por encargo tenga un contrato que lo diga, con qué puede hacer y qué no. Revisamos con quién se comparten datos hoy —casi siempre son más de los que la empresa cree— y qué respalda cada uno.
El cumplimiento se cae si cualquiera entra a la base. Permisos, accesos, respaldos, registros y cifrado se revisan junto con la auditoría técnica, porque una política de privacidad impecable no sirve de nada si la base está abierta. Los dos trabajos se hacen con el mismo alcance o no se entiende ninguno de los dos.
La ley distingue infracciones leves, graves y gravísimas, y las multas de las últimas llegan a las 20.000 UTM. Es el primer régimen chileno de datos personales que exige acreditar lo que se hace —con registro, con políticas y con evidencia— en vez de prometerlo.
Y no es solo la 21.719: revisamos también la 19.628, que sigue vigente hasta el cambio, la ISO 27001, la PCI-DSS si se cobra con tarjeta, y lo que tus clientes exijan en sus propios contratos.
Casi nunca es un ataque sofisticado. Es algo simple que estuvo ahí durante años, que nadie miró porque siempre funcionó, y que se descubre el día que alguien lo busca.
Un respaldo que jamás se restauró no es un respaldo: es la esperanza de que exista uno. Se revisa si se puede volver atrás de verdad, con los datos completos y en un tiempo que sirva para algo, y casi siempre aparece que nadie lo intentó nunca.
Credenciales dentro del repositorio, en el front-end o compiladas dentro de una app. Cualquiera que vea el código las tiene, y cambiarlas después obliga a tocar todo lo que las usa, así que se postergan. Es la falla más barata de encontrar y la más incómoda de cerrar.
Herramientas de administración que quedaron expuestas sin querer, sin segundo factor y sin límite de intentos. Es la puerta más común de todas: no hace falta romper nada, basta con probar la combinación de usuario y clave de siempre. Se encuentra en minutos y a veces no se cierra en meses.
Cuando hay que comunicar un incidente, cada hora sin plan se va discutiendo a quién avisar y quién decide. Sin roles definidos ni evidencia guardada, la respuesta se arma a las apuradas justo cuando hay que actuar, y eso se recuerda mucho más que la falla original.
Antes de tocar nada se firma un permiso que dice qué sistemas entran, en qué horario se prueban, con qué credenciales y hasta dónde se puede llegar. Sin ese documento no empezamos: es lo que separa una auditoría de un delito, y lo que después permite trabajar tranquilo a los dos lados.
Primero en un ambiente de pruebas si existe; después, y con ventana acordada, sobre producción. Probamos a mano además de con herramientas, porque las herramientas encuentran lo de siempre y las fallas de verdad suelen estar en lo que tu sistema hace distinto a todos los demás.
Dos informes: el ejecutivo para quien decide y el técnico para quien arregla. Cuando los hallazgos se cierran, volvemos a probar los mismos puntos y entregamos el resultado de esa segunda pasada. Auditoría que no se re-prueba deja la duda abierta para siempre.
Porque un escáner repite una lista de comprobaciones y no entiende tu sistema. Encuentra lo que ya sabía buscar y no se da cuenta de nada de lo que tu aplicación hace distinto, que es justo donde suele estar la falla.
El alcance, la ventana de tiempo y las credenciales se acuerdan por escrito antes de la primera prueba. Trabajamos con la lista de lo que no se puede tocar, y no la salteamos ni con autorización verbal de por medio.
Lo que vemos adentro no sale de ahí: código, credenciales, datos de tus clientes, configuración interna. Las credenciales que se piden para probar se usan solo para eso y se destruyen al terminar, y el hallazgo se reporta a quien corresponde, no a todo el que pregunte.
Un informe de doscientas páginas no lo lee nadie. Cada hallazgo va con qué tan grave es, cómo se reproduce y qué se recomienda hacer, ordenado por riesgo y no por orden de aparición. Y lo que revisamos y estaba bien también queda escrito: saber qué se descartó vale tanto como saber qué se encontró.
Cuando se cierran los hallazgos volvemos a probar esos mismos puntos y entregamos el resultado, para que quede constancia de que quedaron cerrados. Y todos los planes incluyen horas de acompañamiento remoto —4, 8 o 12 según el alcance, en sesiones de 2 horas y hasta 4 por semana— para cerrarlos junto a tu equipo. Un hallazgo que se cree arreglado y no lo está es el peor de todos, porque da tranquilidad sin motivo.
Lo único que cambia entre planes es cuánto abarcan: la metodología, los dos informes y la re-prueba de lo que se cerró son los mismos en los tres. Las horas son el total de cada plan e incluyen el acompañamiento remoto, que se agenda en sesiones de 2 horas y hasta 4 horas por semana, hasta completar el total.
30 hde trabajo
Conocer los riesgos prioritarios.
Acompañamiento remoto: 4 h · 1 semana
Para una primera evaluación de seguridad.
66 hde trabajo
Seguridad y capacidad técnica, en operación.
Acompañamiento remoto: 8 h · 2 semanas
Para plataformas en operación.
102 hde trabajo
Revisión ampliada y evidencia de cumplimiento.
Acompañamiento remoto: 12 h · 3 semanas
Con exigencias de seguridad, código y privacidad.
El valor de cada plan va en la propuesta: se calcula con el alcance a la vista —qué sistemas entran y cuáles no, cuántos ambientes— y se envía por escrito, junto con la ficha de alcance y la vigencia. Las aplicaciones Android y iPhone entran en los planes Integral y Total.
Con estos datos te enviamos la propuesta: confirmamos el plan que elegiste —o te decimos en cuál calza tu caso, si marcaste «Aún no lo sé»—, qué entra y qué queda fuera, cuántas horas toma y cuánto sale. Si no calza en ninguno de los tres, se cotiza aparte y por escrito.
Se usa solo para responderte. No mandamos publicidad ni compartimos tus datos.
Lo que preguntan casi siempre antes de contratar una auditoría.
Es revisar un sistema para encontrar sus fallas antes de que las encuentre alguien más. Miramos cómo está construido, cómo está configurado y cómo se comporta cuando lo atacan. Al final queda una lista de hallazgos ordenada por gravedad, y por cada uno la forma concreta de cerrarlo.
Depende de cuánto abarque, y por eso hay tres planes: Esencial, Integral y Total. Los tres incluyen la misma metodología, los dos informes y la re-prueba de lo que se cerró; lo que cambia es el alcance. El valor va en la propuesta, con el alcance a la vista y por escrito —qué sistemas entran, qué queda fuera, cuántas horas toma y cuánto sale—, y va en UF, que se reajusta con la inflación. Si tu caso no calza en ninguno de los tres, se cotiza aparte.
La auditoría revisa y documenta; el hacking ético, además, intenta aprovechar las fallas. En la práctica van juntos: el mismo trabajo que revisa la configuración es el que después intenta entrar por donde esa configuración falla, siempre con autorización escrita y dentro de una ventana acordada con quien administra los sistemas. En los planes, el hacking ético entra en el Total.
Sí, y es el primer paso. No tocamos nada sin un permiso escrito del dueño de los sistemas, que diga qué se puede probar, en qué horario y hasta dónde se puede llegar. Es la diferencia entre una auditoría y un ataque: el mismo trabajo, con permiso, es un servicio profesional; sin permiso, es un delito.
Dos informes. Uno ejecutivo, para quien decide: qué encontramos, qué tan grave es, qué riesgo corre la empresa y en qué orden conviene cerrarlo. Y uno técnico, para quien lo va a arreglar: cada hallazgo con su evidencia, cómo reproducirlo y la recomendación concreta. Los hallazgos críticos no esperan al informe: se avisan en cuanto se confirman.
Depende del alcance, no del tipo de servicio: no es lo mismo un sitio de cinco pantallas que una app con API, base de datos y aplicación móvil. En los planes el trabajo está declarado en horas —30, 66 y 102, acompañamiento incluido— y con el alcance a la vista decimos cuándo se entrega el informe, en vez de prometer un plazo único que después no se cumple.
Primero en un ambiente de pruebas, siempre que exista. Cuando no existe, o cuando hay comportamientos que solo aparecen en producción, se acuerda una ventana, se avisa a quien corresponda y se empieza por las pruebas menos invasivas. No dejamos un sistema inestable ni usamos datos reales para demostrar una falla.
Sí. Revisamos cómo guarda los datos el teléfono, qué manda y qué recibe por la red, qué permisos pide y si se puede alterar el binario para saltarse controles. Es un trabajo distinto al de una web: la app vive en un aparato que no es nuestro, y ahí las fallas se ven de otra manera. En los planes, la app entra con el Integral y el Total.
Sí, y es uno de los trabajos que más se está pidiendo. Revisamos qué datos personales trata la empresa, con qué base de licitud, dónde están guardados, quién puede verlos y qué se puede acreditar hoy: registro de tratamientos, política de privacidad, contratos con proveedores, medidas de seguridad y plan de respuesta ante brechas. El resultado es una lista de brechas priorizadas por riesgo, no un certificado.
Entra en vigencia el 1 de diciembre de 2026 y reemplaza en la práctica a la Ley 19.628, que es la que rige hasta entonces. Lo importante no es la fecha del cambio sino lo que hay que tener listo antes: quién responde por los datos, dónde están, con qué base se tratan y cómo se contesta a alguien que pide los suyos. Eso no se arma en una semana.
Se avisa de inmediato, no al final. Si en el camino aparece una falla que expone datos de tus clientes, se para, se confirma, se documenta y se te cuenta ese mismo día, con la contención mínima para que deje de estar expuesta. Un hallazgo crítico que espera tres semanas al informe son tres semanas en que cualquiera lo puede aprovechar.
Sí. Todo lo que aparece en una auditoría —código, credenciales, datos de clientes, configuración interna— queda cubierto por confidencialidad, y firmamos el acuerdo que necesites antes de empezar. Las credenciales que se piden para probar se usan solo para eso y se destruyen al terminar.
No, y conviene decirlo claro: ninguna auditoría puede garantizar que un sistema sea invulnerable. Lo que entrega es una foto seria del estado de seguridad en un momento dado, con lo que se encontró y también con lo que se descartó. La seguridad es un trabajo continuo, no un sello que se pega una vez.
Sí, y es parte de lo que se cotiza: los tres planes incluyen horas de acompañamiento en sesiones remotas —4, 8 o 12 según el plan, en sesiones de 2 horas y con un tope de 4 horas por semana— para que tu equipo cierre los hallazgos con nosotros al lado. Lo que no hacemos es corregirlos nosotros: eso queda en tu equipo o en tus proveedores, y por eso está dicho en el alcance. Cuando se cierran, volvemos a probar los mismos puntos para confirmar que quedaron cerrados de verdad: un hallazgo que se cree arreglado y no lo está es el peor de todos.
Una auditoría no arregla un sistema, pero te dice exactamente qué está mal, qué tan grave es y en qué orden conviene arreglarlo. Y si en el camino aparece algo serio, te enteras por nosotros y no por un tercero.