The HIPAA rules state that the use of encryption is not “mandatory” but “addressable”. This means you are allowed to evaluate whether it is really needed, and can implement an alternative so long as you document the rationale. If you search the web, you will quickly discover that, while encryption is indeed not mandatory, it is seen by most experts as a great way to lower your risk and exposure to fines. For this reason, encryption is considered the best practice, and most implementations of healthcare software do decide in favor of encryption.

As always, the devil is in the details. How does one do a strong implementation of encryption for a healthcare scenario in the cloud? There are several areas to consider

• Protecting the storage medium, such as virtual disks
• Protecting individual information fields or database “columns” that have especially sensitive information
• Protecting encryption keys

Threat vectors

The real questions to ask are about “threat vectors”; in plain English: who are the bad guys and how do they operate?

One major threat vector is from people who have maliciously entered your cloud account, and are now moving around in the account and doing standard operations that you thought only you could do. Such a person could be a “cloud insider” – someone who works at your cloud provider; or it could be a “black hat” who stole your credentials to enter your cloud account. Such people can do significant damage.

For example, it is easy in this scenario to “snapshot” a complete disk and steal a copy without anyone noticing. This threat vector is usually mitigated by full disk encryption and/or full file encryption.

Such an attacker could also choose to damage your virtual disk – detach it or overwrite it. Mitigation can be achieved by creating regular backup snapshots, which many clouds support. The backup snapshots should also be encrypted – to avoid copying as in the previous example.

Another major threat vector is from attackers who have stolen the credentials of an application administrator (or perhaps an administrator “gone bad”). Such credentials can allow the attacker to – for example – query the database for sensitive health information. Mitigation can be achieved by encrypting the most sensitive data fields so they are not available to the administrator. Typically you want administrators to be able to do support work without seeing the names of individual patients in the database.

We must also consider the cunning crook that will attack you through your encryption keys. This is especially tricky in the cloud – if you store your encryption keys in the cloud, the crook may steal them and then decrypt your disks or fields. This actually gets around all the previous safety measures. Because of the seriousness of this attack, a solution is required by the rules. Fortunately, this challenge can be mitigated by split-key encryption (read more about it in this white paper).

What do you really need?

The minimum implementation is full disk encryption together with cloud-enabled key management. If you do that, you are off to a good start. As your business grows, you will find that you also want to address the administrator threat vector, and implement field-level encryption. You are advised to choose a solution that will address all of these requirements, and can do so either all at once or one step at a time.

The post Cloud Encryption as a best practice for HIPAA compliance appeared first on Porticor Cloud Security.

“Always use external key management. Instance-managed encryption is only acceptable for test/development systems you know will never go into production”

Instance managed encryption means the encryption keys are kept on the virtual disk. In other words, anyone with access to your cloud instance, has access to your encryption keys – hence to your data. In addition, specific cloud operations, such as disk snapshots, will snapshot the encryption keys with it.

“For sensitive data in public cloud computing choose a system with protection for keys in volatile memory (RAM). Don’t use a cloud’s native encryption capabilities if you have any concern that a cloud administrator is a risk”

As I see it, there are two great points here, one relates to cloud security concerns, the second is interesting for compliance reasons. Protecting keys in RAM (the security concern) is actually not a simple thing to achieve.  We have worked extremely hard to create a mechanism which keeps the encryption keys encrypted themselves, even while in use in RAM.  To do so, we have used partially homomorphic encryption techniques (fancy name, I know…), a world first implementation of such technology to a cloud security product (you can read more about it here, or download the Porticor white paper for additional information). Now for the second point; using the IaaS provider’s native cloud encryption capabilities means there’s a risk that someone (an employee) within the cloud data center can potentially read your data. While an obvious security risk, this is also a compliance issue as certain regulations (for example PCI) mention separation of duties as a core compliance requirement.

“Pick a product designed to handle the more dynamic cloud computing environment. Specifically one with workflow for rapidly provisioning keys to cloud instances and API support for the cloud platform you use”

I couldn’t agree more. Traditional, “on-premise” encryption and key management systems are not built for the cloud. As a result, many of the cloud most significant advantages, such as scalability and flexibility might not function well (dare I say not function at all) with such encryption systems. A cloud encryption system should seamlessly integrate with your cloud design, and integrate with any automation process you have in place. An API is important as an integration point between your cloud systems and (for example) an orchestration system.  In such scenario you can automate encryption together with the rest of the IaaS system, spin up new or down new encrypted disks, encrypt S3 objects, and even automatically feed encryption keys to specific SaaS applications (I will discuss cloud encryption keys security and split-key encryption in one of my next blogs).

Ariel Dan is co-founder at Porticor Cloud Security.

The post Cloud Encryption: How to choose an IaaS encryption solution appeared first on Porticor Cloud Security.

Some of these are deploying VMware in their private data center, while others are leveraging the cloud model and “renting” capacity from a public VMware-based cloud provider. In a way, both of these scenarios are public: in many of the cases the “private cloud” scenario serves users who belong to different organizations, so from the user point of view the scenario is “public”. As a result, these customers have many of the same security concerns (see here for a deeper discussion of that point).

When considering deployment of a cloud encryption solution in these environments, we have seen several options.

Physical solutions

Physical boxes are a solution that exists a long time in the market. The idea is to put a physical box between the ESX rack and the SAN – plug in the network – and let the box encrypt everything that comes from the ESX rack.

The upside of the physical box is it is tried and tested. Downsides include

• Physical boxes increase TCO and up-front costs, while losing the flexibility of virtualized solutions
• It is an all-or-nothing solution for the entire ESX rack; it is not possible to provide finer-granular control that is sensitive to the needs of a particular application or customer.

Especially in the cloud world, where tenants are a common concept, it is necessary to create strong separation and segregation between different applications and customers – on the same infrastructure. That is why more and more solutions need to be software controlled and virtualized.

Deployment models for a Virtual Solution

A virtual cloud encryption solution – whether for public or private cloud – can have several deployment models.

• A virtual appliance “close to the storage”
• A virtual appliance “close to the customer account or to the application”
• A software agent
• A hook on the ESX level

Each of these is good for different cases.

Virtual appliances close to the storage

This involves a virtual machine image which is deployable so it sees the LUNs, VMFSs and VMDKs exposed by the VMware infrastructure, and encrypts them before they are allocated to a specific application or specific customer account. It is accessible from multiple network segments in the environment and has a tenancy concept which is well integrated with the management concepts of VSpehere and VCloud – and then this is an extremely flexible solution serving a wide range of scenarios.

Virtual appliances “close to the customer”

A virtual machine image is deployable in the customer account, within the network segments used by that customer. It is logically “close” to the application and under possibly under tenant control. Again it should be well integrated with the management concepts of VSpehere and VCloud – allowing its placement in the customer account – and again this is an extremely flexible solution serving a wide range of scenarios.

Software agents

These are typically installed as software on the customer or application VMs. Their advantage is that they are fully contained within the customer guest OS, giving a sense of complete control. Disadvantages include their footprint and upgrade needs.

ESX hooks

ESX is evolving a number of hooking mechanisms that allow functionality to be hooked below the guest OS level. The advantage is that such hooks can be shared by several guests on one ESX instance, and VMware helps deploy them. A security disadvantage is that they may create a sharing situation between guest OS’s that belong to different applications or customers.

The ideal solution

The best of all possible worlds is a solution that can work in several of these deployment models, not just one. Such solutions do exist today. Software-defined security for the virtual world is becoming a reality.

The post Cloud Encryption deployment for VMware-based application services appeared first on Porticor Cloud Security.

Cost

Deploying a cloud encryption solution the traditional way is costly. The majority of the solutions are priced at the tens-to-hundreds thousand dollar range. Purchasing such a solution upfront is naturally a heavy capital expenditure, which forces the cloud provider to think long term only ROI (assuming a healthy business model, we’re looking at one to two years for a return on investment). But in addition to the cost expense, there’s another critical requirement not usually fulfilled with traditional encryption solutions:

Cloudability

Putting budget aside, an encryption solution for a cloud provider has different requirements. Cloud encryption key management and the ability to provide an encryption solution per customer without managing the encryption keys for him are probably the most important ones. A cloud provider should ideally never see or manage its customers’ encryption keys, yet at the same time should allow those same customers to provision an encryption solution quickly, cost effectively, and in a cloud-compelling way (i.e. without compromising cloud elasticity). Challenging? Yes. Doable? Absolutely.

Cloud Encryption using split-key management

An emerging technology such as Porticor Cloud Security resolves both cost and cloudability issues by designing its cloud encryption technology from the ground up for cloud IaaS environments. Using key-splitting technology, Porticor provides a fully virtualized key management system which does not sacrifice trust; ensuring that only the end customer can manage its encryption keys (for additional information download this white paper). As for costs – Porticor provides a monthly subscription fee per customer, enabling its partners to eliminate cloud encryption capital expenditure completely, and become a profit center from the first customer.

The post Cloud providers: Adopt a cloud encryption “profit center” approach appeared first on Porticor Cloud Security.

As cloud computing evolves, these features are being used to try and create secure cloud database solutions enjoying cloud encryption. TDE is a basic building block for such solutions; however, in the cloud, TDE needs some enhancement, specifically around cloud key management.

Like any cloud encryption mechanism, TDE needs encryption keys. The master encryption key is fed into TDE from a mechanism called a “wallet”. The Oracle wallet needs to be stored somewhere and storing it securely in the cloud raises a host of issues.

In principal, the oracle wallet can be stored in a file system, but by itself that is not a secure cloud solution. The most secure way to store the wallet is through split-key encryption and homomorphic key management – this means that the master key to your Oracle database is actually never stored anywhere in the cloud. Split-key encryption, in this context, means that the Oracle TDE master key is itself split into two key shares. Homomorphic encryption of these key shares means that the key shares are encrypted even when in use in the cloud, so they do not offer an attack surface at any moment.

These are cutting edge solutions, yet happily they are beginning to be available in the market. The integration of Oracle TDE’s wallet with Porticor’s homomorphic key management technology provides a cloud solution which is as secure as a physical data center, completely in the cloud. The physical walls are constructed through mathematics.

The post Cloud Key Management and Oracle TDE appeared first on Porticor Cloud Security.

Cloud HIPAA compliance still requires a shared responsibility model

Without getting to the details of what a “Business Associate Agreement” means, I’ll simply say that the updated regulation makes business associates (Healthcare ISVs’, and potentially the cloud providers themselves) of covered entities (i.e. clinics or hospitals) directly liable for compliance with certain requirements of the HIPAA privacy and security rules (read more about it in this excellent HIPAA survival guide post). In other words, the entire “food chain” (The cloud provider, the ISV, and any other business associates in the logical flow to the covered entity), should ideally sign a business associate agreement. But what is the practical meaning of such requirement in an IaaS cloud environment? As one should expect – full compliance can be achieved only if all parties (business associates) will enforce compliance where they can actually do so. The IaaS cloud provider for example, will prove compliance on the physical and hypervisor level, while the Healthcare ISV will prove compliance on the guest OS, the healthcare application, and PHI data stored in the cloud.

Cloud encryption is a critical element

When discussing the HIPAA omnibus standard with some of our healthcare oriented customers, they all say the same: Data encryption is a critical element for cloud security and compliance. It enables them to safely store personal health information (PHI) in a public cloud, knowing that the data will always stay encrypted, for example in a disk snapshot scenario, as well as when the data is backed up. This is critical for them, as encrypted PHI data does not disclose actual information; hence they are well within the compliance requirements, even if an encrypted snapshot is somehow lost. The bigger challenge for them is how to remain in compliance without compromising on critical cloud benefits such as flexibility and elasticity. Using the Porticor technology they were able to secure and encrypt PHI data quickly and effectively (click here for more information and the Porticor white paper), but as important, they integrated data encryption into their product flow without compromising cloud elasticity, by integrating the Porticor API both on the encryption level, as well as on the key management and key distribution level.

The post Cloud security and the omnibus HIPAA – Thoughts on compliance and the shared responsibility model appeared first on Porticor Cloud Security.

The Agent connects to a key management appliance – a Porticor virtual machine deployed in your cloud account, which is responsible to safeguard your master key so that you do not have to trust anybody else with your keys, not even Porticor. You provision the Agent with a secure API key, which allows it to access its own managed crypto keys, but not the master key. All disk encryption takes place locally on the server that runs the Agent, and the disk-encryption keys are split between the key management appliance and the Porticor Virtual Key Management (PVKM) service.

Installing the Agent

1. Download the agent from this link (for Debian/Ubuntu) or this link (for RHEL, CentOS or Amazon Linux).
2. Install the package on your application server:
   On Ubuntu, run dpkg -i package-name.deb
   On Red Hat, CentOS and Amazon Linux, run yum install package-name.rpm
3. Configure the appliance:
   • You will need the address of a Porticor appliance that’s in your cloud account. Go to the PVKM’s main management page, select an appropriate appliance, click “manage” and then note down its DNS address (typically ending with d.porticor.net). If no such appliance exists, you will have to start one.
   • You will also need an API key, which you can obtain from the PVKM’s API key management page.
   • On AWS, we strongly recommend to enter your cloud credentials into the Porticor appliance. Go to the Protected File Systems and enter the AWS Key ID and Secret Key. Note: these credentials are part of your project and your account, even after you enter them – Porticor never sees them.
   • From your application server (where you installed the Porticor agent) run sudo porticor_agent initialize appliance-addr –api-key-id key-id and enter the secret key when prompted. Please do not cut-and-paste from this page, or you might get an incorrect dash in front of “api-key-id”.
   • The agent is ready to go.

Agent Commands

The agent provides a single command porticor_agent, which in turn provides numerous subcommands. All subcommands must be run with root permissions. For example:

sudo porticor_agent status

Command Syntax

All options in brackets [ are optional. All options in double-quotes " must be quoted if they consist of multiple words.

Below is the list of subcommands:

help

List the agent's commands.

status

Display a status summary.

initialize appliance-addr [--agent-name "name"] –api-key-id key-id [--api-secret-key secret-key] [--persist-key] [--no-ip-validation]

Initialize the agent. The agent will connect to the given appliance using the provided API key. If the secret part of the key is not given on the command line, you will be prompted for it (recommended). The agent’s configuration is written to /etc/porticor-agent/agent-config.json. The appliance must be available for the initialization to complete successfully. During initialization, the current server’s entropy pool (/dev/random) is refreshed. You can use −−agent-name to name the agent. Use −−persist-key (not recommended) if you want the agent’s key to be saved on disk so that it can survive a reboot. On AWS, you may use −−no-ip-validation if you prefer not to tie API keys to a particular server instance.

reconfigure appliance-addr [--agent-name "name"] –api-key-id key-id [--api-secret-key secret-key] [--persist-key] [--no-ip-validation]

Similar to initialize, to be used when the agent has already been initialized. This is useful if you want to switch to a different appliance, or another API key.

enter-key –api-key-id key-id [--api-secret-key secret-key] [--persist-key] [--no-ip-validation]

Enter an API key if the secret key has been deleted, e.g. after a reboot.

deconfigure [--force]

Remove the agent’s configuration without uninstalling it. The –force option skips the confirmation prompt. You may not deconfigure an agent while it still has disks configured on it.

secure-disk device-name “comment”

Set up a new disk for encryption. The device name is a block device, e.g. /dev/sdb. Important: make sure the device is empty before using it. You can add a comment between quotes, such as “My project’s MySQL data disk”.

secure-mapped-disk file-name size ["comment"]

Set up a new disk for encryption. This command uses a file-mapped disk (also known as “loop device”) instead of a block device. A new file of the specified size (given in gigabytes) is created and mapped. You can add a comment between quotes, such as “My project’s MySQL data disk”.
After you have set up the disk, you can use the mkfs /dev/mapper/hl-xxxx and mount /dev/mapper/hl-xxxx mount-point commands to respectively format and mount it. The mapper address is displayed by the list-disks command.

lock-disk disk-name

Lock a disk and forget its key. The key is removed from the agent and the appliance, but a key-share is retained on the Porticor Key Management service. The disk-name argument is a name of the form hl-1234abcd, as displayed by the list-disks command.

unlock-disk disk-name

Retrieve the disk’s key from the Key Management service and ready it for use. The disk-name argument is a name of the form hl-1234abcd, as displayed by the list-disks command. You may need to remount the disk using the mount command.

remove-disk [--force] disk-name

Permanently remove the encrypted disk, and forget its encryption key. The disk-name argument is a name of the form hl-1234abcd, as displayed by the list-disks command. This operation cannot be undone! The –force argument overrides the confirmation prompt.

edit-comment disk-name “new comment”

Replaces the comment associated with the disk. The disk-name argument is a name of the form hl-1234abcd, as displayed by the list-disks command. The comment must be quoted.

list-disks

List all the disks managed by the agent.

start

Unlock all disks that are marked as active. Useful in provisioning scripts, after enter-key has been used to refresh the key.

Example Session

Install the agent (on Ubuntu or Debian):

# dpkg -i porticor-agent_1.0-1_all.deb

Initial configuration (you will need an API key):

# porticor_agent initialize izjuuy0klp4-pztgzntfjmj.d.porticor.net   --agent-name "DB Server Agent" --api-key-id Tz8N7YMaBz5Zuw4A --api-secret-key SeCrEt

Check agent status:

# porticor_agent status

Agent Name: DB Server Agent
Version: 2.20
UUID: 2bb0011b-4b79-e6f3-0cea-117d6a395d73
Project Serial: PROJMJNPQJDRJGZD2BLO001=
Appliance: izjuuy0klp4-pztgzntfjmj.d.porticor.net
API Key ID: 3t1aQrnPrdGvh6iK
API Secret Key: Configured
# of Protected Disks: 0


Encrypt an entire disk:

# porticor_agent secure-disk /dev/xvdg "An Encrypted Block Device"

Alternatively, create a file of a certain size, and map it as an encrypted disk:

# porticor_agent secure-mapped-disk encrypted-data 10 "My encrypted data"

List all protected disks:

# porticor_agent list-disks

Name             Device     Size Status Mapping      Comment
hl-50168697a70a /dev/loop0 10 GB Active /dev/mapper/hl-50168697a70a      My encrypted data


Prepare the disk for use: format and mount it:

# mkdir ./mydisk
# mkfs -t ext4 /dev/mapper/hl-50168697a70a
# mount /dev/mapper/hl-50168697a70a ./mydisk


The disk is now ready to use.

Later, when the disk is no longer needed… Lock the disk:

# umount ./mydisk
# porticor_agent lock-disk hl-50168697a70a


Remove the disk (this deletes the encryption keys and the data cannot be recovered)

# porticor_agent remove-disk hl-50168697a70a

This operation cannot be undone. Are you sure? [N]: y


When the agent is no longer in use, delete its configuration:

# porticor_agent deconfigure

Really remove all Agent configuration? [N]: y


Agent Security

In normal use, no long-term secrets are kept on the agent. Whenever the agent is configured using the API key, this key is replaced by a short-term, policy-constrained key, and only that second key is retained. The short-term key allows API calls to originate only from a single cloud instance, and allows for the instance to change its IP address. By default, the secret part of this key is not kept on disk, and so cannot be recovered by snapshot attacks. This means that your provisioning system should refresh the API key using the enter-key command whenever the server reboots. Note that the instance restriction policy is only available if the agent is installed on an AWS server, and requires that any agents should be collocated within the same subnet as their Porticor appliance.

The post Using the Porticor Agent appeared first on Porticor Cloud Security.

Your cloud type dictates the amount of control you have

First and foremost, the level of control and your ability as a cloud customer to implement security in your cloud environment is dictated by your cloud type. For example a customer using Software as a Service (SaaS) will have the least amount of control and the SaaS provider will have the greatest level of responsibility for data security, while in Infrastructure as a Service (IaaS), the customer has much more control on data security implemented in his cloud account while the IaaS provider will emphasize “shared responsibility”. And to translate it to compliance: A customer in a SaaS environment must rely heavily on the provider’s compliance (which is either there or not), while in a IaaS environment the customer must take active responsibility for compliance together with tools provided by the IaaS cloud provider.

                                       (Source: PCI DSS Cloud Computing Guidelines)

Cloud Encryption and Segmentation Considerations

Unlike a traditional data center, where compute environments (i.e. servers and applications) are physically separated from each other, in cloud computing (SaaS, PaaS, or IaaS) the computing environment is shared between customers, and the customer is required to trust the cloud provider with separation and segmentation of the different virtual environments.

There is, however, another option which is entirely under the customer’s control: encryption and key management are probably the most effective ways of segmenting and separating virtual environments.

Cloud encryption does bring new questions around control with it, specifically who manages the encryption keys? If the cloud provider or your encryption vendor is responsible for the encryption and key management, compliance becomes an issue (how can one guarantee that cloud data is safe different entity has access to the encryption keys – hence to the data).

In such cases, solutions such as Porticor cloud security can significantly help. Porticor’s Virtual Private Data system offers the convenience of cloud-based hosted key management without sacrificing trust by requiring someone else to manage the keys. Porticor uses split-key encryption technology, and simultaneously encrypts the key shares using homomorphic encryption technology – even when they are in use, hence protecting the keys and guaranteeing they remain under customer control and are never exposed. (To read more about Porticor click here for the white paper).

The post Cloud Compliance in Infrastructure as a Service is Mainly Your Responsibility appeared first on Porticor Cloud Security.

The main goals of the new user interface are:

• Maintain (or slightly improve) the product’s functionality.
• Maintain full backward compatibility with existing deployed appliances.
• Align the product’s visual “language” with Porticor’s Web presence.
• Improve in-product navigation.

Portal Page – PVKM

Other than the new colors and the modernized user interaction, the last bullet is the most noticeable. Each page on the new appliance improves the user’s navigation experience by providing a pair of menus: a top menu for in-appliance navigation, and a left-hand menu for out-of-appliance navigation. In addition, each page displays the project name, the name of the appliance (this is most useful for multi-instance AWS projects) and the user’s name.

Portal Page – Appliance

Existing Customers

As noted, the new PVKM is fully compatible with existing appliances, and the full PVKM functionality is available under the new “skin”.

If you wish to upgrade your appliances to the new GUI, you need to follow the restore procedure, just like any other product upgrade.

The post Porticor VPD – Enhanced User Interface appeared first on Porticor Cloud Security.

Cloud key management and encryption requirements

We have found that external users have many of the same security requirements, whether the cloud is public or private: from an external user’s point of view, the differences between public and private clouds are technical details, and the user requires the same guarantees from the provider.

In particular, users expect to own their data. In a business context, a user is often another business. These businesses want to know that they are enjoying the benefits of the provided service, but that the provider cannot read their data.

As a consequence, cloud infrastructure must provide an ability to encrypt sensitive data, and to keep encryption keys under the control of the user. This requirement shows up in public deployments, as a requirement to control keys that encrypt disks. It also shows up in private deployments, as a requirement to control keys that are used by the software solution: each user wants to have separate keys, so that other users and the solution provider cannot read the users data. Such solutions are beginning to emerge, for example split-key encryption and homomorphic key management.

Public cloud deployments

Public providers often want to “chop” a large storage array into chunks that are usable for customers. Virtualization technology is very natural here, but the challenge is to make each “chunk” encrypted by different keys, so that customers remain in control.

A natural solution here has emerged from Porticor: Virtual Appliances are deployed on the same VMware-based infrastructure that the provider has chosen. These appliances know how to consume a LUN or VMFS, and re-expose it as a new LUN or VMFS, this time encrypted using keys that are specific to a customer. (For further details read the white paper here)

The Porticor solution actually leverages the same flexibility to carve up storage and compute – that is available from the VMware cloud infrastructure – and adds encryption and key management as a natural layer.

Private cloud deployments

Private providers often have a specific software solution in mind. Here Porticor’s ability to provide unique “tokens” for users, groups or roles – and an API that integrates with the provider’s identity & access management solution – allows individual and group identities to be maintained at the encryption layer.

Providers can offer full multi-tenancy, yet guarantee that the user’s individual data is encrypted using a key that only the user knows. The provider’s employees literally provide the service yet cannot read the data.

Summary

The flexibility of modern virtualization environments is often presented as a security challenge, but with the right technology, it can actually enhance security and offer users greater control of their data – without the hassle of managing it themselves.

The post Key management and encryption in VMware-based clouds appeared first on Porticor Cloud Security.