Wednesday 3 September 2008

My first issue.

I read a post somewhere last week (it may have been one of Rich Mogull's?) where a simple question was asked about what people liked about IT Security blogs. The (rather ironic) answer from one commenter was that they didn't like all the complaining that went on - and preferred it when people explained answers to security problems.

Having written a post just beforehand having a good old moan about things that people do stupidly, I thought I'd try and redress the balance in the force by starting to discuss a few issues, and how I would solve them. I hope to get some input as to why I'm wrong, and as many complaints about my stupidity as my comments can hold.

Issue of the day for me is secure email. Without discussing any more politics, let us assume that we have a business requirement for secure email. I can't tell you what we are sending out, because then I'd have to kill you, just rest assured that we need to. We need to send out to lots of different domains, and we want to initiate that exchange every time. Users of the system must be registered with us.

The solution that was proferred to me was one of the IBEs (Identity Based Encryption). There are 2 that I know of, Trend and Voltage. I'm not going to say which one has been picked, because they are much of a muchness as far as I can see, and neither is right for me.
Requirement - must be standards based.
IBE isn't a standard as yet. It's a great technology, lots of fun, and has some great applications, but it isn't something that's tried and tested. I'm worried by it.
Requirement - must not add complexity of management.
plus Requirement - zero download option.
IBE isn't as simple as you might think. Key management is still the major issue, especially when you are dealing with external clients coming into your network to pick up decryption keys.
Requirement - Blackberry compatible.
Those people who have a requirement for Blackberries probably have a requirement for secure email. It's bad planning not to be addressing this immediately.
Requirement - must integrate with current architecture.
As with the 'standards based' requirement, this is going to be hard work. Anything so new is going to be crowbarred in. The only thing it integrates with is Exchange and Outlook, but then all email solutions do... how about working with certificates, protecting attachments end to end, and being able to vary the levels of security via policy.

Which reminds me - who's writing the policies on this thing. I don't really understand who needs to be encrypted to, or in fact... why?
Requirement - fully audit when this data is sent out of the network.
You just can't do that with the system which created it. If it's being emailed, an internal user can email it out, but there is no reliable automated process to log this. It's either a manual process by the user - so more policy writing, more holes for errors to slip into - or it's nothing. That's scary, especially when the next step is emailing data out of the network.

Which brings me back to the politics I'm afraid. Why does anyone need secure email? Email is NOT secure. The only reason you need secure email is because another process is broken, it is a sticking plaster option to my mind.

Better to create a secure extranet, register your users there, use a third party PKI if you need to use keys at all, and use the certificates to authenticate your users too whilst you're at it. Use a CMS type too to publish pages to individual users as and when they require to download data from your network. That way you have a full audit trail too...

In short, no matter how hard a security person tries to be helpful, they will always end up moaning. It's kind of my their job.

No comments:

MadKasting