September 26, 2012 – Gent, Belgium:

Thank you. It is my honor and pleasure to be here at BruCON 2012.  Thanks very much to Wim and all the organizers for putting on a great event, and for inviting me to speak to all of you about some of my experiences and perspectives. 

I’m Katie Moussouris, and some of you may know me in the context of the past few years at Microsoft as the head of Microsoft’s security community outreach and strategy team. What that means is that I help Microsoft understand and have positive interactions with the security researcher (or “hacker”) community. 

Before Microsoft, I spent about seven years as a pen tester – first as an independent security consultant, then as one of the Artists Formerly Known as @stake. After Symantec acquired @stake, we jokingly referred to ourselves as “SymStake.”

But now I’m a security strategist, and my team at Microsoft runs the internal security-research conference called BlueHat. The idea for that conference was pioneered by Window Snyder when she worked at Microsoft. We invite hackers to come to Redmond and educate the engineers and executives on current and emerging threats.

I founded Microsoft’s third-party vulnerability research program (MSVR), and Microsoft security researchers have been getting hundreds of vulns fixed since 2008 through that program. As an individual, I have managed to convince the ISO community to elect me the editorof an upcoming international standard on vulnerability handling processes -- basically the steps vendors need to take to thoroughly triage, investigate, and remediate vulns.

Last year, my team and I launched the BlueHat Prize, the first defense-oriented competition aimed at finding new runtime mitigations for open problems in modern exploitation, like Return Oriented Programming. As you know, these exploitation techniques can be used to bypass the current best mitigations on any platform.  Microsoft gave the winners over a quarter million dollars in cash, awarded at this past BlackHat. To my knowledge, the Grand Prize of $200,000 is the largest cash award for security research ever paid in a single chunk to an independent security researcher by a vendor. 

(Didier Stevens, who is running the Windows x64 workshop here later today, was one of the excellent contestants. Be sure to check out his workshop here at BruCON.) 

So now you know what I do for Microsoft, but if you had told me a decade ago that I’d eventually be working for Microsoft, and on top of that I’d spend some time as an ISO standards editor, I would have laughed, turned back to my Linux box, and piped your wacky prediction to /dev/null. But something surprising happened in the intervening years -- besides me getting old. I allowed my curiosity to lead, as I always have, and to my great surprise it led right to Microsoft’s front door (even though the back doors at the time were sooo tempting!).

Let me take you back a few more years.  Many of you may be too young to remember a world without Microsoft or Apple or Google. But my first computer was a Commodore 64, and to “play” with this new “toy” my mom bought me required patience and experimentation and curiosity – your basic ingredients of hacking. I had long before had all the screwdrivers in the house removed due to my insatiable curiosity around household electronic devices. Many of you probably did too – I know Fabienne did, and lucky for you, she’s running a hardware hacking workshop here at BruCON where you can satisfy that curiosity.

So, to play with this new thing, I had to focus my curiosity on peeks, pokes, and sprites – sounds perfect for a kid, right? And so began my lifelong reading of technical manuals, and the sudden need to look up the meaning of the word “syntax,” since I kept getting those kinds of errors. :-)

And so I learned BASIC and wrote some programs, but being a lonely nerdy type, at first I didn’t have ANY friends with whom I could share this geeky fun. After coding up my own Zork-like text based adventure game -- based on Choose Your Own Adventure books I enjoyed reading -- I realized it wasn’t much fun solving puzzles for which I already knew the answers. There was no fuel for my curiosity in that, and if it weren’t for the burgeoning technology that would network my computer with others, my curiosity may never have found its purchase in the computing world again, and I would have gone on to be a biochemist like my mother.

So aside from sharing some nostalgia with you, how does that relate to our world today?

In our world of computer security, both sides to the security coin must advance for any of us (attackers or defenders) to have any fun. Each side presents a new challenge to the other, fueling each other’s curiosity, in a cat-and-mouse battle royale that will outlast all of us.

It only stops being fun when you know all the answers, and by challenging each other on the offense and defense of computers, we are playing an incredible choose-your-own-adventure game – one that may or may not result in being eaten by a grue.

Fast forward a few more years. My curiosity around the newborn Internet (though that wasn’t what it was called then) led me through the phone wires to a bulletin board system run by some of the earliest computer hackers in the Boston area. These people followed their curiosity to the extreme, challenging each other and the status quo, and not only lived to tell the tale, but were openly sharing their knowledge. These were my kind of people!  To this day, I can still recall my delight upon meeting some of them at my first 2600 meeting, over twenty years ago.

Now, at this point, I could fast-forward you, vaulting over the dalliance I had with biochemistry and mathematics, but I think it’s important to share some key inspiration I encountered during those years. Computer science is a young field, and computer security is even younger, but at that time I was fortunate enough to have been involved in another very young field: molecular biology, working on the Human Genome Project at MIT. What initially caught my eye during my undergraduate studies was the paper that started the genetic revolution.

The groundbreaking 1953 paper by Watson and Crick that described the biochemical double-helix structure of DNA piqued my curiosity like no other because of one phrase, used at the end of the paper, which I will share with you. This paper had a revolutionary effect on the biochemistry community -- much like Aleph One’s paper on stack-based buffer overflows, “Smashing the stack for fun and profit,” had a delightfully destabilizing effect on computer security, effects which are seen and felt to this day.

When describing the fact that they had only scratched the surface of the science of genetics, and that there was more work to be done, Watson and Crick said:

“It has not escaped our notice that the specific pairing we have postulated immediately suggests a possible copying mechanism for the genetic material.”

That sentence was the understatement of the century.  The phrase “It has not escaped our notice” was a wry challenge that these biochemist hackers issued to the rest of the scientific community. They had rushed their work, racing to beat a prominent chemist named Linus (Linus Pauling, that is). They knew there was so much more out there to do, and with that phrase, they alluded to the fact that they knew their initial work was a profound portal into even greater scientific discoveries and advancements. In saying “It has not escaped our notice,” they invited the world to play in their adventure game.

At the time of their discovery, Watson was in his early twenties -- prime hacking age. Crick was older, but was exploring a new field (he had been a physicist), so his mind was as open and curious as if he were just starting out. It’s no coincidence that many of the boldest and most profound discoveries in any field are often at the hands of the youth, when their minds are in that synesthetic state where they can almost taste the music of their ideas, and the areas of the brain responsible for judgment and risk-taking are not fully mature, so they have the urge and the energy to challenge authority and the status quo.

Hackers are wonderful in that they follow their curiosity, and will boldly challenge authority and the status quo at nearly every opportunity. And without hackers discovering and sharing their knowledge of attacks, mainstream technology will continue to grow without ever developing an immune system to defend itself. We see this in the darker corners of our industry that have recently been exposed, such as SCADA or embedded systems, where a hacker can seeminglystill party like it’s 1999.... or even 1988. Attackers will attack, so defenders need to pay attention to the hackers who have a knack for showing that the emperor has no clothes…and that it’s really cold in the room.

Even as I speak, the Internet itself is profoundly different than it was even a few years ago. Now devices are talking to each other with no human interaction at a rate that if it keeps up will soon eclipse porn. I’m not just talking about tablets or smartphones and the profound societal effects that small, affordable portals to the Internet have engendered -- from enabling the immediacy of social networks updating on what you ate that morning, to sparking and carrying waves of Cultural Revolution across newly re-awakened swaths of civilization. I’m including in this “Internet of Things” your car, your pacemaker, your electric meter at your house… your running shoes…

This Internet of Things is the same as the Internet of PCs was just a short time ago – huge and wide open to abuse. So the challenge to all of us, as people who are passionate about security, is to teach and reteach the lessons of the past, even as society embraces this new wave of interconnected devices before it really knows what kind of an adventure they have chosen. For those who played Zork, this is the point at which we can “get lamp,” and thus hopefully once again dodge the grue. (The grue in our world can also be translated as “cybergeddon.”)

So for those of you on the front lines of defense, it’s not so much that you want to think of yourselves as the mouse to an attacker’s cat -- you need to be the mongoose to the attacker’s cobra, a formidable foe capable of competing and winning, by making the attacks themselves as expensive for the attackers as they are for the defenders.

Computer security defense as an industry is still more mouse than mongoose, but the field is young, and I have faith in the hacking community – not only that we will find great defenders among you, but that great attackers who use their skills wisely will be symbiotic sparring partners in our industry’s growth and evolution. I have faith that this community will turn its laser focus on technology’s threats, whether those threats are technical, legal, policy-driven, or societal -- so that we can all keep playing. We saw it with the recent uprising against botched attempts at laws like SOPA in the US, and against similar attempts at legislation in the EU.

I have found that my hacker’s curiosity has been focused by the patience gained in my old age, and that Microsoft – and even the ISO community – have become the levers by which I can help move the world. Even Mudge and Dark Tangent work for The Man now – they even admit that they ARE The Man now!

My challenge to you all today is to find your levers by which you can move the world, be they in a hacker space where you experiment with hardware and software, or in a meeting room of a giant established organization where you may feel a little out of place, or better yet – DO BOTH. It is places like BruCON that will give you a place to mingle with them all.

The security sea itself cannot swell without you filling it with new knowledge about both offense and defense. You don't just control the tides; as security folks, you are the sea.

Which is convenient if you're a pirate...and judging from this group, a few of you arrrr.

So, pirate or patrol ship, you ride the wakes of each other's advances, each depending on the other to raise the next challenge in order to leap forward. As hackers, you have only begun to scratch the surface of what is possible if you wield your influence with purpose and focus.

And this, my BruCon friends, is a fact that I believe has not escaped your notice. 

Enjoy the con, and thank you!!

Steve Lipner and I are security opposites in a lot of ways. Steve Lipner came from the DoD;  I came from 2600 meetings, and later, @stake.  Steve Lipner built A-1 systems to be provably secure; I spent several years as an application penetration tester routinely disproving supposed security. 

Despite coming from different security backgrounds,  we do have more in common than one might think.  We both hail from MIT, his alma mater, and my first professional employer.  Those experiences molded (warped?) us both, at formative moments in our professional lives.  Working together at Microsoft, Steve and I found quickly that we both were fans of security and truly awful puns.  And just recently, we also realized we were both fans of Star Trek, the original series.  Oh and in case it wasn’t obvious, we’re also both geeks.

Steve has been an incredible Sherpa leading me up some craggy climbs in this mountain of a company, helping me understand not just how this company operates, but also how to drive major initiatives that require acceptance and work across more than just our own security-focused group.  What has surprised me most about working with Steve over the past nearly four years is how many times we actually agree on what to do in terms of security – perhaps for different reasons, given our different backgrounds.  The times when we have disagreed on the best approach, Steve always has very thoughtful reasons, based on his deep experiences and awareness of what has worked historically and what died on the vine.  If nothing else, Steve is the litmus test I use to bounce all my craziest of crazy ideas (internally, these are affectionately known as “Katie’s cockamamie schemes”).  If I can convince Steve, I have a very good chance of convincing everyone else to make it happen. 

The creation of the Microsoft Vulnerability Research (MSVR) program was one such mountain that Steve’s support helped me summit.  While many were involved and critical to the process of getting MSVR off the ground, Steve’s belief in me, as manifested by his support (because he knew I could do it), constructive criticism (because he knew I could take it and use it to strengthen my position), and the opening of the right doors to the right approvers within the company, were all key to the launch of the MSVR program. 

Steve continues to open those doors for me, and helps me hone my arguments to turn my security dreams into reality here at Microsoft and in the larger security ecosystem.  I hope he continues to do this for me, even though I recently may have gotten on his bad side for sending him the video for the song “Star Trekkin”.  He can never un-hear it, and for that I will surely pay.  I have a feeling he’ll come back with some dreadful pun that I will never be able to un-read.  Totally worth it. ;-)

Steve Lipner has changed the security world himself so much in such lasting and positive ways.  His legacy will live on not just in ISSA’s Hall of Fame, but in the progressive evolution of security through his influence and guidance for those like myself, who are filling in the ranks of the newer recruits here at Microsoft.

I’ve been lucky to have had a few very supportive mentors in my life.  Steve Lipner, an unlikely ally on paper, has proven to be one of the very best. 

Thanks and congrats, Steve.  I owe you n+1.

First, I'd like to thank each and every one of the reviewers, especially those who were willing to be thanked and acknowledged for providing their feedback.  There is a range of opinions of the folks on that list, and I expect many of them will share more of their thoughts in the coming days and weeks.  For those of you who provided feedback but declined to be thanked in my post, a sincere thanks to you as well for your time and thoughts, which were very valuable.  I look forward to continuing the disclosure dialogue with all of you.

Second, I'm reiterating the request we made for community feedback on the topic of disclosure.  If there's anything you need clarified about what we're saying, I'm happy to provide context on where this is coming from, as it's been in the works for months now here at Microsoft, as well as in the ISO forum where the term "Responsible" was dropped from the name of the "Vulnerability Disclosure" draft standard back in April 2010.

You can reach me on Twitter as k8em0 (pronounced "Katie" "mo", NOT "Kate" "emo"!!), or via email using katiemo at you know where.

If you want to talk in person, I will be in Vegas next week for BlackHat and DefCon, so find me or any of the other Microsoft people, talk to us, and keep the conversation going!  We all have our opinions.  Talking to each other, *especially* when our opinions differ is the only way we can evolve this industry. 

-Katie

She's an embryologist, with enough babies named after her that her skills are highly sought-after by many fertility centers.  Her meticulousness and expertise have also allowed her to become a lab inspector, certifying that other fertility centers are up to snuff.  She is truly a master of her craft, and you should see her on the micromanipulator -- I have never seen gametes micromanipulated with such finesse!  She is a tiny (under 5 feet tall) technical tornado.

My mom was not only a great technical role model, she also showed me that with education and determination, you can accomplish anything in your field of choice.  She was raised on a small island north of Guam (no, that's not sand on the map, there are even smaller islands there), and she came to the US on an academic scholarship to study biochemistry.  She miraculously raised me and my little sister alone.  And if being and doing all that wasn't enough to inspire me to succeed as a woman in tech, she also bought me my first computer, a Commodore 64.  Perhaps most pivotal for me was that she forced me to learn how to program it myself when she refused to buy me any more games for it.  :-)

I once heard that there are those who love you and those who teach you.  Some people are both.  So thanks mom, for your powerful example packed into a compact frame, and for seeding my success in the industry of my choice.  You showed me not to be bounded by anyone else's narrow vision or stereotyped idea of what I could be, and to press on, especially when no one thinks you can.  I (literally) wouldn't be where I am today without you.

Myth: The ISO draft on Responsible Vulnerability Disclosure is some sort of plot by vendors to tell researchers what to do.

Fact: The ISO draft is misnamed. (I didn’t name it, and I can’t change it.) It should probably be called something like “Guide for Vendors to Implement a Vulnerability Handling Policy”.  It has a strict scope to apply to vendors’ actions only, not researchers’ actions. This was decided by the National Bodies participating for many reasons, not the least of which was the fact that researchers don’t usually follow ISO standards. :-)

Myth: Even if it were renamed, it still has “elements” in it that “tie researchers’ hands”. This will somehow still affect researchers!

Fact: I repeat -- There is nothing in this draft that tells researchers what to do.  Nothing.  Nada.  Nil.  No matter how hard one may try to make this about researchers, it simply isn’t about them.

The ISO draft is a guide for vendors to help them do three (simple, in theory) things:

0.       Receive vulnerability reports from researchers.

1.       Process vulnerabilities via some sort of investigation and potentially create some sort of remediation.

2.       Communicate the remediation (if any) to affected customers.

All of the guidance in the draft is very basic, and very agnostic to business particulars of how a vendor is to carry out these steps.  Since there is no prescriptive guidance in there for vendors, only high-level best practice guidance, there is nothing that will “affect researchers” except maybe, just maybe, make it easier for researchers to find the right contact to report security vulnerabilities at vendors who choose to comply with this ISO standard. 

That’s the sum total of the possible ramifications for researchers that could possibly come of this – it might make reporting vulnerabilities slightly less complicated.  I know, there’s nothing to get upset over with that, so I’m sure those who still want to yell on the Internet will ignore this entire post or pick it apart in 140 characters or less. ;-)

Besides, even if there were rules for researchers in the draft (which I repeat, there are NOT), researchers can do whatever they want. That has always been the case. Every researcher I’ve met has their own personal vulnerability disclosure (or non-disclosure) policy that they generally follow.  I say “generally” because this personal policy varies greatly from researcher to researcher, and can even have significant variation when a single researcher deals with one vendor or another, so much so that in most cases, it shouldn’t even be called a policy, but rather a “collection of exceptions”.  

Perhaps one vendor gives them more technical responses, so the researcher is inclined to give them more time. Perhaps another vendor gives them auto-generated emails every month, so the researcher gives up on ever speaking to a human and releases the vulnerability details after receiving a few robot-mails in a row.  The researcher may give a reason for changing their mind about giving a vendor more or less time, and they may not. 

The point is: nobody can tell researchers what to do now, so how or why on earth would ISO ever try? And if ISO did try to regulate researchers, who would follow the standard?  Not the researchers, that’s for sure.

Basically, researchers answer to no one.  They do what they want, when they want, and on their own timeline.    Nothing will ever change that, so why is there even a “disclosure debate” at all?

In my opinion, the debate only ever comes out when a researcher wants to be *thanked* by a vendor, either via vendor acknowledgement or via monetary compensation. That thanks (or no thanks) is up to the vendor and always will be. 

Now, let’s differentiate between gratitude and credit.  Credit, as opposed to gratitude, is not something that a vendor can give or withhold.  Credit is granted in the numerous vulnerability databases that will inevitably cite the researcher (if they made themselves known publicly), whether they dropped exploits on Full Disclosure ahead of a vendor-supplied fix or not.  A researcher who wants credit will always get it.  A researcher who wants gratitude will have to abide by the vendor’s rules for how the vendor chooses to express gratitude.

No standard will ever regulate the concepts of responsibility, whatever that means, (for researchers) or gratitude, whatever that means, (for vendors).

So there you have it, in all its futility: Researchers will continue to do whatever they want, and (shocking!) so will vendors. 

Only, when this ISO standard comes out, vendors may have a better idea on how to go about their vulnerability handling.  I’ve seen many faces of vendor response, and I can tell you that clues are rarer than you’d think, and that there is a place for this kind of basic level of guidance.

If you’re a vendor, this standard will not tell you how many security staff you need to hire to support a whole new vulnerability handling practice, or whether or not to thank a researcher.  That’s up to you.  If you are a researcher, ISO will not tell you how much time you have to give a vendor or whether or not you have the right to sell your work.  That’s up to you. 

Now you can all get back to work doing whatever you want, or continue screaming FUD-y murder.  It is, as it always has been, up to you.

To my friends who have known me for many years, via hacker-spaces, hacker cons, soldering a Theremin in the desert, and marching with penguins, this may come as a shock. Even the fact that I came to work at Microsoft was less shocking than this.  Katie (AKA k8e), turned policy wonk?!  No way!! 

Way.

Working with ISO has been one of the most exciting (yes, you heard me) things I’ve done in my career.  Seriously.

One may think it’s boring, poring over standards drafts, looking up arcane directives about formatting terms and definitions (okay, that last part *is* a total snooze-fest), but the fact that I get to help pen part of what will be adopted as The Way to Do Things for many people around the world is exciting in and of itself.  Even that micro-slice of influence is nothing compared to the excitement of actually being there, in the twice-annual ISO meetings, hosted by rotating member nations around the world. This last meeting was hosted by the US and held at the Microsoft Conference Center, a convenient commute for me.  The previous two meetings took me to Beijing, China this past May and Limassol, Cyprus in October 2008 – the latter while 35 weeks pregnant. (Note to self: No more traveling in the form and shape of a manatee. I was thrice thrown whole raw fish, which was just a waste since pregnant women are not supposed to consume sushi, and once nearly captured and relocated by helicopter airlift to a cove in the Mediterranean to wallow in freakish misery with other large sea mammals.)

ISO meetings themselves are actually gripping microcosms of humanity.  Subtract the long sonorous stretches of Old Men Yelling at Clouds and you have yourself, as one friend put it, the UN of geeks.  It was beautiful and terrible, full of quiet riots, politics and poetry, kindness and cunning.  The real human drama that goes on has enough juice from which to squeeze a best-selling novel (working title: Bombasts and Bloviates - Policy Poetry and Pugnacious Punditry).  And yet there is a true heart to all of this; an unmistakable human element in what an outsider may otherwise assume is all sterile and businesslike in its formality of process.  We observed a somber and sincere minute of silence at the start of our working group plenary session to mark the passing of a dear friend and colleague who had been involved in SC27 since the beginning, an act clearly demonstrating how these people have really formed a community not only of experts, but of friends.

Over the past two years since joining Microsoft, I have been providing technical comments to an ISO draft standard on Responsible Vulnerability Disclosure.  I have made friends across nations and across companies in my service as a subject matter expert for this topic in the international meetings on behalf of the US National Body.  This past meeting, I was suddenly, unexpectedly asked to do much more.  The editor was indisposed due to illness and on Tuesday morning, day two of the ISO meeting and two hours before the ad hoc editing sessions began, I was asked to fill in as acting editor on the draft.

Suddenly being an acting editor for an ISO draft is like being thrown from a plane with a sufficient amount of silk thread to weave a parachute.  While success is a remote possibility, the sheer amount of work you have to do before you hit the ground (i.e. run out of time before the working group takes a vote at the end of the week) is astronomical.

We had roughly 245 comments to wade through, mostly technical, spanning nearly 80 pages on a standards draft that is a scant 12 pages including annexes.  New countries that had never provided comments on the two working drafts prior to this third draft had emerged as major players in the discussion. At its peak volume, around 15 experts from about 8 different national bodies attended the editing sessions – twice as many individuals as had ever participated in person before -- and they all had an opinion. 

Herding cats would have been easier.  We had to get consensus or at least majority agreement on everything from major concepts at the heart of disclosure, to the structure of the draft, to minute wording and definitions.  Somehow, likely because I was a merciless taskmaster who forced them all to show up early, stay late, and work through lunch, we got through all 245 comments in time for the working group vote. My heartfelt thanks go to all the participants, even those who argued the most.  Though we may not all be birds of a feather, we couldn’t have produced something as balanced and truly international without all of us there.

My work for this meeting done, I handed over the disposition of comments (the document that serves as the editor’s instructions on the changes that were agreed upon by all participating national bodies for the next iteration of the standard draft) to the editor, who was feeling much better.  I felt relief and pride that I had been able to wade through such a pungent mix of policy and personality to create something I can point to one day and say: I helped make that.  

In my appearance on the ‘Partial Disclosure Dilemma’ Panel at SOURCEBoston this year, I found myself surrounded by great minds who most certainly do not think alike.  While there was some agreement and common ground between all parties on the dais, namely wanting to make the Internet safer and protecting people, there was little agreement on the best way to accomplish that goal.  The conversation between us friends and colleagues, both on stage and in the audience, wended its way down many tangential paths, most of which I will have to watch again on the video to fully understand how we got from Partial Disclosure to Dan Kaminsky saying “More people have died from windows crashing on them than from Windows^TM crashing.”  But I promised my redux of the panel, so I will guide you down the path I think was most interesting.  For a broader look at SOURCEBoston, check out Celene Temkin’s post.

The disclosure issues around Dan Kaminsky’s DNS vulnerability were one seed of the panel idea.  If you are reading this blog, then I will assume that you’ve heard of this vulnerability, else you must have been living under an Amish rock in a Luddite colony, high in the brisk, thin air of the Himalayas. 

As far as the disclosure route he chose and how that played out, he executed a plan he thought was best in order to get vendors to fix a serious issue (they did), *and* to get as many affected customers protected (some were) with the fix in place before broadly releasing the technical details.  He let a small number of people know the details, in the hopes that delivering those details to the right people and no one else would best protect the world’s critical infrastructure.  Hence, the term ‘partial disclosure’ was used to describe his approach.  Other notable researchers thought it was just hype, then took it back once they had spoken to Dan, some pretty much figured it out on their own, or chatted about it on DailyDave.  It was weaponized shortly thereafter, and a couple weeks after his initial announcement, some affected people had applied the update and some unfortunately hadn’t.  There were certainly more details I’m skipping here, but that’s the skinny.

Now that the panel stage was set, here’s one of the topics I thought was interesting.

In our introductions, we each counted ourselves among the security research community.  Some of us had also been or still are consultants, all of us had done the startup thing, and some of us had been in charge of running some kind of computing infrastructure. 
At the risk of sounding immodest, I believe I had a unique perspective on the topic of responsible disclosure as I was the only panel member  who has been, at various stages in my career, a vulnerability Finder, Coordinator, and a Vendor (for both open and closed source software).

Let my official punditry from this pugnacious pulpit begin.  ;-)

It was interesting to me that the panelist who most strongly endorsed “inflicting pain” in the form of exploit release in order to provide the necessary “wake up call” to vendors had never been responsible for maintaining any kind of infrastructure deployment.  We all know how much easier it is to break something than it is to build it or to fix it, yet there is a pervasive attitude among many security researchers that nothing should be more important than security, not even the business itself.

And that’s where our disagreement’s footing took a stronger hold on its rocky purchase.  Define pain, our moderator asked.  Who decides on the form the pain will take and how intense or widespread it is, I asked.

Sure, it took some pain to get the attention of software vendors to fix their products and build security in from the ground up.  But as security folks, aren’t we tired of having to use the same arguments of active, widespread exploitation to*prove* that something needs to be done?  Security people often complain that not enough has changed since the epoch began, but if that’s true, then why have we not looked at ways to stop beating our heads upon the supposed brick wall of vendors or deployers of technology, and instead tried something different to get the right eyes on the right issues at the right time to do the right thing?  Doesn’t executing the same behavior over and over again but expecting different results equal insanity?  When are we willing to stop the madness? 

At the end of the panel we were each asked to describe our security utopia.  My Shangri-La was this:  I would like to see more cross-over among those of us who say the sky is falling and those of us upon whom the sky will fall. 

Communication between two groups with different mindsets requires a lingua franca other than exploitation.  One might think that math is the language of the universe, and Proof of Concept serves as the mathematical proof needed for anyone and everyone to arrive at the logical conclusion of “drop everything NOW and create (if you’re a vendor) or apply (if you’re managing infrastructure) the update.”  Before I had ever been responsible for building anything or protecting anything, I might have agreed with that, since it made perfect logical sense to me at the time, in the context within which I worked. 

But it’s not doing the trick of convincing all vendors and all deployers by a long shot, so obviously, we need something to change.  PoC can and should be part of the conversation between responsible researchers and people to whom they are reporting the issues, but it must be framed appropriately for the listener.  PoC is not that simple for non-security types to immediately frame the same way we do as security people.  Even if they do grok the severity of the situation, they may not be *able* to move as quickly as a researcher feels they should. 

Consider this, researcher-types: If you’ve never managed infrastructure before, or been responsible for shipping and maintaining complex and widely deployed code, then you don’t have the context to understand why there are sometimes legitimate reasons to do things more carefully and therefore more slowly.  Once the talk recordings are posted, check out the very thorough treatise by our own MSRC on How Microsoft Fixes Security Vulnerabilities: Everything you wanted to know about the MSRC Security Update Engineering Process. Think about how you as a researcher and security expert would react if some CTO or IT person or developer who lacks your depth of security knowledge and subject matter expertise came and told you what to hack, how to hack, and at what pace to hack it?  That’s essentially what you’re doing when you say “you should be able to fix it and fix it now, and if you don’t do it on my timeline, then you obviously need to be made an example of so I’m going to release an exploit for it into the wild.” 

They don’t swim in your security research toilet :-), so why must you pee in their development or infrastructure pool? 

Okay, I couldn’t resist making the joke – and no, I don’t think security research is a cesspool, or I wouldn’t have founded two vulnerability research programs in my career.  What I am saying is that all of us should be striving for the delicious harmony of combining your chocolate with my peanut butter, your gin and my tonic, your milk and my shake, in order to make the whole greater than the sum of its parts.  As a researcher, one can choose to be the sabot and grind gears to a halt to prove a point, or one can be the grease that moves things along with less friction, earning the trust that will allow each subsequent notification pill to be swallowed more easily.  As a developer or deployer, one can choose to stuff up one’s ears until someone firmly inserts an icepick, or one can strive to fix things as quickly and safely as possible and learn from the experience to continually improve and speed up that process over time.

We need a better way to reach our common ground of protecting the computing environment on which we all rely.  Researchers need a means by which to communicate urgency that avoids descriptive hyperbole or causes damage, which erodes trust.  Developers and deployers need a better way to service existing code and infrastructure reliably, safely, and rapidly if necessary, to build trust among the researcher and customer communities that they are doing the best they can at any given time.  Around here, we’ve done serious work on making this a reality on the development front, with the dual-ninjas of SDL (proactive) and MSRC (reactive).  I’d like to see SDL someday brought up to a full double-D in the form of a Secure Development and Deployment Lifecycle, to build infrastructure design and servicing models that are resilient in the face of threats to deployments as well as software.  Perhaps I can begin to work on this here at Microsoft, if I can get some of my other work done first.  :-)

After we had each said our peace on what our security utopia looked like, that’s where we left things.  No agreement could be reached in the two hours or so we were on the stage, which is no surprise.  If the tape ran out before the end, then you won’t get to see us literally “hug it out” after all was said and done, disagreements notwithstanding.  I continue to have tremendous respect and share camaraderie with my fellow panelists and with researchers around the world.  It is my hope that the determination and vision of those on any side of the equation who can see across the role boundaries of researcher, vendor, and deployer will usher us into a new age. 

People often ask what more is there to say about disclosure that hasn’t already all been said.  I think the real conversation on how to get the results we all desire - to get things fixed *in spite of* our disagreement - has yet to truly begin.

I’m listening, as well as talking.  Are you?

Come back here in a week or so to read my redux on the discussion that is sure to be lively.  My fellow panelists include Dan Kaminsky (IOActive), Ivan Arce (CORE Security), Dino Dai Zovi (recently published co-author of The Mac Hacker's Handbook), and Alex Sotirov (Independent security researcher), moderated by Ryan Naraine (Kaspersky/ZDNet). 

Over two hours on the stage -- should be long enough to get a real dialogue going.  ;-)

-Katie Moussouris, Senior Security Strategist

Follow me on Twitter: https://twitter.com/k8em0