HK1242437A1 - Environment-aware security tokens - Google Patents

Description

Context aware security token

Cross Reference to Related Applications

This application claims priority to U.S. patent application serial No. 14/456,777, filed on 8/11/2014, which is incorporated herein by reference in its entirety.

Technical Field

The present disclosure relates to security of networked devices and files.

Background

A security architecture, such as a shared secret architecture or a public key cryptography architecture, may be used to generate a security token for authorizing use of a computer service.

Disclosure of Invention

In one aspect, the techniques described in this document may be embodied in a computer-implemented method that includes receiving, at a processing device, information about one or more assets associated with a network of devices. The method also includes generating, for at least one asset, a security token based at least on a portion of the received information about the respective asset. The security token may be configured to identify a home network defined for the asset and restrict access to the corresponding asset upon detecting an occurrence of an unauthorized activity involving the asset. The method also includes storing information about the security token and information linking the security token to the corresponding asset in a storage device, and initiating integration of the security token with the corresponding asset.

In another aspect, the techniques described in this document may be embodied in a computing device that includes memory and one or more processors. The one or more processors may be configured to receive information about one or more assets associated with a network of devices. The processor may be further configured to generate, for at least one of the assets, a security token based at least on a portion of the received information about the respective asset. The security token may be configured to identify a home network defined for the asset and also to restrict access to the corresponding asset upon detecting an occurrence of an unauthorized activity involving the asset. The processor may be further configured to store information about the security token and information linking the security token to the respective asset in the storage device and initiate integration of the security token with the respective asset.

In another aspect, the techniques described in this document may be embodied in one or more machine-readable storage devices that store instructions executable by one or more processing devices. The instructions, when executed, may cause one or more processing devices to perform operations comprising receiving information about one or more assets associated with a network of devices. The operations further include generating, for at least one of the assets, a security token based at least on a portion of the received information about the respective asset. The security token may be configured to identify a home network defined for the asset and restrict access to the corresponding asset upon detecting an occurrence of an unauthorized activity involving the asset. The operations further include storing information about the security token and information linking the security token to the corresponding asset in a storage device, and initiating integration of the security token with the corresponding asset.

Implementations of the above embodiments may include one or more of the following features.

Detecting the occurrence of the unauthorized activity may include determining a detachment of the asset from a home network defined for the asset. The assets associated with the network may include one or more of the following: a device connected to a network, a file stored on a storage device connected to the network, and a user profile associated with the network. The asset may be an electronic file, and initiating integration of the security token into the asset may include initiating encryption of the asset based on the security token. A home network for an asset may be defined based on one or more security policies associated with the asset. The information may include one or more of the following: a serial number of the device, a Media Access Control (MAC) address, a file path, a registry key, a network identifier, an Internet Protocol (IP) address, a file type identifier, a user profile identifier, and one or more policies associated with the network.

Information about one or more assets may be received from an agent deployed on a network. The agent may be configured to scan devices of the network for information. The agent may include an automated browser. The security token may comprise an object generated according to a Component Object Model (COM). The security tokens may be generated according to one or more security policies associated with the respective assets. Determining the detachment of the respective asset from the home network may include determining that the respective asset is not connected to the home network. Determining the separation of the respective asset from the home network may include determining that the respective asset is not stored on a device associated with the home network. Determining the separation of the respective asset from the home network may include detecting an access attempt from a user profile not associated with the home network. The corresponding asset may be an electronic file, and the security token may be configured to restrict access to the electronic file by deleting content of the electronic file when determined to be detached from the home network. Information about the security token and information linking the security token to the corresponding identifier may be stored in a database. The corresponding asset may be an electronic file, and initiating integration of the security token into the electronic file may include initiating code injection into a header portion of the electronic file. The respective asset may be an electronic file, and initiating integration of the security token with the electronic file may include initiating encapsulation of the security token with the electronic file. The executable file may be generated by encapsulation. The corresponding asset may be an electronic document and the security token may be integrated into the document as part of a page description language of the document. Information relating to an access point attempting to access the asset may be received from the asset, possibly based on information collected by the security token. Whether the access point is associated with the security token may be determined based on the stored information about the security token. Permission information indicating a level of access allowed for the access point may be provided based on the determination.

In some implementations, the techniques described in this document may provide one or more of the following advantages. Network assets such as one or more devices, user profiles, and document files may be locked within an authorized network through the use of environment-aware security tokens (environment-aware security tokens) that include an identification of the authorized network (often referred to as a home network). Thus, the security of data and other network assets can be increased many times. For example, even if files are fraudulently copied and stored (e.g., via a security breach) on unauthorized devices (i.e., devices that are not authenticated to an authorized network), the context-aware security token associated with such files can detect such separation from the home network and prevent unauthorized access to such files. Thus, the effectiveness of malicious security breaches can be mitigated by reducing the usefulness of stolen data. In some implementations, physical devices such as printers, laptops, phones, mobile devices, etc. can also be associated with the context aware security token so that the device is functional only when connected to an authorized network. The context aware security tokens may be configured to be user defined, extensible, and adaptive to provide a greater degree of control over the accessibility of the respective assets. For example, a context-aware security token associated with a particular document may be configured such that the particular document is only visible on a predetermined set of computing devices within an authorized network.

Other features and advantages will be apparent from the following detailed description, and from the claims.

Drawings

Fig. 1 is an example of a system using context aware security tokens.

2A-2B illustrate examples of user interfaces.

Fig. 3 is a flow diagram depicting an example sequence of operations associated with generating a security token.

Fig. 4 is a diagram illustrating an example of a computing device.

Detailed Description

Security tokens are often used to give an authorized user access to a secure asset, such as a computing device or a file stored within a computing device. Such security tokens may allow, for example, secure single sign-on (also referred to as S3) capabilities in systems that provide access to various resources. The security token may include, for example, a two-factor authentication security mechanism that authorizes access to assets associated with the network. The security token may be stored on a general purpose computing device, such as a desktop computer, laptop computer, or handheld wireless device (e.g., a mobile phone, e-reader, or tablet), and used to access various assets (e.g., files or documents) using the computing device.

Some security tokens (e.g., provided by shared secret or public key cryptographic architectures) may be vulnerable to threats based on replication of underlying cryptographic material. For example, a malicious entity (e.g., a human user such as a hacker or a software entity such as a computer virus or other malware) may breach the security of the network to steal data in the form of documents or other files. In such a case, the stolen file may be stored on a storage device that is conveniently accessible by the malicious entity, and the contents of the file may be used for illegal or harmful activities. This may occur, for example, when a malicious entity attacks a financial institution, such as a credit card company, and is able to copy files that include sensitive user information (such as a username and password pair). Such sensitive information may also be obtained directly from the user, for example by a phishing attack. The sensitive information may then be provided to a token generation mechanism (e.g., a secure website) to obtain the secure token needed to access, for example, a user account.

In a shared private architecture, a profile is typically generated for each end user. The generated profile may include, for example, a username, a personal identification number, and a configurable "secret" (e.g., an answer to a question posed by the user) associated with the particular user. The security provided by the shared secret architecture depends to a large extent on the configuration file. Thus, in the event that a configuration file is stolen or copied, the security provided by the shared private architecture may be compromised.

Architectures such as public key cryptography or asymmetric cryptography provide some advantages over shared secret type architectures by requiring that one of the two separate keys be secret (or private) and the other public. The two keys are mathematically linked and can be used in combination to provide security. For example, the public key may be used to encrypt or verify the digital signature, and the private key may be used to decrypt or create the digital signature. However, if both keys are stolen or copied, the security provided by an architecture such as public key cryptography may also be compromised.

The techniques described in this document improve the security of network assets (documents, files, devices, etc.) by generating context-aware security tokens that are specific to the respective assets. This technique may be used independently and in conjunction with other security techniques, such as provided via third-party software applications or social networking services. For example, a context-aware security token for a document may be generated from context metrics associated with a network in which the document is authorized to reside. Examples of environmental metrics may also include various parameters associated with the asset, such as asset name, asset ID (GUID or UUID), asset class (e.g., the asset is a device, document, user profile, system data, or security policy data, etc.), security token key, security object, and so forth. Examples of parameters associated with a device include an assigned address (e.g., a MAC address), a serial number, a device name, a device ID, and a security object status (e.g., whether a security object is attached or embedded, whether a security object is an empty object, etc.). Examples of parameters associated with a user include a username, a user ID, and a user profile data structure (e.g., a data structure representing data about various user metrics). Examples of parameters associated with a document include a document name, a document ID, and a document profile data structure (e.g., a data structure representing data about a document metric). Examples of parameters associated with the system and security policy data include a system name, a system ID, a security policy name, a security policy ID, and a data structure representing a security policy.

The generated context-aware security token may be configured to include an identification of a particular network, and may then be associated with the document to "lock" the document to the particular network (commonly referred to as a home network). The lock may be such that the document cannot be accessed from any unauthorized device (e.g., a device that is not authenticated to a particular network). For example, the context aware security token may be embedded, attached, packaged, or otherwise associated with the document in such a way that if the document is moved or copied to or attempted to be accessed from a device that is not authenticated to the home network, the context aware security token deletes, digitally damages, or otherwise prevents access to the contents of the document. In some embodiments, the techniques described in this document may be deployed in conjunction with other security architectures, such as the shared secret architecture or public key cryptography architecture described above.

The techniques described in this document may be used to control physical or virtual access to physical or virtual storage locations. In some implementations, file system and document attributes can be used to generate a context-aware security token that provides access to a storage location and/or encrypted file content. Various restrictions may be imposed on the context-aware based security token. In some implementations, the context aware security token can be used to restrict user(s) or device(s) from accessing the asset. In some implementations, the context aware security token can be used to restrict documents from being copied from an original storage location. Further, the file attributes may be configured such that the corresponding context aware security token may be used to prevent unauthorized copying and/or downloading. For example, file attributes may be controlled by an attached or embedded security token (e.g., an embedded security object) that is authenticated by a token server with or without a hardware dongle.

In some implementations, the techniques may be implemented as part of an Operating System (OS). For example, the security layer provided by the present technology may be used to gain control of the file system of the respective OS to control operations such as read, write, and copy. The security layer may be used to control and authenticate various assets, for example, by attaching, encapsulating, or embedding security objects. In some implementations, such as where the security objects are encapsulated with corresponding files or documents into a separate entity (e.g., an application or executable file), the entity may be configured to corrupt, delete, or otherwise digitally shred the content in the file or document upon detecting separation from the home network. For example, a detachment may be detected when an entity fails to establish a connection with a token server that controls management of the security object. In some implementations, the entity may also be configured to collect information about one or more metrics associated with the environment in which the access attempt is being made. For example, in the case of a security breach (e.g., hacker), the entity may be configured to send back details of the environment (e.g., MAC address, IP address, device serial number, etc.) to the token server.

The separation from the home network may include various situations. In some embodiments, the separation may include a loss of physical connection to the home network. A home network may be defined or configured by selecting a set of assets (devices, user profiles, storage locations, files, documents, operating systems, etc.) that are authenticated as being associated with a particular asset, such as a device or document. In some implementations, the separation from the home network may include access attempts from assets or entities not included within the home network as configured for the asset for which the access attempt is being made. In one example, the separation may include an access attempt from a user profile associated with the home network that is not configured for the respective asset. In another example, the separating may include storing (or accessing) the particular asset at a storage location outside of the home network configured for the particular asset. In yet another example, the separation may include disconnecting the device from a network that is not part of the respective home network (including a physical network or a virtual network such as a virtual private network).

Thus, the operating system may be configured such that data cannot be removed from the home network without appropriate permission (e.g., explicit user and/or device authorization). Thus, the techniques may be configured to act as a gateway to physical and virtual storage locations on a home network or on registered devices with user privilege(s). Documents may be assigned identifiers because they are stored in a secure storage location in the home network. Assets such as documents, devices, files, and user profiles may be categorized and a database of asset data may be created from data collected from the assets. A security object, such as a context aware security token, may then be created from the security key defined based on the asset data.

In some implementations, the techniques described in this document provide increased security for various assets in a network. For example, computing devices such as laptop computers, desktop computers, printers, scanners, servers, storage devices, network devices, and electronic files stored within such computing devices may be made more secure by the environment-aware security tokens described in this document.

Fig. 1 shows an example of a system 100 using context aware security tokens. The system 100 includes various network assets (also referred to herein simply as assets) connected to a server 106 over a network 102. The term asset, as used in this document, refers to a device that is directly or indirectly associated with a network, as well as an electronic file that may be stored on a device associated with a network. For example, assets may include personal computing devices 103 (e.g., laptop computers), printers 110, desktop computing devices 112, mobile computing devices (e.g., smartphones, tablets, or e-readers) 114, storage devices 116, or servers 125 (which may also be referred to as remote servers). In some implementations, the asset may include a passive device such as a credit or debit card 108 or a Radio Frequency Identification (RFID) tag, which may communicate over a network via an appropriate reader (e.g., a credit/debit card reader and an RFID tag reader, respectively). The system 100 may include zero, one, or multiple devices of the various types described above. In some implementations, a portion of the network 102 and/or one or more devices coupled to the network 102 may form at least a portion of a home network defined by a particular asset.

In some implementations, the assets include electronic files 104 that can be stored, accessed, read, processed, or otherwise acted upon by a device (e.g., one or more devices associated with network 102). The files 104 may include, for example, documents, software packages, executables, binary files, non-binary files, or other files that may be electronically stored or processed. The files 104 may be associated with various applications and include various features. For example, files 104 may include word processing documents, spreadsheets, text files, drawing files, data files (e.g., database files and/or information), and multimedia files (e.g., audio, video, system data files, etc.). The files 104 may be formatted according to an application and/or operating system associated with the individual files. The format of the file may be identified, for example, by an appropriate file extension such as. exe (for executable files),. htm (for hypertext markup language (HTML) files), or. txt (for text files). In some implementations, the electronic file 104 can include various types of records and files stored in different types of databases. For example, the electronic file 104 may include medical records, academic records, health records, business records, government records, criminal records, real estate records, financial records, social network data, and the like. For example, the electronic file 104 may be stored on a single device (e.g., a laptop or server), or may be distributed across multiple devices (e.g., multiple servers, multiple trays in a data center, or multiple virtual machines in a distributed computing/storage system (e.g., a cloud-based system)).

In some implementations, the electronic files 104 include metadata information about the respective files. The metadata may include, for example, structural metadata relating to the design and specification of the data structure, as well as descriptive metadata relating to additional information of the data content. The metadata may include, for example, information about the location of creation of the document, the means of creation of the document, the time and date of creation of the document, the author or source of the document or data within the document, and the security policy associated with the document. In some implementations, metadata information about a particular document can be used to generate an appropriate context-aware security token for the particular document. For example, if the security policy included in the metadata establishes that the corresponding document can only be viewed by personnel of the human resources department of the company, the context aware security token of the document may be configured such that the document is viewable (and/or printable) only on devices associated with the human resources department.

In some implementations, the system 100 includes a server 106 that coordinates the generation and distribution of the context aware security token 120. The server 106 may also be referred to as a security token server or simply a token server. In some implementations, the server 106 receives asset information 118 regarding various assets associated with the home network and generates corresponding context aware security tokens 120. In some implementations, the server 106 itself may be associated with the context aware security token 120 such that the server cannot be accessed from devices not included in the home network. Even though fig. 1 illustrates a single server 106, multiple servers (e.g., a server farm) and/or one or more remote servers 125 may be used to implement the functionality of the server 106. The server 106 may be a dedicated server, or the functionality of the server 106 may be provided by a server performing other tasks.

Asset information 118 may include identification information related to the asset including, for example, one or more of a serial number of the device, a Media Access Control (MAC) address, a file path, a registry key, a network identifier, an Internet Protocol (IP) address, a file type identifier, a user profile identifier, or other identification information identifying that a particular asset is connected to, authenticated to, or otherwise associated with the home network. In some implementations, a home network may be defined by a serial number or MAC address of a set of physical devices, such as devices owned, managed, or otherwise controlled by a company or organization. In some implementations, the asset information 118 can include an identification of electronic files and documents and/or corresponding storage locations on various devices associated with the home network. In some implementations, the asset information can include user profile information identifying various users authorized to access assets associated with the home network.

In some implementations, the asset information 118 may also include various security policies related to the use of the asset. The security policy may be retrieved, for example, from a storage device connected to or otherwise accessible from the home network. The security policy may be used in conjunction with other asset information 118 to create a context aware security token for one or more assets of the home network. The security policy may include, for example, an identification of a device or user profile (also referred to herein as a user profile) that is authorized to access a particular asset, such as a document, and may be configured, for example, by authorized personnel. A company's security policy may specify that a particular document can only be viewed by board of directors. In this case, the context aware security token for a particular document may be configured such that the document may only be viewed when accessed from a user profile associated with a board member. The security of the document may be further enhanced by configuring the context-aware security token to allow access to the document only from personal devices associated with members of the board of directors. Accordingly, a context aware security token for a document may be generated based on a selectable portion of asset information 118. By allowing such configuration of context-aware security tokens, the techniques described in this document may be made extensible, granular, and flexible to accommodate various types of security requirements.

The server 106 may obtain the asset information 118 by employing one or more techniques. In some implementations, the asset information 118 may be obtained by deploying a network agent configured to collect information about various assets. For example, the network proxy may be deployed by the server 106 as a client application 117 installed on a device associated with a home network. In some implementations, the client application 117 may be pushed by the server 106 to a device that authenticates the home network. In some implementations, the client application 117 can be pre-installed on various devices (e.g., as part of a respective operating system) and authenticated to the home network when the devices attempt to communicate with the home network. In some implementations, the client application 117 itself may include a corresponding context-aware security token that prevents the application 117 from executing when detached from the home network. In some embodiments, the network proxies may be similar to the proxies described in U.S. patent 7,190,478 and U.S. patent 7,872,772, the contents of which are incorporated herein by reference.

In some implementations, the deployment of the network proxy may be configured via a user interface such as example 200 shown in fig. 2A. The user may be able to download and install the network proxy on the device using the user interface 200, which user interface 200 may in turn be launched using the client application 117. For example, upon launching the client application 117, the user may be presented with a user interface 200 to authenticate the user profile and/or device to the home network. This may be accomplished, for example, via controls 205 provided within interface 200 (e.g., fillable text fields, selectable radio buttons, or other controls for entering credentials). After successful authentication, the user may be directed to a storage location from which the network proxy may be installed on the device. For example, a user may be directed to a storage location storing an executable file 210, the executable file 210 configured to install a network proxy on a device. In some implementations, an authorized person (e.g., a network administrator) may be able to install a network agent on a remote device, for example, via user interface 200. In some implementations, the network proxy can be configured to be deployed on the device, for example, when the device registers or authenticates with the server 106.

In some implementations, the network proxy can include one or more software package-specific plug-ins or attachments (also referred to herein as document proxies) installed on devices associated with the home network. FIG. 2B illustrates an example user interface 250 in which such a document agent is installed into a WORD processing application (MICROSOFT WORD in this particular example). Such a document agent may allow a user to perform various configurations on the document, for example, to make the document compatible with the context-aware security token, and/or to specify security parameters for the document. For example, the document agent may allow, e.g., via the second user interface 255, a designation of whether a password is required to access the document, or if one or more actions (e.g., printing, editing, copying, etc.) should be restricted. In some implementations, the document agent may also be configured to transmit the asset information 118 (i.e., information related to the document) to the server 106. For example, activating the control 260 may initiate communication between the document agent and the server 106 to provide the corresponding asset information 118 to the server 106 and receive the environment-aware security token 120 generated by the server 106 based on the corresponding asset information 118. In some implementations, the user interface 255 may be configured to allow a user to specify user-defined security parameters, such as an encryption key or password for the document, so that the document has additional protection, for example, against unauthorized internal access (i.e., access associated with the device or a user profile associated with the home network).

In some embodiments, the document agent may be further configured to integrate the received context-aware security token 120 into a corresponding document. For example, the document agent may be configured to embed the received context-aware security token in a Page Description Language (PDL) of the document. In general, PDL is a language that describes the appearance of a print page at a higher level than the actual output bitmap. Examples of the PDL include PostScript, Printer Command Language (PCL), Portable Document Format (PDF), and markup languages such as open XML Paper Specification (XPS) and hypertext markup language (HTML).

In some implementations, the document agent may be configured to encapsulate the received context-aware security token and the document to create, for example, an executable file. Such an executable file may be configured such that the enforcement point is verified (based on information within the encapsulated context-aware security token) within the home network before allowing access to the encapsulated document. Upon determining that the executable file is being accessed from a location outside of the home network (or an unauthorized device or storage location), access to the packaged document is prevented. In some implementations (e.g., for high security applications), any unauthorized attempt to access an executable file may result in the destruction of the packaged document (e.g., by deletion or digital shredding). Other functions may also be initiated through the operation of the agent and the use of such environment-aware security tokens, such as registering unauthorized attempts, triggering one or more alarms or initiating focused surveys, etc.

Referring again to FIG. 1, in some embodiments, the network proxy is configured to scan assets residing on the device and/or storage location and provide the obtained asset information 118 to the server 106. In some implementations, the network proxy executes from the server (or another device associated with the home network) 106 and polls other devices and storage locations of the home network for asset information 118. The obtained asset information may be associated (i.e., linked) with a corresponding security token, and the association or link information may be stored in a database.

In some embodiments, the obtained asset information is linked to the corresponding asset using an identifier assigned to the asset. Examples of such identifiers may include Globally Unique Identifiers (GUIDs), Universally Unique Identifiers (UUIDs), and so forth. Such identifiers may enable unique identification of various assets within the system 100. For example, one or more documents, files, devices, and storage locations within system 100 may be uniquely identified using such identifiers. Depending on the limited size of the identifier, in some cases, two different assets may share the same identifier. However, the identifier size and generation process may be selected so as to reduce the probability of such occurrence. In some implementations, a 128-bit value (e.g., shown as 32 hexadecimal digits, such as 21EC2020-3AEA-4069-A2DD-08002B30309D) may be used as an identifier assigned to various assets. The identifier may be generated, for example, by a deterministic, random, or pseudo-random process. Alternatively, an identifier that is already associated with the asset (e.g., an identifier issued by the manufacturer, home network, or user/administrator of the home network) may also be used.

In some implementations, the network proxy includes an automated browser (also referred to as a robotic browser) that obtains asset information 118 from some or all of the various devices and other assets associated with the home network. Such an automated browser may be used, for example, to gather information about devices on a network, such as identifiers (GUIDs, UUIDs, etc.) associated with computing devices, printers, and/or storage devices connected to the network. Such an automated browser may also be used, for example, to scan storage locations on various devices to identify asset information, such as file attributes of files associated with the operating system of devices connected to the home network and/or operating systems of devices connected to the home network via a telnet process (e.g., via a Virtual Private Network (VPN)). In some implementations, the automated browser can be configured to attach identifiers such as GUIDs and UUIDs to the acquired asset information. In some implementations, such an automated browser (which may or may not be the same browser used to collect information about devices on the network) may also be used to embed, attach, encapsulate, or otherwise associate the environment-aware security token with a corresponding document or other asset. For example, the automated browser may be configured to include the context aware security token in a header portion of the document via processing such as code injection (e.g., implemented using a programming language such as JAVA). This can be done, for example, by providing the appropriate permissions of the automated browser to modify the document properties. Such permissions may be configured or modified based on a security context grouping policy associated with the home network.

The server 106 may be configured to generate respective context-aware security tokens 120 for one or more assets associated with the home network based on at least a portion of the received asset information 118. The generated context-aware security token 120 may be configured to control how and/or by whom the corresponding asset is accessed. Once the context aware security token 120 is generated and linked to a particular asset, the asset may be used only in accordance with the security policy encoded within the context aware security token 120. For example, the context aware security token 120 for a document may be configured to include an identification of a home network such that the document is only accessible from devices connected to the home network. In some implementations, the context aware security token 120 for a document or file can be configured such that the document is only accessed on a selected set of devices (e.g., identified using a serial number or MAC address) and/or using a user profile from an approved set. For example, in a corporate setting, the context aware security token 120 for a particular document may be configured such that the document is only accessible by an administrative person (e.g., identified by a user profile) and/or a device associated with the person (e.g., a laptop).

The context aware security token 120 may also be used to increase the security of and/or control the accessibility of hardware devices. For example, the context aware security token 120 for a hardware device (e.g., a printer, scanner, copier, facsimile machine, or multi-function device (MFD)) may be configured such that the hardware device will not function outside of the home network. This may be useful, for example, in increasing device security in a corporate setting and/or preventing corporate resources from being used for personal use.

The process of generating the context aware security token 120 may be made extensible, granular, and customizable to provide a flexible security solution. For example, the context aware security token 120 may be configured to control the access levels of various assets. For example, the context aware security token 120 for a particular document may be configured such that only a selected set of people (as identified by the corresponding user profile) can change the content of the document, but a larger set of people associated with the home network (e.g., all employees of the company) can view the document without making any changes.

In some implementations, the context aware security token 120 for an asset may be configured such that the asset may be viewed or accessed from outside the home network, but no changes or edits may be made to the asset. This may be useful, for example, in social networks where a user registers multiple devices (e.g., home computers, office computers, and personal mobile devices) that the user plans to use when accessing a social network account. A context-aware security token 120 may then be generated for each device (e.g., by a social network service provider), and the context-aware security token 120 may be associated with a respective user profile. In this case, the user can update the respective social network account (e.g., in the form of posts, images, videos, etc.) only from the device associated with the user profile. As such, even if the security of the account is compromised (e.g., via a phishing attack that obtains a username-password pair for the user account), a malicious entity (e.g., a hacker) possessing the account credentials may not be able to make changes to the user account from a device that does not have the context-aware security token 120 associated with the corresponding user profile. For example, a malicious entity cannot issue potentially embarrassing or harmful content to a user's account despite obtaining the credentials needed to log into the user's account. Thus, the security of other network-based accounts (e.g., email accounts, internet banking accounts, transaction accounts, and e-commerce accounts) may be increased by associating a predetermined set of physical devices with respective accounts using the context-aware security token 120. In some implementations, context-aware security tokens may be generated for particular users of a social networking service for network resources or assets associated with respective user profiles. Examples of such network resources and assets may include, for example, network segments, storage locations, and files associated with user profiles within a social network service infrastructure. In this case, the user files stored within the infrastructure are protected by the additional security of the corresponding context-aware security token, even if the security of the social networking service is compromised. In some implementations, such additional security may be provided by the social networking service, e.g., in exchange for the same fee.

In some implementations, the home network associated with a given context-aware security token may be configurable by a user. For example, for a context-aware security token 120 associated with a credit card 108, the card may be configured to be used to block one or more types of transactions. For example, the context aware security token 120 corresponding to the card may be configured such that certain types of products or merchandise may not be available for purchase using the card, and/or the card may not be available for use at a predefined set of vendors. This may be useful, for example, when implementing parental control over an accessory card given to young adults. For example, the context aware security token 120 for the add-on card may be configured such that the corresponding home network includes only school stores and suppliers in the school. In this case, the environment-aware security token 120 of the accessory card prevents the card from being used to purchase goods from stores or vendors outside the campus. In some implementations, the context aware security token may also be associated with a virtual instance of a credit card 108, such as a credit card represented by an online account or a smartphone application.

In some implementations, the server 106 may be configured to generate the context-aware security token 120 as a language-agnostic object, which may be developed using various programming languages that are capable of accessing and processing binary data types, such as those associated with the asset information 118. For example, the environment aware security token 120 may be implemented as an object generated using a Component Object Model (COM) standard, which is a binary interface standard for software components developed by MICROSOFT. The standard may be used, for example, to enable interprocess communication and dynamic object creation in a wide range of programming languages. In some embodiments, language agnostic objects, such as COM objects, allow objects to be reused without knowledge of the corresponding internal implementation. For example, objects may be implemented using interfaces that are not aware of implementation details. The different allocation semantics of the various programming languages may be accommodated, for example, by having objects responsible for their own creation and destruction through processes such as reference counting. Reference counting may be used as a technique to, for example, store the number of references, pointers, or handles to a resource, such as an object, memory block, disk space, or other resource. Translation between different interfaces of an object may be achieved, for example, using a query process such as a QueryInterface.

In some implementations, the server 106 is configured to use at least a portion of the received asset information 118 to generate a context aware security token 120 for the respective asset as an object (e.g., a COM object). For example, the object corresponding to the context aware security token may include data fields corresponding to portions of asset information used in generating the context aware security token, as well as procedures (processes) associated with the intended functionality of the context aware security token.

In an object-oriented programming paradigm, processes associated with functions may be referred to as methods. In some embodiments, the method associated with the object corresponding to the context-aware security token may be associated with, for example, one or more of the following functions: i) detecting environmental parameters of an asset associated with the environment-aware security token, ii) authenticating the asset with a token server (e.g., server 106), iii) allowing access to the asset upon authentication, iv) preventing access to the asset upon detection of detachment from the home network, and/or v) tracking various activities related to accessing the asset.

The environment-aware security token 120 embedded or otherwise integrated with the asset may be configured to detect an environmental parameter associated with the asset. For example, if the context aware security token 120 is embedded in the document metadata, the associated object (e.g., a COM object or other security object) may be configured to detect a serial number of the device from which the document is being accessed or stored. The context aware security token 120 may be configured to detect one or more other environmental parameters, such as user profile information, a security policy associated with the document, a type of access attempted to the document, and so forth.

The asset's context aware security token 120 may also be configured to attempt authentication of the asset (or attempted use of the asset) using the detected environmental parameters. For example, the context aware security token 120 may be configured to transmit the detected context parameters to the server 106 to receive an indication of whether access to the asset may be allowed. Alternatively, the context aware security token may also perform at least a portion of the authentication locally, e.g., based on an identification of the home network encoded within the context aware security token 120. If a connection cannot be established to the server 106 (e.g., due to a loss of internet connectivity), a message may be displayed informing the user that the asset cannot be immediately accessed. In some implementations, authentication may be triggered when a user attempts to access a corresponding asset (e.g., when the user attempts to open a document). The context aware security token 120 may also be configured to synchronize with the server 106 periodically, for example, after a predetermined time interval or when any changes to the corresponding asset are detected.

In some implementations, the context aware security token 120 may allow access to the respective asset upon determining that access to the respective asset may be allowed. For example, upon determining that an authorized user is attempting to open a document (e.g., as indicated by authentication information received from server 106), context-aware security token 120 may allow the user to access the document. Access may be allowed based on additional security policies associated with the document. For example, the context aware security token 120 may allow read-only access to the document based on determining that a user attempting to access the document is not authorized to edit the document.

On the other hand, if the context-aware security token 120 determines that access to the asset is unauthorized, access may be prevented. For example, if the context-aware security token 120 determines that a corresponding document resides on a device that is not authenticated to the home network, access to the content of the document may be denied. In high security situations (e.g., for confidential or sensitive military or healthcare related documents), the context aware security token 120 may be configured to corrupt, delete, or digitally shred a corresponding document upon detection of an unauthorized access attempt. This may be done, for example, to prevent any additional attempts to breach the security provided by the context aware security token 120. Such a process may of course be selectively implemented, for example, according to criteria that prevent deletion or destruction of the original document, file or other asset due to accidental access attempts. Furthermore, the techniques described in this document may be used in conjunction with data backup and secondary storage techniques to prevent accidental permanent deletion of data.

In some implementations, the context aware security token 120 may also be used to track usage of the corresponding asset. For example, the context aware security token 120 associated with a document may be configured to record access information (e.g., creation credentials, time and nature of access attempt, location of access attempt, device ID, etc.) of the corresponding asset. The access information may be stored on a local storage device, for example, within an encrypted file system. The stored access information may then be synchronized with information stored at the server 106 during subsequent communications between the context-aware security token 120 and the server 106. In some implementations, a separate agent, such as a Virtual Private Network (VPN) agent, may be used to communicate access information to the server 106. Such agents may themselves be associated with respective context aware security tokens 120 and may manage communications with server 106 using a database management system such as MySQL, ORACLE or MICROSOFT SQL. In some implementations, the access information can also be used to update the context aware security token 120 associated with the document. Thus, the environment aware security token 120 may be used to generate and maintain audit trails of asset usage, thereby further increasing the security and reliability of asset usage.

In some implementations, the asset usage logs stored in the token database may be processed, for example, by an artificial intelligence system to learn trends associated with various assets (e.g., devices, user profiles, and applications). Such artificial intelligence systems may use various types of machine learning techniques. For example, various supervised, unsupervised, or semi-supervised machine learning techniques may be used to identify, classify, or otherwise learn trends and/or behaviors associated with various assets. One or more tools may be used to implement such machine learning techniques. Examples of such tools include decision trees, artificial neural networks, support vector machines, bayesian statistics, classifiers, markov models, and conditional random fields.

Information obtained using machine learning techniques on the asset usage log may then be used to increase the security of the asset. For example, if a malicious entity (e.g., a hacker or malware) attempts to access an asset, such as a document, the agent may be configured to detect fraudulent behavior based on detecting deviations from "normal" behavior learned from asset usage logs. For example, if a log corresponding to a user profile shows that a user typically logs in within a first or two attempts, the occurrence of repeated failed login attempts may be flagged as a potential security breach (break). In this case, the proxy may be configured to capture the identification of the accessing device (e.g., the IP and/or MAC address of the device). If the agent detects malware (e.g., a virus, trojan, or payload software), the agent may be configured to detect the IP and/or MAC address of the server with which the software is communicating (or reporting to). From the identification of the access device, additional information such as geographic location, manufacturer, or serial number may also be determined. This information can be used to take appropriate action on the security breach, possibly with the assistance of law enforcement agencies.

In some implementations, the context aware security token 120 generated by the server 106 is stored within a token database 122 accessible to the server 106. The token database 122 may be stored in a storage device within the server 106 or at a remote storage location or remote server 125 accessible to the server 106. The token database 122 may be used to store information about the context aware security tokens 120 generated at the server 106. For example, the token database 122 may store information linking the context aware security token 120 to a corresponding asset identifier, such as a GUID or UUID. The information linking the context-aware security token 120 to the respective identifier may be used, for example, to identify a home network associated with the respective asset, and/or to authenticate access attempts to various assets. For example, if a user attempts to access a document from a particular device, server 106 may authenticate the access attempt based on information linking the corresponding context-aware security token 120 to an identifier associated with the document. In some implementations, the token database 122 also stores access information associated with the respective asset. For example, if an asset (e.g., a document) is updated, modified, created, deleted, or otherwise manipulated, such access information may be stored, for example, in a token database linked to the corresponding asset identifier.

In some implementations, the server 106 may also be implemented using a distributed computing environment, such as a cloud-based system. In this case, the server 106 may be implemented on a pool 105 of multiple virtual machines 107. Virtual machine 107 may be a set of computing resources (processors, memory, software, etc.) that may be used to perform computing tasks. The computing resources may be provided by one or more independent providers (e.g., providers of cloud computing or other distributed computing services). The security of the virtual machine 107 used to implement the server 106 or portions thereof may be increased, for example, by associating the virtual machine 107 with a corresponding context aware security token 120.

Fig. 3 shows a flowchart 300 depicting an example sequence of operations for providing context-aware security tokens for various assets. In some implementations, at least a portion of the operations of flowchart 300 may be performed, for example, at server 106 described above with reference to fig. 1. The operations include receiving information about one or more assets (302). The various assets may be identified, for example, by respective identifiers such as GUIDs or UUIDs. Assets may include, for example, one or more of the following: a device connected to the home network, a file stored on a storage device connected to the home network, a user profile associated with the home network, or any other asset described above with reference to fig. 1. This information may include any of the asset information 118 described above. For example, the information may include one or more of the following: a serial number of the device, a Media Access Control (MAC) address, a file path, a registry key, a network identifier, an Internet Protocol (IP) address, a file-type identifier, a user profile identifier, and one or more policies associated with the network. In some implementations, the information regarding the one or more assets can be received from an agent deployed on the home network and configured to scan for assets associated with the home network. For example, when a device authenticates to a home network, a proxy may be installed on the device to obtain information about one or more assets associated with the device.

The operations may include generating a security token for the asset based on the received information (304), wherein the security token is configured to identify the home network and restrict access to the corresponding asset when a separation of the asset from the home network is determined. The security token may be generated as a language agnostic object (e.g., a COM object) and may be embedded, attached, encapsulated, or otherwise associated with the respective asset such that if the asset is detached from the home network, the security token deletes, digitally damages, or otherwise prevents access to the asset. In some implementations, the security token can be generated according to one or more security policies associated with the respective asset. Security may be substantially similar to the context aware security token described above.

The separation of assets from the home network may be determined in various ways. For example, determining the detachment of the respective asset from the home network may include determining that the respective asset is not connected to the home network or is not stored on a device connected or registered to the home network. In some implementations, determining the separation of the respective asset from the network can include detecting an access attempt from a user profile that is not associated with the home network. In some implementations, determining the separation can include determining a deviation from a security policy associated with the respective asset.

The operations also include storing information about the security token and information linking the security token to a corresponding identifier (306). This information may be stored, for example, in a database, such as the token database 122 described with reference to fig. 1. In some implementations, the information stored in the database may be updated based on, for example, how the various assets are accessed, used, or updated. For example, the information stored in the database may include logs indicating how, where, and by whom a particular asset is accessed.

Operations may also include initiating integration of the security token into the corresponding asset (308). In some embodiments, initiating the integration may include providing a security token to an agent that performs the integration. For example, a security token of a document may be provided to an agent configured to inject a code corresponding to the security token in a portion of the document. In some embodiments, code injection may be performed, for example, by an automated browser, such as the robotic browser described above. Code or objects (e.g., COM objects) corresponding to the security token of the document or file may be injected into the header within the metadata of the document/file. In some embodiments, a code or object corresponding to a security token of a document may also be embedded in a PDL of the document. In some implementations, the security token can be packaged into a separate file with the corresponding document or file. For example, the agent or application may be configured to generate an application or executable file that encapsulates a security token (e.g., a COM object) with a corresponding document or file. The application, executable file, or file including the security object may be stored at the storage location, for example, as an encrypted document. In some implementations, information about the storage location of the encrypted document may be stored in the token database 122. In some implementations, a distributed storage location (e.g., a cloud-based storage location) may be used to store the encrypted document. The storage location may be defined as a portion of a home network for the corresponding asset. In addition, by threading or otherwise associating a predefined set of user profiles and/or device profiles to a home network, access to an asset may be restricted from within the home network defined for the asset.

During runtime, access to an asset may be controlled based on information received from a respective security token associated with the asset. For example, the security token may provide information about environmental parameters associated with the attempt to access the asset. The environmental parameters may include, for example, information about access points, user profiles, or security parameters associated with the asset. The received information may be compared to stored information to determine whether the access attempt is deemed to be from within a home network associated with the asset. The access attempt may be authorized upon determining that the access attempt indeed came from within the home network and/or satisfied a security policy associated with the corresponding asset. This may be done, for example, by providing a signaling (signal) security token to allow permission information to access the asset.

In some implementations, an asset, such as a document in which the context-aware security token is embedded, may be stored as an encrypted document within a secure storage location within a home network defined for the asset. The encryption used to store the asset within the secure storage location may be based on, for example, a security key specific to the particular user. This may be used, for example, to store a user's documents within a storage system associated with a multi-user system, such as a social networking service or an email service. For example, access to the assets may be controlled based on detecting that the assets are stored at storage locations associated with respective home networks. In some implementations, an additional layer of security may be provided, for example, by checking whether the user profile and/or device profile associated with the access request is authenticated to the home network. In some implementations, access to the home network may be provided, for example, via a hyperlink (e.g., such as one embedded in an email) associated with the context-aware security token. Users or devices not associated with the home network may be able to access assets within the home network using such hyperlinks. In some implementations, a user may be authenticated to the user home network via an authentication request (e.g., a request for biometric authentication) associated with the context-aware security token.

The security techniques described in this document may be used independently or in conjunction with other security systems and architectures. For example, the context aware security token described above may be used in conjunction with security and cryptography techniques such as biometric identification, symmetric key, asymmetric key, symmetric encryption, transport layer security, and encryption techniques. For example, the security of an online account using Secure Sockets Layer (SSL) may be increased by restricting editing capabilities on a set of devices selected by a user by associating the account with a corresponding context-aware security token. In some implementations, files stored on the home network (e.g., system files, data files, documents, voice files, image files, video files, or network files) may be stored with additional cryptography built into the security token using, for example, a symmetric key that is unique to a particular authorized user.

In some implementations (e.g., in high security scenarios), context-aware security tokens may be used in multiple layers to enhance security. For example, a file encrypted with an embedded COM object may be further encapsulated with another COM object to generate a file with dual layer security. By configuring the security policies of the two COM objects differently, the security of the underlying file or document can be greatly increased. For example, the security policy may be configured such that two separate user profiles may be used to open higher and lower level files, requiring not one but two separate people when accessing the files. The encapsulation may be scalable, allowing additional security to be incorporated as needed, for example, through added encapsulation layers.

The techniques described in this document may be used for various applications, application types, or combinations of applications. In some embodiments, the context aware security token may also be used in authentication services such as electronic authentication (eAuthentication). Such authentication services may be provided, for example, by remote servers to other distributed servers, which may be distributed over the internet or an intranet. Similar to credit card verification services provided by third parties to e-commerce websites, authentication services may verify the identity of a user to an entity such as a website or an intranet server. Various networking protocols and application programming interfaces may be used by such an authentication service. Examples of such network protocols include remote authentication dial-in user service (RADIUS), which is a network protocol used to provide centralized authentication, authorization, and accounting (AAA) management for users to connect and use network services. In some embodiments, the techniques described herein may be used in conjunction with or in place of such authentication services to provide secure network-based services. For example, the context aware security token may be used to protect files associated with a network-based transaction such that the files are locked to physical attributes of the respective data center or server. Thus, even if a malicious entity (e.g., a hacker) obtains a transaction file (e.g., by the hacker corresponding to a point of sale of the transaction), the malicious entity may be prevented from opening the file to access sensitive data included in the file. In another example, the credit card data may be secured using an embedded environment security token on the card such that the corresponding user profile may only be accessed from a home network, data center, or cloud service registered with the card. The home network information may in turn be stored in a file protected by another context aware security token to prevent the home network information from being compromised.

The context aware security token may also be used to protect a mobile device, such as a cell phone, tablet, or e-reader. For example, a phone or other mobile device may be associated with a context aware security token. The context aware security token may be configured such that in the event of theft, the biometric login or text login capability is suspended when no activity (or suspicious activity such as multiple login attempts) is detected for a predetermined period of time. Since any harmful activity, such as activities involving downloading files, copying files, or deleting files, requires login authentication with the home network, the owner may have additional time to turn off the phone or mobile device to prevent data theft.

FIG. 4 illustrates an example of a computing device 400 and a mobile device 450 that may be used with the techniques described herein. Referring to fig. 1, any of devices 106, 110, 112, or 114 may be an example of a computing device 400 or a mobile device 450, and server 106 may include one or more computer devices 400. Computing device 400 is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. Computing device 450 is intended to represent various forms of mobile devices, such as personal digital assistants, cellular telephones, smart phones, and other similar computing devices. The components shown here, their connections and relationships, and their functions, are meant to be exemplary only, and are not meant to limit implementations of the techniques described and/or claimed herein.

The exemplary computing device 400 includes a processor 402, memory 404, a storage device 406, a high-speed interface 408 and high-speed expansion ports 410 connected to the memory 404, and a low-speed interface 412 connected to a low-speed bus 414 and storage device 606. Each of the components 402, 404, 406, 408, 410, and 412, are interconnected using various buses, and may be mounted on a common motherboard or in other manners as appropriate. The processor 402 may process instructions for execution within the computing device 400, including instructions stored in the memory 404 or on the storage device 406 to display graphical information for a GUI on an external input/output device, such as display 416 coupled to high speed interface 408. In other embodiments, multiple processors and/or multiple buses may be used, as desired, along with multiple memories and multiple memory types. Moreover, multiple computing devices 400 may be connected, with each device providing portions of the necessary operations (e.g., as a server bank, a blade server bank, or a multi-processor system). In some implementations, a computing device may include a graphics processing unit. The memory 404 stores information within the computing device 400. In one implementation, the memory 404 is volatile memory unit(s). In another implementation, the memory 404 is a non-volatile memory unit(s). The memory 404 may also be another form of computer-readable medium, such as a magnetic or optical disk.

The storage device 406 can provide mass storage for the computing device 400. As shown in FIG. 1, storage device 116 may be an example of storage device 406. In one implementation, the storage device 406 may be or contain a non-transitory computer-readable medium, such as a floppy disk device, a hard disk device, an optical magnetic disk device, or a tape device, a flash memory or other similar solid state storage device, or an array of devices including devices in a storage area network or other configurations. The computer program product may be tangibly embodied in an information carrier. The computer program product may also contain instructions that, when executed, perform one or more methods, such as those described above. The information carrier is a computer-or machine-readable medium, such as the memory 404, the storage device 406, or memory on processor 402.

The high speed controller 408 manages bandwidth-intensive operations for the computing device 400, while the low speed controller 412 manages lower bandwidth-intensive operations. This allocation of functionality is merely an example. In one embodiment, high-speed controller 408 is coupled to memory 404, display 416 (e.g., through a graphics processor or accelerator), and high-speed expansion port 410, where high-speed expansion port 410 can accept various expansion cards (not shown). In this embodiment, low-speed controller 412 is coupled to storage device 406 and low-speed expansion port 414. The low-speed expansion port, which may include various communication ports (e.g., USB, bluetooth, ethernet, wireless ethernet), may be coupled to one or more input/output devices, such as a keyboard, a pointing device, a scanner, or a networking device such as a switch or router, for example, through a network adapter.

Computing device 400 may be implemented in a number of different forms, as shown in the figure. For example, it may be implemented as a standard server 420, or multiple times in a group of such servers. It may also be implemented as part of a rack server system 424. Additionally, it may be implemented in a personal computer such as a laptop computer 422. Alternatively, components from computing device 400 may be combined with other components in a mobile device (not shown), such as device 450. Each of such devices may contain one or more of computing devices 400, 450, and an entire system may be made up of multiple computing devices 400, 450 communicating with each other.

The computing device 450 includes a processor 452, memory 464, an input/output device such as a display 454, a communication interface 466, and a transceiver 468, among other components. The device 450 may also be provided with a storage device, such as a microdrive or other device, to provide additional storage. Each of the components 450, 452, 464, 454, 466, and 468 are interconnected using various buses, and several of the components may be mounted on a common motherboard or in other manners as appropriate.

The processor 452 may execute instructions within the computing device 450, including instructions stored in the memory 464. The processor may be implemented as a chipset of chips that include separate and multiple analog and digital processors. The processor may provide, for example, for coordination of the other components of the device 450, such as control of user interfaces, applications run by device 450, and wireless communication by device 450.

The processor 452 may communicate with a user through a control interface 458 and a display interface 456 coupled to the display 454. The display 454 may be, for example, a TFT LCD (thin film transistor liquid Crystal display) or OLED (organic light emitting diode) display or other suitable display technology. The display interface 456 may comprise appropriate circuitry for driving the display 454 to present graphical and other information to a user. The control interface 458 may receive commands from a user and convert them for submission to the processor 452. Additionally, an external interface 462 may be provided in communication with processor 452 to enable near area communication of device 450 with other devices. External interface 462 may provide, for example, for wired communication in some embodiments, or for wireless communication in other embodiments, and multiple interfaces may also be used.

Memory 464 stores information within computing device 450. The memory 464 may be implemented as one or more of a computer-readable medium or media, volatile memory unit(s), or non-volatile memory unit(s). Expansion Memory 474 may also be provided and connected to device 450 through expansion interface 472, which expansion interface 472 may comprise, for example, a SIMM (Single In Line Memory Module) card interface. Such expansion memory 474 may provide additional storage space for device 450, or may also store applications or other information for device 450. Specifically, expansion memory 474 may include instructions to carry out or supplement the processes described above, and may include secure information also. Thus, for example, expansion memory 474 may be provided as a security module for device 450 and may be programmed with instructions that permit secure use of device 450. In addition, secure applications may be provided via the SIMM card, as well as additional information, such as placing identification information on the SIMM card in a non-hackable manner.

The memory may include, for example, flash memory and/or NVRAM memory, as described below. In one embodiment, a computer program product is tangibly embodied in an information carrier. The computer program product contains instructions that, when executed, perform one or more methods, such as those described above. The information carrier is a computer-or machine-readable medium, such as the memory 464, expansion memory 474, memory on processor 452, or a propagated signal that may be received, for example, over transceiver 468 or external interface 462.

Device 450 may communicate wirelessly through communication interface 466, where necessary, communication interface 466 may include digital signal processing circuitry. Communication interface 466 may provide for communications under various modes or protocols, such as GSM voice calls, SMS, EMS, or MMS messaging, CDMA, TDMA, PDC, WCDMA, CDMA2000, or GPRS, among others. Such communication may occur, for example, through radio-frequency transceiver 468. Further, short-range communication may occur, such as using a bluetooth, WiFi, or other such transceiver (not shown). In addition, GPS (global positioning system) receiver module 470 may provide additional navigation-and location-related wireless data to device 450, which may be used as appropriate by applications running on device 450.

Device 450 may also communicate audibly using audio codec 460, which audio codec 460 may receive voice information from a user and convert it to usable digital information. Audio codec 460 may likewise generate audible sound for a user, e.g., through a speaker (e.g., in a handset of device 450). Such sound may include sound from voice telephone calls, may include recorded sound (e.g., voice messages, music files, etc.), and may also include sound generated by applications operating on device 450.

Computing device 450 may be implemented in a number of different forms, as shown in the figure. For example, it may be implemented as a cellular telephone 480. It may also be implemented as part of a smart phone 482, personal digital assistant, tablet computer, or other similar mobile device.

Various implementations of the systems and techniques described here can be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various implementations can include implementation in one or more computer programs executable and/or interpretable on a programmable system including: at least one programmable processor, which may be special purpose or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, the storage system, at least one input device, and at least one output device.

These computer programs (also known as programs, software applications or code) include machine instructions for a programmable processor, and may be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the terms "machine-readable medium," "computer-readable medium" refers to any computer program product, apparatus and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions.

To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer. Other types of devices may also be used to provide for interaction with a user. For example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback). Input from the user may be received in any form, including acoustic, speech, biometric, or tactile input.

The systems and techniques described here can be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back-end, middleware, or front-end components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a network, such as network 102, described with reference to fig. 1A). Examples of networks include a local area network ("LAN"), a wide area network ("WAN"), and the Internet.

A computing system may include clients and servers, including remote servers. A client and server are generally remote from each other and typically interact through a communication network, such as network 102. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

Other embodiments are within the scope of the following claims.

Claims (60)

1. A computer-implemented method, comprising:

receiving, at a processing device, information about one or more assets associated with a network of devices;

generating a security token for at least one of the assets, the security token based at least on a portion of the received information about the respective asset, wherein the security token is configured to identify a home network defined for the asset and restrict access to the respective asset upon detecting occurrence of an unauthorized activity involving the asset;

storing information about the security token and information linking the security token to the corresponding asset in a storage device; and

initiate integration of the security token with the corresponding asset.

2. The method of claim 1, wherein detecting the occurrence of the unauthorized activity includes determining a separation of the asset from the home network defined for the asset.

3. The method of claim 1, wherein the assets associated with the network include one or more of: a device connected to the network, a file stored on a storage device connected to the network, and a user profile associated with the network.

4. The method of claim 1, wherein the asset is an electronic file, and initiating the integration of the security token into the asset comprises initiating encryption of the asset based on the security token.

5. The method of claim 1, wherein the home network of the asset is defined based on one or more security policies associated with the asset.

6. The method of claim 1, wherein the information comprises one or more of: a serial number of a device, a Media Access Control (MAC) address, a file path, a registry key, a network identifier, a network protocol (IP) address, a file type identifier, a user profile identifier, and one or more policies associated with the network.

7. The method of claim 1, wherein the information about the one or more assets is received from an agent deployed on the network.

8. The method of claim 7, wherein the agent is configured to scan devices of the network for the information.

9. The method of claim 7, wherein the agent comprises an automated browser.

10. The method of claim 1, wherein the security token contains an object generated according to a Component Object Model (COM).

11. The method of claim 1, wherein the security token is generated in accordance with one or more security policies associated with the respective asset.

12. The method of claim 2, wherein determining the separation of the respective asset from the home network includes determining that the respective asset is not connected to the home network.

13. The method of claim 2, wherein determining the separation of the respective asset from the home network includes determining that the respective asset is not stored on a device associated with the home network.

14. The method of claim 2, wherein determining the separation of the respective asset from the home network includes detecting an access attempt from a user profile not associated with the home network.

15. The method of claim 2, wherein the respective asset is an electronic file, and the security token is configured to restrict access to the electronic file by deleting content of the electronic file when the detachment from the home network is determined.

16. The method of claim 1, wherein the information about the security token and the information linking the security token to the respective identifier are stored in a database.

17. The method of claim 1, wherein the respective asset is an electronic file, and initiating integration of the security token into the electronic file comprises initiating code injection into a header portion of the electronic file.

18. The method of claim 1, wherein the respective asset is an electronic file, and initiating integration of the security token with the electronic file comprises initiating encapsulation of the security token with the electronic file.

19. The method of claim 18, wherein an executable file is generated via the encapsulation.

20. The method of claim 1, wherein the respective asset is an electronic document and the security token is integrated into the document as part of a page description language of the document.

21. The method of claim 1, further comprising:

receiving information from the respective asset related to an access point attempting to access the asset;

determining whether the access point is associated with the security token based on the stored information about the security token; and

providing permission information indicating a level of access allowed to the access point based on the determination.

22. A system, comprising:

a memory; and

one or more processors configured to:

receiving information about one or more assets associated with a network of devices,

generating a security token for at least one of the assets, the security token based at least on a portion of the received information about the respective asset, wherein the security token is configured to identify a home network defined for the asset and restrict access to the respective asset upon detecting occurrence of an unauthorized activity involving the asset,

storing information about the security token and information linking the security token to the corresponding asset in a storage device, an

Initiate integration of the security token with the corresponding asset.

23. The system of claim 22, wherein detecting the occurrence of the unauthorized activity includes determining a separation of the asset from the home network defined for the asset.

24. The system of claim 22, wherein the assets associated with the network include one or more of: a device connected to the network, a file stored on a storage device connected to the network, and a user profile associated with the network.

25. The system of claim 22, wherein the asset is an electronic file, and initiating the integration of the security token into the asset comprises initiating encryption of the asset based on the security token.

26. The system of claim 22, wherein the home network of the asset is defined based on one or more security policies associated with the asset.

27. The system of claim 22, wherein the information comprises one or more of: a serial number of a device, a Media Access Control (MAC) address, a file path, a registry key, a network identifier, a network protocol (IP) address, a file type identifier, a user profile identifier, and one or more policies associated with the network.

28. The system of claim 22, wherein the information about the one or more assets is received from an agent deployed on the network.

29. The system of claim 28, wherein the agent is configured to scan devices of the network for the information.

30. The system of claim 28, wherein the computing device is configured to deploy the agent on the network.

31. The system of claim 22, wherein the security token comprises an object generated according to a Component Object Model (COM).

32. The system of claim 22, wherein the computing device is configured to generate the security token according to one or more security policies associated with the respective asset.

33. The system of claim 23, wherein determining the separation of the respective asset from the home network includes determining that the respective asset is not connected to the home network.

34. The system of claim 23, wherein determining the separation of the respective asset from the home network includes determining that the respective asset is not stored on a device associated with the home network.

35. The system of claim 23, wherein determining the separation of the respective asset from the home network includes detecting an access attempt from a user profile not associated with the home network.

36. The system of claim 23, wherein the respective asset is an electronic file, and the security token is configured to restrict access to the electronic file by deleting content of the electronic file when the detachment from the home network is determined.

37. The system of claim 22, wherein the information about the security token and the information linking the security token to the respective identifier are stored in a database.

38. The system of claim 22, wherein the respective asset is an electronic file, and the computing device is configured to initiate integration of the security token into the electronic file by initiating code injection into a header portion of the electronic file.

39. The system of claim 22, wherein the respective asset is an electronic file, and the computing device is configured to initiate integration of the security token with the electronic file by initiating encapsulation of the security token with the electronic file.

40. The system of claim 39, wherein an executable file is generated via the encapsulation.

41. The system of claim 22, wherein the respective asset is an electronic document and the security token is integrated into the document as part of a page description language of the document.

42. The system of claim 22, wherein the computing device is configured to:

receiving information from the respective asset related to an access attempt with respect to the asset;

determining whether the access attempt is associated with the home network based on the stored information about the security token; and

based on the determination, permission information is provided indicating a level of access granted to the access attempt.

43. One or more machine-readable storage devices storing instructions executable by one or more processing devices to perform operations comprising:

receiving information about one or more assets associated with a network of devices;

generating a security token for at least one of the assets, the security token based at least on a portion of the received information about the respective asset, wherein the security token is configured to identify a home network defined for the asset and restrict access to the respective asset upon detecting occurrence of an unauthorized activity involving the asset;

storing information about the security token and information linking the security token to the corresponding asset in a storage device; and

initiate integration of the security token with the corresponding asset.

44. The one or more machine-readable storage devices of claim 43, wherein detecting the occurrence of the unauthorized activity includes determining a separation of the asset from the home network defined for the asset.

45. The one or more machine-readable storage devices of claim 43, wherein the assets associated with the network include one or more of: a device connected to the network, a file stored on a storage device connected to the network, and a user profile associated with the network.

46. The one or more machine-readable storage devices of claim 43, wherein the asset is an electronic file, and initiating the integration of the security token into the asset includes initiating encryption of the asset based on the security token.

47. The one or more machine-readable storage devices of claim 43, wherein the home network of the asset is defined based on one or more security policies associated with the asset.

48. The one or more machine-readable storage devices of claim 43, wherein the information comprises one or more of: a serial number of a device, a Media Access Control (MAC) address, a file path, a registry key, a network identifier, an Internet Protocol (IP) address, a file type identifier, a user profile identifier, and one or more policies associated with the network.

49. The one or more machine-readable storage devices of claim 43, wherein the information about the one or more assets is received from an agent deployed on the network.

50. The one or more machine-readable storage devices of claim 43, wherein the security token contains an object generated according to a Component Object Model (COM).

51. The one or more machine-readable storage devices of claim 43, wherein the security token is generated in accordance with one or more security policies associated with the respective asset.

52. The one or more machine-readable storage devices of claim 44, wherein determining the separation of the respective asset from the home network includes determining that the respective asset is not connected to the home network.

53. The one or more machine-readable storage devices of claim 44, wherein determining the separation of the respective asset from the home network includes determining that the respective asset is not stored on a device associated with the home network.

54. The one or more machine-readable storage devices of claim 44, wherein determining the separation of the respective asset from the home network includes detecting an access attempt from a user profile not associated with the home network.

55. The one or more machine-readable storage devices of claim 44, wherein the respective asset is an electronic file, and the security token is configured to restrict access to the electronic file by deleting content of the electronic file when the detachment from the home network is determined.

56. The one or more machine-readable storage devices of claim 43, wherein the respective asset is an electronic file, and initiating integration of the security token into the electronic file comprises initiating code injection of a header portion of the electronic file.

57. The one or more machine-readable storage devices of claim 43, wherein the respective asset is an electronic file, and initiating integration of the security token with the electronic file comprises initiating encapsulation of the security token with the electronic file.

58. The one or more machine-readable storage devices of claim 57, wherein an executable file is generated via the encapsulation.

59. The one or more machine-readable storage devices of claim 43, wherein the respective asset is an electronic document and the security token is integrated into the document as part of a page description language of the document.

60. The one or more machine-readable storage devices of claim 43, further comprising instructions to:

receiving information from the respective asset related to an access point attempting to access the asset;

determining whether the access point is associated with the security token based on the stored information about the security token; and

providing permission information indicating a level of access allowed to the access point based on the determination.