US20060218389A1 - System and method for identity decisions and invalidation - Google Patents

System and method for identity decisions and invalidation Download PDF

Info

Publication number
US20060218389A1
US20060218389A1 US11/087,222 US8722205A US2006218389A1 US 20060218389 A1 US20060218389 A1 US 20060218389A1 US 8722205 A US8722205 A US 8722205A US 2006218389 A1 US2006218389 A1 US 2006218389A1
Authority
US
United States
Prior art keywords
identity
system
object
media
metadata
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.)
Granted
Application number
US11/087,222
Other versions
US7756841B2 (en
Inventor
Eric Li
John Rector
Genevieve Fernandes
David Probert
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.)
Microsoft Technology Licensing LLC
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Priority to US11/087,222 priority Critical patent/US7756841B2/en
Assigned to MICROSOFT CORPORATION reassignment MICROSOFT CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: FERNANDES, GENEVIEVE, LI, ERIC, PROBERT, DAVID B., RECTOR, JOHN
Publication of US20060218389A1 publication Critical patent/US20060218389A1/en
Application granted granted Critical
Publication of US7756841B2 publication Critical patent/US7756841B2/en
Assigned to MICROSOFT TECHNOLOGY LICENSING, LLC reassignment MICROSOFT TECHNOLOGY LICENSING, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MICROSOFT CORPORATION
Active legal-status Critical Current
Adjusted expiration legal-status Critical

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/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow

Abstract

A system and method for identity decisions and invalidation. Modified objects (e.g., files, executables, etc.) are flagged for reevaluation. Privileges associated with the object are only persisted if the modifications are determined to be authorized (e.g., updates and patches). In one embodiment, a tagging system registers to be notified of all writes, renames, truncations, moves, deletions, or any other relevant modifications to objects. If the tagging system detects a modification operation targeting the object, it invalidates all identity decisions cached with the object. The next time the object runs, the system does not recognize the object and it is forced to reevaluate its identity. Thus, patching and other write operations are still permitted, but the system detects the changed object and reevaluates the identity.

Description

    FIELD OF THE INVENTION
  • The embodiment of the present invention relates to identities in a computer system, and more particularly, to a system and method for identity decisions and invalidation.
  • BACKGROUND OF THE INVENTION
  • Spoofing and impersonation software attacks take advantage of the privileges assigned to executable objects to achieve their nefarious ends. Typically, the attack modifies the executable to perform the malicious acts using (implicit or explicit) privileges or capabilities associated with the unmodified executable. This vulnerability can be addressed by altering the ACL governing the executable to make it non-writable, but this approach also prevents patching and upgrading of the executable.
  • The embodiment of the present invention is directed to providing a system and method that overcome the foregoing and other disadvantages. More specifically, the present invention is directed to an improved system and method for identity decisions and invalidation.
  • SUMMARY OF THE INVENTION
  • A system and method for identity decisions and invalidation is provided. Related methods are described in U.S. patent application Ser. No. 10/938,126, filed Sep. 10, 2004, U.S. patent application Ser. No. 10/963,479, filed Oct. 12, 2004, and U.S. patent application Ser. No. 10/868,183, filed Jun. 15, 2004, each of which is hereby incorporated by reference in its entirety. In accordance with one aspect of the invention, modified objects are flagged for reevaluation. Privileges and decisions associated with the object are only persisted if the modifications are determined to be authorized (e.g., updates and patches). In one embodiment, a tagging system registers to be notified of all writes, renames, truncations, moves, deletions, and any other relevant modifications to the object. If the tagging system detects a modification operation targeting the object, it invalidates all identity decisions cached with the object. The next time the object runs, the system does not recognize the object and it is forced to reevaluate its identity. Thus, patching and other write operations are still permitted, but the system detects the changed object and reevaluates the identity. It will be appreciated that the embodiment of the present invention is intended as an improvement on computing a hash or signature of the object and checking the object each time it is executed, because, in the absence of any writes, there is no significant per run computational cost. This avoids slowing down normal process creation, DLL loads, or other file accesses while computing the hash. Additional implementations may also be envisioned in which the system responds to the appropriate notifications that the target object has/will/might change by deleting the corresponding identity data stored for the target object.
  • In accordance with another aspect of the invention, the system includes an ID engine, a sources ID manifest, decision makers, a metadata cache, and metadata providers (policy engines). The ID engine generates identifications for particular applications and the objects, such as executables, associated with them, and may include a detection component, a protection component, an invalidation component, and a cache for object/identity. The identification engine and decision makers may exchange information regarding objects and identifications. The decision makers and metadata cache may exchange information regarding identifications and metadata. The metadata cache may include an invalidation engine, which is used to invalidate the identity metadata that is cached for an object when a change is detected to the object.
  • In accordance with another aspect of the invention, a per-identity table and a global current sequence number table are maintained. The sequence numbers of the tables are associated with metadata providers, which provide information about the innate characteristics of the application as well as encapsulating explicit policies of the system. A sequence number from the per identity table for an associated provider is compared to the corresponding sequence number from the global current sequence number table to determine if the provider will be invoked to generate current metadata for the identity.
  • In accordance with another aspect of the invention, for untrusted media, such as removable media or an insecure file system, such as FAT, the system may detect that the object is stored on untrusted media, and copy the target object into a trusted directory (perhaps on non-removable or otherwise secured media, such as an NTFS directory with proper ACLs). The identity may then be recomputed on the trusted copy. A determination may then be made as to whether the system has notifications for media removal and media arrival (as well as across system reboots). If the system has such notifications, then the ID may be cached. If the system does not have such notifications, then the ID may not be cached (in other words, the local copy may essentially be thrown out in that it will not have a cached ID and will have to be recopied and have the ID recomputed each time.) The identification is then returned. In a system which has notifications for media removal (as well as across system reboots), if a notification of media removal (or change notification in some file systems) or reboot is received, then the media's cache may be invalidated. It will be appreciated that other embodiments of this routine for untrusted media may also be envisioned, and that the general point is that the correctness of the system depends on reliable change notifications, which prompt the invalidation of the media's cache. A media removal notification is one example, a per-file change notification is another. In many systems, such reliable change notifications may be available. In cases where they are not, whether it is because the media doesn't support a removal notice or the file system doesn't support the necessary per-file changes, or in general if the file system is not trusted, the fall back is the “recomputed on every run” alternative described above where the ID is not cached and is recomputed each time. In general the “recomputed on every run” alternative will be slower, but may be preferred in cases where reliable change notifications are not available.
  • In accordance with another aspect of the invention, for a network volume system, the operating system may detect such volumes and copy the object into a secure directory (on the local system or to a trusted network location). If the remote system or object store is not trusted, or if a determination is made that the object was changed during the copying, then the identity is recomputed on the trusted copy. If the system and object are trusted, and if there were no changes to the object during the copying, then the identification is obtained from the trusted system. With regard to this routine for network volumes, it will be appreciated that in one embodiment a local copy does not need to be made for all network volumes. Instead, a local copy is only made for untrusted network volumes. If the remote machine is trusted, and if the remote machine is able to send reliable change notifications, then the system doesn't have to fall back to copying it locally and recomputing the identification every time. Instead, it may be treated like a file on a trusted local volume.
  • In accordance with another aspect of the invention, for a multi-boot system, the tagging system stores a unique identifier denoting the current executing operating system to uniquely denote which operating system is identified and the associated data for the object. When the system accesses the stored data, the currently executing operating system identification gets checked against the stored operating system identification with the data. If there is a mismatch of operating system IDs, then the system invalidates the stored identity and data and reevaluates the object's identity and stores the current data along with the current operating system identification.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The foregoing aspects and many of the attendant advantages of this invention will become more readily appreciated as the same become better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings, wherein:
  • FIG. 1 is a block diagram of a system for identity decisions and invalidations;
  • FIG. 2A is a diagram of a per-identity table;
  • FIG. 2B is a diagram of a global current sequence number table;
  • FIG. 3 is a flow diagram illustrative of a general routine for obtaining valid decision metadata for an identity utilizing the tables of FIGS. 2A and 2B;
  • FIG. 4 is a flow diagram illustrative of a routine for retrieving decision metadata for an object;
  • FIG. 5 is a flow diagram illustrative of a routine for the revocation of identity data associated with an object based on notification of changes to the object, e.g. by a filter;
  • FIGS. 6A and 6B are flow diagrams illustrative of a routine for associating identities with objects on removable media;
  • FIG. 7 is a flow diagram illustrative of a routine for associating identities with objects on network volumes; and
  • FIG. 8 is a flow diagram illustrative of a routine for associating identities with objects in a multi-boot system.
  • DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
  • FIG. 1 is a block diagram of an identity decision system 100 in accordance with the embodiment of the present invention. As shown in FIG. 1, the identity decision system 100 includes an ID engine 110, a sources ID manifest 120, decision makers 130, a metadata cache 140, and metadata providers 150. The ID engine 110 generates identifications and may include a detection component 112, a protection component 114, an invalidation component 116, and an object identity cache 118. The identification engine 110 and decision makers 130 exchange information regarding objects and identifications. The decision makers 130 and metadata cache 140 exchange information regarding identifications and metadata. The metadata cache 140 includes an invalidation engine 142, which is utilized to invalidate identity metadata that is cached for an object under certain conditions, such as when a change is detected to the object. In one embodiment, the decision metadata may be invalidated either when the object is modified, or as initiated by the metadata provider due to changes in policy. As will be described in more detail below with reference to FIGS. 2A and 2B, a per identity table and a global current sequence number table may be maintained, and a sequence number for a provider from the per identity table may be compared with the provider's current sequence number from the global table to determine if the provider will be invoked to generate current metadata for the current identity.
  • FIG. 2A is a diagram of a per identity table 200A. As will be described in more detail below, the table 200A illustrates how in a cache to go from the object ID to the decision metadata for a provider. As shown in FIG. 2A, the per identity table 200A includes a provider column 210, a provider sequence number column 220, and a provider decision metadata for the object column 230. The provider column 210 lists various providers (e.g., provider 1, provider 2, provider 3, etc.). The provider sequence number column 220 includes sequence numbers for each of the associated providers. The provider decision metadata for the object column 230 includes decision metadata. In one embodiment, the sequence numbers of the provider sequence number column 220 may be thought of as being comparable to time stamps, in that they are compared to sequence numbers from another table (see FIG. 2B), as will be described in more detail below.
  • FIG. 2B is a diagram of a global current sequence number table 200B. As shown in FIG. 2B, the global current sequence number table 200B includes a provider column 250 and a sequence number column 260. The provider column 250 lists various providers (e.g., provider 1, provider 2, provider 3, etc.), while the sequence number column 260 lists the current sequence numbers associated with each of the providers. As will be described in more detail below with reference to FIG. 3, a sequence number from the sequence number column 220 of FIG. 2A is compared with a current sequence number from the sequence number column 260 of FIG. 2B to determine if the provider will be invoked to generate current metadata for the current identity.
  • FIG. 3 is a flow diagram illustrative of a general routine 300 for obtaining valid decision metadata for an identity utilizing the tables of FIGS. 2A and 2B. As shown in FIG. 3, at a block 310, the sequence number for a provider's metadata is obtained from a per identity table (e.g., see per identity table 200A of FIG. 2A). At a block 320, a current sequence number for the provider is obtained from a global table (e.g., see global current sequence number table 200B of FIG. 2B).
  • At a decision block 330, a determination is made as to whether the sequence numbers match. If the sequence numbers match, then the routine continues to a block 360, as will be described in more detail below. If the sequence numbers do not match, then the routine continues to a block 340. At block 340, the provider is invoked to generate current metadata for the current identity. At a block 350, the generated metadata is cached and the provider metadata sequence number is updated in the per identity table. At the block 360, the metadata is returned for the provider.
  • FIG. 4 is a flow diagram illustrative of a routine 400 for retrieving decision metadata for an object (e.g., an object may be a file, an executable, etc.). At a decision block 410, a determination is made as to whether an identity is present for the object. If an identity is present, then the routine continues to a decision block 430, as will be described in more detail below. If an identity is not present, then the routine continues to a block 420, where an identity is computed.
  • At decision block 430, a determination is made as to whether the decision metadata for the object is available. If the decision metadata is available, then the routine ends. If the decision metadata is not available, then the routine continues to a block 440, where the policy engine is asked to provide the decision metadata for the identified object.
  • FIG. 5 is a flow diagram illustrative of a routine 500 for revocation of an identity associated with an object. At a block 510, a filter registers to be notified of all writes, renames, truncations, moves, deletions, and any other relevant modifications. The filter can be implemented as a filter on file system operations, or use notifications (such as OpLocks) or other synchronous callback mechanisms to detect modification. At a block 520, upon detecting a modification to a tagged object, the filter invalidates all identity cached with that object.
  • As will be described in more detail below with regard to FIGS. 6A, 6B, and 7, removable media and network volumes are notable since a malicious user may alter the object/file beyond the detection of the local system. Since an ordinary user may control a network volume, they may tamper with a network object/file after the tagging system stores the identity and the data. Similarly, with removable media, the user may remove the media and change the contents on a different operating system. As will be described in more detail below with regard to FIGS. 6A, 6B, and 7, a copy mechanism may be utilized as part of the identity process.
  • FIGS. 6A and 6B are flow diagrams illustrative of routines 600A and 600B for associating identities with objects on removable media. As shown in FIG. 6A, at a block 610, an object is copied. (In another embodiment, the copy may be avoided if the system can securely store the cache ID and upon media insertion any existing cached identity and data are deleted for that media.) At a block 620, the identity is computed. At a decision block 630, a determination is made as to whether the system has notifications for media removal and media arrival (as well as across system reboots). If the system does not have such notifications, then the identity may not be cached and the routine continues to block 650, as will be described in more detail below (in other words, the local copy may essentially be thrown out in that it will not have a cached identity and will have to be recopied and have the identity recomputed each time). If the system has such notifications, then the routine continues to block 640, where the identification is cached. At the block 650, the identification is returned.
  • It will be appreciated that other embodiments of this routine for untrusted media may also be envisioned, and that the general point is that the correctness of the system depends on reliable change notifications, which prompt the invalidation of the media's cache. A media removal notification is one example, a per-file change notification is another. In many systems, such reliable change notifications may be available. In cases where they are not, whether it is because the media doesn't support a removal notice or the file system doesn't support the necessary per-file changes, or in general if the file system is not trusted, the fall back is the “recomputed on every run” alternative described above where the ID is not cached and is recomputed each time. In general the “recomputed on every run” alternative will be slower, but may be preferred in cases where reliable change notifications are not available.
  • FIG. 6B is a flow diagram illustrative of a routine 600B for invalidating a removable media's cache. As shown in FIG. 6B, at a block 670, a notification of media removal (or change notification in some file systems) or reboot is received. At a block 680, the media's cache is invalidated.
  • FIG. 7 is a flow diagram illustrative of a routine 700 for associating identities with objects on a network volume system. At a block 710, an object and ID are copied. In another embodiment, only the object may be copied at the block 710, however the copying of both the object and ID provides more of an atomic mechanism, and the ID is not used until a determination is made that the object and ID were not changed, as will be described in more detail below with respect to block 740. At a decision block 720, a determination is made as to whether the system is trusted. If the system is not trusted, then the routine continues to a block 760, where the identity is computed. If the system is trusted, then the routine continues to a decision block 730. At decision block 730, a determination is made as to whether the object is trusted. If the object is not trusted, then the routine continues to the block 760 where the identity is computed. If the object is trusted, then the routine continues to a decision block 740. At decision block 740, a determination is made as to whether the object was changed during the copying. If the object and ID were changed, then the routine continues to block 760 where the identity is computed. If the object and ID were not changed during the copying, then the routine continues to a block 750, where the identity is obtained from the trusted system. In some embodiments, an ID might not be present, in which case the system may also make a determination prior to block 750 whether an ID was provided, and if an ID was provided, then at block 750 the ID is used, while if an ID was not provided, then the routine would continue to block 760.
  • With regard to the routine 700 for network volumes, it will be appreciated that in one embodiment a local copy does not need to be made for all network volumes. Instead, a local copy is only made for untrusted network volumes. If the remote machine is trusted, and if the remote machine is able to send reliable change notifications, then the system doesn't have to fall back to copying it locally and recomputing the identification every time. Instead, it may be treated like a file on a trusted local volume.
  • FIG. 8 is a flow diagram illustrative of a routine 800 for associating identities with objects in a multi-boot system. At a block 810, the tagging system stores a unique identifier denoting the current executing operating system to uniquely denote which operating system is identified and the associated data for the object. At a block 820, when the system accesses the stored data, the currently executing operating system identification gets checked against the stored operating system identification with the data, and if there is a mismatch of the operating system's identifications, then the system invalidates the stored identity and data and reevaluates/verifies the object's identity and stores the current data along with the current operating system identification.
  • While the preferred embodiment of the invention has been illustrated and described, it will be appreciated that various changes can be made therein without departing from the spirit and scope of the invention.

Claims (20)

1. A method for identity decisions, comprising:
registering to receive change notifications; and
upon receiving a change notification, invalidating the identity that is cached for an object.
2. The method of claim 1, wherein modifications to an object which can trigger change notifications comprise one or more of writes, renames, truncations, moves, or deletions.
3. The method of claim 1, wherein after the identity is invalidated, the identity is recomputed.
4. The method of claim 1, wherein if a modification to an object which triggered a change notification is determined to be authorized, then the privileges associated with the object are persisted.
5. The method of claim 1, wherein for a removable media, if the system does not support media-removed change notifications, then the object is copied locally and the identity is computed on the local copy.
6. The method of claim 1, wherein for a network volume, if the network volume is not trusted then the object is copied locally.
7. The method of claim 1, wherein for a multi-boot system, an identification for the current executing operating system is stored and when the system accesses the stored data for the object, the currently executing operating system identification is checked against the stored operating system identification, and if there is a mismatch of operating system identifications, then the stored identity for the object is invalidated.
8. A system for identity decisions, comprising:
a cache for caching identities for objects; and
an invalidation engine for invalidating identities cached for objects when modifications are detected to the objects.
9. The system of claim 8, wherein the cache receives metadata from metadata providers.
10. The system of claim 9, wherein the system further comprises an identity engine which generates identities.
11. The system of claim 10, wherein the system further comprises decision makers which receive information regarding objects and identities from the identity engine and which provide information regarding the identities to the cache and which retrieve metadata from the cache.
12. The system of claim 11, wherein the system maintains a per-identity table which associates providers with sequence numbers and decision metadata.
13. The system of claim 12, wherein the system maintains a global current sequence number table which associates providers with current sequence numbers.
14. The system of claim 13, wherein in order to obtain valid decision metadata for an identity, a provider's metadata sequence number is obtained from the per-identity table and is compared with the current sequence number for the provider from the global table, and if the sequence numbers do not match, the provider is invoked to generate current metadata for the identity.
15. One or more computer-readable media for enabling a computer program segment to perform identity decisions, said media comprising:
a set of computer-usable instructions to invalidate an identity cached for an object when a modification is detected to the object.
16. The media of claim 15, wherein modifications to the object may comprise one or more of writes, renames, truncations, moves, or deletions.
17. The media of claim 15, wherein after the identity is invalidated, the identity is recomputed.
18. The media of claim 15, wherein for a removable media, if the system does not support media-removed change notifications, then the object is copied locally, and the identity is computed on the local copy.
19. The media of claim 15, wherein for a network volume, if the network volume is not trusted then the object is copied locally.
20. The media of claim 15, wherein for a multi-boot system, the current executing operating system's identification is stored, and when the system accesses the stored data for the object, the currently executing operating system identification is checked against the stored operating system identification, and if there is a mismatch, then the system invalidates the stored identity for the object.
US11/087,222 2005-03-22 2005-03-22 System and method for identity decisions and invalidation Active 2027-02-01 US7756841B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/087,222 US7756841B2 (en) 2005-03-22 2005-03-22 System and method for identity decisions and invalidation

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US11/087,222 US7756841B2 (en) 2005-03-22 2005-03-22 System and method for identity decisions and invalidation

Publications (2)

Publication Number Publication Date
US20060218389A1 true US20060218389A1 (en) 2006-09-28
US7756841B2 US7756841B2 (en) 2010-07-13

Family

ID=37036571

Family Applications (1)

Application Number Title Priority Date Filing Date
US11/087,222 Active 2027-02-01 US7756841B2 (en) 2005-03-22 2005-03-22 System and method for identity decisions and invalidation

Country Status (1)

Country Link
US (1) US7756841B2 (en)

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100122020A1 (en) * 2008-11-13 2010-05-13 Gridlron Systems, Inc. Dynamic performance virtualization for disk access
US20100125857A1 (en) * 2008-11-17 2010-05-20 Gridlron Systems, Inc. Cluster control protocol
US8402246B1 (en) 2009-08-28 2013-03-19 Violin Memory, Inc. Alignment adjustment in a tiered storage system
US8402198B1 (en) 2009-06-03 2013-03-19 Violin Memory, Inc. Mapping engine for a storage device
US8417871B1 (en) 2009-04-17 2013-04-09 Violin Memory Inc. System for increasing storage media performance
US8417895B1 (en) * 2008-09-30 2013-04-09 Violin Memory Inc. System for maintaining coherency during offline changes to storage media
US8443150B1 (en) 2008-11-04 2013-05-14 Violin Memory Inc. Efficient reloading of data into cache resource
US8442059B1 (en) 2008-09-30 2013-05-14 Gridiron Systems, Inc. Storage proxy with virtual ports configuration
US8635416B1 (en) 2011-03-02 2014-01-21 Violin Memory Inc. Apparatus, method and system for using shadow drives for alternative drive commands
US8667366B1 (en) 2009-04-17 2014-03-04 Violin Memory, Inc. Efficient use of physical address space for data overflow and validation
US8713252B1 (en) 2009-05-06 2014-04-29 Violin Memory, Inc. Transactional consistency scheme
US8775741B1 (en) 2009-01-13 2014-07-08 Violin Memory Inc. Using temporal access patterns for determining prefetch suitability
US8788758B1 (en) 2008-11-04 2014-07-22 Violin Memory Inc Least profitability used caching scheme
US8832384B1 (en) 2010-07-29 2014-09-09 Violin Memory, Inc. Reassembling abstracted memory accesses for prefetching
US8959288B1 (en) 2010-07-29 2015-02-17 Violin Memory, Inc. Identifying invalid cache data
US8972689B1 (en) 2011-02-02 2015-03-03 Violin Memory, Inc. Apparatus, method and system for using real-time performance feedback for modeling and improving access to solid state media
US9069676B2 (en) 2009-06-03 2015-06-30 Violin Memory, Inc. Mapping engine for a storage device

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9098730B2 (en) * 2010-01-28 2015-08-04 Bdo Usa, Llp System and method for preserving electronically stored information

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040001568A1 (en) * 2002-06-03 2004-01-01 Lockheed Martin Corporation System and method for detecting alteration of objects
US20040117386A1 (en) * 2002-12-12 2004-06-17 Sun Microsystems, Inc. Syncronization facility for information domains employing dissimilar protective transformations
US20050108191A1 (en) * 2003-11-17 2005-05-19 Iyengar Arun K. System and method for achieving deferred invalidation consistency
US20050120181A1 (en) * 2003-12-02 2005-06-02 Oracle International Corporation Invalidating cached data using secondary keys
US7124249B1 (en) * 2003-06-26 2006-10-17 Emc Corporation Method and apparatus for implementing a software cache

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050091535A1 (en) 2003-10-24 2005-04-28 Microsoft Corporation Application identity for software products

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040001568A1 (en) * 2002-06-03 2004-01-01 Lockheed Martin Corporation System and method for detecting alteration of objects
US20040117386A1 (en) * 2002-12-12 2004-06-17 Sun Microsystems, Inc. Syncronization facility for information domains employing dissimilar protective transformations
US7124249B1 (en) * 2003-06-26 2006-10-17 Emc Corporation Method and apparatus for implementing a software cache
US20050108191A1 (en) * 2003-11-17 2005-05-19 Iyengar Arun K. System and method for achieving deferred invalidation consistency
US20050120181A1 (en) * 2003-12-02 2005-06-02 Oracle International Corporation Invalidating cached data using secondary keys

Cited By (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8417895B1 (en) * 2008-09-30 2013-04-09 Violin Memory Inc. System for maintaining coherency during offline changes to storage media
US8442059B1 (en) 2008-09-30 2013-05-14 Gridiron Systems, Inc. Storage proxy with virtual ports configuration
US8830836B1 (en) 2008-09-30 2014-09-09 Violin Memory, Inc. Storage proxy with virtual ports configuration
US8443150B1 (en) 2008-11-04 2013-05-14 Violin Memory Inc. Efficient reloading of data into cache resource
US8788758B1 (en) 2008-11-04 2014-07-22 Violin Memory Inc Least profitability used caching scheme
US20100122020A1 (en) * 2008-11-13 2010-05-13 Gridlron Systems, Inc. Dynamic performance virtualization for disk access
US8285961B2 (en) 2008-11-13 2012-10-09 Grid Iron Systems, Inc. Dynamic performance virtualization for disk access
US20100125857A1 (en) * 2008-11-17 2010-05-20 Gridlron Systems, Inc. Cluster control protocol
US8838850B2 (en) 2008-11-17 2014-09-16 Violin Memory, Inc. Cluster control protocol
US8775741B1 (en) 2009-01-13 2014-07-08 Violin Memory Inc. Using temporal access patterns for determining prefetch suitability
US8650362B2 (en) 2009-04-17 2014-02-11 Violin Memory Inc. System for increasing utilization of storage media
US8417871B1 (en) 2009-04-17 2013-04-09 Violin Memory Inc. System for increasing storage media performance
US8667366B1 (en) 2009-04-17 2014-03-04 Violin Memory, Inc. Efficient use of physical address space for data overflow and validation
US9424180B2 (en) 2009-04-17 2016-08-23 Violin Memory Inc. System for increasing utilization of storage media
US8713252B1 (en) 2009-05-06 2014-04-29 Violin Memory, Inc. Transactional consistency scheme
US9069676B2 (en) 2009-06-03 2015-06-30 Violin Memory, Inc. Mapping engine for a storage device
US8402198B1 (en) 2009-06-03 2013-03-19 Violin Memory, Inc. Mapping engine for a storage device
US8402246B1 (en) 2009-08-28 2013-03-19 Violin Memory, Inc. Alignment adjustment in a tiered storage system
US8959288B1 (en) 2010-07-29 2015-02-17 Violin Memory, Inc. Identifying invalid cache data
US8832384B1 (en) 2010-07-29 2014-09-09 Violin Memory, Inc. Reassembling abstracted memory accesses for prefetching
US8972689B1 (en) 2011-02-02 2015-03-03 Violin Memory, Inc. Apparatus, method and system for using real-time performance feedback for modeling and improving access to solid state media
US8635416B1 (en) 2011-03-02 2014-01-21 Violin Memory Inc. Apparatus, method and system for using shadow drives for alternative drive commands
US9195407B2 (en) 2011-03-02 2015-11-24 Violin Memory Inc. Apparatus, method and system for using shadow drives for alternative drive commands

Also Published As

Publication number Publication date
US7756841B2 (en) 2010-07-13

Similar Documents

Publication Publication Date Title
US10530754B2 (en) Publicly readable blockchain registry of personally identifiable information breaches
US9639697B2 (en) Method and apparatus for retroactively detecting malicious or otherwise undesirable software
US9535855B2 (en) Reorganization of virtualized computer programs
US9652614B2 (en) Application reputation service
EP3028489B1 (en) Centralized selective application approval for mobile devices
US9396326B2 (en) User transparent virtualization method for protecting computer programs and data from hostile code
US20170308700A1 (en) Method and apparatus for retroactively detecting malicious or otherwise undesirable software as well as clean software through intelligent rescanning
Jiang et al. Detecting passive content leaks and pollution in android applications
US8966312B1 (en) System and methods for run time detection and correction of memory corruption
US9392016B2 (en) System and method for below-operating system regulation and control of self-modifying code
JP5941872B2 (en) Systems and methods for authentication, data transfer and phishing protection
US8959577B2 (en) Automatic curation and modification of virtualized computer programs
JP5403771B2 (en) System and method for providing secure updates to firmware
US9455955B2 (en) Customizable storage controller with integrated F+ storage firewall protection
US9256552B2 (en) Selective access to executable memory
US9996693B2 (en) Automated malware signature generation
US10063572B2 (en) Antivirus signature distribution with distributed ledger
US9384349B2 (en) Negative light-weight rules
US9660990B2 (en) Temporarily providing higher privileges for computing system to user identifier
JP6332970B2 (en) System and method for secure software update
CN104335220B (en) For preventing and detecting the method and system of security threat
US9652632B2 (en) Method and system for repairing file at user terminal
KR101804996B1 (en) Centralized operation management
US8661541B2 (en) Detecting user-mode rootkits
US9400886B1 (en) System and method for using snapshots for rootkit detection

Legal Events

Date Code Title Description
AS Assignment

Owner name: MICROSOFT CORPORATION, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LI, ERIC;RECTOR, JOHN;FERNANDES, GENEVIEVE;AND OTHERS;REEL/FRAME:015932/0866

Effective date: 20050321

STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

AS Assignment

Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034543/0001

Effective date: 20141014

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552)

Year of fee payment: 8