Security, Middleware, Appliances
RSalz 2700011QK0 590 Views
The W3C is having a Workshop in Data and Services Integration and I was part of a group that submitted a position paper. We were accepted, and I'll be at the workshop next month.
This is my first participation in any kinds of standards body work -- well, okay, it's just a meeting -- in quite some time. We'll see what happens. At any rate, it will be good to see some old friends like Paul Downey again.
RSalz 2700011QK0 473 Views
I've been writing about how various aspects of appliances contribute to the overall security of the product. I was talking about "real," physical appliances, but most of what I wrote also applies to virtual appliances -- a product running as a guest image under a hypervisor -- as well. For example, the issues of having no "extra parts" to be attacked is still important, and an important benefit.
But a virtual appliance has other specialized security concerns that physical appliances do not: the hypervisor. While hypervisors isolate systems from each other, and allow greater utilization of the underlying system, Quis custodiet ipsos custodes? (Who will guard the guards?) Put another way, a virtual appliance can be no more secure than the hypervisor on which it is running.
For example, when first creating an instance, the host container will provide a UUID to uniquely identify that instance. We can use the UUID to generate an encryption key, and use that key to encrypt the virtual disk. If the hypervisor is compromised, however, a third-party can be told the UUID and get complete access to the virtual disk. The security assurance that the data is protected, and that the instance will not be moved, cloned, and run elsewhere, is gone.
Is this a concern? I don't know. An internet search for "hypervisor attacks" turns up thousands of hits, including this one from last year that talked about some hypervisor security tooling developed by IBM and NC State.
RSalz 2700011QK0 431 Views
Two previous posts talked about the security benefits an appliance gets from the physical configuration, and by leaving stuff out. This one is simpler, and talks about the security benefits of knowing what's "on the box."
When an appliance leaves the factory, one of the last steps of the manufacturing process it to install the right firmware on it. The word firmware is a better term than software because it typically includes data, low-level chip controllers and device drivers, and so on. In addition to the technical reasons, it's also a more properly-evocative term of what's installed: a special-purpose monolithic image, as opposed to software running on some server.
The firmware can include a decryption key, and a certificate. When an administrator downloads and installs an update, the existing firmware will check the signature and decrypt the image. (Not necessarily in that order.) The fact that the firmware is encrypted allows the vendor to put it in a reasonably-public web site such as a download support site. Verifying the signature, and using the certificate to verify the signer's credentials, allows the existing firmware to "know" that the new install is authentic (comes from the same source), and unmodified.
Those simple mechanisms allow us to maintain a chain of trust -- we always know exactly what is installed, and are sure of its provenance.
The firmware can also include a signed manifest, that enumerates every file on the appliance, and its digest value. This allows verification of the running image and supporting files, against accidental damage. It is not a full-strength protection against someone installing a corrupt operating system in an adversary's hardware, but the form-factor should prevent that. This shows how multiple security features interact to provide stronger security.
RSalz 2700011QK0 462 Views
Part of the appeal of appliances is that you know what's running on the hardware. You can't do this on a modern general-purpose operating system. I can go to my Linux workstation and type "ps" and there are things running that are completely mystifying to me. Does my desktop machine really need automated power management? Similarly, I can open my laptop and fire of the task manager, and be completely lost the minute I move from the applications to the processes tab. All I know how to do is click on the CPU column, and if my browser is making the system sluggish, I'll kill it.
On an appliance, I can do a ps -- if such a command existed, which it shouldn't -- and understand and explain everything. Further, I can walk through the filesystem and describe the justification for the existence of every single file. And if I can't do it, the appliance development team certainly can.
When an appliance leaves the factory, it should have only what's needed to perform its task. The supporting infrastructure of a general-purpose computer should be removed as much as possible. Or rather, start with the kernel and add items as you find you need them. The /etc/passwd file, and in fact almost all of /etc? Remove it. The /bin directory? Why? A shell? Your appliance should include some kind of command line, and be complete for problem determination, so get rid of bash, sh, ash, etc. Busybox? Only as a way to package many utilities in a small unit. If needed.
The less stuff you have, the smaller your attack surface: the fewer places folks can sneak in and get you. The fewer moving parts in the appliance, the more reliable it will be. Within reason, of course. If the problem-determination tools are completely integrated into the data-processing capabilities, then you'll get lots of "box becomes completely not responsive, and I can't log in" complaints. And you can take my word on that. :)
RSalz 2700011QK0 459 Views
IT appliances can bring a lot to the table in terms of security -- more so that general servers, and especially more so than clouds. A major reason for this is their form factor, the physical configuration of the product. Appliances also benefit because they are not used for general-purpose computing; they're built, sold, and used for a specific set of tasks. (Or to use the IBM term, I guess I should call it workload.)
First, an appliance can be a sealed box with a tamper-indicating switch. If the case is opened, we can refuse to boot. In some circumstances we must just log an audit or diagnostic message. Making the appliance not boot is not a decision to take lightly -- it means that there are really no customer-serviceable parts inside. But if you can do that, you can also add extra features like special non-standard screws, and tamper-evident tape that breaks the seal if the case is opened.
An appliance generally needs some kind of storage to hold the firmware and configuration data. Even if someone opens the box, you went that storage to be somewhat protected. On most motherboards, there is EPROM space for the vendor to use, and you can put some key material there. Make that key be per-device -- this requires some coordination, if not outright ownership, of your manufacturing and fulfillment process. If someone rips the lid off and steals the drive, it will take some time to brute-force the key, and even then only that one, intruded, no-longer-booting, appliance will be compromised.
On some platforms, a TPM (Trusted Platform Module) may be available. This is a small piece of hardware that can verify a digest of various parts of your system -- the boot block, the BIOS, and so on -- and only release a blob (typically a key) if all the parts verify. TPM can be used for DRM (digital-rights management), such as ensuring that only an "authorized" player will display the DVD you bought; I dislike that. But when used in an appliance, to ensure that only the authentic software is running on the product, a TPM can make a lot of sense.
A joke thread from an alumni mailing list I'm on. Here's the two best:
A single cryptographer bring a date up to an apartment.
Date: Do you live here?
A: No, it's a one-time pad.
I also know a really great networking joke, but i'ts about UDP so I don't know if you'll get it.
And in the Usenet tradition, feel free to add your own appendages.
Maybe there's a problem with my delivery?
JSONx is a fairly simple way of mapping between JSON and XML. The topic had come up on the xml-dev mailing list, and I posted a pointer to some IBM product documentation. Jason Hunter presented a paper at the March XML Prague conference, A JSON Facade on MarkLogic Server on the same topic. I think my post on xml-dev started a whole flurry of discussion on reddit. While a lot of it was ad hominum (ad industrium?) dirt-throwing, there was one really excellent comment that explained the how and why. I really like the conclusion:
With these impedance mismatches between XML and JSON in mind, they really actually settled on the simplest possible mapping between the two types of documents that preserves full fidelity for round trip conversions.Particularly the "really actually" part, which makes me think the author was pleasantly surprised :)
After getting some external support, and clearance from the appropriate groups within IBM, I'm pleased to announce that we've submitted an internet-draft to the IETF, that grants full rights to anyone to implement. You can find it here: http://datatracker.ietf.org/doc/draft-rsalz-jsonx/.
If there are things we can do to encourage its adoption and use, please let me know. We hope you find it useful.
RSalz 2700011QK0 544 Views
There are many articles on the web about how to effectively write effective software for multi-core CPU's. A web search for multi-core, with or without the hyphen, will turn up millions of hits. One of the reasons for the interest is the thought that vendors might be reaching physical limits to Moore's Law, and are therefore turning to replication, moving from the single-core ear to the multi-core era. Those cores are all the same, so it's really the 'homogenous multi-core era.' If you're smart, just seeing that first word opens your mind up to the possibility of hybrid multi-core systems, where the CPU has built-in accelerators for special tasks, such as cryptography, XML, or whatever. (If you're really smart, you saw enough to add that word in the first place.) (Either way, you're smarter than me.)
As IT appliances are often deployed in specialized environments, such as the edge of the network, the possibilities seem particularly interesting.
RSalz 2700011QK0 1,507 Views
As far as I know, I made this up.
Q: How do IBM'ers first introduce themselves?
A: Hi, who joined?
Those who don't get it might want to look at this video (which is much funnier than my joke): http://www.youtube.com/watch?v=zbJAJEtNUX0
RSalz 2700011QK0 1,881 Views