Hello All,

I enjoy telling stories. Perhaps, in a former life, I spent time as a bard telling stories of Robin Hood and Maid Marian as I travelled from town to town. Perhaps I just spent too much time playing The Bard’s Tale on my Tandy 1000 back in the day. Either way, I enjoy telling stories to people. It’s even better when I get to tell stories that relate to my job. Recently, I was given the opportunity to tell some stories at BlueHat V10, and that presentation is now online for the world to see. One area of my job that always piques people’s interest is the challenges we face on a day-to-day basis. These are the stories I chose to highlight in the Bluehat V10 presentation, and unlike most old bard’s tales, these stories actually happened.

 

Of course, stories always have a greater impact when they make a point. In each of the case studies I talk about, something went wrong. And let’s face it, if I’m involved, it means something has already gone wrong. That doesn’t mean that someone was at fault, just that things did not go exactly as we expected.

 

When I was originally approached about presenting something, I immediately thought of a few themes I wanted to highlight about what goes on in MSRC. First, few people understand the scope that we deal with every day. I may joke about rebooting countries (just watch the video of the presentation), but it’s really not much of a hyperbole to say that. The actions I take and decisions we make have far reaching consequences, so we take them seriously.

 

I also hoped to highlight the number of moving parts we have in any given security update. In addition to all of the work I do, there are developers, testers, engineers, product groups, communications people, security gnomes, operations personnel, release partners, independent security researchers, and the list just keeps on going (sorry if I left you off). My job is to ensure all of these folks work together toward the common goal of addressing each issue and protecting our customers. I’m not asking for your sympathy here (though I’ll gladly take it), but most people have little understanding of the massive amount of coordination and work it takes to release five new lines of code across 22 platforms in 36 languages.

 

So how do we manage to make all of this happen the second Tuesday of every month? Well, there are 3 P’s that exist here that really drive us to success:

 

·         Passion – Everyone I work with is very passionate about security and protecting customers. Let’s face it, if we weren’t passionate about this, we wouldn’t last long in the sixth worst job in science. And hey, we actually did buy a customer’s laptop just to get repro (and that wasn’t the first time).

·         Process – We’ve done this before. And each time we do it, we learn more and apply those lessons toward doing it better the next time.

·         Pragmatism – Although we might not get everything 100% perfect 100% of the time, we realize we can go back to those first two P’s to cover us when something goes a bit askew. Release Tuesday is huge for us, but it’s not the end of anything; just a major milestone. We actively monitor the ecosystem to make sure everything is behaving the way it should.

 

Well, I hope you enjoy the presentation and the stories I tell in it. If nothing else, it provides a framework for understanding what’s behind that little bundle of joy we deliver every second Tuesday. And if you happen to find me wandering in Skara Brae and would like to hear any more stories, we can head over to ye old tavern where I will spin a few yarns for you. I might even be the one buying. :-]

Cheers!
Dustin
MSRC

There are times when one must look toward the best interests of the customers above any competitive strategies.  Security is one of those themes that has the power to unite teams across company boundaries.  As the EcoStrat team builds and strengthens relationships with researchers and partners, we are sometimes faced with unique challenges that we’ve never encountered before.

In the days of the big worms, we as a company and an industry had to rise to the occasion. Today our challenges have evolved, and are a great deal more complex. As we as a collective industry rise to the occasion once again, our awareness and response must evolve as well.

Enter the dawn of the Blended Threat. Mix one part third-party vulnerability with one part Microsoft vulnerability (and blend over ice) – it sounds like a drink vying to replace the Mojito.

It’s not like these types of threats didn’t exist before, but much like format string vulnerabilities that had been lurking in code for years, no one has been talking much about blended threats in a widespread way – until now. Sure, AV vendors used the term, but they were speaking of malware displaying multiple characteristics and using several techniques to achieve their goals. We’re talking about vulnerabilities that are comprised of two or more less severe vulnerabilities.

It started not with a bang, but with a whisper -- A couple of researchers each independently reported two low/moderate severity issues to two separate companies.  On their own, they seemed to both companies to be relatively low-risk.  But the researcher who reported the issue to us thought of combining the two vulnerabilities, to allow remote code execution. 

In a historic collaboration, both companies came together against our common enemy: security threats. Microsoft Security Advisory 953818 was born of this blended threat, and the Ecosystem Strategy Team was there with a new initiative, announced today at Black Hat: Microsoft Vulnerability Research (MSVR).

Microsoft Vulnerability Research was created as part of the evolution of Microsoft Trustworthy Computing’s work in Security Response, SDL and Security Science. This program is one of the company’s many efforts to not only improve the security of Windows, but of the entire Windows ecosystem, responsibly researching vulnerabilities in third-party software most commonly used by Windows customers. While the source of the vulnerabilities will usually come from original research at Microsoft, the program will also handle third-party vulnerability coordination for blended threats reported to us by responsible researchers, as was the case with Microsoft Security Advisory 953818.

So what's really news here? If we've been practicing responsible disclosure for years, why are we making a big deal about it now? Well, think about when you've performed a penetration test on a company's application and you happen to find a vulnerability in the underlying commercial database. That's traditionally how we used to find third party vulnerabilities--through the course of our normal security work. Now, with MSVR, we're expanding our security research focus to specifically look for third party vulnerabilities.

The MSVR program will formalize the company’s responsible disclosure efforts of working directly with affected vendors, confidentially providing them specific vulnerability information and helping them to create updates.

So in the case of this recent blended threat, along with teams across Microsoft and externally, MSVR allowed us to coordinate with the finders, and across the companies to ensure the best possible outcome for our mutual customers.  Technical contacts, PR contacts -- all were involved in this effort.  It was new ground for all parties, as we had never attempted a joint response to a mutual security threat that was borne of smaller vulnerabilities from each of our products. 

We are often asked what our team does.  This is part of it.  We are the ones who can fast-track security responses that affect not just our users, but users of other people's software to make a significant impact on the safety of the entire Windows ecosystem.  We help make the impossible possible.  We do it with a *lot* of help from our friends, and some from our rivals.  One thing is certain:  While this incident may have been the first, it will not go down in history as the last.  Blended threats are the new black.  And we will all collectively have to become the new Chuck Norris.

Like the countries of the world uniting against a hostile alien invasion, we of all people understand that we can't do it alone.  We rely on the kindness of researchers, competitors, partners, and strangers to make it all come together to help us secure our ecosystem. We are irrevocably intertwined, and so the threats that face us all are blended by their very nature.

My name is Katie Moussouris, and if I am Leia, the security ecosystem is my Obi-Wan Kenobi. 

Help us, Obi-Wan Kenobi, you're our only hope.

For my final thoughts on Black Hat and more, come join me at http://twitter.com/k8em0.

*Postings are provided "AS IS" with no warranties, and confers no rights.*

I’m here at the second edition of the BlueHat Security Forum, this time in Buenos Aires. So far it is shaping up to be an immensely successful event. We started the day off with a welcome announcement from Hernán Rincón, president of Microsoft Latin America, and have more technical insights to come, some scary and some more reassuring, in the typical BlueHat fashion.

We have near 100 attendees with us here today from across Latin America. Countries including Brazil, Argentina, Mexico and Peru are represented. Attendees span local and regional business and industry, government, academia, CERTs and security researcher communities. The thematic focus will range from e-crime attacks, the vulnerability economy and the regional threat landscape, cloud security, mobile security, embedded devices, social networks and the web 2.0 community, and last but surely not least, the Microsoft Security Response Center processes and integration of a Security Development Lifecycle.  To learn about out the presenters taking the podium today, check out Celene’s announcement post for a deeper look.

In our continued efforts to evolve BlueHat and keep content innovative and relevant, we’ve taken an idea from our friends at H2HC and kicked off our event by hosting a panel entitled “Hackers and you”. We have invited Ivan Arce, co-founder of Core Security Technologies; Rodrigo Rubira Branco, Hacker to Hacker Conference (H2HC) organizer; local security researcher and previous BlueHat speaker, Manuel Caballero; You Sh0t the Sheriff (YSTS) conference organizer, Luiz Eduardo; Felix ‘FX’ Lindner, head of Recurity Labs and PH-Neutral fame; Damian Hasse, Principal Security Development Manager of the MSRC/MSEC; and Nico Waisman of Immunity to contribute their thoughts around the term “hacker” – what it means to be one, how it differs throughout regions, and how to keep “hackers” part of an effective enterprise security team. The panel was moderated by our own Andrew Cushman, senior director of Trustworthy Computing at Microsoft, and offered a variety of unique insights.  There was a ton of good commentary, Rodrigo mentioned how the security researcher community really drove broad awareness and vendor responsiveness. FX spoke about how understanding a system is the best way for strong defense and highlighted approaches such as the Elevation of Privilege (Eop) card game produced by our SDL team. From the MSRC perspective, Damian shared how he’s made an effort to keep an active “hacker mindset” as part of an effective security team within Microsoft. Ivan closed the commentary by highlighting how BlueHat  provides a platform for seemingly disparate groups of attendees to effectively engage where they may not otherwise have the opportunity to do so with typical formal communication methods. He encouraged all attendees to look to their neighbors in the audience and take advantage of such experiences to seize and create strategic, mutually beneficial opportunities.  

  

We have strategically partnered with Security Week, a Microsoft hosted event put on by the local Microsoft office in the region. This partnership allows us to bring security and privacy information to local IT Pros, BDMs and Policy Makers. So far this Security Week Buenos Aires installment has reached more than 500 people, providing over 40 presentations throughout the course of the week.

If you haven’t seen the recent posts by BlueHat Security Forum members, check out Manuel Caballero and FX’s insights and stay tuned for future updates. Nothing like bringing the legitimate security space of Latin America together and creating a melting pot of new ideas and relationship-bridging! This might even beat the lomo!  J

- Mike

*Postings are provided "AS IS" with no warranties, and confers no rights.*

It was two years ago at Black Hat that my colleague Katie Moussouris announced the launch of the Microsoft Vulnerability Research (MSVR) program. Shortly thereafter I assumed ownership of the fledgling program to start making our goals a reality. The primary goal as it was defined sounded simple enough: Protect the larger ecosystem by reporting vulnerabilities in a coordinated manner that were identified by Microsoft resources, with MSVR assisting other vendors as they worked through the challenges of addressing vulnerabilities by sharing some of the lessons learned by Microsoft and the MSRC.

While MSVR’s core mission has stayed the same, in the two years since the program’s inception, the program has grown to take on other challenges as they’ve presented themselves. We’ve done so both because those challenges needed to be addressed and because the coordinated nature of MSCR was the best tool for the job. Some examples of those challenges include MSVR’s role in coordinating several large-scale cross-industry vulnerabilities identified by other external security researchers, such as the DNS Rebinding issue disclosed in 2009 by Dan Kaminsky. Microsoft and MSVR also faced a unique situation in coordinating the remediation of a vulnerability in Microsoft’s own code that affected vendors across the ecosystem as a result of the ATL Killbit Bypass vulnerability discovered by Ryan Smith and David Dewey. .

MSVR has also assisted in reporting to vendors instances of zero-day attacks against their products, which were discovered as a result of the telemetry and other threat-detection resources built into the fabric of the MSRC’s response process. MSVR is not intended to serve as a CERT entity; however, we felt leveraging MSVR for these cases was imperative because a vulnerability affected code in both Microsoft and other vendor products.

So what have we learned? For starters, the security maturity of vendors across the ecosystem varies wildly, as you might expect. Sometimes just finding the right organizational entity or person inside a major corporation to report a vulnerability to can be the toughest part of the mission. In other instances, MSVR has had to take on the role not just of vulnerability reporter but also of response educator, as vendors were unaware or unsure of the best ways to communicate the information their customers needed about the vulnerability in their product. On more than one occasion, we encountered statements and questions similar to “what should we put in an Advisory?” -- or, even more challenging, the assertion that “we do not believe this issue warrants an Advisory or public release.” That second response in particular requires MSVR to painstakingly go through the merits of educating the vendor about why notifying customers is important. Touchy work, but worthwhile.

(Interestingly, in the last two years, it has become clear that nothing serves better as the universal vulnerability translator than calc.exe. Sometimes all the man-hours and time spent packaging up what appears to be a cohesive and solid vulnerability report to a vendor devolves to utter exasperation when the response received is “Not a vulnerability”… that is, until the follow-up response from MSVR is the PoC needed to pop calc. Shortly thereafter, it seems like we are suddenly cooking with gas in the MSVR-to-vendor conversation.)

We have also learned that engineering processes across the ecosystem are unique to each company, and each comes with its own challenges that can make engineering a fix complex. Consequently, the timelines vendors require to engineer a fix is unique relative to each vendor and each product in order for them to get it right. To put it more bluntly, a universal time-to-fix mandate from MSVR (or any other vendor) is just not realistic. The speed with which the vendor of a cloud service offering can move to address a cross-site scripting vulnerability doesn’t compare to the time required to address a vulnerability in client-side code in a more traditional boxed product. This statement still holds true even when it is the same vendor who is responsible for both boxed and cloud version of a vulnerable product.

Finally, it has become clear to us that sharing hard data with vendors about the risk posed to our mutual customers can be key to getting traction. Throughout the last year we have leveraged the MSRC’s telemetry-gathering capabilities, both internal to Microsoft and via our MAPP partnerships, to help provide clarity to vendors during situations in which we believed our mutual customers to be at real risk from zero-day vulnerabilities of which they may not have been aware. This has required us to communicate clear and validated data that vendors could use to better prioritize and expedite their engineering processes relative to the trade-offs that they have to make.

It has definitely been a wild ride over the last two years – interesting times indeed. Along the way, we’ve tackled many of same problems that security researchers face when reporting vulnerabilities to vendors, and we’ve learned valuable lessons that will continue to not only make MSVR better, but also that we can channel back to our colleagues in the MSRC. We’ve forged stronger relationships with other security response teams and vendors throughout the ecosystem as well as with the talented security researchers both internal to and outside of Microsoft.

We’re thankful to all of the researchers and MSVR partners, such as MMPC and various MAPP participants, who have chosen to work with us and provided us with needed assistance when called upon. The next two years will hold even bigger challenges and bigger opportunities for MSVR, and it will also come with challenges I am sure I cannot begin to conceive of yet. Interested? I definitely encourage you to check out the whitepaper. And if you’re here at Black Hat drop by the Microsoft booth and let’s talk.

Adrian Stone

As we wrap up the first BlueHat Prize contest, we wanted to share what we learned while running the first competition, from a major vendor, offering a large cash prize for defensive security research. Not only did we get to motivate the development of technical mitigation technology, but we also achieved some valuable non-technical goals as well.

We’ll announce the winners in this post, so scroll down if you can’t wait.

Bonus #1: We identified security defense talent that we may never have encountered otherwise, and helped the world get to know them too.

Some of the contestants were certainly well-known names in the security research community; some were people we had never heard of before. Running the BlueHat Prize contest allowed us insight into a greater number of people who are doing some deep thinking in the areas of security mitigation technology. This not only helps Microsoft find and work with talented people, but the spotlight that we can help shine on all of these contestants will hopefully help them market their ideas and talent so that the entire security industry can benefit and improve.

Bonus #2: We aligned some of the top “offensive security” minds to work with us on defense – with excellent results.

I often say that some of the best defenders come from the “offense” side of the security equation. I believe that you truly have to understand how to break into systems in order to devise effective plans for how to defend those systems. One of the goals we set out to accomplish with this contest was to create both an incentive and an opportunity for fame and fortune in the area of security defensive research that never existed at this scale before. We are very happy that the security community responded positively to our challenge, and some great minds chose to participate.

With those positive bonus outcomes we will not wait any longer to announce the winners. For an in-depth technical analysis of the winning entries, with the contest judging criteria applied, please see Matt Miller’s blog post on the SRD blog.

 

Vasilis Pappas wins $200,000 for his idea, kBouncer – an efficient and fully transparent ROP mitigation technique.

Ivan Fratric wins $50,000 for his idea, ROPGuard – a system that can detect and prevent the currently used forms of return-oriented programming (ROP) attacks at runtime. 

Jared DeMott wins an MSDN subscription, valued at $10,000, and was also surprised on stage live with a check for $10,000 cash for his idea, /ROP – a system that lowers the effect of address space disclosures and mitigates known ROP exploits. 

 

So what is next for the BlueHat Prize?

Check the BlueHat Prize website in the next several weeks for an updated page that will include information on the other contest entries. These beautiful minds all deserve the thanks and attention of the security community, and we are excited to provide them with a venue to showcase their defensive security ideas.

One thing is certain – we will continue to invest in security defense at Microsoft, and we will continue to offer cash incentives to the security community for helping Microsoft, and the rest of the industry, to help improve the state of security for the entire ecosystem. In sports, as in life, a great team understands both offense and defense. To address the security threats of today and tomorrow, we as an industry need to appreciate both.

 - Katie Moussouris

Senior Security Strategist, MSRC

Hi everyone,

Maarten here - my team manages the Microsoft Active Protections Program (MAPP) at Microsoft. MAPP gives defenders a head start by sharing vulnerability information with them so that protection signatures are ready at the same time as security updates.

Recently we have seen a fair amount of discussion around the MAPP program. We know that many customers and partners have questions about how MAPP works and how it helps protect customers, therefore I wanted to take this opportunity to explain how we work to facilitate the creation of active protections.

Our goal with MAPP is to have a transparent, effective program in place. As such, we routinely evaluate MAPP partners to ensure they are adhering to program guidelines, taking action to correct any partner deviations from our program charter. We are also continually looking to strengthen our technical and legal controls to help protect our customers.

Why the MAPP program?

Microsoft developed the MAPP program in 2008 in response to an increase in reverse-engineering occurring around our monthly security update releases. We recognized that there were many tools available that enabled security researchers and attackers alike to very quickly identify the root cause of a vulnerability, given the update binaries. We noted that defenders, such as antivirus or intrusion prevention vendors, were in a race against attackers to reverse-engineer our updates in order to create protection signatures.

Before the MAPP program, defenders were at a disadvantage because detecting exploits is difficult, especially if a security vendor does not have full information on the types of conditions that may trigger successful exploitation. A vendor could write a signature for every attack file they receive, but they would need to respond to every file individually, or spend significant amounts of time reverse- engineering our security updates themselves. By providing technical details about a vulnerability directly to defenders, we strengthen their ability to create more effective and accurate signatures in a shorter timeframe.

MAPP also helps to provide a first line of defense for customers who need, or want, to do their own testing prior to deploying our updates. Microsoft thoroughly tests security updates prior to release, however, we do not have the ability to test with all Line of Business applications that corporations develop in-house.

Given the fact that some customers prefer to perform in-house testing, which may delay installation of the security update, we sought partners that our customers already deployed , and could help protect against exploitation of software vulnerabilities. We found those partners in the anti-malware and intrusion prevention industries.

How does the MAPP program work?

Microsoft operates the MAPP program, free of charge, for security vendors that meet our minimum requirements on both the capability they have to protect customers and the number of customers they represent. One can find detailed information on our admission criteria here. We carefully vet and validate these criteria prior to admitting a new partner.

Each month, our team of security engineers work diligently to create information for our partners that helps them detect the exploitation of security vulnerabilities in our products. This data includes, but is not always limited to:

• A detailed technical write-up on the vulnerability;
• A step-by-step process that they can follow to parse an affected file format, or network protocol, that identifies which elements need to have particular values, or exceed specific boundaries, in order to trigger the security vulnerability;
• Information on how to detect the vulnerability, or exploitation thereof (e.g. event log entries, or stack traces);
• A Proof-of-Concept file that is in itself not malicious, but contains the specific condition that will trigger the vulnerability. Partners can leverage this file to test detection signatures they develop using the step-by-step process we provide.

We provide this information to participating vendors shortly in advance of the release of a security update. We base the timeframe on partners' ability to release effective protections, while limiting the risk, should the information be inadvertently disclosed.

Once we provide the information, our engineers remain available to discuss, in detail, steps security vendors can take to detect exploitation of a vulnerability.

Our team also follows up with the partner vendors to better understand which vulnerabilities attackers are  exploiting in the wild, and where we need to improve guidance to account for specific exploitation methods. We regularly update guidance after the initial release to help increase the ability of partners to protect customers.

How the MAPP program helps protect customers

The MAPP program helps vendors build comprehensive detection for vulnerabilities that Microsoft acknowledges or addresses in a security bulletin. MAPP partners are not permitted to release their protection in advance of the security update release.

For example, In the case of an Office exploit, our detection guidance will describe how to parse the Office file and validate which part of the file, and which elements need to be malformed in order to trigger the vulnerability. Without MAPP data, vendors would –in many cases— need to “guess” which values could trigger a crash, and which could not, which reduces the effectiveness of their signatures.

Detection technology developed using MAPP data tends to be more accurate and more comprehensive than detection built without access to the information. Each month after the bulletin release, Microsoft follows up with each vendor individually to track the use of MAPP guidance across the signature base of our partners. When we identify that certain guidance is difficult to implement for our partner base, we work with partners to understand how we can improve the program and enable them to detect these threats more effectively.

The vulnerability addressed in MS10-087, CVE-2010-3333 is a good example. This particular issue affected our Rich Text Format (RTF) parser in Microsoft Office. Given we have had a small sample of bulletins in this particular component; many vendors did not have an effective way of parsing the file type. We worked with our MAPP vendors to develop a tool that would quickly identify malicious files, and distributed it to our partners, despite previously addressing the issue in a security update.

Risks and limitations

We recognize that there is the potential for vulnerability information to be misused. In order to limit this as much as possible, we have strong non-disclosure agreements (NDA)with our partners. Microsoft takes breaches of its  NDAs very seriously. When partners do not successfully protect our intellectual property, we take action, which may include removing the partner from our program.

In addition, we make sure to only release data shortly in advance of the security update. Prior to MAPP, vendors released detection within hours to days following the release of a security update. Today, we send MAPP data to our partners just as far in advance as they need to get that work done, only now, the protection is usually available when we release the update.

But MAPP also has its limitations. For instance, MAPP does not protect against the exploitation of unknown, zero-day vulnerabilities. In order for MAPP to be effective, Microsoft must be aware of the vulnerability before it can distribute guidance to its MAPP partners.

Additionally, MAPP is only useful to the degree that a product can protect against exploitation of the vulnerability. Intrusion Prevention Vendors may not always be best-positioned to detect exploits for Office vulnerabilities, as they may be encoded in a number of different ways across the network. In the same vein, host-based anti-malware products are often not best-positioned to protect against network- based exploits, such as the recent RDP vulnerability.

We recommend our customers work closely with their protection vendors to understand the abilities and limitations of each individual product.

The Value of MAPP

We believe that helping to strengthen community-based defense is key to protecting customers. The MAPP program provides a critical head-start to defenders, while working to minimize risk.

Microsoft is committed to helping customers by providing protection vendors across a wide variety of security industries with valuable protection information. The MAPP program is an important part of this strategy. While risk can never be completely eliminated, we believe the benefits of the program to our customers far outweigh the risks.

 

Cheers!

Maarten Van Horenbeeck
Senior Program Manager, Microsoft Security Response Center

When we announced the BlueHat Prize on August 3, 2011, we did something that no major vendor had ever done before – offer a large cash prize for defensive security research. While a few vendors and others were offering relatively small cash incentives for security researchers to find and report individual vulnerabilities, we decided that, as a platform provider, Microsoft would be most effective if it sought out new, platform-level, defensive technologies that could possibly help defend against entire classes of vulnerabilities. These defenses could help protect our own applications, and have the potential to protect third-party applications that run on our platform.

We received 20 entries to our inaugural BlueHat Prize contest, a response and participation from the security research community that exceeded our expectations. We now know contestants emerged from different areas of the security community – some from academia, some recognized names in the hacker community, and some from other venues entirely. Interestingly, about half of the entries poured in during the last few days – and even the last few hours and minutes— of the contest entry period. Also of note, most of the top-rated entries were among those last-minute submissions, perhaps substantiating the old adage that brilliance emerges under the glaring pressure of a looming deadline. One thing we learned from this experience was not to set future contest deadlines for midnight on a Sunday!

Getting down to business, here are the names of the three finalists, in alphabetical order:

Jared DeMott

Ivan Fratric

Vasilis Pappas

We will award the prizes to the winners at a 10 p.m. ceremony at our researcher appreciation party on July 26, 2012. We have notified the finalists that they have made it to the finals. The finalists won't know who won which prize - the grand prize of $200,000 USD, the second prize of $50,000 USD, and the third prize of an MSDN subscription, valued at $10,000 USD – until we reveal it to them and the world live on July 26.

You can read a little about each of them and their proposed solutions on our BlueHat Prize contest site. After the contest is over, we’ll also be putting up the names and abstracts of the other contestants, so stay tuned for that update sometime after Black Hat.

For now, please join us as we congratulate all the contestants, and especially the three finalists. We appreciate their hard work, and are excited that we can help showcase their ideas that can help make advancements in platform-level security defense.

- Katie Moussouris

Senior Security Strategist, MSRC

As a follow on to the WGA and Security Updates post by Dustin Childs, I wanted to address another common question we get regarding both security and non-security updates that customers receive from Microsoft through Windows Update or Microsoft Update. Customers sometimes feel that somehow the settings they chose in the update console have been changed. Most commonly, customers who have set the client to notify them before installing updates are now getting updates automatically without prompting.

Before I go into details, I want to take a second to describe the differences between Windows Update (WU), Microsoft Update (MU) and Automatic Updates (AU). Windows Update was first developed to provide updates for Windows operating systems. Later, we introduced Microsoft Update to add the ability to offer updates for other Microsoft products such as Office and Windows Live. Automatic Updates is a feature that allows you to configure your computer to automatically download and install updates from either service. For more information, please see the Windows Update FAQ.

So, does Microsoft change your Automatic Update settings? No. Your settings are not changed by Microsoft unless you consent to do so.

The Windows Update team has seen this question several times and has blogged about it in the past. The team identified the following scenarios where your AU settings can be changed. Note that all of them require some action from you:

• During the installation of Windows Vista or Windows 7, you could choose one of the first two recommended options in the “Out of Box Experience” and elect to get updates automatically from Windows.
• You could go to Windows Update in Control Panel and change the AU settings manually.
• You could go to Security Center in Windows Vista or the Action Center in Windows 7 and change the AU setting.
• You could choose to opt in to Microsoft Update from the Microsoft Update Web site.
• You could choose to opt in to Microsoft Update during the installation or the first-run experience of another Microsoft application such as Office 2007.

In addition, third-party products may change AU settings when installed, though this not a common practice. In some cases malware may attempt to change settings or block WU/MU entirely.

We always recommend that you configure your systems to receive Automatic Updates to ensure that you have the latest security and reliability updates for your Microsoft software. If you believe that your settings have changed without your consent or possibly due to malware on the system, please contact the Microsoft Customer Service & Support team for assistance.

Thanks!

Jerry Bryant

*Postings are provided "AS IS" with no warranties, and confers no rights.*

 

I recently returned from the second iteration of the SOURCE Boston computer security conference, and I must say, it was both an intimate conference of less than 250 folks and a high-caliber gathering. As with other conferences that the Microsoft Security Response Center (MSRC) co-sponsors, we see these forums as opportunities that highlight relevant research and showcase how individual strategies can intersect to offer substantial benefits and positive-sum outcomes.

For those of you not familiar with SOURCE, the conference combines business technology and application security tracks over three jam-packed days of presentations from experts in the field. This was the first time that a Security Start-Up Showcase (for all of you VCs/Start up folks out there not taking this economy to heart ;), Discussion Groups, and a Product Education Track were added to the already buff line-up. The attendee make up was approximately 35 percent Security Professionals, 30 percent Executives (Chief Officers), 10 percent Independent Security Researchers, 10 percent Administrators, 10percent Press, and the remainders were Students/Other.

Although there were more talks that sparked my interest than I was able to attend, I did attend some very insightful tracks. One such talk that appealed to me was a panel called The Partial Disclosure Dilemma hosted by Ryan Naraine with SME’s like Dan Kaminsky, Ivan Arce, Katie Moussouris, Dino Dai Zovi, and Alexander Sotirov. For a deeper dive on this subject from the only vendor on the panel, check out Katie’s blog and hear her stress how, "We need more collaboration between those who say the sky is falling, and those upon whom the sky will fall." Throughout this two hour showdown it was apparent that sometimes finding a vulnerability and creating an update is only part of the picture. Often, there has to be a coordinated fix with other vendors and the solution has to then be deployed to protect critical infrastructure. While folks could agree to disagree on the bulk of disputed points, for the most part everyone believed that the industry has got to move forward trusting each other with a more productive and transparent process, whether it be through more peer review among researchers or other communicative and joint mediums. I got a moment of pleasure hearing David Mortman speak out from the audience to say, "I apply MS Patches right away because I know they are going to work and not break anything." W00t!

An earlier talk on How Microsoft Fixes Security Vulnerabilities: Everything you wanted to know about the MSRC Security Update Engineering Process painted a clear picture of the different ways we find variants and work on mitigations and workarounds as part of the Microsoft response process. This talk answered the fascinating question of, "How come some of your in-band updates take a long time, but sometimes you can produce an out-of-band update in a matter of days?" Dave Midturi, Jonathan Ness, and Mark Wodrich dove into some great case studies that showcased in-band updates versus out-of-band updates to answer that ever popular question. For those of you that missed it, I strongly suggest checking it out in the next couple weeks, once it is available on the con site, so you can see first-hand what goes into a Microsoft Security Update, and how out of some 200,000 non-spam e-mails that come in to secure@microsoft.com per year result in approximately 70 bulletins.

All in all, there was a broad range of topics covered that left me simultaneously scared, inspired and contemplative–and I think that sums up exactly what I’m looking for in a security con. And as an added bonus, the con was hosted harbor side in Beantown, not far from Mike’s Pastry cannoli and some good old fashion American history; tea anyone?

-Celene Temkin

Share this post :

*Postings are provided "AS IS" with no warranties, and confers no rights.*

 BlueHat v9 will take place from October 21 to 23 at the Microsoft campus in Redmond. Last year, we experimented with a day dedicated to attacks and a day dedicated to SDL security mitigations. This year, we will give you the best content out there… we are interweaving talks from internal and external security subject matter experts with themes related to e-crime, mobile security, cloud computing, and fuzzing.

We kick it off with the BlueHat Executive Sessions on October 21 with condensed versions of the presentations delivered in a deeply technical "Cliff Notes" style. October 22 and 23 are filled with BlueHat General Sessions for our Microsoft IT pro and developer population.

As a refresher, this conference is primarily about educating our own Microsoft population so we can better understand how to build more secure products. The more we know about the security ecosystem, the more we at Microsoft can truly comprehend and assess our own security reality.

We were able to record talks and deliver them to the masses on the Web for BlueHat v8 -- we'll continue this momentum and keep the "technical equivalent of those free online courses from MIT" coming for all attendees. You can also count on the usual speaker video podcasts, anecdotes, archives, and new to BlueHat v9, the first BlueHat Training Video examining Office Binary File Formats, content provided by our benevolent counterparts on the MSRC Engineering Team.

As always, I’m incredibly excited to see the amazing security education, partnerships, and networking opportunities that come out of our community-based defense platform. Like Alice going through the looking glass to get to Wonderland, we have to change our perspective to understand the threat landscape. Should Alice want to send a message back to Bob in the real world, it’s up to all of us to keep Eve out of the conversation. ;-)

Here’s a brief overview of the talks and speakers. Full details will be available on the BlueHat web site within the week.

October 22, 2009

Morning Block: Hyper Reality: Who’s Been Painting My Roses Red?

Tumble down the rabbit hole with us as we kick off the BlueHat v9 General Sessions examining e-crime motivation, attacks, and how to navigate through the mounting social engineering aspect of security coverage. We kick off with Jose Nazario taking a deep dive into DDoS attacks and their growing role as an online political weapon in Politically Motivated Denial of Service Attacks. Next up, Adobe’s Peleus Uhley and our own Jesse Collins will scrutinize the great power and responsibility that comes along with those flashy Web applications in RIA Security: Real-World Lessons from Flash and Silverlight. We then wrap up the morning *Cheshire Cat grin* exploring a little flaw by the name of ATL in The Language of Trust: Exploiting Trust Relationships in Active Content, by Ryan Smith, Mark Dowd and David Dewey.

Afternoon Block: Mobile (in)Security: Curiouser and Curiouser

As more people onboard themselves to smart mobile devices our wonderland certainly has gotten curiouser and curiouser. Take a ride with us as Luis Miras and Zane Lackey uncover Attacking SMS and show us how easy it is to be a victim when there is hardly any user interaction needed to fall prey to attack. Next up, our own Josh Lackey will serve some of the teacups of goodness and tell us what is on the horizon with Mobile Security and Software Radio. Charlie Miller will then show us how to stand on our heads and use automated fuzzing on the iPhone and outline the vuln he found as well as how to exploit it in iPhone SMS Hacking with a Touch About Payloads. Last, we will hear from Patrick McCanna of AT&T Security as he gives us an overview of security threats that face mobile operators in Mobile Operator Security: Security Challenges for Global Networks for Pocket-sized Devices.

October 23, 2009

Morning Block: Cloud Services & Virtualization: Up Above the World You Fly, Like a Tea Tray in the Sky…

Kicking off day 2, we find ourselves up in the clouds, quite literally. In Cloudifornication: Indiscriminate Information Intercourse Involving Internet Infrastructure, Chris Hoff of Cisco takes us on a journey where we learn some really scary things happening with the massive convergence of virtualization and cloud computing and their effect on security models and the information they are designed to protect. Our own Mad Hatter, John Walton, will walk us through advantages and challenges within the Microsoft Software-plus-Services model in Get Your Head Out of the Clouds: Security in Software-plus-Services. Flying up even further, Robert Fly takes on a journey highlighting unique aspects of building enterprise-ready cloud services and how to avoid the torrential rainfall of unforeseen problems in Creating Clouds: Avoiding Rain In The Transition From On-Premise To Services. We then wind up the afternoon with past BlueHat speakers Billy Rios and Nitesh Dhanjani engaging us in new discussions on the security implications and magic mushrooms that are likely to effect the cloud platforms and their clients in the near future in Sharing the Cloud with Your Enemy.

Afternoon Block: Fuzzing Tools & Mitigations: Chasing the White Rabbit

As we end our adventure through the looking glass, our Google friends Tavis Ormandy and Neel Mehta will paint a picture on how their technique of sub-instruction profiling uncovered multiple vulnerabilities in Windows. Next up, we get to take a peek Under the Kimono of Office Security Engineering with our own Tom Gallagher and Dave Conger as they show us a framework built by the Office team to efficiently fuzz any file format parser. The final session before hearing from our guests in the security community amongst the ill-fated gong of our lighting talks will be Chris Webers’ Character Transformations: Finding Hidden Vulnerabilities. This talk will cover ways which latent character and string handling can transform clever inputs into malicious outputs in cross-site scripting.

We will continue to update the BlueHat blog and the TechNet site to keep you current on the happenings during and around the conference. See you in Wonderland!

-Celene

*Postings are provided "AS IS" with no warranties, and confers no rights.*