An Information Security Place

…but deadly.

Vet

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 have recently created a website that will strictly host the podcast.  The site is located at http://infosecplacepodcast.com/.  The feed for site is located here.

I am not going to put a lot of design into the site.  I simply wanted a place for a separate site and feed for simplicity.  I will still be posting the podcast here as well.

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

Get your DR / BC plans dusted off if you are on the Gulf Coast in the US.  Gustav is looking like a threat.  Image from wunderground.com.

Of course, these monsters are always unpredictable, but the models are all pointing to hitting in the Gulf somewhere.

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

Here’s the latest installment of the podcast.  Jim Broome talks about some of the BH / DC talks he was interested in and rubs in the fact that I didn’t get to go (he also rubs in the fact that he was in Hawaii last week - thanks Jim).

We get some closure on the Dan Kaminsky / DNS issue (well, it was closure for us anyway).

We talk a little about Alan Shimel’s adventures in pwnage.  We are not giving any details about the issue, but we give the big guy a little sympathy and some major props for his renewed sense of security importance and writing about the whole thing so we can all see how the process doesn’t work.

Then Jim busts into his favorite two segments.  One is the Geek Toy segment, where he talks about the SanDisk Sansa TakeTV device.  Very cool stuff for the traveler.  And the other segment is the Consultant’s Corner, where Jim gives some advice for writing up and presenting an executive outbrief for a project.

The rest of the podcast is just general bantering and virtually poking each other in the ribs.  We had fun with this one.  Leave some comments on what you think.  We’ll discuss some of them in the next podcast.

Music for this podcast is:

• Digital Breaks - “Therapy”
• Digital Droo - “Minor Things”
• Laika Cres - “Miles and Miles”

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

There has been a lot of "news" spam lately with subject lines that include "CNN" or "MSNBC".  Been kinda crazy.  Thankfully Postini, which I just signed up for, has caught all of that crap.

Vet

So there is a particular security product manufacturer that Accuvant sells that I cannot name since I will get in trouble (love ya’ Dan!) that has a good product, but their support has been horrendous lately.  Actually, even their product has been slipping, now that I think of it.  And it is starting to hurt the relationship we have with a couple of customers because we recommended the product back when they were kicking some major butt all around.  And it really just pisses me off because this started just a few months before they got bought by a big company.  Oops, man, that probably gave it away, didn’t it?  Huh?  Wadda mean there’s only been about 20 companies that fit that description?  Oh yeah…

As I was saying, this started just a few months before the announcement of their getting snapped up.  This just seems backwards to me.  Does management just get that distracted that their quality starts sucking wind?  Shouldn’t they be trying to concentrate more on quality?  Maybe the deal was pretty much done and they figured what the heck?  The new guys will clean up the mess? 

I experienced that back when Juniper bought Netscreen as well.  I was a customer, and their support went straight to hell for about a year, then it all came back together.  But I kinda expected that to happen.  That was a big deal.  The company I am talking about is not that big, so there should not be a drop in quality like that.  And the Juniper / Netscreen issues didn’t start until AFTER the buy out.  This is happening BEFORE the buy out.

So if there are any manufacturers reading right now, please think about this.  If you are getting ready to sell, please do everything you can to maintain quality in your product and support.  Don’t screw over your employees (don’t know if that is happening here, but the drive of the sales team seems to have dropped dramatically).  Because if your quality drops, I am going to quit recommending you, and so will a lot of people.  Of course, if you already have your money and are at the beach, you are probably not reading this and couldn’t give less of a crap anyway.

Vet

There’s not really a flaw (that I know of), so sorry for the theatrics.  Just thought that would be a good draw. 

But really, there is a human problem from which NoScript cannot protect you.  What if you have setup a website as trusted through NoScript, then that site gets compromised?  If there is malware in the compromised site, it is possible that your trusted relationship will allow that code to run and infect you.  Yes, there are extra protections built into NoScript to protect against even trusted sites (see screenshots below), but this is still a problem if you have a site in the whitelist and it gets compromised.

This seems obvious now that I see it, but I never thought about it until Alan’s blog got compromised.  My advice would be to whitelist as little as possible and to use the temporary allow feature for everything that doesn’t cause you severe headaches.

NoScript Advance options:

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

Blackhat, Defcon, security conference, hacking, DNS vulnerability, DNS exploit, virtualization security, etc.

There, I posted about BlackHat.

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

Here’s the second installment of the podcast.  Joining me is my cohort and cohost, Jim Broome.  Some of you may know Jim from his blog.  Jim is definitely one of the more technical bloggers out there, serving up all kinds of geek toy and hacking fun.  I hope to keep Jim around a long time since he has a whole lot of experience in the security field, and he is in no way shy to talk about it. :)  Also, Jim is doing most (if not all) of the mixing and production work on the podcast since he has a lot of cool toys and has experience in the broadcast industry.  So thanks Jim!

Some show notes:

• Talk about the goals for the show
• News talk - all about BlackHat / Defcon (and how I am not going to be there - sheesh)
  • Accuvant’s party
  • Various and sundry talks that interest us
• Geek toys - ASUS EEEPC 1000H
• Consultant’s Corner - Rent the SUV… it’s cheaper!

Stick with us as we get all the bugs worked out.  I hope to bring some new perspectives and liveliness to security podcasting.

Vet

I just read a post by Mike Rothman where he is revisiting the "Big is the New Small" post he wrote oh so long ago (is it just me, or does 2 years in the blogging world seem more like 20?).  Basically, it was all about the consolidation of the security market, which is still happening, as Mike points out.

But the little nugget that Mike points out but really doesn’t give enough time to is the integration issue.  Mike says this:

There are many that cling to the "best of breed" myth. It’s even funnier when you think about folks positioning their offerings as "integrated best of breed," whether it happens on the perimeter or on the devices. Or even in security management. Integration/unification and best of breed are opposites. Oil and water. You get the picture. It just doesn’t happen.

I added the emphasis there because I think that is important.  I have seen some of these bigger companies that have a centralized management platform (especially the end-point security companies) that have bought these different products and are still trying to integrate them all into that platform.  Their vision is good as far as the concept goes.  "Let’s put all of these products into a central management console that can provide all the information in a single spot." It makes their offerings attractive to the client if it worked.  I think this is the reason a lot of people are going with some of these "bloated, unresponsive, lumbering vendors."  Some of it may be that they don’t want to work with 5 different companies, but I think that happens more often in infrastructure types of products (DLP products, now mostly owned by bigger companies, still often sell as best of breed much of the time because they each have their own strengths). 

What I see as something of a trend (though not long term because the consolidation will still happen) is that some of these shops will look at best of breed in some areas for a while because the integration they were sold has not been delivered.  I really see some of these shops not wanting "good enough" because it isn’t close enough to actually being good enough.  These products that should have been integrated and functioning smoothly by now are still struggling to get off the ground, and they are causing more management headaches.

I guess we’ll see.  Some people may continue to struggle through and wait for the promise.  But I see a lot of people getting aggravated, and they are being almost forced to make some changes in order to manage the problems.

Vet

So this post is not exactly about security, though it has ramifications in the security industry as well as virtually every other industry.  As you may know, Accuvant is a security consulting / reselling firm.  However, as the trend continues towards convergence of the network and security, we become more and more involved in infrastructure consulting and reselling.  We have a bunch of people who know how to design and implement infrastructure projects and include strong security principles along with the solution, so it actually works well for us.

Well, one of our clients in the Dallas area has used us for the past couple of years to help them build out their infrastructure as they expand.  We designed the phase 1 of the infrastructure, and now we are moving into phase 2.  Part of that phase 2 involves them installing a SAN and VMware ESX servers.  Good move on their part.  We don’t do the SAN and VMware stuff, so he brought in another consultant, namely Dell.  Our client is buying a Dell Equallogic iSCSI box and using Dell to build it and the VMware servers.

The first thing our client told us was that he wanted to connect the SAN and the ESX servers directly to the core since he had plenty of ports, there was redundancy built in there already, and he wouldn’t need to buy more switches.  He doesn’t have a huge environment, but we advised that if he was going to do that, it needed to be in a phased approach, and he needed to put additional switches into his access layer for the SAN and ESX servers when he starts approaching the next phase of the expansion.  He decided to go ahead with that since we made the suggestion, so he started looking at which switches to use.

He is an Extreme Networks shop, so we made a couple of suggestions for switches.  He went to his storage consultants at Dell, and they told him that Extreme was not certified with Equallogic and that he would need to buy Dell or Cisco switches.  Obviously that was throwing a monkey wrench in the plans.  We really didn’t want to throw other switches into this mix.  Should it work?  Yes.  But why tempt the switching gremlins?

So before we started heading down that path, I decided to do a little research.  I sat down in front of my laptop expecting a good 30 minutes or so trying to see if anyone out there had put Extreme in with Equallogic iSCSI.  Well, it took me about 2 minutes with this search to find these two articles:

http://www.equallogic.com/partners/view.aspx?id=332

http://www.equallogic.com/partners/view.aspx?id=290#e

So Equallogic does support Extreme??  Looks like they do when you see this line in the second article:

EqualLogic supports Extreme Networks’ switches.

Can’t get much more definitive than that!

So the point is that you should not always accept the word of an "expert".  it always pays off to do some research.  Yes, you should be able to use the experts advice in making decisions.  But backing that up with your own research often pays off.  Of course, if I’m the expert, then you can absolutely trust anything and everything I say as completely and totally factual.

Vet