CISO Lays It On The Line @ RSA

Representing the average customer, Tim Stanley, CISO of Continental Airlines had the opportunity to ask vendors and researchers direct questions regarding patches and vulnerabilities at the RSA 2010 Conference.  “Microsoft knows about a bug, researchers know about a bug, but I’m the guy who paid for the software.  When am I gonna know? … And don’t tell me about the pains you have in determining what has to be fixed, I don’t care.  You’re in the software business, you’re writing code, that’s what you’re supposed to do.  If you can’t handle it, get out of the business."

A panel discussion brought him in, and put him on the dais with Microsoft, Adobe and HD Moore.  He wasted little time making his displeasure known.  I am pleased to hear that he tossed cold water on some opening remarks regarding the exposure timeframe from the discovery of a bug to when a patch is released, as well as some points on the importance of constant communication between vendors and researchers.

"I love the love-fest between the vendors and researchers, but quite honestly, I don’t give a hoot.  I’m the consumer, the guy who paid for the product that I expect to be correct in the first place.  I’m perturbed with the relationships going on.  The issue becomes a matter where the people paying for the product need to be better represented in this process," Stanley said.

Discussion hit on all the usual topics: vendor triage, prioritization of patching, how zero-day vulnerabilities impact patch cycles, regression testing, and the quality and stability of patches.

HD Moore, famous for script kiddie tool MetaSploit for example, called responsible disclosure of vulnerabilities a vendor created delay tactic.  He opined that as a researcher reporting bugs, he’s at the vendor’s mercy.  Because the vendor controls the patch release cycle, the vendor determines when his research work becomes public.  Too bad, so sad.  Publicity is everything, it seems.  "If you have evidence that something is being exploited in the wild and a vendor has not patched it, at that point is the vendor irresponsible or you for not reporting?"  I only wish that the question was turned back to HD, asking if he publishes code publicly before or even shortly after a patch is available, or creates a plug-and-play module that simplifies exploitation, who is responsible.

I have nothing personal against him, but HD Moore needs to smarten up.  I hope nobody is buying what this guy is pedaling.  He is NOT the savior of all software and the elected dispenser of patch-justice.  Yes, the vendors don’t move fast enough, yes we can make them move faster by releasing dubious “admin” or “pen-test” labeled tools like MetaSploit and its modules that allow any clown with a PC to exploit serious threats.  Yes, HD stands to make a boot-load of money for himself and the company that bought his “product” (or as I’m sure he’d prefer, funds his research).  In my most humble of opinions, this is aiding and abetting an attacker to commit whatever crime they commit, and the authors of such tools and the companies that they work for/with/though should be accountable, regardless of whatever disclaimers are posted in their EULA.

I might not have all of the answers regarding what should be done to get vendors patching their mistakes faster, but lighting a house on fire to get the people to come out so you can save them from smoke inhalation is probably not the best route to take.  If “responsible disclosure” is a process that isn’t working, then fix the parts that aren’t working, or provide a better one.  One that meets the needs of those that a researcher and the vendors are supposed to be serving.  Why not advise the vendor, give them a REASONABLE amount of time to patch, if they don’t produce, release NEWS that you have discovered a serious vulnerability (if you don’t cry wolf, you will gain credibility) and have the vendor (or a trusted impartial 3rd party that is not seeking profit) confirm it.  If the vendor still doesn’t take action, start legal proceedings.  A couple of class action suits and they will probably get interested in patching, or better yet, cleaner coding practices…

There are too many self-serving and egotistical researchers and vendors already, running rough-shod, cowboy style across the windswept plain that is the Internet.  Time to clean up this one-horse town.

C-Net RSA 2010 Article List

Advertisements

2 thoughts on “CISO Lays It On The Line @ RSA

  1. Responsible disclosure doesn’t work because there is no incentive for software vendors to be honest with their customers. Tools like Metasploit are used by professionals and security companies alike to keep the vendors honest. It may be not obvious how public security research benefits the downstream consumer, but anyone familiar with the old software industry (circa 1998) can tell you just how bad things were when the current system of checks and balances were not in place. Don’t underestimate what the real attackers can do without any help from the security research community. Public, detailed vulnerability disclosure is what brings the system administrators into the same playing field as the black hats. Without security tools like Metasploit, the only way to demonstrate the impact of a successful attack is to get owned and hope to piece things back together from the logs, which is actually how things used to work. I don’t expect to change your opinion, but there are strong reasons why I have mine.

  2. Thanks for taking the time to reply, I appreciate your time, and am surprised that you found me in my little corner of the web…

    If there is no incentive for vendors to be honest with their customers, then wouldn’t we be better served defining a method of incentivizing them to be honest that doesn’t damage the cusomer-base, or put them at increased risk? Vendors are also subject to and averse to reputational risk, just like the rest of us.

    Tools like Metasploit have their legitimate uses, but are also regularly used to compromise businesses and destroy livelihoods by lesser skilled and unprofessional (unethical) attackers. If a business doesn’t patch a 3 year old vulnerability and it gets exploited, well that is a matter of internal process failure, but when code or modules emerge before or shortly after a patch is available, that is just irresponsible release. When an organization has to scramble to patch 30-50,000 systems because the likelihood of attack just went off the charts because someone released a module to the script-kiddies and their more experienced brethren, lives are impacted. Costs are incurred. Budgets are affected.

    I have been in the IT field working for and with vendors, consultants, customers and consumers for over 25 years. I have been involved in security incident response for over 10. It is obvious to me how public research has helped everyone build better soft/firm/hardware. It is also apparent that there is another edge to that sword. The playing field has changed dramatically over the years. Attackers’ motivations are not the same as they used to be, attack and defense methodologies are not the same, the tools used by either side are not the same. Time is now of the essence.

    The motivations of researchers are not the same either. Back in the day, the motivation was generally more altruistic, shared learning, common good. It was about hobbyists and professionals alike finding problems and working together to fix them. Back then they did have the luxury of time, mainly because few were interested enough, skilled enough or understood the implications of what was being shared. Today information is consumed at a rapid pace, and technology is ubiquitous. Everyone is looking for an edge to improve their own status. Give it to them and it will be used. There is a sense of entitlement, and less thought is given to the affects our actions have on others.

    I don’t believe that I underestimate the attacker or his capabilities. It’s my job to ensure that I and those around me don’t. However, many of my adversaries’ capabilities are restricted by the tools that they use. Many have little knowledge of the underlying protocols or applications that they are using and abusing. Some do, but most do not. They have a simple tool that allows them to string together and manipulate command lines using a menu system, and in doing so, exploit vulnerabilities remotely to gain unauthorized access to other people’s systems and information. All at a push of a button, click of the mouse. They don’t need to know or understand the intricacies of the protocols they are using and applications that they are subverting. Others take care of that for them when they release these excellent tools and powerful exploitation modules, so quickly.

    Metasploit has not given me, any of my teams, or any of my colleagues an advantage against our attackers that I can recall. In fact just the opposite seems true. It gives the advantage to those that would do the most harm to the most people. The malicious, the ill-informed and the angry. It can only demonstrate for me that my systems are vulnerable to something that should have been fixed in time to deter or deflect an attack. I understand that it is just a tool, and we don’t outlaw screwdrivers just because some people use them to kill others. In my opinion, a module for Metasploit should never be released until everyone on the planet has had ample time to patch against the vulnerabilities that it exploits. Those that choose not to fix accept the risks.

    I also don’t expect to change your opinion, you have likely been in “the game” as long or longer than I have, and have seen things from your own side of the fence. I do expect to show you or anyone that will listen the color of the grass on my side, though. Hopefully something of value will be expressed in the effort.

    Again, thanks for your comment. I wish you continued success, and hope that success places you into a position to drive change.

Comments are closed.