ES2938762T3 - Sistema, dispositivo y procedimiento de detección, mitigación y aislamiento de una tormenta de señalización - Google Patents

Sistema, dispositivo y procedimiento de detección, mitigación y aislamiento de una tormenta de señalización Download PDF

Info

Publication number
ES2938762T3
ES2938762T3 ES20191112T ES20191112T ES2938762T3 ES 2938762 T3 ES2938762 T3 ES 2938762T3 ES 20191112 T ES20191112 T ES 20191112T ES 20191112 T ES20191112 T ES 20191112T ES 2938762 T3 ES2938762 T3 ES 2938762T3
Authority
ES
Spain
Prior art keywords
iot
network
unit
devices
signal probe
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES20191112T
Other languages
English (en)
Inventor
Boris Lifshitz
Itai Weissman
Itai Zilbershtein
Nimrod Dezent
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Allot Ltd
Original Assignee
Allot Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US16/544,910 external-priority patent/US11323884B2/en
Application filed by Allot Ltd filed Critical Allot Ltd
Application granted granted Critical
Publication of ES2938762T3 publication Critical patent/ES2938762T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1416—Event detection, e.g. attack signature detection
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • G06N20/20—Ensemble learning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N5/00—Computing arrangements using knowledge-based models
    • G06N5/01—Dynamic search techniques; Heuristics; Dynamic trees; Branch-and-bound
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/12—Network monitoring probes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1425—Traffic logging, e.g. anomaly detection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12—Detection or prevention of fraud
    • H04W12/121—Wireless intrusion detection systems [WIDS]; Wireless intrusion prevention systems [WIPS]
    • H04W12/122—Counter-measures against attacks; Protection against rogue devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/02—Access restriction performed under specific conditions
    • H04W48/06—Access restriction performed under specific conditions based on traffic conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/144—Detection or countermeasures against botnets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0894—Policy-based network configuration management

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • General Physics & Mathematics (AREA)
  • Evolutionary Computation (AREA)
  • Data Mining & Analysis (AREA)
  • Artificial Intelligence (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Medical Informatics (AREA)
  • Computational Linguistics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Detectar, mitigar y aislar una Tormenta de Señalización, particularmente en redes de comunicación 5G. Se conecta una sonda de señal del plano de control en un primer nodo de red ubicado entre una red de acceso de radio y una red central 5G, para monitorear los mensajes de control que se originan en dispositivos con capacidad 5G. Una sonda de señal del plano de usuario está conectada a un segundo nodo de red ubicado entre la red central 5G y las entidades remotas a las que los dispositivos con capacidad 5G están enviando mensajes, para monitorear los mensajes de control que pasan a través del segundo nodo de red. Un subsistema de gestión de inventario almacena datos que se correlacionan entre dispositivos con capacidad 5G y números IMSI. Una unidad protectora está configurada para recibir (i) datos recopilados por la sonda de señal del plano de control, y (ii) datos recopilados por la sonda de señal del plano de usuario, y (iii) un subconjunto de números IMSI. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Sistema, dispositivo y procedimiento de detección, mitigación y aislamiento de una tormenta de señalización
Campo
La presente invención se refiere a dispositivos conectados a la red, y en particular a dispositivos del "Internet de las cosas" (IoT).
Antecedentes
Millones de usuarios de todo el mundo utilizan a diario dispositivos electrónicos e informáticos. Por ejemplo, los orde­ nadores portátiles, ordenadores de sobremesa, teléfonos inteligentes, tabletas y otros dispositivos electrónicos se utilizan para navegar por Internet, consumir contenidos digitales, transmitir audio y vídeo, enviar y recibir mensajes de correo electrónico, Mensajería Instantánea (IM), videoconferencias, juegos o similares.
Un dispositivo del "Internet de las cosas" (IoT) es un aparato, máquina o dispositivo capaz de comunicarse a través de una red con un servidor remoto o con un destinatario remoto. Por ejemplo, una bombilla IoT puede permitir a un usuario controlar la citada bombilla por medio de su teléfono inteligente. Del mismo modo, un detector de humo IoT puede proporcionar notificaciones de alerta a un teléfono inteligente de un usuario remoto si se detecta humo. La Solicitud de Patente Europea EP 3 313 114 A1 divulga un sistema para detectar y mitigar anomalías, tales como tormentas de señalización, en una Red de Acceso por Radio de un sistema de comunicación inalámbrica. Un proce­ dimiento divulgado en el citado documento incluye: recibir, en un primer módulo de análisis de tráfico local, parámetros de configuración de un segundo módulo de análisis de tráfico local o de un módulo de análisis de tráfico central co­ nectado a una pluralidad de módulos de análisis de tráfico local; monitorizar, por medio de un primer módulo de análisis de tráfico utilizando los parámetros de configuración recibidos, el tráfico en una red de acceso de radio de un sistema de comunicación inalámbrica; detectar, en el tráfico monitorizado sobre la base de los parámetros de configuración, una anomalía que produce una carga de señalización del plano de control; y en respuesta, tomar una acción para mitigar la anomalía y reportar la información sobre la anomalía al módulo de análisis de tráfico central. La solicitud de patente de los Estados Unidos US 2018/0375887 A1, en cuanto a esto se refiere, divulga un sistema y un procedi­ miento de protección de red adaptable para servicios gestionados por Internet de las Cosas (IoT). Una unidad de supervisión del tráfico de red divulgada en la presente memoria descriptiva monitoriza el tráfico de datos, el tráfico de operaciones y gestión, y los mensajes de control, que se relacionan con la comunicación celular entre un dispositivo IoT y una red celular central. Una unidad de agrupamiento de IoT agrupa varios dispositivos IoT en un grupo de IoT determinado. Una unidad de determinación del comportamiento de línea de base determina un Perfil de Comporta­ miento de Comunicación Celular de Línea de Base Regular (RBCCB) que caracteriza las comunicaciones celulares salientes y entrantes de cada miembro del grupo IoT particular. Posteriormente, un detector de valores atípicos detecta que un dispositivo IoT en particular de ese grupo IoT en particular, presenta características de tráfico celular que son anormales en relación con el perfil RBCCB que se caracterizó para ese grupo IoT en particular. Se activa un generador de acciones de aplicación para realizar selectivamente operaciones de aplicación, operaciones de notificación y ope­ raciones de cuarentena.
Sumario
La invención está definida por las reivindicaciones adjuntas.
Algunas realizaciones de la presente invención pueden proporcionar sistemas, dispositivos y procedimientos de pro­ tección de red adaptable para servicios gestionados de Internet de las Cosas (IoT). Por ejemplo, una unidad de su­ pervisión del tráfico de red supervisa el tráfico de datos, el tráfico de operaciones y gestión, y los mensajes de control relacionados con la comunicación celular entre un dispositivo IoT y una red celular principal. Una unidad de agrupa­ miento IoT agrupa varios dispositivos IoT en un grupo IoT particular. Una unidad de determinación del comportamiento de línea de base determina un perfil de Comportamiento de Comunicación Celular de Línea de Base Regular (RBCCB) que caracteriza las comunicaciones celulares salientes y entrantes de cada miembro del grupo IoT particular. Poste­ riormente, un detector de valores atípicos detecta que un dispositivo IoT en particular de ese grupo IoT en particular, presenta características de tráfico celular que son anormales en relación con el perfil RBCCB que se caracterizó para ese grupo IoT en particular. Se activa un generador de acciones de aplicación para realizar selectivamente una o más operaciones de aplicación, operaciones de notificación y operaciones de cuarentena.
La presente invención puede proporcionar otras ventajas y/o beneficios adicionales.
Breve descripción de los dibujos
La figura 1 es una ilustración esquemática de un sistema, de acuerdo con algunas realizaciones demostrati­ vas de la presente invención.
La figura 2 es una ilustración esquemática de un subsistema, de acuerdo con algunas realizaciones demos­ trativas de la presente invención.
La figura 3 es una ilustración esquemática en forma de diagrama de bloques de una unidad de detección y control del tráfico (TSE), de acuerdo con algunas realizaciones demostrativas de la presente invención.
La figura 4 es una ilustración esquemática de un sistema demostrativo en el que se pueden implementar las soluciones de detección y protección de la presente invención.
La figura 5 es una ilustración esquemática de la Unidad Protectora y sus componentes, así como sus inter­ faces con la(s) red(es) móvil(es), de acuerdo con algunas realizaciones demostrativas de la presente inven­ ción.
La figura 6A es una ilustración esquemática de un sistema, que demuestra la integración de unidades de la presente invención en una red 5G NR controlada por EPC, o en una red 5G No Autónoma (NSA).
La figura 6B es una ilustración esquemática de un sistema, que demuestra la integración de unidades de la presente invención en una red 5G Autónoma (SA).
La figura 7 es una ilustración esquemática de un sistema, que demuestra el despliegue o integración de unidades de la presente invención en una red de comunicación celular RAN Abierta.
Descripción detallada de algunas realizaciones demostrativas
El término "servicio IoT" puede comprender o puede ser un servicio o unidad o dispositivo o módulo o sensor distinto basado en IoT, como, por ejemplo, máquinas expendedoras de refrescos, cámaras, cámaras conectadas a Internet, dispositivos o sensores conectados al Protocolo de Internet (IP), cámara IP, sensor IP u otros dispositivos conectados a la red que sean empleados o gestionados o administrados por una corporación o entidad u organización específica. Por ejemplo, una empresa u organización puede utilizar múltiples "servicios IoT" o múltiples dispositivos o sensores IoT simultáneamente, normalmente repartidos en múltiples o numerosas ubicaciones geoespaciales, o cubriendo un área o región.
El término "servicio IoT gestionado" puede comprender o ser un "servicio IoT" que recibe una oferta específica de IoT de un Proveedor de Servicios de Comunicación (CSP) correspondiente, distinto de la población general de abonados del CSP, tales como los teléfonos móviles. De acuerdo con la presente invención, los detalles exactos de la oferta pueden variar entre los CSP; puede comprender ciberseguridad y protección de la red como parte de una propuesta de valor, abordando principalmente las siguientes preocupaciones de alto nivel: (1) Continuidad del servicio; (2) Exfil­ tración de datos, prevención de fugas de datos; (3) Protección de la reputación, protección contra el abuso de dispo­ sitivos IoT.
La presente invención comprende un sistema de red centralizado para CSP, que proporciona protección automatizada para servicios IoT gestionados bajo su control, mediante aprendizaje adaptativo; requiere poco o ningún aprovisiona­ miento manual y/o supervisión manual, y presenta detección automatizada o automática de problemas o amenazas relacionados con la seguridad, y (opcionalmente) solución automatizada o semiautomatizada de problemas o amena­ zas relacionados con la seguridad.
Los Solicitantes se han dado cuenta de que la colección de dispositivos IoT que comprende un servicio IoT gestionado, típicamente presenta o exhibe un comportamiento de red relativamente (o generalmente) coherente, consistente, es­ table y/o predecible, que puede ser monitorizado y rastreado y registrado, y que puede ser utilizado con el fin de detectar una anomalía o actividad de red irregular del o de los dispositivo(s) IoT, particularmente si tales dispositivos IoT que fueron afectados (por ejemplo, por un atacante, un atacante humano, una unidad de ataque automatizada) y/o que son defectuosos o funcionan mal. Esto contrasta con la población general de anfitriones de red, incluidos los teléfonos móviles y los ordenadores personales, que normalmente presentan un comportamiento de red considera­ blemente menos predecible y/o menor.
Por ejemplo, los Solicitantes se han dado cuenta de que un conjunto de dispositivos de usuario final, tales como los teléfonos inteligentes y los ordenadores portátiles de los empleados de una organización, presentan una actividad de red y/o una actividad de tráfico de datos menos predecibles; por ejemplo, puesto que un primer usuario final puede utilizar su dispositivo para realizar únicamente operaciones locales de procesamiento de textos y apenas puede co­ municarse a través de la red, mientras que un segundo usuario final puede utilizar su dispositivo para participar en actividades de videoconferencia de gran anchura de banda; y los citados patrones de uso suelen ser impredecibles. Por el contrario, un conjunto de dispositivos IoT, tal como un conjunto de máquinas expendedoras conectadas a Inter­ net, o un conjunto de detectores de humo conectados a Internet, muestran un comportamiento de red y/o actividad de tráfico generalmente estable y predecible; por ejemplo, cada máquina expendedora envía 3 kilobytes de datos cada hora en punto, y también envía 7 kilobytes adicionales de datos una vez al día a las 3 am. En consecuencia, el sistema de la presente invención puede utilizar esta información con el fin de detectar anomalías; por ejemplo, la observación de que diez máquinas expendedoras están enviando actualmente 8 kilobytes de datos cada 12 minutos, o que una máquina expendedora está enviando actualmente 240 kilobytes de datos cada minuto, desencadena una determina­ ción de que esta o estas máquinas expendedoras están funcionando defectuosamente y/o están afectadas.
Se hace referencia a la figura 1, que es una ilustración esquemática de un sistema 1, de acuerdo con algunas realiza­ ciones demostrativas de la presente invención. El sistema 1 representa opciones de despliegue demostrativas para servicios IoT gestionados dentro de (o en relación con) una o más redes de operadores de redes móviles (MNO), de acuerdo con algunas realizaciones demostrativas de la presente invención.
Con propósitos demostrativos, se muestran tres conjuntos de dispositivos IoT, denotados conjunto 101, conjunto 102 y conjunto 103. Cada conjunto de dispositivos IoT, o cada dispositivo IoT, se comunica (directamente, o indirectamente a través de un agregador IoT) con una Red de Acceso por Radio (RAN), que a su vez se comunica con una Red Central (105) de un Proveedor de Servicios de Comunicación (CSP). La red central se comunica con Internet 110 utilizando dos canales de comunicación separados: un canal de Operaciones, Administración y Gestión (OA&M, u O&M) y un canal de tráfico de datos. El Servicio IoT A (111) y el Servicio IoT B (112) son servicios demostrativos de valor añadido que el CSP proporciona a la empresa propietaria de los dispositivos IoT. Se utiliza un servidor de parte trasera 115 y/o Terminales o A&M 116 para administrar, controlar y gestionar los dispositivos IoT de la empresa.
El primer conjunto 101 de dispositivos IoT pertenecen a la Empresa 1, y se comunican con la RAN 104 indirectamente, a través de una unidad o nodo Agregador IoT. Este conjunto 101 de dispositivos IoT, con su respectivo agregador IoT, utiliza un Nombre de Punto de Acceso (APN) dedicado a esa Empresa 1 en particular, y se denota APN1.
El segundo conjunto 102 de IoT comprende: dispositivos IoT pertenecientes a la Empresa 2, y dispositivos IoT perte­ necientes a la Empresa 3. Se comunican con la RAN 104 a través de un APN dedicado, denominado APN2, que está dedicado únicamente a los dispositivos IoT que pertenecen a la Empresa 2 y a la Empresa 3.
El tercer conjunto de dispositivos IoT 103 comprende: dispositivos IoT pertenecientes a la Empresa 4, y dispositivos IoT pertenecientes a la Empresa 4, y dispositivos de consumidor / usuario final (por ejemplo, teléfonos inteligentes, tabletas, ordenadores portátiles) pertenecientes a varios abonados individuales. Se comunican con la RAN 104 a través de un APN común no dedicado, denominado APN3, que es utilizado por los dispositivos IoT que pertenecen a la Empresa 4 y/o a la Empresa 5 y/o por dispositivos de usuario final de otros abonados o usuarios (por ejemplo, dispositivos no IoT, sino más bien dispositivos de usuario final operados por usuarios humanos).
Como se ha demostrado, el acceso a la red de un dispositivo IoT puede ser Directo o Indirecto. En un acceso Directo a la red, cada dispositivo IoT se conecta directamente a la RAN de la red del CSP. En un acceso Indirecto a la red, varios dispositivos IoT se conectan a un agregador de acceso IoT, que a su vez se comunica con la RAN de la red del CSP.
Como se ha demostrado, el acceso a la red puede utilizar un APN dedicado o un APN común. Por ejemplo, se puede utilizar un APN dedicado para los servicios IoT gestionados, por cada cliente corporativo; de forma que todos los dispositivos IoT pertenecientes a los servicios IoT gestionados del citado cliente en particular utilicen un APN dedicado al cliente. Adicional o alternativamente, el APN dedicado se puede utilizar para servicios IoT gestionados que se com­ parten entre múltiples clientes corporativos; de tal forma que todos los dispositivos IoT pertenecientes a un conjunto de servicios IoT gestionados (y pertenecientes a múltiples clientes diferentes) utilizan un APN dedicado, distinto de los APN utilizados por otros tipos de abonados (por ejemplo, teléfonos móviles). Adicional o alternativamente, se puede utilizar un APN común, de tal manera que los dispositivos IoT pertenecientes a un conjunto de servicios IoT gestiona­ dos utilicen un APN común, que también es utilizado por la población general de abonados (por ejemplo, teléfonos móviles).
El sistema puede utilizar una RAN 104 adecuada, por ejemplo, Proyecto de Asociación de Tercera Generación (3GPP), IoT de Banda Estrecha (NB-IoT), 4G / Evolución a Largo Plazo, (LTE), Sistema Universal de Telecomunicaciones Móviles (UMTS), u otros tipos de RAN; incluyendo, por ejemplo, tipos de RAN específicos de IoT como LoRa, Sigfox, o similares.
Los canales de comunicación utilizados por el sistema incluyen un canal de Operaciones, Administración y Gestión (canal OA&M, o canal O&M); tal como un canal dedicado para operaciones OA&M, entre dispositivos IoT y una plata­ forma IoT OA&M. La plataforma de OA&M puede residir en las instalaciones del MNO y/o en la Internet pública (por ejemplo, en una nube pública). El canal OA&M puede estar protegido, por ejemplo, mediante un túnel de Red Privada Virtual (VPN).
Los canales de comunicación utilizados por el sistema incluyen además un canal de datos; tal como el tráfico de datos entre los dispositivos IoT y la Internet pública, que no está cubierto por (o no es transportado por) el canal OA&M. Esto puede incluir tráfico aplicativo entre dispositivos IoT y su correspondiente servidor, representado como iconos de nube de "servicio IoT".
Se puede desplegar una unidad de Detección y Control del Tráfico (TSE) 106 en uno o más puntos o nodos adecuados, o entre nodos o elementos de red particulares; por ejemplo, en la red principal del operador de telefonía móvil de forma en línea, en la que la unidad TSE 106 tiene visibilidad (y puede escuchar o monitorizar) del tráfico de red de los servicios IoT gestionados. En algunas realizaciones, opcionalmente, este despliegue de red puede corresponder a (o puede utilizar) la interfaz Gi en la arquitectura 3GPP, u otra interfaz adecuada. En algunas realizaciones, opcional­ mente, la unidad TSE 106 puede estar asociada a una plataforma IoT 107 ubicada en las instalaciones del MNO, o puede estar controlada por ella o ser accesible desde ella, que a su vez puede ser accesible desde una plataforma IoT global 108 y/o puede comunicarse con ella; o, en algunas realizaciones, opcionalmente, la unidad TSE 106 puede estar asociada a otro elemento servidor IoT adecuado o panel de control IoT o unidad de gestión IoT, o informar a ellos (o enviar alertas o notificaciones a ellos).
A efectos demostrativos, se muestra una única unidad TSE 106; sin embargo, se pueden utilizar dos o más unidades TSE, y un procesador o una unidad de toma de decisiones pueden operar basándose en datos que son monitorizados o recogidos por las citadas unidades TSE múltiples. Adicional o alternativamente, a efectos demostrativos, la unidad TSE 106 se muestra como situada en el punto de red 121, que se encuentra entre la red central CSP 105 e Internet 110; sin embargo, una o más de estas unidades TSE pueden ser desplegadas en otras ubicaciones de red, por ejem­ plo, en la ubicación 123 entre la RAN 104 y la red central del CSP 105, en la ubicación 124 entre la RAN 104 y el primer conjunto 101 de dispositivos IoT que tienen un agregador IoT, en la ubicación 122 entre la RAN 104 y el segundo conjunto 102 de dispositivos IoT, en la ubicación 125 entre la RAN 104 y el tercer conjunto de dispositivos IoT 103, y/o incluso como nodos de escucha/monitorización posteriores a Internet, tal como en las ubicaciones 126 y/o 127.
Las diversas unidades TSE pueden monitorizar uno o más tipos de paquetes o flujos de datos; por ejemplo, tráfico de datos, carga útil, cabeceras, paquetes o mensajes OA&M, mensajes de señalización y/o control, paquetes de Protocolo de Internet (IP), paquetes IPv4, paquetes IPv6, paquetes celulares, paquetes no IP, paquetes con formato interno de red celular, formato de Protocolo de Datos de Paquete (PDP), datos o paquetes 3GPp , datos o paquetes 2G o 3G o 4G o 4G-LTE o 5G, o similares.
En algunas realizaciones, una o más unidades TSE pueden estar conectadas o desplegadas (y pueden monitorizar el tráfico de red y/o paquetes) en una ubicación o nodo que se encuentra, por ejemplo, post-PGW (después de la Pasa­ rela de Red de Paquetes de Datos de una red básica móvil, como, por ejemplo, supervisando y/o analizando y/o filtrando o poniendo en cuarentena el tráfico que la PGW emite o transfiere), o en una ubicación que hace de interfaz entre una red LTE y otras redes de paquetes de datos (como Internet, o una red IMS basada en SIP); o en una ubicación o nodo entre la pasarela de servicio (SGW) y la PGW, o entre un sistema 2G y una PGW, o en una ubicación entre un sistema 3G y una PGW, o entre un sistema LTE y otro sistema basado en 3GPP, o incluso entre un nodo B evolucionado (o eNodeB, o eNB, o nodo B E-UTRAN) y la SGW, o en una interfaz o nodo de retransmisión de un elemento de red de una red de telefonía móvil que se comunica directamente de forma inalámbrica con el terminal móvil (Equipo de Usuario o UE). Por consiguiente, la(s) unidad(es) TSE puede(n) monitorizar y/o analizar la salida generada o emitida o retransmitida o transmitida por cualquiera de las unidades o nodos o elementos de red que se han mencionado más arriba.
Se aclara que la(s) unidad(es) TSE de la presente invención puede(n) realizar no sólo operaciones de monitorización y análisis de tráfico, sino que también puede(n) realizar una o más operaciones de mitigación una vez que se detecta o estima una anomalía o anormalidad; por ejemplo, un proceso de cuarentena que pone efectivamente en cuarentena un dispositivo IoT que se determina (o estima) que está afectado o está funcionando defectuosamente, bloqueando o descartando o no retransmitiendo paquetes y/o señales y/o mensajes y/o carga útil que se reciben del citado dispositivo IoT (por ejemplo, todo ese tráfico saliente del dispositivo IoT, o selectivamente solo una parte del tráfico saliente que está destinado a llegar a un destino en particular) y/o que se dirigen al citado dispositivo IoT (por ejemplo, todo ese tráfico entrante que se dirige hacia el dispositivo IoT, o selectivamente solo una parte del tráfico entrante que está destinado a llegar al dispositivo IoT desde un remitente en particular). De este modo, las operaciones de cuarentena selectiva pueden aislar el dispositivo IoT defectuoso o está afectado de otros anfitriones o destinos o servidores de la red, y/o pueden aislar el dispositivo IoT defectuoso o está afectado de la Internet pública y/o de uno o más destinos particulares o remitentes particulares y/o de uno o más dominios o servidores particulares; reduciendo o mitigando o eliminando de esta manera los posibles daños que puedan causar otras comunicaciones desde o hacia el citado dispositivo IoT defectuoso o está afectado.
Se hace referencia a la figura 2, que es una ilustración esquemática de un subsistema 2, de acuerdo con algunas realizaciones demostrativas de la presente invención. El subsistema 2 puede ser, por ejemplo, una implementación demostrativa de (o una parte de) la unidad TSE 106 de la figura 1, o un componente del sistema 1 de la figura 1, o un subsistema implementado en la ubicación de red 121 y/o 122 y/o 123 y/o 124 y/o 125 y/o 126 y/o 127, o un subsistema implementado dentro de (o en conjunto con) la red central CSP 105 y/o la RAN 104. El subsistema 2 puede implementarse utilizando una o más unidades o módulos, por ejemplo, un controlador 210 y un sensor / ejecutor 220.
Una Unidad de Sensor 221, u otra unidad de detección o escucha o rastreo o monitorización, ve o escucha o monitoriza o rastrea o captura o recoge todo el tráfico de red relevante (por ejemplo, a través de la interfaz Gi), así como infor­ mación de mapeo de direcciones de abonado (dispositivo IoT) (por ejemplo, proporcionada por una unidad de mapeo de abonado 230, por medio de la interfaz Sm).
El mapeo puede realizarse, por ejemplo, en dos etapas: (i) identificar qué tráfico (por ejemplo, dirigido a qué dirección IP, y/o entrante desde qué dirección IP) pertenece a qué tarjeta de Módulo de Identidad del Suscriptor SIM (por ejem­ plo, basándose en el proceso o los datos de Identificación del Abonado Móvil Internacional (IMSI), basándose en el proceso o los datos de identificación del Número de Directorio del Abonado Internacional de la Estación Móvil (MSI-SDN); ii) identificando el tipo de dispositivo IoT, por ejemplo, asignando o clasificando un dispositivo IoT en particular en una clase o grupo o tipo de dispositivos IoT (por ejemplo, máquinas expendedoras de refrescos; contadores de una compañía eléctrica; detectores de humo; o similares).
La primera etapa, de mapeo de tráfico a una SIM particular, puede ser realizada basándose en la señalización de la red celular, tal como extrayendo los datos de mapeo de la señalización misma, y/o recibiendo los datos de mapeo desde o por medio de contabilidad de radio desde un servidor de radio o una Función de Carga y Control de Políticas (PCRF) de la red celular.
La segunda etapa, de mapeo o clasificación de una tarjeta SIM particular a un tipo particular de dispositivos IoT, puede realizarse de una o más formas adecuadas; por ejemplo, basándose en datos recibidos a través de la integración con la plataforma de gestión de SIM(s) (por ejemplo, una entidad o elemento o unidad de red que maneja o gestiona las SIMs IoT de conectividad), y/o por perfilado de tráfico. Por ejemplo, la elaboración de perfiles de tráfico puede llevarse a cabo supervisando el tráfico de los dispositivos para crear y actualizar un perfil del comportamiento del dispositivo, como los dominios a los que accede de forma regular, y, a continuación, crear y actualizar una base de datos de perfiles de comportamiento de varios dispositivos, lo que permite hacer coincidir un dispositivo con un perfil de dispo­ sitivo existente; como ejemplo demostrativo, un coche conectado Tesla puede comunicarse normalmente con el do­ minio "Tesla-Telemetry-Service.com", mientras que un determinado modelo de máquinas expendedoras de refrescos puede comunicarse solo con el dominio "Best-Cola-Support.com", mientras que las unidades de medición de una compañía eléctrica pueden comunicarse solo con el dominio "Local-Power-And-Light.com", etc.; y en consecuencia, basándose en la agregación de datos de múltiples dispositivos que acceden al mismo dominio, puede crearse una clasificación de dispositivos IoT con un perfil que se acompaña, y la detección de un comportamiento de comunicación que coincida con el citado perfil puede utilizarse para identificar el tipo de dispositivo IoT.
La Unidad de Sensor 221 supervisa y recopila los siguientes datos para cada uno de los puntos finales identificados como dispositivos IoT gestionados, y/o para cada conexión de datos: (a) marca de tiempo de inicio; (b) tupla - 5 de las conexiones (por ejemplo, dirección IP de origen, puerto de origen, dirección IP de destino, puerto de destino, protocolo utilizado); (c) protocolos identificados; (d) volumen de tráfico ascendente; (e) volumen de tráfico aguas abajo; (f) re­ cuento de paquetes ascendentes; (g) recuento de paquetes descendentes. Los datos se recogen periódicamente (por ejemplo, a intervalos de tiempo predefinidos) por una unidad de recogida de datos 211 (por ejemplo, por medio de la interfaz Cl), y se almacenan en un repositorio de la misma.
Una unidad Analizadora 212 realiza el análisis de los datos recogidos: (a) Perfilado de la actividad de la red, realizado periódicamente (por ejemplo, a intervalos de tiempo predefinidos), agrupando los datos recogidos (por ejemplo, por medio de la interfaz Cd) utilizando un mecanismo de agrupamiento predefinido o un algoritmo de agrupamiento (por ejemplo, utilizando de medios K, u otro procedimiento de agrupamiento adecuado); y realizando la extracción de ca­ racterísticas del conjunto de datos, por clase de dispositivos IoT, en el que una clase se refiere a un conjunto de dispositivos IoT que pertenecen al mismo servicio o tipo IoT (por ejemplo, tipo de "máquina expendedora", o tipo de "detector de humo"). (b) Cada nuevo punto de datos para un dispositivo IoT en particular se compara con el clúster o clústeres de la clase para ese dispositivo; o, los rasgos o características del tráfico pertenecientes a un dispositivo IoT en particular, se comparan con los rasgos o características que caracterizan al clúster de dispositivos IoT de ese tipo. (c) Se detectan valores atípicos y se marcan como sospechosos, por ejemplo, basándose en una distancia superior a un valor umbral predefinido, o basándose en otros indicadores de irregularidad de valores o rangos de valores; y se genera una notificación con respecto al citado dispositivo IoT marcado, por ejemplo, para su tratamiento posterior manual y/o automático, para iniciar operaciones de mitigación de ataques, para la desactivación remota o la pausa remota del dispositivo IoT, o similares.
Los dispositivos IoT marcados o los candidatos sospechosos se excluyen de los cálculos K-Mean del clúster; y se colocan en un "modo de observación profunda" ordenando a la Unidad de Sensor 221 (p. ej., por medio de la interfaz In) que monitorice aún más su actividad de red (p. ej., opcionalmente en intervalos de tiempo más cortos o con una granularidad o resolución mayor). El modo de observación profunda puede incluir además el direccionamiento del tráfico HTTP a motores de inspección para la detección o infiltración de Bot; y/o la detección de intentos de escaneo desde los dispositivos IoT sospechosos hacia otros anfitriones internos de la red o del sistema.
La actividad de red monitorizada, y/o cualquier salida de las operaciones anteriores, son por ejemplo: (a) Recogidos periódicamente por el recopilador de datos 211 (por ejemplo, por medio de la interfaz Cl); y/o (b) Analizados periódi­ camente por el analizador 212 (por ejemplo, por medio de la interfaz Cd); y/o (c) Los dispositivos IoT candidatos que muestren un comportamiento malicioso o defectuoso o anormal se comunican a un componente de política 213 (por ejemplo, por medio de la interfaz Ac), y se colocan en cuarentena, sujetos a una política configurable o predefinida que es aplicada por un componente de Aplicación de Políticas 222 (por ejemplo, por medio de la interfaz En).
Lo que sigue es un ejemplo demostrativo de detección y/o mitigación de un ataque de Denegación de Servicio Distri­ buido (DDoS) contra un grupo de cámaras (o sensores, o dispositivos) conectados por IP u otros sensores o cámaras o dispositivos conectados a Internet.
Por ejemplo, 50. cámaras de tráfico de un determinado proveedor (V) están desplegadas en una zona geográfica, una ciudad o un estado. Cada cámara dispone de un módem celular y está conectada a Internet por medio de un proveedor de servicios determinado (CSP-1). Las cámaras envían secuencias de vídeo por medio de la conexión celular a un servidor de contenidos particular que reside en Internet, lo que permite a los ciudadanos ver las condiciones del tráfico en calles concurridas, intersecciones, autopistas o similares.
Esas cámaras conectadas por IP son dispositivos loT, que los piratas informáticos o atacantes pueden intentar afectar y/o explotar. Por ejemplo, los piratas informáticos desean atacar los servidores públicos de "foobar-news.com" me­ diante un ataque DDoS; necesitan un gran conjunto de "bots" o dispositivos afectados, generando cada dispositivo tráfico "legítimo" contra o hacia el servidor o servidores víctimas (por ejemplo, "foobar-news.com") de forma coordi­ nada, manteniendo además el anonimato de los piratas informáticos.
Los piratas informáticos escanean Internet en busca de anfitriones o dispositivos para infectar, subvertir y utilizar como "bots" para el ataque DDoS. Están familiarizados con las cámaras del proveedor V, y saben cómo detectarlas y pene­ trarlas o afectarlas (por ejemplo, abusando de una vulnerabilidad conocida / no parcheada). Realizan una "exploración lenta", escaneando Internet desde un servidor central para detectar esas cámaras vulnerables conectadas por IP.
Los piratas informáticos detectan al menos una cámara en la red de CSP-1. Aprovechan una vulnerabilidad conocida en la cámara de ese proveedor V para obtener acceso shell con privilegios de raíz en esa cámara. Los piratas infor­ máticos transfieren o instalan en la cámara afectada un módulo de software (malware) que les permite controlar la cámara de forma remota, e instruyen al módulo para que realice escaneos, así como ataques DDoS. El módulo de malware se pone en contacto con el servidor de Mando y Control (C&C) de los piratas informáticos. Los piratas infor­ máticos ordenan de forma remota a la cámara infiltrada (afectada) para que realice exploraciones adicionales, empe­ zando por la red CSP-1; se detectan cámaras adicionales y se infiltran del mismo modo; cada cámara infiltrada se pone en contacto con el servidor C&C y se registra para su uso; las cámaras infiltradas continúan realizando explora­ ciones adicionales, y así sucesivamente. Posteriormente, todas o la mayoría o un gran número de las cámaras IP están infectadas y están en contacto con el servidor C&C de los piratas informáticos. En una fecha y hora determina­ das, los atacantes utilizan el servidor de C&C para ordenar a todas las cámaras infiltradas que emitan numerosas y/o rápidas y/o frecuentes peticiones HTTP contra o hacia el/los servidor/es de "foobar-news.com" al mismo tiempo, de­ rribándolo así mediante un ataque DDoS.
El sistema de la presente invención puede detectar, prevenir y/o mitigar el citado ataque DDoS. Por ejemplo, el sistema de la presente invención supervisa y observa los patrones de tráfico de las 50. cámaras, y las agrupa automáticamente. Mientras las cámaras se encuentren en un estado "limpio" (no infectadas, no afectadas), la mayoría de ellas seguirán el mismo patrón de tráfico (por ejemplo, transmisión de secuencias de vídeo al servidor de contenidos; ocasionalmente, comunicación con el servidor de gestión del servicio IoT para conocer el estado y actualizar el software). Sin embargo, tras la infección inicial de una cámara o de algunas cámaras, el agrupamiento dinámica y continua de patrones de tráfico mostraría un cambio en el agrupamiento, a medida que más y más cámaras se infectan, realizan escaneos y están en contacto con el servidor C&C. En algún momento, una parte significativa (por ejemplo, más del N por ciento) de las cámaras de la red mostraría el patrón cambiado, o el patrón de tráfico irregular o anormal (o varios, múltiples, patrones irregulares o patrones anormales) que es diferente del patrón regular que mostraban previamente las cáma­ ras no infectadas y/o las cámaras que funcionaban correctamente. El sistema puede buscar estos cambios (cambios en los patrones / agrupamiento) a medida que se producen en el tiempo, y puede marcar el "cambio creciente" en el patrón como una indicación de infección o como una indicación de que algunos o todos los dispositivos IoT están afectados y/o están mostrando una actividad irregular.
La explicación anterior fue demostrada en el contexto de una detección de cámaras IP que están infectadas por malware y/o que están afectadas hacia (o dentro de) un ataque DDoS. Sin embargo, la presente invención puede operar de manera similar para detectar, prevenir y/o mitigar otras situaciones o condiciones irregulares o anormales o no deseadas; por ejemplo, el Vendedor V ha lanzado una actualización de software que se instala en miles de cámaras conectadas por IP, pero que también hace que transmitan erróneamente cantidades grandes o mayores de paquetes de datos; el sistema de la presente invención puede detectar las citadas cámaras "parcheadas" o "actualizadas" y puede marcarlas como si tuvieran una actividad anormal, incluso si la razón de la actividad irregular de la red fuera un parche legítimo (suministrado por el proveedor) aunque defectuoso, en lugar de un módulo de malware de un atacante.
En otro ejemplo, debido a un "error" (error de programación) en el software o firmware de las cámaras, miles de cámaras -que no están afectadas ni parcheadas- comienzan repentinamente a comportarse de forma anormal en una fecha y hora determinadas, como por ejemplo debido a un "error" de desbordamiento de pila o debido a un contador que supera sus límites predefinidos (p. ej., similar a un error Y2K); y el sistema de la presente invención puede detectar e informar de la citada actividad de red anormal que hace que la multitud de cámaras se comporten de una manera defectuosa o anormal.
La presente invención puede operar comparando un anfitrión (por ejemplo, un dispositivo IoT) con otros anfitriones (por ejemplo, con otros dispositivos IoT) en su grupo o en su clúster de dispositivos IoT (en lugar de simplemente comparar con un perfil de "línea de base" anterior de ese dispositivo por sí mismo) o que tengan el mismo tipo de dispositivo. La infección, la afectación o el ataque se detectan en función del comportamiento masivo de numerosos dispositivos IoT, y no simplemente en función del cambio particular en el patrón de comportamiento de un anfitrión en particular (dispositivo IoT), sino en función del cambio agregado exhibido por un grupo de anfitriones (dispositivo IoT) que aumenta con el tiempo a medida que los atacantes infectan cada vez más dispositivos IoT. La presente invención funciona para llevar a cabo las funciones anteriores, utilizando las características únicas de los dispositivos IoT, como una gran población de dispositivos uniformes, con un patrón de comunicación similar que puede agruparse y que puede utilizarse para la detección de valores atípicos de el agrupamiento; y la capacidad del sistema para observar estos dispositivos en masa, o en el agregado; y para combinar el agrupamiento / inferencia con la información que el sistema obtiene de la interacción con el plano de control del proveedor (por ejemplo, el sistema sabe por el plano de control del CSP-1 (por ejemplo, por IMSI, IP Range, etc.) que todos esos 50. abonados son en realidad dispositivos loT (por ejemplo, y no teléfonos móviles de usuario final), por lo que pueden someterse al procedimiento de detección anterior).
Con propósitos demostrativos, algunas partes de la explicación en la presente memoria descriptiva pueden referirse a una cámara conectada a Internet; sin embargo, otros dispositivos IoT adecuados pueden ser monitorizados y pueden ser asegurados de acuerdo con la presente invención, por ejemplo, varios tipos de sensores, máquinas expendedoras, sistemas de alarma, detectores, detectores de humo, detectores de incendios, detectores de CO, detectores de peligro, o similares.
A efectos demostrativos, algunas partes de la explicación en la presente memoria descriptiva pueden referirse a la utilización del sistema con el fin de detectar una brecha de seguridad de dispositivo(s) IoT, o para detectar un ataque DDoS que se está preparando o ejecutando; sin embargo, la presente invención puede ser utilizada para lograr otros y/o adicionales objetivos o resultados o beneficios, por ejemplo, para detectar otros tipos de brechas de seguridad o ataques, para detectar un mal funcionamiento o un dispositivo IoT que no funciona, o similares.
Se hace referencia a la figura 3, que es una ilustración esquemática en forma de diagrama de bloques de una unidad de Detección y Control del Tráfico (TSE) 3, de acuerdo con algunas realizaciones demostrativas de la presente inven­ ción. La unidad TSE 3 puede ser una implementación demostrativa de cualquiera de las unidades TSE explicadas o descritas más arriba. La unidad TSE 3 puede ser parte del sistema 1 de la figura 1, o puede ser una implementación demostrativa de la unidad TSE 106 de la figura 1, o puede estar conectada en otra(s) ubicación(es) adecuada(s) dentro del sistema 1 de la figura 1. La unidad TSE 3 puede ser una implementación demostrativa del subsistema 2 de la figura 2. En algunas realizaciones, la unidad TSE 3 puede comprender opcionalmente una o más unidades o componentes 0 módulos que no están necesariamente representados en la figura 3 y que pueden estar representados en la figura 1 y/o en la figura 2, y/u otros componentes o módulos adecuados que se han explicado anteriormente o que se des­ criben en la presente memoria descriptiva.
Por ejemplo, tal como se representa en la figura 3, la unidad TSE 3 puede comprender uno o más de los componentes y/o módulos del subsistema 2 de la figura 2, tales como la unidad de Recopilación de Datos 211, la unidad de Análisis 212, el componente de Política 213, el Controlador 210, el Sensor 221, el Ejecutor 222, la unidad de Mapeado de Abonados 230 (o una interfaz o conexión para recibir datos de la citada unidad de mapeado de abonados, o para enviar consultas a la citada unidad de mapeado de abonados).
La unidad TSE 3 puede comprender además una unidad de escucha y monitorización del tráfico de red 301, para monitorizar (a) el tráfico de datos y (b) el tráfico de operaciones y gestión y (c) los mensajes de control, que se originan en un dispositivo del Internet de las Cosas (IoT) y a continuación se intercambian entre (i) una red central de un Proveedor de Servicios Celulares (CSP), y (ii) el Internet público. La unidad de escucha y monitorización del tráfico de red 301 puede comprender opcionalmente (por ejemplo, como subunidades o módulos), o puede estar asociada con un módulo 302 de monitorización del Tráfico de Datos para monitorizar el tráfico de datos; un Módulo 303 de Monito­ rización del Tráfico de Operaciones y Gestión para monitorizar el tráfico de operaciones y gestión; y un módulo 304 de Monitorización de Mensajes de Señalización y Control para monitorizar la señalización y/o monitorizar los mensajes de control.
Una Unidad Identificadora de Datos 305 puede operar para identificar dentro del tráfico y mensajes monitorizados, basándose en la información de mapeo del abonado celular, tráfico de red particular que se intercambia entre (a) dispositivos de Internet de las Cosas (IoT) de un tipo particular, y (b) un destinatario seleccionado del grupo que consiste en: un servidor de operaciones y gestión de IoT, un servidor en la Internet pública, un elemento de red de la citada red central.
Una Unidad de Análisis y Agrupamiento 306 puede analizar el citado tráfico de red particular, y puede caracterizar una agrupamiento que representa un patrón regular de tráfico de red de los citados dispositivos IoT del citado tipo particu­ lar.
Una unidad de Detección de Valores Atípicos 307 puede detectar que un dispositivo IoT en particular exhibe caracte­ rísticas de tráfico de red que son dispares en relación con el citado grupo de patrones regulares de tráfico de red del citado tipo particular de dispositivos IoT.
Una unidad Generadora de Notificaciones 308 puede generar una notificación o alarma o alerta, de que el citado dispositivo IoT en particular está funcionando defectuosamente o está afectado, basándose en las citadas caracterís­ ticas de tráfico de red dispares que son exhibidas por el citado dispositivo IoT en particular.
En algunas realizaciones, el analizador y la unidad de agrupamiento pueden comprender o utilizar un Módulo de Agrupamiento 309 (por ejemplo, también referido en la presente memoria descriptiva a efectos demostrativos como Módulo de Agrupamiento de medios K 309), que realiza agrupamiento de medios K (u otro tipo de agrupamiento) de puntos de datos que representan actividad de red de cada uno de los citados dispositivos IoT que pertenecen al citado tipo particular de dispositivo IoT. En algunas realizaciones, estas operaciones pueden ser opcionalmente realizadas por un Módulo de Agrupamiento de Actividad de Red 310.
En algunas realizaciones, el analizador y la unidad de agolpamiento pueden comprender o utilizar un Módulo de Agrupamiento de medios K 309, que puede realizar una agolpamiento de medios K (u otro tipo de agolpamiento) de puntos de datos que representan el volumen de tráfico aguas arriba transmitido aguas arriba por cada uno de los citados dispositivos loT que pertenecen al citado tipo particular de dispositivo loT; de manera que el detector de valores atípicos detecte que un dispositivo loT en particular presenta un volumen de tráfico ascendente que es diferente en relación con el clúster que representa el volumen de tráfico ascendente del citado tipo particular de dispositivos loT. En algunas realizaciones, estas operaciones pueden ser llevadas a cabo opcionalmente por un módulo Detector de Anomalías Aguas Arriba 311.
En algunas realizaciones, el analizador y la unidad de agrupamiento pueden comprender o utilizar un Módulo de Agrupamiento de medios K 309, que realiza el agrupamiento de medios K (u otro tipo de agrupamiento) de puntos de datos que representan el volumen de tráfico aguas abajo transmitido aguas abajo hacia cada uno de los citados dis­ positivos loT que pertenecen al citado tipo particular de dispositivo loT; de tal forma que el detector de valores atípicos detecta que un dispositivo loT en particular presenta un volumen de tráfico aguas abajo que es diferente en relación con el citado clúster que representa el volumen de tráfico aguas arriba del citado tipo particular de dispositivos loT. En algunas realizaciones, estas operaciones pueden ser llevadas a cabo opcionalmente por un Módulo Detector de Ano­ malías Aguas Abajo 315.
En algunas realizaciones, el analizador y la unidad de agrupamiento pueden comprender o utilizar un Módulo de Agrupamiento de medios K 309, que realiza agrupamiento de medios K (u otro tipo de agrupamiento) de puntos de datos que representan protocolos de comunicación que son utilizados por cada uno de los citados dispositivos loT que pertenecen al citado tipo particular de dispositivo loT; de tal manera que el detector de valores atípicos detecta que un dispositivo loT en particular utiliza uno o más protocolos de comunicación que son dispares en relación con el citado clúster que representa los protocolos de comunicación que son utilizados por el citado tipo particular de dispositivos loT. En algunas realizaciones, estas operaciones pueden ser realizadas opcionalmente por un módulo Detector de Anomalías de Protocolos de Comunicación 312.
En algunas realizaciones, el analizador y la unidad de agrupamiento pueden comprender o utilizar un Módulo de Agrupamiento de medios K 309, que realiza el agrupamiento de medios K (u otro tipo de agrupamiento) de puntos de datos que representan la longitud temporal de las transmisiones de datos ascendentes por cada uno de los citados dispositivos loT que pertenecen al citado tipo particular de dispositivo loT; de tal manera que el detector de valores atípicos detecta que un dispositivo loT particular exhibe duraciones de tiempo de transmisiones de datos ascendentes que son dispares en relación con el citado clúster que representa la duración de tiempo de transmisiones de datos ascendentes por cada uno de los citados dispositivos loT del citado tipo particular de dispositivos loT. En algunas realizaciones, estas operaciones pueden ser llevadas a cabo opcionalmente por un módulo Detector de Anomalías de Duración de Tiempo Aguas Arriba 313.
En algunas realizaciones, el analizador y la unidad de agrupamiento pueden comprender o utilizar un Módulo de Agrupamiento de medios K 309, que realiza el agrupamiento de medios K (u otro tipo de agrupamiento) de puntos de datos que representan la duración de tiempo de las recepciones de datos descendentes hacia cada uno de los citados dispositivos loT que pertenecen al citado tipo particular de dispositivo loT; de manera que el detector de valores atípi­ cos detecta que un dispositivo loT en particular exhibe duraciones de tiempo de recepciones de datos aguas abajo que son dispares en relación con el citado clúster que representa la duración de tiempo de transmisiones de datos aguas abajo hacia cada uno de los citados dispositivos loT del citado tipo particular de dispositivos loT. En algunas realizaciones, estas operaciones pueden ser llevadas a cabo opcionalmente por un módulo 314 de Detección de Ano­ malías de Duración de Tiempo Aguas Abajo.
En algunas realizaciones, el analizador y la unidad de agrupamiento pueden comprender o utilizar un Módulo de Agrupamiento de medios K 309, que realiza el agrupamiento de medios K (u otro tipo de agrupamiento) de puntos de datos que representan marcas de tiempo de inicio de transmisiones de datos ascendentes por cada uno de los citados dispositivos loT que pertenecen al citado tipo particular de dispositivo loT; de tal manera que el detector de valores atípicos detecta que un dispositivo loT en particular exhibe marcas de tiempo de inicio de transmisiones de datos ascendentes que son dispares en relación con el citado clúster que representa marcas de tiempo de inicio de transmi­ siones de datos ascendentes por cada uno de los citados dispositivos loT del citado tipo particular de dispositivos loT. En algunas realizaciones, estas operaciones pueden ser llevadas a cabo opcionalmente por un módulo 316 de Detec­ ción de Anomalías en las Marcas de Tiempo de lnicio.
En algunas realizaciones, la unidad de análisis y agrupamiento tiene en cuenta además el tráfico monitorizado que se intercambia entre (i) una Red de Acceso por Radio (RAN) y (ii) la citada red central del citado CSP; por ejemplo, obtenido o recibido o monitorizado o rastreado por medio de un Módulo de Monitorización de RAN a Núcleo 317, u otro módulo o interfaz adecuado.
En algunas realizaciones, un detector de anomalía de dirección de destino de Protocolo de lnternet (lP) 321 puede operar (i) para determinar que un dispositivo loT particular pertenece a un tipo particular de dispositivos loT, (ii) para determinar que el citado tipo particular de dispositivos loT se comunica típicamente sólo con una única dirección de destino lP particular, (iii) para determinar que el citado dispositivo loT particular se comunica con otra dirección de destino lP, y (iv) para determinar que el citado dispositivo loT está funcionando defectuosamente o está afectado.
En algunas realizaciones, el detector de anomalía de dirección de destino de Protocolo de Internet (IP) 321 puede operar (i) para determinar que un dispositivo IoT particular pertenece a un tipo particular de dispositivos IoT, (ii) para determinar que el citado tipo particular de dispositivos IoT se comunica típicamente sólo con un conjunto predefinido de direcciones de destino IP particulares, (iii) determinar que el citado dispositivo IoT en particular se comunica con otra dirección IP de destino que no se encuentra en el citado conjunto predefinido de direcciones IP de destino en particular, y (iv) determinar que el citado dispositivo IoT está funcionando defectuosamente o está afectado.
En algunas realizaciones, un Detector de Anomalía de Volumen de Datos 322 puede operar (i) para determinar que un dispositivo IoT particular pertenece a un tipo particular de dispositivos IoT, (ii) para determinar que el citado tipo particular de dispositivos IoT se comunica típicamente enviando un volumen de datos particular por unidad de tiempo, (iii) para determinar que el citado dispositivo IoT particular se comunica enviando otro volumen de datos por unidad de tiempo, y (iv) para determinar que el citado dispositivo IoT está funcionando defectuosamente o está afectado.
En algunas realizaciones, un Detector de Anomalía de Frecuencia de Comunicación 323 puede operar (i) para deter­ minar que un dispositivo IoT particular pertenece a un tipo particular de dispositivos IoT, (ii) para determinar que el citado tipo particular de dispositivos IoT se comunica típicamente con destinos remotos hasta N veces por unidad de tiempo, en el que N es un número positivo; (iii) para determinar que el citado dispositivo IoT particular se comunica con destinos remotos más de N veces por unidad de tiempo, y (iv) para determinar que el citado dispositivo IoT está funcionando defectuosamente o está afectado.
En algunas realizaciones, un Detector de Anomalía de Duración de Comunicación 324 puede operar (i) para determi­ nar que un dispositivo IoT particular pertenece a un tipo particular de dispositivos IoT, (ii) para determinar que el citado tipo particular de dispositivos IoT se comunica típicamente con destinos remotos mediante sesiones de comunicación que tienen una duración de tiempo de hasta M unidades de tiempo, en el que M es un número positivo; (iii) determinar que el citado dispositivo IoT particular se comunica con un destino remoto mediante al menos una sesión de comuni­ cación que tiene una duración superior a M unidades de tiempo, y iv) determinar que el citado dispositivo IoT está funcionando defectuosamente o está afectado.
En algunas realizaciones, el Detector de Anomalías de Protocolos de Comunicación 312 puede operar (i) para deter­ minar que un dispositivo IoT particular pertenece a un tipo particular de dispositivos IoT, (ii) para determinar que el citado tipo particular de dispositivos IoT se comunica típicamente con destinos remotos utilizando un primer protocolo de comunicación particular, (iii) determinar que el citado dispositivo particular IoT se comunica con un destino remoto mediante al menos una sesión de comunicación que utiliza un protocolo de comunicación que es diferente del citado primer protocolo de comunicación particular, y (iv) determinar que el citado dispositivo IoT está funcionando defectuo­ samente o está afectado.
En algunas realizaciones, un Detector de Anomalía de Ventana de Tiempo de Comunicación 325 puede operar (i) para determinar que un dispositivo IoT particular pertenece a un tipo particular de dispositivos IoT, (ii) para determinar que el citado tipo particular de dispositivos IoT se comunica típicamente con destinos remotos sólo en una ventana de tiempo particular por día, (iii) determinar que el citado dispositivo IoT en particular se comunica con un destino remoto en un punto de tiempo que está fuera de la citada ventana de tiempo en particular, y (iv) determinar que el citado dispositivo IoT está funcionando defectuosamente o está afectado.
En algunas realizaciones, un Detector de Comunicaciones Excesivas puede operar (i) para determinar que un dispo­ sitivo IoT particular pertenece a un tipo particular de dispositivos IoT, (ii) para determinar que el citado tipo particular de dispositivos IoT se comunica típicamente con uno o más destinos remotos hasta P veces por día, en el que P es un número positivo; (iii) para determinar que el citado dispositivo IoT particular se comunica con uno o más destinos remotos más de P veces por día, y (iv) para determinar que el citado dispositivo IoT está funcionando defectuosamente o está afectado.
En algunas realizaciones, una Unidad de Cumplimiento y Cuarentena 330, al detectar que el citado dispositivo IoT particular está funcionando defectuosamente o está afectado, activa o hace funcionar un Módulo de Aislamiento Com­ pleto de Dispositivos IoT 331 (i) para bloquear la retransmisión de todo el tráfico saliente desde el citado dispositivo particular IoT a todos los destinos, y también (ii) para bloquear la retransmisión de todo el tráfico entrante al citado dispositivo particular IoT desde todos los remitentes.
En algunas realizaciones, por ejemplo, una unidad de aplicación y cuarentena 330 determina que un detector de humo, que normalmente se comunica sólo a las 3: AM durante un máximo de 20 segundos enviando un mensaje de tamaño fijo de 640 bytes a una dirección de destino IP que corresponde a "Smoke-Detectors-Company.com", muestra un comportamiento anormal, como por ejemplo, envía cada cuatro horas un mensaje de tamaño variable de entre 47 kilobytes y 58 kilobytes a una dirección IP de destino que corresponde a "Hackerz-Unite-Server.com". En consecuen­ cia, la unidad de aplicación y cuarentena 330 puede poner "Smoke-Detectors-Company.com" y/o su(s) dirección(es) IP correspondiente(s) en una lista blanca de destinos y remitentes con los que el detector de humo está autorizado a comunicarse. Del mismo modo, la unidad de aplicación y cuarentena 330 puede poner "Hackerz-Unite-Server.com" y/o su(s) dirección(es) IP correspondiente(s) en una lista negra de destinos y remitentes con los que el detector de humo no está autorizado a comunicarse. A continuación, se aplica el bloqueo total, parcial o selectivo del tráfico hacia o desde el dispositivo IoT afectado o que funciona incorrectamente, sobre la base de la citada lista blanca y/o lista negra; por ejemplo, descartando o bloqueando o descartando o no entregando o deteniendo (o borrando en tránsito) paquetes o mensajes o señales que se dirigen desde el dispositivo IoT a un destino de la lista negra, o que se dirigen desde un remitente de la lista negra hacia el dispositivo IoT; y/o permitiendo el paso y/o retransmitiendo y/o reenviando y/o entregando paquetes o mensajes o señales que se dirijan desde el dispositivo IoT a un destino de la lista blanca, o que se dirijan desde un remitente de la lista blanca hacia el dispositivo IoT.
En algunas realizaciones, la unidad de aplicación y cuarentena 330, tras detectar que el citado dispositivo IoT en particular está funcionando defectuosamente o está afectado, activa u opera un Módulo de Aislamiento Selectivo Ba­ sado en Lista Negra 332 (i) para definir una lista negra de destinos de red y remitentes de red con los que el citado dispositivo IoT en particular no está autorizado a comunicarse, y (ii) para bloquear selectivamente la retransmisión de todo el tráfico saliente del citado dispositivo IoT a uno o más destinos en particular incluidos en la citada lista negra, y también (iii) para bloquear selectivamente la retransmisión de todo el tráfico entrante al citado dispositivo IoT desde uno o más remitentes en particular incluidos en la citada lista negra.
En algunas realizaciones, la unidad de aplicación y cuarentena 330, al detectar que el citado dispositivo IoT particular está funcionando defectuosamente o está afectado, activa o hace funcionar un Módulo de Aislamiento Selectivo 333 Basado en Listas Blancas (i) para definir una lista blanca de destinos de red y remitentes de red con los que sólo el citado dispositivo IoT particular está autorizado a comunicarse, y (ii) bloquear selectivamente la retransmisión de todo el tráfico saliente del citado dispositivo IoT a uno o más destinos particulares que no estén en la citada lista blanca, y también (iii) bloquear selectivamente la retransmisión de todo el tráfico entrante al citado dispositivo IoT desde uno o más remitentes particulares que no estén en la citada lista blanca.
Se hace notar que los módulos anteriores, tales como el Módulo de Aislamiento Selectivo Basado en Listas Negras 332 y/o el Módulo de Aislamiento Selectivo Basado en Listas Blancas 333, son ejemplos no limitativos; y se pueden utilizar otros módulos de cuarentena selectiva o módulos de aislamiento selectivo o módulos de filtrado de tráfico selectivo adecuados, opcionalmente como parte de un Módulo de Filtrado de Tráfico Selectivo 335 u otra unidad o componente adecuado.
La unidad TSE 3 puede comprender además, opcionalmente, un Módulo de Perfilado de Tráfico 340 capaz de realizar las operaciones de perfilado de tráfico que se han descrito más arriba; y puede operar en conjunto con, y puede actualizar información en, una Base de Datos de Perfiles de Comportamiento de Dispositivos IoT 341 que almacena perfiles de comportamiento que indican características de la actividad de red que es típica y/o es común y/o está autorizada para un tipo particular de dispositivos IoT (por ejemplo, detector de humo; máquina expendedora; contador de electricidad). Opcionalmente, en el proceso de creación de perfiles de tráfico, una Unidad de Construcción de Perfiles de Tráfico de Dispositivos IoT 342 puede construir dinámicamente un perfil de comportamiento de actividad de red para cada dispositivo IoT que se monitoriza; los citados perfiles son entonces comparados o emparejados, por medio de un Módulo de Emparejamiento / Comparación 343 con la Base de Datos de Perfiles de Comportamiento de Dispositivos IoT 341, con el fin de determinar si un dispositivo IoT en particular, basado en las características detec­ tadas de su actividad de red, coincide con el perfil de comportamiento de la actividad de red de los dispositivos IoT de este tipo, o exhibe una actividad de red anormal y por lo tanto se sospecha que está afectado o está funcionando defectuosamente.
Opcionalmente, un Clasificador de Tipo de Dispositivo IoT 345 puede operar en conjunto con uno o más de los módulos o unidades que se han mencionado más arriba, por ejemplo, para clasificar un dispositivo IoT particular en un Tipo de dispositivos IoT (por ejemplo, detectores de humo; máquinas expendedoras; contadores de electricidad) basándose en una coincidencia entre (i) la actividad de red exhibida de ese dispositivo IoT particular y (ii) la actividad de red típica de los dispositivos IoT de este tipo según se refleja en su perfil de comportamiento. La clasificación puede utilizarse posteriormente para determinar si una actividad de red o un comportamiento de red detectados o capturados recien­ temente se encuentran dentro de los comportamientos de actividad de red típicos, comunes o permitidos para ese tipo de dispositivos IoT, determinando de esta manera que el dispositivo IoT no parece estar en peligro o no funciona correctamente; o, a la inversa, determinar si una actividad de red o un comportamiento de red detectado o capturado recientemente no se encuentra dentro de los comportamientos de actividad de red típicos, comunes o permitidos para ese tipo de dispositivos IoT, determinando de esta manera que el dispositivo IoT parece estar en peligro o funcionar incorrectamente.
En algunas realizaciones, opcionalmente, la Unidad de Análisis y Agrupamiento 306 (u otros módulos de análisis / agrupamiento como se describe), puede operar basándose en, o teniendo en cuenta, paquetes TCP/IP, paquetes PDP, tráfico post PGW, tráfico pre Pg W, tráfico post SGW, tráfico pre SGW, tráfico pre eNodeB, tráfico post eNodeB, tráfico RAN, tráfico o paquetes de Red Central, tráfico o señalización o mensajes de RAN a Red Central; cabeceras, cargas útiles, señales de elementos de comunicación; así como mensajes de señalización y/o control intercambiados, recibidos o enviados por cualquiera de los anteriores. En algunas realizaciones, opcionalmente, la Unidad de Análisis y Agrupamiento 306 (u otros módulos de análisis / agrupamiento como se describe), puede operar basándose en, o teniendo en cuenta, la salida PGW, entrada PGW, PGW retransmitida, salida SGW, entrada SGW, salida RAN, entrada RAN, salida Central Network, entrada Central Network, entrada eNodeB, salida eNodeB; así como mensajes de se­ ñalización y/o control intercambiados por, recibidos por o enviados por cualquiera de los anteriores.
En algunas realizaciones de la presente invención, un sistema comprende: una unidad de monitorización de tráfico de red 301, para monitorizar al menos uno de: (a) tráfico de datos, (b) tráfico de operaciones y gestión, (c) mensajes de control, que se refieren a la comunicación celular entre (I) un dispositivo de Internet de las Cosas (IoT) y (II) una red central de un Proveedor de Servicios Celulares (CSP); una unidad de agrupamiento IoT 326, para agrupar múltiples dispositivos IoT en un grupo IoT particular, basado en al menos uno de: (A) datos predefinidos que indican que los citados múltiples dispositivos IoT pertenecen a una misma entidad (por ejemplo, a una misma entidad propietaria); (B) datos predefinidos que indican que los citados múltiples dispositivos IoT son operados por una misma entidad (por ejemplo, a una misma entidad operadora; en la que el operador en este contexto no es necesariamente un Operador de Red Celular, sino más bien, es una entidad que opera un grupo específico de dispositivos IoT en nombre de un cliente o un cliente en particular, como, por ejemplo, una empresa de seguridad que opera un conjunto de cámaras IP o sensores IP en nombre de un cliente o un cliente) ); (C) datos generados dinámicamente que indican que los citados dispositivos múltiples exhiben el mismo patrón de comunicación durante un período de tiempo particular; una unidad de determinación de comportamiento de línea de base 327, para determinar un perfil de Comportamiento de Comuni­ cación Celular de Línea de Base Regular (RBCCB) que caracteriza las comunicaciones celulares salientes y entrantes de cada miembro del citado grupo IoT particular; un detector de valores atípicos 307, para detectar posteriormente que un dispositivo IoT particular del citado grupo IoT particular, exhibe características de tráfico celular que son anor­ males en relación con el perfil RBCCB que se caracterizó para el citado grupo IoT particular; un generador de acciones de aplicación 328, para realizar o generar o desencadenar o iniciar una o más operaciones de aplicación o acciones de respuesta con respecto al citado dispositivo IoT particular que exhibe características de tráfico celular que son anormales en relación con el perfil RBCCB que se caracterizó para el citado grupo IoT particular.
En algunas realizaciones, la unidad de supervisión del tráfico de red debe monitorizar: (a) tráfico de datos, y además, al menos uno de: (b) tráfico de operaciones y gestión, y (c) mensajes de control, relacionados con la comunicación celular entre (I) el citado dispositivo del Internet de las Cosas (IoT) y (II) la red central del proveedor de servicios celulares (CSP).
En algunas realizaciones, la unidad de agrupamiento IoT debe agrupar los citados múltiples dispositivos IoT en el citado grupo IoT particular, basándose en una lista de cadenas de Identidad de Abonado Móvil Internacional (IMSI) que se obtiene o recibe de un propietario u operador de los citados múltiples dispositivos IoT. Por ejemplo, un propie­ tario u operador de un grupo de 150 detectores de humo, proporciona una lista de cadenas IMSI de estos dispositivos en particular; que a continuación se agrupan en un grupo IoT basado en sus cadenas IMSI pertenecientes a esta lista.
En algunas realizaciones, la unidad de agrupamiento IoT debe agrupar los citados múltiples dispositivos IoT en el citado grupo IoT particular, basándose en una lista de una o más cadenas de Número de Director de Suscriptor Inter­ nacional de Estación Móvil (MSISDN) y/o cadenas de Identidad de Equipo Móvil Internacional (IMEI), que se obtiene o recibe de un propietario u operador de los citados múltiples dispositivos IoT. Por ejemplo, un propietario u operador de un grupo de 150 detectores de humo, proporciona una lista de cadenas MSISDN y/o IMEI de estos dispositivos en particular; que a continuación se agrupan en un grupo IoT basado en sus cadenas MSISDN o IMEI pertenecientes a esta lista.
En algunas realizaciones, la unidad de agrupamiento IoT debe agrupar los citados múltiples dispositivos IoT en el citado grupo IoT particular, basándose en al menos una lista de entre: (i) lista de datos de aprovisionamiento de dispositivos, (ii) lista de datos de serialización de dispositivos, que se obtiene o recibe de un propietario u operador de los citados múltiples dispositivos IoT.
En algunas realizaciones, la unidad de agrupamiento IoT debe agrupar los citados múltiples dispositivos IoT en el citado grupo IoT particular, basándose en al menos la detección de una misma cadena de usuario - agente en las peticiones HTTP enviadas por cada uno de los citados múltiples dispositivos IoT.
En algunas realizaciones, la unidad de agrupamiento IoT debe agrupar los citados múltiples dispositivos IoT en el citado grupo IoT particular, basándose en al menos la detección de que cada uno de los citados dispositivos IoT, envía exactamente M bytes de datos cada T horas, y recibe exactamente N bytes de datos cada T horas; en el que M, N y T son valores umbral predefinidos. La unidad de agrupamiento IoT puede utilizar, para este fin y para otros fines descritos en la presente memoria descriptiva, una o más unidades o módulos que miden o cuentan bytes o paquetes o elementos de datos que son enviados por y/o recibidos de un dispositivo IoT, junto con un temporizador o una unidad de temporización que supervisa el paso del tiempo, lo que permite la determinación del número o tamaño de las transmisiones / recepciones en un período de tiempo específico o franja horaria o ventana de tiempo por cada dispo­ sitivo IoT.
En algunas realizaciones, la unidad de agrupamiento IoT es para agrupar los citados múltiples dispositivos IoT en el citado grupo IoT particular, basado en al menos la detección de que cada uno de los citados dispositivos IoT: (I) envía cada T horas datos celulares con un volumen total en el rango de entre M1 y M2 bytes; y (II) recibe cada T horas datos celulares con un volumen total en el rango de entre N1 y N2 bytes; siendo M1, m 2, N1, N2 y T valores umbral prede­ finidos.
En algunas realizaciones, la unidad de agrupamiento IoT debe agrupar los citados múltiples dispositivos IoT en el citado grupo IoT particular, basándose en al menos la detección de que cada uno de los citados dispositivos IoT envía datos celulares salientes sólo a un mismo destino particular único (por ejemplo, al mismo destino único de Remote-Server.ExampleDomain.com), no más de una vez cada T minutos; en el que T es un valor umbral predefinido; o, a un mismo lote de destinos o entidades externas similares o generalmente similares o suficientemente similares (por ejem­ plo, algunos dispositivos IoT envían datos a RemoteServer.ExampleDomain.com, mientras que algunos otros dispo­ sitivos IoT envían datos a DataCollector.ExampleDomain.com, y algunos otros dispositivos IoT envían datos a Data-Receiver Example Domain.com; o similares, indicando la similitud de los destinos receptores debido a que tienen el mismo nombre de dominio, y permitiendo de esta manera a la unidad de agrupamiento IoT agruparlos aunque no envíen datos al mismo destino exacto sino a destinos suficientemente similares, en el que la suficiente similitud se determina en base a criterios o condiciones predefinidas como se ha demostrado más arriba con respecto a tener el mismo nombre de dominio en todos esos destinos similares).
En algunas realizaciones, la unidad de agrupamiento IoT debe agrupar los citados múltiples dispositivos IoT en el citado grupo IoT particular, basándose en al menos la detección de que cada uno de los citados dispositivos IoT recibe datos celulares entrantes sólo de una entidad remota única igual o similar (o, de un conjunto o lote de entidades remotas suficientemente similares o correlacionadas de otro modo, como se ha demostrado más arriba), no más de una vez cada T minutos; en el que T es un valor umbral predefinido.
En algunas realizaciones, la unidad de agrupamiento IoT debe agrupar los citados múltiples dispositivos IoT en el citado grupo IoT particular, basándose en al menos la detección de un patrón repetitivo particular de operaciones de comunicación celular salientes y entrantes que cada uno de los citados dispositivos IoT realiza repetidamente durante un periodo de tiempo predefinido. Esto puede ser realizado opcionalmente por un módulo o unidad de detección de patrones, que puede formar parte de la unidad de agrupamiento IoT o funcionar conjuntamente con ella, y que puede detectar o determinar que existe un patrón particular o suficientemente similar con respecto a las comunicaciones entrantes y/o salientes de dos o más dispositivos IoT.
En algunas realizaciones, la unidad de determinación del comportamiento de línea de base debe generar el citado perfil RBCCB del citado grupo IoT particular, realizando análisis tanto de (i) datos de tráfico celular de cada uno de los citados múltiples dispositivos IoT, como de (ii) metadatos sobre comunicaciones celulares de cada uno de los citados múltiples dispositivos IoT.
En algunas realizaciones, la unidad de determinación del comportamiento de línea de base es generar el citado perfil RBCCB del citado grupo IoT particular, mediante la realización de análisis tanto de (i) datos de tráfico celular de cada uno de los citados múltiples dispositivos IoT, como de (ii) metadatos sobre comunicaciones celulares de cada uno de los citados múltiples dispositivos IoT; en el que el citado análisis determina: (A) un volumen máximo de tráfico celular saliente que sale de un miembro del citado grupo IoT particular dentro de un periodo de tiempo predefinido; y (B) un volumen mínimo de tráfico celular saliente que sale de un miembro del citado grupo IoT particular dentro de un periodo de tiempo predefinido.
En algunas realizaciones, la unidad de determinación del comportamiento de línea de base es para generar el citado perfil RBCCB del citado grupo IoT particular, mediante la realización de análisis tanto de (i) datos de tráfico celular de cada uno de los citados múltiples dispositivos IoT, como de (ii) metadatos sobre comunicaciones celulares de cada uno de los citados múltiples dispositivos IoT; en el que el citado análisis determina: (A) un volumen máximo de tráfico celular entrante que llega a un miembro del citado grupo IoT particular dentro de un periodo de tiempo predefinido; y (B) un volumen mínimo de tráfico celular entrante que llega a un miembro del citado grupo IoT particular dentro de un periodo de tiempo predefinido.
En algunas realizaciones, la unidad de determinación del comportamiento de base debe generar el citado perfil RBCCB del citado grupo IoT particular, que indica al menos: (a) un volumen total máximo de tráfico celular saliente que un miembro del citado grupo IoT particular está autorizado a enviar dentro de un periodo de tiempo predefinido; y (b) un número máximo de transmisiones celulares salientes que un miembro del citado grupo IoT particular está autorizado a enviar dentro de un periodo de tiempo predefinido.
En algunas realizaciones, la unidad de determinación del comportamiento de línea de base debe generar el citado perfil RBCCB del citado grupo IoT particular, basándose en una lista obtenida de valores umbral de comunicaciones celulares y rangos umbral que un miembro del citado grupo IoT particular tiene permitido realizar dentro de un periodo de tiempo predefinido.
En algunas realizaciones, la unidad de determinación del comportamiento de línea de base debe actualizar el citado perfil RBCCB del citado grupo IoT particular, basándose en una indicación o una identificación de que los miembros del citado grupo IoT particular han recibido una actualización de firmware o un parche de seguridad. Esto puede permitir al sistema reducir o eliminar posteriormente una decisión de "falso positivo" con respecto a los dispositivos IoT que recibieron la citada actualización o parche, lo que les hizo modificar legítimamente su patrón de comunicacio­ nes (por ejemplo, debido a la actualización o mejora o al parche, cada dispositivo IoT envía ahora legítimamente 326 bytes cada hora, en lugar de enviar previamente sólo 241 bytes cada tres horas).
En algunas realizaciones, la unidad de determinación del comportamiento de línea de base es para determinar el citado RBCCB basado al menos en el agrupamiento de puntos de datos que representan el número de transmisiones celulares salientes que son transmitidas por cada uno de los citados múltiples dispositivos loT dentro de un período de tiempo predefinido. El agolpamiento que se ha descrito más arriba o en la presente memoria descriptiva, puede basarse en el agolpamiento de medios K, y/o en otros tipos adecuados de procedimientos de agolpamiento; y puede basarse en un solo tipo de puntos de datos o en múltiples tipos de puntos de datos (por ejemplo, múltiples caracterís­ ticas) que se evalúan juntas con fines de agrupamiento.
En algunas realizaciones, la unidad de determinación del comportamiento de línea de base debe determinar el citado RBCCB basándose al menos en el agrupamiento de puntos de datos que representan el número de recepciones celulares entrantes que son recibidas por cada uno de los citados múltiples dispositivos loT dentro de un periodo de tiempo predefinido.
En algunas realizaciones, la unidad de determinación del comportamiento de línea de base debe determinar el citado RBCCB basándose al menos en el agrupamiento de puntos de datos que representan el volumen ascendente total de transmisiones celulares salientes que son transmitidas por cada uno de los citados múltiples dispositivos loT dentro de un periodo de tiempo predefinido.
En algunas realizaciones, la unidad de determinación del comportamiento de línea de base debe determinar el citado RBCCB basándose al menos en el agrupamiento de puntos de datos que representan el volumen descendente total de recepciones celulares entrantes que son recibidas por cada uno de los citados múltiples dispositivos loT dentro de un periodo de tiempo predefinido.
En algunas realizaciones, la unidad de determinación del comportamiento de línea de base debe determinar el citado RBCCB basándose al menos en el agrupamiento de puntos de datos que representan la duración de las transmisiones celulares ascendentes transmitidas por cada uno de los citados múltiples dispositivos loT dentro de un periodo de tiempo predefinido.
En algunas realizaciones, la unidad de determinación del comportamiento de línea de base debe determinar el citado RBCCB basándose al menos en el agrupamiento de puntos de datos que representan la duración de las recepciones celulares descendentes recibidas por cada uno de los citados múltiples dispositivos loT dentro de un periodo de tiempo predefinido.
En algunas realizaciones, la unidad de determinación del comportamiento de línea de base debe determinar el citado RBCCB basándose al menos en el agrupamiento de puntos de datos que representan tipos particulares de protocolos de comunicación que son utilizados para transmisiones celulares ascendentes por cada uno de los citados múltiples dispositivos loT dentro de un periodo de tiempo predefinido.
En algunas realizaciones, la unidad de determinación del comportamiento de línea de base debe determinar el citado RBCCB basándose al menos en el agrupamiento de puntos de datos de lnspección Profunda de Paquetes (DPl) que representan tipos particulares de aplicaciones que generan transmisiones celulares ascendentes por cada uno de los citados múltiples dispositivos loT dentro de un periodo de tiempo predefinido.
En algunas realizaciones, la unidad de determinación del comportamiento de línea de base debe generar el citado perfil RBCCB que indica que todos los miembros del citado grupo loT particular envían transmisiones celulares ascen­ dentes sólo a una única dirección de destino de Protocolo de lnternet (lP) particular; en el que el detector de valores atípicos comprende un detector de anomalía de dirección de destino de Protocolo de lnternet (lP), (i) para determinar que el citado dispositivo loT particular envía una o más transmisiones celulares ascendentes a otra dirección de destino lP, y (ii) para determinar que el citado dispositivo loT particular está funcionando defectuosamente o está afectado.
En algunas realizaciones, la unidad de determinación del comportamiento de línea de base debe generar el citado perfil RBCCB que indica que todos los miembros del citado grupo loT particular reciben transmisiones celulares des­ cendentes sólo desde una única dirección de origen de Protocolo de lnternet (lP) particular; en el que el detector de valores atípicos comprende un detector de anomalía de dirección de origen de Protocolo de lnternet (lP), (i) para determinar que el citado dispositivo loT particular recibe una o más comunicaciones celulares descendentes desde otra dirección de destino lP, y (ii) para determinar que el citado dispositivo loT particular está funcionando defectuosa­ mente o está afectado.
En algunas realizaciones, la unidad de determinación del comportamiento de base debe generar el citado perfil RBCCB que indica que todos los miembros del citado grupo loT particular envían transmisiones celulares ascendentes sólo a un conjunto particular de direcciones de destino de Protocolo de lnternet (lP); en el que el detector de valores atípicos comprende un detector de anomalías en la dirección de destino del Protocolo de lnternet (lP), (i) para determinar que el citado dispositivo loT particular envía una o más transmisiones celulares ascendentes a otra dirección de destino lP que no está en el citado conjunto particular de direcciones de destino lP, y (ii) para determinar que el citado dispositivo loT particular está funcionando defectuosamente o está afectado.
En algunas realizaciones, la unidad de determinación del comportamiento de base debe generar el citado perfil RBCCB que indica que todos los miembros del citado grupo loT particular reciben transmisiones celulares descendentes sólo desde un conjunto particular de direcciones de origen de Protocolo de lnternet (lP); en el que el detector de valores atípicos comprende un detector de anomalías en la dirección de origen del Protocolo de lnternet (lP), (i) para determinar que el citado dispositivo loT en particular recibe una o más comunicaciones celulares descendentes desde otra dirección de destino IP que no se encuentra en el citado conjunto particular de direcciones de origen IP, y (ii) para determinar que el citado dispositivo IoT en particular está funcionando defectuosamente o está afectado.
En algunas realizaciones, la unidad de determinación del comportamiento de línea de base debe generar el citado perfil RBCCB que indica que cada transmisión celular ascendente, que es típicamente realizada por cada miembro del citado grupo IoT particular, tiene una longitud total de entre M1 y M2 bytes, en el que M1 y M2 son valores umbral predefinidos; en el que el detector de valores atípicos comprende un detector de anomalías en el volumen de datos, (i) para determinar que el citado dispositivo IoT particular envía al menos una transmisión celular ascendente que tiene una longitud total que no está entre M1 y M2 bytes, y (ii) para determinar que el citado dispositivo IoT particular está funcionando defectuosamente o está afectado.
En algunas realizaciones, la unidad de determinación del comportamiento de base debe generar el citado perfil RBCCB que indica que cada transmisión celular descendente, que es típicamente recibida por cada miembro del citado grupo IoT particular, tiene una longitud total de entre M1 y M2 bytes, en el que M1 y M2 son valores umbral predefinidos; en el que el detector de valores atípicos comprende un detector de anomalías en el volumen de datos, (i) para determinar que el citado dispositivo IoT particular recibe al menos una transmisión celular descendente que tiene una longitud total que no está entre M1 y M2 bytes, y (ii) para determinar que el citado dispositivo IoT particular está funcionando defectuosamente o está afectado.
En algunas realizaciones, la unidad de determinación del comportamiento de línea de base debe generar el citado perfil RBCCB que indica que cada miembro del citado grupo IoT particular, envía entre N1 y N2 transmisiones celulares discretas dentro de un período de tiempo de T horas, en el que N1 y N2 y T son valores de umbral predefinidos; en el que el detector de valores atípicos comprende un detector de anomalías en la frecuencia de comunicación, (i) para determinar que el citado dispositivo IoT en particular envía D transmisiones celulares discretas dentro de T horas, en el que D no está entre N1 y N2 bytes, y (ii) para determinar que el citado dispositivo IoT en particular está funcionando defectuosamente o está afectado.
En algunas realizaciones, la unidad de determinación del comportamiento de línea de base debe generar el citado perfil RBCCB que indica que cada miembro del citado grupo IoT particular, establece entre N1 y N2 solicitudes de conexión a la red central cada T horas, en el que N1 y N2 y T son valores umbral predefinidos; en el que el detector de valores atípicos comprende un detector de anomalías en la frecuencia de comunicación, (i) para determinar que el citado dispositivo IoT particular establece R solicitudes de conexión a la red central cada T horas, en el que D no está entre N1 y N2, y (ii) para determinar que el citado dispositivo IoT particular está funcionando defectuosamente o está afectado.
En algunas realizaciones, la unidad de determinación del comportamiento de línea de base debe generar el citado perfil RBCCB que indica que cada transmisión celular ascendente, que es típicamente realizada por cada miembro del citado grupo IoT particular, tiene una duración de tiempo total de entre M1 y M2 segundos, en el que M1 y M2 son valores umbral predefinidos; en el que el detector de valores atípicos comprende un detector de anomalías en la duración temporal, (i) para determinar que el citado dispositivo IoT particular envía al menos una transmisión celular ascendente que tiene una duración temporal total que no está comprendida entre M1 y M2 segundos, y (ii) para determinar que el citado dispositivo IoT particular está funcionando defectuosamente o está afectado.
En algunas realizaciones, la unidad de determinación del comportamiento de línea de base debe generar el citado perfil RBCCB que indica que cada transmisión celular ascendente, que es típicamente realizada por cada miembro del citado grupo IoT particular, es realizada usando un protocolo de comunicación particular; en el que el detector de valores atípicos comprende un detector de anomalía de protocolo de comunicación, (i) para determinar que el citado dispositivo IoT particular envía al menos una transmisión celular ascendente usando otro protocolo de comunicación, y (ii) para determinar que el citado dispositivo IoT particular está funcionando defectuosamente o está afectado.
En algunas realizaciones, la unidad de determinación del comportamiento de línea de base es para generar el citado perfil RBCCB que indica que cada transmisión celular ascendente, que es típicamente realizada por cada miembro del citado grupo IoT particular, es realizada por una aplicación particular que se ejecuta en cada miembro del citado grupo IoT particular; en el que el detector de valores atípicos comprende un detector de anomalías de la aplicación, (i) para determinar que el citado dispositivo IoT particular envía al menos una transmisión celular ascendente por medio de otra aplicación que se ejecuta en el citado dispositivo IoT particular, y (ii) para determinar que el citado dispositivo IoT particular está funcionando defectuosamente o está afectado.
En algunas realizaciones, la unidad de determinación del comportamiento de línea de base debe generar el citado perfil RBCCB que indica que cada transmisión celular ascendente, que es típicamente realizada por cada miembro del citado grupo IoT particular, es realizada por una aplicación particular que se ejecuta en cada miembro del citado grupo IoT particular; en el que el detector de valores atípicos comprende un detector de anomalías de la aplicación, (i) para determinar, basándose en el análisis de Inspección Profunda de Paquetes (DPI), que el citado dispositivo IoT particular envía al menos una transmisión celular ascendente por medio de otra aplicación que se ejecuta en el citado dispositivo IoT particular, y (ii) para determinar que el citado dispositivo IoT particular está funcionando defectuosa­ mente o está afectado.
En algunas realizaciones, la unidad de determinación del comportamiento de línea de base es para generar el citado perfil RBCCB que indica que cada transmisión celular ascendente, que es típicamente realizada por cada miembro del citado grupo IoT particular, es realizada dentro de una ventana de tiempo particular; en el que el detector de valores atípicos comprende un detector de anomalía de ventana de tiempo de comunicación, (i) para determinar que el citado dispositivo IoT particular envía al menos una transmisión celular ascendente durante un intervalo de tiempo que está fuera de la citada ventana de tiempo particular, y (ii) para determinar que el citado dispositivo IoT particular está fun­ cionando defectuosamente o está afectado.
En algunas realizaciones, la unidad de determinación del comportamiento de línea de base debe generar el citado perfil RBCCB que indica que cada miembro del citado grupo IoT particular, realiza hasta N transmisiones celulares ascendentes por día; en el que el detector de valores atípicos comprende un detector de comunicaciones excesivas, (i) para determinar que el citado dispositivo IoT particular realiza más de N transmisiones celulares ascendentes por día, y (ii) para determinar que el citado dispositivo IoT particular está funcionando defectuosamente o está afectado.
En algunas realizaciones, la unidad de determinación del comportamiento de línea de base debe generar el citado perfil RBCCB basándose en una base de datos previamente obtenida o previamente preparada que almacena datos que indican reglas de comunicación celular de línea de base que pertenecen a diferentes tipos de dispositivos IoT.
En algunas realizaciones, la unidad de determinación del comportamiento de referencia actualiza dinámicamente el citado perfil RBCCB del citado grupo IoT particular, basándose en el Aprendizaje de Máquina (ML) continuado del comportamiento relacionado con el tráfico de los miembros del citado grupo IoT particular.
En algunas realizaciones, el detector de valores atípicos es para: (i) detectar que el citado dispositivo IoT en particular muestra una actividad de comunicación celular que es suficientemente diferente, más allá de un umbral predefinido de diferencia, del citado perfil RBCCB del citado grupo IoT en particular, y (ii) activar el citado generador de acciones de aplicación para realizar una o más operaciones de aplicación con respecto al citado dispositivo IoT en particular.
En algunas realizaciones, el detector de valores atípicos es para: (i) detectar que el citado dispositivo IoT en particular exhibe una actividad de comunicación celular que es suficientemente dispar, más allá de un umbral predefinido de disparidad, del citado perfil RBCCB del citado grupo IoT en particular, y (ii) para detectar que existe una causa autori­ zada para la citada actividad de comunicación celular, y (iii) para determinar que la citada actividad de comunicación celular es un falso positivo, y evitar la activación del citado generador de acciones coercitivas.
En algunas realizaciones, el generador de acciones de aplicación debe enviar una notificación, a un propietario o a un operador del citado grupo IoT particular, indicando (i) un identificador del citado dispositivo IoT particular, y (ii) una indicación de que el citado dispositivo IoT particular está funcionando defectuosamente o está afectado.
En algunas realizaciones, el generador de acciones de aplicación es para poner en cuarentena todo el tráfico celular que se envía desde el citado dispositivo IoT en particular.
En algunas realizaciones, el generador de acciones de aplicación es para poner en cuarentena todo el tráfico celular que se dirige al citado dispositivo IoT en particular.
En algunas realizaciones, el generador de acciones de aplicación es para poner en cuarentena todo el tráfico celular que se dirija al citado dispositivo IoT en particular, excepto el tráfico celular que se origine desde un propietario genuino del citado dispositivo IoT (por ejemplo, de acuerdo con lo predefinido en el sistema, por ejemplo, basado en una lista que indica identificadores de dispositivos IoT y su respectivo propietario legítimo o propietario genuino).
En algunas realizaciones, al detectar que el citado dispositivo IoT en particular está funcionando defectuosamente o está afectado, el generador de acciones de aplicación activa un módulo de cuarentena selectiva basado en una lista negra (i) para definir una lista negra de destinos de red y remitentes de red con los que el citado dispositivo IoT en particular no está autorizado a comunicarse, y (ii) bloquear selectivamente la retransmisión de todo el tráfico celular saliente del citado dispositivo IoT a uno o más destinos particulares que se encuentren en la citada lista negra, y también (iii) bloquear selectivamente la retransmisión de todo el tráfico celular entrante al citado dispositivo IoT desde uno o más remitentes particulares que se encuentren en la citada lista negra.
En algunas realizaciones, al detectar que el citado dispositivo IoT particular está funcionando defectuosamente o está afectado, el generador de acciones de aplicación activa un módulo de cuarentena selectiva basado en listas blancas (i) para definir una lista blanca de destinos de red y remitentes de red con los que solamente el citado dispositivo IoT particular está autorizado a comunicarse, y (ii) para bloquear selectivamente la retransmisión de todo el tráfico celular saliente del citado dispositivo IoT a uno o más destinos particulares que no estén en la citada lista blanca, y también (iii) para bloquear selectivamente la retransmisión de todo el tráfico celular entrante al citado dispositivo IoT desde uno o más remitentes particulares que no estén en la citada lista blanca.
De acuerdo con las realizaciones de la presente invención, los cálculos, operaciones y/o determinaciones pueden realizarse localmente dentro de un único dispositivo, o pueden realizarse por o por medio de múltiples dispositivos, o pueden realizarse parcialmente localmente y parcialmente remotamente (por ejemplo, en un servidor remoto) utilizando opcionalmente un canal de comunicación para intercambiar datos brutos y/o datos procesados y/o resulta­ dos de procesamiento.
Aunque porciones de la explicación en la presente memoria descriptiva, a efectos demostrativos, se refieren a enlaces por cable y/o comunicaciones por cable, algunas realizaciones no están limitadas en este sentido, sino que pueden utilizar comunicación por cable y/o comunicación inalámbrica; pueden incluir uno o más enlaces por cable y/o inalám­ bricos; pueden utilizar uno o más componentes de comunicación por cable y/o comunicación inalámbrica; y/o pueden utilizar uno o más procedimientos o protocolos o estándares de comunicación inalámbrica.
Algunas realizaciones pueden implementarse utilizando una máquina de propósito especial o un dispositivo de propó­ sito específico que no sea un ordenador genérico, o utilizando un ordenador no genérico o un ordenador o máquina no general. El citado sistema o dispositivo puede utilizar o comprender uno o más componentes o unidades o módulos que no formen parte de un "ordenador genérico" y que no formen parte de un "ordenador de propósito general", por ejemplo, transceptores celulares, transmisor celular, receptor celular, unidad GPS, unidad de determinación de ubica­ ción, acelerómetro(s), giroscopio(s), detectores o sensores de orientación del dispositivo, detectores o sensores de posicionamiento del dispositivo, o similares.
Algunas realizaciones pueden implementarse como, o utilizar, un procedimiento automatizado o proceso automati­ zado, o un procedimiento o proceso implementado por máquina, o como un procedimiento o proceso semiautomatizado o parcialmente automatizado, o como un conjunto de pasos u operaciones que pueden ser ejecutados o realiza­ dos por un ordenador o máquina o sistema u otro dispositivo.
Algunas realizaciones pueden implementarse utilizando un código o código de programa o instrucciones legibles por máquina o código legible por máquina, que pueden almacenarse en un medio de almacenamiento no transitorio o artículo de almacenamiento no transitorio (por ejemplo, un CD-ROM, un DVD-ROM, una unidad de memoria física, una unidad de almacenamiento físico), de tal manera que el programa o código o instrucciones, cuando son ejecutados por un procesador o una máquina o un ordenador, hacen que el citado procesador o máquina u ordenador realice un procedimiento o proceso como se describe en la presente memoria descriptiva. El citado código o instrucciones pue­ den ser o comprender, por ejemplo, uno o más de entre: software, un módulo de software, una aplicación, un programa, una subrutina, instrucciones, un conjunto de instrucciones, código informático, palabras, valores, símbolos, cadenas, variables, código fuente, código compilado, código interpretado, código ejecutable, código estático, código dinámico; incluyendo (pero no limitado a) código o instrucciones en lenguaje de programación de alto nivel, lenguaje de progra­ mación de bajo nivel, lenguaje de programación orientado a objetos, lenguaje de programación visual, lenguaje de programación compilado, lenguaje de programación interpretado, C, C++, C#, Java, JavaScript, SQL, Ruby on Rails, Go, Cobol, Fortran, ActionScript, AJAX, XML, JSON, Lisp, Eiffel, Verilog, Lenguaje de descripción de hardware (HDL), BASIC, Visual BASIC, Matlab, Pascal, HTML, HTML5, CSS, Perl, Python, PHP, lenguaje de máquina, código máquina, lenguaje ensamblador o similares.
Las explicaciones en la presente memoria descriptiva que utilizan términos tales como, por ejemplo, "procesamiento", "computación", "cálculo", "determinación", "establecimiento", "análisis", "comprobación", "detección", "medición", o si­ milares, pueden referirse a la(s) operación(es) y/o proceso(s) de un procesador, un ordenador, una plataforma infor­ mática, un sistema informático, u otro dispositivo electrónico o dispositivo informático, que puede(n) manipular y/o transformar de forma automática y/o autónoma datos representados como cantidades físicas (por ejemplo, electróni­ cas) dentro de registros y/o acumuladores y/o unidades de memoria y/o unidades de almacenamiento en otros datos o que puedan realizar otras operaciones adecuadas.
Los términos "pluralidad" y "una pluralidad", tal como se utilizan en la presente memoria descriptiva, incluyen, por ejemplo, "múltiple" o "dos o más". Por ejemplo, "una pluralidad de artículos" incluye dos o más artículos.
Las referencias a "una realización", "la realización", "realización demostrativa", "varias realizaciones", "algunas reali­ zaciones", y/o términos similares, pueden indicar que la(s) realización(es) descrita(s) de esta manera puede(n) incluir opcionalmente un rasgo, estructura o característica particular, pero no todas las realizaciones incluyen necesariamente el rasgo, estructura o característica particular. Además, el uso repetido de la frase "en una realización" no se refiere necesariamente a la misma realización, aunque puede hacerlo. Del mismo modo, el uso repetido de la frase "en algu­ nas realizaciones" no se refiere necesariamente al mismo conjunto o grupo de realizaciones, aunque puede hacerlo.
Tal como se utiliza en la presente memoria descriptiva, y a menos que se especifique lo contrario, la utilización de adjetivos ordinales tales como "primero", "segundo", "tercero", "cuarto", etc., para describir un elemento o un objeto, simplemente indica que se está haciendo referencia a diferentes instancias de los citados elementos u objetos simila­ res; y no pretende implicar que los elementos u objetos descritos de esa manera deban estar en una secuencia deter­ minada, ya sea temporal, espacial, de clasificación o de cualquier otra forma de ordenación.
Algunas realizaciones pueden usarse en, o junto con, diversos dispositivos y sistemas, por ejemplo, un Ordenador Personal (PC), un ordenador de sobremesa, un ordenador móvil, un ordenador portátil, un ordenador tipo notebook, un ordenador tipo tableta, un ordenador servidor, un ordenador de mano, un dispositivo de mano, un dispositivo Asis­ tente Digital Personal (PDA), un dispositivo PDA de mano, una tableta, un dispositivo incorporado, un dispositivo no incorporado, un dispositivo híbrido, un dispositivo vehicular, un dispositivo no vehicular, un dispositivo móvil o portátil, un dispositivo de consumo, un dispositivo no móvil o no portátil, un aparato, una estación de comunicación inalámbrica, un dispositivo de comunicación inalámbrica, un punto de acceso (PA) inalámbrico, un enrutador o pasarela o conmu­ tador o concentrador por cable o inalámbrico, un módem por cable o inalámbrico, un dispositivo de vídeo, un dispositivo de audio, un dispositivo de audio y vídeo (A/V), una red cableada o inalámbrica, una red de área inalámbrica, una red de área de vídeo inalámbrica (WVAN), una red de área local (LAN), una LAN inalámbrica (WLAN), una red de área personal (PAN), una PAN inalámbrica (WPAN), o similares.
Algunas realizaciones se pueden usar junto con sistemas de radiocomunicación unidireccionales y/o bidireccionales, sistemas de radiocomunicación celular, un teléfono móvil, un teléfono celular, un teléfono inalámbrico, un dispositivo de Sistemas de Comunicación Personal (PCS), un PDA o dispositivo de mano que incorpore capacidades de comuni­ cación inalámbrica, un dispositivo de Sistema de Posicionamiento Global (GPS) móvil o portátil, un dispositivo que incorpore un receptor o transceptor o chip GPS, un dispositivo que incorpore un elemento o chip RFID, un transceptor o dispositivo de Entrada Múltiple y Salida Múltiple (MIMO), un transceptor o dispositivo de Entrada Única y Salida Múltiple (SIMO), un transceptor o dispositivo de Entrada Múltiple y Salida Única (MISO), un dispositivo con una o más antenas internas y/o antenas externas, dispositivos o sistemas de Radiodifusión de Vídeo Digital (DVB), dispositivos o sistemas de radio multiestándar, un dispositivo de mano inalámbrico o con cable, por ejemplo., un teléfono inteli­ gente, un dispositivo de Protocolo de Aplicación Inalámbrica (WAP), o similares.
Algunas realizaciones pueden comprender, o pueden implementarse utilizando, una "app" o aplicación que se puede descargar u obtener de una "app store" o "tienda de aplicaciones", de forma gratuita o de pago, o que puede preins­ talarse en un dispositivo informático o electrónico, o que puede transportarse y/o instalarse de otro modo en el citado dispositivo informático o electrónico.
La presente invención comprende además dispositivos, sistemas y procedimientos para la detección y/o aislamiento y/o prevención y/o mitigación de una "tormenta de señalización" o una "tormenta de señal" o una "tormenta de señales" u otros tipos de ciberataques y/o ataques distribuidos que se realizan sobre el Plano de Control (CP) y/o el Plano de Usuario (UP), particularmente de tales tormentas de señalización o ciberataques que son generados por dispositivos IoT, y particularmente de tales tormentas de señalización o ciberataques en redes móviles 5G.
Los Solicitantes han apreciado que el rápido desarrollo de las redes públicas de comunicación, los servicios digitales y la adopción generalizada de varios tipos de dispositivos "inteligentes" o conectados a Internet, producen nuevos retos y problemas en el campo de la ciberseguridad, y abre nuevos vectores de ataque o superficies de ataque que aún no se han abordado adecuadamente.
Los Solicitantes han apreciado de que una demanda significativa de dispositivos de Internet de las Cosas (IoT), de diferentes suministradores y fabricantes y proveedores, junto con el despliegue o implantación de redes celulares 5G que pueden ser capaces de soportar una densidad muy alta de dispositivos IoT (por ejemplo, hasta un millón de dispositivos IoT por kilómetro cuadrado), pueden requerir que las entidades Proveedoras de Servicios de Comunica­ ción (CSP), así como las entidades que poseen u operan los citados dispositivos IoT, sean capaces de detectar y descubrir (y mitigar) de manera eficiente los riesgos de seguridad y los "agujeros" de seguridad, así como la infección de dispositivos IoT (por ejemplo, por malware, o controlados o utilizados de otro modo por un atacante); y, además, detectar o prevenir o mitigar los ataques de Denegación de Servicio Distribuidos (DDoS o DDOS o D-DoS o DoS distribuidos), en particular los ataques DDoS salientes o de salida que utilizan numerosos dispositivos IoT con capa­ cidad 5G.
Los Solicitantes han apreciado que existe la necesidad de detectar, prevenir y/o mitigar los ataques DDoS, o las tormentas de señalización que se derivan de los citados ataques DDoS o de un lote de dispositivos IoT que funcionan defectuosamente (por ejemplo, debido a una actualización de software o una actualización de firmware defectuosa o errónea o "con errores" que se instaló en miles de dispositivos IoT); en particular, en redes celulares / móviles 5G de diversos tipos, y en vista del creciente número de dispositivos IoT conectados y su alta densidad por área geográfica, lo que convierte a los citados dispositivos IoT en un objetivo deseable para los ciberatacantes y delincuentes y que hace que los citados dispositivos IoT se conviertan en un factor de riesgo tanto para las entidades CSP como para los consumidores.
Los Solicitantes han apreciado además de que los mecanismos de protección convencionales, a lo sumo, pueden funcionar para proteger el propio dispositivo de punto final (p. ej., un programa antivirus o antimalware que escanea periódicamente el dispositivo IoT desde el interior); mientras que la Red de Acceso por Radio y/o la Red Central aún no disfrutan de una protección eficaz frente a ataques salientes. Los Solicitantes han apreciado de que en las redes 5G, un ataque puede sobrecargar excesivamente los elementos de red o los nodos de red ordenando a los dispositivos IoT que generen un Tráfico de Control significativo (y no necesariamente completando la formación de una nueva conexión, y/o no necesariamente transmitiendo un tamaño excesivo de carga útil). Los solicitantes también han apre­ ciado de que, a diferencia de las redes 4G, la capacidad de las redes 5G para aprovechar significativamente la capa­ cidad de la interfaz aérea (por ejemplo, cientos de veces), permite que los dispositivos IoT puedan sobrecargar la red 5G generando mensajes de control de forma aleatoria o pseudoaleatoria, a una velocidad de generación más baja por dispositivo IoT; y los procedimientos de protección convencionales no serían eficaces.
Se hace referencia a la figura 4, que es una ilustración esquemática de un sistema demostrativo 4 en el que pueden implementarse las soluciones de detección y protección de la presente invención.
El sistema 4 comprende varios dispositivos IoT o dispositivos "inteligentes" o dispositivos conectados a Internet o dispositivos conectados a IP o dispositivos con capacidad 5G; por ejemplo, mostrando a efectos demostrativos tres dispositivos 5G 401-403 conectados. Cada uno de estos dispositivos conectados a 5G puede ser, por ejemplo, un dispositivo o electrodoméstico o sensor doméstico inteligente (por ejemplo, una cámara de seguridad o un detector de humo conectados a Internet), un dispositivo o sensor industrial o empresarial conectado a Internet (por ejemplo, una máquina o sensor de fábrica conectado a Internet para enviar informes y/o recibir órdenes a distancia), un coche o vehículo inteligente (por ejemplo, conducido u operado por un ser humano; o por un robot o máquina; o por una unidad de conducción autónoma o autoconducción), un dron inteligente o dispositivo volador o vehículo aéreo no tripulado (UAV) (por ejemplo, controlado u operado a distancia por un ser humano; o por un robot o máquina; o por una unidad voladora autónoma), teléfonos inteligentes, tabletas, relojes inteligentes, consolas de videojuegos, televisores inteli­ gentes, unidades de iluminación interior o exterior inteligentes, equipos agrícolas o de construcción u otra maquinaria inteligente, o similares.
Cada uno de los citados dispositivos 401-403 puede comprender un transceptor de comunicación inalámbrica, tal como un transceptor celular 5G; y puede comunicarse con una Red Central 410 (por ejemplo, una red central celular 5G) directamente o por medio de una Red de Acceso por Radio (RAN) 411; con el fin de comunicarse con, o enviar datos y/o comandos a, o recibir datos y/o comandos de, una o más Entidades Remotas tales como un Receptor Remoto de Datos 421, un Proveedor Remoto de Datos 422, un proveedor de servicios Por Encima (OTT) 423, o similares.
De acuerdo con algunas realizaciones demostrativas de la presente invención, el sistema 4 puede comprender ade­ más: una Unidad Protectora 431; una Sonda de Plano de Usuario (UP) 432; una Sonda de Plano de Control (CP) 433; un subsistema de Gestión de Inventario (IM) 434; y un subsistema de Gestión de Relaciones con Clientes (CRM) 435.
La Unidad Protectora 431 es un elemento de protección activo, que opera para analizar datos monitorizados y/o metadatos, para generar percepciones con respecto a ataques o riesgos de seguridad actuales y/o en curso y/o previstos, y para aplicar o desplegar una política de seguridad adecuada o una política de mitigación de ataques (por ejemplo, seleccionada de un grupo o banco de varias políticas predefinidas). La Unidad Protectora 431 puede recibir datos de la Sonda UP 432 y/o de la Sonda CP 433. La Unidad Protectora 431 puede proporcionar reglas de descarte de tráfico o reglas de modificación de tráfico, a la Sonda UP 432 y/o a la Sonda CP 433, y estas Sondas entonces hacen cumplir o implementan las citadas reglas en el tráfico que pasa a través de ellas.
La Sonda UP 432 es un elemento o unidad activa en línea de monitorización y refuerzo del tráfico, que analiza el tráfico en el Plano de Usuario, y modifica selectivamente y/o descarta selectivamente paquetes en el Plano de Usuario de acuerdo con las reglas de política o directivas que son establecidas por la Unidad Protectora 431. La Sonda UP 432 puede monitorizar, rastrear, contar y/o medir el número y/o la cantidad y/o la frecuencia y/u otras características de uno o más mensajes de control y/o peticiones, por ejemplo, peticiones de Servidor de Nombres de Dominio (DNS), mensajes TCP, mensaje de control de Número de Secuencia (SYN) o mensaje SYN o petición SYN o consulta SYN o paquete SYN, acuse de recibo SYN o SYN-ACK o respuesta SYN o paquete SYN-ACk , mensaje FIN o mensaje de control FIN o paquete FIN (por ejemplo correspondiente al byte final y/o al paquete final) u otra solicitud de finalización de conexión FIN, FIN-ACK o acuse de recibo FIN u otro mensaje de acuse de recibo FIN o mensaje de control de acuse de recibo FIN que indique acuses de recibo de finalización de conexión, otros mensajes de control ACK (acuse de recibo), mensajes ACK selectivos (SACK) que se refieran a paquetes o mensajes en particular que se estén acu­ sando recibo, o similares. La Sonda UP 432 puede contar estos mensajes, por tipo de mensaje y/o en la agregación de tipos, y puede rastrear su número o su cantidad por unidad de tiempo (por ejemplo, por minuto) por dispositivo IoT desde el que se originan y/o por tipo de dispositivo desde el que se originan; y el sistema puede comparar entonces los datos monitorizados con valores umbral o rangos de valores predefinidos, y/o puede realizar procesos de Apren­ dizaje de Máquina (ML) de los citados datos, para determinar que el número (la cantidad) y/o la frecuencia de los citados mensajes de control monitorizados es excesivamente alta y/o irregular y/o anormal y por tanto indica que el dispositivo IoT está infectado y/o está afectado y/o está funcionando defectuosamente.
La Sonda CP 433 es un elemento o unidad activa en línea de monitorización y refuerzo de tráfico, que analiza el tráfico en el Plano de Control (CP), y modifica selectivamente y/o descarta selectivamente paquetes en el Plano de Control de acuerdo con reglas de política o directivas que son establecidas por la Unidad Protectora 431. La Sonda CP 433 puede monitorizar, rastrear, contar y/o medir el número y/o la cantidad y/o la frecuencia y/o otras características de uno o más mensajes y/o peticiones de control, por ejemplo, Peticiones de Conexión RRC (por ejemplo, mensaje de control que se utiliza para solicitar el establecimiento de una conexión de Control de Recursos de Radio (RRC)), Petición de Adjuntar o Mensaje de Control de Adjuntar, Petición de Crear Sesión o Mensaje de Control de Crear Sesión, o similares. La sonda Cp 433 puede contar estos mensajes, por tipo de mensaje y/o en la agregación de tipos, y puede rastrear su número o su cantidad por unidad de tiempo (por ejemplo, por minuto) por dispositivo IoT desde el que se originan y/o por tipo de dispositivo desde el que se originan; y el sistema puede comparar entonces los datos monitorizados con valores umbral o rangos de valores predefinidos, y/o puede realizar procesos de Aprendizaje de Máquina (ML) de los citados datos, con el fin de determinar que el número (la cantidad) y/o la frecuencia de los citados mensajes de control monitorizados es excesivamente alto y/o irregular y/o anormal y por lo tanto indica que el dispo­ sitivo loT está infectado y/o está afectado y/o está funcionando defectuosamente.
Los Solicitantes han apreciado que, en algunas implementaciones, puede no ser suficiente contar los mensajes de control por unidad de tiempo para detener o mitigar eficazmente un ataque DDoS o una tormenta de señalización o un ciberataque de "inundación", particularmente en redes 5G que pueden soportar un número significativo de disposi­ tivos IoT conectados. Por ejemplo, un valor de umbral predefinido que esté asociado a un único dispositivo IoT puede no indicar un ataque, ya que el dispositivo IoT infectado o está afectado puede generar repetidamente tráfico que esté por debajo del valor de umbral, aunque el tráfico acumulado por miles o decenas de miles de tales dispositivos IoT sería perjudicial para la red y constituiría de hecho un ataque DDoS efectivo. Por lo tanto, en algunas implementacio­ nes, los dispositivos IoT y sus patrones de comunicación se monitorizan, rastrean y analizan junto con otras condicio­ nes o restricciones, como la hora del día, el día de la semana, la fecha del mes, el tipo de dispositivo o similares, y los citados datos se correlacionan con el comportamiento de dispositivos IoT vecinos o similares mediante análisis ML, para alcanzar una detección y mitigación eficaces de la citada tormenta de señalización.
Los Solicitantes también han apreciado de que en algunas implementaciones, puede no ser suficiente monitorizar, rastrear, contar y/o analizar de otro modo los datos sobre mensajes de control que pasan por medio del Plano de Usuario (UP) solamente, o que pasan por medio del Plano de Control (CP) solamente; sino que algunas implementa­ ciones pueden detectar y aislar eficazmente una tormenta de señalización monitorizando, rastreando y analizando tanto los mensajes de control que pasan por medio del Plano de Control como los mensajes de control que pasan a través del Plano de Usuario. Por ejemplo, los Solicitantes han apreciado de que un ataque de tormenta de señalización puede penetrar o influir negativamente en la red 5G a través del Plano de Control, generando únicamente mensajes de control a través del Plano de Control sin generar una cantidad significativa de tráfico a través del Plano de Usuario; o, de forma similar, un ataque de tormenta de señalización puede penetrar o influir negativamente en la red 5G sobre el Plano de Usuario, generando mensajes que parecen cumplir con el flujo estándar o regular sobre el Plano de Con­ trol; ya que tales ciberataques pueden configurarse en función de la identidad del objetivo que el atacante desea atacar, como, por ejemplo, el Plano de Control, el Plano de Usuario (el Plano de Datos), tanto el CP como el UP, o una entidad víctima objetivo que se encuentra fuera de la red. Por consiguiente, realizado por los Solicitantes, la monitorización del tráfico tanto de CP como de UP puede permitir una detección y mitigación mejores y más eficaces de tales ciberataques.
El subsistema IM 434 almacena datos que la Unidad Protectora 431 puede recuperar u obtener o consultar; por ejem­ plo, indicando a la Unidad Protectora 431 el tipo o grupo de un dispositivo examinado o un dispositivo IoT supervisado, basándose en su número de Identidad Internacional de Abonado Móvil (IMSI) y/o basándose en otro identificador único del dispositivo IoT cuyo tráfico y/o cuyo comportamiento de comunicación está siendo supervisado, inspeccionado y/o analizado.
El subsistema CRM 435 almacena datos que la Unidad Protectora 431 puede recuperar u obtener o consultar; por ejemplo, indicando a la Unidad Protectora 431 los datos asociados con la cuenta IoT o la cuenta de abonado de un dispositivo IoT en particular que se supervisa, así como los datos de contacto pertinentes (por ejemplo, dirección de correo electrónico, número de teléfono) de un punto focal de contacto relevante del citado dispositivo IoT (por ejemplo, con el fin de alertar al citado destinatario sobre un riesgo actualmente detectado o un ataque actual, o sobre una operación de mitigación actual que se está desplegando).
El Sistema 4, y en particular su Unidad Protectora 431 y sus Sondas 432-433, pueden configurarse para detectar y/o mitigar una "Tormenta de Señalización", que es un tipo particular de ataque DDoS. Por ejemplo, la tormenta de seña­ lización puede ser generada por cualquier tipo de dispositivos IoT o anfitriones conectados, y puede caracterizarse por un número anormalmente grande de paquetes de control por unidad de tiempo (por ejemplo, por segundo o por minuto). La tormenta de señalización que el sistema 4 puede detectar y/o mitigar, puede ser un ataque que intenta sobrecargar la Interfaz Aérea y/o la(s) Función(es) de la Red Central que son responsables del procesamiento de los flujos de control.
Los Solicitantes han apreciado de que en algunos escenarios, cuando un único dispositivo IoT transmite mensajes de control de forma permanente (por ejemplo, causando continuamente el reinicio del anfitrión), la RAN puede ser capaz de detectar la citada actividad de comunicación anormal del dispositivo IoT y puede ser capaz de ponerlo en cuaren­ tena, deshabilitando así los servicios de comunicación para el citado dispositivo IoT atacante. Sin embargo, los Solici­ tantes han apreciado de que en una RAN de una red celular 5G, en vista de la alta densidad de dispositivos IoT conectados, un solo dispositivo IoT puede ser capaz de generar un número relativamente menor de mensajes con frecuencia variable por unidad de tiempo; y los procedimientos de protección convencionales que se implementan en la RAN de redes 4G / LTE no son eficaces para tales escenarios 5G.
Por ejemplo, los Solicitantes han apreciado de que un dispositivo IoT atacante en una red 5G, puede aprovechar el hecho de que un dispositivo IoT de Banda Estrecha (NB) puede transmitir datos (por ejemplo, datos no IP, paquetes no IP) como parte de Mensajes de Control sin utilización de recursos UP. Por lo tanto, los solicitantes han apreciado, una entidad atacante puede formar o construir una tormenta de señalización 5G simulando un intercambio de comu­ nicaciones IoT normal o regular, y no se detectaría convencionalmente ninguna anomalía o actividad de comunicación anormal en la UP. Por consiguiente, como han apreciado los Solicitantes, una sonda UP convencional no detectaría actividad maliciosa, y los datos recogidos por una sonda UP convencional no pueden correlacionarse con contadores CP para el reconocimiento de ataques y para el aislamiento o cuarentena de anfitriones sospechosos.
El sistema 4 opera, e implementa procedimientos, para detectar y mitigar ataques que se realizan en el CP de redes móviles, y particularmente en el CP de una red celular 5G o una red 5G New Radio (NR). El citado ataque puede ser, por ejemplo, el resultado de una infección intencionada de dispositivos IoT con fines de ataque DDoS intencionado, o puede ser el resultado de un "error" o error no intencionado en un código de programa (por ejemplo, original, o actua­ lizado, o parcheado, o mejorado) o componente de software o componente de firmware del citado dispositivo IoT. El sistema 4 aprovecha y utiliza el hecho de que cada uno de los dispositivos IoT supervisados (o, en algunas realizacio­ nes, cada clase o tipo de dispositivos IoT) está preclasificado o preasociado con un perfil de dispositivo IoT corres­ pondiente (y, normalmente, de confianza) que se almacena en una base de datos (por ejemplo, la unidad IM y la unidad CRM) accesible por la Unidad Protectora 431, que puede buscar u obtener datos sobre cada uno de los citados dispositivos IoT o, al menos, sobre el tipo o clase de dispositivos IoT a los que pertenece un dispositivo IoT en parti­ cular.
El Perfil pre-almacenado, que está asociado con un dispositivo IoT, o (en algunas implementaciones) está asociado con un Tipo o un Grupo o un Lote de dispositivos IoT (por ejemplo, hechos por el mismo fabricante; o vendidos por el mismo proveedor; o mantenidos y soportados por el mismo proveedor o CSP; o poseídos u operados por la misma entidad cliente; o agrupados o en clúster de otra manera), puede comprender, por ejemplo, los siguientes parámetros o campos o registros: (a) identificador o indicador del tipo de dispositivo (por ejemplo, "cámara de seguridad", "puerta de enlace IoT", "detector de humos", "televisor inteligente" o "máquina expendedora"); b) identificador del fabricante (por ejemplo, "fabricante A" o "fabricante B") y, opcionalmente, un número de modelo (por ejemplo, "modelo 123" o "modelo 456"); c) número de conexiones (por ejemplo, acumulativas, y no necesariamente simultáneas), por unidad de tiempo (por ejemplo, por segundo, por minuto o por hora) que el dispositivo de IO puede (o se espera que pueda) crear o mantener o solicitar o emplear durante la citada unidad de tiempo (por ejemplo, hasta 4 conexiones por minuto); d) frecuencia máxima permitida o esperada de las transmisiones (por ejemplo, hasta 8 transmisiones por minuto, a través de todas las conexiones); (e) tamaño máximo permitido o esperado de la carga útil (por ejemplo, en bytes; por transmisión única; o, por lote o grupo de transmisiones; o, por unidad de tiempo); (f) lista de uno o más destinos o destinatarios remotos (por ejemplo, identificados por su dirección IP o su dirección MAC o por dirección DNS o por URL o URI u otro localizador de recursos) con los que el dispositivo IoT tiene permitido o autorizado comunicarse; g) opcionalmente, otros datos o metadatos adecuados sobre el dispositivo IoT en particular (por ejemplo, tipo y versión del sistema operativo (SO); fecha o versión de la última actualización o parche del SO; fecha o versión o identificador(es) de la(s) aplicación(es) que se ejecutan en el dispositivo IoT o que están instaladas en el dispositivo IoT; o similares).
El Sistema 4, y los procedimientos y dispositivos de la presente invención, pueden operar en conjunto con varios tipos de despliegue 5G, y particularmente en aquellos en los que se proporcionan servicios de conectividad móvil sobre 5G New Radio (NR); e incluyendo, por ejemplo, dos tipos de escenario operativo. En un primer tipo de escenario operativo, la red 5G NR está controlada por (o es servida o atendida o implementada por) una red central 4G, por ejemplo, utilizando un Núcleo de Paquetes Evolucionado (EPC). En un segundo tipo de escenario operativo, la red 5G Nr está controlada por (o es servida o atendida o implementada por) una red central 5G (5GC), es decir, sin depender de (o utilizar) una red central 4G.
Se hace referencia a la figura 5, que es una ilustración esquemática de la Unidad Protectora 431 y sus componentes, así como sus interfaces con la(s) red(es) móvil(es), de acuerdo con algunas realizaciones demostrativas de la presente invención. La Unidad Protectora 431 realiza el procesamiento de datos y la aplicación de políticas en tiempo real o casi real, por ejemplo, inmediatamente después de la detección de una sesión de comunicación o un paquete que se determina que está asociado con un dispositivo IoT atacante o con un dispositivo IoT que está funcionando defectuo­ samente. Se hace notar que, a efectos demostrativos, la RAN y la Red Central 5G se muestran como interconectadas con (o, proporcionando datos a) la Unidad Protectora 431; pero aunque todos aparecen dentro de la misma caja rectangular de la Unidad Protectora 431, por supuesto, la Unidad Protectora 431 no incluye realmente en su interior la totalidad de la RAN o de la Red Central 5G, sino que la Unidad Protectora 431 recupera u obtiene o extrae de ellas (o de sus interfaces, o de sus elementos de red) los datos pertinentes que la Unidad Protectora 431 utiliza a continuación para el análisis, la selección de políticas o la selección de reglas, y la aplicación de reglas.
Una Unidad de Sonda / Contador 451 de la Unidad Protectora 431 puede ser implementada o realizada como un dispositivo físico o unidad basada en hardware, o como una sonda de red virtual o sonda de red basada en la nube; o como una función de Red Central tal como, en el segundo tipo de escenarios, en el que la Unidad Protectora 431 puede suscribirse para Eventos y Contadores en Servicios 5GC, tales como Función de Gestión de Acceso y Movilidad (AMF), Función de Análisis de Datos de Red (NWDAF), o similares). La Unidad de Sonda / Contador 451 cuenta los mensajes durante ventanas temporales predefinidas, que se originan desde (o que proceden de) cualquier IMSI, o que se originan desde (o que proceden de) una IMSI particular o específica (o, un conjunto o grupo particular de números IMSI). Además, la Unidad de Sonda / Contador 451 se implementa como un elemento en línea, y de acuerdo con las directivas o reglas recibidas del Motor de Reglas (RE) del Protector (que se ha discutido en la presente memoria descriptiva), la Unidad de Sonda / Contador 451 puede descartar selectivamente los mensajes de solicitud que se originaron en (o que son entrantes desde) un anfitrión en cuarentena o un dispositivo IoT en cuarentena, y/o puede hacer que tales paquetes entrantes sean descartados y no sean reenviados o retransmitidos o transferidos de otra manera a su destino previsto.
Una Base de Datos 452 de Dispositivos IoT Infectados / que Funcionan Defectuosamente puede almacenar datos que reflejen, en tiempo real o en tiempo casi real, los valores IMSI o números IMSI o cadenas IMSI que corresponden a dispositivos IoT que actualmente se estima que están (o, se determina que están) infectados y/o está afectados y/o atacando y/o funcionando defectuosamente (por ejemplo, de manera que se produzcan comunicaciones anómalas); y almacenando además en la citada Base de Datos 452 los perfiles de dispositivos IoT pertinentes para los citados dispositivos, y las reglas que reflejan la política del CSP para el aislamiento de dispositivos IoT infectados o que funcionan defectuosamente (por ejemplo, en general, o de un tipo particular de dispositivos IoT).
Un Motor de Aprendizaje de Máquina (ML) 453 recolecta y analiza los contadores y disparadores (por ejemplo, Alarmas de Cruce de Umbral), que son recibidos desde la Unidad de Sonda / Contador 452; y genera y provee Automatización de Ciclo Cerrado aplicando acciones basadas en políticas para prevenir o mitigar el impacto adverso del servicio. En algunas realizaciones, basándose en la configuración deseada y en las fuentes de datos disponibles, la Unidad Pro­ tectora 431 puede aislar los ataques de forma proactiva y/o automática y/o autónoma, inmediatamente después de la detección de un dispositivo IoT afectado o en defectuosamente funcionamiento; para minimizar de esta manera el impacto adverso en los servicios, y/o para prevenir los ataques de forma predictiva y eliminar o reducir el potencial impacto negativo.
El Motor ML 453 comprende dos unidades: una Unidad de Predicción 454, y un Motor de Reglas (RE) 455. La Unidad de Predicción 454 ejecuta los datos recibidos por medio de uno o más modelos ML. Cada uno de estos modelos de ML puede basarse en un algoritmo de ML adecuado, por ejemplo, regresión logística, Naive Bayes, Máquinas de Vectores de Soporte, Árboles de Decisión, Árboles Potenciados, Bosque Aleatorio, Vecino Más Próximo u otros pro­ cedimientos de ML adecuados o procedimientos de inteligencia artificial (IA) o procedimientos de aprendizaje profundo.
En algunas realizaciones, la predicción se lleva a cabo con respecto a un gran número de dispositivos IoT conectados, con varios perfiles diferentes y en tiempo real; y por lo tanto, los procedimientos Bosque Aleatorio pueden ser adecua­ dos para la tarea, proporcionando un mejor rendimiento y/o una precisión adecuada.
En una realización demostrativa, la Predicción se calcula como:
Figure imgf000022_0001
en la que X = {xi,... Xn) es un conjunto de entrenamiento. Cada xi es una función (por ejemplo, característica) de la desviación de los contravalores de los contadores de los correspondientes valores de funcionamiento normal definidos en el perfil y los eventos / disparadores. Por ejemplo, el perfil define valores de funcionamiento normal como par de límites bajo y alto. El mismo parámetro puede tener diferentes pares de valores, dependiendo del día de la semana y de la hora del día, o basándose en otras variables (por ejemplo, ser un día festivo nacional en el que las operaciones comerciales están cerradas). En una realización demostrativa, cada característica tiene 3 valores posibles, que se denotan en la presente memoria descriptiva como "rojo" o "amarillo" o "verde":
x = {"Verde", "Amarillo", "Rojo"}
en el que "Verde" indica que no se ha detectado ninguna anomalía o irregularidad; "Amarillo" indica que se ha detec­ tado una anomalía o irregularidad de bajo nivel o menores, y por lo tanto puede requerir atención (por ejemplo, el dispositivo IoT presenta un número de conexiones o transmisiones o un tamaño de carga útil que no supera en más de un N por ciento su límite autorizado predefinido; por ejemplo, N es 5 o 12 u otro valor adecuado); "Rojo" indica que se ha detectado una anomalía o irregularidad importante o de alto nivel y que es necesario prestar atención (por ejemplo, el dispositivo IoT presenta un número de conexiones o transmisiones o un tamaño de carga útil que supera en un N por ciento o más su límite autorizado predefinido).
Otros parámetros de la fórmula de predicción antes mencionada son:
Y = {yi, .. yn} indica un conjunto de respuestas;
x ' indica una muestra recibida que debe ser procesada;
W (Xi, x') indica la función de peso no negativo del punto de entrenamiento x¡ en relación con el nuevo punto x' en el mismo árbol;
m indica el número de árboles;
n indica el número de puntos de entrenamiento.
El Motor de Reglas (RE) ejecuta los datos de Predicción recibidos por medio de su propio modelo ML. Aunque el Modelo de Reglas puede utilizar uno o más modelos ML adecuados, algunas realizaciones pueden implementar Bos­ que Aleatorio para lograr mejores resultados y/o un mejor rendimiento. En una realización demostrativa, las caracte­ rísticas del motor de reglas son funciones de los siguientes parámetros:
Predicción - valor recibido del Predictor;
Estado del dispositivo : servicio desactivado o servicio activado;
Tiempo transcurrido desde el último cambio de estado;
Ubicación : señala el segmento de red pertinente en el que se encuentra el dispositivo IoT;
Número de dispositivos infectados del mismo tipo;
KPIs : indicadores clave de rendimiento que reflejan la carga de la red y/o la carga de los segmentos de red;
Tipo de dispositivo;
Día de la semana y hora del día.
Como resultado de la citada ejecución de los valores de predicción por medio del modelo ML del Motor de Reglas, el Motor de Reglas selecciona una única regla, o una secuencia o lote o grupo de reglas, para ser ejecutada o aplicada con respecto al tráfico o paquetes del dispositivo IoT relevante.
Se hace referencia a la figura 6A, que es una ilustración esquemática de un sistema 601, demostrando la integración de unidades de la presente invención en una red 5G NR controlada por EPC, o en una red 5G No Autónoma (NSA). Por ejemplo, una sonda de señalización que se comunica con la Unidad Protectora 431 puede colocarse o localizarse en el Punto 611 (por ejemplo, en implementaciones Open RAN), y/o en el Punto 612, y/o en el Punto 613. La sonda de señalización cuenta los siguientes mensajes de control por Equipo de Usuario (UE) o por IMSI: si está situada en el punto 611, cuenta las Solicitudes de Conexión de Control de Recursos por Radios (RRC); si está situada en el punto 612, cuenta las Solicitudes de Conexión; si está situada en el punto 613, cuenta las Solicitudes de Creación de Sesión.
Con el fin de suspender los servicios de comunicación para un UE o dispositivo IoT específico, tras la detección de un ataque (o tras la detección de un funcionamiento defectuoso de un dispositivo IoT), la Unidad Protectora puede actua­ lizar los registros relacionados con el UE o los registros relacionados con el dispositivo en el Servidor de Abonado Doméstico (HSS) y/o en el Registro de Identidad de Equipo (EIR) (por ejemplo, simulando o emulando una tarjeta SIM robada, o marcando el registro de ese dispositivo IoT como si su tarjeta SIM hubiera sido robada), opcionalmente utilizando una Interfaz de Programación de Aplicaciones (API) RESTful, o creando archivos de datos adecuados (por ejemplo, un archivo CSV, un archivo XML, un archivo TXT, o similares) y cargándolos después en estas funciones de red para procesarlos allí como unidades SIM robadas y/o como indicadores de que se requiere la suspensión del servicio. Adicional o alternativamente, y en particular cuando no está disponible la interacción ni con el h Ss ni con el EIR (por ejemplo, temporal o permanentemente), la Unidad Protectora puede ordenar a la sonda de señalización que descarte todos los paquetes o todos los mensajes entrantes desde el UE infectado, y/o que descarte selectivamente paquetes o mensajes que cumplan criterios predefinidos (por ejemplo, descartar cualquier mensaje cuya carga útil sea superior a N bytes; o, descartar cualquier mensaje que se reciba del dispositivo IoT entre las 14: y las 16:; o, descartar cualquier mensaje que se reciba del dispositivo IoT y que tenga un destinatario o destino en particular).
Se hace referencia a la figura 6B, que es una ilustración esquemática de un sistema 621, demostrando la integración de unidades de la presente invención en una red 5G Autónoma (SA). Puesto que la Red Básica 5G define interfaces hacia cualquiera de sus funciones, la Unidad Protectora puede comunicarse directamente con las funciones pertinen­ tes de la Red Básica 5G para recopilar contadores y KPI, y para garantizar la aplicación de la política y las normas. En algunas redes 5G, cualquier modificación o aplicación de políticas debe pasar por una Función de Control de Políticas (PCF). En consecuencia, una sonda de señalización puede conectarse en el Punto 631 sólo si la RAN se implementa de acuerdo con la arquitectura Open RAN.
Con el fin de suspender los servicios de comunicación para un UE o dispositivo IoT específico tras la detección de un ataque (o, tras la detección de un funcionamiento defectuoso del dispositivo IoT), el Protector actualiza las políticas en el PCF; por ejemplo, creando un nuevo Descriptor de Filtro de Paquetes y conectándolo a una Política de Suspen­ sión de Servicios; asociando entre una IMSI que está siendo suspendida y una política de Lista Negra; o similares.
De manera similar a la arquitectura 5G NSA que se ha descrito más arriba, la Unidad Protectora puede instruir a la sonda de señalización en el Punto 631 para descartar todos los paquetes o todos los mensajes, o para descartar selectivamente paquetes o mensajes basados en criterios o reglas predefinidas; sin embargo, en algunas realizacio­ nes, tal flujo puede no ser nativo para redes 5G SA, y operaciones de aplicación similares (por ejemplo, descarte completo de paquetes o mensajes, o descarte selectivo basado en criterios) deberían ser gestionadas típicamente por (o pasadas a través de) el PCF de la red 5G SA.
Se hace referencia a la figura 7, que es una ilustración esquemática de un sistema 7, demostrando el despliegue o integración de unidades de la presente invención en una red de comunicación celular Open RAN. La mayoría de los componentes mostrados en el sistema 7 son componentes convencionales; sin embargo, de acuerdo con la presente invención, se implementa una Unidad Protectora / Sonda de Señalización 701 en la Capa de Aplicación 704 del Con­ trolador de Inteligencia RAN (RIC) casi en Tiempo Real 705; y se interconecta con la unidad de Gestión de Conexión de Radio 702 y con la Base de Información de Radio-Red 703.
Por ejemplo, la Unidad Protectora puede utilizar una o más sondas de señalización, que pueden operar o interoperar con dos componentes en tiempo no real (Non-RT) o en tiempo casi real (Near-RT) del controlador de inteligencia RAN (RIC) por medio de una API RESTful: el Gestor de Conexión de Radio y la Base de Información de la Red de Radio ; la Unidad Protectora y/o sus sondas asociadas pueden obtener de esta manera mediciones operativas y contadores de conexiones, y pueden utilizar estos componentes para hacer cumplir la suspensión del servicio para dispositivos IoT que tengan valores IMSI sospechosos (por ejemplo, dispositivos IoT infectados, afectados, que atacan, que fun­ cionan defectuosamente).
Algunas realizaciones pueden comprender un sistema para detectar y mitigar una tormenta de señalización 5G gene­ rada por uno o más dispositivos con capacidad 5G. Por ejemplo, el sistema comprende una sonda de señales del Plano de Control (CP), conectada en línea a un primer nodo de red situado entre una Red de Acceso por Radio (RAN) y una Red Básica 5G, para monitorizar los mensajes de control del Plano de Control originados por los dispositivos con capacidad 5G y que pasan por el primer nodo de red; una sonda de señales del Plano de Usuario (UP), conectada en línea a un segundo nodo de red situado entre la Red Básica 5G y una o más entidades remotas a las que los dispositivos con capacidad 5G envían mensajes, para monitorizar los mensajes de control del plano de usuario que pasan por el segundo nodo de red; un subsistema de Gestión de Inventario (IM), para almacenar los datos de corre­ lación entre un determinado dispositivo con capacidad 5G y un número de Identidad Internacional de Abonado Móvil (IMSI) que se le haya asignado; y, una Unidad Protectora, configurada (A) para recibir (i) los datos recogidos por la sonda de señal CP, y (ii) los datos recogidos por la sonda de señal UP, y (iii) un subconjunto de números IMSi del subsistema IM, y (B) para generar una lista de dispositivos 5G particulares que se detecta que están afectados o funcionan defectuosamente, y (C) para activar la puesta en cuarentena de los mensajes de control salientes de los citados dispositivos 5G particulares que están en la citada lista.
En algunas realizaciones, la Unidad Protectora debe realizar un análisis de (i) los datos recogidos por la sonda de señal del Plano de Control y (ii) los datos recogidos por la sonda de señal del Plano de Usuario, y basándose en el citado análisis, generar una determinación de que un determinado dispositivo con capacidad 5G está afectado o está funcionando defectuosamente.
En algunas realizaciones, la Unidad Protectora debe seleccionar una política de protección particular, de entre un conjunto de políticas de protección predefinidas, basándose en una o más características del citado dispositivo 5G particular.
En algunas realizaciones, basándose en la citada política de protección particular, la Unidad Protectora debe configurar dinámicamente la sonda de señal del Plano de Control para descartar en el primer nodo de red todos los mensajes de control salientes procedentes del citado dispositivo 5G particular.
En algunas realizaciones, basándose en la citada política de protección particular, la Unidad Protectora debe configurar dinámicamente la sonda de señal del Plano de Usuario, para descartar en el segundo nodo de red todos los mensajes de control salientes que salen del citado dispositivo capaz de 5G particular.
En algunas realizaciones, basándose en la citada política de protección particular, la Unidad Protectora debe configurar dinámicamente la sonda de señal del Plano de Control, para descartar selectivamente en el primer nodo de red sólo los mensajes de control salientes que son enviados desde el citado dispositivo particular capaz de 5G a un destino particular.
En algunas realizaciones, basándose en la citada política de protección particular, la Unidad Protectora debe configurar dinámicamente la sonda de señal del Plano de Usuario, para descartar selectivamente en el segundo nodo de red sólo los mensajes de control salientes que son enviados desde el citado dispositivo particular capaz de 5G a un destino particular.
En algunas realizaciones, la Unidad Protectora debe realizar un análisis de Aprendizaje de Máquina de (i) los datos recogidos por la sonda de señal del Plano de Control y (ii) los datos recogidos por la sonda de señal del Plano de Usuario, y basándose en el citado análisis de Aprendizaje de Máquina, generar una determinación de que un disposi­ tivo 5G en particular está afectado o está funcionando defectuosamente. En algunas realizaciones, el citado análisis de Aprendizaje de Máquina comprende al menos un análisis de Bosque Aleatorio de (i) los datos recogidos por la sonda de señal del Plano de Control y (ii) los datos recogidos por la sonda de señal del plano de usuario.
En algunas realizaciones, en el citado análisis de Bosque Aleatorio, cada punto es una característica de desviación de los contadores del correspondiente rango de valores predefinido de funcionamiento normal representado como un par de valor mínimo y valor máximo.
En algunas realizaciones, en el citado análisis de Bosque Aleatorio, a cada punto se le asigna un valor que corresponde a (i) un indicador de comunicaciones regulares por el dispositivo con capacidad 5G, o (ii) un indicador de anomalía menor que está por debajo de un valor umbral predefinido de comunicaciones anormales, o (iii) un indicador de ano­ malía mayor que es igual o mayor que el citado valor umbral predefinido de comunicaciones anormales.
En algunas realizaciones, la Unidad Protectora debe realizar un análisis de Aprendizaje de Máquina de (i) valores de contadores de mensajes por unidad de tiempo por número IMSI, y (ii) un Perfil de Dispositivo predefinido que indica un rango normal para el número de mensajes de control que un dispositivo 5G particular está autorizado a enviar por unidad de tiempo; y basándose en el citado análisis de Aprendizaje de Máquina, generar una determinación de que un dispositivo 5G particular está afectado o está funcionando defectuosamente. En algunas realizaciones, la Unidad Protectora debe llevar a cabo un análisis de Bosque Aleatorio de (i) los valores de los contadores de mensajes por unidad de tiempo por número IMSI, y (ii) un perfil de dispositivo predefinido que indica un rango normal para el número de mensajes de control que un dispositivo con capacidad 5G en particular está autorizado a enviar por unidad de tiempo; y basándose en el citado análisis de Bosque Aleatorio, generar una determinación de que un dispositivo con capacidad 5G en particular está afectado o está funcionando defectuosamente.
En algunas realizaciones, tras la detección de que un dispositivo 5G en particular está afectado o está funcionando defectuosamente, la Unidad Protectora realiza un análisis de Aprendizaje de Máquina para seleccionar una o más reglas de política que se aplicarán a los mensajes de control salientes del citado dispositivo 5G en particular.
En algunas realizaciones, tras la detección de que un dispositivo 5G en particular está afectado o está funcionando defectuosamente, la Unidad Protectora realiza un análisis de Bosque Aleatorio para seleccionar una o más reglas de política que se aplicarán a los mensajes de control salientes del citado dispositivo 5G en particular.
En algunas realizaciones, el citado análisis de Bosque Aleatorio utiliza al menos dos de las siguientes características: un indicador de si el dispositivo 5G en particular muestra una anomalía menor o una anomalía mayor en las comuni­ caciones; un indicador de un segmento de red en el que se encuentra el citado dispositivo 5G en particular; un indicador de carga de red, que representa la carga de red por medio de un segmento de red en particular; un número que indica cuántos dispositivos 5G del mismo tipo que el citado dispositivo 5G en particular están afectados o funcionan defec­ tuosamente.
En algunas realizaciones, la Unidad Protectora está conectada a un nodo de red particular, y monitoriza las señales de control salientes que pasan por medio del citado nodo de red particular, y produce el descarte selectivo de los mensajes de control que pasan a través del citado nodo de red particular; en el que el citado nodo de red particular es un NodoB de Nueva Generación (gNB) y es anterior a una interfaz Xn.
En algunas realizaciones, la Unidad Protectora está conectada a un nodo de red particular, y monitoriza las señales de control salientes que pasan a través del citado nodo de red particular, y produce el descarte selectivo de mensajes de control que pasan a través del citado nodo de red particular; en el que el citado nodo de red particular está localizado entre un NodoB de Nueva Generación (gNB) y una Entidad de Gestión de Movilidad (MME).
En algunas realizaciones, la Unidad Protectora está conectada a un nodo de red particular, y monitoriza las señales de control salientes que pasan a través del citado nodo de red particular, y produce el descarte selectivo de mensajes de control que pasan a través del citado nodo de red particular; en en el que el citado nodo de red particular está localizado entre una Entidad de Gestión de Movilidad (MME) y una Función de Plano de Control de Pasarela de Servicio (S-GW-C).
En algunas realizaciones, la Unidad Protectora activa la cuarentena total o la cuarentena selectiva de los mensajes de control salientes de un dispositivo 5G particular, modificando dinámicamente un registro asociado con el citado dispo­ sitivo 5G particular, en al menos uno de entre: un Servidor de Subscriptor Doméstico (HSS), un Registro de Identidad de Equipo) (EIR); en el que el citado registro es modificado por la Unidad Protectora para indicar que una tarjeta SIM del citado dispositivo capaz de 5G fue robada; en el que el citado registro, una vez modificado por la Unidad Protectora, causa la suspensión de los servicios de comunicación celular al citado dispositivo capaz de 5G en particular.
En algunas realizaciones, la Unidad Protectora está conectada a un nodo de red particular, y monitoriza las señales de control salientes que pasan a través del citado nodo de red particular, y causa el descarte selectivo de mensajes de control que pasan a través del citado nodo de red particular; en en el que el citado nodo de red particular está localizado entre una Entidad de Gestión de Movilidad (MME) y una Función de Plano de Control de Pasarela de Servicio (S-GW-C).
En algunas realizaciones, la Red de Acceso por Radio (RAN) es una RAN Abierta (O-RAN); en la que la Unidad Protectora se implementa en una Capa de Aplicación de un Controlador de Inteligencia RAN (RIC) casi en Tiempo Real; en la que la Unidad Protectora opera mediante interfaz con una unidad de Gestión de Conexión por Radio y con una Base de Información de Red por Radio de la citada RAN Abierta.
En algunas realizaciones, la sonda de señal del Plano de Usuario (UP) realiza la monitorización del Plano de Usuario de al menos: Mensajes SYN, mensajes SYN-ACK, mensajes FIN, mensajes FIN-ACK, mensajes ACK y mensajes Selective ACK (SACK); la sonda de señal del Plano de Control (CP) realiza la monitorización del Plano de Control de al menos: Peticiones de Conexión RRC, Unir Peticiones, Crear Peticiones de Sesión; y la Unidad Protectora determina que un dispositivo IoT en particular está en peligro o está funcionando defectuosamente, basándose en el análisis de Aprendizaje de Máquina (ML) tanto de i) los mensajes de control supervisados por la sonda de señal UP en el plano de usuario, como de ii) los mensajes de control supervisados por la sonda de señal CP en el Plano de Control.
Algunas realizaciones incluyen un procedimiento para detectar y mitigar una tormenta de señalización 5G generada por uno o más dispositivos con capacidad 5G. El procedimiento comprende: en una sonda de señales del Plano de Control (CP), conectada en línea a un primer nodo de red situado entre una Red de Acceso por Radio (RAN) y una Red Básica 5G, monitorizar los mensajes de control del Plano de Control originados por los dispositivos con capacidad 5G y que pasan por el primer nodo de red; en una sonda de señales del plano de usuario (UP), conectada en línea a un segundo nodo de red situado entre la Red Básica 5G y una o más entidades remotas a las que los dispositivos con capacidad 5G envían mensajes, monitorizar los mensajes de control del plano de usuario que pasan por el segundo nodo de red; en un subsistema de gestión de inventario (IM), almacenar datos que correlacionen un determinado dispositivo con capacidad 5G y un número de Identidad Internacional de Abonado Móvil (IMSI) que se le haya asig­ nado; en una Unidad Protectora, (A) recibir (i) los datos recogidos por la sonda de señal CP, y (ii) los datos recogidos por la sonda de señal UP, y (iii) un subconjunto de números IMSI del subsistema IM, y (B) generar una lista de dispo­ sitivos 5G particulares que se detecte que están afectados o funcionan defectuosamente, y (C) activar la puesta en cuarentena de los mensajes de control salientes de los citados dispositivos 5G particulares que estén en la citada lista.
Las funciones, operaciones, componentes y/o características descritas en la presente memoria descriptiva con refe­ rencia a una o más realizaciones de la presente invención, pueden combinarse con, o pueden utilizarse en combina­ ción con, una o más funciones, operaciones, componentes y/o características descritas en la presente memoria des­ criptiva con referencia a una o más realizaciones de la presente invención. De esta manera, la presente invención puede comprender cualquier combinación posible o adecuada, reordenación, montaje, remontaje, u otra utilización de algunos o todos los módulos o funciones o componentes que se describen en la presente memoria descriptiva, incluso si se explican en diferentes lugares o diferentes capítulos de la explicación anterior, o incluso si se muestran por medio de diferentes dibujos o múltiples dibujos.

Claims (15)

REIVINDICACIONES
1. Un sistema (4) para detectar y mitigar una tormenta de señalización 5G generada por uno o más dispositivos con capacidad 5G (401,402, 403), comprendiendo el sistema (4):
una sonda de señal de Plano de Control (CP) (433), conectada en línea a un primer nodo de red situado entre una Red de Acceso por Radio (RAN) (411) y una Red Central 5G (410), para monitorizar los mensajes de control del Plano de Control originados por los dispositivos aptos para 5G (401,402, 403) y que pasan por el primer nodo de red;
una sonda de señal de Plano de Usuario (UP) (432), conectada en línea en un segundo nodo de red situado entre la Red Central 5G (410) y una o más entidades remotas (421) a las que los dispositivos con capacidad 5G están enviando mensajes, para monitorizar los mensajes de control del Plano de Usuario que pasan por medio del segundo nodo de red;
un subsistema de Gestión de Inventario (IM) (434), para almacenar datos correlacionados entre un determi­ nado dispositivo con capacidad 5G (401, 402, 403) y un número de Identidad Internacional de Abonado Móvil (IMSI) asignado al mismo;
una Unidad Protectora (431) configurada (A) para recibir (i) datos recogidos por la sonda de señal CP (433), y (ii) datos recogidos por la sonda de señal UP (432), y (iii) un subconjunto de números IMSI del subsistema IM (434), y (B) generar una lista de dispositivos particulares con capacidad 5G (401,402, 403) que se detecta que están afectados o funcionan defectuosamente, y (C) activar la cuarentena de mensajes de control sa­ lientes de los citados dispositivos particulares con capacidad 5G (401,402, 403) que están en la citada lista;
caracterizado por que la Unidad Protectora (431) está configurada para realizar análisis de Aprendizaje de Máquina de (i) los datos recogidos por la sonda de señal del Plano de Control (433) y (ii) los datos recogidos por la sonda de señal del plano de usuario (432), y para generar, basándose en el citado análisis de Apren­ dizaje de Máquina, una determinación de que un dispositivo con capacidad 5G en particular (401, 402, 403) está afectado o está funcionando defectuosamente;
el citado análisis de Aprendizaje de Máquina comprende al menos un análisis de Bosque Aleatorio de (i) los datos recogidos por la sonda de señal del Plano de Control (433) y (ii) los datos recogidos por la sonda de señal del Plano de Usuario (432);
en el que, en el citado análisis de Bosque Aleatorio, cada punto es una característica de desviación de los contadores del correspondiente intervalo de valores predefinido de funcionamiento normal representado como un par de valor mínimo y valor máximo, y a cada punto se le asigna un valor que corresponde a (i) un indicador de comunicaciones regulares por parte del dispositivo con capacidad 5G (401, 402, 403), o (ii) un indicador de anomalía menor que está por debajo de un valor umbral predefinido de comunicaciones anor­ males, o (iii) un indicador de anomalía mayor que es igual o mayor que el citado valor umbral predefinido de comunicaciones anormales.
2. El sistema (4) de la reivindicación 1,
en el que la Unidad Protectora (431) debe realizar un análisis de (i) los datos recogidos por la sonda de señal del Plano de Control (433) y (ii) los datos recogidos por la sonda de señal del plano de usuario (432), y basándose en el citado análisis, generar una determinación de que un determinado dispositivo con capacidad 5G (401, 402, 403) está afectado o funciona incorrectamente;
en el que la Unidad Protectora (431) debe seleccionar una política de protección particular de entre un con­ junto de políticas de protección predefinidas, basándose en una o más características del citado dispositivo 5G particular (401, 402, 403).
3. El sistema (4) de cualquiera de las reivindicaciones 1-2,
en el que la Unidad Protectora (431) debe realizar un análisis de Bosque Aleatorio de (i) los valores de los contadores de mensajes por unidad de tiempo por número IMSI, y (ii) un perfil de dispositivo predefinido que indica un intervalo normal para el número de mensajes de control que un determinado dispositivo con capa­ cidad 5G (401, 402, 403) está autorizado a enviar por unidad de tiempo; y basándose en el citado análisis de Bosque Aleatorio, generar una determinación de que un determinado dispositivo con capacidad 5G (401, 402, 403) está afectado o funciona incorrectamente;
en el que, en el citado análisis de Bosque Aleatorio, a cada punto se le asigna un valor que corresponde o bien a (i) un indicador de comunicaciones regulares por parte del dispositivo con capacidad 5G, o bien a (ii) un indicador de anomalía menor que está por debajo de un valor umbral predefinido de comunicaciones anormales, o bien a (iii) un indicador de anomalía mayor que es igual o mayor que el citado valor umbral predefinido de comunicaciones anormales.
4. El sistema (4) de cualquiera de las reivindicaciones 1-3,
en el que, al detectar que un dispositivo 5G en particular (401, 402, 403) está afectado o está funcionando defectuosamente, la Unidad Protectora (431) realiza un análisis de Bosque Aleatorio para seleccionar una o más reglas de política que se aplicarán a los mensajes de control salientes del citado dispositivo 5G en particular (401,402, 403);
en el que el citado análisis Bosque Aleatorio utiliza al menos dos de las siguientes características:
un indicador de si el dispositivo en particular con capacidad 5G (401,402, 403) presenta una anomalía menor o una anomalía mayor en las comunicaciones;
un indicador de un segmento de red en el que se encuentra el citado dispositivo particular con capacidad 5G (401, 402, 403);
un indicador de carga de red, que representa la carga de red en un segmento de red en particular;
un número que indica cuántos dispositivos aptos para 5G que son del mismo tipo que el citado dispositivo apto para 5G en particular (401, 402, 403), se ha determinado que están afectados o funcionan defectuosa­ mente.
5. El sistema (4) de cualquiera de las reivindicaciones 1-4,
en el que la Unidad Protectora (431) está conectada a un nodo de red particular, y monitoriza las señales de control salientes que pasan a través del citado nodo de red particular, y provoca el descarte selectivo de los mensajes de control que pasan a través del citado nodo de red particular;
en el que el citado nodo de red en particular es uno de los siguientes:
(a) un NodoB de Nueva Generación (gNB) situado antes de una interfaz Xn;
(b) un nodo de red situado entre un NodoB de Nueva Generación (gNB) y una Entidad de Gestión de Movili­ dad (MME);
(c) un nodo de red situado entre una entidad de Gestión de Movilidad (MME) y una Función de Plano de Control de Pasarela de Servicio (S-GW-C).
6. El sistema (4) de cualquiera de las reivindicaciones 1-5,
en la que la Unidad Protectora (431) debe activar la cuarentena total o la cuarentena selectiva de los mensa­ jes de control salientes de un determinado dispositivo con capacidad 5G (401, 402, 403), modificando dinámicamente un registro asociado al citado dispositivo particular con capacidad 5G (401,402, 403), en al menos uno de los siguientes: un Servidor de Abonado Doméstico (HSS), un Registro de Identidad de Equipo (EIR),
en el que el citado registro es modificado por la Unidad Protectora (431) para indicar que una tarjeta SIM del citado dispositivo apto para 5G (401, 402, 403) fue robada;
en el que el citado registro, una vez modificado por la Unidad Protectora (431), provoca la suspensión de los servicios de comunicación celular al citado dispositivo particular con capacidad 5G (401, 402, 403).
7. El sistema (4) de cualquiera de las reivindicaciones 1-6,
en el que la sonda de señal de Plano de Usuario (UP) (432) realiza la monitorización de Plano de Usuario de al menos: Mensajes SYN, mensajes SYN-ACK, mensajes FIN, mensajes FIN-ACK, mensajes ACK y mensa­ jes Selectivos ACK (SACK);
en el que la sonda de señal del Plano de Control (CP) (433) realiza la supervisión del Plano de Control de al menos: Solicitudes de conexión de control de recursos de radio (RRC), Solicitudes de Conexión, Solicitudes de Creación de Sesión;
en el que la Unidad Protectora (431) determina que un dispositivo IoT en particular está afectado o está funcionando defectuosamente, basándose en el análisis de Aprendizaje de Máquina (ML) tanto de (i) los mensajes de control monitorizados por la sonda de señal UP (432) en el Plano de Usuario, como de (ii) los mensajes de control monitorizados por la sonda de señal CP en el Plano de Control (433).
8. El sistema (4) de la reivindicación 2, en el que, basándose en la citada política de protección particular, la Unidad Protectora (431) debe configurar dinámicamente la sonda de señal del Plano de Control (433), para descartar todos los mensajes de control salientes que salgan del citado dispositivo particular con capacidad 5G (401,402, 403).
9. El sistema (4) de la reivindicación 2, en el que, basándose en la citada política de protección particular, la Unidad Protectora (431) debe configurar dinámicamente la sonda de señal del Plano de Control (433), para descartar selectivamente sólo los mensajes de control salientes que son salientes desde el citado dispositivo particular con capacidad 5G (401, 402, 403) a un destino particular.
10. El sistema (4) de cualquiera de las reivindicaciones 1-9, que comprende:
una Unidad de Predicción (454), configurada para ejecutar los datos recibidos por medio de uno o más mo­ delos de Aprendizaje de Máquina (ML), y para realizar predicciones con respecto a un gran número de dis­ positivos IoT conectados con varios perfiles diferentes y en tiempo real;
un Motor de Reglas (455), configurado para ejecutar datos de predicción por medio de su propio modelo de Aprendizaje de Máquina (ML) que comprende un modelo Bosque Aleatorio que utiliza los siguientes paráme­ tros:
(a) valor de los datos de predicción recibidos de la Unidad de Predicción (454);
(b) estado del dispositivo, indicando si el servicio está desactivado o activado;
(c) tiempo transcurrido desde el último cambio de estado;
(d) ubicación, que señala un segmento de red pertinente en el que se encuentra el dispositivo IoT;
(e) número de dispositivos infectados del mismo tipo;
(f) Indicadores Clave de Rendimiento (KPI) que reflejen la carga de la red y/o la carga de los segmentos de red;
(g) tipo de dispositivo;
(h) día de la semana y hora del día;
en el que, como resultado de la citada ejecución de valores de predicción por medio del modelo ML del Motor de Reglas (455), el Motor de Reglas (455) está configurado para seleccionar una única regla, o un grupo de reglas, que se aplicará con respecto al tráfico del dispositivo IoT relevante.
11. El sistema (4) de cualquiera de las reivindicaciones 1-10, que comprende:
una Sonda de Señalización, configurada para comunicarse con la Unidad Protectora (431),
en el que la Sonda de Señalización está situada en un punto (611) de una RAN Abierta,
en la que la sonda de señalización está configurada para contar las Solicitudes de Conexión de Control de Recursos por Radio (RRC), por Equipo de Usuario (UE) o por IMSI.
12. El sistema (4) de cualquiera de las reivindicaciones 1-10, que comprende:
una Sonda de Señalización, configurada para comunicarse con la Unidad Protectora (431),
en el que la Sonda de Señalización se encuentra en un punto (612) situado entre un NodoB de Nueva Gene­ ración (gNB) y una Entidad de Gestión de la Movilidad (MME);
en la que la sonda de señalización está configurada para contar Solicitudes de Conexión por Equipo de Usuario (UE) o por IMSI.
13. El sistema (4) de cualquiera de las reivindicaciones 1-10, que comprende:
una Sonda de Señalización, configurada para comunicarse con la Unidad Protectora (431),
en el que la sonda de señalización se encuentra en un punto (613) situado entre una Entidad de Gestión de Movilidad (MME) y una Función de Plano de Control de Pasarela de Servicio (S-GW-C);
en la que la Sonda de Señalización está configurada para contar las Solicitudes de Creación de Sesión, por Equipo de Usuario (UE) o por IMSI.
14. El sistema (4) de cualquiera de las reivindicaciones 11-13,
en el que,
cuando la interacción con un Servidor de Abonado Doméstico (HSS) y un Registro de Identidad de Equipo (EIR) no está disponible temporal o permanentemente,
la Unidad Protectora (431) está configurada para ordenar a la Sonda de Señalización que descarte selecti­ vamente los mensajes que cumplan un criterio predefinido de tener una carga útil superior a N bytes.
15. Un procedimiento para detectar y mitigar una tormenta de señalización 5G generada por uno o más dispositivos con capacidad 5G (401, 402, 403), el procedimiento comprende:
en una sonda de señal de Plano de Control (CP) (433), conectada en línea en un primer nodo de red situado entre una Red de Acceso por Radio (RAN) (411) y una Red Central 5G (410), supervisar los mensajes de control del Plano de Control originados por los dispositivos con capacidad 5G y que pasan por el primer nodo de red;
en una sonda de señal del Plano de Usuario (UP) (432), conectada en línea en un segundo nodo de red situado entre la Red Central 5G (410) y una o más entidades remotas (421) a las que los dispositivos con capacidad 5G (401, 402, 403) están enviando mensajes, monitorizar los mensajes de control del Plano de Usuario que pasan a través del segundo nodo de red;
en un subsistema de Gestión de Inventario (IM) (434), almacenar datos correlacionados entre un determinado dispositivo apto para 5G y un número de Identidad Internacional de Abonado Móvil (IMSI) que se le haya asignado;
en una Unidad Protectora (431), (A) recibir (i) datos recogidos por la sonda de señal CP (433), y (ii) datos recogidos por la sonda de señal UP (432), y (iii) un subconjunto de números IMSI del subsistema IM, y (B) generar una lista de dispositivos particulares con capacidad 5G (401, 402, 403) que se detecta que están afectados o funcionan defectuosamente, y (C) activar la cuarentena de mensajes de control salientes de los citados dispositivos 5G (401,402, 403) que están en la citada lista;
el procedimiento se caracteriza por que comprende los pasos de: en la Unidad Protectora (431), realizar un análisis de Aprendizaje de Máquina de (i) los datos recogidos por la sonda de señal del Plano de Control (433) y (ii) los datos recogidos por la sonda de señal del Plano de Usuario (432), y basándose en el citado análisis de Aprendizaje de Máquina, generar una determinación de que un determinado dispositivo con ca­ pacidad 5G (401, 402, 403) está afectado o funciona incorrectamente;
en el que el citado análisis de Aprendizaje de Máquina comprende al menos un análisis de Bosque Aleatorio de (i) datos recogidos por la sonda de señal del Plano de Control (433) y (ii) datos recogidos por la sonda de señal del Plano de Usuario (432);
en el que, en el citado análisis de Bosque Aleatorio, cada punto es una característica de desviación de los contadores del correspondiente intervalo de valores predefinido de funcionamiento normal representado como un par de valor mínimo y valor máximo;
en el que, en el citado análisis de Bosque Aleatorio, a cada punto se le asigna un valor que corresponde o bien a (i) un indicador de comunicaciones regulares por parte del dispositivo con capacidad 5G (401, 402, 403), o bien a (ii) un indicador de anomalía menor que está por debajo de un valor umbral predefinido de comunicaciones anormales, o bien a (iii) un indicador de anomalía mayor que es igual o mayor que el citado valor umbral predefinido de comunicaciones anormales.
ES20191112T 2019-08-20 2020-08-14 Sistema, dispositivo y procedimiento de detección, mitigación y aislamiento de una tormenta de señalización Active ES2938762T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US16/544,910 US11323884B2 (en) 2017-06-27 2019-08-20 System, device, and method of detecting, mitigating and isolating a signaling storm

Publications (1)

Publication Number Publication Date
ES2938762T3 true ES2938762T3 (es) 2023-04-14

Family

ID=72087953

Family Applications (1)

Application Number Title Priority Date Filing Date
ES20191112T Active ES2938762T3 (es) 2019-08-20 2020-08-14 Sistema, dispositivo y procedimiento de detección, mitigación y aislamiento de una tormenta de señalización

Country Status (3)

Country Link
EP (1) EP3783856B1 (es)
CA (1) CA3090037C (es)
ES (1) ES2938762T3 (es)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113449815B (zh) * 2021-07-20 2023-01-24 四川大学 一种基于深度包分析的异常包检测方法及系统
CN114339767B (zh) * 2021-12-30 2024-04-05 恒安嘉新（北京）科技股份公司 一种信令检测方法、装置、电子设备及存储介质
WO2024028114A1 (en) * 2022-08-01 2024-02-08 Telefonaktiebolaget Lm Ericsson (Publ) Determining anomalous state of wireless communication devices

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3313114B1 (en) * 2016-10-18 2021-06-09 Nokia Solutions and Networks Oy Detection and mitigation of signalling anomalies in wireless network
US10862911B2 (en) * 2017-06-27 2020-12-08 Allot Ltd. System, device, and method of adaptive network protection for managed internet-of-things services

Also Published As

Publication number Publication date
EP3783856A1 (en) 2021-02-24
EP3783856B1 (en) 2023-01-18
CA3090037C (en) 2023-08-08
CA3090037A1 (en) 2021-02-20

Similar Documents

Publication Publication Date Title
US11323884B2 (en) System, device, and method of detecting, mitigating and isolating a signaling storm
US11516239B2 (en) System, device, and method of adaptive network protection for managed internet-of-things services
US11743299B2 (en) System, method, and apparatus of securing and managing internet-connected devices and networks
ES2938762T3 (es) Sistema, dispositivo y procedimiento de detección, mitigación y aislamiento de una tormenta de señalización
US10542029B2 (en) System and method for security and quality assessment of wireless access points
US11323953B2 (en) Rogue base station router detection with machine learning algorithms
CN112219381B (zh) 用于基于数据分析的消息过滤的方法和装置
US9763099B2 (en) System and method for security and quality assessment of wireless access points
US20200053567A1 (en) Security architecture for machine type communications
US11711395B2 (en) User-determined network traffic filtering
WO2016086763A1 (zh) 无线访问节点检测方法、无线网络检测系统和服务器
Liebergeld et al. Cellpot: A concept for next generation cellular network honeypots
Sebeni Telco honeypot
Hsu et al. Overview of Cyberattacks Against Radio Access Networks in Long-term Evolution Mobile Networks and Defense Solutions
US9781136B2 (en) Mitigating the impact from internet attacks in a RAN using internet transport
Bakhit et al. DAGGER: Distributed architecture for granular mitigation of mobile based attacks
Jha Layer Based Security in Narrow Band Internet of Things (NB-IoT) Rakesh Kumar Jha, Puja, Haneet Kour and Manoj Kumar, Shubha Jain