Dan Griffin's Blog
Comments on security, PKI, smart cards, cryptography, and entrepreneurship.
Shamir’s Law
February 6, 2007
"Every 18 months, computer security gets 50% worse"
I’m not really doing justice to the full context of that comment, but whatever. Nevertheless, if consumers and enterprise users alike didn’t have all of these networked devices - PCs, cell phones, mp3 players, game consoles - then people in the information security field wouldn’t have such challenging problems to work on …
- The products formerly known as Certificate Lifecycle Manager (and, before that, Alacris idNexus) and MIIS are now combined and re-branded as Identity Lifecycle Manager 2007. See http://www.microsoft.com/windowsserver/ilm2007/default.mspx. It’ll be interesting to see how the potential synergy in the Registration Authority and Meta-Directory technologies plays out.
Second concern: I haven’t seen an RTM date for ILM yet; hopefully it won’t slip too much.
- The second big announcement is a compatibility agreement between Microsoft CardSpace and OpenID. Kim Cameron’s blog post this morning covers the deal - http://www.identityblog.com/?p=668.
Top 10 Bio-IT Trends for 2007
February 3, 2007
Interesting article in this month’s Bio-IT World magazine (available online - http://www.bio-itworld.com/issues/2006/dec-jan/inside-the-box/) entitled "Top Ten BioIT Trends for 2007". Some of the trends really resonate, both as common pain points and as potential business opportunities in the IT field overall.
- "Power and Cooling Costs" - what high-tech firm doesn’t see this, even on a small scale? The more computer equipment you plugin, the greater the electricity bill! The article says that running a typical 42 unit rack for a year, including power + air-conditioning costs, costs $30K per year in electricity. One industry trend, developing partly in response to this: increases in the number of CPU cores per board. The technical terminology for that trend: FLOPS per Watt.
Although the article lists it separately, I’d group another IT trend here as well: virtualization, which I find to be a fascinating technology for a variety of reasons.
Back in the olden days, I used to do all of my software testing on separate workstations, primarily because we were testing operating system-level changes and VM technology wasn’t ready for primetime. The latter has certainly changed. In fact - I’ll cite a specific product here - VMware cuts our overall development costs dramatically, since the inevitable setup and configuration costs in software testing can now be amortized across multiple engineers and projects, and we’ve found the technology to be reliable even when mixing and matching host/guest architectures and operating systems.
Returning to the initial point, virtualization will also have an impact a power consumption, since compromises in shared hardware can now be made that weren’t previously feasible. From a reliability perspective, server software is rarely designed to allow multiple instances to coexist on a single host, previously restricting deployments to a single instance per machine. With virtualization, that’s no longer the case. The same case can be made for security considerations - previously, some trust boundaries could only safely be enforced on a per-machine basis (e.g. who has administrator-level login privileges). Via virtualization, access can safely be granted to each instance piecemeal.
- "Unified Identity Management" - this one doesn’t strike me as a ubiquitous need, but the point is made that providing reliable, convenient, and secure single sign-on capability across Windows, Mac, and Unix hosts is still quite difficult. It’s a major pain point for certain industries (bio apparently being one of them) where research computing networks have traditionally been separate from production/enterprise networks, but where those boundaries are now by necessity eroding.
- "10 Gigabit Ethernet" - this is a cool concept, although I’m not quite clear on what role it will play in solving the industry’s data management problems, which are after all worsening exponentially. If my job is to build computational models based on terabytes of data, what good is 10 Gb ethernet? Won’t it still take two hours to copy 10 TB of data?
Permalink | Comments (0)
Enforce Digitally Signed Email to Reduce Spread of Viruses?
February 1, 2007
Conversations with colleagues over the past few months had me thinking about this. If a company were to require that all email handled by its servers is digitally signed, could that help to reduce the spread of email-borne viruses? I’ve come up with the following considerations:
1. The biggest email-borne threat is in the form of attachments consisting of executable content. E.g. Click on this to see the dancing elephants! So stripping such attachments at the server is effective. However, determining what qualifies as executable content vs what qualifies as "safe-enough" is a moving target. For example, lots of people rely on compressed/ZIP attachments, and few organizations block them, but there have been critical flaws reported in that file format. Ditto for Office suite documents, especially with respect to embedded macros. There have even been recent security flaws in multimedia formats. In summary, configuring the mail server to respond to up-to-the-minute threats from myriad file formats, while still balancing productivity requirements, is hard.
2. Conditionally locking down the mail server to accept only signed email is problematic in two regards. First, if this is done in response to an elevated internet threat level, it’s likely to be too late, especially for a large organization with a large attack surface. I.e. the virus is already on the corporate network. Second, this implies that every internal email client, even those that just a moment ago weren’t required to send signed email, can dynamically start doing so on demand. This is likely to cause more problems than establishing a policy to be in effect at all times.
3. In addition, regardless of whether an S/MIME policy were enforced at all times or only conditionally, consideration must be made for external email. Must all of the company’s partners send signed email as well? Within enterprises that have deployed a PKI, best-practice is to rely on internal certificate chains for all line-of-business use. Otherwise, trust decisions are being delegated to an outside entity. But cross-certification doesn’t scale to the degree that most companies are likely to require in order to enforce 100% inbound and outbound signed email. Perhaps the usual digital identity vendors (e.g. Thawte; VeriSign) are well-known enough to be trusted for "everyday" email signing purposes (e.g. as opposed to certain high-value internal transactions) across a majority of partner relationships. But that raises the cost of provisioning each user, especially if an enterprise PKI exists.
4. A smart virus will respect the settings of the user’s mail client. If I’m writing a virus or worm that spreads via email, and I want it to be robust against enterprise defenses, then I’ll make it send signed email. On the defense side, best practice is for users to be prompted to confirm use of their private key. But the majority of users will click OK.
5. In comparing two short and otherwise identical emails sent from Outlook via Microsoft Exchange, one signed and one not, the signed one is three times the size! Comparing a larger-than-average email with an attachment, the signed version is still 50% bigger. Some percentage of the S/MIME overhead may be specific to Microsoft’s implementation, even though this stuff is theoretically standards-based, but there’s still a practical concern here. Storage itself is relatively cheap, but I don’t know how well existing servers scale on throughput.
Permalink | Comments (0)
