Testing,testing,1,2,1,2

4 or 5 years ago a friend of mine approached me with the idea of going into the penetration testing business: "Let's go into the penetration testing business", he said, and we did some market research. We could buy the required tools, a server, a shed, and a reasonably large internet connection, install a free copy of Nessus and be up and running by the end of the week.

Of course we looked a little further than that, and realised that everyone and his dog was already doing it, and like every other business, it was just a case of whoever was shouting the loudest would make the biggest bucks. Steve and I were total techheads and neither particularly interested in making noise at the time, so we went back to the day jobs...

A couple of years later, a new friend at a new company asked me about my background. We got around to talking about my close call with pen testing and he said: "yep, I thought about that for a while, no money in it."

All of us remain firmly under the employ of other entrepreneurs, some large, some small, but none of them us.

Today I saw a quote from a pen testing company, not one for dropping names, let's just say they do secure tests. My jaw dropped when I saw the price for 4 days work. An amazing return for them, but just like Starbucks charge more for a coffee I could make at home because of their ability to make it in bulk and present it better than I can, so they can do a much better job than we can, make a pretty report, tailored to our needs, and there's probably negligible real cost difference to us anyway. Not that we could do our own tests, but it did strike me that the only reason we have to do them anyway is because our security team (now disbanded) had identified the need in the first place...

The MD of this testing company often writes for a magazine that I have written for in the past. He shouts louder than I do, and makes his presence known. He's also very good, knows the market and knows what makes a good product. I'm not sure I could have built a business out of it in such a cutthroat market.

Still, it would have been nice, wouldn't it?

Bad security awards

I wrote recently of how it could be excused for me to complain a little whilst I'm writing here. Of course I'd like to be constructive in everything I write, but the job of security is so often finding holes that it is a rut that we get stuck in, and maybe not a bad one at that.

I recently received an e-book from a provider of security solutions. Their name shall remain private to me at this stage, as shall their niche. What I am going to reveal to the world however, is their utter crapness. The e-book was sent to me, I presume, for approval. I sat and read it for 10 minutes, tutting as I went, and then went to reply. The first draft took half an hour. Then I realised it was slightly offensive and saved it in my Outlook Drafts folder for later adjustment.

I picked up where I'd left off 2 days later, re-reading my draft, adjusting the text to be less rude, and then cutting out whole paragraphs. Eventually I deleted the whole thing and started again. The problem was manifold, and the amount of time I had already spent trying to pick the bones out of it was worthy of being paid. So thus I replied: "I did write up a full retort to everything in this article, but I realised that I would normally charge for the amount of work I've done on it. My main issue with the article is that it seems to have had headings written by someone who knows about security, but the paragraphs underneath were filled in by a marketing department with access only to Google."

"We've passed it back to our client" was the rather mute reply. I never did hear back, I guess my services aren't required on that one. The thing that really got to me was the laziness, no backing up of wild assumptions, repetition of useless statistics (did you know that 70% of attacks are internal! No way!), etc... the kind of crass indescribable blah that we read on a daily basis, and yet means entirely nothing.

Still, that isn't the worst piece of security I've seen this week. No, that goes to an internal project that wants to use digital certificates to REPLACE passwords. No way is that one getting through. If there is anyone out there who doesn't understand why this is a bad thing, please ask, I will gladly explain, again...

Projects march on

Following on from my last post, I've had a lot of comments suggesting various technologies for firewall monitoring and application scanning, but absolutely nothing on endpoint security.

Funny that, but I'm wondering exactly why. Is it maybe because you all assume I know enough about endpoint security to make my own decision? I think not. Is it because endpoint security is totally irrelevant to our current situation? Again, not very likely.

What I think is more likely is that it's still just too early for anyone to really have the requisite experience of these technologies to have a real opinion yet. Certainly my conclusion on the project is that we should wait. Although the action to get something to protect our endpoints came from an audit, I believe we can mitigate the risk sufficiently to pass the next audit until the endpoint/DLP market has settled down, and therefore 'sweat the assets' a bit more. I hope the business would appreciate that thought.

Therefore it follows that the project I got most feedback on - web app scanning - should be the one I concluded was the most important. Incredibly, it was. My suggestion is to make it into a real project, but try to get our outsourcer to swallow some of the cost as they do our solution design. I like the idea of getting something that checks sourcecode too, so that will form the next part of my project.

Which leaves us with the firewall monitoring. One comment, which predicted the technology which has already been suggested to solve the issues we are facing. The problem and the solution were suggested by the operational security guys, so I've suggested we pass ownership of the whole project back to them... seems simple enough.

What's really pleasing is to get my ideas out and validated by the great and the good. Glad to be back and blogging...

More e-projects

I'll come back to secure email at a later date, I'm interested to see if our business processes will come up with the same conclusions as I have. I'm prepared to admit that this is a two-sided argument, there may be a requirement for secure email, or it may be that email was never meant to be secure, so no-one will ever use it as such. Comparing it to terrestrial mail services doesn't really help, because to a large extent, email has replaced snail mail, and even phone calls. The 'more secure' version of land mail was email, so the more secure version of email is...?
Personally I think it will be as the banks are finding - directing people to portals to download (NOT giving links in the mail, but asking them to log into their account - beware of phishing attacks).

So I now have 3 new Security Projects (note the capital letters) to get on with:

1. Endpoint Security - not DLP, we don't have any data classification on our network, and it was identified specifically to stop CD burners being used on our network, so DLP is deemed too much.

2. Firewall Monitoring - thrilling stuff, we need to know if our firewall rules are sensible.

3. Web Application Scanning - Third party web app provider, variable quality of code, our problem.

I keep going backwards and forwards, depending on who I talk to about these. The higher up the chain I go, the less I want 1 and the more I want 3. When I come back to the security team, I want 2 to help them, and 1 to protect them.

I'm not sure there is a good way to justify endpoint security, not until the market has settled down a bit anyway. Maybe then we'll be ready for DLP?

Firewall monitoring seems to be something that's been put in to make someone's job easier, so again, hard to justify.

Web Application Scanning on the other hand seems to be vitally important. As I've been brought in to secure the e-commerce rollout, I think this is the one I will be most behind.

WebInspect seems to be the best (only) option at present. I'll talk more about how I get on with it once I've found the best way to justify it.

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.