ES3013809T3 - Game engine-based computer security - Google Patents

Game engine-based computer security Download PDF

Info

Publication number
ES3013809T3
ES3013809T3 ES19846733T ES19846733T ES3013809T3 ES 3013809 T3 ES3013809 T3 ES 3013809T3 ES 19846733 T ES19846733 T ES 19846733T ES 19846733 T ES19846733 T ES 19846733T ES 3013809 T3 ES3013809 T3 ES 3013809T3
Authority
ES
Spain
Prior art keywords
data
game engine
event
monitored event
logic
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
ES19846733T
Other languages
English (en)
Inventor
Jonathan Allan Malm
Joshua Howard Stein
Patrick Nathaniel Wardle
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.)
Jamf Software LLC
Original Assignee
Jamf Software LLC
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
Application filed by Jamf Software LLC filed Critical Jamf Software LLC
Application granted granted Critical
Publication of ES3013809T3 publication Critical patent/ES3013809T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/554—Detecting local intrusion or implementing counter-measures involving event detection and direct action
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/562—Static detection
    • G06F21/565—Static detection by checking file integrity
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/35—Details of game servers
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70—Game security or game management aspects
    • A63F13/73—Authorising game programs or game devices, e.g. checking authenticity
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70—Game security or game management aspects
    • A63F13/75—Enforcing rules, e.g. detecting foul play or generating lists of cheating players
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • G07F17/3241—Security aspects of a gaming system, e.g. detecting cheating, device integrity, surveillance
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/034—Test or assess a computer or a system
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2109—Game systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Multimedia (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Virology (AREA)
  • Storage Device Security (AREA)
  • Debugging And Monitoring (AREA)
  • Computer And Data Communications (AREA)

Abstract

Un sensor de motor de juego de un dispositivo informático que ejecuta un sistema operativo recibe datos del sistema operativo que representan la ocurrencia de un evento monitorizado. El sensor envía datos secundarios correspondientes al evento monitorizado a un controlador lógico del motor de juego. Un primer bloque lógico del controlador determina, basándose en los datos segundos y terceros que representan el estado del sistema del dispositivo informático, que se cumple una primera condición de predicado. Un segundo bloque lógico del controlador determina, basándose en los datos segundos y terceros, que se cumple una segunda condición de predicado. Se detecta una amenaza a la seguridad informática basándose en el cumplimiento de las condiciones de predicado primera y segunda, y se instruye a al menos un actuador del motor de juego para que realice al menos una acción en respuesta a la amenaza. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Seguridad informática basada en motor de juego
Antecedentes
A medida que los sistemas y dispositivos informáticos se han vuelto más populares, tales sistemas y dispositivos se han convertido en objetivos de actividad maliciosa, tales como virus, malware, ransomware, ataques de phishing, etc. Diversas soluciones de seguridad informática están disponibles para usuarios y empresas para intentar y evitar tal actividad maliciosa. Algunas soluciones de seguridad informática están basadas en firmas y comparan archivos o cargas útiles potencialmente maliciosos con una firma que se sabe que corresponde a archivo o archivos maliciosos. Sin embargo, estas soluciones son tan buenas como las firmas subyacentes, y tratar de emitir actualizaciones de firma para mantenerse al día con las amenazas en constante cambio es una propuesta perdedora, especialmente porque el malware sofisticado a menudo tiene la capacidad de mutar y anular automáticamente la detección basada en firmas. Las soluciones basadas en inteligencia artificial (AI) introducen un archivo potencialmente malicioso (o datos derivados del mismo) en un modelo de IA (por ejemplo, una red neuronal) para predecir si el archivo es malicioso o no. Sin embargo, la eficacia de una solución basada en Al está determinada por el modelo subyacente y, a veces, puede ser difícil obtener datos de entrenamiento suficientemente completos para entrenar el modelo.
El documento US2017/235967 A1 divulga un método para proteger un criterio de valoración contra la exposición a contenido no seguro o desconocido. El método comprende cifrar archivos en el criterio de valoración para evitar el acceso no autorizado a los archivos. Al cifrar los archivos, el método comprende monitorizar estados de exposición de un proceso en el criterio de valoración a contenido potencialmente no seguro aplicando una pluralidad de reglas de comportamiento para determinar si los estados de exposición del proceso están expuestos o son seguros. El método comprende adicionalmente restringir el acceso por el proceso a los archivos cuando el proceso se expone controlando el acceso a los archivos a través de un filtro de sistema de archivos que descifra condicionalmente uno o más archivos para el proceso de acuerdo con el estado de exposición del proceso.
El documento US2008/214300 A1 divulga un método para evitar la manipulación en un sistema de juego. El método comprende controlar una descarga de datos de juego, tal como una imagen ejecutable para generar un juego de azar, de un primer dispositivo de juego a un segundo dispositivo de juego.
El documento US2004/266533 A1 divulga un método para la distribución de software de juegos en un entorno de sistema de juegos. El método comprende recibir una solicitud de un solicitante de una licencia para usar un programa de software de juego aprobado y recibir una indicación de pago por la licencia. En respuesta a la indicación de pago, el método comprende descargar el programa de software de juego aprobado al solicitante.
Sumario
La invención se define por las reivindicaciones independientes. Además, las realizaciones de la invención se definen en las reivindicaciones. Es más, ejemplos, realizaciones y descripciones, que no están cubiertos por las reivindicaciones no se presentan como realizaciones de la invención, sino como laTécnica anterioro ejemplos útiles para comprender la invención.
Breve descripción de los dibujos
Para una comprensión más completa de la naturaleza y de los objetos deseados de la presente divulgación, se hace referencia a la siguiente descripción detallada tomada junto con las figuras de los dibujos adjuntos en donde los caracteres de referencia similares indican partes correspondientes a lo largo de las diversas vistas.
La FIG. 1 ilustra un ejemplo de una canalización de seguridad informática de "caja negra";
la FIG. 2 ilustra un ejemplo de un sistema que incluye seguridad informática basada en motor de juego;
la FIG. 3 ilustra un ejemplo de funcionamiento en el sistema de la FIG. 2 con respecto a un caso de uso de seguridad informática particular;
la FIG. 4 ilustra un ejemplo de un método de seguridad informática basada en motor de juego; y
la FIG. 5 ilustra un ejemplo de un sistema de gestión de dispositivo móvil (MDM) que incluye seguridad informática basada en motor de juego.
Descripción detallada
Los aspectos de la presente divulgación pueden entenderse con referencia a las siguientes definiciones.
Como se usa en el presente documento, la forma singular "un", "una", y "el/la", incluyen las referencias al plural a menos que el contexto indique claramente lo contrario.
A menos que se indique específicamente o sea obvio por el contexto, como se usa en el presente documento, los términos "aproximadamente" y "sustancialmente" se entienden dentro de un intervalo de tolerancia normal en la técnica, por ejemplo, dentro de 2 desviaciones estándar de la media. "Aproximadamente" y "sustancialmente" pueden entenderse como dentro del 10 %, 9 %, 8 %, 7 %, 6 %, 5 %, 4 %, 3 %, 2 %, 1 %, 0,5 %, 0,1 %, 0,05 % o 0,01 % del valor indicado. A menos que se aclare lo contrario a partir del contexto, todos los valores numéricos proporcionados en el presente documento se modifican por los términos aproximadamente o sustancialmente.
Tal como se usan en la memoria descriptiva y en las reivindicaciones, los términos "comprende", "que comprende", "que contiene", "que tiene", y similares pueden tener el significado que se les atribuye en la ley de patentes de EE. UU. y pueden significar "incluye", "que incluye", y similares.
A menos que se indique específicamente o sea obvio por el contexto, el término "o", como se usa en el presente documento, se entiende que es inclusivo.
Se entiende que los intervalos proporcionados en el presente documento son abreviaturas de todos los valores dentro del intervalo. Por ejemplo, se entiende que un intervalo de 1 a 50 incluye cualquier número, combinación de números o subrango del grupo que consiste en 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21,22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49 o 50 (así como fracciones de los mismos a menos que el contexto indique claramente lo contrario).
En ciertos aspectos, se desvela un sistema y un método asociado para la seguridad informática basada en motor de juego. Si bien los motores de juego y la seguridad informática se consideran conceptos informáticos no relacionados (y los juegos son un vector de infección común para archivos maliciosos), los aspectos de la presente divulgación incluyen aprovechar componentes de arquitecturas de motor de juego para implementar funciones de seguridad informática, incluyendo funciones que no tienen nada que ver con juegos específicos o incluso juegos en general.
Un motor de juego puede incluir una estructura de software o entorno de desarrollo diseñado principalmente para que las personas construyan componentes reutilizables de videojuegos. La funcionalidad principal de un motor de juego a menudo incluye motores de representación, motores de física, animación, efectos de iluminación, etc. Algunos motores de juego también incluyen componentes configurados para ejecutar funciones lógicas que determinan un conjunto de salidas que se van a realizar dentro del juego dada una o más entradas generadas o recibidas dentro del juego.
En un aspecto específico, un motor de juego puede incluir uno o más sensores, un modelo de propiedades/estado, controlador lógico y accionadores. Los sensores pueden recopilar datos de un entorno de juego y proporcionar los datos al controlador lógico como propiedades y estados de los objetos en los entornos. Un modelo de propiedades/estado puede representar entradas recopiladas del sensor o sensores y cómo tales entradas encajan en un modelo global de todo el entorno de juego. Los controladores lógicos pueden ejecutar operaciones y/o simulaciones sobre el estado del juego y las propiedades del sensor, que se pueden usar para ajustar el estado del juego y enviar señales a los accionadores. Los accionadores pueden realizar funciones tales como mover objetos, añadir/eliminar objetos, etc. Estas acciones pueden iniciarse por la salida de los controladores lógicos.
Se apreciará que usar un motor de juego para realizar funciones de seguridad informática es marcadamente diferente de las técnicas de seguridad informática convencionales. Por ejemplo, antivirus y otras técnicas de detección de criterio de valoración a menudo se basan en una canalización de datos rígida, en caja negra de observación de eventos, evaluación de reglas y, en última instancia, acciones/alertas. En la FIG. 1 se ilustra un ejemplo de una canalización 100 de este tipo. Mapear este proceso canalizado en componentes de motor de juego (por ejemplo, sensores, estado de sistema, controladores lógicos y accionadores) introduce un tipo de detección y respuesta del criterio de valoración que es abierto, personalizable, flexible, extensible y soporta decisiones basadas en inteligencia artificial (IA). Los métodos y sistemas descritos en el presente documento permiten modelar un sistema operativo informático y comportamientos impulsados por el usuario final utilizando marcos de motor de juego y semántica para recopilar, detectar y/o responder a eventos de seguridad cibernética interesantes, sospechosos o maliciosos en un dispositivo de criterio de valoración de forma personalizable, flexible y ampliable.
La FIG. 2 ilustra un sistema 200 que incluye seguridad informática basada en motor de juego de acuerdo con un aspecto. El sistema 200 incluye uno o más sensores 205, que pueden desplegarse con respecto a un sistema operativo como una serie de monitores para detección en tiempo real o casi en tiempo real de eventos de sistema operativo (por ejemplo, monitores de eventos del sistema). Para fines de ilustración, los sensores 205 pueden corresponder a subrutinas de software que utilizan comunicación en modo de usuario y/o modo de núcleo con el sistema operativo o componentes que generalmente están bajo el control del sistema operativo. En algunos ejemplos, los sensores 205 pueden corresponder adicional o alternativamente a componentes de hardware que están en comunicación con el sistema operativo.
En ejemplos particulares, los sensores 205 se basan en un marco de auditoría del sistema operativo o interfaz de programación de aplicaciones (API), como OpenBSM, que soporta la monitorización de procesos, archivos, operaciones de entrada/salida (E/S), actividad de red, descargas, registradores de teclas, clics sintéticos, acceso periférico (por ejemplo, cámara o micrófono), capturas de pantalla, etc. Por tanto, los sensores 205 pueden incluir, pero no se limitan a: un monitor de sistema de archivos, un monitor de proceso, un monitor de red, un monitor de autenticación (por ejemplo, un monitor de llavero), un monitor de descarga, un monitor de captura de pantalla, un monitor de medio extraíble (por ejemplo, USB, disco duro externo, etc.), un monitor de clic sintético (por ejemplo, un uso programático del ratón), un monitor de volumen (por ejemplo, disco lógico), un monitor de reanudación de la actividad del usuario (por ejemplo, apertura de la tapa del portátil, regreso de un modo de salvapantallas, encendido, etc.) y/o monitores de actividad de cámara web/micrófono.
Los sensores 205 pueden observar, analizar y organizar datos sin procesar en un modelo de datos objetivo, facilitando una actualización del estado de sistema (por ejemplo, caché) para reflejar un evento recién recibido y para habilitar el envío del nuevo evento y estado de sistema a un controlador lógico. A continuación se proporciona un ejemplo ilustrativo no limitante de datos sin procesar que pueden recibirse por un sensor 205 desde un sistema operativo cuando se inicia una aplicación de calculadora:
posix_spawn(2) / 43190 / 2019-08-05 23:54:10 0000 / 7 tokens
Token AUT HEADER32:
size : 219
versión : 11
e type : 43190
e_mod : 0
s : 1565049250
ms : 761
Token AUTEXECARGS:
arg : /Applications/Calculator.app/Contents/MacOS/Calculator
Token AUT PATH:
path :/dev/null
Token AUT DATA:
Token AUT SUBJECT32:
auid : 4294967295
euid : 501
egid : 20
ruid : 501
rgid : 20
pid : 48653
sid : 100000
tid : au_tid32(port: 0, addr: 0)
Token AUTRETURN32:
status : 0
ret : 0
Token AUT TRAILER:
magic .45317
count : 219
A continuación se proporciona un ejemplo ilustrativo no limitante de un modelo de datos objetivo. El ejemplo incluye un objeto "Evento de proceso", que incluye un subobjeto "Proceso". Debe entenderse que cualquier número de objetos puede ser parte del modelo de datos objetivo, y los objetos pueden incluir cualquier número de subobjetos. Es más, el modelo de datos objetivo no solo puede incluir algunos de los datos sin procesar recibidos del sistema operativo, pero también puede incluir datos que se calculan basándose en los datos sin procesar y/o basándose en otros datos que están disponibles o pueden medirse. En algunos casos, el modelo de datos objetivo incluye o apunta a código que es ejecutable para calcular ciertos elementos de datos, y tales elementos de datos se evalúan dinámicamente (por ejemplo, justo a tiempo) cuando son referenciados por un bloque/regla lógica.
{"etiqueta": "Evento de Proceso", "valor": "$evento", "tipo": "EventoProcesoGPP",
"descripción": "Eventos de creación y salida de proceso.", "icono": "proceso",
"campos": [
{"etiqueta": "ID único", "valor": "iduu", "tipo": "cadena", "códigos": "base", "descripción": "Un identificador único para este evento."},
{"etiqueta": "tipo", "valor": "tipo", "tipo": "enum", "códigos": "base", "descripción": "Actividad de proceso.",
"opciones": [
{"etiqueta": "Ninguno", "valor": 0},
{"etiqueta": "Crear", "valor": 1},
{"etiqueta": "Salir", "valor": 2}
]
},
{"etiqueta": "subtipo", "valor": "subTipo", "tipo": "enum", "códigos": "base", "descripción": "Actividad de proceso detallada. ",
"opciones": [
{"etiqueta": "Ejec", "valor": 7},
{"etiqueta": "Horquilla", "valor": 2},
{"etiqueta": "Salir", "valor": 1},
{"etiqueta": "Ejecutivo", "valor": 23},
{"etiqueta": " Posix Spawn ", "valor': 43190}
]
},
{"etiqueta": "Marca de tiempo", "valor": "marca de tiempo", "códigos": "base", "tipo": "fecha", "descripción": "La marca de tiempo del evento de proceso."},
{"etiqueta": "ID de proceso", "valor": "idp", "tipo": "número", "códigos": "base", "descripción": "El identificador de proceso asociado con el evento de proceso."},
{"etiqueta": "Proceso", "valor": "proceso", "tipo": "proceso", "códigos": "relacionados", "descripción": "Objeto de proceso asociado con este evento".}
]
}
{"etiqueta": "Proceso", "valor": "proceso", "tipo": "proceso", "descripción": "Un objeto que representa un proceso y sus atributos.",
"campos": [
{"etiqueta": "ID único", "valor": "iduu", "tipo": "cadena", "códigos": "base", "descripción": "Un identificador único para este proceso."},
{"etiqueta": "ID de proceso", "valor": "idp", "tipo": "número", "códigos": "base", "descripción": "El identificador de proceso asociado con este proceso."},
{"etiqueta": "ID de usuario", "valor": "idu", "tipo": "número", "códigos": "base", "descripción": "El identificador asignado al usuario responsable de ejecutar este proceso."},
{"etiqueta": "ID de grupo", "valor": "idg", "tipo": "número", "códigos": "base", "descripción": "El identificador asignado al grupo responsable de ejecutar este proceso."},
{"etiqueta": "ID de usuario real", "valor": "idur", "tipo": "número", "códigos": "base", "descripción": "El identificador asignado al usuario real responsable de ejecutar este proceso."},
{"etiqueta": "ID de grupo real", "valor": "idgr", "tipo": "número", "códigos": "base", "descripción": "El identificador asignado al grupo real responsable de ejecutar este proceso."},
{"etiqueta": "ID de grupo de proceso", "valor": "idgp", "tipo": "número", "códigos": "base", "descripción": "El grupo de procesos asociado con este proceso."},
{"etiqueta": "Marca de tiempo de inicio", "valor": "marcaDeTiempoDeInicio", "tipo": "fecha", "códigos": "base", "descripción": "La marca de tiempo de inicio del proceso."},
{"etiqueta": "Marca de tiempo final", "valor": "marcaDeTiempoFinal", "tipo": "fecha", "códigos": "base", "descripción": "La marca de tiempo final del proceso."},
{"etiqueta": "Trayectoria", "valor": "trayectoria", "tipo": "cadena", "códigos": "base", "descripción": "La trayectoria binaria de los procesos."},
{"etiqueta": "Nombre", "valor": "nombre", "tipo": "cadena", "códigos": "base", "descripción": "El nombre de los procesos."},
{"etiqueta": "ID de proceso principal", "valor": "idpp", "tipo": "número", "códigos": "base", "descripción": "El identificador de proceso del proceso principal."},
{"etiqueta": "Args", "valor": "args", "tipo": "matriz", "códigos": "extendido", "descripción": "Una lista de argumentos (opcionalmente) pasados al proceso."},
{"etiqueta": "Código de salida", "valor": "códigoSalida", "tipo": "número", "códigos": "base", "descripción": "El código de salida para el proceso."},
{"etiqueta": "Binario", "valor": "binario", "tipo": "binario", "códigos": "relacionados", "descripción": "El sistema binario asociado con el proceso."},
{"etiqueta": "Usuario", "valor": "usuario", "tipo": "usuario", "códigos": "relacionados", "descripción": "Usuario que inició/posee el proceso."},
{"etiqueta": "Grupo", "valor": "grupo", "tipo": "grupo", "códigos": "relacionados", "descripción": "Grupo que inició/posee el proceso."},
{"etiqueta": "Principal", "valor": "principal", "tipo": "proceso", "códigos": "relacionados", "descripción": "El objeto de proceso responsable de generar este proceso."},
{"etiqueta": "Es la App GUI", "valor": "APPgui", "tipo": "bool", "códigos": "extendido", "descripción": "Verdadero es que este proceso es una aplicación con una interfaz gráfica de usuario (GUI)."}, {"etiqueta": "Información de firma", "valor": "infoFirma", "tipo": "señalización", "códigos": "extendido", "descripción": "La información de firma de código dinámica asociada con este proceso."}, {"etiqueta": "Icono", "valor": "icono", "tipo": "imagen", "descripción": "El icono de imagen para el proceso."},
{"etiqueta": "Paquete", "valor": "paquete", "tipo": "paquete", "descripción": "El paquete asociado con este proceso."},
{"etiqueta": "Trayectoria de App", "valor": "trayectoriaApp", "tipo": "cadena", "códigos": "extendido", "descripción": "La trayectoria completa a la aplicación asociada con este proceso".} ]
}
El sistema 200 también puede incluir un modelo de estado de sistema 210. El modelo 210 (designado "estado de sistema" en la FIG. 2) puede recibir datos sin procesar de un sistema operativo (por ejemplo, observado por los sensores 205). En algunos ejemplos, todo o una parte del análisis y organización descritos anteriormente como realizados por los sensores 205 puede realizarse en su lugar en el modelo 210. Los datos de eventos modelados recibidos de los sensores 205 y/o generados en el modelo 210 pueden ampliarse adicionalmente para incluir cálculos (por ejemplo, cálculo predeterminado) y relaciones (por ejemplo, relaciones conocidas), incluyendo datos calculados/recopilados en código. Los aspectos del sistema 200 pueden modelarse a través de una memoria caché de eventos evaluados previamente (por ejemplo, ampliado con salidas/extensiones de controlador lógico anteriores) y tipos de datos de sistema recopilados previamente (por ejemplo, archivos, procesos, usuarios, grupos, etc.) que representan el estado actual e histórico del entorno. En algunos ejemplos, la memoria caché de estado de sistema es una tabla u otra estructura de datos en la que se almacenan eventos previos y se pueden consultar. Por tanto, en un momento dado, el modelo 210 puede representar lo que está sucediendo "actualmente" en el sistema 200 y/o lo que ha sucedido en el sistema 200 hasta ese punto en el tiempo.
En algunos aspectos, el modelo 210 permite aplicar extensiones (por ejemplo, "etiquetas") mediante una lógica personalizada, definida por el usuario y evaluada en un controlador lógico, como se describe con más detalle en el presente documento. Tales extensiones se pueden usar para describir conceptos y comportamientos de nivel superior a medida que se concatenan durante la evaluación de eventos en un controlador lógico, permitiendo que un evento se entienda mejor a medida que el evento se abre paso a través del sistema 200. En algunos casos, el evento puede reevaluarse como "datos ortogonales" con respecto a un evento posterior.
El sistema 200 también puede incluir un controlador lógico 215. El controlador lógico 215 puede ser o implementar un sistema de reglas basado en predicados, gráfico, árbol de decisión, máquina de estado, estrategias deterministas o probabilísticas, código personalizado y/u otros algoritmos de inteligencia artificial (IA), incluyendo bloques lógicos detectables por IA dentro de los sistemas mencionados anteriormente. El controlador lógico 215 puede construirse sobre bloques lógicos 216 que pueden definirse, configurarse, añadirse o eliminarse individualmente, etc., para describir y/o detectar diferentes comportamientos. Los bloques lógicos 216 se pueden concatenar entre sí para describir conceptos de nivel superior y detectar comportamientos "emergentes", ya que la salida de un único bloque lógico 216 puede alimentarse a otro(s) bloque(s) lógico(s) 216 como una entrada. El controlador lógico 215 puede recibir nuevas entradas (por ejemplo, modeladas) de los sensores 205. El controlador lógico 215 puede ejecutar a continuación los bloques lógicos 216 en un orden configurado. Encapsular la lógica para diferentes detectores de seguridad informática en diferentes bloques lógicos 216 permite un despliegue rápido de detectores para diversas amenazas de seguridad. Para fines de ilustración, el mismo bloque lógico predefinido o definido por el usuario puede desplegarse en diferentes detectores de amenazas.
La ejecución de los bloques lógicos 216 puede dar como resultado una diversidad de funciones. En algunos casos, la ejecución de los bloques lógicos 216 puede actualizar o ampliar el modelo de estado de sistema 210 para un evento individual. Los bloques lógicos 216 pueden basarse en datos cualitativos y cuantitativos asociados con eventos de sistema. El sistema 200 puede soportar datos de "contexto" (por ejemplo, pares clave:valor) y/o datos de "etiquetas" (por ejemplo, una lista de claves). Ambos tipos de datos pueden usarse como entradas a reglas.
En algunos casos, la ejecución de los bloques lógicos 216 puede dar como resultado la emisión de un evento totalmente enriquecido de modo que el modelo de estado de sistema 210 para el sistema 200 pueda actualizarse, incluyendo cualquier "contexto" y/o "etiquetas" calculado. En algunos casos, la ejecución de los bloques lógicos 216 puede dar como resultado la salida de una lista de "acciones" que alimentan a los accionadores, como se describe con más detalle en el presente documento.
Se apreciará que la capacidad de concatenar diferentes combinaciones de bloques lógicos 216 posibilita un marco de detección potente y flexible para problemas de seguridad informática. Los bloques lógicos aguas arriba 216 pueden considerarse como "etiquetadores" que etiquetan selectivamente eventos y otros datos a medida que viajan a través del sistema 200, y los bloques lógicos aguas abajo 216 pueden considerarse como "combinadores" predicados que emiten comandos a los accionadores 220 para tomar ciertas acciones si existe una combinación específica de etiquetas de evento y/o estado de sistema. A modo de ejemplo de concatenación de bloque lógico (o regla), un primer bloque lógico puede detectar si un archivo no está firmado, y un segundo bloque lógico puede iniciar una alerta si un archivo que se detectó como no firmado eleva (o intenta elevar) los privilegios de cuenta de invitado.
El sistema 200 puede incluir un conjunto de accionadores 220. Los accionadores 220 pueden recibir una entrada del controlador lógico 215 (donde esa entrada se determinó basándose en el evento o eventos detectados por los sensores 205 y/o información del modelo 210 con respecto al estado general del sistema) y realizar una o más acciones basándose en el entrada recibida. Las acciones de los accionadores pueden ser configurables (por ejemplo, destino(s) configurado(s) para registros, alertas, etc.). Por tanto, dependiendo de la configuración, el mismo accionador puede hacer que se almacenen en caché más o menos datos en el modelo de estado de sistema 210, escrito en un archivo de registro, etc., permitiendo así que un administrador establezca una verbosidad de los datos devueltos. Por ejemplo, un administrador puede seleccionar la cantidad y/o tipos de datos ortogonales almacenados en caché, registrados, recogidos, etc.
Los accionadores 220 pueden ejecutar una diversidad de acciones. En algunos casos, los accionadores 220 pueden realizar una acción "caché", donde los accionadores 220 actualizan un estado de todo el sistema (por ejemplo, el modelo 210) con salida del controlador lógico 215 para un evento dado. En algunos casos, los accionadores 220 pueden realizar una acción de "registro local/remoto", donde los accionadores 220 escriben las salidas del controlador lógico 215 en una entrada de registro de un archivo de registro local o una capacidad de registro remoto (por ejemplo, un gestor de eventos y registros, etc.). En algunos casos, los accionadores 220 pueden realizar una acción de "respuesta activa", donde los accionadores 220 pueden, por ejemplo, alertar al sistema o a un usuario de una amenaza de seguridad, poner archivos en cuarentena, borrar archivos, recopilar datos adicionales, terminar un proceso, ajustar un cortafuegos del sistema y/o terminar una conexión de red, etc.
Dependiendo de la implementación, uno o más componentes de la FIG. 2 puede incluirse como parte de un motor de juego. Por ejemplo, el modelo de estado de sistema 210, el controlador lógico 215, los bloques lógicos 216 y los accionadores 220 pueden ser parte de un motor de juego, mientras que los sensores 205 pueden acoplarse al motor de juego.
Durante el funcionamiento, el sistema 200 puede implementar diversos procedimientos de seguridad informática. Para fines de ilustración, un controlador lógico 215 puede configurarse para realizar ciertas operaciones (designadas como "(1)" en la FIG. 2). Los sensores 205 pueden recibir un evento (designado como "(2)"), por ejemplo, un evento generado por u que se produce en un sistema operativo de un dispositivo informático. Los sensores 205 pueden manipular los datos sin procesar del evento para generar evento' (una representación del evento que es compatible con el modelo de estado de sistema 210). El modelo 210 puede actualizarse basándose en el evento' (designado como "(3)"). Se puede proporcionar una combinación del evento y el estado de sistema del modelo 210 a uno o más bloques lógicos 216 que implementan (por ejemplo, son invocados por) el controlador lógico 215. Por ejemplo, un bucle de código iterativo 218 puede evaluar (designado como "(4)") el evento modelado y el estado de sistema del modelo 210, que incluye identificar etiquetas/contextos/acciones aplicables, para generar un evento". Si el controlador lógico 215 determina que se va a realizar una acción, el controlador lógico 215 ordena a un accionador 220 que realice la acción, como registrar, informar y/o comunicar una alerta. En algunos ejemplos, el modelo de estado de sistema 210 puede actualizarse adicionalmente basándose en el evento" y la acción o acciones realizadas.
Los bloques lógicos 216 pueden representar, por lo tanto, predicados que pueden concatenarse entre sí. En algunos ejemplos, se pueden definir predicados para el acceso inicial, ejecución, persistencia, escalada de privilegios, evasión de defensa, acceso de credenciales, descubrimiento, movimiento lateral, recogida, exfiltración, mando y control, etc. Tales predicados pueden reutilizarse en diversos controladores lógicos que están configurados para detectar diversos problemas de seguridad basándose en eventos de difusión en continuo desde un sistema operativo y/o datos de evento almacenados en caché desde un modelo de estado de sistema.
Se apreciará que las técnicas de seguridad basadas en motor de juego descritas en el presente documento pueden buscar más allá de firmas convencionales y detección basada en archivo/contenido para encontrar específicamente comportamientos sospechosos. La actividad de malware/sospechosa normalmente comienza como desconocida. Las detecciones convencionales basadas en firma y archivo/contenido esperan que se conozca algo (o al menos fundamentalmente diferente en el nivel de archivo/binario/contenido). La actividad de malware/sospechosa normalmente tiene un objetivo que finalmente intenta completar. Por lo tanto, en lugar de buscar un "malo" conocido en el nivel de archivo/binario/contenido (que, sin embargo, puede incorporarse en algunas implementaciones del sistema de seguridad basado en motor de juego descrito), las técnicas descritas implican inspeccionar e identificar comportamientos sospechosos en el nivel de actividad, y muchos de tales comportamientos se pasan por alto por firma convencional y sistemas de detección basados en archivo/contenido. Si bien puede ser cierto que al menos algo tiene que comenzar a actuar de manera sospechosa antes de que se encuentre conductualmente, los sistemas convencionales basados en firma y archivo/contenido normalmente no pueden detectar esta actividad, y se basan en algún conocimiento a priori de una muestra real. Si la muestra es desconocida (por ejemplo, en el caso de una amenaza de día 0), puede producirse una actividad maliciosa irreversible y la amenaza puede permanecer desconocida. Sin embargo, en el sistema de seguridad basado en motor de juego descrito, la amenaza al menos se identificará debido a su actividad y se puede responder a ella en consecuencia, incluso en los casos en los que la actividad maliciosa no se evitó completamente en el primer dispositivo infectado. En algunos ejemplos, cuando se detecta actividad sospechosa, el archivo/proceso correspondiente a la actividad sospechosa se "aísla" o se mueve a una máquina virtual y se le permite completar la actividad maliciosa de una manera relativamente inofensiva mientras se supervisa de cerca, de modo que se pueda obtener un conocimiento adicional sobre la amenaza.
La FIG. 3 ilustra un ejemplo de operación en el sistema 200 y generalmente se designa como 300. La FIG. 3 representa el caso de uso de detectar cuándo se copia o mueve una imagen de captura de pantalla que contiene las palabras "Alto Secreto" desde el sistema 200 a un dispositivo de medios extraíbles, y para alertar adicionalmente a una red o administrador de la copia/movimiento. La configuración (para un controlador lógico) correspondiente a este caso de uso se designa 301. La configuración del controlador lógico puede incluir crear y/o concatenar bloques lógicos correspondientes a diferentes reglas de predicado, como se describe con más detalle en el presente documento.
Los sensores 205 (por ejemplo, un sensor de sistema de archivos) pueden observar un evento de sistema de archivos sin procesar 302 generado por el sistema operativo. Los sensores 205 pueden analizar y organizar adicionalmente el evento de sistema de archivos sin procesar en un evento modelado 303. Por ejemplo, los datos semidocumentados proporcionados por el sistema operativo pueden incluir datos de trayectoria, como "/Usuarios/usuario1/Escritorio/ejemplo.png", y escribir datos, como "Renombrar archivo", etc. Los datos organizados pueden introducirse a continuación en el modelo de estado de sistema 210 como una actualización 304. Adicionalmente, también se pueden introducir datos "extendidos" en el modelo de estado de sistema 210. Ejemplos de datos extendidos pueden incluir datos adicionales para el archivo encontrado en la trayectoria de archivo referenciada. En algunos casos, los datos extendidos también pueden incluir datos ortogonales consultados desde el sistema operativo.
El modelo de estado de sistema 210 puede extenderse adicionalmente por datos que se extraen del archivo asociado con el evento. Por ejemplo, diferentes tipos de datos extraídos pueden incluir datos sin procesar, datos de reconocimiento óptico de caracteres (OCR), atributos de archivo, etc.
Lo siguiente es un ejemplo de una regla compuesta para generar una alerta cuando una captura de pantalla con el término "Alto Secreto" se mueve a medios extraíbles:
TipoEntrada: Evento de sistema de archivo
EtiquetasSalida: Captura de pantalla, Alto Secreto, Renombrar, Extraíble
Predicado: tipo.evento== RENOMBRAR Y
trayectoriadest.evento.esExtraíble == verdadero Y archivo.trayectoriadest.evento.esCapturaPantalla == verdadero Y archivo.trayectoriadest.evento.comoImagenOCR.contiene ("Alto Secreto").
Acción: Alerta
Por tanto, la regla compuesta puede incluir una evaluación integral "de una sola vez" del predicado, dando como resultado la ejecución de una acción de "alerta".
Como alternativa, una cadena de bloques lógicos del controlador lógico 215, en lugar de una única regla compuesta, puede aprovechar el modelo de estado de sistema 210. El uso de bloques lógicos discretos que pueden concatenarse puede permitir la reutilización de componentes para operaciones que consumen muchos recursos (por ejemplo, reconocimiento de imágenes OCR). A continuación se proporciona un bloque lógico de ejemplo para detectar copiar o mover un archivo a medios extraíbles:
Def. de regla:
TipoEntrada: Evento de sistema de archivo
Marbetes: Renombrar, Extraíble
Predicado: tipo.evento== RENOMBRAR Y
trayectoriadest.evento.esExtraíble == verdadero.
El tipo de evento "RENOMBRAR" se usa anteriormente porque el sistema operativo en cuestión genera un evento RENOMBRRAR cuando se copia o mueve un archivo. Por tanto, cuando un archivo se copia o se mueve a un disco extraíble, el evento observado se puede etiquetar con las etiquetas "Renombrar" y "Extraíble". El modelo de estado de sistema 210 puede actualizarse con esta etiqueta, y el evento puede continuar a través del resto del sistema de reglas de modelo de estado de sistema con la etiqueta aplicada.
En otro ejemplo, se puede generar una regla para supervisar y ejecutar acciones en eventos asociados con un lenguaje específico, tal como "Alto Secreto". A continuación se proporciona un bloque lógico de ejemplo para determinar si los datos de OCR de una captura de pantalla incluyen "Alto secreto":
Def. de regla:
TipoEntrada: Evento de sistema de archivo
Marbetes: Alto Secreto, Captura de pantalla
Predicado: archivo.evento.esCapturaPantalla == verdadero Y archivo.evento.comoImagenOCR contiene "Alto Secreto"
Por tanto, cuando se observa cualquier archivo de captura de pantalla con caracteres reconocidos como "Alto Secreto" (que pueden o no ser sensibles a mayúsculas y minúsculas), el modelo de estado de sistema 210 se puede actualizar con etiquetas de "Alto secreto" y "Captura de pantalla". El evento puede continuar a continuación a través del resto del sistema de reglas de modelo de estado de sistema con las etiquetas aplicadas.
En otro ejemplo más, se puede generar una regla para proporcionar una alerta basándose en los eventos monitorizados. A continuación se proporciona un bloque lógico de ejemplo para emitir una alerta cuando se activan tanto la regla de medios extraíbles como la regla de datos de OCR de "Alto Secreto":
Alerta:
TipoEntrada: Evento de sistema de archivo
Acciones: Alerta
Marbetes: Sospechoso
Predicado: ("Alto secreto", "Captura de pantalla", "Renombrar" y "Extraíble") en $etiquetas.
Cuando un evento "alcanza" esta regla, y se ha marcado con etiquetas apropiadas ("Alto Secreto", "Captura de pantalla", "Renombrar", y "Extraíble"), el modelo de estado de sistema 210 puede actualizarse con la etiqueta "Sospechoso", y el evento continuará a través del resto del esquema de reglas con esta etiqueta aplicada. El modelo de estado de sistema 210 también se puede actualizar para incluir una acción de "Alerta" asociada con el evento, de modo que cuando el evento completa su ejecución a través del esquema de reglas, el sistema 200 puede ejecutar una acción de alerta basándose en esta regla. Como se muestra en 305, puede tomar más de un "bucle" de ejecución de bloque lógico antes de que se asocien todas las etiquetas y se determine una acción.
Adicionalmente o, como alternativa, una regla puede incluir un valor de prominencia, que puede posicionar la ejecución de la regla dentro del orden de un esquema de regla general. Para fines de ilustración, un valor de prominencia de dos puede indicar que se va a ejecutar una alerta posterior a otras reglas en el esquema de reglas. Adicionalmente o, como alternativa, cuando una regla se evalúa como verdadera, se pueden asignar uno o más valores de confianza a la evaluación. En un ejemplo ilustrativo, un valor de confianza es un número entre cero y uno, y el uso de valores de confianza hace que las salidas de regla de combinación sean de naturaleza "difusa". Cuando una regla aplica múltiples etiquetas a un evento, las etiquetas pueden compartir un valor de confianza común o cada etiqueta puede tener su propio valor de confianza. En algunos aspectos, cuando se usan valores de confianza, una amenaza de seguridad puede detectarse basándose al menos en parte en un agregado (por ejemplo, media, suma u otra función) de los valores de confianza que satisfacen un umbral. En algunos casos, cuando se usan valores de confianza, las reglas "finales" que combinan diversas etiquetas para detectar actividad sospechosa pueden reemplazarse con una regla que compara una confianza agregada con un umbral.
En el ejemplo ilustrado, cuando se determina que una captura de pantalla que incluye el término "Alto Secreto" se está copiando en un medio extraíble, se instruye al accionador o accionadores 306 para que realicen una acción o acciones, tal como actualizar 307 el modelo de estado de sistema 210 y emitir una alerta 308 (que puede ser visual, audible, un mensaje de comunicación (por ejemplo, texto, correo electrónico, etc.), u otro tipo de alerta).
El ejemplo de la FIG. 3 ilustra así un ejemplo de la flexibilidad y robustez de modelar e implementar operaciones de seguridad informática utilizando componentes de motor de juego tales como sensores de entrada, eventos modelados, cachés de estado de sistema, controladores/bloques lógicos y accionadores. Con cada regla ejecutada, un modelo de estado de sistema puede ampliarse con conocimiento adicional que puede referenciarse o usarse en una futura evaluación de reglas (o bloque lógico), incluyendo información con respecto a comandos/acciones accionados que pueden realizarse. Al utilizar flujos de eventos en tiempo real o casi en tiempo real, así como el estado de sistema almacenado en caché, los sistemas y métodos de seguridad informáticos basados en motor de juego divulgados son capaces de detectar problemas de seguridad, incluyendo problemas de seguridad previamente desconocidos, que pueden evadir soluciones basadas en firmas y basadas en IA. Es más, haciendo que las etiquetas viajen con los eventos a medida que los eventos se abren paso a través del sistema, y almacenando en caché eventos anteriores junto con su información de etiqueta en una memoria caché de estado de sistema, las técnicas descritas pueden examinar eventos en conjunto y detectar amenazas de seguridad incluso si esos eventos parecen inocentes cuando se examinan individualmente. Las técnicas descritas pueden, por tanto, ser capaces de frustrar las amenazas de seguridad que se auto modifican para evitar la detección basada en firmas y "reproducir lentamente" su actividad maliciosa para evitar la detección tradicional basada en comportamiento/heurística. En algunas implementaciones, las técnicas de seguridad informática basadas en motor de juego divulgadas pueden usarse junto con otra (por ejemplo, sistema de seguridad basado en firmas).
En un ejemplo, las técnicas de seguridad informática basadas en motor de juego divulgadas pueden configurarse para detectar amenazas de tipo ransomware. En amenazas de tipo ransomware, normalmente hay tres condiciones que se cumplen: modificación de ficheros en directorios específicos por un proceso que no está firmado por una entidad de confianza (por ejemplo, el proveedor del sistema operativo) o el mercado de software confiable (por ejemplo, una tienda de aplicaciones conocida), el contenido del archivo se cifra, y el mismo proceso cifra un gran número de archivos en un período de tiempo corto. Por tanto, se puede definir un primer bloque lógico para determinar si una modificación de archivo es una operación de cifrado por un proceso no confiable en un directorio de usuario, y, si es así, puede etiquetar el evento con una etiqueta "CifradoNoConfiable":
$evento.seModifica == verdadero Y
$trayectoria.evento COINCIDE [directorio de usuario] Y
!$Etiqueta s.proceso.evento. contiene ([firmante del sistema operativo], [firmante de la tienda de aplicaciones]) Y $contenidos.evento.cifrado == verdadero
En algunos casos, el sistema operativo puede proporcionar información a los sensores 205 sobre si un archivo está cifrado. En otros casos, se puede usar un detector de cifrado, donde el detector de cifrado diferencia entre archivos cifrados, sin cifrar y comprimidos basándose en una combinación de técnicas matemáticas, como el análisis de entropía, distribución de chi cuadrado, análisis de monte carlo pi, etc.
Un segundo bloque lógico puede concatenarse al primer bloque lógico y puede definirse para determinar si, cuando la etiqueta CifradoNoConfiable está presente, el proceso responsable de ese cifrado no confiable de un archivo ha cifrado rápidamente múltiples archivos:
$etiquetas.evento.contiene("CifradoNoConfiable") Y
[el estado de sistema indica > X archivos cifrados en los últimos Y segundos por ese proceso]
Se apreciará que en el ejemplo anterior, la estructura de datos de "etiquetas" para el evento se usa para mantener etiquetas de eventos para el evento a medida que el evento se abre paso a través del sistema de seguridad basado en motor de juego. Si el predicado incorporado por el segundo bloque lógico se evalúa como verdadero, entonces se ha detectado una amenaza de tipo ransomware y se pueden activar accionadores particulares para tomar las acciones apropiadas.
En otro ejemplo, las técnicas de seguridad informática basadas en motor de juego divulgadas pueden configurarse para detectar comportamiento de amenaza persistente avanzada (APT). Un ejemplo de una amenaza APT es Windshift, una amenaza macOS® que infecta los sistemas usando una combinación de navegadores web que abren automáticamente los archivos descargados, registrando un manejador de URL personalizado e iniciando una aplicación. macOS® es una marca registrada de Apple Computer, Inc. de Cupertino, Ca . Para detectar una amenaza similar a Windshift, se puede usar una primera regla para detectar una apertura automática de un archivo por un navegador web:
$evento.esNuevoDirectorio == verdadero Y
$nombre.proceso.evento == [nombre del navegador]
Puede usarse una segunda regla para detectar un manejador de URL personalizado:
$evento.esNuevoDirectorio == verdadero Y
$archivo.evento.esPaqueteApp == verdadero Y $paquete.archivo.evento.infoDiccionario.TiposURLPaqueteCF != nil
Aunque ciertos ejemplos pueden describirse en el presente documento con respecto a la seguridad macOS®, debe entenderse que esto es solo para ilustración y no debe considerarse limitante.
Puede usarse una tercera regla para detectar un lanzamiento de aplicación. Si las tres reglas han etiquetado el evento o eventos, entonces se puede ordenar a un accionador que tome la acción apropiada (por ejemplo, activar una alerta de que se ha detectado una posible amenaza similar a Windshift).
Como otro ejemplo, las técnicas de seguridad informática basadas en motor de juego divulgadas pueden configurarse para detectar malware tal como o similar a FruitFly, un malware de Mac que pasó desapercibido durante casi quince años. FruitFly exhibió un conjunto específico de comportamientos de tiempo de instalación que pueden detectarse usando la concatenación de reglas/lógica de la presente divulgación. En particular, FruitFly se instaló en una ubicación que le permitiría persistir entre ciclos de reinicio, FruitFly no fue firmado por el proveedor del sistema operativo, y FruitFly utilizaría un binario oculto. Puede usarse una primera regla para detectar la persistencia de elemento de lanzamiento:
$trayectoria.evento COINCIDE [trayectoria(s) de archivo de agentes de lanzamiento persistentes] Y $evento.esNuevoArchivo == verdadero
Puede usarse una segunda regla para determinar si un archivo no está firmado por el proveedor del sistema operativo: !$contenidos.archivo.evento.ComoDict.ArgumentosPrograma[0].InfoFirma([firmante SO])
Se puede usar una tercera regla para determinar si se utiliza un binario oculto (en el siguiente ejemplo, un archivo macOS® oculto se detecta basándose en la propiedad indicadora de su nombre de archivo que comienza con un punto):
"DLanzamiento" EN $etiquetas Y
$contenidos.archiv o. evento.ComoDi ct.ArgumentosPrograma [0] .ComponenteÚltimaTrayectoria. comienza Con
Durante el tiempo de ejecución, FruitFly ejecutó el binario oculto como un proceso sin firmar y soltó una carga útil en una carpeta de uso común para archivos temporales, reglas ilustrativas para las cuales se proporcionan a continuación. FruitFly también accedería a menudo a la cámara de un ordenador y generaría clics sintéticos, ambos de los cuales pueden detectarse de manera similar usando el marco de sensores y la concatenación de reglas de la presente divulgación.
$trayectoria.proceso.evento.ComponenteÚltimaTrayectoria.comienzaCon(".") $trayectoria.proceso.evento.comienzaCon([trayectoriaarchivo para carpeta temporal])
$evento. proceso, etiquetas. contiene ("Sin firmar")
En otro ejemplo, las técnicas de seguridad informática basadas en motor de juego divulgadas pueden configurarse para detectar si un individuo normalmente confiable (por ejemplo, empleado de la empresa) se está comportando de manera que puede amenazar la seguridad de la empresa. Por ejemplo, se puede usar una regla para detectar si un usuario está escribiendo archivos en una unidad extraíble (lo que puede ser una violación de la política de la empresa):
$evento.esNuevo == verdadero Y
$archivo.evento.enMedioExtraíble == verdadero Y
$trayectoria.evento COINCIDE [unidades/trayectoria de volúmenes]
Como otro ejemplo, se puede usar una regla para detectar cuándo un usuario intenta ejecutar un programa con privilegios de seguridad modificados invocando la utilidad sudo:
$trayectoria.evento == "/usr/bin/sudo"
Pueden usarse reglas adicionales para detectar cuándo un empleado toma capturas de pantalla o está realizando cualquier actividad después de las horas de trabajo normales.
En otro ejemplo, se puede configurar una regla para detectar si un archivo intenta borrarse a sí mismo, lo que puede ser una señal de que el archivo puede ser malicioso.
$tipo.evento == borrar.archivo Y $trayectoria.proceso.evento == $trayectoria.evento
Se puede usar una combinación de la regla de autoeliminación y una regla configurada para detectar un cambio en la configuración del sistema de nombres de dominio (DNS) de la interfaz o interfaces de red para detectar amenazas de malware tales como MaMi, un Malware de secuestro de DNS macOS®.
A modo de otro ejemplo más, se puede usar una regla para detectar si se hizo un intento de escribir una carga útil en una ubicación de sistema operativo protegido por la integridad del sistema (SIP).
Debe observarse que los diversos ejemplos y casos de uso descritos en el presente documento son meramente ilustrativos y no deben considerarse limitantes. Las técnicas de la presente divulgación pueden usarse con diversos tipos de dispositivos informáticos, incluyendo, aunque no de forma limitativa, ordenadores de escritorio, portátiles, servidores, tabletas, teléfonos móviles, reproductores multimedia portátiles, dispositivos informáticos ponibles, etc. Las técnicas descritas pueden usarse para diversos sistemas operativos, incluyendo, pero sin limitación macOS®, Windows®, Linux®, sistemas operativos móviles/integrados (por ejemplo, iOS® o Android®), etc. Windows es una marca registrada de Microsoft Corp. de Redmond, WA. Linux es una marca registrada de Linus Torvalds o Boston, MA. iOS es una marca registrada de Cisco Technology, Inc. de San José, CA. Android es una marca registrada de Google Inc. de Mountain View, CA.
La FIG. 4. ilustra un ejemplo particular de un método 400 de seguridad informática basada en motor de juego. En los ejemplos ilustrativos, el método 400 corresponde a operaciones descritas con referencia a las FIGS. 2-3.
A continuación, el método 400 incluye recibir, en un sensor de motor de juego de un dispositivo informático que ejecuta un sistema operativo, primeros datos del sistema operativo que representan la ocurrencia de un evento monitorizado, en 402. Por ejemplo, el sensor 205 puede recibir datos de un sistema operativo, donde esos datos representan la ocurrencia de un evento monitorizado. El método 400 también incluye enviar, desde el sensor de motor de juego, segundos datos correspondientes al evento monitorizado a un controlador lógico del motor de juego, en 404. Por ejemplo, el sensor 205 puede enviar datos de eventos modelados al controlador lógico 215.
El método 400 incluye además determinar, en un primer bloque lógico del controlador lógico del motor de juego basándose en los segundos datos y terceros datos que representan un estado de sistema del dispositivo informático, que se cumple la condición de un primer predicado, en 406. El método 400 incluye determinar, en un segundo bloque lógico del controlador lógico del motor de juego basándose en los segundos datos y los terceros datos, que se cumple la condición de un segundo predicado, en 408. Por ejemplo, diferentes bloques lógicos 216 pueden determinar que se cumplen diversas condiciones de predicado, como se describe con referencia a las FIGS. 2-3.
El método 400 también incluye detectar una amenaza de seguridad informática basándose en que se satisfacen la primera y la segunda condiciones de predicado, en 410. El método 400 incluye además, basándose en la detección de la amenaza de seguridad informática, dar instrucciones a al menos un accionador de motor de juego para realizar al menos una acción en respuesta a la amenaza de seguridad informática, en 412. Por ejemplo, se puede ordenar al accionador 220 que realice una acción en respuesta a la amenaza detectada. Tales acciones pueden incluir actualizar el modelo de estado de sistema 210, generar una alerta, poner en cuarentena un archivo, terminar un proceso, etc.
En aspectos particulares, las técnicas de seguridad informática basadas en motor de juego de la presente divulgación pueden aplicarse en un contexto de gestión de dispositivo móvil (MDM). En los sistemas MDM, un servidor de MDM puede mantener información de pertenencia a grupos basándose en grupos "inteligentes". Como se usa en el presente documento, un grupo "inteligente" puede ser un grupo cuya pertenencia se actualiza dinámicamente en respuesta a ciertos eventos. Para fines de ilustración, un administrador de tecnología de la información (TI) puede crear un grupo que se dirige a un conjunto particular de usuarios (por ejemplo, un grupo de edad particular, un rol laboral particular, etc.). La pertenencia al grupo puede actualizarse dinámicamente a medida que los dispositivos gestionados (por ejemplo, teléfonos móviles, ordenadores tipo tabletas, ordenadores portátiles, televisiones, dispositivos inteligentes, dispositivos de entretenimiento, electrodomésticos, vehículos, dispositivos de navegación, etc.) envían solicitudes de unión a grupo o solicitudes de restablecimiento al servidor de MDM. Como se usa en el presente documento, un "grupo MDM" se refiere a un grupo inteligente.
La FIG. 5 ilustra un ejemplo de un sistema operable para realizar la gestión de dispositivos móviles, y se designa en general con 500. El sistema 500 incluye un servidor de MDM 520. El servidor de MDM 520 está acoplado a un servicio de notificaciones push 530, a un dispositivo móvil 550 y a un dispositivo informático 540. Debería entenderse que el servidor de MDM 520 acoplado a dos dispositivos se proporciona como un ejemplo ilustrativo. En algunos aspectos, el servidor de MDM 520 está acoplado a menos de dos dispositivos o más de dos dispositivos.
El dispositivo informático 540 puede incluir un sistema operativo (SO) 541 y el dispositivo móvil 550 puede incluir un SO móvil 551. Cada SO 541, 551 puede controlar funciones informáticas, tal como entrada/salida (por ejemplo, una pantalla táctil, altavoz, un micrófono, cámara, etc.) y redes (por ejemplo, celular, Bluetooth, fidelidad inalámbrica (Wi-Fi), Ethernet, etc.). Cada SO 541, 551 también puede soportar la ejecución de aplicaciones (apps) 543, 553, 567 y proporcionar tales aplicaciones acceso a recursos y datos de dispositivo 544, 554. Ejemplos de aplicaciones incluyen, aunque sin limitación, un navegador web, correo electrónico, un calendario, redes sociales, un lector de documentos/libros electrónicos, un reproductor multimedia, una aplicación de juego, una aplicación de gestión de pacientes, una solicitud de referencia médica, una herramienta de rastreo de medicación, etc. Las aplicaciones pueden corresponder a instrucciones de software que se almacenan en una memoria y se ejecutan por un procesador, circuitos de hardware que implementan funcionalidad de aplicación, o ambos.
El dispositivo móvil 550 incluye un cliente de gestión de dispositivos 552. En algunos ejemplos, el cliente de gestión de dispositivos 552 está configurado para, en respuesta a recibir una entrada (por ejemplo, entrada de usuario 504 de un usuario 503) que indica que el dispositivo móvil 550 es (o va a ser) parte de un grupo 514, enviar una solicitud de unión a grupo 555 al servidor de MDM 520. El cliente de gestión de dispositivos 552 está configurado para recibir un comando para realizar una acción 557 desde el servidor de MDM 520 y para iniciar la realización de la acción 557. La acción 557 incluye, por ejemplo, descargar la una o más aplicaciones 567 asociadas con el grupo 514, descargar uno o más ajustes de configuración 565, etc. En algunas implementaciones, enviar la solicitud de unión a grupo 555 que indica que el grupo 514 no provoca la eliminación, en el dispositivo móvil 550, de aplicaciones, datos o una combinación de los mismos, asociada con cualquier grupo diferente del grupo 514. En otras implementaciones, enviar la solicitud de unión a grupo 555 que indica que el grupo 514 inicia la eliminación, en el dispositivo móvil 550, de aplicaciones, datos o una combinación de los mismos, asociada con uno o más grupos diferentes del grupo 514. Por ejemplo, la solicitud de unión a grupo 555 inicia la eliminación de aplicaciones y datos asociados con grupos distintos del grupo 514, mientras que una solicitud de restablecimiento 585 inicia la eliminación de todas las aplicaciones, todos los datos, el SO móvil 551, el cliente de gestión de dispositivos 552, o una combinación de los mismos.
El dispositivo informático 540 también incluye una copia del cliente de gestión de dispositivos 552. El cliente de gestión de dispositivos 552 del dispositivo informático 540 está configurado para, en respuesta a la recepción de una notificación de inserción 531 desde el servicio de notificaciones push 530, iniciar la realización de un evento de registro 546 enviando una solicitud de registro al servidor de MDM 520.
En un aspecto específico, el cliente de gestión de dispositivos 552 corresponde a un procesador configurado para realizar una o más operaciones descritas en el presente documento. En un aspecto específico, el cliente de gestión de dispositivos 552 corresponde a instrucciones que, cuando se ejecutan por un procesador, hacen que el procesador realice una o más operaciones descritas en el presente documento. En un aspecto específico, el cliente de gestión de dispositivos 552 corresponde a un dispositivo de almacenamiento legible por ordenador que almacena instrucciones que son ejecutables para realizar una o más operaciones descritas en el presente documento.
El servidor de MDM 520 incluye una memoria 523, un gestor de dispositivos móviles 534, o ambos. La memoria 523 está configurada para almacenar datos de pertenencia a grupos 528 e identificadores de dispositivo 512 de dispositivos gestionados. Los datos de pertenencia a grupos 528 indican acciones a realizar para grupos particulares, dispositivos incluidos en un grupo, o una combinación de los mismos. Por ejemplo, el gestor de dispositivos móviles 534 está configurado para, en respuesta a recibir la solicitud de unión a grupo 555 desde el dispositivo móvil 550 y determinar que la solicitud de unión a grupo 555 indica el grupo 514, actualizar los datos de pertenencia al grupo 528 para añadir el dispositivo móvil 550 al grupo 514. El gestor de dispositivos móviles 534 está configurado para enviar un comando al dispositivo móvil 550 que indica que se va a realizar la acción 557.
En un aspecto específico, el gestor de dispositivos móviles 534 corresponde a un procesador configurado para realizar una o más operaciones descritas en el presente documento. En un aspecto específico, el gestor de dispositivos móviles 534 corresponde a instrucciones que, cuando se ejecutan por un procesador, hacen que el procesador realice una o más operaciones descritas en el presente documento. En un aspecto específico, el gestor de dispositivos móviles 534 corresponde a un dispositivo de almacenamiento legible por ordenador que almacena instrucciones que son ejecutables para realizar una o más operaciones descritas en el presente documento.
Durante el funcionamiento, un usuario 501 (por ejemplo, un administrador de TI) configura uno o más grupos en el servidor de MDM. Por ejemplo, el usuario 501 proporciona la entrada de usuario 502 al servidor de MDM 520 que indica el grupo 514, uno o más grupos adicionales, o una combinación de los mismos. La entrada de usuario 502 indica nombres de los grupos, acciones correspondientes a los grupos, o una combinación de los mismos. Por ejemplo, la entrada de usuario 502 indica un nombre de grupo (por ejemplo, "Enfermería") del grupo 514. En un ejemplo ilustrativo, el grupo 514 se basa en un rol de laboral (por ejemplo, enfermero/a, técnico de laboratorio, médico o gerente). El usuario 501 puede configurar el grupo 514 basándose en cualquier criterio. Por ejemplo, el usuario 501 puede configurar el grupo 514 basándose en la edad, género, rol laboral, ubicación, habilidad, relación, otros criterios, o una combinación de los mismos. La entrada de usuario 502 indica la acción 557 a realizar sobre un dispositivo que se une al grupo 514. Por ejemplo, la entrada de usuario 502 indica que los miembros del grupo 514 están autorizados a acceder a las aplicaciones 567, que los miembros del grupo 514 no están autorizados a acceder (por ejemplo, tienen restringido el acceso) a las aplicaciones 553, o una combinación de las mismas. En un aspecto específico, la entrada de usuario 502 indica los ajustes de configuración 565. La acción 557 indica la descarga de las aplicaciones 567, la descarga de los ajustes de configuración 565, generar una GUI que incluye iconos de las aplicaciones 567, generar una GUI que excluye iconos de aplicaciones 553 asociados con un grupo diferente (por ejemplo, "Médicos"), borrar (o desinstalar) las aplicaciones 553, o una combinación de los mismos.
En diversos aspectos, la entrada de usuario 502 puede indicar acciones a realizar por dispositivos cuando se añade un nuevo miembro al grupo 514 o cuando un miembro abandona un grupo. Los datos de pertenencia al grupo 528 pueden actualizarse cuando un dispositivo se une o abandona un grupo. Los dispositivos pueden agruparse generalmente basándose en cualquier criterio. Los ejemplos de criterios de agrupación incluyen, aunque sin limitación, una capacidad de dispositivo, un componente de dispositivo, un estado de dispositivo, un nivel de batería del dispositivo, un espacio de memoria de dispositivo, un sistema operativo de dispositivo, una versión de software de dispositivo, un tipo de dispositivo, una ubicación de dispositivo, etc. En algunos ejemplos, una lista de grupos 563 es mantenida por el servidor de MDM 520 y comunicada a otros dispositivos en el sistema 500, por ejemplo, en respuesta a una solicitud de actualización 561. En otro ejemplo, las notificaciones push 531, 533 se inician a través de una solicitud de notificación 524 y se usan para hacer que los dispositivos inicien eventos de registro 583, 546 con el servidor de MDM 520, que puede comunicar una lista de grupos actualizada 563 a los dispositivos en respuesta a los registros. También se pueden comunicar otros comandos a los dispositivos cuando se registran. Por ejemplo, el servidor de MDM 520 puede enviar acciones 547, 548 que hacen que los dispositivos descarguen/instalen/desinstalen aplicaciones o archivos, implementar ajustes de configuración, establecer un bloqueo de activación, modificar la pertenencia a un grupo inteligente, etc. En algunos casos, se puede usar un comando de restablecimiento 587 para activar el restablecimiento de fábrica en un dispositivo. En algunos casos, el comando de restablecimiento 587 puede enviarse en respuesta a una solicitud de restablecimiento 585.
Mientras que algunos de los casos de uso anteriores se describen para la seguridad informática en un solo dispositivo, el sistema 500 de la FIG. 5 puede habilitar seguridad informática basada en motor de juego basándose en la entrada de sensor y/o acciones correspondientes a múltiples dispositivos. Por ejemplo, el servidor de MDM 520 puede incluir uno o más componentes de un sistema de seguridad basado en motor de juego, y tal(es) componente(s) se designan en 590. Para fines de ilustración, el servidor de MDM 520 puede incluir uno o más de los sensores 205, el modelo de estado de sistema 210, el controlador lógico 215, los bloques lógicos 216 y/o los accionadores 220. En un ejemplo particular, el servidor de MDM 520 incluye accionadores y está configurado para iniciar acciones con respecto a uno o más dispositivos gestionados. En algunos ejemplos, los sensores y los controladores/bloques lógicos pueden ubicarse de forma remota al servidor de MDM 520, tal como en dispositivos gestionados u otros servidores. En una implementación alternativa, el servidor de MDM 520 incluye al menos algunos de los controladores/bloques lógicos del motor de juego.
El sistema de seguridad basado en motor de juego puede recibir una entrada de sensor desde múltiples dispositivos en el sistema 500, tal como el dispositivo informático 540 y el dispositivo móvil 550. Pueden definirse reglas lógicas para evaluar predicados basándose en datos correspondientes a múltiples dispositivos, que pueden estar o no en el mismo grupo inteligente. El estado de sistema considerado durante la evaluación de reglas puede incluir información de estado asociada con múltiples dispositivos gestionados. Las acciones de respuesta de seguridad pueden tomarse en múltiples dispositivos, que pueden o no estar en el mismo grupo. Por tanto, en algunos casos, a múltiples dispositivos gestionados se les puede enviar un comando para realizar una acción basándose en un evento monitorizado que se produce en menos de todos (o quizás ninguno) de esos dispositivos gestionados. De manera similar, los eventos de múltiples dispositivos gestionados pueden agregarse para identificar una amenaza de seguridad (por ejemplo, un ataque de denegación de servicio distribuido (DDoS) o actividad de botnet) que puede ser difícil de identificar usando eventos que ocurren en un solo dispositivo.
A modo de ejemplo no limitativo ilustrativo, si se detecta una amenaza de tipo ransomware en un dispositivo, otros dispositivos en el sistema que no están actualmente en uso pueden conmutarse a una red secundaria que está aislada del dispositivo infectado. En otro ejemplo no limitativo ilustrativo, si múltiples dispositivos en un grupo inteligente "Florida" casi no tienen ciclos informáticos inactivos, se puede detectar malware de criptominería, que indica que los dispositivos distribuidos a los empleados de una sucursal de Florida de una empresa se han infectado, probablemente a través de un vector de infección localizado.
En algunos ejemplos, las reglas predicadas del sistema de seguridad basado en motor de juego no están codificadas de forma rígida y, en su lugar, se pueden ajustar dinámicamente en tiempo de ejecución. Los conjuntos de reglas pueden combinarse en "perfiles" de seguridad y tales perfiles pueden conmutarse/ajustarse dinámicamente basándose en la operación en el sistema de seguridad basado en motor de juego. Para fines de ilustración, un accionador puede tomar una acción para ajustar el perfil de seguridad en uso en uno o más dispositivos de modo que la evaluación general de la regla sea más o menos agresiva. A modo de ejemplo, si se identifica actividad potencialmente sospechosa en un dispositivo gestionado, otros dispositivos gestionados que se encuentren en el área o en la misma red pueden cambiar a un perfil de seguridad más agresivo (por ejemplo, más estricto) y aumentar la verbosidad de los eventos y alertas registrados. Como otro ejemplo, las reglas pueden incluirse/excluirse dinámicamente de la canalización de evaluación de reglas en respuesta a una acción tomada por un accionador. A modo de otro ejemplo más, un parámetro de una regla (por ejemplo, un umbral contra el que se comparan los datos de evento) puede ajustarse dinámicamente basándose en respuesta a una acción tomada por un accionador. Para fines de ilustración, cuando los valores de confianza están en uso y se detecta una amenaza de seguridad, puede reducirse el umbral en el que se determina que una confianza agregada corresponde a actividad sospechosa.
Las reglas/perfiles también pueden ajustarse dinámicamente basándose en ciertos eventos detectados. Por ejemplo, se pueden usar perfiles más o menos agresivos basándose en datos de ubicación de GPS o datos de red que indican que un dispositivo está conectado a la red doméstica, una red de oficinas, una red desconocida, una red abierta/no segura/pública, etc. Debe entenderse que los ejemplos anteriores con respecto al ajuste dinámico de reglas/perfiles pueden implementarse dentro del contexto de MDM (por ejemplo, como se describe con referencia a la FIG. 5) y también sin implicación de los principios de MDM (por ejemplo, como se describe con referencia a las FIGS. 2-4).
El sistema 500 de la FIG. 5 puede habilitar por tanto la seguridad informática basada en motor de juego para dispositivos informáticos gestionados, incluyendo la detección de amenazas de seguridad basándose en la entrada del sensor desde múltiples dispositivos y la realización de acciones de respuesta en múltiples dispositivos.
Aunque una o más de las FIGS. 1-5 pueden ilustrar sistemas, dispositivos y/o métodos de acuerdo con las enseñanzas de la divulgación, la divulgación no se limita a estos sistemas, dispositivos y/o métodos ilustrados. Los aspectos de la divulgación pueden emplearse adecuadamente en cualquier dispositivo que incluya circuitería integrada incluyendo memoria, un procesador y circuitería en chip.
Una o más funciones o componentes de cualquiera de las FIGS. 1-5 como se ilustra o describe en el presente documento puede combinarse con una o más porciones de otra de las FIGS. 1-5. En consecuencia, ningún aspecto individual descrito en el presente documento debe interpretarse como limitante y los aspectos de la divulgación pueden combinarse adecuadamente sin apartarse de las enseñanzas de la divulgación.
Los expertos apreciarán además que los diversos bloques lógicos, configuraciones, módulos, circuitos y etapas de algoritmo ilustrativas descritos en relación con los aspectos divulgados en el presente documento pueden implementarse como hardware electrónico, software informático ejecutado por un procesador, o combinaciones de ambos. Diversos componentes, bloques, configuraciones, módulos, circuitos y etapas ilustrativas se han descrito anteriormente en general en términos de su funcionalidad. Si dicha funcionalidad se implementa como hardware o instrucciones ejecutables por procesador depende de la aplicación particular y las restricciones de diseño impuestas en el sistema global. Los expertos en la materia pueden implementar la funcionalidad descrita de diversas maneras para cada aplicación particular, pero tales decisiones de implementación no deben interpretarse como que provocan una desviación del alcance de la presente divulgación.
Las etapas de un método o algoritmo descritos en relación con los aspectos divulgados en el presente documento pueden incorporarse directamente en hardware, en un módulo de software ejecutado por un procesador, o en una combinación de ambos. Un módulo de software puede residir en una memoria de acceso aleatorio (RAM), memoria flash, memoria de solo lectura (ROM), memoria de solo lectura programable (PROM), memoria de solo lectura programable y borrable (EPROM), memoria de solo lectura programable y borrable eléctricamente (EEPROM), registros, disco duro, un disco extraíble, una memoria de solo lectura de disco compacto (CD-ROM) o cualquier otra forma de medio de almacenamiento no transitorio conocido en la técnica. Un medio de almacenamiento ilustrativo (por ejemplo, un dispositivo de almacenamiento legible por ordenador) está acoplado al procesador de tal manera que el procesador puede leer información de, y escribir información en, el medio de almacenamiento. Como una alternativa, el medio de almacenamiento puede ser integral al procesador. El procesador y el medio de almacenamiento pueden residir en un circuito integrado de aplicación específica (ASIC). El ASIC puede residir en un dispositivo informático o un terminal de usuario. Como una alternativa, el procesador y el medio de almacenamiento pueden residir como componentes discretos en un dispositivo informático o terminal de usuario. Un dispositivo de almacenamiento no es una señal.
En un aspecto, se divulga un método de seguridad implementado por ordenador que incluye configurar uno o más sensores de motor de juego para detectar uno o más eventos, el uno o más sensores de motor de juego acoplados en comunicación con un motor de juego. El método también incluye configurar el motor de juego para: mantener uno o más estados que representan una situación de seguridad; recibir uno o más eventos detectados por el uno o más sensores de motor de juego; actualizar uno o más estados basándose en el uno o más eventos detectados por el uno o más sensores de motor de juego; e iniciar una acción una vez que se alcanza un estado definido. En algunos aspectos, los eventos son eventos a nivel de sistema operativo. En algunos aspectos, los eventos de nivel de sistema operativo incluyen uno o más de: eventos de sistema de archivos, eventos de proceso, eventos de red, eventos de autenticación, eventos de autorización, eventos de descarga, eventos de captura de pantalla, eventos de medios extraíbles, eventos de entrada sintéticos, eventos de volumen, eventos de actividad de usuario, eventos de cámara web o eventos de micrófono. En algunos aspectos, los estados se representan por asociación con una o más etiquetas. En aspectos adicionales, al menos uno de los estados definidos requiere una pluralidad de etiquetas.
En otro aspecto, un método incluye recibir, en un sensor de motor de juego de un dispositivo informático que ejecuta un sistema operativo, primeros datos del sistema operativo que representan la ocurrencia de un evento monitorizado. El método también incluye enviar, desde el sensor de motor de juego, segundos datos correspondientes al evento monitorizado a un controlador lógico del motor de juego. El método incluye además determinar, en un primer bloque lógico del controlador lógico del motor de juego basándose en los segundos datos y terceros datos que representan un estado de sistema del dispositivo informático, que se cumple la condición de un primer predicado. El método incluye determinar, en un segundo bloque lógico del controlador lógico del motor de juego basándose en los segundos datos y los terceros datos, que se cumple la condición de un segundo predicado. El método también incluye detectar una amenaza de seguridad informática basándose en que se satisfacen la primera y la segunda condiciones de predicado. El método incluye, además, basándose en la detección de la amenaza de seguridad informática, dar instrucciones a al menos un accionador de motor de juego para realizar al menos una acción en respuesta a la amenaza de seguridad informática.
En otro aspecto, un sistema incluye al menos un procesador y una memoria que almacena instrucciones ejecutables por el al menos un procesador para recibir, en un sensor de motor de juego, primeros datos de un sistema operativo que representan la ocurrencia de un evento monitorizado. Las instrucciones también son ejecutables para enviar, desde el sensor de motor de juego, segundos datos correspondientes al evento monitorizado a un controlador lógico de motor de juego. Las instrucciones son además ejecutables para determinar, en un primer bloque lógico del controlador lógico del motor de juego basándose en los segundos datos y terceros datos que representan un estado de sistema asociado con el dispositivo informático, que se cumple la condición de un primer predicado. Las instrucciones son ejecutables para determinar, en un segundo bloque lógico del controlador lógico del motor de juego basándose en los segundos datos y los terceros datos, que se cumple la condición de un segundo predicado. Las instrucciones también son ejecutables para detectar una amenaza de seguridad informática basándose en que se satisfacen la primera y la segunda condiciones de predicado. Las instrucciones son además ejecutables para, basándose en la detección de la amenaza de seguridad informática, dar instrucciones a al menos un accionador de motor de juego para realizar al menos una acción en respuesta a la amenaza de seguridad informática.
En otro aspecto, un dispositivo de almacenamiento legible por ordenador almacena instrucciones que, cuando se ejecutan, hacen que al menos un procesador realice operaciones que incluyen recibir, en un sensor de motor de juego, primeros datos de un sistema operativo que representan la ocurrencia de un evento monitorizado. Las operaciones también incluyen enviar, desde el sensor de motor de juego, segundos datos correspondientes al evento monitorizado a un controlador lógico del motor de juego. Las operaciones incluyen además determinar, en un primer bloque lógico del controlador lógico del motor de juego basándose en los segundos datos y terceros datos que representan un estado de sistema asociado con el dispositivo informático, que se cumple la condición de un primer predicado. Las operaciones incluyen determinar, en un segundo bloque lógico del controlador lógico del motor de juego basándose en los segundos datos y los terceros datos, que se cumple la condición de un segundo predicado. Las operaciones también incluyen detectar una amenaza de seguridad informática basándose en que se satisfacen la primera y la segunda condiciones de predicado. Las operaciones incluyen además, basándose en la detección de la amenaza de seguridad informática, dar instrucciones a al menos un accionador de motor de juego para realizar al menos una acción en respuesta a la amenaza de seguridad informática.
La descripción anterior de los aspectos divulgados se proporciona para permitir que cualquier persona experta en la materia haga o use los aspectos divulgados. Diversas modificaciones a estos aspectos serán fácilmente evidentes para los expertos en la materia, y los principios definidos en el presente documento se pueden aplicar a otros aspectos sin apartarse del alcance de la divulgación. Por tanto, la presente divulgación no pretende limitarse a los aspectos mostrados en el presente documento, sino que debe otorgarse el alcance más amplio posible consistente con los principios y características novedosas definidos en las siguientes reivindicaciones.

Claims (12)

REIVINDICACIONES
1. Un método (400) de seguridad informática basada en motor de juego, usando el método (400) componentes de una arquitectura de motor de juego, comprendiendo los componentes un sensor de motor de juego, un controlador lógico del motor de juego y al menos un accionador lógico de motor de juego, que comprende:
recibir (402), en dicho sensor de motor de juego (205) de un dispositivo informático que ejecuta un
sistema operativo, primeros datos del sistema operativo que representan la ocurrencia de un evento monitorizado, en donde los primeros datos comprenden datos de evento que indican una actualización a un estado de sistema asociado con el dispositivo informático acerca del evento monitorizado;
enviar (404), desde el sensor del motor de juego (205), segundos datos correspondientes al evento monitorizado a dicho controlador lógico del motor de juego (215), que comprende bloques lógicos (216), representando cada bloque lógico un predicado respectivo,
en donde los segundos datos son datos de evento modelados como una representación de los datos de evento compatibles con un modelo de estado de sistema (210);
determinar (406), en un primer bloque lógico (216) del controlador lógico (215) del motor de juego basándose en los segundos datos y terceros datos que representan el estado de sistema asociado con el dispositivo informático, que se cumple la condición de un primer predicado;
determinar (408), en un segundo bloque lógico (216) del controlador lógico (215) del motor de juego basándose en los segundos datos y los terceros datos, que se cumple la condición de un segundo predicado, en donde el primer y el segundo bloques lógicos están configurados para concatenarse juntos de tal manera que una salida del primer bloque lógico se proporciona como entrada al segundo bloque lógico;
detectar (410) una amenaza de seguridad informática basándose en que se cumplen la primer y segunda condiciones de predicado concatenadas; y
basándose en la detección de la amenaza de seguridad informática, dar instrucciones (412) a dicho al menos un accionador de motor de juego (220) para realizar al menos una acción en respuesta a la amenaza de seguridad informática, en donde los segundos datos incluyen un tipo del evento monitorizado, una trayectoria del evento monitorizado, información de directorio asociada con el evento monitorizado, información de aplicación asociada con el evento monitorizado, o cualquier combinación de los mismos;
o
en donde los segundos datos incluyen información con respecto a un archivo asociado con el evento monitorizado, si el archivo se modifica, información sobre el contenido del archivo, o cualquier combinación de los mismos,
o en donde los segundos datos incluyen información con respecto a un proceso de ejecución asociado con el evento monitorizado,
o en donde los segundos datos incluyen datos de etiqueta asociados con el evento monitorizado, siendo determinados los datos de etiqueta por el primer o el segundo bloque lógico.
2. El método (400) de la reivindicación 1, en donde el sensor de motor de juego (205) comprende un monitor de sistema de archivo, un monitor de proceso, un monitor de autenticación, un monitor de descarga, un monitor de captura de pantalla, un monitor de medios extraíbles, un monitor de clic sintético, un monitor de volumen,
un monitor de reanudación de actividad de usuario, un monitor de cámara, un monitor de micrófono y/o cualquier combinación de los mismos.
3. El método (400) de la reivindicación 1, en donde si los segundos datos incluyen datos de etiqueta asociados con el evento monitorizado, el segundo bloque lógico (216) determina que se cumple la segunda condición de predicado basándose al menos en parte en una determinación de que los datos de etiqueta incluyen una primera etiqueta añadida a los datos de etiqueta por el primer bloque lógico (216).
4. El método (400) de la reivindicación 1, en donde la al menos una acción comprende actualizar el estado de sistema o
en donde la al menos una acción comprende generar una alerta o
en donde la al menos una acción comprende poner en cuarentena un archivo, borrar un archivo, recopilar datos adicionales con respecto al evento monitorizado, terminar un proceso, ajustar un cortafuegos, terminar una conexión de red, o cualquier combinación de los mismos.
5. El método (400) de la reivindicación 1, en donde el controlador lógico del motor de juego (215) es ejecutado por un servidor de gestión de dispositivos móviles (MDM) (520), y en donde el evento monitorizado tiene lugar en un primer dispositivo informático gestionado lejos del servidor de<m>D<m>.
6. El método (400) de la reivindicación 5, en donde se produce un segundo evento monitorizado en un segundo dispositivo informático gestionado, y en donde la amenaza a la seguridad informática se detecta adicionalmente basándose en la aparición del segundo evento monitorizado, o
en donde el estado de sistema comprende información de estado asociada con una pluralidad de dispositivos informáticos gestionados.
7. El método (400) de la reivindicación 1, en donde la al menos una acción comprende iniciar el envío de un comando a una pluralidad de dispositivos informáticos gestionados.
8. El método (400) de la reivindicación 1, que comprende además consultar el estado de sistema basándose en al menos una porción de los segundos datos.
9. Un sistema (200) que comprende componentes de una arquitectura de motor de juego, comprendiendo los componentes un sensor de motor de juego, un controlador lógico del motor de juego y al menos un accionador lógico de motor de juego, el dispositivo de almacenamiento legible por ordenador, comprendiendo además el sistema (200):
al menos un procesador; y
una memoria que almacena instrucciones ejecutables por el al menos un procesador para:
recibir, en dicho sensor de motor de juego (205), primeros datos de un sistema operativo que representan la ocurrencia de un evento monitorizado, en donde los primeros datos comprenden datos de evento que indican una actualización a un estado de sistema asociado con un dispositivo informático acerca del evento monitorizado;
enviar, desde el sensor del motor de juego (205), segundos datos correspondientes al evento monitorizado a dicho controlador lógico del motor de juego (215), que comprende bloques lógicos (216), representando cada bloque lógico un predicado respectivo,
en donde los segundos datos son datos de evento modelados como una representación de los datos de evento compatibles con un modelo de estado de sistema (210);
determinar, en un primer bloque lógico (216) del controlador lógico (215) del motor de juego basándose en los segundos datos y terceros datos que representan el estado de sistema asociado con el dispositivo informático, que se cumple la condición de un primer predicado;
determinar, en un segundo bloque lógico (216) del controlador lógico (215) del motor de juego basándose en los segundos datos y los terceros datos, que se cumple la condición de un segundo predicado, en donde el primer y el segundo bloques lógicos están configurados para concatenarse juntos de tal manera que una salida del primer bloque lógico se proporciona como entrada al segundo bloque lógico;
detectar una amenaza de seguridad informática basándose en que se cumplen la primer y segunda condiciones de predicado concatenadas; y
basándose en la detección de la amenaza de seguridad informática, dar instrucciones a dicho al menos un accionador de motor de juego (220) para realizar al menos una acción en respuesta a la amenaza de seguridad informática, en donde los segundos datos incluyen un tipo del evento monitorizado, una trayectoria del evento monitorizado, información de directorio asociada con el evento monitorizado, información de aplicación asociada con el evento monitorizado, o cualquier combinación de los mismos;
o
en donde los segundos datos incluyen información con respecto a un archivo asociado con el evento monitorizado, si el archivo se modifica, información sobre el contenido del archivo, o cualquier combinación de los mismos,
o en donde los segundos datos incluyen información con respecto a un proceso de ejecución asociado con el evento monitorizado,
o en donde los segundos datos incluyen datos de etiqueta asociados con el evento monitorizado, siendo determinados los datos de etiqueta por el primer o el segundo bloque lógico.
10. El sistema (200) de la reivindicación 9, que comprende además un servidor de gestión de dispositivos móviles (MDM) (520) que incluye el al menos un procesador y la memoria.
11. El sistema (200) de la reivindicación 10, en donde el evento monitorizado se produce en un primer dispositivo informático gestionado lejos del servidor de MDM (520), y en donde la al menos una acción comprende iniciar el envío de un comando a un segundo dispositivo informático gestionado que es distinto del primer dispositivo informático gestionado.
12. Un dispositivo de almacenamiento legible por ordenador, que comprende componentes de una arquitectura de motor de juego, comprendiendo los componentes un sensor de motor de juego, un controlador lógico del motor de juego y al menos un accionador lógico de motor de juego, almacenando el dispositivo de almacenamiento legible por ordenador instrucciones que, cuando se ejecutan, hacen que al menos un procesador realice operaciones que comprenden:
recibir, en dicho sensor de motor de juego (205), primeros datos de un sistema operativo que representan la ocurrencia de un evento monitorizado, en donde los primeros datos comprenden datos de evento que indican una actualización a un estado de sistema asociado con un dispositivo informático acerca del evento monitorizado; enviar, desde el sensor del motor de juego (205), segundos datos correspondientes al evento monitorizado a dicho controlador lógico del motor de juego (215), que comprende bloques lógicos (216), representando cada bloque lógico un predicado respectivo,
en donde los segundos datos son datos de evento modelados como una representación de los datos de evento compatibles con un modelo de estado de sistema (210);
determinar, en un primer bloque lógico (216) del controlador lógico (215) del motor de juego basándose en los segundos datos y terceros datos que representan el estado de sistema asociado con el dispositivo informático, que se cumple la condición de un primer predicado;
determinar, en un segundo bloque lógico (216) del controlador lógico (215) del motor de juego basándose en los segundos datos y los terceros datos, que se cumple la condición de un segundo predicado, en donde el primer y el segundo bloques lógicos están configurados para concatenarse juntos de tal manera que una salida del primer bloque lógico se proporciona como entrada al segundo bloque lógico
detectar una amenaza de seguridad informática basándose en que se cumplen la primer y segunda condiciones de predicado concatenadas; y
basándose en la detección de la amenaza de seguridad informática, dar instrucciones a dicho al menos un accionador de motor de juego (220) para realizar al menos una acción en respuesta a la amenaza de seguridad informática, en donde los segundos datos incluyen un tipo del evento monitorizado, una trayectoria del evento monitorizado, información de directorio asociada con el evento monitorizado, información de aplicación asociada con el evento monitorizado, o cualquier combinación de los mismos;
o
en donde los segundos datos incluyen información con respecto a un archivo asociado con el evento monitorizado, si el archivo se modifica, información sobre el contenido del archivo, o cualquier combinación de los mismos,
o en donde los segundos datos incluyen información con respecto a un proceso de ejecución asociado con el evento monitorizado,
o en donde los segundos datos incluyen datos de etiqueta asociados con el evento monitorizado, siendo determinados los datos de etiqueta por el primer o el segundo bloque lógico.
ES19846733T 2018-08-07 2019-08-06 Game engine-based computer security Active ES3013809T3 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201862715627P 2018-08-07 2018-08-07
PCT/US2019/045375 WO2020033457A1 (en) 2018-08-07 2019-08-06 Game engine-based computer security

Publications (1)

Publication Number Publication Date
ES3013809T3 true ES3013809T3 (en) 2025-04-15

Family

ID=69406002

Family Applications (1)

Application Number Title Priority Date Filing Date
ES19846733T Active ES3013809T3 (en) 2018-08-07 2019-08-06 Game engine-based computer security

Country Status (7)

Country Link
US (1) US11599638B2 (es)
EP (1) EP3833458B1 (es)
JP (1) JP7431844B2 (es)
AU (2) AU2019317441A1 (es)
ES (1) ES3013809T3 (es)
PL (1) PL3833458T3 (es)
WO (1) WO2020033457A1 (es)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020142651A1 (en) * 2019-01-04 2020-07-09 Proofpoint, Inc. Context based authorized external device copy detection
US20220180173A1 (en) * 2020-12-07 2022-06-09 Nvidia Corporation Graphics processing units for detection of cheating using neural networks

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7878905B2 (en) 2000-02-22 2011-02-01 Creative Kingdoms, Llc Multi-layered interactive play experience
US20080214300A1 (en) 2000-12-07 2008-09-04 Igt Methods for electronic data security and program authentication
US7814021B2 (en) * 2003-01-23 2010-10-12 Verdasys, Inc. Managed distribution of digital assets
CA2464788A1 (en) * 2003-04-16 2004-10-16 Wms Gaming Inc. A gaming software distribution network in a gaming system environment
US8777737B2 (en) 2006-04-13 2014-07-15 Igt Method and apparatus for integrating remotely-hosted and locally rendered content on a gaming device
US8926435B2 (en) 2008-12-15 2015-01-06 Sony Computer Entertainment America Llc Dual-mode program execution
US9087195B2 (en) * 2009-07-10 2015-07-21 Kaspersky Lab Zao Systems and methods for detecting obfuscated malware
US20170099592A1 (en) * 2014-05-30 2017-04-06 Interdigital Technology Corporation Personalized notifications for mobile applications users
US9647897B2 (en) * 2014-08-20 2017-05-09 Jamf Software, Llc Dynamic grouping of managed devices
US9542799B2 (en) * 2014-12-12 2017-01-10 Synergy Blue, Llc Hybrid arcade-type, wager-based gaming techniques and predetermined RNG outcome batch retrieval techniques
US9454993B1 (en) * 2015-10-09 2016-09-27 Sports Logic Group, LLC System capable of integrating user-entered game event data with corresponding video data
US9984248B2 (en) 2016-02-12 2018-05-29 Sophos Limited Behavioral-based control of access to encrypted content by a process
US20190081963A1 (en) * 2017-09-08 2019-03-14 Sophos Limited Realtime event detection

Also Published As

Publication number Publication date
JP2021536088A (ja) 2021-12-23
US11599638B2 (en) 2023-03-07
EP3833458B1 (en) 2025-01-29
EP3833458A4 (en) 2022-04-20
US20200050763A1 (en) 2020-02-13
AU2025202447A1 (en) 2025-04-24
WO2020033457A1 (en) 2020-02-13
PL3833458T3 (pl) 2025-05-26
AU2019317441A1 (en) 2021-04-01
JP7431844B2 (ja) 2024-02-15
EP3833458A1 (en) 2021-06-16

Similar Documents

Publication Publication Date Title
US11853414B2 (en) Mitigation of return-oriented programming attacks
US10924517B2 (en) Processing network traffic based on assessed security weaknesses
US10972483B2 (en) Electronic mail security using root cause analysis
Shabtai et al. Google android: A state-of-the-art review of security mechanisms
US20190190936A1 (en) Electronic mail security using a heartbeat
Hassan Ransomware revealed
GB2551983A (en) Perimeter encryption
GB2551813A (en) Mobile device policy enforcement
KR20140033349A (ko) 가상 머신 모니터 기반 안티 악성 소프트웨어 보안 시스템 및 방법
Pareek et al. Application whitelisting: approaches and challenges
Goni et al. A study on cyber security: Analyzing current threats, navigating complexities, and implementing prevention strategies
AU2025202447A1 (en) Game engine-based computer security
Sabharwal et al. Ransomware attack: India issues red alert
Rao et al. Malicious software and anti-virus software
US11275828B1 (en) System, method, and apparatus for enhanced whitelisting
Alshaikh et al. Crypto-ransomware detection and prevention techniques and tools a survey
GB2572471A (en) Detecting lateral movement by malicious applications
Caruso Forensic Analysis of Mobile Spyware: Investigating Security, Vulnerabilities, and Detection Challenges in Android and iOS Platforms
DeMara et al. Mitigation of network tampering using dynamic dispatch of mobile agents
SakthiMurugan et al. Advanced Privilege Escalation Prevention System for Windows
Major A Taxonomic Evaluation of Rootkit Deployment, Behavior and Detection
Lombardi et al. Heterogeneous architectures: Malware and countermeasures
Phanireddy Mitigating Supply Chain Attacks in Web Applications: A Case Study on Log4j and Spring4shell
Sahay et al. Secure Knowledge Management In Artificial Intelligence Era
Jauhiainen et al. Ensuring system integrity and security on limited environment systems