Sabemos cómo proteger a nuestras tropas de los ataques a las telecomunicaciones. Simplemente no lo estamos haciendo.

A medida que se intensifica la lucha con Irán, la revelación de principios de este mes, informado por primera vez por The Financial Times – que Irán esté atacando al personal militar estadounidense a través de sus teléfonos inteligentes – no debería sorprendernos. La guerra en Ucrania ha proporcionado numerosas historias tanto de ucranio y ruso Soldados asesinados cuando sus teléfonos móviles revelaron su ubicación. Y, sin embargo, es probable que los militares estadounidenses en Medio Oriente sigan usando sus teléfonos celulares, tal como lo hacen los soldados ucranianos y rusos en Europa.

Lo sé, porque hace una generación, en la guerra de Irak, yo era sargento de comunicaciones de las Fuerzas Especiales del Ejército, con la tarea de mantener a mi equipo en contacto con el mando. Llevaba más de 100 libras de equipo de radio en mi mochila, pero también siempre llevaba un teléfono móvil en el bolsillo. A pesar de decenas de miles de dólares en equipos de comunicaciones, lo que sabía que siempre funcionaría cada vez que lo encendía era mi teléfono celular.

Los teléfonos móviles no han hecho más que mejorar desde entonces y su adopción (incluida la adopción militar) se ha ampliado. La telefonía móvil comercial está en casi todas partes, es fiable y está integrada en nuestras vidas. Incluso los altos funcionarios estadounidenses (que tienen equipos dedicados a transportar equipos de comunicaciones clasificados) se han metido en problemas al utilizar sus teléfonos inteligentes personales para comunicaciones confidenciales.

La guerra moderna, al igual que el resto de la vida moderna, se ejecuta en redes celulares comerciales, que funcionan muy bien pero que nuestros adversarios ponen en peligro fácilmente. Moscú aprendió esto cuando Ucrania pilotó drones en lo profundo de Rusia, utilizando las propias redes celulares de Rusia para hacer estallar. miles de millones de dólares de aviones militares. Pero Rusia no puede cerrar permanentemente su red celular, como tampoco podemos lograr que nuestros soldados dejen de usar teléfonos celulares.

Los ataques a las telecomunicaciones de Irán no son particularmente nuevos ni inventivos. El conocimiento de los ataques de señalización SS7 utilizados por Irán existe desde hace décadas. Los miembros del Congreso de ambos partidos han hecho sonar la alarma repetidamente a lo largo de los años, y en 2024, un funcionario de la Agencia de Seguridad de Infraestructura y Ciberseguridad informó que “numeroso” Los intentos exitosos han robado datos de ubicación, monitoreado mensajes de voz y de texto, entregado software espía e influenciado a los votantes estadounidenses desde el extranjero a través de mensajes de texto.

Los ataques de señalización aprovechan los mensajes de máquina a máquina que utilizan las redes de telecomunicaciones para verificar que usted paga su factura, verificar su ubicación y enrutar sus llamadas, mensajes o tráfico web. La señalización ocurre en segundo plano, invisible para los usuarios, y ha conectado a operadores globales durante décadas; considérelo como un sistema privado exclusivo para telecomunicaciones. Los ingenieros de telecomunicaciones diseñaron los protocolos que permiten la señalización en una era en la que sólo un pequeño número de grandes empresas de telecomunicaciones podían unirse al sistema, y ​​el modelo de seguridad refleja ese legado. Hoy en día, miles de entidades tienen acceso, pero los protocolos de telecomunicaciones aún aceptan cualquiera de sus mensajes de señalización como legítimos.

El resultado es que un atacante con acceso a la red troncal de señalización global, ya sea a través de un contrato de arrendamiento comercial o de un operador comprometido, puede enviar mensajes que los operadores de todo el mundo consideran confiables. Esto les permite rastrear la ubicación de un objetivo en tiempo real, interceptar llamadas y mensajes de texto, usar números de teléfono falsos y negar el servicio. Para el miembro del servicio desplegado, esto significa que los adversarios pueden analizar rápidamente sus patrones diarios y cualquier cambio en ellos, sin instalar malware, enviar un enlace de phishing o dejar ningún rastro en su dispositivo.

Entonces, ¿qué hacer? Los ataques a las redes de telecomunicaciones son especialmente peligrosos porque los usuarios no pueden protegerse mediante mejores hábitos de seguridad o precaución. Incluso si desactivas el uso compartido de ubicación y pones tu teléfono en modo de bloqueo, tu teléfono aún tiene que conectarse a redes celulares para poder funcionar. El diseño en sí permite a los adversarios acceder a él de forma remota. La solución no requiere del individuo, sino de la industria, los legisladores y el Pentágono.

En primer lugar, la industria mundial de las telecomunicaciones debería reforzar el control sobre el acceso a la red arrendado a terceros mal examinados. Los organismos de normalización deberían exigir transparencia y salvaguardias para los arrendamientos comerciales para evitar que los operadores de vigilancia adquieran credenciales legítimas. Cuando los reguladores detectan un mal comportamiento, deben actuar con rapidez para poner fin a esos acuerdos.

En segundo lugar, el Congreso y los reguladores deberían presionar a las principales aerolíneas para que fortalezcan sus defensas. En este momento, tienen pocas razones para corregir sus vulnerabilidades. Todas las principales aerolíneas estadounidenses han sufrido incumplimiento tras incumplimiento sin enfrentar consecuencias reales. Para responsabilizarlos, los operadores deberían publicar auditorías de seguridad, informar sobre sus firewalls y someterse a pruebas de penetración anuales. Después de los ataques del gobierno chino con el “Tifón de la Sal” contra las principales empresas de telecomunicaciones estadounidenses, Los senadores Ron Wyden y Eric Schmitt exigió al gobierno obtener auditorías de ciberseguridad de los operadores. Los transportistas se negaron, una respuesta inaceptable ahora que se han perdido vidas porque la industria ignoró este problema.

En tercer lugar, el Departamento de Defensa debería equipar a nuestros miembros del servicio con un servicio celular más seguro. Los teléfonos móviles siempre estarán en el campo de batalla, y ninguna formación o procedimiento puede solucionar un problema que no requiere software espía ni error del usuario para explotarlo. Las tecnologías innovadoras pueden abordar esta vulnerabilidad, pero como he previamente llamadonuestros soldados no pueden usarlos porque el Pentágono asegura el servicio celular a través de un contrato general de diez años, Espiral 4, que se renovó por última vez en 2024. La próxima oportunidad de cambiar a algo mejor no llegará hasta 2034.

Esta era de guerra conectada con adversarios técnicamente capacitados como Irán, Rusia y China hace que las vulnerabilidades de la infraestructura de telecomunicaciones sean una cuestión de vida o muerte. Sabemos esto desde hace décadas y la industria, el Congreso y el Pentágono pueden solucionarlo. Conozco la comodidad y el peligro de ese teléfono en mi bolsillo de carga, y debemos proteger la red de la que depende esta generación de soldados.

Juan Doyle

Escrito por John Doyle

John Doyle es el fundador y director ejecutivo de Cape, el operador de telefonía móvil que prioriza la privacidad.

RAMPART y Clarity de código abierto de Microsoft para proteger a los agentes de IA durante el desarrollo – CYBERDEFENSA.MX

Microsoft ha presentado dos nuevas herramientas de código abierto llamadas MURALLA y Claridad para ayudar a los desarrolladores a probar mejor la seguridad de los agentes de inteligencia artificial (IA).

MURALLAabreviatura de Risk Assessment and Measurement Platform for Agentic Red Teaming, funciona como un marco de pruebas de seguridad nativo de Pytest para escribir y ejecutar pruebas de seguridad para agentes de IA, que cubren problemas adversarios y benignos, así como varias categorías de daños.

Los usuarios pueden escribir casos de prueba para atacar o sondear a un agente de IA para explorar posibles violaciones de seguridad, como inyecciones cruzadas, donde datos no confiables llegan a un sistema de IA indirectamente a través de una fuente de datos (por ejemplo, correo electrónico, archivo o página web) procesada por este, o regresiones de comportamiento no intencionadas y exfiltración de datos.

RAMPART luego evalúa el resultado de esas pruebas e informa los resultados. Todo lo que necesita es un adaptador que conecte un agente al conjunto de pruebas. La herramienta se basa en PyRIT (abreviatura de Python Risk Identification Tool), que Microsoft lanzó hace más de dos años como una forma de probar sistemas de inteligencia artificial.

Claridadpor otro lado, ha sido descrito por el gigante tecnológico como una «caja de resonancia estructurada» para ayudar a los desarrolladores a llegar al enfoque correcto incluso antes de escribir una sola línea de código. Es un «socio de pensamiento de IA que retrocede», guiándolos a través de la aclaración de problemas, la exploración de soluciones, el análisis de fallas y el seguimiento de decisiones.

Ciberseguridad

Al hacer públicas estas herramientas, Microsoft dijo que la idea es abordar por qué ciertas decisiones se incorporan en una etapa temprana del desarrollo de software para que cualquier problema potencial (por ejemplo, el acceso de un agente a una herramienta) se aborde mucho antes de que se construya el sistema.

«Queríamos brindarles a los gerentes de producto e ingenieros una manera de poner a prueba sus suposiciones al inicio de un proyecto, cuando cambiar de rumbo es barato y la conversación correcta puede ahorrar meses de retrabajo». Ram Shankar Siva Kumarun Data Cowboy y fundador del AI Red Team de Microsoft, dicho en un blog compartido con The Hacker News.

Microsoft señaló que una motivación secundaria detrás de invertir en estas herramientas es hacer que los incidentes sean reproducibles y las mitigaciones verificables y escalar los aprendizajes de los ejercicios de equipos rojos convirtiéndolos en activos de ingeniería ejecutables.

«Mientras que PyRIT se optimiza para el descubrimiento de cajas negras por parte de los investigadores de seguridad después de que se construye el sistema, RAMPART se construye para los ingenieros a medida que se construye el sistema», agregó Siva Kumar. «La claridad ayuda a los equipos a aclarar la intención del diseño y capturar las suposiciones. Juntos, estos enfoques hacen que la seguridad de la IA pase de una revisión única a un conjunto de artefactos vivos que los desarrolladores pueden utilizar durante todo el ciclo de vida».

El Congreso y la industria reflexionan sobre la postura del gobierno para proteger los centros de datos

El crecimiento de los centros de datos (y los ataques de sus adversarios) dejó a los legisladores en una audiencia del miércoles contemplando si el gobierno federal tiene la configuración adecuada para defenderlos.

Algunos testigos y expertos de la industria en la audiencia del Subcomité de Seguridad Nacional sobre Ciberseguridad y Protección de Infraestructura de la Cámara de Representantes testificaron que la respuesta podría ser dar a los centros de datos su propia designación independiente como sector de infraestructura crítica.

La cuestión de cómo proteger los centros de datos contra ataques físicos y cibernéticos coincide con la inteligencia artificial alimentando un auge en la construcción de tales instalaciones en todo Estados Unidos. Mes pasado, Drones iraníes atacaron dos centros de datos de Amazon en respuesta a la campaña de bombardeos de Estados Unidos e Israel contra Irán, y también fue atacado un tercer centro de datos en Bahrein.

«Si un importante centro de datos es atacado, interrumpido o desconectado, las consecuencias pueden ir mucho más allá de una empresa o un sector», dijo el representante Andy Ogles, republicano por Tennessee, en los comentarios de apertura preparados. «Sin embargo, nuestro marco actual no proporciona un enfoque claro y unificado para la seguridad del centro de datos. No responde claramente qué agencia federal es responsable de comprender el riesgo, coordinar con la industria o liderar la respuesta cuando esta infraestructura es un objetivo».

Tres proveedores representan 63 por ciento de la cuota de mercado de los centros de datos: Amazon Web Services, Microsoft Azure y Google Cloud Platform.

El Reino Unido ya ha considerado los centros de datos como sector de infraestructura crítica independiente. Los representantes Vince Fong, republicano por California, y LaMonica McIver, DN.J., preguntaron a los testigos del panel el miércoles sobre la protección federal que se les brinda.

«Dado el escrutinio que se requiere para garantizar que esos centros de datos sean seguros, sería beneficioso que trabajaran juntos como un consejo coordinador único», dijo Robert Mayer, vicepresidente senior de ciberseguridad e innovación de USTelecom, un grupo industrial.

Mark Montgomery, de la Fundación para la Defensa de las Democracias, sugirió un sector que combine centros de datos y proveedores de nube, dada la superposición en la propiedad. La reescritura de 2024 de un memorando de seguridad nacional de la Casa Blanca dejó a algunos expertos decepcionados por no designar la computación en la nube como un sector de infraestructura crítica.

Samuel Visner, presidente de la junta directiva del Centro de Análisis e Intercambio de Información Espacial, dijo que estaba de acuerdo, dado el papel que desempeñan los centros de datos en la economía, el ejército y otras dependencias de Estados Unidos. «Encontrar una manera de considerarlos como parte de nuestra infraestructura crítica y protegerlos en consecuencia es sine qua non, absolutamente necesario», dijo.

Un cuarto testigo no opinó sobre la necesidad de una designación separada de infraestructura crítica. Pero Scott Algeier, director ejecutivo del Centro de Análisis e Intercambio de Información de Tecnología de la Información, dijo que su organización había creado un «grupo de interés especial» para proveedores de centros de datos.

«Los centros de datos ya están integrados en las discusiones sobre infraestructura crítica», dijo al panel.

Tim Starks

Escrito por Tim Starks

Tim Starks es reportero senior de CyberScoop. Sus paradas anteriores incluyen trabajar en The Washington Post, POLITICO y Congressional Quarterly. Originario de Evansville, Indiana, se ocupa de la ciberseguridad desde 2003. Envíe un correo electrónico a Tim aquí: tim.starks@cyberscoop.com.

Cómo proteger su SaaS de ataques de bots con SafeLine WAF – CYBERDEFENSA.MX

La mayoría de los equipos de SaaS recuerdan el día en que el tráfico de usuarios empezó a crecer rápidamente. Pocos se dan cuenta del día en que los robots empezaron a atacarlos.

Sobre el papel, todo parece genial: más registros, más sesiones, más llamadas API. Pero en realidad, algo se siente mal:

  • Los registros aumentan, pero los usuarios no se activan.
  • Los costos de los servidores aumentan más rápido que los ingresos.
  • Los registros están llenos de solicitudes repetidas de agentes de usuario extraños.

Si esto le suena familiar, no es sólo una señal de popularidad. Su aplicación está bajo constante ataque automatizado, incluso si no han llegado correos electrónicos de rescate. Su balanceador de carga ve el tráfico. Su equipo de producto ve «crecimiento». Su base de datos ve dolor.

Aquí es donde encaja un WAF como SafeLine.

Línea segura es un firewall de aplicaciones web (WAF) autohospedado que se ubica frente a su aplicación e inspecciona cada solicitud HTTP antes de que llegue a su código.

No solo busca paquetes rotos o IP malas conocidas. Observa cómo se comporta el tráfico: qué envía, a qué velocidad, en qué patrones y contra qué puntos finales.

En este artículo, mostraremos cómo se ven los ataques reales para un producto SaaS, cómo los bots explotan la lógica empresarial y cómo SafeLine puede proteger su aplicación sin agregar trabajo adicional a su equipo.

Los ataques que realmente ven los productos SaaS

Cuando la gente dice «ataques web», muchos piensan sólo en inyección SQL o XSS. Todavía existen y SafeLine los bloquea con un motor de análisis semántico integrado.

El motor de análisis semántico de SafeLine lee las solicitudes HTTP como un ingeniero de seguridad. En lugar de simplemente buscar palabras clave, comprende el contexto, decodifica cargas útiles, detecta tipos de campos extraños y reconoce la intención de ataque en SQL, JS, NoSQL y marcos modernos. Bloquea robots sofisticados y días cero con una precisión del 99,45 % y no es necesario realizar ajustes constantes en las reglas.

Solicitudes maliciosas bloqueadas por SafeLine

Pero para SaaS, los ataques más dolorosos no siempre son los más “técnicos”. Ellos son los que modifican las reglas de su negocio.

Ejemplos comunes:

  • Registros falsos: Los scripts de registro automatizados generan pruebas gratuitas, graban códigos de invitación o obtienen cupones de descuento.
  • Relleno de credenciales: Los bots prueban pares de nombre de usuario/contraseña filtrados en su punto final de inicio de sesión hasta que algo funciona.
  • raspado de API: Los competidores o raspadores genéricos recorren su API, página por página, copiando su contenido o precios.
  • Automatización abusiva: Un usuario (o botnet) desencadena trabajos pesados ​​en segundo plano, tareas de exportación o tormentas de webhooks por los que usted paga.
  • Picos de tráfico de bots: Oleadas repentinas de solicitudes programadas llegan a los mismos puntos finales, no lo suficientemente grandes como para ser un DDoS clásico, pero sí lo suficiente como para ralentizar todo.

La parte complicada es que todas estas solicitudes parecen «normales» a nivel HTTP.

Ellos son:

  • Bien formado
  • A menudo a través de HTTPS
  • Usando su API documentada

Por qué un WAF autohospedado tiene sentido para SaaS

Hay muchos productos WAF en la nube. Funcionan bien para muchos equipos. Pero los productos SaaS tienen algunas preocupaciones especiales:

  • Control de datos: Es posible que no desee que todas las solicitudes y respuestas fluyan a través de la nube de otra empresa.
  • Latencia y enrutamiento: Los saltos externos adicionales pueden ser importantes para los usuarios globales.
  • Depuración: Cuando un WAF en la nube bloquea algo, a menudo se ve un mensaje vago, no un contexto completo.

SafeLine toma un camino diferente:

  • Es autohospedado y se ejecuta como un proxy inverso frente a su aplicación.
  • Mantienes el control total sobre los registros y el tráfico.
  • Puede ver exactamente por qué se bloqueó una solicitud en sus propios paneles.

Para los equipos SaaS, eso significa que puedes:

  • Cumpla con las demandas más estrictas de los clientes o de cumplimiento sobre dónde fluyen los datos.
  • Ajuste las reglas sin abrir un ticket de soporte.
  • Trate su configuración WAF como parte de su infraestructura normal, no como un servicio de caja negra.

Cómo SafeLine ve y detiene el tráfico de bots

Los bots no son una sola cosa. Algunos son guiones torpes; algunos son casi indistinguibles de los usuarios reales. SafeLine utiliza varias capas para abordarlos.

1. Comprender el tráfico, no solo las firmas

SafeLine combina comprobaciones basadas en reglas con análisis semántico de solicitudes.

En la práctica, eso significa que analiza:

  • Parámetros y cargas útiles (para intentos de inyección, codificaciones extrañas, patrones de explotación).
  • Estructuras de URL y rutas de acceso (para escáneres, rastreadores y kits de explotación).
  • Frecuencia y distribución de llamadas (por abuso de inicio de sesión, scraping y ataques sutiles de inundación).

Esto es lo que le permite:

  • Bloquee los ataques web clásicos con una baja tasa de falsos positivos.
  • Detectar patrones extraños que no coinciden con ninguna «firma» pero que claramente no son un comportamiento normal del usuario.

2. Desafíos anti-bot

Algunos bots sólo pueden detenerse obligándolos a demostrar que no son máquinas. SafeLine incluye un Desafío anti-bots Característica: cuando detecta tráfico sospechoso, puede presentar un desafío que los navegadores reales manejan, pero los bots fallan.

Puntos clave:

  • Los usuarios humanos normales apenas lo notan.
  • Los rastreadores, scripts y herramientas de abuso básicos se bloquean o ralentizan drásticamente.
  • Tú decides dónde habilitarlo: registro, inicio de sesión, páginas de precios o API específicas.

3. Limitación de tarifas como red de seguridad

Para SaaS, “demasiado de algo bueno” es un problema real. Una integración demasiado entusiasta, un script defectuoso o un ataque pueden agotar los recursos.

SafeLine limitación de velocidad te permite:

  • Limite la cantidad de solicitudes que una IP o token puede realizar a puntos finales específicos por segundo, minuto u hora.
  • Proteja el inicio de sesión, el registro y las costosas API contra la fuerza bruta y las inundaciones.
  • Mantenga su aplicación estable incluso bajo picos anormales.

Esto es esencial para:

  • Proteger los niveles gratuitos del abuso.
  • Evitar que las “llamadas API ilimitadas” se conviertan en “facturas ilimitadas en la nube”.

4. Controles de identidad y acceso

Algunas partes de su SaaS nunca deberían ser públicas:

  • Paneles internos
  • Funciones beta tempranas
  • Herramientas de administración específicas de la región

SafeLine proporciona una desafío de autenticación característica. Cuando está habilitado, los visitantes deben ingresar una contraseña que usted establezca antes de poder continuar.

Esta es una forma sencilla de:

  • Oculte entornos internos o de prueba de escáneres y bots.
  • Reduzca el radio de explosión de rutas mal configuradas u olvidadas.

Una historia sencilla: un equipo SaaS frente al abuso de bots

Hay un pequeño producto B2B SaaS:

  • Menos de 10 personas en el equipo.
  • Nginx al frente de un conjunto de API REST.
  • Pruebas gratuitas, registro público y documentos API abiertos.

Al principio, los números parecen buenos. Entonces:

  • Los registros falsos ascienden a entre 150 y 200 por día.
  • Los picos de CPU alcanzan el 70 % debido a los intentos de inicio de sesión y al tráfico abusivo.
  • La base de datos crece más rápido que los usuarios de pago.

Cuando agregan SafeLine:

  • Lo implementan detrás de Nginx, como un WAF autohospedado.
  • Permiten la detección de bots, límites de tasas de registro e inicio de sesión y reglas básicas de abuso para cuentas nuevas.

Dentro de una semana:

  • Los registros falsos caen por debajo de 10 por día.
  • La CPU se estabiliza alrededor del 40%.
  • La conversión comienza a recuperarse porque los usuarios reales enfrentan menos obstáculos.

Lo interesante no son los números.

Es lo que hizo el equipo. no tienes que hacer:

  • No diseñaron una limitación compleja en la aplicación.
  • No mantenían un código personalizado de bloqueo de bots.
  • Durante meses no discutieron sobre si podían enviar el tráfico a un servicio de inspección externo.

SafeLine tomó silenciosamente la primera ola de abuso y el equipo de producto se centró nuevamente en las funciones y los clientes.

Cómo encaja SafeLine en una pila SaaS

Desde el punto de vista de la arquitectura, SafeLine se comporta como un proxy inverso:

  • Tráfico externo → SafeLine → sus servidores Nginx/aplicaciones.

Esto hace que sea más fácil de adoptar sin tener que reescribir su producto.

Puede:

  • Coloque SafeLine frente a su aplicación web principal y puerta de enlace API.
  • Enrute lentamente más dominios y servicios a través de él a medida que gane confianza.

El panel de SafeLine se convierte entonces en su “consola de seguridad”:

  • Verá registros de ataques: qué IP intentó qué, qué regla se activó, qué carga útil se bloqueó.
  • Ve tendencias: mayores escaneos, nuevos tipos de cargas útiles o patrones de bots en crecimiento.
  • Puede ajustar las reglas y protecciones con unos pocos clics.

Implementación y facilidad de uso

SafeLine WAF está diseñado para operadores de SaaS que quizás no tengan equipos de seguridad dedicados.

Una implementación suele tardar menos de 10 minutos. A continuación se muestra el comando de implementación con un solo clic:

bash -c «$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)» — –es

Consulte la documentación oficial para obtener instrucciones detalladas: https://docs.waf.chaitin.com/en/GetStarted/Deploy

Más importante aún, Línea segura todavía ofrece una edición gratuita para todos los usuarios de todo el mundo. Entonces, una vez que lo instales, estará listo para usar nada más sacarlo de la caja, sin ningún costo adicional. Sólo cuando necesite funciones avanzadas se requiere una licencia paga.

Después de la instalación, verás una interfaz limpia con una experiencia de configuración súper simple e intuitiva. Proteja su primera aplicación siguiendo este tutorial oficial: https://docs.waf.chaitin.com/en/GetStarted/AddApplication.

Una vez configurado, el WAF funciona de forma autónoma y proporciona visibilidad detallada de las amenazas y las acciones de mitigación.

Mirando hacia el futuro: seguridad continua

El panorama de amenazas está en constante evolución. Los bots son cada vez más inteligentes, los ataques están cada vez más dirigidos y las plataformas SaaS siguen aumentando en complejidad. Para mantenerse a la vanguardia, las empresas deben:

  • Supervise el comportamiento del tráfico continuamente
  • Adapte dinámicamente las reglas de limitación de velocidad y detección de bots
  • Audite periódicamente los registros para detectar actividades inusuales
  • Asegúrese de que los puntos finales sensibles tengan protecciones en capas

El enfoque de SafeLine se alinea perfectamente con estas necesidades, proporcionando una capa de seguridad flexible basada en datos que crece con su negocio SaaS.

Para aquellos interesados ​​en explorar la tecnología de primera mano, visite el Repositorio SafeLine GitHub o experimentar el Demostración en vivo. O simplemente puedes ir directamente a instalar ¡Pruébalo y pruébalo gratis para siempre!

¿Encontró interesante este artículo? Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en noticias de google, Gorjeo y LinkedIn para leer más contenido exclusivo que publicamos.