MX2014009046A - Administracion operativa centralizada. - Google Patents

Administracion operativa centralizada.

Info

Publication number
MX2014009046A
MX2014009046A MX2014009046A MX2014009046A MX2014009046A MX 2014009046 A MX2014009046 A MX 2014009046A MX 2014009046 A MX2014009046 A MX 2014009046A MX 2014009046 A MX2014009046 A MX 2014009046A MX 2014009046 A MX2014009046 A MX 2014009046A
Authority
MX
Mexico
Prior art keywords
security
application
document
operations
operating system
Prior art date
Application number
MX2014009046A
Other languages
English (en)
Other versions
MX353868B (es
Inventor
Peter Kiehtreiber
Jacques A Vidrine
Christopher S Linn
Randy D Saldinger
Braden J Thomas
Original Assignee
Apple Inc
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 Apple Inc filed Critical Apple Inc
Publication of MX2014009046A publication Critical patent/MX2014009046A/es
Publication of MX353868B publication Critical patent/MX353868B/es

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1433—Vulnerability analysis
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general

Abstract

Se proporciona un novedoso marco de seguridad que es parte de un sistema operativo de un dispositivo. El marco incluye un evaluador de seguridad que realiza valoraciones de directrices de seguridad para diferentes operaciones que necesitan realizarse en relación con una aplicación que se ejecuta en el dispositivo. Ejemplos de tales operaciones incluyen la instalación de la aplicación, la ejecución de la aplicación, y la apertura de archivos de contenido (por ejemplo, apertura de documentos) por la aplicación.

Description

ADMINISTRACIÓN OPERATIVA CENTRALIZADA CAMPO DE LA INVENCIÓN La presente invención se relaciona con un novedoso marco de seguridad que es parte de un sistema operativo de un dispositivo.
ANTECEDENTES DE LA INVENCIÓN La identidad y autenticidad de los programas almacenados y que corren en un sistema de computación es una cuestión fundamental de seguridad para los usuarios. Esencialmente, los usuarios desean que los programas con los cuales ¡nteractúan se ejecuten a medida que los programas se publicitan. Los usuarios pueden encontrar problemas cuando confían en un programa específico, en tanto que el programa se comporta de manera inesperada. En algunas situaciones, el programa puede haberse alterado deliberadamente, o un virus u otro problema de seguridad puede presentarse. La mayor parte de las veces, el programa simplemente se comporta de manera diferente a la que el usuario inicialmente esperaba dado que no proviene de una fuente confiable, se ha alterado en algún momento haciéndolo incompatible con otros componentes, o es ineficaz por algunas otras razones.
De esta manera, en las computadoras modernas se corre una gran cantidad de programas de seguridad que intentan abordar este problema. Cada una de estas aplicaciones aborda un conjunto de necesidades de seguridad de la computadora. Estas incluyen aplicaciones antivirus, firewalls, programas de detección de malware, mecanismos de comprobación de firmas, etc. Algunos de estos programas se ofrecen como parte del sistema operativo, algunos se integran en buscadores de Internet, en tanto que otros se adquieren o incluso se descargan de terceros.
Sin embargo, estos programas no son mecanismos consistentes para establecer autenticación de identidades. No puede dependerse de ellos para comprobar de manera comprehensiva todas las operaciones que corren en el sistema operativo, aún cuando cualquier operación que corre en el sistema puede introducir objetos de datos que provienen de fuentes poco fiables y dañar la computadora. Estos procesos a menudo no se ejecutan en forma óptima en el sistema operativo y retardan la velocidad del sistema global. La naturaleza combinada de estos programas de seguridad hace difícil o imposible introducir un conjunto de programas de interfaces de seguridad uniforme para los desabolladores de software. Peor aún, algunos de los surtidos combinatorios de programas de valoración de seguridad pueden haber provenido de fuentes que no se ha certificado apropiadamente como confiables.
Lo que se necesita es un mecanismo consistente para establecer autenticación de identidades. Específicamente, lo que se necesita es un mecanismo de valoración de seguridad que se integre completamente con el sistema operativo para ofrecer una ejecución consistente, examen comprehensivo de las operaciones que tienen lugar en el sistema operativo, y un soporte de desarrollo de software uniforme.
SUMARIO DE LA INVENCIÓN Algunas modalidades de la invención proporcionan un novedoso marco de seguridad para un dispositivo, en algunas modalidades, este marco es parte del sistema operativo del dispositivo. El marco de algunas modalidades incluye un evaluador de seguridad que realiza valoraciones de directrices de seguridad para diferentes operaciones que necesitan realizarse en relación con una aplicación que se ejecuta en el dispositivo. Ejemplos de tales operaciones incluyen la instalación y ejecución de la aplicación, y la apertura de archivos de contenido (por ejemplo, apertura de documentos) por la aplicación.
En algunas modalidades, el dispositivo tiene un iniciador de operaciones que recibe solicitudes para diferentes operaciones en relación con la aplicación. Al recibir tal solicitud, el iniciador de operaciones dirige al evaluador de seguridad para comprobar la viabilidad de la operación solicitada con base en las reglas de directrices de seguridad que se almacenan en un almacenamiento de datos de directrices de seguridad. Las reglas de directrices de seguridad en algunas modalidades se utilizan para comprobar la validez de los programas descargados, para verificar la fuente o editor del programa, etc. Si una regla de directriz de seguridad permite la operación solicitada, el evaluador de seguridad informa al iniciador de operaciones que la operación se ha aprobado, y el iniciador de operaciones dirige al manipulador de operaciones apropiado (por ejemplo, instalador, ejecutor, o abridor de archivos) para realizar la operación solicitada.
En algunas modalidades, las directrices de seguridad se representan en diferentes reglas o instrucciones que se almacenan en una base de datos de reglas. Las reglas en la base de datos de reglas especifican lo que se requiere de los objetos de datos (por ejemplo, código de programación o documentos a abrirse) con el fin de que cumplan con la directriz de seguridad de la computadora. En algunas modalidades, la base de datos de reglas incluye diferentes tablas con el fin de hacer más eficientes las consultas sobre la base de datos de reglas. Una tabla de autoridades y una tabla caché son dos ejemplos de tales tablas.
Valorar la seguridad de un objeto de datos bajo una directriz de seguridad, en algunas modalidades, requiere examinar las entradas de datos de la tabla de autoridades en la base de datos de reglas en el orden establecido por sus prioridades. Para cualquier valoración de seguridad determinada para un objeto de datos en estas modalidades, reglas de prioridad inferior se hacen aplicables sólo cuando las reglas de prioridad superior no son aplicables. Una regla de prioridad superior suplanta las reglas de prioridad inferior donde se superponen. Por tanto, cualquier cambio a una regla de prioridad superior cambia potencialmente la aplicabilidad de las reglas de prioridad inferior.
El iniciador de operaciones en algunas modalidades realiza la valoración de seguridad para cada operación que se solicita para la aplicación. En otras modalidades, el iniciador de operaciones realiza la valoración de seguridad sólo para algunas de las operaciones que se solicitan para la aplicación. Por ejemplo, en algunas modalidades, la valoración se realiza sólo para la instalación de una aplicación recién recibida o sólo para la apertura inicial de un archivo recién recibido por la aplicación. Para facilitar esta estrategia, el dispositivo de algunas modalidades asocia una etiqueta con aplicaciones recién recibidas y archivos recién recibidos cuando tales archivos se cargan primero sobre el dispositivo o se abren por primera vez (por ejemplo, descargados primero a través de una red o a través de una interfaz de periféricos del dispositivo).
El evaluador de seguridad de algunas modalidades, aprueban o desaprueban la validez de uno o más archivos de datos al verificar la validez de una estructura de datos (tal como un "paquete") que contiene los archivos de datos. En algunas modalidades semejantes, los paquetes llevan firma de identidad que puede utilizarse para autenticar de un modo seguro los archivos de datos e identificar la fuente de los archivos de datos incluidos en esos paquetes. Más específicamente, el sistema operativo de estas modalidades incluye reglas en la base de datos de reglas que aprueban o desaprueban documentos o archivos de datos con base en la firma incrustada en las estructuras de paquetes que contienen ese documento o archivos de datos. Un documento en un paquete aprobado se aprueba automáticamente.
El Sumario precedente pretende servir como breve introducción a algunas modalidades de la invención. No pretende ser una introducción o generalidades de toda la materia objeto inventiva dada a conocer en este documento. La Descripción detallada que sigue y los Dibujos que se refieren en la Descripción detallada describirán además las modalidades descritas en el Sumario así como otras modalidades. Por consiguiente, para comprender todas las modalidades descritas por este documento, se necesita una completa revisión del Sumario, Descripción detallada y los Dibujos. Más aún, la materia objeto reclamada no debe limitarse por los detalles ilustrativos en el Sumario, Descripción detallada y los Dibujos, sino que deben definirse por las reivindicaciones adjuntas, dado que la materia objeto reclamada puede representarse en otras formas específicas sin apartarse del espíritu de la materia objeto.
BREVE DESCRIPCIÓN DE LOS DIBUJOS Los novedosos atributos de la invención se exponen en las reivindicaciones adjuntas. Sin embargo, para propósito de explicación, varias modalidades de la invención se exponen en las siguientes figuras.
La Figura 1 ilustra un sistema operativo de un dispositivo de computación que valora la seguridad de diferentes operaciones que se le solicita realizar.
La Figura 2 ilustra conceptualmente un proceso que el sistema operativo usa para manipular y aprobar las operaciones solicitadas.
La Figura 3 ilustra conceptualmente un proceso ejemplar para realizar una valoración de seguridad de una operación solicitada con base en las directrices de seguridad del sistema operativo.
Las Figuras 4-6 ilustran el flujo de datos en un sistema operativo cuando se realiza valoración de seguridad al utilizar el evaluador de seguridad y la base de datos de reglas.
La Figura 7 ilustra conceptualmente una tabla de autoridades que almacena las reglas o instrucciones para determinar las directrices de seguridad de un sistema operativo.
La Figura 8 ilustra conceptualmente una tabla de autoridades que incluye un campo adicional.
La Figura 9 ilustra conceptualmente una tabla de autoridades que incluye sólo un campo de regla en cada registro o entrada.
La Figura 10 ilustra una tabla de autoridades, en la cual múltiples entradas se utilizan para expresar una sola directriz de seguridad.
La Figura 11 ilustra un conjunto de diagramas de Venn para una directriz de seguridad ejemplar.
La Figura 12 ilustra un conjunto de diagramas de Venn para otra directriz de seguridad ejemplar.
La Figura 13 ilustra conceptualmente un proceso para realizar una valoración de seguridad al utilizar la tabla de autoridades.
La Figura 14 ilustra una base de datos de reglas que incluye una tabla de autoridades y una tabla caché.
La Figura 15 ilustra un evaluador de seguridad que utiliza tanto la tabla de autoridades como la tabla caché para hacer una valoración de seguridad con base en una solicitud de un iniciador de operaciones.
La Figura 16 ¡lustra la generación y almacenamiento de una entrada de tabla caché para un objeto de datos por un evaluador de segundad.
La Figura 17 ilustra conceptualmente un proceso que utiliza tanto una tabla de autoridades como una tabla caché para realizar una valoración de seguridad.
La Figura 18 ilustra conceptualmente un proceso que mantiene la tabla de reglas después de un cambio en la base de datos de reglas por parte del usuario.
La Figura 19 ilustra una computadora con un sistema operativo que inserta su propio identificador para realizar valoración de seguridad.
La Figura 20 ilustra un sistema operativo que comprueba que la etiqueta es parte de una operación de valoración de seguridad.
Las Figuras 21-22 ¡lustran el flujo de datos en un sistema operativo cuando se realiza una valoración de seguridad al utilizar un iniciador de operaciones que identifica etiquetas en objetos de datos.
La Figura 23 ¡lustra un sistema operativo que incluye una base de datos de reglas con reglas para procesar bits de etiquetas.
La Figura 24 ilustra una computadora que recibe y almacena paquetes de datos que contienen firmas.
La Figura 25 ilustra un sistema operativo que incluye reglas en la base de datos de reglas para hacer valoraciones de seguridad de archivos de datos o documentos con base en las firmas en los paquetes de datos.
La Figura 26 ilustra conceptualmente un proceso que realiza valoraciones de seguridad de operaciones de apertura de documentos.
La Figura 27 ilustra conceptualmente un sistema electrónico con el cual se implementan algunas modalidades de la invención.
DESCRIPCIÓN DETALLADA DE LA INVENCIÓN En la siguiente descripción, se exponen numerosos detalles para propósito de explicación. Sin embargo, un experto en la técnica se percatará de que la invención puede practicarse sin el uso de estos detalles específicos. En otros casos, estructuras y dispositivos reconocidos se muestran en forma de diagrama de bloques con el fin de no oscurecer la descripción de la invención con detalles innecesarios.
I. SISTEMA OPERATIVO CON VALORACIÓN DE SEGURIDAD La Figura 1 ilustra un sistema operativo 100 de un dispositivo de computación que valora la seguridad de diferentes operaciones que se le solicita realizar. Las operaciones solicitadas pueden ser aplicaciones en ejecución, aplicaciones de instalación, documentos de apertura, etc. La seguridad de la operación solicitada se valora por un evaluador de seguridad, el cual es parte de un marco de seguridad proporcionado por el sistema operativo. Con base en esta valoración de seguridad, el sistema operativo termina la operación solicitada o le permite proceder.
Como se ilustra en la Figura 1 , el sistema operativo 100 incluye el evaluador de seguridad 110, una base de datos de reglas 120, un iniciador de operaciones 130, un solicitante de operaciones 140, un módulo de instalación 170, un módulo de ejecución 172, y un módulo de apertura de contenido 174. La Figura 1 también ilustra una aplicación 150 y un archivo de datos 160 para el cual el sistema operativo 100 valora la directriz de seguridad. El evaluador de seguridad 110 y la base de datos de reglas 120 son parte de un marco de seguridad 180 que proporciona la interfaz de programación de aplicaciones (API) 190.
El sistema operativo 100 es un conjunto de programas que administra recursos de hardware informático y proporciona servicios comunes para diferentes programas de aplicaciones de software. El sistema operativo 100 actúa como intermediario entre los programas de aplicaciones y el hardware informático para funciones tales como entrada, salida y asignación de memoria. En algunas modalidades, el código de aplicaciones de un programa se ejecuta por el hardware e interactúa con el sistema operativo a través de interrupciones recibidas del sistema operativo o llamadas hechas al sistema operativo.
La aplicación 150 es un objeto de datos ejecutable para operar y realizar funciones en el sistema operativo. Ejemplos de la aplicación 150 incluyen procesadores de palabras, navegadores de red, juegos, aplicaciones de edición multimedia, etc. En algunas modalidades, la aplicación 150 es un programa de instalación, que instala uno o más programas ejecutables en la computadora en que el sistema operativo 100 corre.
En algunas modalidades, la aplicación 150 incrusta una o más firmas de identidad para permitir a un usuario de la aplicación determinar la autenticidad de la aplicación. Una firma que se incrusta en la aplicación 150 es un identificador asegurado de la fuente o el editor de la aplicación. Un objeto de datos (por ejemplo, una aplicación) se "firma" cuando una firma se genera con base en el contenido del objeto de datos al utilizar una clave privada secreta que se sabe sólo por el firmante del objeto de datos. Tal firma por lo tanto es capaz de identificar al firmante o la fuente del objeto de datos y proteger la integridad del objeto de datos. Para autenticar la firma de un objeto de datos, es decir, para verificar que la firma de hecho generó el objeto de datos por su fuente/firmante pretendido, el receptor del objeto de datos (es decir, el sistema operativo) usa una clave pública para autenticar la firma en conjunto con el contenido del objeto de datos. Se sabe que la clave pública ha provenido del fuente/firmante pretendido, y el receptor puede verificar independientemente que la clave pública de hecho se emite por el fuente/firmante pretendido (por ejemplo, al consultar una autoridad de certificación confiable o al comprobar la base de datos propia del receptor).
En algunas modalidades, una firma de un objeto de datos se extrae de un certificado de clave pública que se asocia con el objeto de datos. Un certificado de clave pública (también conocido como certificado digital o certificado de identidad) es un documento electrónico que usa una firma digital para unirse a una clave pública con una identidad (información tal como el nombre de una persona, o una organización, su dirección, etcétera). El certificado puede utilizarse para verificar que una clave pública pertenece a un individuo. Las firmas en un certificado son declaraciones por el firmante del certificado de que la información de identidad y la clave pública se pertenecen. Una firma que se genera o firma con base tanto en el contenido del objeto de datos de aplicaciones como la información en el certificado, cuando se autentica, declara que el contenido del objeto de datos de aplicaciones no se ha violado, y que la información en el certificado es genuina. Además de los identificadores de firma y fuente (por ejemplo, la ID de distribuidor y la clave pública), el certificado también incluye información sobre cómo puede autenticarse la firma (por ejemplo, la ID del algoritmo que se utiliza para generar la firma).
En el ejemplo de la Figura 1 , el sistema operativo 100 realiza la operación de autenticación de firma. En algunas modalidades, el sistema operativo 100 previene que la aplicación 150 se ejecute o instale si el sistema operativo no autentica la firma de la aplicación. En algunas modalidades el sistema operativo 100 previene que las operaciones procedan incluso de una aplicación autenticada, a menos que la aplicación sea de un origen que se ha determinado como confiable, de acuerdo con un conjunto de directrices de seguridad.
El archivo de datos 160 es un objeto de datos asociado con una o más aplicaciones que pueden ejecutarse en el sistema operativo. Ejemplos del archivo de datos 160 incluyen archivos de texto, documentos de procesador de palabras, hojas de cálculo, archivos multimedia, etc. El archivo de datos 160 se lee o abre por una aplicación capaz de leer o abrir el archivo de datos. En algunas modalidades, el archivo de datos 160 incluye documentos que no incluyen firmas o certificados. El archivo de datos también puede colocarse en una estructura de paquetes a fin de que el archivo de datos pueda asociarse con firmas o certificados. Las Figuras 25 y 26 a continuación describen cómo manipula el evaluador de seguridad de algunas modalidades los archivos de datos en los paquetes de datos.
El módulo de instalación 170 es un módulo dentro del sistema operativo 100 que supervisa la instalación de aplicaciones, tal como la aplicación 150. En algunas modalidades, el módulo de instalación 170 espera un comando "proceder" del iniciador de operaciones 130 antes de que inicie el proceso de la aplicación 150 para la instalación a través del sistema operativo. En algunas de estas modalidades, el módulo de instalación hace pasar el objeto de datos de aplicaciones 150 al evaluador de seguridad 110 para verificar la firma de la aplicación, así como su cumplimiento con un conjunto de requerimientos de acuerdo con un conjunto de directrices de seguridad. El módulo de instalación 170 procede a instalar la aplicación 150 sólo cuando recibe una comunicación del iniciador de operaciones 130 que indica que la aplicación 150 se autentica y su fuente se verifica.
El módulo de ejecución 172 es un módulo dentro del sistema operativo 100 que lanza aplicaciones, tal como la aplicación 150, para su ejecución en el sistema operativo 100. Como el módulo de instalación 170, el módulo de ejecución 172, en algunas modalidades, espera un comando "proceder" del iniciador de operaciones 130 antes de que lance la aplicación 150 para su ejecución a través del sistema operativo 100. En algunas de estas modalidades, el módulo de ejecución hace pasar el objeto de datos de aplicaciones 150 al evaluador de seguridad 110 para verificar la firma de la aplicación, y para satisfacer un conjunto de requerimientos de acuerdo con un conjunto de directrices de seguridad. El módulo de ejecución 172 procede a ejecutar la aplicación 150 sólo cuando recibe un comando de lanzamiento del iniciador de operaciones 130 después de que la aplicación 150 se ha autenticado y su fuente se ha verificado.
El módulo de apertura de contenido 174 es un módulo dentro del sistema operativo 100 que supervisa la apertura del archivo de datos 160. En algunas modalidades, la apertura de contenido implica una operación que identifica una aplicación adecuada para el contenido en el archivo de datos 160 y luego suministra el contenido a la aplicación. Como se menciona anteriormente, el contenido del archivo de datos puede o puede no acompañarse por una firma y puede o puede no necesitar autenticarse. Para documentos que necesitan autenticarse, el documento se hace pasar al evaluador de seguridad 110 con el fin de verificar la firma del documento y para satisfacer un conjunto de requerimientos de acuerdo con un conjunto de directrices de seguridad. El módulo de apertura de contenido 174 procede a abrir el archivo de datos de documento 160 sólo cuando recibe un comando de lanzamiento del iniciador de operaciones 130 después de que el archivo de datos 160 se ha autenticado y su fuente se ha verificado.
En algunas modalidades, la apertura del archivo de datos 160 se asocia con la ejecución de una aplicación. El módulo de apertura de contenido 174, en algunas de estas modalidades, identifica primero la aplicación para abrir el archivo de datos 160. Si la aplicación identificada por el módulo de apertura de contenido 174 ya se está ejecutando en el sistema operativo, el módulo de apertura de contenido suministra el archivo de datos al módulo de ejecución 172 para ejecutarse. Si la aplicación identificada no se ejecuta actualmente, el módulo de apertura de contenido 174 da lugar a que el módulo de ejecución 172 inicie, ejecutando la aplicación. La ejecución de la aplicación identificada tiene lugar sólo después de que el sistema operativo 100 ha determinado que la aplicación está autenticada y su fuente está verificada.
El solicitante de operaciones 140 es un módulo que solicita la ejecución de una operación particular por el sistema operativo 100. Tales operaciones pueden incluir instalar una aplicación, ejecutar una aplicación., abrir archivos de datos, etc. En algunas modalidades, ei solicitante de operaciones 140 es una interfaz de usuario (tal como una GUI) que recibe un comando de usuario para abrir un documento o ejecutar una aplicación particular (por ejemplo, al seleccionar un icono gráfico para un documento o una aplicación). El solicitante de operaciones 140 también puede ser un programa diferente que se ejecuta dentro del sistema operativo y hace una solicitud al iniciador de operaciones 130 para la operación a realizarse. En algunas modalidades, el solicitante de operaciones 140 también recibe una notificación del iniciador de operaciones 130 si la directriz de seguridad del sistema operativo 100 no permitiera que la operación tuviera lugar (por ejemplo, la firma de la aplicación 150 no se autentica, o si la fuente de la aplicación 150 no es confiable).
El iniciador de operaciones 130 es un módulo que exige la directriz de seguridad del sistema operativo al permitir o prevenir que una operación particular tenga lugar. El iniciador de operaciones 130 recibe una solicitud para la operación particular del solicitante de operaciones 140. Con base en la solicitud, el iniciador de operaciones 130 obtiene los objetos de datos necesarios (por ejemplo, la aplicación 150 o el archivo de datos 160). El iniciador de operaciones 130 entonces solicita que el evaluador de seguridad 110 valore la operación solicitada bajo las directrices de seguridad del sistema operativo 100. El iniciador de operaciones también hace pasar el objeto de datos recibido al evaluador de seguridad como parte de las operaciones solicitadas de valoración de seguridad.
El evaluador de seguridad 110 es un módulo que determina si una operación cumple con las directrices de seguridad del sistema operativo. El evaluador de seguridad 110 recibe una consulta del iniciador de operaciones 130 que solicita la valoración de la directriz de seguridad que concierne a una operación particular. El evaluador de seguridad 110 determina si la operación cumple con las directrices de seguridad al examinar objetos de datos asociados con la operación. Por ejemplo, la solicitud con base en una operación para instalar la aplicación 150 puede incluir varios objetos de datos para que el evaluador de seguridad los examine (por ejemplo, archivos de instalación de un paquete de instalación para la aplicación 150 así como el programa de instalación en sí). En otro ejemplo, una solicitud para abrir el archivo de datos 160 por la aplicación 150 puede incluir objetos de datos para el programa ejecutable de la aplicación 150 y el archivo de datos 160 a examinarse por el evaluador de seguridad 110. En algunas modalidades, la aplicación 150 y el archivo de datos 160 se refieren como el sujeto de la valoración de seguridad. El evaluador de seguridad 110 entonces responde a la consulta recibida del iniciador de operaciones 130. Por ejemplo, si la operación particular satisface los requerimientos de la directriz de seguridad, el evaluador de seguridad informa al iniciador de operaciones 130 que la directriz de seguridad se satisfizo. Por otro lado, si la operación particular no satisface los requerimientos de la directriz de seguridad, el evaluador de seguridad responde al iniciador de operaciones que la operación particular falló en la directriz de seguridad.
En algunas modalidades, el evaluador de seguridad 110 y la base de datos de reglas 120 se implementan como parte del marco de seguridad 180 que realiza la valoración de seguridad para el sistema operativo 100. Otros componentes del sistema operativo pueden utilizar la API 190 de seguridad proporcionada por el marco de seguridad 180 para realizar la valoración de seguridad de las operaciones. En el ejemplo de la Figura 1 , el iniciador de operaciones 130 es un componente del sistema operativo 100 que se comunica con el evaluador de seguridad 110 a través de la API 190.
Una vez que el iniciador de operaciones 130 recibe la respuesta del evaluador de seguridad 110 para la consulta, el iniciador de operaciones 130 exige la directriz de seguridad al permitir o no permitir (por ejemplo, prevenir) que la operación particular proceda. Si la operación se deja proceder, el iniciador de operaciones 130 da lugar a que el módulo de instalación 170, el módulo de ejecución 372, o el módulo de apertura de contenido 174 inicie la ejecución de la operación solicitada por el solicitante de operaciones 140. Si la operación no se permite, el iniciador de operaciones 130 notifica al solicitante de operaciones 140, que a su vez notifica al usuario y termina la operación solicitada. La Figura 2 a continuación describe un proceso ejemplar que se realiza por el iniciador de operaciones 130.
Una firma incrustada en un objeto de datos, cuando se autentica por su receptor, verifica que el objeto de datos es de una fuente particular. En algunas modalidades, el evaluador de seguridad 110 autentica la firma en el objeto de datos y constata la fuente del objeto de datos. Un objeto de datos que no produce una firma que pueda autenticarse (por ejemplo, que es defectuosa o incompleta) por el evaluador de seguridad probablemente es de una fuente poco fiable. En tal situación, el evaluador de seguridad 110, bajo las directrices de seguridad del sistema operativo, informa al iniciador de operaciones 130 para prevenir que el objeto de datos se ejecute o abra, (en algunas modalidades, un documento o programa con una firma que falla en autenticarse nunca puede dejarse proceder). Por el contrario, si el evaluador de seguridad 1 10 es capaz de autenticar la firma del objeto de datos, el evaluador de seguridad puede informar al iniciador de operaciones que es seguro proceder con la operación solicitada, asumiendo que otros requerimientos, bajo la directriz de seguridad también se cumplen (por ejemplo, si la fuente del objeto de datos es confiable).
La directriz de seguridad implementada por algunas modalidades examina diferentes objetos de datos de manera diferente. Para ciertos tipos de objetos de datos, las directrices de seguridad del sistema operativo pueden tener requerimientos adicionales que necesitan satisfacerse además de la autenticación de una firma. Por ejemplo, las directrices de seguridad pueden requerir la autenticación de una firma con base en una cadena de certificados, o requerir que la fuente del objeto de datos sea un distribuidor particular (incluso si la firma de código se autentica con éxito). En algunas modalidades, las directrices de seguridad pueden alterarse por el usuario. Por ejemplo, un administrador confiable de una computadora puede cambiar las directrices de seguridad del sistema operativo de tal modo que el evaluador de seguridad pueda aceptar un objeto de datos particular sin verificar o autenticar ninguna firma. En algunas modalidades, el evaluador de seguridad 1 10 puede programarse de manera arbitraria para implementar cualquier directriz de seguridad con respecto a cualquier objeto de datos que se someta por el iniciador de operaciones 130.
En algunas modalidades, las directrices de seguridad utilizadas para valorar un objeto de datos se implementan como un conjunto de instrucciones que el evaluador de seguridad 1 10 ejecuta con el fin de determinar si un objeto de datos cumple con las directrices de seguridad. En el sistema operativo ejemplar de la Figura 1 , el conjunto de instrucciones que implementan las directrices de seguridad se almacena en la base de datos de reglas 320. El evaluador de seguridad 10 recupera el conjunto de instrucciones de la base de datos de reglas 120, y usa las instrucciones recuperadas para (i) analizar el objeto de datos (por ejemplo, para determinar si la fuente del objeto de datos es aceptable) y para (ii) emitir una respuesta al iniciador de operaciones 130 con base en el análisis. Cada conjunto de una o más reglas almacenadas en la base de datos de reglas algunas veces se refiere como "requerimiento de código", dado que especifica lo que se requiere de un objeto de datos (por ejemplo, un código de programación ejecutable tal como la aplicación 150 o el archivo de datos 160) con el fin de que cumpla con la directriz de seguridad del sistema operativo. La Figura 3 a continuación describe un proceso ejemplar realizado por el evaluador de seguridad 110. Los requerimientos de códigos se describirán a continuación en los detalles en referencia a las Figuras 9 y 13.
La base de datos de reglas 120 es una base de datos que almacena los conjuntos de instrucciones para implementar las directrices de seguridad del sistema operativo 100. El evaluador de seguridad 1 30 recupera los conjuntos de instrucciones de la base de datos de reglas 120 con el fin de responder a la consulta de seguridad hecha por el iniciador de operaciones 130. La base de datos de reglas además se describe posteriormente, por la referencia a las Figuras 7-17.
La Figura 2 ilustra conceptualmente un proceso 200 que el sistema operativo de algunas modalidades usa para manipular y aprobar las operaciones solicitadas. Específicamente, el proceso solicita valoraciones de seguridad para las operaciones solicitadas y lanza las operaciones que se han aprobado. En algunas modalidades, el proceso 200 se realiza por un módulo dentro del sistema operativo 100, tal como el iniciador de operaciones 130 de la Figura 1.
El proceso 200 inicia cuando recibe (en 210) una solicitud de operación (por ejemplo, del solicitante de operaciones 140). En algunas modalidades, la solicitud es un comando de usuario para abrir un documento o ejecutar una aplicación. La solicitud también puede incitarse por un proceso de aplicación o sistema que se ejecuta actualmente, para realizar una operación particular en el sistema operativo.
Después, el proceso hace pasar (en 220) la solicitud al evaluador de seguridad. En el ejemplo de la Figura 1 , la solicitud también incluye objetos de datos (por ejemplo, la aplicación 150 o el archivo de datos 160) que se requieren para que el evaluador de seguridad valore la seguridad de la solicitud bajo la directriz de seguridad. Por ejemplo, una solicitud de operación iniciada por un comando de usuario para abrir un documento puede requerir que múltiples objetos de datos se hagan pasar al evaluador de seguridad dado que, en algunos casos, abrir un documento requiere la invocación de una aplicación y, por lo tanto, la solicitud hecha pasar al evaluador de seguridad puede incluir descriptores de archivos tanto del documento como de la aplicación.
El proceso después recibe (en 230) la respuesta del evaluador de seguridad (por ejemplo, 1 10) y determina (en 240) si se aprueba la operación solicitada. En algunas modalidades, la respuesta del evaluador de seguridad indica (por ejemplo, al informar al iniciador de operaciones 130) si la solicitud ha pasado la directriz de seguridad del sistema operativo. El proceso 200 en algunas modalidades deja a la operación solicitada proceder si la respuesta indica que la solicitud ha pasado la valoración de seguridad (por ejemplo, al tener una firma autenticada y que proviene de una fuente permisible). El proceso 200 en algunas modalidades termina o suspende la operación solicitada si la respuesta lo indica de otra manera (por ejemplo, el evaluador de seguridad no puede autenticar la firma o el objeto de datos no proviene de una fuente permisible).
Si la solicitud se aprueba, el proceso 200 hace pasar (en 250) la solicitud a un manipulador de operaciones capaz de recibir la solicitud y realizar la operación aprobada. Como se ilustra en la Figura 1 , varios manipuladores de operaciones son capaces de recibir solicitudes y realizar operaciones, incluyendo el módulo de instalación 170, el módulo de ejecución 172 y el módulo de apertura de contenido 174. Después de hacer pasar la solicitud al manipulador de operaciones, el proceso 200 termina.
Por otro lado, si el proceso 200 no aprueba la solicitud devuelve (en 260) un mensaje predeterminado al solicitante de operaciones (por ejemplo, 140 de la Figura 1 ), que a su vez notifica al usuario (no mostrado). Adicionalmente, el proceso 200 no hace pasar la solicitud al manipulador de operaciones cuando la solicitud no se aprueba. De esta manera, ninguno de los manipuladores de operaciones, tales como 170, 172, y 174, realizará la operación solicitada cuando la solicitud no se aprueba. Después de devolver el mensaje predeterminado al solicitante de operaciones, el proceso 200 termina.
Algunas modalidades realizan variaciones del proceso 200. Por ejemplo, las operaciones específicas del proceso 200 pueden no realizarse en el orden exacto mostrado y descrito. Las operaciones específicas pueden no realizarse en una serie continua de operaciones, y diferentes operaciones específicas pueden realizarse en diferentes modalidades.
La Figura 3 ilustra conceptualmente un proceso ejemplar 300 para realizar una valoración de seguridad de una operación solicitada con base en las directrices de seguridad del sistema operativo. Específicamente, el proceso 300 usa una base de datos de reglas para hacer coincidir la solicitud con una regla que habilita el proceso para hacer una valoración de seguridad con respecto a la operación solicitada. En algunas modalidades, el proceso 300 se realiza por un módulo en el sistema operativo, tal como el evaluador de seguridad 1 10 de la Figura 1.
El proceso 300 inicia cuando recibe (en 310) una solicitud del iniciador de operaciones. La solicitud indica que una valoración de seguridad se requiere para una operación solicitada particular.
Después, el proceso consulta (en 320) la base de datos de reglas para encontrar una coincidencia. El proceso 300 examina las entradas en la base de datos de reglas para las reglas que coinciden con o son aplicables a la solicitud. Una regla que no coincide con la solicitud no puede utilizarse para hacer una valoración de seguridad para la solicitud. Por ejemplo, una regla para comprobar una aplicación con un nombre específico no puede utilizarse para comprobar una aplicación con un nombre diferente. Como se discutirá además a continuación, múltiples entradas en la base de datos de reglas pueden coincidir de manera simultánea con la solicitud, y sólo la regla con la prioridad más alta se aplicará.
El proceso entonces determina (en 330) si una regla de coincidencia o aplicable se ha encontrado en la base de datos de reglas. Si el proceso 300 encuentra por lo menos una regla de coincidencia, el proceso procede a 340. De otro modo, el proceso procede a 360.
En 360, el proceso regresa una respuesta predeterminada al iniciador de operaciones para indicar que no hay reglas o instrucciones aplicables con respecto a la solicitud. En algunas modalidades, la directriz de seguridad predeterminada es para rechazar una solicitud para una operación que no tiene reglas de coincidencia en la base de datos de reglas. En algunas modalidades, la directriz de seguridad predeterminada permite solicitudes que no se prohiben específicamente por la base de datos de reglas. En algunas modalidades, la directriz predeterminada requiere que el sistema operativo notifique al usuario. Después de devolver la respuesta predeterminada, el proceso 300 termina.
En 340, el proceso hace la valoración de seguridad con respecto a la solicitud. En algunas modalidades, el proceso realiza la valoración de seguridad al aplicar las reglas de coincidencia o el conjunto aplicable de instrucciones a los objetos de datos asociados con la solicitud (por ejemplo, la aplicación 150 y/o el archivo de datos 160). En algunas modalidades, el conjunto coincidente de reglas se ejecuta en el evaluador de seguridad como programa ejecutable. En algunas modalidades, el conjunto coincidente de reglas da lugar a que el evaluador de seguridad haga la valoración de seguridad con base en variables tales como la fuente del objeto de datos, la identidad del objeto de datos, y el tipo del objeto de datos Una vez que la valoración de seguridad se ha hecho, el proceso devuelve (en 350) la valoración de seguridad al iniciador de operaciones para decidir si dejar o no que la operación solicitada proceda. El proceso 300 termina después de que ha devuelto la valoración de seguridad al iniciador de operaciones.
Algunas modalidades realizan variaciones del proceso 300. Por ejemplo, las operaciones específicas del proceso 300 pueden no realizarse en el orden exacto mostrado y descrito. Las operaciones específicas pueden no realizarse en una serie continua de operaciones, y diferentes operaciones específicas pueden realizarse en diferentes modalidades.
Las Figuras 4-6 ilustran el flujo de datos en el sistema operativo 100 cuando se realiza valoración de seguridad al utilizar el evaluador de seguridad y la base de datos de reglas. Como en la Figura 1 , el sistema operativo 100 en las Figuras 4-6 incluye el evaluador de seguridad 110, la base de datos de reglas 120, el iniciador de operaciones 130, el solicitante de operaciones 140, el módulo de instalación 170, el módulo de ejecución 172, y el módulo de apertura de contenido 174.
La Figura 4 ilustra el flujo de datos dentro del sistema operativo 100 cuando la operación solicitada es para instalar una aplicación. El flujo de datos de operación inicia en el solicitante de operaciones 340 cuando hace una solicitud al iniciador de operaciones 130 para instalar la Aplicación X (operación T). Esta solicitud, en algunas modalidades, se basa en un comando de usuario para instalar la Aplicación X. El comando de usuario puede recibirse por medio de una interfaz de usuario.
El iniciador de operaciones 130 entonces hace una solicitud (operación '2') al evaluador de seguridad 1 10 para valorar la seguridad en instalar la Aplicación X bajo las directrices de seguridad del sistema operativo. En algunas modalidades, esta solicitud al evaluador de seguridad 110 incluye descriptores para objetos de datos que son necesarios para instalar la Aplicación X, tales como los archivos y paquetes de instalación.
El evaluador de seguridad 110, al recibir la solicitud, consulta (operación '3') la base de datos de reglas 120 para reglas o instrucciones que coinciden con la solicitud de instalación bajo la directriz de seguridad. La base de datos de reglas proporciona (operación '4') las reglas o instrucciones que coinciden con la consulta en su base de datos al evaluador de seguridad 110. Este proceso de consulta entre el evaluador de seguridad 110 y la base de datos de reglas 120 continúa hasta que una regla de coincidencia se encuentra en la base de datos de reglas o se hace una determinación de que no hay regla aplicable en la base de datos de reglas.
Una vez que se ha encontrado una regla de coincidencia, el evaluador de seguridad 110 realiza una valoración de seguridad al aplicar las reglas de coincidencia a los objetos de datos en relación con la instalación de la Aplicación X. En algunas modalidades, las reglas toman la forma de instrucciones de programación para procesar los objetos de datos y determinar si los objetos de datos cumplen con las directrices de seguridad del sistema operativo. El procesamiento de los objetos de datos, en algunas modalidades, incluye verificar, dentro de los objetos de datos, firmas en relación con la instalación de la Aplicación X. En algunas modalidades, el cumplimiento con las directrices de seguridad se determina con base en si la firma se ha autenticado con éxito y si la firma es de una fuente confiable. La valoración de seguridad entonces se comunica nuevamente al iniciador de operaciones 130 (operación '5'). En el ejemplo ilustrado en la Figura 4, el evaluador de seguridad indica que está listo para instalar la Aplicación X. Esto es la valoración de seguridad dado que se ha encontrado que los objetos de datos en relación con la instalación de la Aplicación X cumplen con las directrices de seguridad almacenadas en la base de datos de reglas.
Después de recibir la valoración de seguridad de que está listo para instalar la Aplicación X, el iniciador de operaciones 130 ordena al módulo de instalación 170 lanzar el instalador e instalar la Aplicación X en la computadora. Las líneas discontinuas alrededor del módulo de ejecución 172 y módulo de apertura de contenido 174 indican que esta operación no implica esos dos módulos.
La Figura 5 es similar a la Figura 4, excepto que, en lugar de ilustrar flujo de datos para una operación de instalación, la Figura 5 ilustra el flujo de datos dentro del sistema operativo 100 cuando la operación solicitada es para ejecutar (por ejemplo, lanzar o invocar) una aplicación. El flujo de datos de operación inicia en el solicitante de operaciones 140 cuando hace la solicitud para ejecutar la Aplicación X (operación T) al iniciador de operaciones 130. Esta solicitud, en algunas modalidades, es un comando de usuario para ejecutar la Aplicación X. El comando de usuario puede recibirse por medio de una interfaz de usuario.
El iniciador de operaciones 130 entonces hace una solicitud (operación '2') al evaluador de seguridad para valorar la seguridad en ejecutar la Aplicación X bajo las directrices de seguridad del sistema operativo. En algunas modalidades, esta solicitud incluye descriptores para objetos de datos que son necesarios para ejecutar la Aplicación X, tal como el código de máquina ejecutable de la Aplicación X.
El evaluador de seguridad 110, al recibir la solicitud, consulta (operación '3') la base de datos de reglas 120 para reglas o instrucciones que coinciden con la solicitud para ejecutar la aplicación bajo la directriz de seguridad. La base de datos de reglas proporciona (operación '4') las reglas o instrucciones que satisfacen la consulta en su base de datos al evaluador de seguridad 110. Este proceso de consulta entre el evaluador de seguridad 110 y la base de datos de reglas 120 continúa hasta que una regla de coincidencia se encuentra en la base de datos de reglas o se hace una determinación de que no hay regla aplicable en la base de datos de reglas.
Una vez que se ha encontrado una regla de coincidencia, el evaluador de seguridad 110 realiza una valoración de seguridad ai aplicar las reglas de coincidencia a los objetos de datos en relación con la ejecución de la Aplicación X. En algunas modalidades, las reglas toman la forma de instrucciones de programación para procesar los objetos de datos y determinar si los objetos de datos cumplen con las directrices de seguridad del sistema operativo. El procesamiento de los objetos de datos, en algunas modalidades, incluye verificar, dentro de los objetos de datos, firmas en relación con la ejecución de la Aplicación X. En algunas modalidades, el cumplimiento con las directrices de seguridad se determina con base en si la firma se ha autenticado con éxito y si la firma es de una fuente confiable. La valoración de seguridad entonces se comunica nuevamente al iniciador de operaciones 130 (operación '5'). En el ejemplo de la Figura 5, el evaluador de seguridad indica que está listo para ejecutar la Aplicación X. Esto es la valoración de seguridad dado que se ha encontrado que los objetos de datos en relación con la ejecución de la Aplicación X cumplen con las directrices de seguridad almacenadas en la base de datos de reglas.
Después de recibir la valoración de seguridad de que está listo para ejecutar la Aplicación X, el iniciador de operaciones 130 ordena al módulo de ejecución 172 lanzar la Aplicación X. Las líneas discontinuas alrededor del módulo de instalación 170 y módulo de apertura de contenido 174 indican que esta operación no implica esos dos módulos.
La Figura 6 es similar a las dos figuras previas, excepto que el flujo de datos de la Figura 6 se basa en una solicitud para abrir un documento. El flujo de datos comienza en el solicitante de operaciones 140 cuando hace una solicitud para abrir un archivo de datos de documento X (operación ) al iniciador de operaciones 130. Esta solicitud, en algunas modalidades, es un comando de usuario para abrir el archivo de datos X. El comando de usuario puede recibirse por medio de una interfaz de usuario.
El iniciador de operaciones 130 entonces hace una solicitud (operación '2') al evaluador de seguridad para valorar la seguridad en abrir el archivo de datos X bajo las directrices de seguridad del sistema operativo. En algunas modalidades, esta solicitud incluye descriptores para el archivo de datos X. Si el archivo de datos X es un documento que debe abrirse por la aplicación Y, entonces esta solicitud, en algunas modalidades, también incluye descriptores para los archivos binarios ejecutables de la aplicación Y. En este caso, tanto el documento X como la aplicación Y se consideran objetos de datos necesarios para abrir el documento X. Por lo tanto, la valoración de seguridad se realiza en ambos objetos de datos. Sin embargo, en algunas modalidades, la aplicación necesaria para abrir el archivo de datos X ya se ejecuta (y, de esta manera, ya ha aprobado una valoración de seguridad, tal como en el ejemplo de la Figura 5). Por lo tanto, sólo el descriptor para el archivo de datos X se hace pasar al evaluador de seguridad como parte de la solicitud.
El evaluador de seguridad 110, al recibir la solicitud, consulta (operación '3') la base de datos de reglas 120 para reglas o instrucciones que coinciden con la solicitud de apertura de documento bajo la directriz de seguridad. La base de datos de reglas proporciona (operación '4') las reglas o instrucciones en su base de datos al evaluador de seguridad 1 10. Este proceso de consulta entre el evaluador de seguridad 110 y la base de datos de reglas 120 continúa hasta que una regla de coincidencia se encuentra en la base de datos de reglas o hasta que se hace una determinación de que no hay regla aplicable en la base de datos de reglas.
Una vez que se ha encontrado una regla de coincidencia, el evaluador de seguridad 1 10 aplica las reglas de coincidencia a los objetos de datos en relación con la apertura del archivo de datos X (por ejemplo, aplicación Y). En algunas modalidades, las reglas toman la forma de instrucciones de programación que procesan los objetos de datos y hacen una determinación en cuanto a si esos objetos de datos cumplen con las directrices de seguridad del sistema operativo. El procesamiento de los objetos de datos, en algunas modalidades, incluye verificar firmas dentro de los objetos de datos en relación con la apertura del archivo de datos X. La determinación se hace, en algunas modalidades, con base en si la firma se ha autenticado con éxito y si la firma es de una fuente confiable. La valoración de seguridad entonces se comunica nuevamente al iniciador de operaciones 130 (operación '5'). En el ejemplo de la Figura 6, el evaluador de seguridad indica que está listo para abrir el archivo de datos X. Esto es la valoración de seguridad dado que se ha encontrado que los objetos de datos en relación con la apertura del archivo de datos X (por ejemplo, archivo de datos X en sí y aplicación Y) cumplen con las directrices de seguridad almacenadas en la base de datos de reglas.
Después de recibir la valoración de seguridad de que está listo para abrir el archivo de datos X, el iniciador de operaciones 130 ordena al módulo de apertura de contenido 174 lanzar la Aplicación X. Las líneas discontinuas alrededor del módulo de ejecución 172 y el módulo de instalación 170 indican que esta operación no implica esos dos módulos. En algunas modalidades, cuando la apertura de un documento requiere la ejecución de una aplicación que no se ejecuta actualmente en la computadora, el iniciador de operaciones también lanzará el módulo de ejecución 172.
II. BASE DE DATOS DE REGLAS En los ejemplos descritos anteriormente, los objetos de datos asociados con las operaciones solicitadas se valoran de acuerdo con las directrices de seguridad del sistema operativo. Estas directrices de seguridad se representan en diferentes reglas o instrucciones almacenadas en la base de datos de reglas. Las "directrices de seguridad del sistema operativo" de esta manera son un conjunto de reglas programables que controla las operaciones que tienen lugar en el sistema operativo pero no es parte de los programas del sistema operativo en sí. Como se discutirá en la Sección ll-C, estas "directrices de seguridad del sistema operativo" pueden alterarse por los usuarios o el distribuidor del sistema de computación.
En algunas modalidades, la base de datos de reglas incluye diferentes tablas con el fin de hacer más eficientes las consultas sobre la base de datos de reglas. Dos tablas semejantes (una tabla de autoridades y una tabla caché) se describen a continuación.
A. Tabla de autoridades La base de datos de reglas, en algunas modalidades, incluye una tabla de autoridades. En algunas modalidades semejantes, la tabla de autoridades contiene las reglas que el evaluador de seguridad recupera para determinar si se permite que una operación particular tenga lugar en un sistema operativo. Las reglas en la tabla de autoridades especifican lo que se requiere de los objetos de datos (por ejemplo, código de programación o documentos a abrirse) con el fin de que cumplan con la directriz de seguridad de la computadora. Por tanto, cada conjunto de una o más de estas reglas se refiere como "requerimiento de código" en algunas modalidades.
Los requerimientos de código pueden expresar condiciones arbitrarias en los certificados utilizados para firmar el asunto, tal como requerir que la ID de distribuidor y/o la clave pública en el certificado pertenezcan a una fuente confiable particular. El requerimiento de código también puede requerir otras cosas, tales como entradas en diccionarios de configuración que son partes integrales de estos programas. Por ejemplo, un requerimiento de código puede indicar "debe tener un privilegio que permita el uso de la libreta de direcciones" (los privilegios siendo uno de esos diccionarios de configuración especificados por algunos para su inclusión en los programas), que no tiene nada que ver con su firma.
La Figura 7 ilustra conceptualmente una tabla de autoridades 700 que almacena las reglas o instrucciones para determinar las directrices de seguridad de un sistema operativo. La tabla de autoridades 700 incluye un conjunto de entradas o registros, y cada entrada o registro almacena un conjunto de uno o más reglas o instrucciones que especifican un requerimiento de código. Una directriz de seguridad particular puede expresarse por una o más entradas en la tabla de autoridades.
Como se ilustra, un dispositivo de almacenamiento 710 almacena la tabla de autoridades 700, que incluye varias entradas o registros, incluyendo los registros 721 , 722, y 723. Los registros expresan varias directrices de seguridad, incluyendo las directrices 731 , 732, y 733. Cada registro o entrada también incluye un conjunto de campos 741-744. Los campos 741-743 se etiquetan 'Regla G a 'Regla n'. El campo 744 se etiqueta 'Acción'.
Cada campo de un registro es un conjunto de reglas o instrucciones que dirige al evaluador de seguridad del sistema operativo para realizar un conjunto de operaciones lógicas o aritméticas y tomar una decisión de acuerdo con el conjunto de operaciones lógicas o aritméticas. Por ejemplo, la 'X' en el campo 741 del registro 721 puede ser un conjunto de operaciones que se comprueban para ver si el valoración de seguridad es para una aplicación, la ?' en el campo 742 del registro 721 puede ser un conjunto de operaciones que comprueba la fecha de expiración del certificado, la 'Z' en el campo 742 del registro 722 puede ser una regla que verifica si la aplicación es de un distribuidor o fuente confiable, en tanto que la 'W en el campo 741 puede ser una regla que comprueba si un archivo que se abre es un archivo descargado de la Internet. Una entrada no tiene que tener todos los campos llenos. Por ejemplo, la entrada 723 tiene sólo un campo de regla lleno (741). La instrucción en ese campo para el registro 723 puede ser una comprobación de si un documento que requiere abrirse se descarga de la Internet.
Los diferentes conjuntos de instrucción en los diferentes campos de un registro hacen en conjunto una sola determinación. Esta sola determinación se utiliza para decidir si la acción indicada en el campo 'Acción' 744 debe emprenderse. Por ejemplo, la 'aprobación' en el campo de acción 744 del registro 722 puede dar lugar a que el evaluador de seguridad apruebe la solicitud para lanzar una aplicación particular si el objeto de datos que se evalúa es una aplicación, tiene un certificado que se ha verificado bajo el estándar X.509, y proviene de un distribuidor confiable. Por otro lado, en tanto que la 'desaprobación' de la entrada 723 puede dar lugar a que el evaluador de seguridad desapruebe una solicitud para abrir un elemento de contenido particular si se descarga de la Internet.
Tal colección de instrucciones o requerimientos constituye una directriz de seguridad. En el ejemplo de la Figura 7, las reglas o instrucciones en el registro 721 constituyen la directriz de seguridad A 731 , las reglas o instrucciones en el registro 722 constituyen la directriz de seguridad B 732, y las reglas o instrucciones en el registro 723 constituyen la directriz de seguridad C 733. En algunas modalidades, una directriz de seguridad es una colección de reglas que abarcan dos o más registros en la tabla de autoridades. Tal tabla de autoridades además se discute a continuación en referencia a la Figura 10.
En algunas modalidades, algunas de las reglas son para coincidencia y algunas de las reglas son para verificación. Las reglas para coincidencia determinan si la entrada particular es aplicable a la solicitud de la valoración de seguridad. Las reglas para verificación determinan si la solicitud cumple con la directriz de seguridad representada por la entrada o registro particular de la tabla de reglas. Por ejemplo, una regla que rechaza un tipo de objeto de datos de un distribuidor particular es una regla para verificación, en tanto que una regia que limita la aplicabilidad de la regla a aplicaciones de juegos es una regla para coincidencia.
Además de los campos de reglas y un campo para acción, algunas modalidades incluyen otros campos. La Figura 8 ilustra conceptualmente una tabla de autoridades 800 que es similar a la tabla de autoridades 700, excepto que, además de los campos de reglas y el campo de acción ilustrados en la Figura 7, la tabla de autoridades 800 incluye un campo adicional. La tabla de autoridades 800 también tiene una serie de entradas (821-823), y cada entrada tiene una serie de campos (840-844). Estos campos incluyen los campos de reglas (841 -843) y un campo de acción (844). A diferencia de la tabla de autoridades 700, sin embargo, cada entrada en la tabla de autoridades 800 también incluye un campo de prioridad 840.
El campo de prioridad 840 de algunas modalidades decide cuál entrada en la tabla de autoridades se examinará primero para encontrar reglas que coinciden con la solicitud. Las entradas con valor de prioridad superior en el campo de prioridad se examinarán antes de las entradas con valores de prioridad inferiores. Como se ilustra en la Figura 8, el registro 822 tiene un valor de prioridad de 1.75 en el campo de prioridad 840, en tanto que el registro 823 tiene un valor de prioridad de 1.25. El registro 822 por lo tanto se buscará antes que el registro 823, en tanto que el registro 821 (que tiene un valor de prioridad de 2.70) se buscará antes de los registros 822 y 823. La prioridad de entradas puede expresarse en otras formas (por ejemplo, al utilizar un número entero, al disponer las entradas en una lista vinculada de la prioridad más alta a la prioridad más baja, o al ordenar las entradas de acuerdo con la prioridad).
Para cualquier solicitud de valoración de seguridad determinada, múltiples entradas de la tabla de autoridades pueden coincidir con la solicitud. Sin embargo, en algunas modalidades, el evaluador de seguridad detiene la búsqueda de la tabla de autoridades cuando se encuentra una entrada coincidente. Por ejemplo, para una búsqueda que puede tener múltiples coincidencias, el evaluador de seguridad simplemente usará la primera entrada coincidente, que es la entrada coincidente de mayor prioridad. El uso de un campo de prioridad, por lo tanto, reduce la posibilidad de múltiples coincidencias, lo que asegura que únicamente se utiliza una sola entrada coincidente para la valoración de seguridad.
En los ejemplos de las Figuras 7 y 8, una entrada en una tabla de autoridades incluye varios campos, incluyendo varios campos de reglas que contienen, cada uno, un conjunto de instrucciones para realizar un conjunto de operaciones lógicas o aritméticas. Sin embargo, algunas modalidades expresan los conjuntos de instrucciones de todos los campos de reglas como una sola regla y tienen únicamente un solo campo de regla en la tabla de autoridades. El único campo de regla en un registro de la tabla de autoridades abarca todas las instrucciones necesarias para hacer la valoración de seguridad bajo una directriz de seguridad particular.
La Figura 9 ilustra conceptualmente una tabla de autoridades 900 de algunas otras modalidades, que incluye sólo un campo de regla en cada registro o entrada. La tabla de autoridades 900 es similar a la tabla de autoridades 800, incluyendo un campo de prioridad 941 , un campo de acción 943, y una serie de entradas (921-923). Sin embargo, a diferencia de la tabla de autoridades 800, que incluye varios campos de reglas, la tabla de autoridades 900 incluye sólo un campo de regla 942.
El requerimiento de código que incluye el campo de regla 942 para cada registro o entrada, incluye todas las instrucciones necesarias para realizar una valoración de seguridad para una solicitud, incluyendo instrucciones de coincidencia y de verificación. En algunas modalidades, el requerimiento de código, como se menciona antes, puede ser un conjunto de una o más reglas concatenadas. En tales modalidades semejantes, el requerimiento de código se aplica al objeto de datos solicitado con el fin de validar la fuente del objeto de datos. Por ejemplo, un conjunto de instrucciones en el requerimiento de código que incluye el campo de regla 942 para la entrada 921 puede hacer cada una de las siguientes determinaciones: (1 ) si la solicitud para la valoración de seguridad es para una aplicación; (2) si la aplicación es de un distribuidor o fuente confiable; y (3) si la información de identificación de fuente en el certificado (por ejemplo, ID de distribuidor, clave pública, etc.) en efecto pertenece al distribuidor o fuente confiable. Sólo cuando cada una de las tres determinaciones satisface su regla correspondiente, se aplicará la acción en el campo de acción 943. Por otro lado, cuando una o más de las tres determinaciones no satisfacen su regla correspondiente, el campo de acción del registro no se aplicará. De esta manera, la acción prescrita por el campo de acción se basa en la única regla para el registro, y puede comunicarse al evaluador de seguridad (por ejemplo, aprobación o desaprobación de la acción solicitada).
La tabla de autoridades puede tener diferentes formatos, a partir de los que se ilustran en las Figuras 7-10. Por ejemplo, una entrada de tabla de autoridades, en alguna modalidad, puede incluir un campo denominado "deshabilitar" de tal modo que, cuando la campo deshabilitar contenga cierto valor, la entrada pueda saltarse y el evaluador de seguridad no considerará la entrada en la búsqueda.
Como se menciona antes por la referencia a la Figura 7, las directrices de seguridad del sistema operativo se expresan por las reglas e instrucciones en la base de datos de reglas. En algunas modalidades, cada entrada en la tabla de autoridades es suficiente para expresar una directriz de seguridad particular (por ejemplo, al permitir sólo aplicaciones que tienen una firma válida de un distribuidor específico). En algunas modalidades, una directriz de seguridad puede expresarse por dos o más entradas en la tabla de autoridades.
La Figura 10 ilustra una tabla de autoridades 1000, en la cual múltiples entradas se utilizan para expresar una sola directriz de seguridad. La Figura 10 se describirá con referencia a las Figuras 1 1 y 12. La tabla de autoridades 1000 es similar a la tabla de autoridades 900. Tiene una serie de entradas (1021-1027) y cada una de las entradas tiene tres campos (un campo de prioridad 1041 , un campo de regla 1042, y un campo de acción 1043). Sin embargo, la Figura 10 también ilustra una directriz de seguridad ejemplar 1031 ('directriz de seguridad G) que se implementa por tres entradas de la tabla de autoridades (las entradas 1021 , 3024, y 1026). Las tres entradas de la directriz de seguridad tienen diferentes prioridades (P1 P5, y P8) de tal modo que sólo la entrada con la prioridad de coincidencia más alta se utilice para hacer la valoración de seguridad. En este ejemplo, P1 tiene la prioridad más alta, la prioridad de P5 es inferior a la de P1 , y P8 tiene la prioridad más baja.
La Figura 11 ilustra un conjunto de diagramas de Venn para la directriz de seguridad ejemplar 1031 de la Figura 10. Los diagramas ilustran las relaciones lógicas entre las tres entradas de tabla de autoridades (P1 , P5 y P8). Los diagramas también ilustran la construcción de la directriz de seguridad ejemplar 1031 por el uso de prioridades.
La Figura 11 incluye la directriz de seguridad 1031 , un diagrama de Venn bidimensional 1 120 y un diagrama tridimensional 1 130. La directriz de seguridad 1031 incluye un registro (o un conjunto de instrucciones) para la prioridad P1 , un registro para la prioridad P5, y un registro para la prioridad P8. Las reglas en el registro con la prioridad P1 (es decir, 1021) pueden permitir "todas las aplicaciones de procesamiento de palabras con certificado válido de la empresa X". Las reglas en el registro con la prioridad P5 (es decir, 1024) pueden permitir "ninguna aplicación de la empresa X". Las reglas en el registro con la prioridad P8 (es decir, 1026) pueden permitir la apertura de todas las aplicaciones. En algunas modalidades, un certificado se considera "válido" si su firma se ha autenticado.
El diagrama de Venn 2-D 1120 incluye tres óvalos 1 121-1123. El diagrama 3-D 1330 ilustra los mismos tres óvalos en una forma tridimensional. El óvalo 1121 representa las reglas con la prioridad P1 , el óvalo 1322 representa las reglas con la prioridad P5, y el óvalo 1123 representa las reglas con la prioridad P8.
El diagrama de Venn 2-D 1120 de esta manera ilustra las relaciones lógicas entre las tres entradas de tabla de autoridades. Dentro del diagrama de Venn 1120, el óvalo 1 123 abarca los óvalos 1122 y 1 121 , y el óvalo 1122 abarca el óvalo 1 121. Esto corresponde a las relaciones lógicas entre las reglas en los tres registros, donde la aplicabilidad de la regla P1 , "todas las aplicaciones de procesamiento de palabras con certificado válido de la empresa X", es un subconjunto de la aplicabilidad de la regla P5 "las aplicaciones de la empresa", y la aplicabilidad de la regla P5 es un subconjunto de la aplicabilidad de la regla P8 "todas las aplicaciones".
El diagrama 3-D ilustra cómo el uso del campo de prioridad en la tabla de autoridades decide cuál de las reglas dentro de la directriz de seguridad 101 debe aplicarse para realizar la valoración de seguridad. Como se ilustra, el óvalo 1121 es el más alto y corresponde a la regla de prioridad más alta (P1) en la directriz de seguridad 1031. El óvalo 1 122 es el segundo más alto y corresponde a la siguiente regla de prioridad más alta (P5) en la directriz de seguridad 1031. El óvalo 1123 es el más bajo y corresponde a la regla de prioridad más baja (P8) en la directriz de seguridad 1031. Una regla de prioridad superior suplanta las reglas de prioridad inferior donde se intersecan, justo a medida que los óvalos de prioridad más alta restan importancia a los óvalos de prioridad inferior en cualquier momento en que se intersecan. La aplicabilidad de las reglas de prioridad superior efectivamente abre huecos en la aplicabilidad de las reglas de prioridad inferior.
La directriz de seguridad 1031 de esta manera puede construirse al utilizar múltiples entradas en la tabla de autoridades 1000 sin inconsistencia lógica cuando se realizan valoraciones de seguridad. El uso del campo de prioridad resuelve el problema de cuáles reglas utilizar cuando diferentes entradas en la tabla de autoridades se aplican a la misma solicitud.
La Figura 12 ilustra un conjunto de diagramas de Venn para otra directriz de seguridad ejemplar 1231. Los diagramas ilustran las relaciones lógicas entre las tres entradas de tabla de autoridades (P1 , P5 y P8). Los diagramas también ilustran la construcción de la directriz de seguridad ejemplar 1231 por el uso de prioridades. Las entradas de tabla de autoridades en la directriz de seguridad 1231 , a diferencia de las entradas de tabla de autoridades en la directriz de seguridad 1031 , no son necesariamente subconjuntos una de otra.
La Figura 12 incluye la directriz de seguridad 1231 , un diagrama de Venn bidimensional 1220 y un diagrama tridimensional 1230. La directriz de seguridad 1231 incluye un registro (o un conjunto de instrucciones) para la prioridad P1 , un registro para la prioridad P5, y un registro para la prioridad P8. Las reglas en el registro con la prioridad P1 pueden permitir "todas las aplicaciones de procesamiento de palabras con certificado válido". Las reglas en el registro con la prioridad P5 pueden permitir "nada de la empresa X".
Las reglas en el registro con la prioridad P8 pueden permitir la apertura de todas las aplicaciones con un certificado válido.
El diagrama de Venn 1220 incluye tres óvalos 1221-1223. El diagrama 3-D 1230 ilustra los mismos tres óvalos en una forma tridimensional. El óvalo 1221 representa las reglas con la prioridad P1 , el óvalo 1222 representa las reglas con la prioridad P5, y el óvalo 1223 representa las reglas con la prioridad P8.
El diagrama de Venn 2-D de esta manera ilustra las relaciones lógicas entre las tres entradas de tabla de autoridades. Dentro del diagrama de Venn 1220, el óvalo 1223 abarca el óvalo 1221 , en tanto que el óvalo 1222 se superpone con los óvalos 1221 y 1223. Esto corresponde a las relaciones lógicas entre las reglas en los tres registros. Específicamente, la aplicabilidad de la regla P1 , "todas las aplicaciones de procesamiento de palabras con certificado válido", es un subconjunto de la aplicabilidad de la regla P8 "todas las aplicaciones con certificado válido". La aplicabilidad de la regla P5, "nada de la empresa X" interseca los registros P1 y P8 sin ser su subconjunto o su súperconjunto.
El diagrama 3-D 1230 ilustra cómo el uso del campo de prioridad en la tabla de autoridades decide cuál de las reglas dentro de la directriz de seguridad 1231 debe aplicarse para realizar la valoración de seguridad. Como se ilustra, el óvalo 1221 es el más alto y corresponde a la regla de prioridad más alta (P1) en la directriz de seguridad 1231. El óvalo 1222 es el segundo más alto y corresponde a la siguiente regla de prioridad más alta (P5) en la directriz de segundad 1231. El óvalo 1223 es el más bajo y corresponde a la regla de prioridad más baja (P8) en la directriz de seguridad 1231. Una regla de prioridad superior suplanta las reglas de prioridad inferior cuando se intersecan, justo a medida que el óvalo de prioridad más alta resta importancia a los óvalos de prioridad inferior en cualquier momento en que se intersecan.
La directriz de seguridad 1031 de esta manera puede construirse al utilizar múltiples entradas en la tabla de autoridades sin inconsistencia lógica cuando se realiza una valoración de seguridad. El uso del campo de prioridad resuelve el problema de cuáles reglas utilizar cuando diferentes entradas en la tabla de autoridades se aplican a la misma solicitud. Por ejemplo, una solicitud de un procesador de palabras con un certificado válido de la empresa X puede resultar en que el procesador de palabras se apruebe, dado que la regla para "todas las aplicaciones de procesamiento de palabras con certificado válido" tiene prioridad superior a la de "nada de la empresa X". Como otro ejemplo, una solicitud para una aplicación de navegador de red con un certificado válido de la empresa X puede no aprobarse, dado que la regla para "nada de la empresa X" tiene una prioridad superior a la de "todas las aplicaciones con certificado válido".
Para algunas modalidades, la Figura 13 ilustra conceptualmente un proceso 1300 para realizar una valoración de seguridad al utilizar la tabla de autoridades. El proceso recibe una solicitud de valoración de seguridad y hace coincidir las entradas (o registros) de la tabla de autoridades con la solicitud. El proceso entonces realiza la valoración de seguridad al verificar si el objeto de datos de la solicitud cumple con el requerimiento de código almacenado en la tabla de autoridades.
El proceso 1300 inicia cuando recibe (en 1310) una consulta o una solicitud para hacer una valoración de seguridad. La solicitud se acompaña por un objeto de datos (por ejemplo, un código de programación de aplicaciones, un paquete de instalación, o un documento a abrirse) al cual se aplicará el requerimiento de código almacenado en la tabla de autoridades.
El proceso después extrae (en 1320) una firma de código del objeto de datos. En algunas modalidades, la firma se extrae de un certificado de clave pública emitido por la fuente del objeto de datos. El proceso entonces determina (en 1325) si la firma extraída está autenticada. En algunas modalidades, un módulo separado en el evaluador de seguridad realiza la autenticación de firma de código (por ejemplo, módulo verificador de firma de código). Una vez que la firma de código se ha extraído, el proceso usa el módulo verificador de firma de código para comprobar si la firma de código se ha autenticado con éxito. Si la firma se autentica con éxito, el proceso procede a 1330. Si la firma no se autentica con éxito, el proceso 1300 termina.
El proceso encuentra después (en 1330) la entrada de prioridad más alta en la tabla de autoridades. En algunas modalidades, el proceso 1300 compara los campos de prioridad de cada entrada en la tabla de autoridades con el fin de determinar cuál entrada tiene la prioridad más alta. El proceso entonces determina (en 1340) si la entrada se ha encontrado. En algunas modalidades, esto se consigue al registrar cuáles entradas ya se han examinado. Si todas las entradas en la tabla de autoridades ya se han examinado, entonces no hay más entradas a encontrarse. Si se encuentra la entrada de prioridad más alta, el proceso procede a 1350. Si no hay más entradas a examinarse en la tabla de autoridades, el proceso 1300 finaliza.
En 1350, el proceso recupera el requerimiento de código de la entrada de tabla de autoridades que se encontró. El proceso entonces usa (en 1360) el requerimiento de código recuperado para verificar la fuente del objeto de datos. Tal verificación puede incluir la verificación de la ID de distribuidor y la fecha de expiración del certificado que se utiliza para generar la firma. El requerimiento de código recuperado también se utiliza para verificar otros atributos requeridos del objeto de datos, atributos tales como el tipo del objeto de datos, nombre del objeto de datos, o cualquier otro atributo que pueda asociarse con un objeto de datos. De esta manera, por ejemplo, incluso si el proceso es capaz de autenticar la firma del objeto de datos, el proceso aún puede rechazar el objeto de datos si no satisface el requerimiento de código (por ejemplo, si no posee el tipo correcto o no proviene de una fuente que se estima confiable).
El proceso entonces determina (en 1370) si el requerimiento de código coincide con o es aplicable a la consulta. Una valoración de seguridad no puede hacerse con base en un requerimiento de código que no es aplicable a la solicitud. Algunas modalidades no comprueban la aplicabilidad del requerimiento de código hasta este punto del proceso dado que la aplicabilidad de un requerimiento de código algunas veces no puede determinarse hasta que el proceso ha utilizado el requerimiento de código para procesar el objeto de datos de la solicitud. En algunas modalidades, el proceso comprueba la aplicabilidad del requerimiento de código tan pronto como suficiente información se encuentra disponible. Si el requerimiento de código coincide con (es decir, es aplicable) la consulta, el proceso procede a 1390. De otro modo, el proceso procede a 1380.
En 1380, el proceso busca la tabla de autoridades para la siguiente entrada de prioridad más alta. Algunas modalidades marcan las entradas previas más altas que se examinaron previamente, y la siguiente entrada de prioridad más alta simplemente es la entrada de prioridad más alta que no se ha marcado. El proceso después determina (en 1325) si la entrada se encuentra. Si es así, el proceso regresa a 1330. De otra manera, el proceso 1300 termina.
En 1390, el proceso usa el requerimiento de código para determinar la acción que debe emprenderse por el iniciador de operaciones. En algunas modalidades, esta acción se especifica por el campo de acción de la entrada coincidente (es decir, para aprobar o desaprobar) lo que depende de si el objeto de datos ha satisfecho el requerimiento de código. Después de responder a la solicitud, el proceso 1300 termina.
B. Tabla caché Realizar la valoración de seguridad al utilizar entradas en la tabla de autoridades, en algunas modalidades, puede incluir muchos cálculos. Una regla que verifica información incrustada en un certificado puede incluir operaciones computacionalmente intensas, en algunas modalidades. Adicionalmente, cruzar de un lado a otro de muchas entradas en la tabla de autoridades puede ser necesario para completar una búsqueda para una entrada que coincide con la solicitud. Por ejemplo, para asegurar que una solicitud no tiene entradas coincidentes, un cruce completo de la tabla de autoridades puede ser necesario. Algunas modalidades ahorran tiempo de valoración de seguridad al realizar operaciones de valoración de seguridad sólo en objetos de datos que aún no se han valorado. En otras palabras, la consulta se hace a la tabla de autoridades sólo cuando un programa de aplicaciones se lanza por primera vez o sólo cuando un archivo de datos se abre por primera vez.
Para acelerar además las operaciones de valoración de seguridad, la base de datos de reglas de algunas modalidades incorpora una tabla caché además de la tabla de autoridades. En algunas modalidades, una tabla caché almacena la acción requerida para un objeto de datos en una ubicación de dirección indizada por un valor de resumen criptográfico que es único para ese objeto de datos. Por ejemplo, un valor de resumen criptográfico de directorio de código único puede calcularse para un programa de aplicaciones o un archivo de datos. De esta manera, una solicitud para una valoración de seguridad para la ejecución (o instalación) de una aplicación o apertura de un paquete (se describirá con mayor detalle posteriormente en la Sección IV en referencia a las Figuras 24 y 25) requieren sólo el cálculo del valor de resumen criptográfico de la aplicación ejecutable, el archivo de instalación, o el paquete. La acción (por ejemplo, aprobación o desaprobación) entonces se recupera de la ubicación de dirección de la tabla caché indicada por el valor de índice de resumen criptográfico.
A diferencia de una consulta de la tabla de autoridades, una consulta de la tabla caché no requiere el cruce de múltiples entradas ni cálculo prolongado de acuerdo con las reglas. Una solicitud de valoración de una operación que implica un objeto de datos que tiene una entrada correspondiente en la tabla caché puede de esta manera acelerarse en gran medida. En algunas modalidades, una solicitud de una valoración de seguridad primero intenta encontrar una entrada coincidente en la tabla caché antes de buscar en la tabla de autoridades. Una tabla caché también se denomina tabla de objetos, dado que cada entrada en la tabla caché corresponde a un objeto de datos (por ejemplo, una aplicación ejecutable o un documento). Dado que los usuarios tienden a interactuar con objetos de datos con los que han interactuado recientemente (y por tanto con entradas en la tabla caché), el uso de la tabla caché reduce significativamente el tiempo de valoración de seguridad.
Para algunas modalidades, la Figura 14 ilustra una base de datos de reglas 1400 que incluye una tabla de autoridades 1410 y una tabla caché 1460. La figura también ilustra entradas ejemplares de la tabla caché y las relaciones entre las entradas de tabla caché y las entradas de tabla de autoridades. En algunas modalidades, la tabla de autoridades y la tabla caché se almacenan en almacenamientos físicos separados, en tanto que, en otras modalidades, la tabla de autoridades y la tabla caché se almacenan en un solo almacenamiento físico.
La tabla de autoridades 1410 tiene el mismo formato y contenido que la tabla de autoridades 900 de la Figura 9, incluyendo las entradas de registro 1421-1423, un campo de prioridad 1440, un campo de regla 1441 , y un campo de acción 1442.
La tabla caché 1460 incluye tres entradas 1471-1473. A diferencia de las entradas de la tabla de autoridades, las entradas de la tabla caché no incluyen un campo de regla. Sin embargo, la tabla caché incluye otros campos, incluyendo un campo ID de resumen criptográfico 1491 , un campo de fecha de expiración 1492, un campo de acción 1493, y un campo de referencia 1494.
La entrada 1471 de la tabla caché 1460 se basa en un objeto de datos (objeto de datos A) que coincide con la entrada 1421 de la tabla de autoridades 1410. La entrada 1472 de la tabla caché 1460 se basa en otro objeto de datos (objeto de datos B) que coincide con la entrada 1422 de la tabla de autoridades 1410. En algunas modalidades, estas entradas de tabla caché se hacen cuando se hacen solicitudes de valoración de seguridad con base en los objetos de datos A y B. La entrada 1473 se basa en un objeto de datos (objeto de datos C) que no coincide con ninguna entrada de la tabla de autoridades 1410. La entrada negativa 1473 se hace en la tabla caché 1460 cuando la tabla de autoridades 1410 no produce una regla de coincidencia para una solicitud de valoración de seguridad que implica el objeto de datos C. Por lo tanto, la existencia de tal entrada negativa en la tabla caché previene una larga búsqueda exhaustiva de la tabla de autoridades 1410.
La entrada negativa 1473 de la tabla caché no hereda ningún campo de la tabla de autoridades dado que se genera a partir de un objeto sin una entrada coincidente en la tabla de autoridades 1410. En algunas modalidades, la entrada negativa incluye una indicación de que esta es una entrada negativa y de que no hay entrada coincidente en la tabla de autoridades 1410 para el objeto de datos. En algunas modalidades semejantes, la tabla de autoridades contiene entradas "virtuales" que no se procesan normalmente sino sirven como anclas para que las entradas negativas en la tabla caché se refieran nuevamente. En otras palabras, los registros caché que se crean como resultado de determinar que no se aplican reglas (es decir, entradas negativas) pueden referirse a una regla de "no autoridad" virtual almacenada en la tabla de autoridades (es decir, entradas virtuales). Esto se hace principalmente para asegurar la consistencia en las estructuras de datos y no afecta el comportamiento visible de estas modalidades.
El campo de acción 1493 en una entrada de tabla caché registra la acción que se tomó en realidad para un objeto de datos. Esta acción se basa en la aplicación de las reglas de coincidencia almacenadas en la tabla de autoridades 1410, que aprueban o no aprueban el objeto de datos. Por ejemplo, el campo de acción de la entrada de tabla caché 1472 indica "no aprobar" para el objeto B. Esto indica que la regla de coincidencia para el objeto B (almacenada en la entrada de tabla de autoridades 1422) valora el objeto B como correspondiente para cumplir con su requerimiento de código y que el objeto B se desaprobó. Una recuperación de esta entrada en la tabla caché por la siguiente solicitud con base en el objeto B entonces puede también desaprobarse. En otras palabras, el campo de acción 1493 de cada entrada de tabla caché almacena la valoración de seguridad del objeto de datos de esa entrada.
El campo de fecha de expiración 1492 indica cuándo una entrada caché ha expirado. En algunas modalidades, la fecha de expiración de una entrada de tabla caché para un objeto de datos se determina, por el contenido del objeto de datos. Algunas modalidades usan la fecha de expiración del certificado del objeto de datos como la fecha de expiración en la entrada de caché. Para los objetos de datos cuya firma se deriva de una cadena de certificados, la fecha de expiración del certificado que expira primero se utilizará en algunas de estas modalidades. En algunas modalidades, la fecha de expiración se determina por las reglas en la tabla de autoridades y se inserta en la tabla caché cuando se crea una entrada de tabla caché. En algunas modalidades, el sistema operativo especifica la fecha de expiración por sí mismo con base en información diferente a los certificados de los objetos de datos. Tal información, en algunas modalidades, puede ser un valor predeterminado suministrado por los distribuidores, el tipo de la operación solicitada, o cualquier otra información disponible para el sistema operativo.
En algunas modalidades, un evaluador de seguridad comprueba el campo de fecha de expiración de una entrada de tabla caché antes de aplicar la entrada. Una entrada de tabla caché que ha expirado de acuerdo con la fecha de expiración, se ignorará (y tratará como fallo de caché) por el evaluador de seguridad. Esto previene que el evaluador de seguridad haga una valoración de seguridad incorrecta con base en entradas obsoletas en la tabla caché 1460. En algunas modalidades, una entrada de tabla caché expirada se purga cuando se accede a ella. Algunas modalidades incluyen un mecanismo de purga que comprueba periódicamente la tabla caché en cuanto a entradas expiradas y removerlas de la tabla.
El campo de ID de resumen criptográfico 1491 almacena un valor de resumen criptográfico. En algunas modalidades, el campo de ID de resumen criptográfico de una entrada de tabla caché almacena un valor que se asocia con un resumen criptográfico del objeto de datos de la entrada de tabla caché. Algunas otras modalidades no incluyen este campo en la tabla caché.
En algunas modalidades el campo de referencia 1494 almacena un enlace de retorno a la entrada en la tabla de autoridades. Específicamente, el campo de referencia 1494 de cada entrada de tabla caché almacena un enlace de regreso a la entrada de tabla de autoridades que se utiliza para generar la entrada de tabla caché (es decir, las reglas de la entrada de tabla de autoridades se utilizan para realizar la valoración de seguridad del objeto de datos asociado con la entrada de tabla caché). Por ejemplo, el campo de referencia de la entrada de tabla caché 1471 puede indicar que la entrada de tabla caché 1471 se genera a partir de la entrada de tabla de autoridades 1421 , y que el campo de referencia de la entrada de tabla caché 1472 puede indicar que la entrada de tabla caché 1472 se genera a partir de la entrada de tabla de autoridades 1422.
Algunas modalidades usan el campo de referencia en la tabla caché para purgar la tabla caché de las entradas que se han vuelto obsoletas debido a cambios en la tabla de autoridades. En algunas modalidades, la tabla caché también incluye un campo de prioridad que se hereda de la tabla de autoridades (no ilustrado). Algunas modalidades usan el campo de prioridad en la tabla caché para purgar la tabla caché de las entradas que se han vuelto obsoletas debido a cambios en la tabla de autoridades. La purga de las entradas de tabla caché se describirán además a continuación en la Sección ll-C y en referencia a la Figura 18.
En algunas modalidades, la tabla caché 1460 incluye otros campos. El contenido de algunos de estos campos de tabla caché se hereda de la entrada de tabla de autoridades que se utiliza para crear la entrada de tabla caché. En algunas modalidades, las entradas en la tabla caché no son necesariamente contiguas, dado que sus direcciones se determinan por valores de resumen criptográfico de los objetos de datos que se utilizan para producir esas entradas. En algunas modalidades, el valor de resumen criptográfico para un objeto de datos se produce al realizar una operación de resumen criptográfico en el objeto de datos. En algunas modalidades, la operación de resumen criptográfico produce un valor de resumen criptográfico que identifica de manera única el objeto de datos a partir de cualquier otro objeto de datos. En algunas modalidades, la operación de resumen criptográfico incluye una operación de resumen criptográfico creciente. Descripciones de la operación de resumen criptográfico creciente pueden encontrarse, por ejemplo, en la Patente de E.U. 7,103,779, que se incorpora por la presente para referencia.
En algunas modalidades, la operación de resumen criptográfico incluye una operación de resumen criptográfico de directorio de código. El resumen criptográfico de directorio de código es un valor único en algunas modalidades, que se refiere a toda entrada única en la tabla caché. Por lo tanto, cada objeto de datos con su requerimiento de código correspondiente se identifica de manera única en la tabla caché, por un resumen criptográfico de directorio de código único. Las descripciones de resumen criptográfico del directorio de código y sus funciones pueden encontrarse en la Publicación de Patente de E.U. 2008/0168553, que se incorpora por la presente para referencia.
En el ejemplo de la Figura 14, la entrada para el objeto A (1471) se almacena en una ubicación que se indiza por un valor de resumen criptográfico del objeto A, la entrada para el objeto B (1472) se almacena en una ubicación que se indiza por un valor de resumen criptográfico del objeto B, y la entrada para el objeto C (1473) se almacena en una ubicación que se indiza por un valor de resumen criptográfico del objeto C.
Para algunas modalidades, la Figura 15 ilustra un evaluador de seguridad 1500 que utiliza tanto la tabla de autoridades como la tabla caché para hacer una valoración de seguridad con base en una solicitud de un iniciador de operaciones. Como se ilustra, el evaluador de seguridad 1500 recibe una solicitud de un iniciador de operaciones 1505 y consulta tanto a una tabla de autoridades 1510 como a una tabla caché 1515. El evaluador de seguridad 1500 incluye un administrador de consultas 1520 para consultar la tabla de autoridades y un administrador de consultas 1525 para consultar la tabla caché. El evaluador de seguridad 1500 también incluye un procesador 1530 y un generador de registros de tabla caché 1540. El administrador de consultas 1520 para consultar la tabla de autoridades 1510 también incluye un motor de reglas 1550, un selector de registro 1560, y un verificador de firma 1570.
El iniciador de operaciones 1505 hace las solicitudes de valoración de seguridad y espera que los resultados de la valoración de seguridad provengan del procesador 1530 del evaluador de seguridad. El procesador 1530 recibe las solicitudes de valoración de seguridad del iniciador de operaciones 1505. Con base en esta solicitud de valoración de seguridad recibida, el procesador se comunica con ambos administradores de consultas 1520 (para la tabla de autoridades) y 1525 (para la tabla caché) con el fin de determinar si se aprueba la solicitud de valoración de seguridad. También usa el generador de registros de tabla caché 1540 para generar nuevas entradas de caché cuando hay un fallo de caché en la tabla caché 1515. El generador de registros de tabla caché también se utiliza para generar una dirección para la memoria física de la tabla caché 1515 al resumir criptográficamente los objetos de datos que son el sujeto de la solicitud (es decir, códigos de programación o documentos).
El administrador de consultas 1525 para consultar la tabla caché proporciona una interfaz entre el procesador 1530 y la memoria física que contiene la tabla caché 1515. El administrador de consultas 1520 para consultar la tabla de autoridades proporciona una interfaz entre el procesador 1530 y la memoria física que contiene la tabla de autoridades 1510. El administrador de consultas 1520 también usa el selector de registro 1560 para seleccionar y recuperar una entrada de la tabla de autoridades 1510. La entrada recuperada entonces se retransmite al motor de reglas 1550 para analizarse y ejecutarse. En algunas modalidades, el administrador de consultas 1520 usa el verificador de firma 1570 para verificar la firma de código del objeto de datos. En algunas modalidades semejantes, si la firma de código no se autentica apropiadamente por cualquier razón, el evaluador de seguridad 1500 devuelve un mensaje de desaprobación al iniciador de operaciones 1505. En algunas modalidades, las funcionalidades del motor de reglas 1550, el selector de registro 1560, y el verificador de firma 1570 se realizan por el procesador 1530 en lugar del administrador de consultas 1520.
El módulo verificador de firma 1570 autentica la firma de código del objeto de datos. En algunas modalidades, el módulo verificador de firma autentica la firma al utilizar la información en un certificado de clave pública así como el contenido del objeto de datos en sí. El módulo verificador de firma realiza la operación de autenticación de firma de acuerdo con un algoritmo de autenticación de firma que se identifica por el certificado. Con la terminación del proceso de autenticación de firma, el módulo verificador de firma informa al evaluador de seguridad 1500 si la firma del objeto de datos se autenticó con éxito.
La Figura 16 ilustra la generación y almacenamiento de una entrada de tabla caché para un objeto de datos por un evaluador de seguridad 1600. Específicamente, la figura ilustra la generación de diferentes campos en una entrada de tabla caché cuando se hace una solicitud al evaluador de seguridad con base en el objeto de datos. La Figura 16 ilustra una tabla de autoridades 1605, una tabla caché 1610, y un iniciador de operaciones 1620 que hace una solicitud ai evaluador de seguridad 1600 para el objeto de datos 1625. La tabla caché incluye las entradas 161 1-1613.
El evaluador de seguridad 1600 incluye un administrador de consultas 1630 para la tabla de autoridades, un módulo de resumen criptográfico 1650, una interfaz de memoria 1660, y un módulo de extracción de fecha de expiración 1670. Para algunas modalidades, el administrador de consultas 1630 es similar al administrador de consultas 1520 en la Figura 15, en tanto que las funciones del módulo de resumen criptográfico 1650, y el módulo de extracción de fecha de expiración 1670 se realizan por un procesador similar al procesador 1530 de la Figura 15. El evaluador de seguridad 1600 también incluye otros módulos, tal como un módulo verificador de firma, que no se muestran para el propósito de simplificación de la figura.
El iniciador de operaciones 1620 hace una solicitud al evaluador de seguridad 1600 para una valoración de seguridad con respecto a una operación que requiere el uso de un objeto de datos 1625 (objeto de datos 'X'). El objeto de datos 1625 se retransmite a varios módulos en el evaluador de seguridad 1600, incluyendo el administrador de consultas 1630, el módulo de resumen criptográfico 1650, y el módulo de extracción de fecha de expiración 1670. El administrador de consultas 1630 encuentra una entrada de la tabla de autoridades 1605 que coincide con el objeto de datos 1625. El administrador de consultas entonces aplica las reglas de la entrada coincidente para determinar la acción apropiada para el objeto de datos 1625. Esta acción tomada por el administrador de consultas forma el campo de acción 1642 para una nueva entrada de tabla caché 1612.
El módulo de resumen criptográfico 1650 recibe el objeto de datos 1625 y realiza una operación de resumen criptográfico en el objeto de datos recibido. En algunas modalidades, la operación de resumen criptográfico es una operación de resumen criptográfico creciente. El módulo de resumen criptográfico 1650 produce un valor de resumen criptográfico de directorio de código único 1655 que sirve como índice ('índice para X') para especificar una ubicación en la tabla caché para la entrada de tabla caché recién creada para el objeto de datos X. La interfaz de memoria 1660 entonces usa este valor como dirección física para la tabla caché. En algunas modalidades, este valor de resumen criptográfico de directorio de código generado de manera única se almacenará en el campo de ID de resumen criptográfico de la entrada 1612 para el objeto de datos X.
El módulo de extracción de fecha de expiración 1670, que también recibe el objeto de datos 1625, calcula o extrae la fecha de expiración del objeto de datos 1625. En algunas modalidades, la fecha de expiración de un objeto de datos se especifica por el certificado que se utiliza para generar la firma del objeto de datos. Un objeto de datos puede tener su firma derivada de más de un certificado o incluso cadena de certificados. Para tal objeto de datos, algunas modalidades usan la primera fecha de expiración entre estos certificados como la expiración para la entrada de tabla caché. La fecha de expiración extraída se vuelve el campo de fecha de expiración 1675. En algunas modalidades, el módulo de extracción de fecha de expiración 1670 usa otra información como la base para determinar las fechas de expiración. En algunas otras modalidades, el campo de fecha de expiración 1675 se hereda de la tabla de autoridades y no se calcula por el módulo de extracción de fecha de expiración 1670.
El campo de acción 1642, y el campo de fecha de expiración 1675 se concatenan en conjunto para formar una nueva entrada de tabla caché 1612 para el objeto de datos X, en conjunto con un campo de ID de resumen criptográfico y un campo de referencia para el objeto de datos X. La tabla caché 1610 tiene otras dos entradas para otros dos objetos (entrada 1611 para el objeto de datos Y, y entrada 1613 para el objeto Z).
En algunas modalidades, los contenidos de una tabla caché pueden compartirse a través de diferentes computadoras que corren sistemas operativos similares. Una computadora puede importar una tabla caché que se genera por otra computadora, o una tabla caché preempacada que se suministra por el distribuidor del sistema operativo. Una computadora que utiliza tal tabla caché prellenada inmediatamente puede acelerar sus operaciones de valoración de seguridad sin tener que generar sus propias entradas de caché.
Para algunas modalidades, la Figura 17 ilustra conceptualmente un proceso 1700 que utiliza tanto la tabla de autoridades como la tabla caché para realizar una valoración de seguridad. El proceso intenta primero encontrar una entrada coincidente en la tabla caché. Si el proceso no es capaz de encontrar tal entrada en la tabla caché (es decir, fallo de caché), consultará la tabla de autoridades para encontrar una entrada coincidente en cambio. La consulta de la tabla de autoridades resulta en una nueva entrada en la tabla caché. Este proceso se realiza por el evaluador de seguridad del sistema operativo, en algunas modalidades.
El proceso 1700 inicia cuando una solicitud para una operación (por ejemplo, ejecutar una aplicación, instalar una aplicación, o abrir un documento) se hace por el iniciador de operaciones. El proceso recibe (en 17 0) esta solicitud en conjunto con el objeto de datos que se necesita por la operación solicitada.
El proceso después determina (en 1720) un valor de resumen criptográfico para el objeto de datos (es decir, el valor de resumen criptográfico de directorio de código único). El valor de resumen criptográfico se calcula en algunas modalidades por una operación de resumen criptográfico creciente. El valor de resumen criptográfico calculado actúa como índice para localizar la entrada en la tabla caché para el objeto de datos. Después, el proceso determina (en 1730) si es capaz de encontrar una entrada de tabla caché al utilizar el valor de resumen criptográfico. Esta determinación, en algunas modalidades, se basa en sí hay una entrada válida almacenada en la ubicación indicada por el valor de resumen criptográfico. En algunas de estas modalidades, cada entrada de tabla caché se asocia con un bit que indica si la entrada de tabla caché es válida o no. Una entrada de tabla caché no es válida si no se ha llenado por una entrada de caché para un objeto de datos, o si la entrada de tabla caché se ha purgado y no se ha llenado todavía con una nueva entrada de caché. Si el proceso es capaz de encontrar una entrada válida al utilizar el valor de resumen criptográfico del objeto de datos (presencia en caché), el proceso procede a 1740. De otra manera, (fallo de caché), el proceso procede a 1750.
En 1740, el proceso determina la respuesta a la solicitud de valoración de seguridad con base en el contenido de la entrada de tabla caché coincidente. El proceso entonces determina (en 1780) si la respuesta es una aprobación de la operación solicitada. Si la respuesta aprueba la operación, el proceso procede a 1790, en el cual el iniciador de operaciones hace pasar la solicitud a un manipulador de operaciones, tal como el módulo de ejecución 172, el módulo de instalación 170, o el módulo de apertura de contenido 174 de la Figura 1. Si la respuesta no aprueba la operación, el iniciador de operaciones evita que la operación proceda al no hacer pasar la solicitud al manipulador de operaciones. Después de responder al iniciador de operaciones con base en los contenidos de la entrada de tabla caché, el proceso 1700 finaliza.
En 1750, el proceso consulta la tabla de autoridades a causa del fallo de caché en la tabla caché. En algunas modalidades, esta operación se realiza por el proceso 1300 de la Figura 13, que busca en la tabla de autoridades una entrada que coincida con la solicitud.
Después, el proceso determina (en 1755) si fue capaz de encontrar una entrada coincidente en la tabla de autoridades. Si es así, el proceso procede a 1760. De otra manera, el proceso procede a 1770 para crear una entrada de caché negativa para el objeto de datos y luego finaliza. La entrada de caché negativa para el objeto de datos, como se discute anteriormente, habilita al evaluador de seguridad para constatar rápidamente que las directrices de seguridad del sistema operativo no tienen reglas que son aplicables a la solicitud particular.
En 1760, el proceso determina una respuesta de la entrada coincidente de la tabla de autoridades. El proceso después crea (en 1765) una nueva entrada en la tabla caché con base en esta entrada coincidente de la tabla de autoridades. El proceso entonces procede a 1780 para determinar si aprobar o desaprobar la operación solicitada. Después de responder al iniciador de operaciones con base en los contenidos de la entrada de tabla de autoridades, el proceso 1700 finaliza.
C. Invalidación de usuario En algunas modalidades, a los usuarios con suficientes privilegios se les permite hacer cambios a la base de datos de reglas al agregar, eliminar o modificar entradas en la tabla de autoridades. Por ejemplo, un usuario con privilegio de administrador puede eludir la autenticación de firma para ejecutar una aplicación particular. El usuario puede hacerlo así al agregar, una entrada de prioridad superior en la tabla de autoridades que suplanta las reglas de prioridad inferior, y lo que en consecuencia permite que la aplicación particular se ejecute.
Sin embargo, como se muestra en la Figura 10 anterior, una directriz de seguridad a menudo incluye una serie de entradas de tabla que se enlazan en conjunto por las prioridades. Por lo tanto, valorar un objeto de datos bajo una directriz de seguridad requiere examinar estas entradas de tabla en el orden expuesto por sus prioridades. Para cualquier valoración de seguridad determinada para un objeto de datos, reglas de prioridad inferior se hacen aplicables sólo cuando las reglas de prioridad superior no son aplicables. Por tanto, cualquier cambio a una regla de prioridad superior cambia potencialmente la aplicabilidad de las reglas de prioridad inferior.
Dado que la tabla caché almacena entradas de caché que reflejan la aplicabilidad de las reglas antes del cambio en la tabla de autoridades, en algunas modalidades, un cambio en la tabla de autoridades de una prioridad particular activa la purga de todas las entradas de prioridad igual o inferior en la tabla caché. Por ejemplo, una nueva entrada de tabla de autoridades con el valor de prioridad 2.3 puede activar la purga de todas las entradas de tabla caché con valores de prioridades iguales o inferiores a 2.3. En algunas modalidades, este proceso de purga usa el campo de referencia (por ejemplo, 1494 de la Figura 14) en cada una de las entradas de tabla caché para aprender la prioridad de la entrada de tabla de autoridades que se utiliza para crear la entrada de tabla caché. En algunas otras modalidades, cada entrada de tabla caché lleva un campo de prioridad que se hereda de la tabla de autoridades para este propósito.
En algunas modalidades, se asume que una entrada de caché negativa tiene la prioridad más baja. Dado que una entrada negativa es la entrada de tabla caché de un objeto de datos que no tiene entrada coincidente en la tabla de autoridades, cualquier cambio en la tabla de autoridades puede afectar el objeto de datos de la entrada negativa (es decir, el cambio en la autoridad da lugar a potencialmente a que el objeto de datos tenga una entrada coincidente en la tabla de autoridades, lo que de esta manera hace obsoleta la entrada negativa). En algunas de estas modalidades, cualquier cambio a la tabla de autoridades siempre da lugar a que se purguen entradas de caché negativas.
Para algunas modalidades, la Figura 18 ilustra conceptualmente un proceso que mantiene la tabla de reglas después de un cambio en la base de datos de reglas por un usuario administrativo. El proceso purga las entradas de prioridad inferior de la tabla caché. El proceso 1800 inicia cuando un usuario con privilegios (por ejemplo, administrador) hace un cambio a la base de datos de reglas. El proceso recibe (en 1810) el cambio de regla del usuario con privilegios y determina (en 1820) si el cambio de regla es para una regla que ya está en la tabla de autoridades. Si el cambio de regla es para una regla que ya está en una entrada de tabla de autoridades, el proceso procede a 1840 para actualizar la entrada de tabla de autoridades. Si no, el proceso procede a 1830 para hacer una nueva entrada en la tabla de autoridades.
El proceso después determina (en 1850) si hay entradas en la base de datos de reglas con prioridad inferior a la de la regla recién agregada o actualizada. Si es así, el proceso procede a 1860. De otro modo, el proceso 1800 termina.
En 1860, el proceso elimina todas las entradas de prioridad inferior de la tabla caché. En algunas modalidades, el proceso examina todas las entradas ocupadas en la tabla caché y purga las entradas con prioridades inferiores o iguales a la entrada de tabla de autoridades recién agregada o actualizada. Después de eliminar todas las entradas de tabla caché de prioridad inferior (incluyendo cualquier entrada negativa), el proceso 1800 termina.
III. VALORACIÓN DE SEGURIDAD DE CONTENIDO DESCARGADO Algunas de las modalidades descritas antes usan certificados que se incrustan en objetos de datos para hacer una valoración de seguridad acerca de estos objetos de datos. En la mayor parte de los casos, estos métodos dependen de identificadores que se proporcionan por la fuente de estos objetos de datos (por ejemplo, firmas e ID de distribuidor en los certificados). Sin embargo, estos identificadores proporcionados por fuentes no siempre se encuentran disponibles o son confiables. De esta manera, además o en lugar de depender de estos identificadores proporcionados por fuentes para realizar la valoración de seguridad, el sistema operativo de algunas modalidades proporciona su propio identificador para los objetos de datos. En algunas de estas modalidades, el sistema operativo asocia una etiqueta con objetos de datos que se importan de fuentes externas tales como la Internet, una pastilla de memoria USB, o a través de otra interfaz de periféricos del dispositivo. La etiqueta incluye un bit de cuarentena para indicar que el objeto de datos es de una fuente externa. La presencia del bit de cuarentena además indica que el sistema no ha realizado valoración de seguridad en el objeto de datos. Una vez que el sistema operativo ha realizado valoración de seguridad en el objeto de datos, la etiqueta se actualiza (por ejemplo, al remover el bit de cuarentena) para indicar que el objeto de datos ya se ha valorado bajo la directriz de seguridad del sistema operativo, y que el objeto de datos ha hecho pasar (o fallado) la directriz de seguridad del sistema operativo.
La Figura 19 ilustra una computadora 1900 con un sistema operativo que usa su propio identificador para realizar valoración de seguridad. Específicamente, el sistema operativo de la computadora 1900 agrega una etiqueta o bit de cuarentena al contenido y/o aplicaciones que, por ejemplo, se descargan de la Internet. La computadora 1900 incluye un dispositivo de almacenamiento 1910, un módulo de etiqueta 1920, una aplicación 1930 que corre actualmente en la computadora 1900, una interfaz de red 1940, y un módulo de interfaz de usuario (Ul) 1950. El módulo de Ul 1950 controla la comunicación con el usuario a través de los controladores de dispositivos de entrada de datos 1960 y un módulo de visualización 1970.
La interfaz de red 1940 proporciona la interfaz de comunicación entre la computadora 1900 y el mundo exterior mediante una red. La red permite que la computadora 1900 se comunique a través de la Internet 1980 y acceda a objetos de datos tales como los archivos de aplicaciones 1981-1982 y archivos de contenido 1983-1984 de otras computadoras. Estos archivos de contenido pueden ser archivos de texto, documentos de procesador de palabras, hojas de cálculo, archivos multimedia, etc. Los archivos de aplicaciones pueden incluir archivos de instalación y programa. Estos archivos de aplicación y contenido entonces pueden descargarse en la computadora 1900. Aunque no se muestra en la figura, la computadora 1900 también puede descargar objetos de datos de fuentes externas diferentes a la Internet (tal como una pastilla de memoria externa).
La aplicación 1930 es un programa o un conjunto de procesos que corren actualmente en la computadora 1900 mediante el sistema operativo. La aplicación 1930 puede ser un buscador de Internet, un procesador de palabras, un videojuego, una aplicación de edición multimedia o cualquier programa que pueda operarse en la computadora 1900. La aplicación 1930 puede realizar operaciones que requieren comunicación a través de la Internet, incluyendo la descarga de objetos de datos 1981-1984 de fuentes a través de la Internet mediante la interfaz de red. Una vez que los archivos se han descargado, la aplicación 1930 almacena los archivos descargados en el dispositivo de almacenamiento 1910. En algunas modalidades, los archivos descargados deben ir a través del módulo de etiqueta 1920 antes de almacenarse.
El módulo de etiqueta 1920 asocia cada archivo descargado con una etiqueta. En algunas modalidades, tal etiqueta incluye un bit de cuarentena para indicar que el archivo descargado es de una fuente externa y no se ha examinado bajo la directriz de seguridad del sistema operativo. En algunas modalidades, el módulo de etiqueta inserciones o adjunta la etiqueta en el archivo descargado. En algunas modalidades, el módulo de etiqueta mantiene una tabla de etiquetas que registra cuáles archivos son de la Internet u otras fuentes externas. Otros procesos o módulos que corren en la computadora pueden acceder a la tabla de etiquetas para encontrar cuáles archivos u objetos de datos están etiquetados como provenientes de fuentes externas tales como la Internet. Algunas modalidades asocian una etiqueta con un archivo de la fuente externa tan pronto como se descarga por la aplicación 1930 y antes de que el archivo se almacene en el dispositivo de almacenamiento 1910.
El dispositivo de almacenamiento 1910 almacena diversos objetos de datos para la computadora 1900. Estos objetos de datos pueden incluir archivos de contenido y archivos de aplicación que se descargan de la Internet u otras fuentes externas. En algunas modalidades, estas aplicaciones y archivos de contenido descargados se asocian con etiquetas que se suministran por el módulo de etiqueta 1920.
Una vez que los archivos descargados se almacenan y etiquetan, el sistema operativo puede realizar una valoración de seguridad con base en las directrices de seguridad que consideran si un objeto de datos se descarga o no. La Figura 20 ilustra, un sistema operativo 2000 cuya directriz de seguridad requiere comprobar la presencia de etiqueta o bits de cuarentena. Específicamente, el sistema operativo 2000 incluye un mecanismo para identificar si un objeto de datos está etiquetado o no antes de realizar operaciones de valoración de seguridad. Las operaciones de valoración de seguridad son similares a las descritas en las Secciones I y II anteriores.
Como se ilustra, el sistema operativo 2000 incluye un solicitante de operaciones 2005, un evaluador de seguridad 2020, una base de datos de reglas 2030, y un iniciador de operaciones 2010. El iniciador de operaciones incluye un procesador 2040 y un módulo identificador de etiqueta 2050. El sistema operativo también incluye un módulo de instalación 2060 y un módulo de apertura de contenido 2070.
En algunas modalidades, el sistema operativo 2000 es similar al sistema operativo 100 de la Figura 1. Específicamente, el solicitante de operaciones 2005, como el solicitante de operaciones 140, hace solicitudes de rendimiento de operaciones al iniciador de operaciones 130. Como el módulo de instalación 170 y el módulo de apertura de contenido 174, el módulo de instalación 2060 y el módulo de apertura de contenido 2070 son los manipuladores de operaciones que reciben las solicitudes aprobadas y realizan la operación aprobada.
El evaluador de seguridad 2020 y la base de datos de reglas 2030 realizan operaciones similares a las del evaluador de seguridad 110 y la base de datos de reglas 120 ilustrada en la Figura 1. Las funciones del evaluador de seguridad y la base de datos de reglas también se describen antes en la Sección II en referencia a las Figuras 7-17. Por ejemplo, la base de datos de reglas 2030 incluye una tabla de autoridades y una tabla caché en algunas modalidades. En algunas modalidades, el evaluador de seguridad 2020 realiza valoración de seguridad del objeto etiquetado con base en la señal de entrada del usuario. Por ejemplo, al recibir una solicitud de valoración de seguridad para un objeto etiquetado, el evaluador de seguridad 2020 informa al usuario que la operación solicitada implica un objeto descargado y pregunta al usuario si procede conociendo los riesgos.
El iniciador de operaciones 2010, como el iniciador de operaciones 130, exige la directriz de seguridad del sistema operativo al permitir o rechazar que una operación particular tenga lugar. Recibe una solicitud para la operación particular del solicitante de operaciones 2005 y solicita al evaluador de seguridad 2020 valorar la operación solicitada bajo las directrices de seguridad del sistema operativo 2000. Sin embargo, a diferencia del iniciador de operaciones 130 de la Figura 1 , el iniciador de operaciones 2010 comprueba si el objeto de datos para la operación solicitada está etiquetado como si fuera de la Internet o cualquier otra fuente externa. Los objetos de datos que están etiquetados como si fueran de una fuente externa (por ejemplo, etiquetados con un bit de cuarentena) se someten a valoración de seguridad. Con el fin de evitar la valoración de seguridad repetida en los objetos de datos que ya se han valorado, algunas modalidades actualizan la etiqueta después de la valoración de seguridad para indicar que el objeto de datos ya se ha valorado previamente. Algunas modalidades consiguen esto al remover el bit de cuarentena. En algunas modalidades, la etiqueta actualizada también indica si el objeto de datos ha pasado o fallado la valoración de seguridad previa.
En el ejemplo de la Figura 20, el módulo identificador de etiqueta 2050 en el interior del iniciador de operaciones 2010 comprueba la etiqueta y reporta al módulo procesador 2040. En el sistema operativo 2000, el evaluador de seguridad 2020 no hace su valoración de seguridad con base en la etiqueta. Es el procesador 204 dentro del iniciador de operaciones 2010 que utiliza la etiqueta para decidor si se procede con la operación solicitada. En algunas de estas modalidades, el iniciador de operaciones 2010 procede con la valoración de seguridad sólo si el objeto de datos asociado con la operación solicitada está etiquetado como si fuera de una fuente externa y que nunca se ha valorado. Si el objeto de datos está etiquetado como tal (por ejemplo, si el bit de cuarentena se ha removido, o si el objeto de datos ya está etiquetado como si se hubiera valorado previamente), el iniciador de operaciones 2010 no solicitará al evaluador de seguridad realizar la valoración de seguridad.
Las Figuras 21-22 ilustran el flujo de datos en el sistema operativo 2000 cuando se realiza una valoración de seguridad al utilizar un iniciador de operaciones que identifica etiquetas en objetos de datos. Como en la Figura 20, el sistema operativo 2000 en las Figuras 21-22 incluye el evaluador de seguridad 2020, la base de datos de reglas 2030, el iniciador de operaciones 2010, el solicitante de operaciones 2005, el módulo de instalación 2060, el módulo de ejecución 172, y el módulo de apertura de contenido 2070.
La Figura 21 ilustra el flujo de datos de una operación que instala una aplicación en el sistema operativo 2000. La operación inicia en el solicitante de operaciones 2005 cuando hace una solicitud para instalar la Aplicación X (operación ) al iniciador de operaciones 2010. El procesador 2040 entonces envía un comando al módulo identificador de etiqueta 2050 para preguntar si la Aplicación X está etiquetada (operación '2'). Si la Aplicación X está etiquetada como si fuera de una fuente externa (por ejemplo, con un bit de cuarentena), el identificador de etiqueta 2050 envía la confirmación al procesador 2040 (operación '3'), y el procesador a su vez hace una solicitud al evaluador de seguridad 2020 (operación '4') para realizar la valoración de seguridad. Por otro lado, si la Aplicación X no está etiquetada, o si la Aplicación X está etiquetada como si se hubiera valorado previamente (o con su bit de cuarentena removido), el procesador 2040, en algunas modalidades, no solicitará al evaluador de seguridad 2020 realizar la valoración de seguridad. En algunas modalidades, si la Aplicación X está etiquetada como si hubiera fallado en la valoración de seguridad previa, el procesador 2040 puede finalizar inmediatamente el proceso de instalación sin implicar al evaluador de seguridad 2020. Por el contrario, si la Aplicación X está etiquetada como si hubiera pasado la valoración de seguridad previa, el procesador 2040, en algunas modalidades, puede permitir inmediatamente que la Aplicación X proceda sin implicar al evaluador de seguridad 2040.
Si la solicitud para la valoración de seguridad se ha hecho, el evaluador de seguridad 2020 consulta la base de datos de reglas 2030 (operación '5'). La base de datos de reglas 2030 proporciona (operación '6') las reglas o instrucciones en su base de datos al evaluador de seguridad 2020. Este proceso de consulta entre el evaluador de seguridad 2020 y la base de datos de reglas 2030 continúa hasta que una regla de coincidencia se encuentra en la base de datos de reglas o hasta que se hace una determinación de que no hay regla aplicable en la base de datos de reglas.
Una vez que se ha encontrado una regla de coincidencia, el evaluador de seguridad 2020 aplica la regla de coincidencia a los objetos de datos en relación con la instalación de la Aplicación X. La valoración de seguridad entonces se comunica nuevamente al iniciador de operaciones 2010 (operación '7'). En el ejemplo de la Figura 21 , la comunicación del evaluador de seguridad nuevamente al iniciador de operaciones indica que está listo para instalar la Aplicación X, dado que se ha encontrado que los objetos de datos en relación con la instalación de la Aplicación X cumplen con las directrices de seguridad almacenadas en la base de datos de reglas.
Al saber que la Aplicación X ha pasado la valoración de seguridad realizada por el evaluador de seguridad 2020, el procesador 2040 determina si se procede con la instalación de la Aplicación X. Además de la valoración de seguridad hecha por el evaluador de seguridad, el procesador 2040, en algunas modalidades, considera si la Aplicación X está etiquetada o no. Si el procesador decide que está listo para proceder con la instalación de la Aplicación X, envía un comando al módulo de instalación 2060 para lanzar la instalación de la Aplicación X (operación '8'). Las líneas discontinuas alrededor del módulo de apertura de contenido 2070 indican que no está implicado en esta operación.
La Figura 22 ilustra un diagrama de flujo de datos para una operación que abre un documento en el sistema operativo 2000. La operación inicia en el solicitante de operaciones 2005 cuando hace una solicitud para abrir el archivo de datos X (operación T) al iniciador de operaciones 2010. El procesador 2040 entonces envía un comando al módulo identificador de etiqueta 2050 para preguntar si el archivo de datos X está etiquetado (operación '2'). Si el archivo de datos X está etiquetado como si fuera de una fuente externa (por ejemplo, con un bit de cuarentena), el identificador de etiqueta 2050 envía la confirmación al procesador 2040 (operación '3'), y el procesador a su vez hace una solicitud al evaluador de seguridad 2020 (operación '4') para realizar la valoración de seguridad. Por otro lado, si el archivo de datos X no está etiquetado, o si el archivo de datos X está etiquetado como si se hubiera valorado previamente, el procesador 2040, en algunas modalidades, no solicitará al evaluador de seguridad 2020 realizar la valoración de seguridad. En algunas modalidades, si el archivo de datos X está etiquetado como si hubiera fallado en la valoración de seguridad previa, el procesador 2040 puede finalizar inmediatamente el proceso de apertura de archivo sin implicar al evaluador de seguridad 2020. Por el contrario, si el archivo de datos X está etiquetado como si hubiera pasado la valoración de seguridad previa, el procesador 2040, en algunas modalidades, puede permitir inmediatamente que la apertura del archivo de datos X proceda sin implicar al evaluador de seguridad 2040.
Si la solicitud para la valoración de seguridad se ha hecho, el evaluador de seguridad 2020 consulta la base de datos de reglas 2030 (operación '5'). La base de datos de reglas 2030 proporciona (operación '6') las reglas o instrucciones en su base de datos al evaluador de seguridad 2020. Este proceso de consulta entre el evaluador de seguridad 2020 y la base de datos de reglas 2030 continúa hasta que una regla de coincidencia se encuentra en la base de datos de reglas o hasta que se hace una determinación de que no hay regla aplicable en la base de datos de reglas.
Una vez que se ha encontrado una regla de coincidencia, el evaluador de seguridad 2020 aplica las reglas de coincidencia a los objetos de datos en relación con la apertura del archivo de datos X. La valoración de seguridad entonces se comunica nuevamente al iniciador de operaciones 2010 (operación '7'). En el ejemplo de la Figura 22, la comunicación del evaluador de seguridad nuevamente al iniciador de operaciones indica que está listo para abrir el archivo de datos X, dado que se ha encontrado que el archivo de datos X cumple con las directrices de seguridad almacenadas en la base de datos de reglas.
Al saber que el archivo de datos X ha pasado la valoración de seguridad realizada por el evaluador de seguridad 2020, el procesador 2040 determina si se procede con la apertura del archivo de datos X. Además de la valoración de seguridad hecha por el evaluador de seguridad, el procesador 2040, en algunas modalidades, considera si el archivo de datos X está etiquetado o no. Si el procesador decide que está listo para proceder con la apertura del archivo de datos X, envía un comando al módulo de apertura de contenido 2070 para lanzar la apertura del archivo de datos X (operación '8'). Las líneas discontinuas alrededor del módulo de instalación 2060 indican que no está implicado en esta operación.
Las Figuras 20-22 ilustran un sistema operativo 2000 que tiene un iniciador de operaciones 2010 que decide si un objeto de datos está etiquetado como si fuera de una fuente externa tal como la Internet. El iniciador de operaciones 2010 del sistema operativo 2000 también hace la determinación de si se procede con una operación con base en la etiqueta. Las reglas almacenadas en la base de datos de reglas no consideran o procesan la etiqueta. En algunas otras modalidades, sin embargo, la base de datos de reglas del sistema operativo incluye reglas que identifican la etiqueta y hacen valoraciones de seguridad con base en la etiqueta identificada Para algunas modalidades, la Figura 23 ilustra un sistema operativo 2300 que incluye una base de datos de reglas con reglas para procesar etiquetas asociadas con objetos de datos descargados. El iniciador de operaciones, en algunas modalidades semejantes, no comprueba la etiqueta del objeto de datos que se asocia con la operación solicitada. Como el sistema operativo 2000, el sistema operativo 2300 incluye un solicitante de operaciones 2305, un evaluador de seguridad 2320, una base de datos de reglas 2330, y un iniciador de operaciones 2310. El sistema operativo también incluye un módulo de instalación 2360 y un módulo de apertura de contenido 2370.
El iniciador de operaciones 2310 recibe solicitudes para operaciones del solicitante de operaciones 2305 y hace solicitudes para valoraciones de seguridad al evaluador de seguridad 2320. Sin embargo, a diferencia del iniciador de operaciones 2010, el iniciador de operaciones 2310 no realiza la comprobación de etiquetas descargadas.
El evaluador de seguridad 2320 recibe las solicitudes para valoraciones de seguridad del iniciador de operaciones 2310 y consulta la base de datos de reglas para reglas que coinciden con el objeto de datos asociado con cada solicitud de valoración de seguridad.
La base de datos de reglas 2330 almacena las reglas para realizar la valoración de seguridad. A diferencia de la base de datos de reglas 2030, la base de datos de reglas 2330 también incluye reglas para analizar objetos de datos para ver si están etiquetados. Si el objeto de datos está etiquetado, algunas modalidades entonces proceden a aplicar las reglas en la base de datos de reglas para realizar la valoración de seguridad en el objeto de datos y aprobar/desaprobar la operación solicitada. En algunas modalidades, la base de datos de reglas 2330 incluye una tabla de autoridades y una tabla caché, como se describe antes en la Sección II. Por ejemplo, un objeto de datos que se desaprobó por una primera valoración de seguridad a causa de su bit de cuarentena, puede tener una entrada de caché con un campo de acción que desaprueba el objeto de datos.
IV. VALORACIÓN DE SEGURIDAD DE DOCUMENTOS Dado que una firma para identificar la fuente de un objeto de datos se deriva en parte con base en el contenido del objeto de datos, las firmas pueden utilizarse para probar si el objeto de datos se ha alterado. Esto también significa que un objeto de datos cuyo contenido se cambia frecuentemente por los usuarios (por ejemplo, un documento) no puede tener su propia firma. Sin embargo, un archivo de datos puede colocarse en una estructura (tal como un paquete) que es capaz de llevar un certificado que incluye una firma. Tal firma puede utilizarse para identificar de un modo seguro la fuente de los archivos de datos en la estructura. En algunas modalidades, el sistema operativo incluye reglas en la base de datos de reglas que aprueban o desaprueban los documentos o archivos de datos con base en los identificadores en los certificados incrustados en las estructuras de paquetes. Un documento en un paquete aprobado se considera, por algunas de estas modalidades, como aprobados también.
La Figura 24 ilustra una computadora 2400 que recibe y almacena paquetes de datos que tienen certificados. Los certificados (con firmas) entonces pueden utilizarse por el sistema operativo de la computadora 2400 para identificar de un modo seguro la fuente del contenido dentro del paquete. Como se ilustra, la computadora 2400 incluye un dispositivo de almacenamiento 2410, una aplicación 2430 que corre actualmente en la computadora 2400, una interfaz de red 2440, y un módulo de interfaz de usuario (Ul) 2450. El módulo de Ul 2450 controla la comunicación con el usuario a través de los controladores de dispositivos de entrada de datos 2460 y un módulo de visualización 2470.
La interfaz de red 2440 proporciona la interfaz de comunicación entre la computadora 2400 y el mundo exterior mediante una red. La red permite que la computadora 2400 se comunique a través de la Internet y acceda a objetos de datos tales como los paquetes de datos 2481-2484 de otras computadoras. El contenido de estos paquetes puede ser archivos de texto, documentos de procesador de palabras, hojas de cálculo, archivos multimedia, etc. El contenido de estos paquetes también puede ser aplicaciones ejecutables o archivos de instalación de aplicaciones. Algunos o todos estos paquetes de datos tienen certificados con firmas que identifican su fuente. Un paquete de datos puede contener una pieza de contenido (tal como el paquete de datos 2481) o múltiples piezas de contenidos o archivos (tal como el paquete de datos 2484). Aunque no se muestra en la figura, la computadora 2400 también puede acceder a paquetes de datos de otras computadoras a través de otros medios de comunicación de datos, tal como una pastilla de memoria externa.
La aplicación 2430 es un programa o un conjunto de procesos que corren actualmente en la computadora 2400 mediante el sistema operativo. La aplicación 2430 puede ser un buscador de Internet, un procesador de palabras, un videojuego, una aplicación de edición multimedia o cualquier programa que pueda operarse en la computadora 2400. La aplicación 2430 puede realizar operaciones que requieren comunicación con la Internet, incluyendo la descarga de los paquetes de datos 2481-2484 de la Internet mediante la interfaz de red 2440.
Una vez que los paquetes de datos se han descargado, la aplicación 2430 almacena los archivos descargados en el dispositivo de almacenamiento 2410. La operación de almacenamiento de los paquetes de datos en el dispositivo de almacenamiento 2410 es similar a la operación de almacenamiento de datos etiquetados o en cuarentena, como se describe antes en referencia a la Figura 19. El dispositivo de almacenamiento 2410 almacena los paquetes de datos. Una vez que los paquetes de datos se almacenan, el sistema operativo puede realizar valoraciones de seguridad al autenticar las firmas y examinar los certificados incrustados en los paquetes de datos.
La Figura 25 ilustra un sistema operativo que incluye reglas en la base de datos de reglas para hacer valoraciones de seguridad de archivos de datos o documentos con base en los certificados de los paquetes de datos. Específicamente, la Figura 25 ilustra una solicitud ejemplar para abrir el archivo de datos en el sistema operativo 2500. El archivo de datos se incrusta en un paquete de datos.
El sistema operativo 2500 incluye un solicitante de operaciones 2505, un evaluador de seguridad 2520, una base de datos de reglas 2530, un iniciador de operaciones 2510 y un módulo de apertura de contenido 2570. El sistema operativo 2500 también tiene acceso al dispositivo de almacenamiento 2560, que almacena varios paquetes de datos, incluyendo el paquete de datos 2580. En algunas modalidades, el dispositivo de almacenamiento 2560 incluye el almacenamiento 2410 de la Figura 24, que almacena paquetes de datos descargados de la Internet u otras fuentes externas.
En algunas modalidades, el sistema operativo 2500 es similar al sistema operativo 100 de la Figura 1. Específicamente, el solicitante de operaciones 2505, como el solicitante de operaciones 140, hace solicitudes de rendimiento de operaciones al iniciador de operaciones 2510. El iniciador de operaciones 2510 recibe la solicitud del solicitante de operaciones 2505 y hace una solicitud para una valoración de seguridad al evaluador de seguridad 2520. En el ejemplo ilustrado por la Figura 25, la solicitud es para abrir un documento o archivo de datos que se incrusta en el paquete de datos 2580. El iniciador de operaciones 2510 hace la solicitud al evaluador de seguridad 2520 al hacer pasar el paquete de datos 2580 al evaluador de seguridad. Una vez que el iniciador de operaciones 2510 recibe la respuesta del evaluador de seguridad 2520, lanza el módulo de apertura de contenido 2570 o termina la operación solicitada con base en la valoración de seguridad.
El evaluador de seguridad 2520 y la base de datos de reglas 2530 realizan operaciones similares a las del evaluador de seguridad 110 y la base de datos de reglas 120. En algunas modalidades, la base de datos de reglas incluye una tabla de autoridades y una tabla caché, como se describe antes en la Sección II en referencia a las Figuras 7-17. Con el fin de identificar de un modo seguro la fuente de los archivos de datos o documentos, el evaluador de seguridad 2520 autentica la firma antes de aplicar las reglas almacenadas en la base de datos de reglas 2530.
El módulo de apertura de contenido 2570 es similar al módulo de apertura de contenido 174 de la Figura 1. Una vez que recibe el comando de lanzamiento del iniciador de operaciones 2510, el módulo de apertura de contenido 2570 procede a abrir el archivo de datos solicitado. En el ejemplo de la Figura 25, el archivo de datos solicitado para abrirse se encuentra en el paquete de datos 2580, el cual se almacena en el dispositivo de almacenamiento 2560. Para abrir el archivo de datos, el módulo de apertura de contenido 2570, en algunas modalidades, extrae el archivo de datos de la estructura de paquetes y luego abre el archivo de datos (por ejemplo, al enviar el archivo de datos a una aplicación que necesita para abrir el archivo de datos).
Para algunas modalidades, la Figura 26 ilustra conceptualmente un proceso 2600 que realiza valoraciones de seguridad de operaciones de apertura de documentos. Específicamente, el proceso 2600 se realiza por un sistema operativo para hacer la determinación de valoración de seguridad con base en los certificados con firmas incrustados en los paquetes de datos.
El proceso 2600 inicia cuando recibe una solicitud para abrir un archivo de datos (o documento). El proceso recibe (en 2610) el documento que se solicita abrir. El proceso entonces determina (en 2620) si el documento es de un tipo seguro. En algunas modalidades, los documentos o archivos de tipos que se consideran improbables de dañar una computadora, se permiten abrir independientemente de su fuente. Por ejemplo, los archivos de texto se consideran seguros y no requieren firma u otras identificaciones de fuente. Si se considera que el documento es de un tipo seguro, el proceso procede a 2670 para hacer pasar el documento a un manipulador de operaciones (tal como el módulo de apertura de contenido 2570 de la Figura 25) para abrir el documento. Si se considera que el documento no es de un tipo seguro, el proceso procede a 2630. Los documentos que son ejecutables no se consideran seguros en algunas modalidades. Los documentos no ejecutables de ciertos tipos también requieren verificación de fuente en algunas modalidades, dado que tales documentos no ejecutables son capaces de llevar código malicioso que puede dañar la computadora a través de aplicaciones que se abren y usan esos documentos.
Después, el proceso determina (en 2630) si un documento se encuentra en un paquete. Como se menciona antes, algunos archivos de datos o documentos no tienen una firma de identificación de fuente, pero los archivos de datos pueden colocarse en una estructura de paquetes que lleva una firma. Sin embargo, en algunas modalidades, los documentos de ciertos tipos pueden incluir firmas de sí mismos sin estar en un paquete (por ejemplo, los documentos que se cambian raramente pueden llevar una firma que prueba si el archivo se ha alterado). Si el documento se encuentra en un paquete, el proceso 2600 procede a 2650. De otra manera, el proceso procede a 2640 para realizar una valoración de seguridad del documento por sí mismo.
En 2640, el proceso realiza la valoración de seguridad con base en el propio certificado del documento. La operación incluye la autenticación de la firma del documento que se incrusta en el certificado del documento, así como valoraciones de seguridad adicionales con base en otra información en el certificado. En algunas modalidades, el proceso consulta la base de datos de reglas para reglas de coincidencia que pueden utilizarse para hacer una valoración de seguridad en el documento. Esta operación, en algunas modalidades, incluye aplicar requerimientos de código al documento. Los requerimientos de código pueden incluir instrucciones para examinar certificados incrustados en el documento y para comprobar si la fuente es confiable. Después de realizar la valoración de seguridad, el proceso determina (en 2660) si se aprueba el documento para abrirse con base en las reglas de coincidencia. Si es así, el proceso hace pasar (en 2670) el documento a un manipulador de operaciones (tal como el módulo de apertura de contenido 2C70 de la Figura 25) para abrirse. De otro modo, el proceso termina.
En 2650, el proceso realiza la valoración de seguridad con base en el certificado del paquete. La operación incluye la autenticación de la firma que se incrusta en el certificado del paquete, así como valoraciones de seguridad adicionales con base en otra información en el certificado. En algunas modalidades, el proceso consulta la base de datos de reglas para reglas de coincidencia que pueden utilizarse para hacer una valoración de seguridad en el paquete. Esta operación, en algunas modalidades, incluye aplicar requerimientos de código al paquete. Los requerimientos de código pueden incluir instrucciones para examinar certificados en el paquete y comprobar si la fuente es confiable. El proceso entonces determina (en 2660) si se aprueba el paquete y, por tanto, todos los documentos en el paquete para abrirse con base en las reglas de coincidencia. Si es así, el proceso hace pasar (en 2670) el documento a un manipulador de operaciones (tal como el módulo de apertura de contenido 2570 de la Figura 25) para abrirse. De otro modo, el proceso termina.
V. SISTEMA ELECTRÓNICO Muchos de los atributos y aplicaciones descritos anteriormente, se implementan como procesos de software que se especifican como un conjunto de instrucciones registradas en un medio de almacenamiento legible por computadora (también referido como medio legible por computadora). Cuando estas instrucciones se ejecutan por una o más unidades computacionales o de procesamiento (por ejemplo, uno o más procesadores, núcleo de procesadores, u otras unidades de procesamiento), dan lugar a que la o las unidades de procesamiento realicen las acciones indicadas en las instrucciones. Ejemplos de medios legibles por computadora incluyen, pero no se limitan a, CD-ROMs, pastillas de memoria, memoria de acceso aleatorio (RAM) chips, discos duros, memorias de sólo lectura programables regrabables (EPROMs), memorias de sólo lectura programables eléctricamente regrabables (EEPROMs), etc. Los medios legibles por computadora no incluyen ondas portadoras y las señales electrónicas se hacen pasar de manera inalámbrica o a través de conexiones por cable.
En esta especificación, el término "software" quiere decir que incluye firmware que reside en memoria de sólo lectura o aplicaciones almacenadas en almacenamiento magnético que puede leerse en la memoria para procesamiento por un procesador. También, en algunas modalidades, múltiples invenciones de software pueden implementarse como subpartes de un programa más grande en tanto que permanecen distintas invenciones de software. En algunas modalidades, múltiples invenciones de software también pueden implementarse como programas separados. Finalmente, cualquier combinación de programas separados que en conjunto implementan una invención de software descrita aquí se encuentra dentro del alcance de la invención. En algunas modalidades, los programas de software, cuando se instalan para operar en uno o más sistemas electrónicos, definen una o más implementaciones de máquina específicas que ejecutan y realizan las operaciones de los programas de software.
La Figura 27 ilustra conceptualmente un sistema electrónico 2700 con el cual se implementan algunas modalidades de la invención. El sistema electrónico 2700 puede ser una computadora (por ejemplo, una computadora de escritorio, computadora personal, computadora tipo tableta, etc.), teléfono, PDA, o cualquier otra clase de dispositivo electrónico. Tal sistema electrónico incluye diversos tipos de medios legibles por computadora e interfaces para varios otros tipos de medios legibles por computadora. El sistema electrónico 2700 incluye un bus 2705, unidad o unidades de procesamiento 2710, una unidad de procesamiento de gráficos (GPU) 2715, una memoria de sistema 2720, una red 2725, una memoria de sólo lectura 2730, un dispositivo de almacenamiento permanente 2735, dispositivos de entrada de datos 2740, y dispositivos de salida de datos 2745.
El bus 2705 representa colectivamente todos los buses de sistema, periféricos, y circuito auxiliar integrado que conectan en forma comunicativa los numerosos dispositivos internos del sistema electrónico 2700. Por ejemplo, el bus 2705 conecta en forma comunicativa la o las unidades de procesamiento 2710 con la memoria de sólo lectura 2730, la GPU 2735, la memoria de sistema 2720, y el dispositivo de almacenamiento permanente 2735.
A partir de estas diversas unidades de memoria, la o las unidades de procesamiento 2710 recuperan instrucciones a ejecutar y datos a procesar con el fin de ejecutar los procesos de la invención. La o las unidades de procesamiento pueden ser un solo procesador o un procesador de núcleos múltiples en diferentes modalidades. Algunas instrucciones se hacen pasar a y se ejecutan por la GPU 2715. La GPU 2715 puede redirigir diversos cálculos o complementar el procesamiento de imágenes proporcionado por la o las unidades de procesamiento 2710. En algunas modalidades, tal funcionalidad puede proporcionarse al utilizar el lenguaje de sombreado de núcleo de Corelmage.
La memoria de sólo lectura (ROM) 2730 almacena datos estáticos e instrucciones que se necesitan por la o las unidades de procesamiento 2710 y otros módulos del sistema electrónico. El dispositivo de almacenamiento permanente 2735, por otro lado, es un dispositivo de memoria de lectura y escritura. Este dispositivo es una unidad de memoria no volátil que almacena instrucciones y datos aún cuando el sistema electrónico 2700 está apagado. Algunas modalidades de la invención usan un dispositivo de almacenamiento en masa (tal como un disco magnético u óptico y su unidad de disco correspondiente) como el dispositivo de almacenamiento permanente 2735.
Otras modalidades usan un dispositivo de almacenamiento desmontable (tal como un disco flexible, dispositivo de memoria de destello, etc., y su unidad de disco correspondiente) como el dispositivo de almacenamiento permanente. Como el dispositivo de almacenamiento permanente 2735, la memoria de sistema 2720 es un dispositivo de memoria de lectura y escritura. Sin embargo, a diferencia del dispositivo de almacenamiento 2735, la memoria de sistema 2720 es una memoria de lectura y escritura volátil, tal como una memoria de acceso aleatorio. La memoria de sistema 2720 almacena algunas de las instrucciones y datos que el procesador necesita en tiempo de ejecución. En algunas modalidades, los procesos de la invención se almacenan en la memoria de sistema 2720, el dispositivo de almacenamiento permanente 2735, y/o la memoria de sólo lectura 2730. Por ejemplo, las diversas unidades de memoria incluyen instrucciones para procesar clips multimedia, de acuerdo con algunas modalidades. A partir de estas diversas unidades de memoria, la o las unidades de procesamiento 2710 recuperan instrucciones a ejecutar y datos a procesar con el fin de ejecutar los procesos de algunas modalidades.
El bus 2705 también se conecta a los dispositivos de entrada de datos y de salida de datos 2740 y 2745. Los dispositivos de entrada de datos 2740 habilitan al usuario para comunicar información y seleccionar comandos al sistema electrónico. Los dispositivos de entrada de datos 2740 incluyen teclados alfanuméricos y dispositivos apuntadores (también denominados "dispositivos de control de cursor"), cámaras (por ejemplo, cámaras en red), micrófonos o dispositivos similares para recibir comandos por voz, etc. Los dispositivos de salida de datos 2745 muestran imágenes generadas por el sistema electrónico o, de otra manera, datos de salida. Los dispositivos de salida de datos 2745 incluyen impresoras y dispositivos de visualización, tales como tubos de rayos catódicos (CRT) o pantallas de cristal líquido (LCD), así como altavoces o dispositivos de salida de audio similares. Algunas modalidades incluyen dispositivos tales como una pantalla táctil que funcionan como dispositivos de entrada de datos y de salida de datos.
Finalmente, como se muestra en la Figura 27, el bus 2705 también acopla el sistema electrónico 2700 a una red 2725 a través de un adaptador de red (no mostrado). En esta forma, la computadora puede ser parte de una red de computadoras (tal como una red de área local ("LAN"), una red de área amplia ("WAN"), una intranet, o una red de redes, tal como la Internet). Cualquiera o todos los componentes del sistema electrónico 2700 pueden utilizarse en conjunto con la invención.
Algunas modalidades incluyen componentes electrónicos, tales como microprocesadores, almacenamiento y memoria que almacenan instrucciones de programa de computadora en un medio legible por máquina o legible por computadora, (alternativamente referidos como medios de almacenamiento legible por computadora, medios legibles por máquina, o medios de almacenamiento legibles por máquina). Algunos ejemplos de tales medios legibles por computadora incluyen RAM, ROM, discos compactos de sólo lectura (CD-ROM), discos compactos grabables (CD-R), discos compactos regrabables (CD-RW), discos versátiles digitales de sólo lectura (por ejemplo, DVD-ROM, DVD-ROM de doble capa), una diversidad de DVD grabables/regrabables (por ejemplo, DVD-RAM, DVD-RW, DVD+RW, etc.), memoria de destello (por ejemplo, tarjetas SD , tarjetas mini SD, tarjetas micro SD, etc.), discos duros magnéticos y/o en estado sólido, discos de sólo lectura y Blu-Ray® grabables, discos ópticos de ultra densidad, cualquier otro medio óptico o magnético, y discos flexibles. Los medios legibles por computadora pueden almacenar un programa de computación que es ejecutable por al menos una unidad de procesamiento e incluye conjuntos de instrucciones para realizar diversas operaciones. Ejemplos de programas de computación o código de computación incluyen código de máquina, tal como el producido por un compilador, y archivos que incluyen código de nivel superior que se ejecutan por una computadora, un componente electrónico, o un microprocesador al utilizar un intérprete.
Aunque la discusión anterior se refiere principalmente a un microprocesador o procesadores de núcleos múltiples que ejecutan software, algunas modalidades se realizan por uno o más circuitos integrados, tales como circuitos integrados específicos de aplicaciones (ASIC) o matrices de puertas programables en campo (FPGA). En algunas modalidades, tales circuitos integrados ejecutan instrucciones que se almacenan en el circuito en sí. Además, algunas modalidades ejecutan software almacenado en dispositivos lógicos programables (PLD), ROM, o dispositivos RAM.
Como se utiliza en esta especificación y cualquier reivindicación de esta solicitud, los términos "computadora", "servidor", "procesador", y "memoria" se refieren a dispositivos electrónicos u otros tecnológicos. Estos términos excluyen personas o grupos de personas. Para los propósitos de la especificación, los términos "muestran" o "que muestra" significan mostrar en un dispositivo electrónico. Como se utiliza en esta especificación y cualquier reivindicación de esta solicitud, los términos "medio legible por computadora", "medios legibles por computadora" y "medio legible por máquina" se restringen completamente a objetos físicos tangibles que almacenan información en una forma que es legible por una computadora. Estos términos, excluyen cualquier señal inalámbrica, señal descargada por cable, y cualquier otra señal efímera.
En tanto que la invención se ha descrito con referencia a numerosos detalles específicos, un experto en la técnica reconocerá que la invención puede representarse en otras formas específicas sin apartarse del espíritu de la invención. Además, por lo menos algunas de las figuras (incluyendo las Figuras 2, 3, 13, 17, 18 y 26) ilustran procesos conceptualmente. Las operaciones específicas de estos procesos pueden no realizarse en el orden exacto mostrado y descrito. Las operaciones específicas pueden no realizarse en una serie continua de operaciones, y diferentes operaciones específicas pueden realizarse en diferentes modalidades. Adicionalmente, el proceso puede implementarse al utilizar varios subprocesos, o como parte de un macroproceso más grande. De esta manera, un experto en la técnica puede comprender que la invención no debe limitarse a los detalles ilustrativos precedentes, sino que debe definirse por las reivindicaciones adjuntas.

Claims (20)

REIVINDICACIONES
1. Un dispositivo electrónico que comprende: un conjunto de unidades de procesamiento; y un medio legible por máquina que almacena un sistema operativo que comprende: un solicitante de operaciones para recibir un comando para abrir un documento y una aplicación asociada con el documento; un iniciador de operaciones para solicitar la valoración de seguridad con base en el comando recibido, en donde la solicitud comprende un conjunto de objetos digitales que se asocian con el documento y una pluralidad de diferentes operaciones que se asocian con la aplicación; y un evaluador de seguridad para valorar si el conjunto de objetos de datos cumple con las directrices de seguridad asociadas con el documento y la pluralidad de diferentes operaciones.
2. El dispositivo electrónico de conformidad con la reivindicación 1 , en donde el conjunto de objetos digitales comprende un primer subconjunto de objetos digitales asociados con el documento y un segundo subconjunto de objetos digitales asociados con la pluralidad de diferentes operaciones.
3. El dispositivo electrónico de conformidad con la reivindicación 2, en donde, cuando el primer y segundo subconjuntos se encuentran en cumplimiento con las directrices de seguridad, el iniciador de operaciones inicia la apertura del documento y lanza la aplicación.
4. El dispositivo electrónico de conformidad con la reivindicación 1 , en donde el evaluador de seguridad es parte de un marco de seguridad para realizar las valoraciones de seguridad solicitadas al utilizar una interfaz de programación de aplicaciones (API).
5. El dispositivo electrónico de conformidad con la reivindicación 1 , en donde la pluralidad de operaciones comprende instalar la aplicación en una computadora, la cual se está ejecutando en el sistema operativo.
6. El dispositivo electrónico de conformidad con la reivindicación 1 , en donde el evaluador de seguridad valora una directriz de seguridad para una operación particular al examinar un requerimiento de código que especifica un conjunto de características que se requieren de un subconjunto de objetos digitales asociados con la operación particular.
7. El dispositivo electrónico de conformidad con la reivindicación 6, en donde el sistema operativo además comprende una base de datos que almacena una pluralidad de conjuntos de instrucciones asociadas con las directrices de seguridad, en donde el evaluador de seguridad determina la directriz de seguridad asociada con una operación particular al recuperar un conjunto de instrucciones que coincide con la operación particular de la base de datos.
8. El dispositivo electrónico de conformidad con la reivindicación 7, en donde la base de datos comprende una tabla de autoridades y una tabla caché, en donde la recuperación del conjunto de instrucciones que coincide con la operación particular de la base de datos comprende buscar una entrada coincidente en la tabla caché antes de buscar una entrada coincidente en la tabla de autoridades.
9. Un medio no transitorio legible por máquina que almacena un programa que, cuando se ejecuta por al menos una unidad de procesamiento de un dispositivo, proporciona una valoración de seguridad en un sistema operativo, el programa comprende conjuntos de instrucciones para: recibir un comando para abrir un documento asociado con una aplicación que se ejecuta en el dispositivo; solicitar un marco de seguridad para realizar una valoración de seguridad (i) en el documento y la aplicación cuando el marco de seguridad previamente no ha realizado una valoración de seguridad de la aplicación, o (ii) en el documento cuando el marco de seguridad previamente realizó una valoración de seguridad de la aplicación; determinar abrir el documento con base en la valoración de seguridad.
10. El medio no transitorio legible por máquina de conformidad con la reivindicación 9, en donde la valoración de seguridad se basa en un requerimiento de código que especifica un conjunto de características que se requieren de un objeto digital asociado con el documento.
11. El medio no transitorio legible por máquina de conformidad con la reivindicación 9, en donde el programa además comprende un conjunto de instrucciones para mantener una base de datos que almacena una pluralidad de conjuntos de instrucciones para realizar las valoraciones de seguridad, en donde el evaluador de seguridad determina una directriz de seguridad asociada con el documento al recuperar un conjunto de instrucciones que coincide con el documento de la base de datos.
12. El medio no transitorio legible por máquina de conformidad con la reivindicación 11 , en donde la base de datos comprende una tabla de autoridades y una tabla caché, en donde la recuperación del conjunto de instrucciones que coincide con el documento de la base de datos comprende buscar una entrada coincidente en la tabla caché antes de buscar una entrada coincidente en la tabla de autoridades.
13. El medio no transitorio legible por máquina de conformidad con la reivindicación 9, en donde la valoración de seguridad del documento comprende determinar si el documento provino de una fuente confiable.
14. Un método para valorar la seguridad de las operaciones realizadas por un sistema operativo, el método comprende: recibir un comando para abrir un documento en una aplicación que se ejecuta dentro de un sistema operativo; solicitar una valoración de seguridad del documento al utilizar una interfaz de programación de aplicaciones (API) para acceder a un marco de seguridad; solicitar una valoración de seguridad adicional para la aplicación cuando la aplicación no se ha valorado previamente; y determinar si se realiza una operación particular con base en las valoraciones de seguridad solicitadas.
15. El método de conformidad con la reivindicación 14, en donde la solicitud de la valoración de seguridad de la aplicación es antes de la solicitud de la valoración de seguridad de la aplicación.
16. El método de conformidad con la reivindicación 14, en donde la operación particular comprende abrir el documento asociado con la aplicación en ejecución en el sistema operativo.
17. El método de conformidad con la reivindicación 14, en donde determinar si se realiza la operación particular comprende determinar si el documento provino de una fuente confiable.
18. El método de conformidad con la reivindicación 14, en donde la valoración de seguridad comprende valorar directrices de seguridad para el documento al examinar un requerimiento de código que especifica un conjunto de características que se requieren de un objeto digital asociado con el documento.
19. El método de conformidad con la reivindicación 18, en donde el requerimiento de código se almacena en una base de datos que almacena una pluralidad de conjuntos de instrucciones asociadas con las directrices de seguridad, en donde la base de datos comprende una tabla de autoridades y una tabla caché, en donde recuperar el conjunto de instrucciones que coincide con el documento de la base de datos comprende buscar una entrada coincidente en la tabla caché antes de buscar una entrada coincidente en la tabla de autoridades.
20. El método de conformidad con la reivindicación 14, que además comprende determinar una directriz de seguridad asociada con el documento al recuperar un conjunto de instrucciones que coincide con el documento a partir de una base de datos.
MX2014009046A 2012-02-03 2012-12-28 Administracion operativa centralizada. MX353868B (es)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201261595021P 2012-02-03 2012-02-03
US13/624,836 US9137261B2 (en) 2012-02-03 2012-09-21 Centralized operation management
US13/624,832 US8966574B2 (en) 2012-02-03 2012-09-21 Centralized operation management
US13/624,828 US8978094B2 (en) 2012-02-03 2012-09-21 Centralized operation management
PCT/US2012/072191 WO2013115927A1 (en) 2012-02-03 2012-12-28 Centralized operation management

Publications (2)

Publication Number Publication Date
MX2014009046A true MX2014009046A (es) 2014-10-24
MX353868B MX353868B (es) 2018-02-01

Family

ID=48904078

Family Applications (1)

Application Number Title Priority Date Filing Date
MX2014009046A MX353868B (es) 2012-02-03 2012-12-28 Administracion operativa centralizada.

Country Status (9)

Country Link
US (4) US8978094B2 (es)
EP (1) EP2810210A1 (es)
JP (1) JP5961708B2 (es)
KR (3) KR101677576B1 (es)
CN (1) CN104137114B (es)
AU (1) AU2012368190B2 (es)
BR (1) BR112014018837B1 (es)
MX (1) MX353868B (es)
WO (1) WO2013115927A1 (es)

Families Citing this family (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8695060B2 (en) 2011-10-10 2014-04-08 Openpeak Inc. System and method for creating secure applications
US8978094B2 (en) 2012-02-03 2015-03-10 Apple Inc. Centralized operation management
US9455879B1 (en) * 2013-03-04 2016-09-27 Amazon Technologies, Inc. Validating changes to attributes for computing resources
US9754392B2 (en) 2013-03-04 2017-09-05 Microsoft Technology Licensing, Llc Generating data-mapped visualization of data
US9137237B2 (en) 2013-09-03 2015-09-15 Microsoft Technology Licensing, Llc Automatically generating certification documents
US9253212B2 (en) * 2013-09-24 2016-02-02 Microsoft Technology Licensing, Llc Automated production of certification controls by translating framework controls
US9361432B2 (en) * 2014-01-15 2016-06-07 Hewlett-Packard Development Company, L.P. Configuring a security setting for a set of devices using a security policy
US9158909B2 (en) * 2014-03-04 2015-10-13 Amazon Technologies, Inc. Authentication of virtual machine images using digital certificates
US10789300B2 (en) * 2014-04-28 2020-09-29 Red Hat, Inc. Method and system for providing security in a data federation system
US10061808B2 (en) * 2014-06-03 2018-08-28 Sap Se Cached views
US9350818B2 (en) 2014-09-05 2016-05-24 Openpeak Inc. Method and system for enabling data usage accounting for unreliable transport communication
US9100390B1 (en) 2014-09-05 2015-08-04 Openpeak Inc. Method and system for enrolling and authenticating computing devices for data usage accounting
US8938547B1 (en) 2014-09-05 2015-01-20 Openpeak Inc. Method and system for data usage accounting in a computing device
US20160071040A1 (en) 2014-09-05 2016-03-10 Openpeak Inc. Method and system for enabling data usage accounting through a relay
US9232013B1 (en) 2014-09-05 2016-01-05 Openpeak Inc. Method and system for enabling data usage accounting
US10445505B2 (en) * 2014-09-22 2019-10-15 Mcafee, Llc Process vulnerability assessment
US9881159B1 (en) * 2014-11-14 2018-01-30 Quest Software Inc. Workload execution systems and methods
GB2534556B (en) * 2015-01-21 2019-12-25 F Secure Corp Preventing misuse of code signing certificates
CN104680061A (zh) * 2015-02-28 2015-06-03 国鼎网络空间安全技术有限公司 一种Android环境下应用程序启动中代码签名验证的方法和系统
US9232078B1 (en) 2015-03-16 2016-01-05 Openpeak Inc. Method and system for data usage accounting across multiple communication networks
CN106407830B (zh) * 2015-07-29 2020-01-21 阿里巴巴集团控股有限公司 一种基于云的数据库的检测方法和装置
US10402584B1 (en) * 2015-10-01 2019-09-03 Hrl Laboratories, Llc System and method for translating security objectives of computer software to properties of software code
EP3200037A1 (en) * 2016-01-26 2017-08-02 Basf Se System and method for risk based control of a process performed by production equipment
CN107766453A (zh) * 2017-09-26 2018-03-06 上海策赢网络科技有限公司 基于区块链的数据库管理方法、装置及存储介质
EP3847643A4 (en) 2018-09-06 2022-04-20 Coffing, Daniel L. DIALOG GUIDANCE PROVIDING SYSTEM
WO2020056409A1 (en) * 2018-09-14 2020-03-19 Coffing Daniel L Fact management system
US11139985B2 (en) * 2018-12-04 2021-10-05 Journey.ai Receiving information through a zero-knowledge data management network
KR102089688B1 (ko) * 2019-04-12 2020-04-24 주식회사 이글루시큐리티 준지도학습을 통한 인공지능 기반 보안이벤트 분석시스템 및 그 방법
US11165777B2 (en) 2019-05-30 2021-11-02 Bank Of America Corporation Controlling access to secure information resources using rotational datasets and dynamically configurable data containers
US11138328B2 (en) 2019-05-30 2021-10-05 Bank Of America Corporation Controlling access to secure information resources using rotational datasets and dynamically configurable data containers
US11153315B2 (en) * 2019-05-30 2021-10-19 Bank Of America Corporation Controlling access to secure information resources using rotational datasets and dynamically configurable data containers
US11838429B2 (en) * 2019-07-18 2023-12-05 Itron, Inc. Certificate chain compression to extend node operational lifetime
WO2024044005A1 (en) * 2022-08-22 2024-02-29 Microsoft Technology Licensing, Llc Remote management over security layer

Family Cites Families (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA1270339A (en) 1985-06-24 1990-06-12 Katsuya Nakagawa System for determining a truth of software in an information processing apparatus
JPH08137686A (ja) * 1994-09-16 1996-05-31 Toshiba Corp 著作物データ管理方法及び著作物データ管理装置
CN1183841A (zh) 1995-02-13 1998-06-03 英特特拉斯特技术公司 用于安全交易管理和电子权利保护的系统和方法
US8079086B1 (en) 1997-11-06 2011-12-13 Finjan, Inc. Malicious mobile code runtime monitoring system and methods
KR101041515B1 (ko) 1999-05-19 2011-06-16 디지맥 코포레이션 컴퓨터들을 제어하거나 물리적 및 전자적 객체들로부터 인터넷 리소스들에 링크하기 위한 방법들 및 시스템들
AU4851300A (en) 1999-05-19 2000-12-05 Digimarc Corporation Methods and systems for controlling computers or linking to internet resources from physical and electronic objects
WO2001025925A1 (en) 1999-10-01 2001-04-12 Infraworks Corporation Port blocking method and system
US7185192B1 (en) 2000-07-07 2007-02-27 Emc Corporation Methods and apparatus for controlling access to a resource
JP2004213181A (ja) * 2002-12-27 2004-07-29 Ricoh Co Ltd カプセル化文書構造、記憶媒体、情報処理装置、カプセル化文書作成編集装置及び起動プログラム
US20040194027A1 (en) 2002-12-27 2004-09-30 Akira Suzuki Computerized electronic document producing, editing and accessing system for maintaining high-security
US20040255167A1 (en) * 2003-04-28 2004-12-16 Knight James Michael Method and system for remote network security management
KR100968003B1 (ko) * 2003-05-17 2010-07-07 마이크로소프트 코포레이션 보안 위험을 평가하는 메카니즘
US8607299B2 (en) * 2004-04-27 2013-12-10 Microsoft Corporation Method and system for enforcing a security policy via a security virtual machine
US7657925B2 (en) 2004-10-14 2010-02-02 Oracle International Corporation Method and system for managing security policies for databases in a distributed system
US7698744B2 (en) * 2004-12-03 2010-04-13 Whitecell Software Inc. Secure system for allowing the execution of authorized computer program code
US7624111B2 (en) * 2005-06-27 2009-11-24 Microsoft Corporation Active content trust model
US20070083930A1 (en) * 2005-10-11 2007-04-12 Jim Dumont Method, telecommunications node, and computer data signal message for optimizing virus scanning
US7805752B2 (en) 2005-11-09 2010-09-28 Symantec Corporation Dynamic endpoint compliance policy configuration
JP4745858B2 (ja) 2006-02-20 2011-08-10 富士通株式会社 セキュリティ管理プログラム、およびセキュリティ管理方法
EP1998269A4 (en) 2006-02-21 2012-02-29 Nec Corp PROGRAM EXECUTION MONITORING SYSTEM, EXECUTION MONITORING METHOD, COMPUTER CONTROL PROGRAM
US8272048B2 (en) 2006-08-04 2012-09-18 Apple Inc. Restriction of program process capabilities
US8375458B2 (en) 2007-01-05 2013-02-12 Apple Inc. System and method for authenticating code executing on computer system
KR100884200B1 (ko) * 2007-06-29 2009-02-18 이화여자대학교 산학협력단 태그의 의미 식별자에 기초하여 콘텐츠를 관리하는 콘텐츠관리 시스템 및 방법
CN101414327B (zh) * 2007-10-15 2012-09-12 北京瑞星信息技术有限公司 文件保护的方法
JP4645644B2 (ja) 2007-12-25 2011-03-09 富士ゼロックス株式会社 セキュリティポリシー管理装置、セキュリティポリシー管理システム及びセキュリティポリシー管理プログラム
WO2009111408A1 (en) 2008-03-04 2009-09-11 Apple Inc. System and method of authorizing execution of software code based on at least one installed profile
KR101018435B1 (ko) 2008-08-14 2011-02-28 한국전자통신연구원 사용자 단말기의 보안 관리 장치 및 방법
CN101350034B (zh) * 2008-09-10 2012-05-23 普天信息技术研究院有限公司 一种移动存储设备及文件访问的方法
US8272028B2 (en) 2008-10-15 2012-09-18 Ricoh Company, Ltd. Approach for managing access to electronic documents on network devices using document retention policies and document security policies
JP5434322B2 (ja) 2009-07-10 2014-03-05 富士ゼロックス株式会社 処理決定装置、画像処理装置、処理決定システム、及びプログラム
JP5460215B2 (ja) 2009-09-29 2014-04-02 キヤノン株式会社 情報処理装置及びその方法
CN101853363B (zh) * 2010-05-07 2012-08-08 飞天诚信科技股份有限公司 一种文件保护方法及系统
US9465935B2 (en) 2010-06-11 2016-10-11 D2L Corporation Systems, methods, and apparatus for securing user documents
US8978094B2 (en) 2012-02-03 2015-03-10 Apple Inc. Centralized operation management

Also Published As

Publication number Publication date
AU2012368190B2 (en) 2015-10-22
US20130205363A1 (en) 2013-08-08
MX353868B (es) 2018-02-01
KR20170137216A (ko) 2017-12-12
KR20140114060A (ko) 2014-09-25
BR112014018837A8 (pt) 2017-07-11
KR101677576B1 (ko) 2016-11-18
BR112014018837A2 (es) 2017-06-20
US20160142441A1 (en) 2016-05-19
US10122759B2 (en) 2018-11-06
EP2810210A1 (en) 2014-12-10
US20130205362A1 (en) 2013-08-08
WO2013115927A1 (en) 2013-08-08
AU2012368190A1 (en) 2014-08-21
CN104137114A (zh) 2014-11-05
US8966574B2 (en) 2015-02-24
JP2015509252A (ja) 2015-03-26
US9137261B2 (en) 2015-09-15
JP5961708B2 (ja) 2016-08-02
US20130205364A1 (en) 2013-08-08
KR101804996B1 (ko) 2017-12-06
CN104137114B (zh) 2017-03-08
US8978094B2 (en) 2015-03-10
KR20160134867A (ko) 2016-11-23
BR112014018837B1 (pt) 2021-10-05
KR101941398B1 (ko) 2019-01-22

Similar Documents

Publication Publication Date Title
US10122759B2 (en) Centralized operation management
US7788730B2 (en) Secure bytecode instrumentation facility
EP3552098B1 (en) Operating system update management for enrolled devices
CN105354493B (zh) 基于虚拟化技术的终端可信增强方法及系统
CN105760787B (zh) 用于检测随机存取存储器中的恶意代码的系统及方法
US11706220B2 (en) Securing application behavior in serverless computing
EP3583536B1 (en) Securely defining operating system composition without multiple authoring
EP4283498A2 (en) Virtual environment type validation for policy enforcement
EP4182823A1 (en) Threat analysis and risk assessment for cyber-physical systems based on physical architecture and asset-centric threat modeling
CN110070360B (zh) 一种事务请求处理方法、装置、设备及存储介质
EP3631669B1 (en) Expression evaluation of database statements for restricted data
JP7445017B2 (ja) ユーザ識別子および署名収集を利用したモバイルアプリケーション偽造・変造探知方法、コンピュータプログラム、コンピュータ読み取り可能な記録媒体およびコンピュータ装置
Huh et al. Managing application whitelists in trusted distributed systems
Reichert et al. An Integrity-Focused Threat Model for Software Development Pipelines
Smith et al. Exe-Guard Project

Legal Events

Date Code Title Description
FG Grant or registration