Category: Security

Got some more info on the DDos on Bluehost.com

Got some more info on the DDos on Bluehost.com

Here’s what they sent me:

There was a SYNC FLOOD where we were only receiving ACK to our webserver, so our Rio Rey, which is our anti-DDOS box, did not reject, because it was seen as legitimate traffic. Due to the nature of the problem, we were required to block approximately half of the internet at the Cisco level.

Anyone know what this Rio Rey product is, or maybe this is just their hostname?

Vet

A day in the life of a pre-sales security engineer…

A day in the life of a pre-sales security engineer…

I have decided to start putting down some of the day-to-day events with this new job.  I think it will actually help stir my mind to blog more since I have not been writing near enough lately.  So here goes.

I have actually been kinda bored since my recent job change.  Though I have been getting in contact with our vendor partners and getting setup for training on products, the real action is out there selling and designing and proposing.  I really want to get thrown into the fire. 

Part of the reason I’m not out there yet is we do not have a sales person dedicated to the Houston market.  We need someone badly because the guy selling in Houston is based in Dallas, and he has a lot to do up there as well as down here.  However, he finally got down here today, and it got crazy quickly (be careful what you ask for).

The sales guy flew in at 9am this morning at IAH (Houston Intercontinental), but he didn’t get in my car (I was chauffeur today) until 9:25am, and we had an appointment in SW Houston at 10am.  For those of you who know Houston, IAH is on the far north side of Houston, and Houston is BIG.  I made the trip in about 25 minutes, which I was proud of.

Anyway, the talk was basically an introduction to Accuvant and what we could offer.  This was my first real meeting with the sales pitch thrown to a client, so I learned a lot (I learned even more through the day).  But to be honest, I think of the term “sales pitch” as negative.  What we did today was, technically, selling Accuvant.  However, Accuvant really has differentiated itself quite a bit from most “security” companies because of the unique approach to the industry.  I have talked about it before, but Accuvant just seems to do things right.  Yes, there are always going to be internal problems, but Accuvant just seems to be a company that takes customers seriously and at face value.  We don’t want to walk in and just sell a box then walk out until it’s time for a maintenance renewal.  We want to partner and grow with our clients, and this is no BS.  I am really impressed by Accuvant, and I know this compnay is going to succeed even more in the coming years.

OK, sorry.  Anyway, the meeting went well.  We have some strong offerings in compliance and assessment, and the client seemed to take to that well (we were talking to IT risk manager and audit types, so they loved the ControlPath product we offer for keeping track of compliance, risk, etc.).

The next client is looking at implementing Infoblox, which is a pretty sweet product in my estimation.  Infoblox offers simple and secure DNS, DHCP, IPAM, and RADIUS services in an appliance.  I have seen the box and how it works.  It is very simple.  Many companies are replacing their Microsoft-based DNS, DHCP, and RADIUS with this product, and I am seeing some great results. 

The next client was a partial introduction – I had previously worked at this client, so the intro was more for the sales guy and Accuvant in broader terms.  They are a property-management company who delas almost exclusively with apartments.  They are looking at wireless access for their tenants in new complexes, which is going to be fairly daunting for a lot of reasons that I won’t get into.  Suffice it to say that they want a lot for little.

So after that client, we went to an established client that is looking into SIM / SEM (some call it SIEM) for capturing very specific events in remote offices and centralize it to corporate (insert Rothman negative comment here).  We are putting Network Intelligence in front of them for the scalability and sheer EPS (events per second).  To put it simply, I like this product.  I might get into that at a later date.

Anyway, we left that client, located in Downtown Houston, at almost exactly 5PM.  Not a good time in Houston.  The sales guy’s plane left at 7pm, so, needless to say (but I am going to say it anyway), we were a bit rushed.  However, we found out after we got on the road that, due to a LOT of storms down here today, his flight was delayed for over an hour, so we calmed down.  Then, wouldn’t you you know it, we still made it to the airport in plenty of time for the original flight time.  I guess being relaxed during the drive helped me just go with the flow better, so driving was a lot quicker than I expected.

So, that’s my day.  It was very busy and crazy, but I finally got in the mix.  I have a lot of “action items” from these meetings, so that is going to help me get even more familiar with the products we sell.  These meetings also helped me get down our philosophy (I think that sounds better than “sales pitch”), so I will be better prepared for future meetings with clients (especially since I know I will be mostly on my own until we get a sales person down here).  Things are starting to pick up, so I got out of the house, and I am glad for that.  I love my wife and kids, and they love me (or so they tell me), but we are all getting a little tired of each other right now!

More later.

Vet

Some more info on the bluehost.com DDos

Some more info on the bluehost.com DDos

Email string between Matt Heaton (Bluehost CEO) and me on the DDos.  Not a lot of info, but here it is (start at the bottom):

 

It was directed at one specific IP, not a domain name.  The IP was a shared IP with over 800 domains on it so it was not possible for us to just block the incoming traffic to that IP.

Thanks,

Matt Heaton / Bluehost.com

On Oct 5, 2006, at 11:53 AM, Michael R. Farnum wrote:

Matt,

Thanks for the reply.  Did the attack appear to be directed at a certain site that you host?  Was it directed at a certain IP or an IP range?  I understand if you can’t divulge information, but I want to gather as much info as possible.

Thanks,

Michael


From: Matt Heaton [mailto:matt@bluehost.com]
Sent: Thursday, October 05, 2006 11:57 AM
To: m1a1vet@infosecplace.com
Subject: Re: Recent DDos on Bluehost

There isn’t really much to know.  We mitigated most of the attack even though it looked horrible from many customers side we had blocked upwards of 80% of it.   The entire attack was a total of more than 8000 ips all originating in asian countries with Japan, and Taiwan being the majority of the attack.  It was sending more than 800,000 packets every 5 minutes and consuming more than 350 Mbit of bandwidth.  It was a HUGE attack.  I hope this helps.

Thanks,

Matt Heaton / Bluehost.com

On Oct 5, 2006, at 6:02 AM, Michael R. Farnum wrote:

Matt,

I couldn’t get to my website (infosecplace.com – hosted at Bluehost) because of the DDos on one of your servers yesterday.  My website is a blog dedicated to Information Security, and I would love to write about this incident.  Is there any way you would be willing to share some non-confidential information on the incident so I could have kind of an “exclusive”?

 

Not sure how this squares with this email from Bluehost support:

We are currently experiencing a DOS attack on this server, and so we have blocked a portion of the internet from being able to access the server. If you are in one of the IP octets that were blocked then you will not be able to access the server because our router is blocking you. Once the DOS attack stops you will be able to continue accessing your site.

Obviously I am not working from Asia, so I don’t know why I would have been blocked.  So I think that explanation was bogus at best and just meant to keep people off their backs.  So my site was definitely down to more than just me.  But that’s what support lines do, right?  Obviously, they didn’t know they were dealing with a man of superior intellect and a keen sense of information security!!!  Right….

Vet

Why aren’t NAC vendors buying patch management companies?

Why aren’t NAC vendors buying patch management companies?

So McAfee is buying Citadel.  These guys have got the right idea.   If McAfee can integrate this into  their NAC solution to a point where the desktop has automatic patching when it is sent to a remediation zone, then I will recommend McAfee to everyone.

Furthermore, I still cannot understand why in the world other NAC providers don’t buy a Citadel and integrate it into their NAC solution.  I asked for this CONSTANTLY when I was in security operations, and no one had it.  I cannot be the only guy asking for this. 

Vet

Bluehost.com was DDos’ed yesterday

Bluehost.com was DDos’ed yesterday

It looks like at least one server at bluehost.com was DDos’ed yesterday.  Bluehost.com hosts my website, so I was unable to reach my site for most of the day.  They said that the site was up, but they had to block large segments of the Internet from which the attack was coming, so I guess I was on one of those segments.  If you couldn’t get to infosecplace.com yesterday, then you were also on one of those segments.

I am trying to get some details about the attack and will let you know if I get any details.

Vet

Determina and ZERT blur the third-party patch definition a bit

Determina and ZERT blur the third-party patch definition a bit

I have stated that I do not like thrid-party patches.  Here are some reasons:

  • It can open other avenues of attack, since the bad guy is likely to start studying the thrid-party patch for security holes. 
  • Potential problems caused by the unofficial patch when installing the official vendor patch
  • Management headache of uninstalling the unofficial patch
  • Possibly causing support problems with the vendor because of unofficial patch
  •  

    Now, there is a possibility that one of these reasons may no longer be an issue.  SC Magazine has an article talking about the new MSFT flaw and the patches that have been released byDeterminaa and ZERT.  Both of these organizations claim that their patches do not need to be uninstalled to apply the official MSFT patch.  If that is true, then the third issue from the above list is a non-issue.  Now, that “if” is really big, and you would have to limit your patching to those organization that build their patches in such a manner.

    Now, I know something about Determina.  I have seen this product installed, and I know basically how it performs.  Essentially, it creates a shield around processes in memory, almost running each process in its own virtual memory space.  It then does not allow any unauthorized access to those processes.  It is basically a host-based IPS, but it does not rely on signatures to stop attacks.  It is a pro-active solution, and from what I have seen, it is a good product that allows you to relax your patching posture.

    However, if they are fixing the flaw in the same manner, then they are not actually patching but are actually just shielding your system from the attack.  So I would not call this a patch at all.  However, it does work.  To test it yourself, first go here to test if your browser is vulnerable.  WARNING: if your browser is vulnerable, then it WILL crash.  I have run the test, and it DOES crash your browser (of course, you’re fine if you are running Firefox, which I suspect many are that are reading this blog).  Now that you have seen it crash, you can go download Determina’s “shield” from here.  Run the MSI.  Close all instances of IE, then go back to the test site and run it again.  You should not be affected this time.

    I did not run the ZERT patch (if that is what it is) because it looked a lot more complicated in its execution and I did not want to risk it.  The Determina fix was packaged neatly in an MSI as well, so I have to believe that it is much easier to push out than the ZERT fix.

    So make your own judgements with this new breed of third-party fixes / patches / shields.  I still don’t advocate them completely, but if they work as the Determina and ZERT fixes claim, then I am less hesitant than before. 

    Vet

    Ignorance and naivete

    Ignorance and naivete

    In my previous stint for a reseller, I was in the trenches doing implementations with very little pre-sales work.  But now, in an almost pure pre-sales engineering role, I get the benefit of seeing things from a reseller’s point of view and the manufacturer’s point of view.  Instead of having my head down letting all the sales people play their games, I get to be right in there with ’em.  And I am getting to see a world that I have never seen.

    I knew there were a lot of things about the IT and security world that I did not know.  I know there still are.  But the distinctions I find between the end-user world (security and IT management) and the reseller and manufacturer world are spectacular.  And to be honest, even though the differences are obvious, it is hard to put a finger on it.  Really defining it is difficult.

    I guess it may come down to the basic pressures of the job being different.  A security or IT manager has day-to-day pressures of taking care of a network and the staff that runs it.  A sales person (even a sales engineer) does not have that constant pressure.  So the intensity in the look just doesn’t seem to be there.  Yes, the sales folks have to meet quota, but that’s not a constant, daily driving force.  Deals usually come in bits and spurts.  Thought the sales person always wants that next deal, the over-arching responsibility of a day-to-day operation is not there, and it shows.  Even the sales engineer, who many times has been in the shoes of a security or IT manager or admin and has dealt with those pressures, knows that the anxiety of operations is not there, and it shows there as well.

    I know I will learn more differences over the coming months as I get used to the job.  And I know that I will not be able to share some of those differences (I can’t give away all the secrets - my boss reads my blog sometimes).  But if I ever do get back into security management, I know the knowledge will serve me well.  Not that I plan on leaving any time soon.  This is too much fun!

    On the SSAATY Podcast – Selling Security UP!

    On the SSAATY Podcast – Selling Security UP!

    I forgot to mention that I was a guest panelist on Alan Shimel’s SSAATY podcast last night.  This was a great panel.  I had a great time, and I think we really hit some key points and offered some solutions to security admins and managers out there that need some help selling security to execs.

    The panel consisted of yours truly along with Martin McKeay (Network Security Blog, ComputerWorld), Bobby Dominguez (Sykes) and Mike Rothman (SecurityIncite, NetworkWorld).  It was hosted by Alan and Mitchell, two of the best podcast hosts I know, and though I have never met either face to face, I know they are both good guys.

    One person that was scheduled but ran into some emergency security management duties was Michael from mcwresearch.com.  I understand why he couldn’t be there, but I really missed his insight.  I would have loved to hear some of his horror stories.

    BTW, I was VERY impressed by Bobby Dominguez.  I have never talked to Bobby, but I figured out very quickly yhat he has a vast amount of experience, expertise, and just plain ol’ smarts.  You REALLY need to listen to this guy.  Hopefully he will start a blog soon himself.  He has a lot to offer the community.

    Martin is always good to have on a discussion like this because he has a lot of experience in this area.  He never ceases to impress.

    And Mike Rothman, well…, he’s Mike.  What else need be said?  And we actually agreed on something in the podcast, if you can believe it!  Actually, Mike and I agree on a lot of things.  We just like to disagree to make it exciting.

    And of course, there’s me.  ‘Nuff said! 🙂

    Anyway, the podcast should be up soon.  Go look for it in the next few days at Alan’s blog.

    Vet

    Karn says we should all get out

    Karn says we should all get out

    Karn Griffen over at the the Information Security Gurus blog mentions my post about getting out of security management.  He has a good post today about how we should all be getting out of the front lines when there are so many possibilities with outsourcing.  He also commented on that same post, where he said the following:

    If I can turn on secure networking services, complete with IPS, Virus, Spam filtering, etc. and the company I outsource this to will provide me an SLA that guarantees the service parameters I’m looking for, why would I bother with a full-time person (or more) to do these things.

    While I agree with Karn on this point, the question that comes to my mind is if you can’t convince an exec that security is needed at all, then why would he  / she do either?

    The big problem is that execs often cannot justify security at all as a cost.  The ramifications to not spending money on security are still so light.  Much of the legislation out there still does not have teeth.  The media is getting tired of printing stories about this stuff because readers are tired of it.  Some non-governmental regs like PCI are starting to get somewhere, but that is not anywhere close to where it needs to be.

    So unless you can convince your execs that security is needed, they ain’t gonna spend money on it, no matter if you outsource or insource it. 

    But let’s play devil’s advocate here and assume that all exec’s get smart and buy off on security.  Then, the SMB exec’s get even smarter and see Karn’s point that they can outsource.  Where does that leave guys like me getting out of operations and trying to sell security?  Should I be selling to SMB’s now when I know they would be better served by outsourcing?  Do I sell to MSSP’s?  Better yet, do I have to start working for MSSP’s, sitting in a chair watching packets go by?  Do I lose even that job to ever-more sophisticated UTMs / IPSs / heuristic filters that can figure this stuff out better than I can?  Does the UTM take over for those MSSPs where there are only 2 or 3 viable options for them to filter traffic for their clients, essentially killing much of the security market?  Are the enterprise-type clients enough to hold up the market?  Does the technology get so good that even enterprise clients can use it?  Does my job just go POOF in 5 – 10 years?  AAAAAAAHHHHHHHHH!!!!!!!!!!!

    Karn, you are on to something, but I’m not sure it’s good.  But good or not, is it inevitable?

    Vet

    Juniper / Symantec

    Juniper / Symantec

    OK, let me start this out with a disclaimer: I am going to work for Accuvant (as most of you know by now since I can’t stop blogging about it), and they are a big Juniper reseller.  They do not sell Cisco, so they drink the purple Kool-Aid.  Also, I am a fan of Juniper when it comes to many of their security products (I love their SSL VPN and their firewall / VPN devices, but their IPS leaves something to be desired).  All that being said, you might think I am going to say something positive about this deal between Juniper and Symantec.  Well, you’re right and wrong.

    First, I agree with Mike Rothman’s comments:

    …adding Symantec’s anti-spam, IPS signatures, and vulnerability research to Juniper’s products will make them better and I think it will actually happen. Why wouldn’t Juniper do this, given they are pretty much irrelevant in the IPS space and don’t really have a compelling UTM platform? They’ve got nothing to lose.

    I also agree with Mike that this mostly comes from a “We Hate Cisco” reaction.  I don’t think Cisco is the best out there in most things that they do.  They do many things decently, but they are not the top in quality.  But they ARE Cisco, and they are taking so much of the market for the simple fact that nobody ever got fired for buying Cisco.

    The fact that Richard Stiennon hates this deal is not surprising.  Stiennon is negative on just about anything that ever happens in security nowdays simply because he doesn’t agree with the direction security is taking, namely “host plus network security”.  However, his perspective that Juniper and Symantec have not taken advantage of opportunities given to them is correct.  Symantec is the epitome of the “bumbling giant”.  I don’t think Juniper is anywhere close to that yet, but Stiennon has to lump them in because, again, he is negative about anything to do with NAC, UTM, etc.

    I don’t like this deal because it is with Symantec.  I just don’t like how Symantec works and I don’t like John Thompson (especially after his keynote at RSA 2005).  But I like this deal from the fact that it can help Juniper leverage Symantec’s knowledge.  Juniper NEEDS to become a premier security knowledge source on the par of Symantec or TippingPoint if they ever hope to be completely respected in this arena.  Building boxes ain’t gonna do it.  What I am hoping is that they use Symantec to maybe help them learn how to do this themselves.

    Vet

    One of the reasons I am getting out of security management…

    One of the reasons I am getting out of security management…

    …is crap like this.  I am honestly tired of having to worry about keeping up with the latest security flaw and making sure my IPS has the latest filters and trying to make sure my network admin is keeping the patches up to date and yada yada yada.  It just gets old.

    A while back, I published a list of all the things I do on a daily / weekly / monthly basis as a security manager.  When I look back at that list, I am seeing about nine tenths of it as reactionary chores.  And I am tired of being in such a state of constant reaction, even when I do everything I can to be proactive.  It just gets old. 

    I realize this may sound discouraging.  Believe me when I say I don’t want to give up the fight.  I just want to help some other people fight the fight instead of being on the front lines every day. 

    When I first thought about it, it kinda felt like the front line troops were going to lose a man to battle fatigue.  But to clarify by carrying the military analogy a little further, think of me as a REMF (ask your military buddies – they know what that stands for).  Basically, REMF’s are the people who sit in the back away from the front lines.  They drive fuel trucks, they fix broken vehicles, they cook food, deliver MRE’s, deliver ammunition, etc.  They are support.  They don’t always get a lot of respect.  But without the support the REMF provides, the grunt, the M1A1 tank crewman, the Apache pilot, and the howitzer gunner can’t fight the fight.  So you gotta love the REMF, even if he is not looking at bullets every day.

    It may sound like I am trying to convince myself that I am making a good move, and to some degree I probably am.  I know this is the move I am supposed to make.  I feel that deeply.  I just want people to know that I am not giving up.  I am just moving to the back lines.  Is there some fatigue?  You betcha.  But I am not going to be the guy who Patton slaps.  I’m gonna be the guy driving the ammunition to the front line so you can shoot at the bad guys.

    Of course, if the guy who brings the ammunition had to convince the tank commander every time that his ammunition was better than that other guys ammunition, and that his ammunition fit better in the gun tube and would make pretty lights when he shot it down range, then our military would be in a bad way.  OK, so maybe the analogy doesn’t play all the way through, but work with me here, OK?

    Vet

    The Security Collision

    The Security Collision

    Let’s look at a scenario. 

    Most security managers will limit the ports users can use going out to the Internet.  You typically allow http and https, and maybe ftp. It just doesn’t make sense to allow “Any” out to the Internet.  This will limit your attack vectors by not allowing IRC and other such dangerous protocols.  There are also other things you can do to block what the firewall won’t see (protocol blocking, proxying, layer 7 filtering, etc.).

    In the same manner, most organizations block incoming ports as well if they are not needed.  Why allow http or ftp traffic in if you don’t have a web or FTP server?  But if you do have these types of servers on your network, you might implement another layer of security by using non-standard ports on your webservers to help combat ID theft and other attacks.  Basically, instead of using port 443 for SSL, you might set something like 8000 or 8700 or 8900…  And many security admins and managers attest to the success of this approach.  They claim to see fewer attacks because your typical script kiddy is going to be using scanning tools to look for standard ports and will just skip over those sites without those ports.  Makes sense.  Colleges and universities are a big advocate and user of this approach.

    But what about the security admin / manager who practices limits the ports his users have access to but also has a user staff with a high percentage of professionals who have to access those very schools and other organizations that implement this type of security by obscurity (SBO)?  Many are working on their degrees.  Many are researchers that have regular access into university networks.  These are legitimate needs for these types of professionals, so he can’t say “too bad, do your work at home”.  If they were all accessing one or two different networks, then no big deal, but it just ain’t that simple. 

    What you have here is a “security collision”. 

    Basically, the security manager of the organization with staff trying to access these sites using SBO has to open ports to allow the traffic.  But then you cause potential security problems because malicious insiders and malware (bots, etc.) might take advantage of those ports.  So you try to limit that exposure by narrowly defining the policies by using specific source and destination IPs in the policy.  That becomes a headache quickly because of the sheer number of policies this has the potential of creating.  So what is this security manager to do?

    Looking at this narrowly, SBO raises it’s head as the issue.  I have spoken for SBO in the past, and I continue to think it is a legitimate tool in the security managers arsenal.  Some people argue that if you have appropriate security measures in place you won’t need it.  I contend that SBO can be one of those “appropriate security measures” and you should have layers.  But it can cause headaches for others.  Should that deter the security manager from using it?  Probably not.  You have to look out for you data and network first (and if some admin from another company calls me and starts griping that I am using non-standard ports, and it is causing him headaches, he might find himself on the “blocked IP” list quickly). 

    However, the above scenario is merely an example of the problem.  There are other security collision problems out there.

    Another example is caused by the fight against spam, namely reverse DNS lookups.  Here is an excerpt from this 2004 Security Focus article:

     

    1.4.1 Host-less and vanity domains

    The reverse lookup approach requires email to originate from a known and trusted mail server located at a well-known IP address (the reverse-MX record). Unfortunately, the majority of domain names are not associated with static IP addresses. Omitting cyber squatters, the general case includes individuals and small companies that want to use their own domain rather than their ISP’s, but cannot afford their own static IP address and mail server. DNS registration hosts, such as GoDaddy, provide free mail forwarding services to people that register host-less or vanity domains. Although these mail forwarding services can manage incoming email, they do not offer free out-going email access.

    Reverse-lookup solutions cause a few problems for these host-less and vanity domain users:

    • No reverse-MX record. People sending email from a host-less or vanity domain simply configure their mail application to send email from their registered domain name. Unfortunately, a lookup of the sender’s IP address will not find the sender’s domain, and a lookup of the sender’s domain may not find the correct reverse-MX record. The former is particularly common for mobile, dialup, and other users that frequently change IP addresses.
    • No outgoing mail. One possible solution requires relaying all outgoing email through the ISP’s SMTP server. This would provide a valid reverse-MX record for sending email. Unfortunately, many ISP’s do not permit relaying when the sender’s domain is not the same as the ISP’s domain.

    In both cases, someone that uses a vanity domain, or a domain that does not have its own mail server, will be blocked by reverse-lookup systems.

    This may not be a huge problem, but I have seen a couple of problems caused by this over my years in IT and Security.

    Many people would say that these problems can be fought by sticking to standards, but baddies often rely on us doing that to make their job easier.  That is seen specifically in the first example.

    I am not trying to create FUD here – these are just things I see in my job.  In reality, I do not think this is some gargantuan issue that we need to start putting a lot of effort into.  I think it many of the security collision issues have to be taken care of on a management level.  But it something that I and other security managers have to deal with on a fairly regular basis.  So what can we do?

    Stop waiting for an answer… I’m asking you! 🙂

    Vet

    Apple needs to learn the hard way

    Apple needs to learn the hard way

    Thanks to the SecurityCurve blog for posting this about Apple.  The Mac users are going to get hard one day, and they are not going to be prepared.  Yes, many of them use AV software, but my suspicion is that many do not run it because they don’t see a reason for it.  Take a look at this post to see if you think I am wrong.  Though the author admits that it may happen one day, he is just so smug (to use SecurityCurve’s analogy) that his Mac is just wonderfully immune right now.

    What I see is this: Malware is more and more specific now days.  It is written for monetary gain, not for kicks (it is possible someone may write something just to prove Apple wrong, but who knows).  Apple will get more and more of the market.  Their servers, because more people are using Macs in business, will start to get more popular (just like with Windows).  Then more and more valuable data will be stored on Apple servers, and the possibility of monetary gain will increase.  So the possibilty of malware will increase.

    Vet

    Third-party patches – not a good idea

    Third-party patches – not a good idea

    This story talks about using third-party patches for security flaws instead of waiting for the vendor to put out a patch.  Personally, I am dead-set against it (I posted a while back about it, but I am too lazy to go look for it) for the same reasons the security pros in this article are against it. 

    • It can open other avenues of attack, since the bad guy is likely to start studying the thrid-party patch for security holes. 
    • Potential problems caused by the unofficial patch when installing the official vendor patch
    • Management headache of uninstalling the unofficial patch
    • Possibly causing support problems with the vendor because of unofficial patch

    And I am sure there are more issues.  One of the main points brought up in the article is that if you have a good defense-in-depth infrastructure, you can maintain good security without the need to install patches right when they come out.  One comment struck me:

    Using a mitigation strategy like blocking certain ports or shutting certain programs is the better solution. The user may have to go without a feature for a week, but it’s better than taking a risk with a third-party fix that you then have to go and uninstall before installing the real patch.

    I couldn’t agree more.  And if you have a good IPS vendor with a quick signature turn-around, then you can probably have the ports turned back on or the features back in operation much quicker.

    I talked about this on Alan Shimel’s podcast a few weeks back as well.  He asked me what Patch Tuesday was like for a security manager like myself, and I besically told him that it was no big deal really.  I trusted in the security I had in place.  I’m not saying I’m invulnerable.  But locking down the infrastructure and paying attention to current threats and responding to them in a timely manner is the key to stop attacks before patches are available.

    Vet

    Some of the reasons I write a security blog

    Some of the reasons I write a security blog

    Just some random thoughts here on why I write this security blog:

    1. Simply, I enjoy writing
    2. Simply, I enjoy security
    3. I enjoy people reading and commenting on my opinions
    4. It might make me famous one day!
    5. It helps me become a better security professional because I have to research to write viable and informed opinions
    6. It helps me to become a better writer
    7. I get to meet great people (Martin, Alan, Mike, Chris, Mitchell, etc.)
    8. It gives me something to do when I am up at 1am in the morning (I need to go to sleep)
    9. Looks cool on my resume
    10. Some other stuff

    Vet

    Mike doesn’t like my SIM log format post – bull shitake!

    Mike doesn’t like my SIM log format post – bull shitake!

    Mike Rothman takes issue with my SIM post.  Basically, I said that it is a good thing that Arcsight is trying to create a standard log format for SIM’s. Mike disagrees. 

    Let it be known that I DO have a SIM in place now, and I have received some value from it.  I think the value that anyone gets from SIM depends a lot on how your environment and how the SIM is implemented.  This is the same as any security product.  Is SIM living up to it’s expectations?  No, it is not.  I agree with Mike on this point.  But I do not believe that SIM is dead. 

    So I stand by that assertion that a common reporting standard for security appliances is a good thing, though I agree with Mike that it will be years before this has any real benefit because of the delay of vendors to move on such things.  I also agree with Mike that SIM does not meet expectations right now.  Vendors very clearly point out what their product will do and then steer away from those security appliances and products that it will not support, so the ol’ bull shitake meter definitely hits the high scale when they try to push something on me.  But I don’t think it is a lost cause necessarily.

    Here’s a quote from Mike about SIM:

    It’s all about being able to 1) prioritize efforts and remediate faster, and 2) crank out a report to keep the auditor happy. 

    The point is that if we can get a common standard, number one can be met.  Should we just throw out SIM if there is a possibility of having a standard that may give us what we are asking of SIM now?  No, I don’t think so.  There can be some value now if, again, you implement well.  But the problem here is what Mike says about the timing and when we would see value.  So if you do not have a SIM yet, I would say do a LOT of research before getting one, and I would possibly recommend against it at this time (and with the advent of UTM’s, you may not need to get one if you go that route).

    On point two, I think Mike’s really big analyst’s hat is getting in the way.  He is forgetting about us little people!  Auditing is a REALITY that I and my fellow security managers have to deal with.  I am all about securing my network and getting everything else out of my way.  If I can satisfy and auditor and get him out of my hair by producing a report from a SIM, I am damn sure going to do it.  If a SIM makes ’em happy, then I will spend the money.  That is value to me right there!  That may not sound fiscally responsible, but the less I have to answer questions from some dude who is reading off of a script, the more time I have to actually do my job.

    So overall, I disagree with Mike that the common format is not a good thing.  I think Mike is trying to throw out SIM when there is a possibility of it actually giving a lot of value later down the road.  But if you do not have SIM now, take a long, hard look before buying.

    Vet

    Reporting standard for SIM needs to be adopted

    Reporting standard for SIM needs to be adopted

    You’ve got anywhere from six to 60 security applications and tools in your data center, and most of them work pretty well. There’s just one problem: None of them speak the same language.

    ArcSight today attacked that problem by proposing a new log management standard, the Common Event Format, that could enable security devices and applications to present and exchange event data in a common way. The net result: Security managers might soon be able to analyze security incidents from a single screen, without plowing through event logs and data on a dozen different apps or appliances.

    Amen brother.  SIMs were supposed to fix so many problems by pulling logs together and alerting on them.  But so many devices that spit out syslog messages use different formats, and then the SIM vendor has a choice: either partner with every security vendor out there, or partner with a few but accept syslog and make you create your own alerts.  Something needs to happen, and badly.  This os one of the reasons security management outsourcing is becoming so popular.

    Vet

    What I read in security

    What I read in security

    Since I started blogging, I’ve seen a few people post what blogs they peruse. I guess I’ll hop on that train as well, especially since I just learned how to export my OPML file out of BlogBridge and import it into Bloglines.

    There are 60 feeds (this includes news and blogs) pertaining to security that I read. Some of these are rarely updated, some are fairly consistent, and some are in between. Many are common. Some are fairly new and haven’t gained much traction yet. But the sheer amount of opinions and data there is astounding, just in 60 feeds.

    So take a look my public Bloglines feed list if you have the inclination.

    Vet

    Stock Spam

    Stock Spam

    I saw this article about the rise of image spam, and I started thinking about the image spam I have been receiving. A very high percentage of it (for me) has been stock spam, just like in this article. And the author of the article mentioned that there was a rise in the value of the stock (almost 28%) from the previous day’s closing. This obviously could have been a coincedence, but it got me to thinking.

    So, I bought a few penny stocks, connected to my IRC server, got a few bots going,…oh, wait. Sorry, my nefarious personality just reared his head.

    Anyway, I thought it would be cool to track the effectiveness of stock spam. Does this actually work? It certainly seems plausible. Unfortunately, I delete all the spam that comes in to me, so I don’t have a good record. I thought I would hit my email gateway’s message log and filter on “stock” to get a list, but that doesn’t work too well because the spammers don’t usually include the actual word “stock” in their emails, and it definitely doesn’t work in image spams.

    So, what to do? I don’t want to have to wait too long to gather a bunch of spams, especially since my filter seems to be performing better since I did some tuning. So, I thought I would look around the net for something. Lo and behold, I am not as an original thinker as I thought. Take a look at this site.

    Here’s a quick screen shot as well.

    Basically, this site is showing the short term gains that a lot of stocks show when a stock spam comes out. It is interesting, but this site shows that almost every stock that has been spammed shows a long term drop. This didn’t surprise me at all, but it is still an interesting point.

    Go here to see an excellent FAQ about stock spam and here to see a list of spam-advertised stocks (both of these are also linked at the first site above).

    Vet

    Security ROI

    Security ROI

    I just read this post by Richard Bejtlich at Taosecurity. Basically, a guy was trying to come up with an ROI for security, trying to show management where security adds value in actual dollars. Richard is correct that there really ain’t no such animal.

    I have never figured out a way to show my CEO or CFO value for putting in an IPS. I can show how it fills a security gap or helps us comply with HIPAA (though when you come up with a concrete definition for that one, let me know). But I cannot show him that the IPS will pay for itself by adding value to our company. Like Richard points out, security is insurance. The IPS will only pay for itself if it prevents an attack that would have cost the company more than what we paid for the IPS.

    Of course, the problem with that argument is that you never really know what an attack would have cost you. Yes, you can quantify an asset and tell the CFO that it will cost the company $50,000 if it is lost. But not many execs put stock in something that MIGHT happen or what it MIGHT have cost. They want numbers.

    Vet

    Bump key video

    Bump key video

    Watch the video below.  I have heard and read some stuff about this, but this video really tells the tale.  It seems professionally done.  The people all seem very genuine and not actors, or they are very good actors.

    Just a few of my thoughts on the issue:

    • This is from a foreign country, so I don’t know if the insurance issues are the same here in the states, but basically the concern was that if there are no signs of burglary, then your insurance company won’t pay a claim.
    • The claim was that this was the end of security for physical locks.  I think this is a little bit of the ol’ FUD game, but hearing it from an experienced (30 years) locksmith makes you think a little bit.
    • It brings out the need for layers in security.  An alarm system is a fairly good layer, even in houses.  At least it will deter some low-level crooks, which are your typical crooks in home burglaries.
    • When it comes to businesses, they will need to start looking into alarms and better locks (keypads, etc.)
    • And the overall lesson, no matter what you do, if someone is determined to break in, they probably will.  All you can do is your best.

    [gv data=”7Uv45y6vkcQ”][/gv]

    Has the VA ever done a risk analysis – How about some disclosure to the public?

    Has the VA ever done a risk analysis – How about some disclosure to the public?

     

    The VA is now buying encryption software for their  computers, handhelds, and other mobile devices.  This makes me wonder about a few things:

    1. Are they also installing it on their subcontractor’s computers?  The last theft of VA data happened at Unisys, not at the VA.  How are they going to handle that?
    2. Have they EVER done a risk analysis?  I ask this because it would be interesting to see what the analysis said about remote laptops, computers, etc. before the thefts.  Did it show there was risk of this happening?  Did they actually weigh the risk and decide it wasn’t a big deal?
    3. My suspicion is that they never ran a risk analysis.  So have they run one now?  Are they just knee-jerking?  Was this process under way before the last theft, or have they gone about this the right way and they just have bad timing?

    Even though a risk analysis is always needed, the results are not always correct.  Even if you go about the process in the most scientific manner, you always need to plan for contingencies and the possibilities that your results are either not right or the smallest risks will still happen.

    In this case, if the VA did run a risk analysis before the thefts, then they either ignored this risk or deemed it not enough of a risk to worry about.  Though we see it as an obvious risk, and though the many, many stories of laptop theft happening out there before the VA incident make it even more obvious, the VA still did nothing.  That’s why I think they either never had the analysis done, or they simply did one to fulfill requirements then ignored the results.  Both are deplorable practices.

    I would really like to see some better disclosure from the VA.  Don’t give me the results of your risk analysis.  Just let us know that you are performing one.  Just like this event, make an announcement that you have a company coming in to help with this and name the company.  Even though you have an obvious hole with the laptops and desktops, you still need to perform your due diligence in making your security holistic  Do not just piece some security measures together to make everything look good to the public.

    Vet

    Keyloggers on clients’ computers cause bank to get in trouble by press – HUH?!

    Keyloggers on clients’ computers cause bank to get in trouble by press – HUH?!

    Martin McKeay posted a few days back about keylogging software on client’s of HSBC Bank.  Bruce Schneier pointed out this article this morning about the same issue.  Both came to roughly the same conclusion: this is ridiculous.

    Yes, there are things the bank can do to help with this, but come one, where is the personal responsibility for the clients?  Sheesh.

    Vet

    New SmartChip Passports to start rolling out

    New SmartChip Passports to start rolling out

    Read the story here.  It looks like the process is being held up now because of legal challenges from another company that thought they should win the project.

    I have held out commenting on this so far because I don’t have the expertise here to add much of value.  But what does concern me is that the company they are awarding the contract to is a an affiliate of a German-owned company.  That sounds about as smart as giving up the dock security to an Saudi-owned company.

    Vet

    My “NAC Happy Week” chime in – Please give me remediation!

    My “NAC Happy Week” chime in – Please give me remediation!

    Like Mike Rothman says today, this has been the week of NAC, so I figure I would pile on as well.  I am not an expert on NAC by any means, so forgive me and correct me where I need it.  But in talking to Alan Shimel and his StillSecure crew this week and with all the bloggers putting out some great information, I have learned more about NAC this week than I have in the last year.  BTW, a bunch of my blogging buddies and Richard Stiennon got together last night on the Security Roundtable Podcast (hasn’t been posted yet) to discuss NAC, so I am really excited about listening when it gets posted.

    Anyway, to my gripe of the day.  I had a NAC vendor out today to discuss their product.  They have gone totally with the inline strategy for their solution, and it seems like a good product.  But it has weaknesses (obviously everyone of them have strengths and weaknesses).  Some of what I saw was poor ongoing posture checking, so-so unmanaged-client checking, opening of ports to allow authentication, and no remediation after quarantining.  And they partner with other vendors to do some of the stuff above.  That’s not in-and-of-itself a problem, but I just didn’t like the way they threw it all together.  To be fair, they had one feature that I REALLY liked, and that was the ability to do auditing and reporting on client file access without (so it seems) the need to turn on auditing on your servers (basically, they go to level 7 and report from there – if it works, it would be great to have because it means less CPU cycles, less disk space, and less configuration on servers – anyone else do this guys?).

    I have looked at a few other vendors out there as well, and as I parenthetically said above, they all have weaknesses and strengths.  Many times, it really depends on your infrastructure and what you need.  And it may take more than one vendor to get done what you need.  Though management starts sucking bad, right now this may be the only choice we have to get a complete solution (go see Alan’s point in his post about cobbling together a bunch of security vendors for a NAC solution -  I hope he is right that this will start going away). 

    As a quick aside, I am going to compliment StillSecure, and it is not because Alan had me on his podcast (well, maybe a little bit).  StillSecure’s Safe Access, thus far, seems to have the most complete solution out there (Alan, send the check to my personal address please). Now, back to our regularly scheduled program…

    But one weakness or missing part or whatever you want to call it that I see across the board is the remediation of the vulnerabilities for the endpoint.  What I mean by that is that I have not seen one of the NAC solutions that includes a remediation solution.  They either partner with someone (which also seems to be going away somewhat), or they leave it up to the “discretion of the administrator.”  So please answer this question for me, oh you Alan’s and Mitchell’s of the NAC world: wattup wit dat?

    I mean, I just don’t get it.  I am not speaking for the rest of the security managers out there, but I know that it just makes sense to me for someone who is going to offer quarantining to offer remediation as well.  Is it because no one has made it that far?  Is it because the market is not asking for it?  Is it because there are options available, so you just don’t want to spend the dollars to do it?  And if you are going to partner with someone for it, INTEGRATE IT.  Don’t make me manage another solution.  Tie the dang things together, and make it work.  Remember my busy security manager post?  We need help!  Give us a solution that works from A to Z.  Not A to W, then BigFix can handle X,Y, and Z (now I’ve said my ABC’s, next time won’t you…  sorry, too much Sesame Street – I have small children).

    [As I was writing this, I wanted to make sure I wasn’t smoking crack, so I looked closer at SafeAccess and noticed that it mentions tying together patch management with SafeAccess, and I think this happens through VAM, but I am not sure.  I invite Alan or another StillSecure employee to clarify this.]

    Vet