Source: https://patents.google.com/patent/CA2640804C/en
Timestamp: 2020-01-22 08:43:09
Document Index: 486191364

Matched Legal Cases: ['art 500', 'art 550', 'art 600', 'art 700', 'art 800', 'art 900', 'art 1000', 'art 1100']

CA2640804C - Method and system for integrated securing and managing of virtual machines and virtual appliances - Google Patents
CA2640804C
CA2640804C CA 2640804 CA2640804A CA2640804C CA 2640804 C CA2640804 C CA 2640804C CA 2640804 CA2640804 CA 2640804 CA 2640804 A CA2640804 A CA 2640804A CA 2640804 C CA2640804 C CA 2640804C
CA 2640804
CA2640804A1 (en
2007-10-07 Priority to US97812107P priority Critical
2007-10-07 Priority to US60/978,121 priority
2008-10-07 Application filed by Embotics Corp filed Critical Embotics Corp
2009-04-07 Publication of CA2640804A1 publication Critical patent/CA2640804A1/en
2015-04-07 Publication of CA2640804C publication Critical patent/CA2640804C/en
Method and system for the integrated securing and managing of virtual machines and virtual appliances are presented. Attaching Delta file, sealing the virtual appliance at the computer of a sender, verifying authenticity of the sender at a recipient computer and managing the execution of the VA are performed in a seamless fashion.
METHOD AND SYSTEM FOR INTEGRATED SECURING AND MANAGING OF
Some computer operators, including software vendors, who are interested in simplifying the delivery, control, supportability, security and the tuning of their applications to work in a virtualized environment have created a purpose-built VM containing a preferred Operating System (OS) and their application(s), and configured the virtual machine to the most optimal settings for their needs. At the same time they can choose to restrict how their application(s) and OS are accessed by disabling specific ports and OS
utilities, even disabling command line login. This type of virtual machine has been named a virtual appliance.
Certain of these issues have been solved in the software industry for other types of objects. Web servers, especially for online banking or e-commerce, have been exchanging digital certificates to secure communications. These digital certificates allow the user to know that he/she is communicating with the correct entity. Digital certificates are controlled by a central authority and are given out only when sufficient proof has been provided by the potential digital certificate owner. The digital certificates also provide access to a "public key", which is one of two keys used in asymmetric cryptography to secure communications. The private key is held by the web server (the online banking institution or e-commerce site). This is an oversimplification of the technology, but each side uses its half of the key to encrypt outgoing information and decrypt incoming data ensuring a secure session.
In spite of existing software solutions, there is an existing need in the industry for the development of an improved and effective method and system for managing and securing VMs, including tracking and controlling of VMs, SUMMARY OF THE INVENTION
Accordingly, there is an object of the present invention to provide a method and system for achieving a secure and manageable virtualization environment capable of supporting secure virtual machines and, in turn, secure virtual appliances (VAs). The proposed Delta file is very much beneficial as then the recipient of the VAs would be able to see the original file together with the changes that have been made to the VAs at a sender's computer.
According to one aspect of the invention, there is provided a method for the integrated securing and managing a virtual appliance (VA), comprising an operating system and software applications, the method comprising the steps of: (a) attaching a Delta file to the VA, the Delta file including changes made to the VA on a sender computer;
(b) sealing the VA at the sender computer after the step (a), including attaching to the VA a signature of a sender and policies governing usage of the VA to generate a sealed VA;
(c) verifying authenticity of the sender upon receiving the sealed VA at a recipient computer; and (d) managing execution of the VA on the recipient computer in accordance with the policies; whereby preserving the integrity of the VA and protecting the VA from unauthorized use.
The step (b) further comprises: (b-1) creating a signature uniquely identifying the sender; (b-2) creating policies for managing ownership of the VA; (b-3) creating policies for managing operations performed by the VA; and (b-4) producing the sealed VA
by attaching the signature and the policies generated in the steps (b-1), (b-2) and (b-3) to the VA, and delivering the sealed VA to a recipient to be received at the recipient computer.
The step (b-1) further comprises: (b-1-1) using cryptographic keys, comprising a private key and a public key, at both the sender and the recipient; (b-1-2) determining a hash of contents of a file containing the VA; and (b-1-3) encrypting the hash with the private key of the recipient. The method further comprises the step of (b-1-4) encrypting the sealed VA for providing further security. The step of encrypting further comprises: (b-1-4-1) using a one-time symmetric key for performing symmetric cryptography in securing the sealed VA; (b-1-4-2) encrypting the sealed VA with the one-time symmetric key;
and (b-1-4-3) encrypting the one-time symmetric key with the public key of the recipient.
The step (c) further comprises: (c-1) verifying the signature uniquely identifying the sender by using the public key of the sender; (c-2) retrieving the hash generated in the step (b-1-2); (c-3) determining a hash of contents of the file containing the VA at the recipient computer; and (c-4) comparing the hash determined in the step (c-3) with the hash retrieved in step (c-2) for verifying an identity of the sender. The method further comprising the following steps, the steps being performed before the step (c-1): (c-0-1) decrypting the one-time symmetric key with the private key of the recipient;
and (c-O-2) decrypting the sealed VA using the one-time symmetric key obtained in step (c-0-1).
Step (d) further comprises: (d-1) loading the VA at the recipient computer;
and (d-2) using the VA in accordance with the policies created in the steps (b-2) and (b-3). The method further comprises the step of applying the changes in the Delta file to the VA, the step being performed after the step (d-1). The (d-1) further comprises: (d-1-1) verifying accessibility of files containing the operating system and the software applications; (d-1-2) loading contents of the files on the recipient computer;
and (d-1-3) creating a new Delta file for recording changes made to the VA on the recipient computer.
The step (d-2) further comprises: (d-2-1) executing the software applications in the VA
in one of the following modes: (d-2-1i) read-only mode when no changes are allowed to be made to the VA on the recipient computer; or (d-2-iii) read and write mode when changes are allowed to be made to the VA on the recipient computer; and (d-2-2) recording changes made in the new Delta file during the executing of the step (d-2-1);
(d-2-3) generating a signature of the recipient; (d-2-4) saving the VA; and (d-2-5) sealing the VA at the recipient computer including attaching the signature, the policies and the new Delta file to the VA.
According to another aspect of the invention, there is provided a system for securing a virtual appliance (VA), comprising an operating system and software applications, the system comprising: a processor and a non-transitory computer readable storage medium, storing computer executable instructions to be executed by the processor, to form the following modules: (e) a Delta file handler module, recording changes made to the VA on a sender computer and generating a Delta file, including said changes, (f) a sealing module, attaching to the VA a signature of a sender and policies, governing usage of the VA, to generate a sealed VA at the sender computer; (g) a security enforcement module, verifying authenticity of the sender upon receiving the sealed VA
at a recipient computer; (h) an execution management module, managing execution of the VA on the recipient computer in accordance with the policies; and (i) metadata module, including metadata, comprising resource requirement data and runtime data for the VA.
The sealing module (f) further comprises: (f-1) a security provisioning module, creating a signature uniquely identifying the sender; (f-2) a policy generation module, creating policies for managing ownership of the VA; and (f-3) a delivery module, producing the sealed VA, including attaching the signature and the policies to the VA, and delivering the sealed VA to a recipient.
The security provisioning module (f-1) further comprises: (f-1-1) a hash generation module, creating a hash of contents of a file containing the VA; and (f-1-2) a signature generation module, encrypting the hash with a private key of the recipient.
The signature generation module (f-1-2) further comprises a symmetric encryption module, encrypting the sealed VA with a one-time symmetric key, and encrypting the one-time symmetric key with a public key of the recipient, thereby providing further security.
The security enforcement module (g) further comprises: (g-1) a signature verification module, verifying the signature; and (g-2) a hash verification module, determining a hash of contents of the file containing the VA at the recipient computer and comparing with the hash generated by the hash generation module (f-1-1). The signature verification module further comprises (g-1-1) a symmetric decryption module, decrypting the sealed VA generated by the symmetric encryption module. The execution management module (h) further comprises a policy enforcement module, using the VA in accordance with the policies.
The execution management module further comprises a second Delta file handler module, recording changes made to the VA on the recipient computer and generating a new Delta file, including said changes. The policy enforcement module further comprises a rules engine, processing rules describing policies for managing ownership of the VA and policies for managing operations performed by the VA using the metadata of the step (g).
According to another aspect of the invention, there is provided a non-transitory computer readable storage medium, having a computer readable instructions stored thereon for execution by a processor causing the processor to perform the following: (j) attach a Delta file to a virtual appliance (VA), the Delta file including changes made to the VA on a sender computer, (k) sealing the VA at the sender computer, including attaching to the VA a signature of a sender and policies governing usage of the VA to generate a sealed VA, (I) verify authenticity of the sender upon receiving the sealed VA
at a recipient computer and (m) manage execution of the VA on the recipient computer in accordance with the policies, thereby preserving the integrity of the VA
and protecting the VA from unauthorized use.
According to another aspect of the invention, there is provided a system for integrated securing and managing a virtual appliance (VA) comprising an operating system and software applications, the system comprising: a processor; a non-transitory computer readable storage medium, storing computer executable instructions for execution by the processor, causing the processor to: attach a Delta file to the VA, the Delta file including changes made to the VA on a sender computer; seal the VA at the sender computer after attaching the Delta file, including attaching to the VA a signature of a sender and policies governing usage of the VA to generate a sealed VA; verify authenticity of the sender upon receiving the sealed VA at a recipient computer; and manage execution of the VA on the recipient computer in accordance with the policies.
The computer readable instructions in the system further cause the processor to: load the VA at the recipient computer; and create policies for managing ownership of the VA
and operations performed by the VA. The computer readable instructions may further cause the processor to apply the changes in the Delta file to the VA after the VA has been loaded at the recipient computer. The computer readable instructions may further cause the processor to: verify accessibility of files containing the operating system and the software applications; load contents of the files on the recipient computer; and create a new Delta file for recording changes made to the VA on the recipient computer.
According to another aspect of the invention, there is provided a secured virtual machine apparatus, comprising: at least one hardware processor; and at least one hardware memory device, having computer readable instructions stored thereon for execution by the at least one hardware processor, forming: a virtual machine, comprising a virtual hard disk, containing an operating system and software applications running on the virtual hard disk; and a security and management module, comprising: a Delta module, recording changes made to the virtual machine on a sender computer; a sealing module, sealing with the virtual machine after recording the changes, a signature of a sender, and policies governing ownership and execution of the virtual machine, to generate a secured virtual machine at a sender computer; a security enforcement module, verifying authenticity of the sender upon receiving the secured virtual machine at a recipient computer; and an execution management module, retrieving the virtual machine and the policies from the secured virtual machine, and managing the execution of the virtual machine on the recipient computer in accordance with the policies. The sealing module in the secured virtual machine apparatus may be further configured to seal the changes together with the virtual machine, the signature and the policies to generate the secured virtual machine. The computer readable instructions herein further may form yet another module, for recording changes made to the virtual machine on the recipient computer. The computer readable instructions herein may further form a metadata module, comprising metadata related to resource requirement data and runtime data for the virtual machine. The execution management module herein may further comprise a rules engine and processing rules describing the policies. The computer readable instructions in the secured virtual machine apparatus may further form an encryption module for encrypting the secured virtual machine at the sender computer, and a decryption module, decrypting the secured virtual machine at the recipient computer.
The sealing module may further comprise: a hash generation module, creating a hash of contents of a file containing the virtual machine; and a signature generation module, encrypting the hash with a private key of the recipient. The signature generation module may further comprise an encryption module, encrypting the secured virtual machine with a key, and further encrypting the key with a public key of the recipient.
The security enforcement module may further comprise: a signature verification module, verifying the signature of the sender; and a hash verification module, determining a hash of contents of the file containing the virtual machine at the recipient computer, and comparing the hash of contents of the file containing the virtual machine at the recipient computer with a hash of contents of a file containing the virtual machine at the sender computer.
According to another aspect of the invention, there is provided a computer system, comprising: a hardware platform, comprising at least one central processing unit, and at least one memory device; the at least one hardware memory device, having computer readable instructions stored thereon for execution by the at least one central processing unit, forming: a hypervisor having a virtual machine manager, managing one or more virtual machines, each virtual machine, comprising a virtual hard disk, containing an operating system and software applications running on the virtual hard disk;
at least one of the virtual machines being configured as a secured virtual machine by causing the at least one central processing unit to: to generate a secured virtual machine at a sender computer, including sealing with a virtual machine, a signature of a sender, and policies governing ownership and execution of the virtual machine; verify authenticity of the sender upon receiving the secured virtual machine at a recipient computer;
and retrieve, from the secured virtual machine, the virtual machine and the policies, and manage the execution of the virtual machine on the recipient computer in accordance with the policies; wherein the computer readable instructions further cause the at least one central processing unit to record changes made to the virtual machine on the sender computer before the virtual machine has been sealed, and to seal the changes together with the virtual machine, the signature and the policies to generate the secured virtual machine. The computer readable instructions in the computer system may further cause the at least one central processing unit to record changes made to the virtual machine on the recipient computer. The computer readable instructions may further cause the at least one central processing unit to encrypt the secured virtual machine at the sender computer, and to decrypt the encrypted secured virtual machine at the recipient computer. The computer readable instructions may further cause the at least one central processing unit to: create a hash of contents of a file containing the virtual machine; and encrypt the hash with a private key of the recipient. The computer readable instructions may further cause the at least one central processing unit to encrypt the secured virtual machine with a key, and further encrypt the key with a public key of the recipient. The computer readable instructions may further cause the at least one central processing unit to: verify the signature of the sender; and determine a hash of contents of the file containing the virtual machine at the recipient computer, and comparing the hash of contents of the file containing the virtual machine at the recipient computer with a hash of contents of a file containing the virtual machine at the sender computer. The computer readable instructions may further cause the at least one central processing unit to form a rules engine, processing rules describing the policies.
The computer readable instructions may further form a metadata module, comprising metadata related to resource requirement data and runtime data for the virtual machine.
According to another aspect of the invention, there is provided a system for generating a secured virtual machine, the system comprising: a sender computer, comprising: a first processor; and a first memory device, having computer readable instructions stored thereon for execution by the first processor, causing the first processor to generate the secured virtual machine, comprising recording changes made to a virtual machine, sealing with the virtual machine a signature of a sender, policies governing ownership and execution of the virtual machine and the changes made to the virtual machine; and a recipient computer, comprising:
a second processor; and a second memory device, having computer readable instructions stored thereon for execution by the second processor, causing the second processor to:
verify authenticity of the sender upon receiving the secured virtual machine at a recipient computer; and retrieve the virtual machine and the policies from the secured virtual machine, and manage the execution of the virtual machine on the recipient computer in accordance with the policies.
Figure 1(a) schematically illustrates a secured VA of the embodiment of the present invention, which is securely wrapped in a software container comprising security and policy modules;
Figure 1 (b) schematically illustrates the secured VA of Figure 1(a), which is further securely wrapped with a Delta file stored externally and applied at runtime;
Figure 2 shows the functional components of the security and management unit of Figures 1(a) and 1(b);
Figure 3 schematically shows a computer system for securing and managing virtual machines, including the security and management unit of Figure 2:
Figure 4 illustrates a secure VA with its corresponding Delta files;
Figure 5(a) shows a flowchart illustrating the steps of the method for managing and securing virtual appliances executed at a sending computer;
Figure 5(b) shows a flowchart illustrating the steps of the method for managing and securing virtual appliances executed at a recipient computer;
Figure 6 shows a flowchart illustrating the step 504 "Perform Sealing of VA"
of Figure 5(a);
Figure 7 shows a flowchart illustrating the step 556 "Perform Verification of VA" of Figure 5(b);
Figure 8 shows a flowchart illustrating the step 558 "Execute VA" of Figure 5(b);
Figure 9 shows a flowchart illustrating the step 810 "Use VA" of Figure 8;
Figure 10 shows a flowchart illustrating the step of the method "Start VA";
Figure 11 shows a flowchart illustrating the step of the method "Stop VA"; and Figure 12 illustrates change management for secure virtual machines.
Figure 1(a) illustrates a secured virtual machine 10, or a VA, of the embodiment of the present invention, comprising a virtual hard disk 14 containing the Operating System (OS) and Applications 12 associated with the VA, and including other Virtual Machine Disk (VMDK) format or Virtual Hard Disk (VHD) format information, wrapped in a software container 16 along with a Security and Management unit 15. The Security and Management unit 15 performs the steps of the method of the embodiment of the present invention, and ensures security and integrity of the VA 10 as it is delivered from a sending computer by a sender to a recipient who executes the VA 10 on a recipient computer. The steps of securing a VA and managing its execution are combined in a seamless way.
The Security and Management unit 15 generates a sealed VA 10. It ensures that the VA 10 is "signed" by the sender or vendor using a certificate from a recognized Certificate Authority, so that each recipient of the VA 10 (customer/end-user) that uses this package knows that it has retrieved the package from a trusted reputable source and that the package has not been compromised. The Security and Management unit 15 also provides for the VA 10 as will be described in detail later in this document.
A virtual appliance is dynamic by nature. Each time the VA 10 is opened/run, the VA 10 may be modified by the operating system and the applications 12 within them.
To protect the original VA, an additional technology, providing the ability to record these changes in a Delta file 20, has been used in the embodiment of the present invention. It is schematically illustrated in Figure 1(b), where the Delta file 20 has been created, comprising of a Delta - OS and Applications file 20a for the OS that is contained within Delta-virtual hard disk 20b corresponding to the VA. The Delta file 20 is a file that contains only the differences between the original VA 10 and the current running state of the VA 10 within virtualization. Each time the VA 10 is started, the virtualization system loads the original VA 10 disk image, and then applies the Delta files 20 one after another in a progression based on dependencies until the complete image is loaded and then the OS and the application may start to run. There can be one or many Delta files 20 secured and stored with a VA. Only one Delta file 20, the content of which is updated with corresponding changes, is shown in Figure 1(b) for simplicity.
It is understood that multiple Delta files 20 may be created in association with the VM or VA, when the VA 10 is opened and used in succession by multiple recipients.
Accordingly, a new way to ensure rights management is required. The solution is provided by the Security and Management unit 15 of the embodiment of the present invention, which is associated with the VA 10 and wrapped in the software container 16 as illustrated in Figures 1(a) and 1(b) above. This unit is used at a sending computer used by the sender to seal the VA 10, thereby describing and providing security and integrity for the VA 10, and at a recipient computer used by a recipient of the sealed VA
for verifying authenticity of the sender, enforcing the security of a VA 10 and for managing the execution of the VA 10 at the recipient computer. The sealed VA
includes a signature of the sender, policies governing the usage of the VA 10 by the recipient and, potentially, one or many Delta file(s) 20 including the changes made to the original VA 10 if this has passed through a middleman. Both the sender and the recipient have keys including a private key and a public key that are used in the encryption of information associated with the VA.
A system 300 for securing and managing a virtual appliance (VA) of the embodiment of the invention will be described with regard to Figures 2 and 3 below. The system includes a general purpose or specialized computer having a CPU and a computer readable medium, e.g., memory. Alternatively, the system can be implemented in firmware, or combination of firmware and a specialized computer.
Various modules of the Security and Management unit 15 are discussed with the help of Figure 2. Please note that the Sealing module 202, the Security Provisioning module 204, the Hash Generation module 212, the Signature Generation module 214, the Symmetric Encryption module 216, the Policy Generation module 206, the First Delta Handler module 208, the Delivery Module 210, the Security Enforcement module 218, the Hash verification module 220, the Signature Verification module 222, the Symmetric Decryption module 224, the Execution Management module 226, the Policy Enforcement module 228, the Second Delta file handler module 232, the Rules engine module 230 include units comprising a firmware or alternatively a computer software code stored in a computer readable medium, comprising computer memory, DVD, CD-ROM, floppy or the like.
Security Provisioning module 204 provides security related services. This module in turn includes a Hash Generation module 212 for determining a hash of the contents of the file containing the VA 10 and a Signature Generation module that generates the signature for uniquely identifying the sender. The Signature Generation module optionally includes a Symmetric Encryption module 216 that is used for performing symmetric cryptography when further security is used by the sender.
1. Ownership: Is this VA 10 locked to a specific enterprise, user, system, timeframe, etc?
2. License: How many concurrent copies of a VA 10 can be run at the same time?
3. Transfer of ownership: Can this VA 10 be given to others to use? and 4. Uniqueness: Can this VA 10 be duplicated?
1. Automatically issue new licenses;
2. Deny access to shared folders outside of the VA;
3. Deny the ability to use clipboard techniques to copy information into or out of the VA; and 4. Deny console or KVM (keyboard-video-mouse) access to the VA.
Metadata module 234 contains metadata that is used by the various modules of the Security and Management unit 15 for providing the desired functionality.
Metadata includes instance data such as resource needs of the VA 10 and runtime data monitoring execution of the VA to discover excessive CPU usage, for example.
Metadata is typically stored on a computer readable medium, for example, random access memory.
The computer system 300, comprising a VA 10 of Figure 1(a) that has been secured with the help of the Security and Management unit, is described in more detail with the help of Figure 3. The computer system 300 includes a hypervisor 304 or a virtualization aware operating system that is responsible for abstracting the components of the physical hardware platform 301. These physical components include CPUs 301a, Memory 301b, Network Interfaces 301c and Storage 301d. Within the Storage component 301d, the image of the VMs (only one VM image 302 being shown for simplicity) exist as a series of files. Please note that the secure VM image 303 is the image obtained after sealing the VM image 302.
The Virtual Machine Manager (VMM) 305, on command to start a virtual machine from the virtual machine image 302 received from the Management Interface to Virtual Services 306, retrieves the files for the chosen VM image 302 from storage through the hypervisor 304, loads it and starts to run the code within as if the VM 302 was running an OS on the hard drive of a physical hardware platform. The OS within the VM
accesses the virtual CPU, Memory, NIC and Storage provided by the hypervisor 304 as if it was a physical box.
While authenticating the sealed VA 10, the Security and Management Unit 15 returns an "authorized r/o (read-only)" or "authorized r/w (read and write)" message.
A more detailed description of the method is provided later in this document. The difference between each message has to do with the signature on the secure VM image 303.
If a public key is needed/used to decrypt the VM (303), then the VM image (303) is put into a read-only state. A public key will be needed if the secure VM 303 came from an external source, i.e. this VMM was not the system that created this VM ¨ it has been signed with a public key of a third party. If a private key is used, it most likely means that the VM image 303 was created by the VMM 305 and therefore is alterable.
This process is schematically illustrated in Figure 4. In order to protect the integrity of the original VA 10, Delta files 20 are used to record changes made during a VM's execution. The example in Figure 4 shows a Secure VM 401 and two secure Delta files:
Delta1, 402 and Delta2, 403 contained in a Sealed VM 400. Delta1 402 is due to changes made to Secure VM 401 by a previous user when it was the sole component of Sealed VM 400. Together they were passed on to the company currently using the virtual machine and thus a public key for the previous user is necessary for decryption.
Delta2 403 is due to an employee in the current company, so the private key for the current user, device or company is to be used for decryption.
The first few steps of the method of the embodiment of the invention are executed at the sending computer for clarity and the rest of the steps are executed on a recipient computer although they can be all run at the same site. The steps of the method of the invention executed at the sending computer are explained with the help of the flowchart 500 illustrated in Figure 5(a). Upon start (box 502), procedure 500 performs the sealing operation for the VA 10 (box 504). The sealed VA 10 is then delivered to the recipient (box 506) and the procedure 500 exits (box 516).
The steps of the method of the invention executed at the recipient computer are explained with the help of the flowchart 550 illustrated in Figure 5(b). Upon start (box 552), the sealed VA 10 delivered from the sending computer is received at the recipient computer (box 554). The procedure 550 performs verification of the VA (box 556) next.
After the authenticity and the integrity of the VA are verified, the procedure proceeds to execute the VA and manage its execution (box 558) and exits (box 560).
The step "Perform sealing of VA" (box 504) of procedure 500 presented in Figure 5(a) is explained further with the help of flowchart 600 displayed in Figure 6.
Such an operation is typically performed, when a vendor has completed its virtual appliance, and plans to sell it into the trusted market. Before the steps of the method 600 displayed in Figure 6 are executed, the vendor acquires a digital certificate from a trusted certificate authority (CA) that verifies the vendor's identity. Upon Start (box 602), the Vendor creates a hash of the contents of the file containing the newly created VA 10 that is stored in a VMDK file for example (box 604). Then the vendor uses its private key to generate a signature for the VA 10 (box 606). This is achieved by encrypting the hash.
The "signature" is then attached to the hash of the VA 10 (box 608). Whether or not more security is required is checked next (box 610). If no further security is required the procedure 600 exits 'NO' from box 610, delivers the VA 10 to the recipient (box 612) and exits (box 618). If further security is required, the procedure 600 exits 'YES' from box 610. At this point another level of security is added by encrypting the entire VA 10 with a one-time symmetric key (box 614) and then the symmetric key is encrypted with the recipient's public key ensuring that only the recipient can open the VA 10 (616).
Next, the procedure 600 delivers the VA 10 to the recipient (box 612) and exits (box 618).
The step "Perform Verification of the VA" (box 556) of procedure 550 presented in Figure 5(b) is explained further with the help flowchart 700 presented in Figure 7. This operation is typically performed when a recipient has received a signed VA, and wants to verify its authenticity and integrity before use. Upon Start (box 702), a sealed VA 10 is received (box 704). The procedure 700 checks to see if extra security was used (box 706). If so, the procedure 700 exits 'YES' from box 706, and decrypts the one-time symmetric key using the recipient's private key (box 708). The signed VA 10 available in the form of a VMDK file for example, is then decrypted with the symmetric key (box 710). The procedure 700 authenticates the signature by using vendor's public key (box 712) and retrieves the hash for VA 10 (box 714). The procedure 700 determines the hash of the VA 10 (box 716) and compares the hash with the data retrieved in the previous step (box 718). If they do not match, the procedure exits 'NO' from box 718, generates an error message indicating that the integrity is compromised (box 720) and exits (box 722). If they match, the recipient can be assured that the VA 10 has not been compromised, and it can continue to execute the VA 10; thus, the procedure exits 'YES' from box 718, and exits (box 722). If no extra security was used the procedure exits 'NO' from box 706, and goes directly to the input of box 712.
The step "Execute VA and manage its execution" (box 558) of procedure 550 presented in Figure 5(b) is explained further with the help of flowchart 800 presented in Figure 8. Upon start (box 802), the procedure 800 verifies if this is first use of the VA
(box 804). If this is the first use, the procedure 800 exits 'YES' from box 804 and 5 creates a new Delta file 20 (box 806) to record the changes made to the VA
during execution on the recipient computer, keeping the original VA 10 intact. This is followed by allowing the Virtualization platform to load the VA 10 and apply the Delta files 20 (box 808). The procedure 800 then allows the user/recipient to use the VA 10 (box 810) and exits (box 812). If the VA 10 has been used before, the procedure 800 exits NO
10 from box 804, and goes directly to the entry of box 808.
The step "Use VA" (box 810) of Figure 8 is explained with the help of flowchart 900 presented in Figure 9. Upon start (box 902), the procedure 900 starts the VA
10 (box 904) upon receiving a start command. The desired operations on the VA 10 are performed next (box 906). After completing these operations the procedure 900 stops the VA 10 (box 908) upon receiving a stop command and exits (box 910).
The step "start VA" is explained with the help of flowchart 1000 presented in Figure 10.
Upon start (box 1002), procedure 1000 receives a command to start a VA 10 (box 1004) from the Management Interface to Virtual Services 306. Whether access to the file is all right is checked next (box 1006). If not, the procedure 1000 exits 'NO' from box 1006, generates an error message (box 1008) and exits (box 1030). Otherwise, the procedure 1000 exits 'YES' from box 1006 and checks whether or not the VA 10 to be started is a secure VA 10 (box 1010). If not, the procedure 1000 exits 'NO' from box 1010, proceeds to follow a traditional approach for starting the virtual appliance (box 1012) and exits (box 1030). Otherwise, the first file in the VA is examined (box 1014) and the procedure 1000 checks the authenticity and integrity of the file (box 1016). If the file fails the test, the procedure 1000 exits 'NO' from box 1016, generates an error message (box 1018) and exits (box 1030). Otherwise, the contents of the file are loaded into memory (box 1020) and whether or not this was the last file in the VA is checked (box 1022). If not, the procedure 1000 exits 'NO' from box 1022, examines the next file in the VA (box 1023) and loops back to the entry of box 1016.
Otherwise, the procedure 1000 checks the type of the last file (box 1024). For a file that the user is not authorized to use and the access to which is denied, the procedure 1000 exits `Access Denied/Not Authorized' from box 1024, generates an error message (box 1026) and exits (box 1030). For a read-only file type, the procedure 1000 exits `Authorized r/o' from box 1024, creates a new Delta file 20 (box 1028) for recording changes during execution of the VA on the recipient computer and exits (box 1030). For a read and write file type, a new Delta file 20 is not required and the procedure 1000 exits `Authorized r/w' from box 1024 and exits (box 1030).
The step "Stop VA" is explained with the help of flowchart 1100 displayed in Figure 11.
Upon start (box 1102) the procedure receives the command for stopping the VA
(box 1104) from the Management Interface to Virtual Services 306. The VA is then saved on the disk (box 1106) and the procedure 1100 checks whether or not this is a secure VA (box 1108). If not, the procedure 1100 exits 'NO' from box 1108, proceeds to follow the traditional approach for stopping the execution of the virtual appliance (box 1110) and exits (box 1114). Otherwise, the procedure 1100 exits `YES' from box 1108, signs and seals the VA image (box 1112) and exits (box 1114). In this way, if a new Delta file 20 was created it remains protected. Please note that protecting the new Delta file 20 is required when the owner requires additional security or the VA 10 is being shipped to another enterprise or back to the vendor for root cause analysis.
So, for clarity, let us walk through a few examples to illustrate the loading of a secure VM image 303, and saving a VM image to storage 301d. A new secure VM image 303 (we will refer to it in this text as "WebServer" for ease of reading), received from a third-party vendor, is deployed to a virtualization system and the command to start the "WebServer" is received by the VMM through the Management Interface to Virtual Services 306. The "WebServer" VM is signed by the sender with its private key.
The VMM 305 will request to load the secure VM image 303 through the Security and management unit 15. The Security and management unit verifies the authenticity and integrity of this secure VM image 303 and passes it as "authorized r/o". The loads the "WebServer" into memory, creates and associates a Delta file 20 and starts the "WebServer".
At this point, the secure VM image 303 operates in the same manner as an unsecured VM (e.g. VM image 302) with the ability to transform through normal operations or by patching. When the Management Interface to Virtual Services 306 passes the stop command across, VMM 305 needs to ensure that the secure VM image 303 is still secure ¨ along with its associated Delta files 20. The VMM 305 will request that the Security and Management unit 15 sign and seal the VM image 303 including all its associated Delta files 20 that are written to the disk.
The exact implementation of the Security and Management unit 15 within the architecture depends on the virtualization technology being used. As the requests are based on file accesses to load a secure VM image 303, it is simplest to implement it as a read-thru module between the VMM 305 and the physical storage device 301d, thereby abstracting the verification, encryption and decryption system from the VMM
Now that we have a secure VM image 303 and a method of using it, the rights are applied to the secure VM image 303. The "rights" being granted to the secure VM
image 303 are stored within a digital certificate, the same digital certificate that is used to verify the authenticity of the signature. Policies usually pertain to ownership issues ¨
how to limit the use in copying, running, transferring. These policies are applied to the secure VM image 303 as described above.
A secure VM image 303 can contain any operating system and any number of applications including applications that can hold sensitive systems. The digital certificate can contain metadata and policy information, in a standards-based policy description language, that is enforced at the Policy Enforcement module 228.
An integrated Policy Enforcement module and the Security Enforcement module 218 that are close to the VMM 305 ensure a seamless enforcement without gaps in security.
To present an example, an enterprise wants to ensure that the system 300 with its sensitive information is only loaded up on a specific virtualization host and only by specific individuals. Not only can the secure VM image 303 be secured with a certificate to lock it down to a specific system, but User Credentials can be specified as a requirement as well in the policy. So, in this example, the policy is set to require verification of a User Certificate for employee Bob. If Alice wanted to start this secure VM, the Security Enforcement module 218 would verify authenticity and integrity as described above, but then challenge the user for credentials. Unable to provide Bob's credentials, Alice is denied access to that secure VM image 303. Even if the secure VM
image 303 is removed from the enterprise by a malicious user, the certificates around the secure VM image 303 envelopes the sensitive data within the secure VM 703, keeping it encrypted for all but authorized users.
So now we have a secured VM image 303, and can apply regular authorization polices.
Virtualization offers some interesting capabilities that are applicable to VMs ¨ the ability to clone a VM, for instance, allows a copy of the VM to be created. A policy can be created to ensure that for each authorized VM, there is only one instance within the entire virtualization environment. This still leaves room for the movement of this VM
from one host to another or for disaster recovery scenarios while still keeping the usage to a single instance.
A policy could also be created to ensure that the configuration of the secure VM image 303 is limited in how it can be altered. For example, network interface cards (NICs) are virtualized and can be attached/detached and reattached at any time. A policy can ensure that only a set number of NICs are attached and that they cannot be detached or reconfigured. This would be presented either to trigger a violation at the Policy Enforcement module 228 that would correct the changes or as a denial of the action within the Management Interface to Virtual Services 306 ¨ the latter being the preferred method.
Now that the secure VM image 303, including its associated Delta files 20, is secured, and the rights applied to that VM are being enforced, chain of custody and change management will be considered. When a VA 10 is transferred from one owner/user to another, it is imperative that the chain of custody is maintained. The current owner/user must be able to authenticate and verify the integrity of each and every piece of a VA 10 ¨ the original package and each Delta file 20 that, based on rights and policies, is allowed to be transferred with the VA. This mechanism will present the pedigree of any particular VA 10 in the computer system.
A new series of rights can be applied to this VA 10 allowing or disallowing an end-user from using portions of the VA 10 without other portions. For example, an end-user can receive a VA 10 with a policy that allows the user to use the original VA 10 and the Delta files 20 so long as they are all applied and cannot revert to the original VA.
Another policy can be set to allow the user to use the VA 10 with or without applying the Delta files 20. This would allow the transference and use of the original VA
10 (rights permitting) as well as with the Delta files 20 applied depending on the needs of this end-user.
Change management is a hot topic these days and no less so that around virtual = machines and virtual appliances. When a sealed VA 10 is started for the first time, a Delta file 20 is created ensuring that no changes occur to the original VA, but are recorded within the Delta file 20. The Delta file 20 can be examined to present the differences between it and the original VA 10 presenting a list of changed items. To this end, Delta files 20 can be created throughout the lifecycle of a VA, especially when critical updates are applied to control and minimize the change applied to any particular Delta file 20. Other tools in virtualization can be used to combine the changes contained in Delta files 20 once the changes within each Delta files 20 are tested and considered approved.
What happens if the customer/user wants to take an original VA, add/modify the application or data held within the VA 10 (within the limits of rights policies) and then transfer this new VA 10 to another customer/end-user is discussed next. As with the original VA, each and every Delta file 20 can be signed as well offering assurances to the recipient that the Delta file 20 came from the originating party and that it has not been tampered with. This process is schematically illustrated in Figure 12.
Secure Delta1, 1202 is a Delta file 20 that came with original Secure VM 1201. When the user opens the sealed virtual appliance 1200 of Figure 12, a new Delta file 20, Secure Delta2, 1203 is created. If this Delta file 20 is to be protected, it would be done using private keys within the company that is operating on the virtual appliance 1200. Thus, when changes are being made to the secure VMs, they happen in the last Delta file 20 ¨ the one being used by the final user. Those changes can be tracked in real-time, if desired, but it is also necessary to track the changes that occurred to the previous components of the secure VM image 303, meaning the original VM and all Delta files 20 preceding the final Delta files 20.
Each raw file image is mounted to a forensics system in a read-only manner to gain access to the content in the virtual hard disk drive without tampering with the contents.
Then an application module makes a file list from the older raw file image including details on the file names, sizes, hashes, access times, last user id, etc and then creates a similar list for the newer raw file image. The differences between the two lists are then captured giving a first order view of the changed items that occurred on the newer image. For a more detailed comparison of the changed items, each file identified in the difference list can be compared "byte for byte" whether it is a text or binary file, and the differences can be collected.
For a sealed VM 10, Change Management is handled as described above. In particular, calling for the changed items would have the virtualization system mount the secure VM
image 303 (assuming that it was authorized by the Security Enforcement module) in a read-only state and the same VM with Delta files 20 applied up to the point of interest would also be mounted in a read-only state. At this point both file systems can be traversed to changes made at each Delta file 20 (like a checkpoint). As an enhancement, the changes can be attached to the digital certificate as a first order view to simplify retrieval by future users with the digital certificate protecting this first order view from tampering as well.
Thus, an integrated method and system for securing .and managing virtual appliances, = including tracking and controlling of VAs, have been provided.
For example, instead of sealing the VA 10 in its entirety, each and every file in the VA
can be sealed separately. For any object that was read-only, the file is already 5 signed and sealed on the storage device 301d. For any object that was marked as read-write, the Security and Management Unit 15 can calculate the hash of it and sign it with a private key thereby allowing each component to be stored in a secure manner. It may also be possible to group related virtual appliances and secure and manage the group as a single unit.
1 A method for integrated securing and managing a virtual appliance (VA) comprising an operating system and software applications, the method comprising:
(a) attaching a Delta file to the VA, the Delta file including changes made to the VA on a sender computer;
(c) verifying authenticity of the sender upon receiving the sealed VA at a recipient computer, and (d) managing execution of the VA on the recipient computer in accordance with the policies;
2 The method of claim 1, wherein the step (b) further comprises.
(b-1) creating a signature uniquely identifying the sender;
(b-2) creating policies for managing ownership of the VA, (b-3) creating policies for managing operations performed by the VA; and (b-4) producing the sealed VA by attaching the signature and the policies generated in the steps (b-1), (b-2) and (b-3) to the VA, and delivering the sealed VA to a recipient to be received at the recipient computer.
3. The method of claim 2, wherein the step (b-1) further comprises:
(b-1-1) using cryptographic keys, comprising a private key and a public key, at both the sender and the recipient;
(b-1-2) determining a hash of contents of a file containing the VA; and (b-1-3) encrypting the hash with the private key of the recipient.
4 The method as described in claim 3, further comprising (b-1-4) encrypting the sealed VA for providing further security.
5. The method of claim 4, wherein the encrypting further comprises:
(b-1-4-1) using a one-time symmetric key for performing symmetric cryptography in securing the sealed VA, (b-1-4-2) encrypting the sealed VA with the one-time symmetric key; and (b-1-4-3) encrypting the one-time symmetric key with the public key of the recipient.
6. The method of claim 5, wherein the step (c) further comprises:
(c-1) verifying the signature uniquely identifying the sender by using, the public key of the sender;
(c-2) retrieving the hash generated in the step (b-1-2);
(c-3) determining a hash of contents of the file containing the VA at the recipient computer; and (c-4) comparing the hash determined in the step (c-3) with the hash retrieved in step (c-2) for verifying an identity of the sender.
7. The method as described in claim 6, further comprising the following steps, the steps being performed before the step (c-1):
(c-0-1) decrypting the one-time symmetric key with the private key of the recipient; and (c-0-2) decrypting the sealed VA using the one-time symmetric key obtained in step (c-0-1).
8. The method of claim 1, wherein the step (d) further comprises:
(d-1) loading the VA at the recipient computer; and (d-2) using the VA in accordance with the policies created in the steps (b-2) and (b-3).
9. The method of claim 8, further comprising applying the changes in the Delta file to the VA, the step being performed after the step (d-1).
10. The method of claim 8, wherein the step (d-1) further comprises:
(d-1-1) verifying accessibility of files containing the operating system and the software applications;
(d-1-2) loading contents of the files on the recipient computer; and (d-1-3) creating a new Delta file for recording changes made to the VA on the recipient computer.
11 The method of claim 10, wherein the step (d-2) further comprises:
(d-2-1) executing the software applications in the VA in one of the following modes:
(d-2-l1) read-only mode when no changes are allowed to be made to the VA on the recipient computer, or (d-2-1ii) read and write mode when changes are allowed to be made to the VA on the recipient computer; and (d-2-2) recording changes made in the new Delta file during the executing of the step (d-2-1).
(d-2-3) generating a signature of the recipient;
(d-2-4) saving the VA; and (d-2-5) sealing the VA at the recipient computer including attaching the signature, the policies and the new Delta file to the VA.
13 A system for securing a virtual appliance (VA), comprising an operating system and software applications, the system comprising:
a processor and a non-transitory computer readable storage medium, storing computer executable instructions to be executed by the processor, forming.
(e) a Delta file handler module, recording changes made to the VA on a sender computer and generating a Delta file including said changes;
(f) a sealing module, attaching to the VA a signature of a sender and policies, governing usage of the VA, to generate a sealed VA at the sender computer;
(g) a security enforcement module, verifying authenticity of the sender upon receiving the sealed VA at a recipient computer;
(h) an execution management module, managing execution of the VA on the recipient computer in accordance with the policies; and (i) metadata module, including metadata, comprising resource requirement data and runtime data for the VA.
14. The system of claim 13, wherein the sealing module (1) further comprises:
(f-1) a security provisioning module, creating a signature uniquely identifying the sender, (f-2) a policy generation module, creating policies for managing ownership of the VA; and (f-3) a delivery module, producing the sealed VA, including attaching the signature and the policies to the VA, and delivering the sealed VA to a recipient.
15. The system of claim 14, wherein the security provisioning module (f-1) further comprises:
(f-1-1) a hash generation module, creating a hash of contents of a file containing the VA; and (f-1-2) a signature generation module, encrypting the hash with a private key of the recipient.
16. The system of claim 15, wherein the signature generation module (f-1-2) further comprises a symmetric encryption module, encrypting the sealed VA with a one-time symmetric key, and encrypting the one-time symmetric key with a public key of the recipient, thereby providing further security.
17. The system of claim 16, wherein the security enforcement module (g) further comprises:
(g-1) a signature verification module, verifying the signature; and (g-2) a hash verification module, determining a hash of contents of the file containing the VA at the recipient computer and comparing with the hash generated by the hash generation module (f-1-1).
18 The system of claim 17, wherein the signature verification module further comprises (g-1-1) a symmetric decryption module, decrypting the sealed VA generated by the symmetric encryption module.
19. The system of claim 13, wherein the execution management module (h) further comprises a policy enforcement module, using the VA in accordance with the policies.
20. The system of claim 19, wherein the execution management module further comprises a second Delta file handler module, recording changes made to the VA on the recipient computer and generating a new Delta file, including said changes.
21. The system of claim 19, wherein the policy enforcement module further comprises a rules engine, processing rules describing policies for managing ownership of the VA
and policies for managing operations performed by the VA using the metadata of the metadata module (i).
22. A non-transitory computer readable storage medium, having computer readable instructions stored thereon for execution by a processor causing the processor to perform the following:
(j) attach a Delta file to a virtual appliance (VA), the Delta file including changes made to the VA
on a sender computer;
(k) seal the VA at the sender computer, including attaching to the VA a signature of a sender and policies governing usage of the VA to generate a sealed VA;
(I) verify authenticity of the sender upon receiving the sealed VA at a recipient computer; and (m) manage execution of the VA on the recipient computer in accordance with the policies, thereby preserving the integrity of the VA and protecting the VA from unauthorized use.
23. A system for integrated securing and managing a virtual appliance (VA) comprising an operating system and software applications, the system comprising:
a non-transitory computer readable storage medium, storing computer executable instructions for execution by the processor, causing the processor to:
attach a Delta file to the VA, the Delta file including changes made to the VA
seal the VA at the sender computer after attaching the Delta file, including attaching to the VA a signature of a sender and policies governing usage of the VA to generate a sealed VA;
verify authenticity of the sender upon receiving the sealed VA at a recipient computer; and manage execution of the VA on the recipient computer in accordance with the policies.
load the VA at the recipient computer; and create policies for managing ownership of the VA and operations performed by the VA.
25. The system of claim 24, wherein the computer readable instructions further cause the processor to apply the changes in the Delta file to the VA after the VA has been loaded at the recipient computer.
26. The system of claim 24, wherein the computer readable instructions further cause the processor to:
verify accessibility of files containing the operating system and the software applications;
load contents of the files on the recipient computer; and create a new Delta file for recording changes made to the VA on the recipient computer.
27. A secured virtual machine apparatus, comprising:
at least one hardware processor; and at least one hardware memory device, having computer readable instructions stored thereon for execution by the at least one hardware processor, forming:
a virtual machine, comprising a virtual hard disk, containing an operating system and software applications running on the virtual hard disk; and a security and management module, comprising:
a Delta module, recording changes made to the virtual machine on a sender computer;
a sealing module, sealing with the virtual machine after recording the changes, a signature of a sender, and policies governing ownership and execution of the virtual machine, to generate a secured virtual machine at a sender computer;
a security enforcement module, verifying authenticity of the sender upon receiving the secured virtual machine at a recipient computer; and an execution management module, retrieving the virtual machine and the policies from the secured virtual machine, and managing the execution of the virtual machine on the recipient computer in accordance with the policies.
28. The secured virtual machine apparatus of claim 27, wherein the sealing module is further configured to seal the changes together with the virtual machine, the signature and the policies to generate the secured virtual machine.
29. The secured virtual machine apparatus of claim 27, the computer readable instructions further forming yet another module, recording changes made to the virtual machine on the recipient computer.
30. The secured virtual machine apparatus of claim 27, the computer readable instructions further forming a metadata module, comprising metadata related to resource requirement data and runtime data for the virtual machine.
31. The secured virtual machine apparatus of claim 27, wherein the execution management module further comprises a rules engine, processing rules describing the policies.
32. The secured virtual machine apparatus of claim 27, the computer readable instructions further forming an encryption module for encrypting the secured virtual machine at the sender computer, and a decryption module, decrypting the secured virtual machine at the recipient computer.
33. The secured virtual machine apparatus of claim 27, wherein the sealing module further comprises:
a hash generation module, creating a hash of contents of a file containing the virtual machine;
and a signature generation module, encrypting the hash with a private key of the recipient.
34. The secured virtual machine apparatus of claim 33, wherein the signature generation module further comprises an encryption module, encrypting the secured virtual machine with a key, and further encrypting the key with a public key of the recipient.
35. The secured virtual machine apparatus of claim 27, wherein the security enforcement module further comprises:
a signature verification module, verifying the signature of the sender; and a hash verification module, determining a hash of contents of the file containing the virtual machine at the recipient computer, and comparing the hash of contents of the file containing the virtual machine at the recipient computer with a hash of contents of a file containing the virtual machine at the sender computer.
a hardware platform, comprising at least one central processing unit, and at least one memory device;
the at least one hardware memory device, having computer readable instructions stored thereon for execution by the at least one central processing unit, forming:
a hypervisor having a virtual machine manager, managing one or more virtual machines, each virtual machine, comprising a virtual hard disk, containing an operating system and software applications running on the virtual hard disk;
at least one of the virtual machines being configured as a secured virtual machine by causing the at least one central processing unit to:
to generate a secured virtual machine at a sender computer, including sealing with a virtual machine, a signature of a sender, and policies governing ownership and execution of the virtual machine;
verify authenticity of the sender upon receiving the secured virtual machine at a recipient computer; and retrieve, from the secured virtual machine, the virtual machine and the policies, and manage the execution of the virtual machine on the recipient computer in accordance with the policies;
wherein the computer readable instructions further cause the at least one central processing unit to record changes made to the virtual machine on the sender computer before the virtual machine has been sealed, and to seal the changes together with the virtual machine, the signature and the policies to generate the secured virtual machine.
37. The computer system of claim 36, wherein the computer readable instructions further cause the at least one central processing unit to record changes made to the virtual machine on the recipient computer.
38. The computer system of claim 36, wherein the computer readable instructions further cause the at least one central processing unit to encrypt the secured virtual machine at the sender computer, and to decrypt the encrypted secured virtual machine at the recipient computer.
39. The computer system of claim 36, wherein the computer readable instructions further cause the at least one central processing unit to:
create a hash of contents of a file containing the virtual machine; and encrypt the hash with a private key of the recipient.
40. The computer system of claim 39, wherein the computer readable instructions further cause the at least one central processing unit to encrypt the secured virtual machine with a key, and further encrypt the key with a public key of the recipient.
41. The computer system of claim 36, wherein the computer readable instructions further cause the at least one central processing unit to:
verify the signature of the sender;
determine a hash of contents of the file containing the virtual machine at the recipient computer;
and compare the hash of contents of the file containing the virtual machine at the recipient computer with a hash of contents of a file containing the virtual machine at the sender computer.
42. The computer system of claim 36, wherein the computer readable instructions further cause the at least one central processing unit to form a rules engine, processing rules describing the policies.
43. The computer system of claim 36, the computer readable instructions further forming a metadata module, comprising metadata related to resource requirement data and runtime data for the virtual machine
44. A system for generating a secured virtual machine, the system comprising:
a sender computer, comprising.
a first processor; and a first memory device, having computer readable instructions stored thereon for execution by the first processor, causing the first processor to generate the secured virtual machine, comprising recording changes made to a virtual machine, sealing with the virtual machine a signature of a sender, policies governing ownership and execution of the virtual machine and the changes made to the virtual machine; and a recipient computer, comprising:
verify authenticity of the sender upon receiving the secured virtual machine at a recipient computer; and retrieve the virtual machine and the policies from the secured virtual machine, and manage the execution of the virtual machine on the recipient computer in accordance with the policies
CA 2640804 2007-10-07 2008-10-07 Method and system for integrated securing and managing of virtual machines and virtual appliances Active CA2640804C (en)
US97812107P true 2007-10-07 2007-10-07
US60/978,121 2007-10-07
CA2640804A1 CA2640804A1 (en) 2009-04-07
CA2640804C true CA2640804C (en) 2015-04-07
CA 2640804 Active CA2640804C (en) 2007-10-07 2008-10-07 Method and system for integrated securing and managing of virtual machines and virtual appliances
2008-10-07 US US12/247,210 patent/US8171301B2/en active Active
2008-10-07 CA CA 2640804 patent/CA2640804C/en active Active
2012-04-28 US US13/459,129 patent/US8549313B2/en active Active
US8549313B2 (en) 2013-10-01
US8171301B2 (en) 2012-05-01
US20120216045A1 (en) 2012-08-23
US20090094673A1 (en) 2009-04-09
CA2640804A1 (en) 2009-04-07
2013-11-04 EEER Examination request