I just talked with a client who had been using an unnamed “take down service provider” for some time now. These vendors specialize in removing sites used in phishing attacks and drive-by-download attacks from the Internet. Many claim to have elite connections at various hosting providers that they can call upon to quickly remove sites from production.

Using a take down vendor is basically a bet on outsourcing. You are betting your payment to them that they can get a site taken down with less time, damage and effort than you could if you were doing it yourself and that working with them will reduce your time requirements in periods of incident response, when cycles are at a premium. In the real world, however, many times these bets may not pay off as well as you might think…

For example, take down companies that really have a lot of clients, may have a number of cases and sites that they are working at any given time. If they don’t sufficiently staff their teams at all times, there may be long delays caused by resource constraints on their side. Getting them “into action” is also a complaint about more than a few of these vendors in various infosec forums. Often, their customers claim that getting the information needed by the take down vendor to get them to investigate and act is basically about the same amount of hassle as working with registrars and hosting providers to get sites taken down.

Of course, not all take down vendors are difficult. There are a few of them out there who get glowing reviews by their customers, but a little quick Internet research showed there were a lot more that got bad reviews than good. In addition, the old adage of “you get what you pay for” seemed to apply to the quick checks we did. Many of the lower cost vendors did not have very good commentary about them and the bad references seemed to diminish as you went up the pay scale.

Another tip from a client of ours was to beware the take down vendors that want a retainer or monthly fee. You may only need their services a few times a year and you are likely to save money using a per-occurrence approach over the long run. Additionally, the monthly service fee vendors also appear to be some of the most commonly complained about – likely because they may have a tendency to oversell and under staff in the ebb-and-flow world of incident response.

The bottom line is that take down vendors may be of use to you or they may not be. Identifying your needs and internal capabilities are good places to start. If you do choose to partner with a take down vendor, make sure you do your research and that includes customer references, Internet searches and pricing comparisons. You can probably find a couple of vendors to fit your needs and your budget. It would probably not hurt to give their response line a call before the purchase as well and see just what level of service you can expect.

BTW – my original client that started this discussion found that simply opening a call and trouble ticket with the ISP was enough to get them to accept incoming take down requests with lists of sites in near real time via email or fax. The couple of folks I talked to who have been through this said that many of the largest ISPs and hosting providers have gotten a lot easier to work with and more responsive in the last couple of years. They suggested that if the attacks seem to revolve around large, common providers – you might want to take an initial stab at talking with them and if they seem to be responsive and engaged – save your incident response budget and work directly with the providers. Save your take down dollars for those obscure, hard to reach or unresponsive providers.

It’s that time of year again, spring is in the air in much of the US. That usually means it’s time to do a little clean up work around your organization.

Now is a good time to:

• Review policies, processes and exceptions and make sure they are current and all still apply.
• Check for expired accounts or accounts that should have their passwords changed – especially service accounts.
• Update your awareness program and plan for activities and areas of key focus for the rest of the year
• Review all cryptographic certificates and such to make sure none have expired or close to expiration
• Begin to plan your staff coverage for IT vacations, the summer events and the time when staff is usually reduced for the summer
• Begin the process of hiring those summer interns
• Review the logs and archives and back them up or destroy them as needed
• Any other periodic or seasonal security planning activities

Now is a very good time to do all of these things. It is also a good time to put together your plans for the rest of year and make sure that first quarter hasn’t broken your budget already. 😉

Are there other security spring cleaning items your team does every year? If so, drop us a comment and share your plans with others. More brains are better than one!

As we covered in an earlier post, there appears to be a security issue with Cisco Works.

Now, more information has emerged about what appears to be a back door that allows anyone who can telnet to a port on the Cisco Works box to execute OS commands with high levels of privilege. Essentially turning the Cisco configuration and monitoring tool into a pretty powerful weapon for an attacker.

No word yet on how this back door got into the code, what steps have been taken to make sure this doesn’t happen again or anything else beyond the “ooops and here is a patch” statement. Cisco is hopefully increasing their code management, security testing and QA processes to check for this and other forms of application security before they release code to the public.

Once again, Cisco has shown, in my opinion, a serious lack of attention to detail in security. Given their mission-critical role in many enterprise networks and the global Internet, we should and do expect more from them than from an average software developer. Please, Cisco, invest in code testing and application security cycles in the SDLC before something really bad happens to a whole bunch of us…

A quick review of vulnerability postings to the emerging threats content of this blog is sure to make clear just how popular the anti-virus as exploitation vector has become. Major levels of security research and exploit development continue to be aimed at the anti-virus vendors and their products. And, why not? It stands to reason from the attacker view point. All of these years infosec folks have been staging education and awareness programs to make sure that nearly every PC on the planet has anti-virus software installed.

It stands to reason, that given the near ubiquity of AV tools, that it would be a very easy, albeit traditional, way to compromise systems at large. Vulnerabilities in anti-virus tools are an insidious mechanism for attack, often run with enhanced privileges and carry enough “in your face” and “gotcha” temptation to be a very interesting target. No wonder they have become a favorite attack vector.

On the other hand, from the security standpoint, who else besides anti-virus vendors and purveyors of critical applications linked into the defensive infrastructure should be the poster children for secure development. Every piece of code has bugs, mine included. But, shouldn’t anti-virus vendors be doing extensive code reviews, application assessments and testing? Isn’t this especially true of vendors with large corporate names, deep budgets and pockets and extensive practices in application security and testing?

Anti-virus tools are still needed for nearly every PC on the planet. Malware still remains a large concern. AV has its value and is still a CRITICAL component of information security processes, initiatives and work. Vendors just have to understand that, now more than ever, they are also a target. They have to do a better job of testing their AV applications and they have to embrace the same secure coding tools and processes that many of their own consultants are shouting from the virtual hills to the cyber-valleys. We still need AV, we just need better, stronger, more secure AV.