AWS Storage Gateway looks good, but don’t forget security

Just announced today, the AWS Storage Gateway is offered as an on-premise virtual machine image to which the customer attaches its own storage arrays. Data written via iSCSI to the on-prem gateway is then automatically replicated up to the Amazon cloud. There, it acts as a secondary copy in case the on-prem storage fails, and of course the cloud copy is accessible to cloud-based applications as well. It’s a smart model.

What about security? As usual, the devil is in the details. Some of the details are documented here. Commendably, during replication, the data traverses an encrypted tunnel (SSL). As well, when the data is received by Amazon’s storage gateway proxy in the cloud, it’s encrypted before it’s written to permanent storage.

However, since Amazon has access to the encryption keys, that protection buys you checkbox compliance, but not much more. After all, whoever has access to the keys can decrypt the data, and that includes rogue system administrators, or even Amazon itself if under duress (subpoena, national security, etc.).

If the data is subject to regulation that says it must be encrypted, this feature probably meets that bar. But if the data has value or sensitivity above and beyond that, a different approach is required.

One option is to ensure that the data written to the on-prem storage device is already encrypted. That can be accomplished by placing an encrypting proxy between the device and the rest of the on-prem data center. Data read through the proxy will be decrypted, while data propagated up to the cloud will remain encrypted (and then be encrypted again in the cloud, but that’s okay).

One example of such a proxy is SecurEntity, a software library available from JW Secure. More information is available here.

Cloud Computing: The First Trip to the Cloud

The best way for IT organization with line of business application development responsibilities to develop new capabilities is to experiment. Not haphazardly, mind you, but in a systematic and planned way.

Planning your first custom cloud application is no exception: while IT must do everything it can in order to develop new capabilities so the business can compete, the security ramifications of cloud computing need to be well understood so that undue risk isn’t brought to the business.

Contrary to popular belief, cloud security isn’t a contradiction in terms. Read more here about architecting cloud applications in a secure way.

Patch Management on Business-Critical Servers

May seem obvious, but two best-practices can help you maximize server uptime while still maintaining a high security bar:

  • Don’t run any software or features on your servers that aren’t truly required.
  • Many patches are published with a documented work-around. Use the work-around to postpone patch-related reboots.

Read more here.

Business Agility with Secure Structured Storage in the Cloud

Competitiveness for knowledge-based businesses is all about squeezing every possible benefit out of the Information Technology budget. The ability to quickly deploy new capabilities is key. Want to learn how to do it faster? Read about it in the JW Secure Informer Newsletter v12.

Design Cloud-Based Mobile Apps for Compliance

Got a requirement for a mobile line of business application, and it needs to be deployed immediately? Cloud computing is the way to go. Oh, the data is sensitive? That’s going to require a little more homework.

But not too much. Designing mobile cloud-based applications that are compliant with regulations such as HIPAA, PCI, and government InfoSec is challenging, but not impossible. It just requires planning, and that you choose the right tools for the job. Read all about it in Designing a Cloud-Based Mobile Application for Compliance.

Steps for market analysis

In case you ever forget:

  1. Environmental scan
  2. SWOT
  3. 4Ps
  4. 4Cs (see above)

How secure boot works

As I’ve mentioned in previous posts, a notable area of recent security innovation is the Trusted Platform Module, or TPM, which is a tamper-resistant security chip that has been built into many PC motherboards for the past several years. Importantly, TPM capabilities are being integrated into firmware in system-on-a-chip architectures (such as the latest wave of tablets). Soon we’ll be seeing TPMs in mobile phones.

Of the scenarios enabled by the TPM, two of my favorites are secure boot and remote attestation. Here’s how it starts: at boot time, the BIOS computes a cryptographic hash of the operating system boot loader and boot drivers. This is critical for blocking malware such as rootkits, which load early in the boot cycle in order to effectively become invisible to antivirus software which loads much later.

Once the cryptographic loader and driver hashes have been computed, and the system is booted, a report consisting of a list of those hashes can be generated. This is where things get interesting. The hash of the boot loader is protected by the TPM itself. Further, the TPM can be provisioned with a cryptographic key which can be used to sign a measured boot log file. Thus, if you trust the TPM key, and you trust that a user can’t muck with the TPM itself (generally considered to be very hard, but not impossible), then you can establish a hardware-rooted trust chain for all of the drivers listed in that report.

This approach to secure boot has limitations. For one thing, it only protects early-boot drivers. For software higher in the stack, including most device drivers and anything loaded in user mode (e.g. browser plug-ins), you’re trusting your antivirus software to protect you. Second, the measurement part of secure boot only happens at boot time. After that, until the next reboot, you’re trusting your antivirus software to do its job.

Remote attestation is just a fancy, albeit descriptive name for the process of taking the signed report described above and sending it off-box for verification. The ramifications of that ability may not be immediately obvious, but they’re significant, since the main weak point of authentication schemes today is, “How do we really know that the client PC is acting on behalf of the user?”

In current authentication schemes, a server has no way of knowing whether a rootkit has been installed on a remote client. Why should it care? Compromised client computers are more likely to be used in fraudulent transactions. With remote attestation, a trusted TPM, and a trusted antimalware solution in place, the server can with higher assurance authorize the user to perform high-value transactions (transfer money, get a driver’s license, etc).

Claims mapping & cloud application design

Claims mapping is an important technique for improving the maintainability of applications offering federated authentication. Claims mapping does this by abstracting the details of identity provider-specific semantics. Suppose that you are federating authorization with two separate organizations, each exposed by their own ADFS. It’s likely that the ADFS servers, and the claims issued by each, are configured slightly differently. Suppose further that you have two separate but related applications, both of which must be accessible to both organizations. Claims mapping allows you to not only isolate that two applications from the variations between the two ADFS servers, but also to output claims in a way that is application-specific.

For example, one ADFS server might issue a claim of Title = Doctor, while another server might issue a claim of Title = Dr. Claims mapping allows canonicalization of those titles. Further, if one application is used to track drug dispensation and one is used to view medical records, the former could implemented to expect a claim such as MayPrescribe and the other a claim such as MayView. With this implementation, the logic of interpreting titles has been entirely abstracted from the application, resulting in less duplication of logic and in code that is easier to understand and maintain.

Notably, claims mapping is being offered as a service: see the Windows Azure AppFabric Access Control Service (ACS). 

Informer v11: Cloudy Crime

The JW Secure Informer Newsletter v11 is now available. Are you dipping your toe into cloud computing, but getting nervous about the security implications? Let us know – we’ll show you how to lower costs while protecting the crown jewels.

Secure measured boot in Windows 8

Microsoft gave a sneak peek at some of the cool upcoming security features of Windows 8 at the recent BUILD conference. One of the notable areas of innovation is building on the Trusted Platform Module, or TPM, which is a tamper-resistant security chip that has been built into many PC motherboards for the past several years (or, more recently, integrated as firmware into system-on-a-chip architectures).

Of the TPM-related features, one of my favorites is “measured boot”. It’s introduced in this video from BUILD, Building hardware-based security with a TPM.

If you install the Win 8 developer preview build on a TPM-capable machine (for example, I’m using a 64-bit HP ProBook 6360b), the measured boot feature is on by default. You’ll need a third party tool to view the data, or you can build your own from an SDK sample Microsoft has provided. Back to that in a second, though.

What does measured boot do? In short, it computes a cryptographic hash of the operating system boot loader and boot drivers. This is critical for blocking malware such as rootkits, which load early in the boot cycle in order to effectively become invisible to antivirus software which loads much later.

Once the cryptographic loader and driver hashes have been computed, and the system is booted, a log file which lists those hashes can be generated. This is where things get interesting. The hash of the boot loader is protected by the TPM itself. Further, the TPM can be provisioned with a cryptographic key which can be used to sign a measured boot log file. Thus, if you trust the TPM key, and you trust that a user can’t muck with the TPM itself (generally considered to be very hard, but not impossible), then you can establish a hardware-rooted trust chain for all of the drivers in the log file.

Measured boot has limitations. For one thing, it only protects early-boot drivers (including an optional Early-Load Anti-Malware, ELAM, driver which is expected to be provided by antivirus vendors – see the “Secured boot architecture” slide in the above presentation). For software higher in the stack, including most device drivers and anything loaded in user mode (e.g. browser plug-ins), you’re trusting your antivirus software to protect you. Second, the measurement part of measured boot only happens at boot time (see the “TPM basics” slide in the above presentation). After that, until the next reboot, you’re trusting your antivirus software to do its job.

The ELAM/anti-malware opportunity is cool, but where measured boot really shines is in the context of remote attestation, another TPM-based feature discussed at BUILD. Remote attestation is just a fancy, albeit descriptive name for the process of taking the signed log file described above and sending it off-box for verification. The ramifications of that ability may not be immediately obvious, but they’re significant, since the main weak point of authentication schemes today is, “How do we really know that the client PC is acting on behalf of the user?”

In current authentication schemes, a server has no way of knowing whether a rootkit has been installed on a remote client. Why should it care? Compromised client computers are more likely to be used in fraudulent transactions. With remote attestation, a trusted TPM, and a trusted antimalware/ELAM solution in place, the server can with higher assurance authorize the user to perform high-value transactions (transfer money, get a driver’s license, etc).

So much for the fine print; let’s see measured boot in action. The easiest way to do so is to download and build the Platform Crypto Provider sample from MSDN. It builds pcptool.exe, which offers a command-line interface for interacting not only with measured boot, but also with other TPM-related features discussed in the BUILD presentation. Unfortunately, building pcptool.exe seems to require the full Developer Preview version of Visual Studio 11, rather than just the Express version.

Once pcptool.exe is built, you can retrieve the binary version of the measured boot log data as follows:

>PCPTool.exe GetLog c:\temp\bootlog.out

Then, to convert the binary into XML:

>PCPTool.exe DecodeLog c:\temp\bootlog.out > c:\temp\bootlog-decoded.txt

Finally, it’s instructive to examine the contents of the XML log file.

<LoadedModule_Aggregation Size=”435″>
  <FilePath Size=”60″>\Windows\system32\winload.exe</FilePath>
  <ImageSize Size=”8″>1286144<!– 0x000000000013a000 –></ImageSize>
  <HashAlgorithmId Size=”4″>SHA-256</HashAlgorithmId>
  <AuthenticodeHash Size=”32″>
    9cb15db889bb78400e4cc6831d04616c013bf904b097cedb503e5136e5750b16
  </AuthenticodeHash>
…  <AuthoritySHA1Thumbprint Size=”20″>
    cc9008d2d4e80eb924e3ad29cb08600f58570cdc
    <!– …………….XW.. –>
  </AuthoritySHA1Thumbprint>
</LoadedModule_Aggregation>

The above log entry shows the hash and signer information for the Windows boot loader. Again, combined with remote attestation, this information can be evaluated by a remote server to establish cryptographically that early system boot components have not been modified.

Measured boot is a powerful security feature of Windows 8, and we’re looking forward to integrating it into customer protocols and applications.