An Information Security Place

Actually, this is a legitimate email, but I just about had to laugh when I saw the subject.  Michelle, I really don’t want to know.  You and Obama keep that to yourselves…

Vet

I sometimes get sick of my fellow Computerworld blogger Steven J. Vaughan-Nichols, A.K.A. Cyber Cynic.  He is an avowed Linux-phile, which is fine with me.  But he is constantly going on rants about how secure Linux is and how it’s great and wonderful and how Windows is so insecure and both sucks and blows.

But in this article he actually ends up surprising me.  He talks about a bunch of Linux boxes getting attacked through compromised SSH keys.  He goes on to say how the Linux admins that didn’t fix the problems are idiots and how he would have fired them if they worked for him.  And he is where he surprises me.  He says:

Linux really is more secure than most operating systems, but, as the security mantra goes, "security is a process, not a product."

That statement seemed so painful for Steven to get out.  I think I actually felt him straining to get those words out (maybe Steven has been eating too much cheese lately).  He actually had to admit that an admin actually had to work to make Linux secure.  Of course, he couldn’t let that go without first saying that Linux "really is more secure than most operating systems", but at least he said it.

Seriously folks, I am not some Windows fan boy.  I know I have said that a million times, but it is true.  I don’t care what OS you use.  You are ALWAYS going to have to secure it by patching and hardening.  It is the nature of the beast.  You can make a Windows box just as secure as a Linux box if you harden it correctly.

Steven is right that security is a process.  You have to do your due diligence.  If you love Linux and hate Windows, then use Linux for your server.  But don’t let that cloud your brain when it comes time to lock that box down.

Vet

I have learned a lot in the last week about how not setting expectations and not being prepared can have a huge negative affect on a project.  I know that sounds really logical and obvious.  I have seen how being unprepared can slow projects.  I have seen how not setting expectations can cause a project to totally derail.  But the complexity and importance of a project affects proportionately the level of preparedness and the level of expectations that need to be set.  You can’t walk into a large and very important project with confidence unless you have spent a major amount of time and effort.  And you can’t go into a project without knowing what is expected and making damn sure the customer understands those expectations.  It is essentially asking for disaster to strike if you do that.

That is exactly what I have experienced on two different projects last week and this week.  One was a wireless technology demonstration that is the first step into wireless for a very large enterprise company in Houston (I won’t discuss the other for fear of someone there reading this post).  The project is easily over $1 million in equipment and services, and is likely going to get close to $2 million.  With that kind of dinero  in play, and with the possibility of even more on the far back end, you have to come loaded for bear.  You have to be organized, and you have to test.  That didn’t happen (there were multiple issues and people in play, but I blame myself for a lot of it).  We had one day to prepare for a three day demo, and we didn’t make it happen.  Consequently, the first 1 1/2 days were disastrous. 

A major issue with the project was that expectations were not set adequately with the client.  They had a process for gauging technologies, and unfortunately that was kept mostly hidden from the team trying to setup the demo.  Another contributor to the problem (don’t want to call it a failure yet) was a lack of preparedness.  Under advisement from one of our wireless consultants, we had the technical team come into our local Houston offices the day before the demo was scheduled so we could do a dry run.  Though we spent several hours on that, we still were not comfortable with the results.  But we really had no choice but to move ahead because this was our one shot at the project.  Put all of that together, mix well, and bake for 20 minutes on 450 degrees, and you have a disaster pie waiting for you at the end.

But what about knowledge and flexibility, Michael??  Those words are in your title?  Well, here’s what I have to say about that.  The missing factors that would have allowed us to be successful from day one in that demo were knowledge and flexibility.  We had to end up calling in a big gun from the wireless company that had both of those factors after the original resource starting losing it.  The original engineer on the job had a good degree of knowledge (though he was still fairly new), but was severely lacking in flexibility.  When the customer went on a tangent and asked for something even slightly outside the scope of the original demo, he locked up and started making excuses (I hope he doesn’t read this, but oh well).  That did not go over well with the customer.  But when the big gun walked in a took over, that went out the window.  He knew the product well, and he was flexible.  Thus, he was able to meet whatever the client threw at him.

The other things that chaps is that if the big gun had been engaged on day one, the original problems would not have appeared.  Oh well.

So summary, you have to prepare, and you have to set expectations.  But if those turn out to be too light, or if you just run into a customer who likes to stroll down tangent lane, then you have to have a high degree of knowledge, and you have to be flexible.  They ARE the customer, after all.

BTW, the second 1 1/2 days were much, much better.  Actually, it was extremely successful.  But by then a lot of damage had been done.  And to top it off, the project lead got called on emergency meetings during the successful part of the demo, so the bad taste stayed in her mouth.  Not good.  I’ll let you know what happens.  I also plan on podcasting about this when Jim and I next get together.

Vet

I have two things to say:

1. Welcome back to the blogosphere Alan.  Great to have you back.

2. You people who screwed with him are filthy bastard racist cowards.

Vet

Here’s one of those times (link NSFW) when doing something that seems contrary to good security practices because of a legitimate business need can cause you problems.  This guy had an email account get hacked by someone, and the offender sent out a nasty email to everyone.  But the email account was for a deceased employee who used to handle customer relations, and they needed to keep the address alive so emails could be forwarded to another employee.  OK, first, that would constantly creep me out if I was getting email addressed to a dead person.  But the real point is that sometimes legitimate business needs that go counter to good security practices can cause problems.  It sucks, but that is the way it is. 

However, if there is a legitimate business need that could potentially cause security headaches, it is up to the security staff to put in a compensating control.  According to the poster, there was a real business need to have this email account alive.  So if that is the case, why didn’t they just create an alternate email address for the currently living employee instead of keeping the email account alive?  Maybe their software wouldn’t allow it, but I doubt it.  In this case, there was no compensating control.

To me, it sounds like someone just did the easiest thing (though that can be argued because they had to setup a forwarding address, which is really just as much labor as setting up an alternate email) instead of making this secure.  It’s a lesson, though thankfully they didn’t cause any terrible harm (unless you are extremely offended by dirty pictures).

Vet

I just posted over at my CW blog about the lost laptop from the company running the Clear program.  Whiskey Tango Foxtrot, over?

When you read, take a look at the quotes I found from their website.  Friggin’ classic.

Vet