US20120131635A1 - Method and system for securing data - Google Patents

Method and system for securing data Download PDF

Info

Publication number
US20120131635A1
US20120131635A1 US13304010 US201113304010A US2012131635A1 US 20120131635 A1 US20120131635 A1 US 20120131635A1 US 13304010 US13304010 US 13304010 US 201113304010 A US201113304010 A US 201113304010A US 2012131635 A1 US2012131635 A1 US 2012131635A1
Authority
US
Grant status
Application
Patent type
Prior art keywords
data
process
access
method according
application
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US13304010
Inventor
Luis Miguel Huapaya
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
EMC Corp
Original Assignee
AFORE SOLUTIONS Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/602Providing cryptographic facilities or services
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/604Tools and structures for managing or administering access control systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/088Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage

Abstract

Disclosed is a method of supporting security policies and security levels associated with processes and applications. A security level is associated with a process independent of a user executing the process. When secure data is to be accessed, the security level of the process is evaluated to determine whether data access is to be granted. Optionally, the security level of a user of the process is also evaluated prior to providing data access.

Description

  • This application claims the benefit of U.S. Provisional Patent Application No. 61/416,569, filed on Nov. 23, 2010, the entire contents of which are incorporated herein by reference.
  • FIELD OF THE INVENTION
  • The present invention relates generally to computer security and more particularly to data leakage protection.
  • BACKGROUND
  • The loss and theft of data has become such an impactful reality in today's computing world that many nations have or are enacting laws requiring sensitive information to be secured. For example, organizations handling sensitive information, such as medical or financial records are required to implement encryption processes to prevent the accidental disclosure or intentional misappropriation of sensitive information.
  • To that end, several “Enterprise Data Encryption” solutions, also known as “Data At Rest” or “Data In Motion,” solutions have been implemented. Some of these known solutions and their known shortcomings are as follows:
  • Full Disk Encryption. These solutions implement a mechanism that encrypts an entire file system as it is stored on a storage medium. Only a system provided with a proper startup password successfully starts up and the storage devices, which are fully encrypted. Once the machine is started, anyone has access to the encrypted data—either now in plain text form or now accessible via a known decryption process or key. Moreover, full disk encryption solutions are very demanding of a computer's CPU and of a portable computer's batteries since all file access operations continually encrypt/decrypt data.
  • Volume Based Encryption. These solutions represent an improvement over the full disk encryption solutions insofar as only a portion of a file system, in this case a single volume, is encrypted. These solutions continue to suffer from the fact that once access is granted, all of the information within the volume becomes available without restriction. That said, locking of the computer can access to the secure data via the computer until it is unlocked. It has been recently shown that this type of security often poses a problem when the computer is accessible via an external port, wherein the security data once populated is accessible by the computer and secure data is therefore retrievable via the external port even when the computer is locked.
  • Folder Based Encryption. This solution only encrypts selected folders within a storage medium. It often suffers from the same drawbacks as were previously mentioned but is usually more CPU and battery efficient.
  • Each of the solutions listed above were designed to protect sensitive information from being stolen when a computing device went missing or was stolen. None of these solutions protect against a malicious employee who has access to the information. They are in a position to misappropriate the information by copying it to a portable storage device, by sending it over the Internet using email or FTP, etc.
  • It would be advantageous to provide a solution that not only protects sensitive data when a computing device is lost or stolen, but also protects sensitive information from some malicious users and malicious software that have access to the computing device.
  • SUMMARY OF THE INVENTION
  • In accordance with an embodiment of the invention there is provided a method comprising: assigning a first privilege level to a first process, the first process in execution on a processor of a computer system, the first privilege level other than related to a privilege level of a user of the process or a group of the user; storing a first data file in a data store; requesting access to the first data file by the first process; evaluating the first privilege level of the first process by a second process, the second process in execution on the processor of the computer system and the second process for controlling access to file data by the first process; and in dependence upon the first privilege level of the first process, the second process is operable one of to provide access to the first data file stored in the data store to the first process and to deny access to the first data file stored in the data store to the first process.
  • In accordance with another embodiment of the invention there is provided a method comprising: providing an operating system comprising security for securing data and for providing user access to data based on security policies associated with a user; providing a first application for execution within the operating system; and, assigning to the first application security policies for being applied to restrict access to data accessed within or through the operating system based on the security policies, at least some of the security policies independent of the security policies of both a user of the application and a group of a user of the application.
  • In accordance with another embodiment of the invention there is provided a method comprising: establishing trust between the computer system and the second system; evaluating by the second system the first privilege level of the first process in execution within the computer system; when the first privilege level is sufficient to provide access to the cipher data, providing access to at least some of the cipher data; and when the first privilege level is insufficient to support access to the cipher data, other than providing access to the at least some of the cipher data.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • Embodiments of the invention will now be described with reference to the drawings in which like numbered elements are similar and in which:
  • FIG. 1 is a simplified general block diagram of an exemplary computing environment.
  • FIG. 2 is a simplified block diagram of an operating system environment that suitably represents the logic of existing operating systems 35, whereby application programs 36 contain function calls to OS API functions 202 that are used to interface with underlying OS subsystems 205. Of particular note is how the application code 200 calls OS API functions 202 in order to interface with the OS subsystems 205.
  • FIG. 3 is a simplified block diagram of a computer system illustrating a mechanism of function hooking wherein the regular flow of logic is redirected such that the default behavior of OS API functions 202 gets superseded by that of the OS API override 301, allowing for either additional processing or totally different processing to occur.
  • FIG. 4 is a simplified network diagram illustrating several computing devices 100 managed by one or more security controllers 400 that are used to establish a trust with each remote client 402 and to deploy security policies and allow system administrators to manage security policies within the network.
  • FIG. 5 is a simplified diagram of a computer system for supporting security policies applied to applications and processes.
  • FIG. 6 is a simplified diagram illustrating a possible embodiment of a server controller 400, wherein incoming transactions 610 interface with four distinct handlers, audit, identity, policy, and key recovery.
  • FIG. 7 is a simplified flow diagram of a method implementing decision logic for use in an environment where application programs 36 fall in one of three security groups, namely trusted, semi-trusted and non-trusted.
  • FIG. 8 is a simplified flow diagram illustrating a method for securing clipboard contents.
  • FIG. 9 is a simplified flow diagram illustrating exemplary decision logic for creating a listening network socket.
  • FIG. 10 is a simplified flow diagram illustrating exemplary decision logic for attempting to connect to a remote listening network socket.
  • FIG. 11 is a simplified data block diagram relating to encryption for use with embodiments of the present invention.
  • DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION
  • Most computing devices used today require an operating system that facilitates the interaction between application programs and the hardware of the computing device. Those skilled in the art know that most modem operating systems implement security mechanisms that allow security policies against users, groups, and devices that grant, deny or restrict access to secured data objects. Fundamentally, this is believed to suffice since a user's access profile should determine all of the data a user is entitled to access and should not change. Further, a device's access privileges relate directly to the operation of said device and, as such typically cannot change. As such, a user either accesses data or does not. It was proposed and has been shown that a same user is grantable several different security levels, for example to prevent accidental modification of data, either entered through separate user profiles or through provision of a secondary password, for example modification of a file requires a modification password. That said, each of these security methodologies is related to the user of the information, be it a person, a group or a device.
  • It is now proposed to implement security access restrictions to processes and application programs, thus allowing security policies to be applied against an application during execution, above and beyond security policies for users, groups, and devices.
  • By elevating the application program to the level of an object that is subject to security policies, it is now possible to restrict an interaction of different applications and/or processes in execution within a same environment (i.e. on a same machine, by a same user) and also to implement a robust data protection mechanism which allows only certain application programs to gain access to plain text versions of encrypted files—decrypted files—while other application programs executing within the same environment are either denied access to said encrypted files or are only able to see the secured version of the files—the encrypted version of the files. Further optionally, access to data within processes during execution is controlled in dependence upon said same security policies.
  • As such, data exchange mechanisms such as, but not limited to, a system clipboard and networks sockets are restricted to make sure that data from one application program is not transferred over to other application programs with lesser security permissions within the same environment. Further, computer data that is persistent within a file system (i.e. computer files) is also secured such that, data written by application programs with higher security privileges cannot be read by other application programs with lesser security privileges. Alternatively, data is secured based on security policy data allowing applications or processes to restrict some data and publish other data.
  • FIG. 1 provides a brief general description of a suitable computing environment in which some embodiments of the invention are implementable. Computing device 100 includes non-volatile storage in the form of hard disk drive 27. The hard disk drive 27 comprises data stored therein such as a file allocation table 20 for indicating file locations within the hard disk drive 27, operating system data and files 35, application program files 36, other program files 37 and data 38. The hard disk drive 27 also has an interface 32 for receiving and providing data from and to the hard disk drive 27. Typically, the interface 32 is coupled with a data bus shown with arrows connecting to different parts of the computing device 100. The computing device 100 further comprises a video adapter 48, serial port 46, processing unit 21, network interface 53, host adapter 55, magnetic disk drive interface forming part of a floppy disk drive 28, and optical disk drive interface 34 forming part of an optical drive 30, a USB controller 63, and system memory 22 including ROM 24, BIOS 26, RAM 25, application programs 36, other programs 37, OS 35, and program data 38. The computer also includes interface elements such as monitor 47, keyboard 40, mouse 42, and modem 54. Many of the components shown are or have been standard components for personal computers.
  • FIG. 2 illustrates a simplified block diagram of an operating system environment that suitably represents the logic of existing operating systems 35, whereby application programs 36 comprise function calls to OS API functions 202 that are used to interface with underlying OS subsystems 205. Of particular note is how the application program code 200 invokes OS API functions 202 in order to interface with the OS subsystems 205.
  • The present embodiment relies on a mechanism of function hooking, as illustrated in FIG. 3, where the regular flow of logic is redirected such that the default behavior of OS API functions 202 gets superseded by that of OS API override 301. This allows for either additional processing or totally different processing to occur in response to an OS API function call. Alternatively, a future operating system could include the additional functions therein to provide applications and/or processes with associated security levels. The embodiment introduces a method for enforcing security policies on a per application programs 36 basis and/or per process basis. In this fashion application programs 36 and processes become objects that are subject to security policies. The present embodiment creates a virtual “Operating System abstraction layer” enabling operating system behavior to differ from one application program 36 or process to another.
  • The OS API override 301 logic is implemented in accordance with the present embodiment such that its behavior optionally differs from one application program 36 to another, depending on which security policies are associated with the application program 36. A security manager 300 is used for controlling OS API overrides behavior and for ensuring that each application program 36 in execution is properly controlled based on an associated set of security policies, the application program 36 making calls to the OS API override 301 and optionally, a user within whose virtual space the application program 36 is executing. Such a security manager 300 is, for example, a system service or a kernel level driver. Though the present embodiment describes the security manager 300 as a system or kernel service, it can be implemented in various forms as to allow it to respond to the operating system 35 and operating system specific functionalities.
  • In a specific embodiment of the invention, application programs 36 are associated with groups used to represent varying trust levels representing a hierarchy of trust levels that ranges from fully trusted application programs that are given the maximum level of privilege to banned application programs that are prevented from executing within the OS 35. An exemplary trust level hierarchy is shown in FIG. 22. Of course, other trust levels or policies are also supported.
  • FIG. 4 is a simplified network diagram. The diagram of FIG. 4 illustrates how several computing devices 100 in the form of remote clients 402 are managed by security controllers 400. Optionally, only one security controller 400 is implemented for supporting numerous remote clients 402. Security controllers 400 for example are integrated within domain controllers. Alternatively, security controllers 400 are standalone security policy servers. The security controllers 400 establish a trust with each remote client 402, deploy security policies, and allow system administrators to manage security policies. In some embodiments, there is one master security controller and a series of distributed security controllers. Alternatively, there is one active security controller and at least one backup security controller. A backup security controller is also implementable with distributed security controllers or with a plurality of master security controllers.
  • FIG. 5 is a block diagram of an embodiment of security manager 300 presented to facilitate understanding of the embodiments presented herein. Here the OS API overrides 301 interface with the security manager 300 through four distinct mechanisms:
  • Application Monitor 507 detects when an application program 36 begins execution and stops executing. Application Monitor 507 allows the security manager 300 to correctly identify and register the application program 36 within registered applications 504. This is performed, for example using one or more of various mechanisms such as digital signed binary files, a SHA-1 hash, a SHA-256 hash, etc. The security manager 300 then selects associated security policies 505 for being applied to each and every registered application 504.
  • The cipher key manager 508 allows application programs 36 with sufficient privileges to retrieve cryptographic keys for decrypting encrypted files. Various security policies for determining when a request for a cryptographic key is responded to positively or negatively are implementable depending on the nature of the system and of applications for execution therein. When the cryptographic key is other than stored within a local cach 503, the cipher key manager 508 communicates with security controller 400 via transaction handler 501 in order to recover a cryptographic key. This is described further hereinbelow.
  • In some embodiments, socket manager 509 enforces security restrictions on communication sockets such that application programs 36 associated with insufficient privileges are blocked from connecting to sockets, local, remote, or both of higher privileges. In some circumstances, security policies require that both endpoints of a socket connection have identical privileges. The socket manager 509 relies upon the transaction manager 501 in order to register application programs 36 with the security controller 400 such that remote clients 402 have access to that information and determine the security privileges of application programs 36 remotely executing. Handling of socket connection requests is thereby enforced by the socket manager. Alternatively, security restrictions are enforced differently.
  • In some embodiments, audit recorder 510 records an audit log of system activities such that audit logs within a cache 506 are uploaded to the security controller 400 via the transaction manager 501. Optionally, the audit log is stored locally in a secure fashion. Optionally, the audit log comprises an audit of system activities as defined by stored policies. Optionally, the audit log is tamper proof.
  • Optionally, update manager 502 occasionally updates locally cached security policies stored with policy cache 505 by retrieving current data from the security controller 400 via the transaction manager 501. Optionally, security policies dictate that a failure to communicate with the security controller 400 represents a loss of trust. In such a situation all locally cached cipher keys within key cache 503 are deleted and computing device 100 is flagged as untrusted.
  • FIG. 6 is s block diagram of a server controller illustrating a simplified embodiment of server controller 400. Here incoming transactions 610 interface with four handlers:
  • Audit manager 601 is aggregates incoming audit logs into audit log 609 and analyzes audit events for unusual activity that raises alerts or causes the security controller 400 to modify a trust of remote client 500.
  • Identity manager 602 ensures that an incoming transaction 609 from a remote client 500 originates from remote client 500 and not from another computing device pretending to be remote client 500. Preferably, a strong trust relationship is defined between security controller 400 and each remote client 500. It is important to ensure that when a remote client 500 connects with the security controller 400, it is identified correctly. Existing identification mechanisms such as Kerberos are optionally relied upon. The identity manager 602 optionally leverages domain controllers 600 or other secure servers. In the preferred embodiment of the invention, a trust chain would be created between the security controller 500 and a trusted user 607 running on a trusted remote client 605.
  • The policy manager 603 manages and deploys security policies to remote clients 500. Security policies optionally include group policies 606, application policies 608 and existing security policies from sources such as domain controllers 600. The policy manager 603 aggregates security policies from various sources and then deploys said policies to the remote clients 500. The policy manager 603 also ensures remote client 500 and transacting application program 36 have a right to data in the form of policy data and cryptographic keys via key recovery controller 604.
  • The key recovery controller 604 is for recovering a cryptographic key for an encrypted file that is stored on a remote client 500. Remote clients 500 transact with the security controller 400 to read or write to an encrypted file when the local key cache 503 other than contains the associated key data.
  • Preferably, data files are individually encrypted with individual security keys and then decrypted on demand if the application program 36 attempting to read/write to the encrypted file has sufficient privileges indicated within locally cached security policies 505. In order to better illustrate this concept, FIG. 7 is a simplified flow diagram of a method comprising decision logic where application programs 36 are each in one of three security groups—trusted, semi-trusted and non-trusted. A file is opened at 701. A series of decisions follow relating to the file level security—is the file encrypted—and the process security—is the process trusted, semi-trusted, or untrusted. At 702 the file is accessed with decryption and at 703 the file is accessed. If the file is not encrypted, the trust level of the process is evaluated to determine if the file should be secured. When the process is untrusted, the plain-text file is unchanged at 705. Otherwise, the file is encrypted, either right away or the next time it is modified at 704 and 706.
  • A cryptographic key required to decrypt a first file is embedded within the file itself using a mechanism such as asymmetric encryption relying upon two portions of an asymmetric key. Recovery of the cryptographic key is performed by a security controller 400 that has one portion of the asymmetric key pair. For performance, cryptographic keys that are generated or recovered are optionally cached within a local cipher key cache 503.
  • Only trusted application programs 36 are provided access to encrypted files. Files that are created or modified by the application program are automatically encrypted, thus guaranteeing that any and all persistent data handled by the application program is secured. On Microsoft Windows operating system 35, the operating system application process interface (API) hooked encompasses file system API calls such as but not limited to the following: CreateFile( ), CreateFileEx( ), CloseHandle( ), ReadFile( ), ReadFileEx( ), WriteFile( ) and WriteFileEx( ). File mapping API calls would also have to be hooked, API calls such as CreateFileMapping( ) and MapviewOfFile( ). Basically, any operating system call that causes a persistent file to be created, opened, modified and/or closed is hooked in order for default operating system behavior to be replaced or modified by the more complex policy resolution process and encryption and decryption logic. Implementation within other operating systems typically involves a similar process depending on implementation dependant details of file system is access by application programs 36.
  • Application program that is assigned higher privileges causes files that it writes to be encrypted. There are two possible scenarios for deciding when to encrypt a file. If the file already existed in plain text before a write operating, it is converted into an encrypted file when the next write operation occurs. If it is a newly created file, then as soon as data is stored within it, the data is encrypted. File content is encrypted, for example, in fixed sized blocks using a symmetric cryptographic key that is optionally unique to the file.
  • As illustrated in FIG. 11, for each encrypted file one symmetric cryptographic key 2611 and one asymmetric cryptographic key pair 2604 are generated. The private portion of the asymmetric key 2605 is used to encrypt 2610 the symmetric key 2611 and the public portion 2606 of the asymmetric key (i.e. the key capable of recovering the encrypted symmetric key) is encrypted 2609 using a public key 2615 that is tied to a privilege level of the encrypted file. The security controller 400 contains all of private keys 2600 assigned to each privilege level. When the cipher key manager 508 on a remote client 402 attempts to retrieve the cryptographic key assigned to a specific file and the key is not stored in the local key cache 503, the remote client 402 initiates key recovery by communicating with the security controller 400, which has stored therein the private asymmetric keys for each privilege level. Thus, using an appropriate private asymmetric key based on policy, the security controller 400 recovers cryptographic information for the file by first resolving the asymmetric key and then using that key to decrypt the asymmetrically encrypted symmetric key.
  • In an embodiment, each encrypted file 2603 includes a block of metadata along with one or more fixed sized blocks (2608) of encrypted data. The block of metadata includes data such as the following:
  • An encrypted file marker 2612 in the form of a deterministic data value denoting that the file is encrypted.
  • A unique file identifier 2613 such as a 128 bit or 256 bit GUID (Globally Unique Identifier) used for tracking and auditing purposes.
  • A security group identifier 2614 such as a 128 bit or 256 bit GUID. This is relied upon during the key recovery process to help determine which private encryption key to use to recover the internal symmetric key. Optionally, all application programs with identical levels of privileges are assigned identical security group identifiers.
  • A data block comprising the symmetric key 2611 used to encrypt/decrypt the file content. The data block is encrypted with the private key 2605 of asymmetric key pair 2604 that is unique to the file.
  • A data block comprising public key 2606 is also stored.
  • In some embodiments, a system clipboard is secured such that information from an application program 36 associated with a higher privilege or a different group is inaccessible from an application program 36 of lesser or different privilege. FIG. 8 shows a simplified flow diagram illustrating an embodiment, where requesting to read from the system clipboard at 800 invokes the security manager 300. The security manager 300 first determines whether or not the data within the clipboard originate from an application program 36 of privilege and whether or not the application program 36 attempting to read the clipboard has sufficient privilege to access the data. The application program 36 is allowed to read the data from the clipboard at 802 when policies and privileges so allow; otherwise access is denied at 801.
  • In this fashion, the content of the system clipboard can be prevented from being used to transfer sensitive data from a first application program with higher privilege to a second application program of lesser privilege.
  • In an embodiment implemented on the Microsoft Windows operating system 35, the operating system application process interface (API) calls to be hooked include clipboard system API calls such as OpenClipboard( ), EmptyClipboard( ), GetClipboardData( ) and SetClipboardData( ). In a simple embodiment, when an application program 36 calls SetClipboardData( ) a globally shared variable is initialized with the privilege level of the application program 36 that is initializing the clipboard. When any other application program 36 initiates GetClipboardData( ), the function succeeds when the programs privilege level is equal or higher than the value set within the globally shared variable. Otherwise, the function reacts as though the clipboard is empty. Implementation within other operating systems is also supported.
  • Similar to the system clipboard discussed hereinabove, network sockets are also used to transfer data between application programs. In some embodiments, the implementation of a socket manager 509 mechanism within the security manager 300 is advantageous to ensure that network connections between application programs of incompatible privilege are one of avoided and filtered. This prevents a transfer of secure data from an application program of higher privilege to one of lesser privilege.
  • FIGS. 9 and 10 are simplified flow diagrams illustrating exemplary decision logic that would be implemented to secure network sockets. Application program 36 creates a listening network socket through the process shown in FIG. 9 and an application program attempting to connect to a remote listening network socket is shown in FIG. 10.
  • Referring to FIG. 9, shown is a flow diagram for deciding whether to grant a connection request at 905 or whether to deny said request at 906. At 900 a listening socket is created. At 901 socket( ) is called, at 902 bind( ) is called and at 903 listen( ) is called. At 904 the system awaits an incoming connection request. When an incoming request arrives, a trust level of the requestor process is determined and either 905 or 906 are selected. Conversely for connecting as shown in FIG. 10, connect( ) is called instead of listen at 1000. At 1001, the connect requestor process is registered with the security controller. At 1002, a connection is made with a remote client and at 1003 a result is returned. As noted with regards to FIG. 9, the result varies depending on trust of the requestor process.
  • Security controller 400 is used as a brokerage mechanism between remote clients 500 allowing the remote client 500 that is listening at 900, 901, 902 & 903 for an incoming connection to ensure that the application program in execution on the remote client 500 that is attempting to connect at 904 does have adequate security privileges to complete the connection; otherwise the connection is refused.
  • In an embodiment implemented using Microsoft Windows operating system 35, the operating system application process interface (API) calls that are hooked include network socket API calls such as listen( ), accept( ) and connect( ). Any calls that initialize a network connection either by creating a new connection with listen( ) or by trying to connect to an existing connection with connect( ) are hooked in order to extend the default operating system behavior such that the security controller 400 is queried. This ensures that both sides of the connection have compatible privileges. Alternatively, implementation is within other operating systems, which is also supported.
  • There are other operating system resources that are shared between application programs. Some of these are usable to transfer data from one application program 36 to another. Preferable, OS API override 301 hooks ODS calls to ensure that application programs 36 of lesser privilege do not share these resources with application programs 36 of higher privilege. Examples of such shared resources include global file mappings, mail slots or named pipes, etc.
  • With Microsoft Windows operating system 35, application process interface (API) calls are hooked when they involve shared resources such as mail slots, global file mappings and named pipes. In each of these cases, there is one application program that creates the shared resource and then other application programs might attempt to use the shared resource. Any API calls for consuming an existing shared resource optionally fails when the privilege level of the resource consumer application is not identical to the privilege level of the resource initiator application. Optionally, the process is implemented within other operating systems.
  • Though privilege levels are described throughout as being higher or lower, in an alternative embodiment privileges and privilege levels are more complex than merely higher and lower. In such an embodiment, privilege levels are compatible and incompatible and are evaluated for compatibility based on policy data.
  • Numerous other embodiments may be envisaged without departing from the scope of the invention.

Claims (24)

  1. 1. A method comprising:
    assigning a first privilege level to a first process, the first process in execution on a processor of a computer system, the first privilege level other than related to a privilege level of a user of the process or a group of the user;
    storing a first data file in a data store;
    requesting access to the first data file by the first process;
    evaluating the first privilege level of the first process by a second process, the second process in execution on the processor of the computer system and the second process for controlling access to file data by the first process; and
    in dependence upon the first privilege level of the first process, the second process is operable one of to provide access to the first data file stored in the data store to the first process and to deny access to the first data file stored in the data store to the first process.
  2. 2. A method according to claim 1 wherein the data store is in data communication with the processor of the computer system via a communication network and wherein access to the first data file is provided via a communication network.
  3. 3. A method according to claim 1 comprising:
    providing access to the first data to the first process.
  4. 4. A method according to claim 3 wherein the access provided is selected from a plurality of types of access supported by the system.
  5. 5. A method according to claim 1 wherein the first data file comprises a system clipboard data file.
  6. 6. A method according to claim 1 wherein the first data file is encrypted and wherein access to the first data file requires access to a decryption key associated with the first data file.
  7. 7. A method according to claim 6 wherein the first data file is encrypted.
  8. 8. A method according to claim 7 wherein access to the decryption key is provided in dependence upon a privilege level of the first process and the encrypted data.
  9. 9. A method according to claim 8 wherein once accessed the decryption key is cached by the process for further use thereby.
  10. 10. A method according to claim 6 wherein the first file is encrypted with a symmetric key and stored in association with the symmetric key, the symmetric key stored in a secure form comprising:
    requesting the symmetric key form a key manager;
    wherein in dependence upon the first privilege level of the first process, the second process is operable one of to provide access to the first data file stored in the data store to the first process and to deny access to the first data file stored in the data store to the first process comprises when access to the first data file is provided, extracting the symmetric key by a key manager and providing the extracted symmetric key to the first process.
  11. 11. The method according to claim 1 wherein the second process is the computer system's operating system.
  12. 12. A method according to claim 1 wherein the second process is called in response to a hook into the OS APIs.
  13. 13. A method according to claim 1 wherein privilege levels comprise:
    Top secret, full trusted, semi-trusted, non-trusted, and banned.
  14. 14. A method according to claim 1 wherein the first data file is stored within a second system and comprises cipher data for accessing first secured data, the first secured data secured with a cipher comprising:
    establishing trust between the computer system and the second system;
    evaluating by the second system the first privilege level of the first process in execution within the computer system;
    when the first privilege level is sufficient to provide access to the cipher data, providing access to at least some of the cipher data; and
    when the first privilege level is insufficient to support access to the cipher data, other than providing access to the at least some of the cipher data.
  15. 15. A method comprising:
    providing an operating system comprising security for securing data and for providing user access to data based on security policies associated with a user;
    providing a first application for execution within the operating system; and,
    assigning to the first application security policies for being applied to restrict access to data accessed within or through the operating system based on the security policies, at least some of the security policies independent of the security policies of both a user of the application and a group of a user of the application.
  16. 16. A method according to claim 15 comprising:
    storing first data in a data store;
    requesting access to the first data by the first application;
    evaluating the first application security policies by a second process in execution on a processor of a computer system and the second process for controlling access by the first application to data; and
    in dependence upon the first application security policies, the second process is operable one of to provide access to the first data to the first application and to deny access to the first data to the first application.
  17. 17. A method according to claim 16 wherein the first data comprises data within a clipboard of the operating system.
  18. 18. A method according to claim 16 wherein the first data comprises data accessible via a socket of the operating system.
  19. 19. A method according to claim 16 wherein the first data comprises data accessible from another application in contemporaneous execution on a processor of a computer system wherein access to the first data is provided when the first application security policies is compatible with the security policies of the another application.
  20. 20. A method according to claim 16 wherein the first data comprises data accessible from shared system resources wherein access to the first data is provided when the first application security policies is compatible with the security policies of the shared system resources.
  21. 21. A method according to claim 16 wherein the first data comprises data accessible from shared system resources wherein access to the first data is provided when the first application security policies is compatible with the security policies of an application that stored the first data in association with the shared system resources.
  22. 22. A method according to claim 16 wherein the first data comprises data stored within a persistent data file.
  23. 23. A method according to claim 16 wherein the second process comprises a process forming part of a security controller.
  24. 24. A method comprising:
    establishing a level of trust between a first process in execution on a computer system and a second other process in execution on a computer system, the level of trust established in dependence upon security policy data associated with the first process and security policy data associated with the second other process; and,
    in dependence upon the level of trust established between the first process and the second other process, selectively performing one of providing access to data from the second other process to the first process and denying access to data by the second other process.
US13304010 2010-11-23 2011-11-23 Method and system for securing data Abandoned US20120131635A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US41656910 true 2010-11-23 2010-11-23
US13304010 US20120131635A1 (en) 2010-11-23 2011-11-23 Method and system for securing data

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13304010 US20120131635A1 (en) 2010-11-23 2011-11-23 Method and system for securing data
US14696708 US20150227748A1 (en) 2010-11-23 2015-04-27 Method and System for Securing Data

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14696708 Continuation US20150227748A1 (en) 2010-11-23 2015-04-27 Method and System for Securing Data

Publications (1)

Publication Number Publication Date
US20120131635A1 true true US20120131635A1 (en) 2012-05-24

Family

ID=46065679

Family Applications (2)

Application Number Title Priority Date Filing Date
US13304010 Abandoned US20120131635A1 (en) 2010-11-23 2011-11-23 Method and system for securing data
US14696708 Pending US20150227748A1 (en) 2010-11-23 2015-04-27 Method and System for Securing Data

Family Applications After (1)

Application Number Title Priority Date Filing Date
US14696708 Pending US20150227748A1 (en) 2010-11-23 2015-04-27 Method and System for Securing Data

Country Status (2)

Country Link
US (2) US20120131635A1 (en)
CA (1) CA2759612C (en)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130254536A1 (en) * 2012-03-22 2013-09-26 Workshare, Ltd. Secure server side encryption for online file sharing and collaboration
WO2014018731A1 (en) * 2012-07-25 2014-01-30 The University Of North Carolina At Chapel Hill Methods, systems, and computer readable media for providing a secure virtual research space
US20140258720A1 (en) * 2013-03-11 2014-09-11 Barracuda Networks, Inc. Systems and methods for transparent per-file encryption and decryption via metadata identification
US20140321637A1 (en) * 2013-04-30 2014-10-30 Kathie Wilson Secure Time and Crypto System
US20150058619A1 (en) * 2011-08-09 2015-02-26 CloudPassage, Inc. Systems and methods for implementing computer security
US9070112B2 (en) 2011-06-08 2015-06-30 Workshare, Ltd. Method and system for securing documents on a remote shared storage resource
WO2016154525A1 (en) * 2015-03-25 2016-09-29 Vera Policy enforcement
US20160292433A1 (en) * 2013-12-30 2016-10-06 Huawei Device Co., Ltd Permission management method and apparatus
US9473512B2 (en) 2008-07-21 2016-10-18 Workshare Technology, Inc. Methods and systems to implement fingerprint lookups across remote agents
US20170024571A1 (en) * 2015-07-23 2017-01-26 Ca, Inc. Executing privileged code in a process
US9613340B2 (en) 2011-06-14 2017-04-04 Workshare Ltd. Method and system for shared document approval
US10025759B2 (en) 2010-11-29 2018-07-17 Workshare Technology, Inc. Methods and systems for monitoring documents exchanged over email applications
US10133723B2 (en) 2014-12-29 2018-11-20 Workshare Ltd. System and method for determining document version geneology

Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5699428A (en) * 1996-01-16 1997-12-16 Symantec Corporation System for automatic decryption of file data on a per-use basis and automatic re-encryption within context of multi-threaded operating system under which applications run in real-time
US20030200459A1 (en) * 2002-04-18 2003-10-23 Seeman El-Azar Method and system for protecting documents while maintaining their editability
US20060075464A1 (en) * 2004-10-01 2006-04-06 Microsoft Corporation Access authorization API
US20060294372A1 (en) * 2005-06-24 2006-12-28 Microsoft Corporation Securely providing extensible third-party plug-ins
US20090007256A1 (en) * 2007-06-28 2009-01-01 Microsoft Corporation Using a trusted entity to drive security decisions
US20090328129A1 (en) * 2008-06-25 2009-12-31 International Business Machines Corporation Customizing Policies for Process Privilege Inheritance
US20100217912A1 (en) * 2009-02-26 2010-08-26 Broadcom Corporation Dockable handheld computing device with graphical user interface and methods for use therewith
US20100242083A1 (en) * 2009-03-23 2010-09-23 International Business Machines Corporation Restricting access to objects created by privileged commands
US7877781B2 (en) * 2005-12-29 2011-01-25 Nextlabs, Inc. Enforcing universal access control in an information management system
US20110029772A1 (en) * 2004-12-03 2011-02-03 Whitecell Software Inc. Cloud-based application whitelisting
US20110131640A1 (en) * 2008-02-18 2011-06-02 Microelectronica Espanola S.A.U. Secure transfer of data
US8136155B2 (en) * 2003-04-01 2012-03-13 Check Point Software Technologies, Inc. Security system with methodology for interprocess communication control

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6487665B1 (en) * 1998-11-30 2002-11-26 Microsoft Corporation Object security boundaries
US7669051B2 (en) * 2000-11-13 2010-02-23 DigitalDoors, Inc. Data security system and method with multiple independent levels of security
US20030014466A1 (en) * 2001-06-29 2003-01-16 Joubert Berger System and method for management of compartments in a trusted operating system
US7685436B2 (en) * 2003-10-02 2010-03-23 Itt Manufacturing Enterprises, Inc. System and method for a secure I/O interface
JP2006155155A (en) * 2004-11-29 2006-06-15 Fujitsu Ltd Information leakage preventing device and method, and its program
US7665143B2 (en) * 2005-05-16 2010-02-16 Microsoft Corporation Creating secure process objects
CN101283332A (en) * 2005-10-04 2008-10-08 日本电气株式会社 Information processing device, information processing method, and program
CN101305377A (en) * 2005-11-09 2008-11-12 日本电气株式会社 Communication terminal device, server terminal device, and communication system using the same
US8560863B2 (en) * 2006-06-27 2013-10-15 Intel Corporation Systems and techniques for datapath security in a system-on-a-chip device
US8272048B2 (en) * 2006-08-04 2012-09-18 Apple Inc. Restriction of program process capabilities
US20080107275A1 (en) * 2006-11-08 2008-05-08 Mehdi Asnaashari Method and system for encryption of information stored in an external nonvolatile memory
US8095517B2 (en) * 2007-02-08 2012-01-10 Blue Coat Systems, Inc. Method and system for policy-based protection of application data
US8429741B2 (en) * 2008-08-29 2013-04-23 Google, Inc. Altered token sandboxing
US8166314B1 (en) * 2008-12-30 2012-04-24 Emc Corporation Selective I/O to logical unit when encrypted, but key is not available or when encryption status is unknown
US8505084B2 (en) * 2009-04-06 2013-08-06 Microsoft Corporation Data access programming model for occasionally connected applications
US8631482B2 (en) * 2010-05-28 2014-01-14 Apple Inc. Method for managing computer resources accessed by a program operating in a restricted environment
US8640187B2 (en) * 2010-05-28 2014-01-28 Red Hat, Inc. Systems and methods for providing an fully functional isolated execution environment for accessing content

Patent Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5699428A (en) * 1996-01-16 1997-12-16 Symantec Corporation System for automatic decryption of file data on a per-use basis and automatic re-encryption within context of multi-threaded operating system under which applications run in real-time
US20030200459A1 (en) * 2002-04-18 2003-10-23 Seeman El-Azar Method and system for protecting documents while maintaining their editability
US8136155B2 (en) * 2003-04-01 2012-03-13 Check Point Software Technologies, Inc. Security system with methodology for interprocess communication control
US20060075464A1 (en) * 2004-10-01 2006-04-06 Microsoft Corporation Access authorization API
US20110029772A1 (en) * 2004-12-03 2011-02-03 Whitecell Software Inc. Cloud-based application whitelisting
US20060294372A1 (en) * 2005-06-24 2006-12-28 Microsoft Corporation Securely providing extensible third-party plug-ins
US7877781B2 (en) * 2005-12-29 2011-01-25 Nextlabs, Inc. Enforcing universal access control in an information management system
US20090007256A1 (en) * 2007-06-28 2009-01-01 Microsoft Corporation Using a trusted entity to drive security decisions
US20110131640A1 (en) * 2008-02-18 2011-06-02 Microelectronica Espanola S.A.U. Secure transfer of data
US20090328129A1 (en) * 2008-06-25 2009-12-31 International Business Machines Corporation Customizing Policies for Process Privilege Inheritance
US20100217912A1 (en) * 2009-02-26 2010-08-26 Broadcom Corporation Dockable handheld computing device with graphical user interface and methods for use therewith
US20100242083A1 (en) * 2009-03-23 2010-09-23 International Business Machines Corporation Restricting access to objects created by privileged commands

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
David D. Clark; Acomparison of commercial and military computer security policies; Year: 1987; IEEE; PP; 1-11 *

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9473512B2 (en) 2008-07-21 2016-10-18 Workshare Technology, Inc. Methods and systems to implement fingerprint lookups across remote agents
US9614813B2 (en) 2008-07-21 2017-04-04 Workshare Technology, Inc. Methods and systems to implement fingerprint lookups across remote agents
US10025759B2 (en) 2010-11-29 2018-07-17 Workshare Technology, Inc. Methods and systems for monitoring documents exchanged over email applications
US9070112B2 (en) 2011-06-08 2015-06-30 Workshare, Ltd. Method and system for securing documents on a remote shared storage resource
US9613340B2 (en) 2011-06-14 2017-04-04 Workshare Ltd. Method and system for shared document approval
US20150058619A1 (en) * 2011-08-09 2015-02-26 CloudPassage, Inc. Systems and methods for implementing computer security
US9497224B2 (en) * 2011-08-09 2016-11-15 CloudPassage, Inc. Systems and methods for implementing computer security
US20130254536A1 (en) * 2012-03-22 2013-09-26 Workshare, Ltd. Secure server side encryption for online file sharing and collaboration
US9984245B2 (en) 2012-07-25 2018-05-29 The University Of North Carolina At Chapel Hill Methods, systems, and computer readable media for providing a secure virtual research space
WO2014018731A1 (en) * 2012-07-25 2014-01-30 The University Of North Carolina At Chapel Hill Methods, systems, and computer readable media for providing a secure virtual research space
US20140258720A1 (en) * 2013-03-11 2014-09-11 Barracuda Networks, Inc. Systems and methods for transparent per-file encryption and decryption via metadata identification
US20140321637A1 (en) * 2013-04-30 2014-10-30 Kathie Wilson Secure Time and Crypto System
US9306751B2 (en) * 2013-04-30 2016-04-05 Kathie Wilson Secure time and crypto system
US20160292433A1 (en) * 2013-12-30 2016-10-06 Huawei Device Co., Ltd Permission management method and apparatus
US10133723B2 (en) 2014-12-29 2018-11-20 Workshare Ltd. System and method for determining document version geneology
WO2016154525A1 (en) * 2015-03-25 2016-09-29 Vera Policy enforcement
US9785783B2 (en) * 2015-07-23 2017-10-10 Ca, Inc. Executing privileged code in a process
US20170024571A1 (en) * 2015-07-23 2017-01-26 Ca, Inc. Executing privileged code in a process

Also Published As

Publication number Publication date Type
CA2759612A1 (en) 2012-05-23 application
US20150227748A1 (en) 2015-08-13 application
CA2759612C (en) 2018-10-23 grant

Similar Documents

Publication Publication Date Title
Halcrow Demands, solutions, and improvements for Linux filesystem security
Gray et al. D’Agents: Security in a multiple-language, mobile-agent system
Walsh et al. Security and reliability in Concordia/sup TM
US8572757B1 (en) Seamless secure private collaboration across trust boundaries
US6173402B1 (en) Technique for localizing keyphrase-based data encryption and decryption
US20110271279A1 (en) Secure Virtual Machine
US20070016771A1 (en) Maintaining security for file copy operations
US20110246767A1 (en) Secure virtual machine memory
US20070011749A1 (en) Secure clipboard function
US20070011469A1 (en) Secure local storage of files
US20100161928A1 (en) Managing access to an address range in a storage device
US20130067243A1 (en) Secure Data Synchronization
US8261320B1 (en) Systems and methods for securely managing access to data
US6272631B1 (en) Protected storage of core data secrets
US8412934B2 (en) System and method for backing up and restoring files encrypted with file-level content protection
US20110030045A1 (en) Methods and Systems for Controlling Access to Resources and Privileges Per Process
US20100303240A1 (en) Key management to protect encrypted data of an endpoint computing device
US20070112772A1 (en) Method and apparatus for securely accessing data
US20080181406A1 (en) System and Method of Storage Device Data Encryption and Data Access Via a Hardware Key
US20140108793A1 (en) Controlling mobile device access to secure data
US20100037296A1 (en) Client Authentication And Data Management System
US20140164774A1 (en) Encryption-Based Data Access Management
US20110277013A1 (en) Methods and Systems for Forcing an Application to Store Data in a Secure Storage Location
US8510552B2 (en) System and method for file-level data protection
US20120036370A1 (en) Protecting Documents Using Policies and Encryption

Legal Events

Date Code Title Description
AS Assignment

Owner name: AFORE SOLUTIONS INC., CANADA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HUAPAYA, LUIS MIGUEL;REEL/FRAME:027273/0326

Effective date: 20111122

AS Assignment

Owner name: CLOUDLINK TECHNOLOGIES INC., CANADA

Free format text: CHANGE OF NAME;ASSIGNOR:AFORE SOLUTIONS INC.;REEL/FRAME:035286/0040

Effective date: 20140715

AS Assignment

Owner name: EMC CORPORATION, MASSACHUSETTS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:CLOUDLINK TECHNOLOGIES INC.;REEL/FRAME:036324/0659

Effective date: 20150415