Read more: http://technet.microsoft.com/en-us/security/cc185712.aspx

Download now: http://www.microsoft.com/downloads/details.aspx?FamilyId=CD057D9D-86B9-4E35-9733-7ACB0B2A3CA1&displaylang=en

Take a few moments and give yourself a security checkup. If you have any comments or feedback on the tool, feel free to leave them here on my blog—I’ll make sure the right people see it.

From the download page:

The MSAT employs a holistic approach to measuring your security posture by covering topics across people, process, and technology. Findings are coupled with prescriptive guidance and recommended mitigation efforts, including links to more information for additional industry guidance. These resources may assist you in keeping you aware of specific tools and methods that can help change the security posture of your IT environment.

There are two assessments that define the Microsoft Security Assessment Tool:

• Business Risk Profile Assessment
• Defense in Depth Assessment (UPDATED)

The questions identified in the survey portion of the tool and the associated answers are derived from commonly accepted best practices around security, both general and specific. The questions and the recommendations that the tool offers are based on standards such as ISO 17799 and NIST-800.x, as well as recommendations and prescriptive guidance from Microsoft’s Trustworthy Computing Group and additional security resources valued in the industry.

After completing an Assessment, you will gain access to a detailed report of your results. You may also compare your results with those of your peers (by industry and company size), provided that you upload your results anonymously to the secure MSAT Web server. When you upload your data the application will simultaneously retrieve the most recent data available. To be able to provide this comparative data, we need customers such as you to upload their information. All information is kept strictly confidential and no personally identifiable information whatsoever will be sent.

As promised, we recorded all of the day’s presentations and we’ve published them on TechNet:

Keynote Address by Scott Charney, Corporate VP, Microsoft Trustworthy Computing

Threat Modeling at EMC and Microsoft by Danny Dhillon of EMC and Adam Shostack of the Microsoft SDL team (of course)

Mitigations Unplugged by Matt Miller, Microsoft Security Science team

Concurrency Attacks on Web Applications by Scott Stender and Alex Vidergar of iSEC Partners

Fuzzed Enough? When it’s OK to Put the Shears Down by Jason Shirk, Dave Weinstein and Lars Opstad, Microsoft Security Science team

Real World Code Review – Using the Right Tools in the Right Place at the Right Time by Vinnie Liu of Stach & Liu

In addition to the presentations, we also recorded some short interviews (about 10 minutes long) with each of the speakers. If you’re just looking for a quick summary of a particular talk, these interviews are the place to start:

Threat Modeling at EMC, Danny Dhillon

Threat Modeling at Microsoft, Adam Shostack

Mitigations Unplugged, Matt Miller

Concurrency Attacks on Web Applications, Scott Stender and Alex Vidergar

Fuzzed Enough? Jason Shirk and Dave Weinstein

Real World Code Review, Vinnie Liu

I hope at least 96% of online readers will be able to directly apply this material to their products, just like the show attendees. Please post back and let us know, either way. And let us know what you’d like to see for next year. We have big plans to build on our success and make SDL Sessions 2.0 even bigger and better than the first.

Note that if I want to opt out of further communications, I have to do two separate things -- which actually becomes three things.

• First I have to click the last link to opt out of future TechTarget spam. (Yes, I deleted the actual links. But certainly none of my trustworthy readers would attempt to re-subscribe me, right...? <g>
• But that isn't enough -- I also have to separately opt out of future Avaya spam! (Why does the no-more-from-Avaya link live on a techtargetmail.com server? Whatever.) Clicking on that link eventually does land me on an avaya.com page, where I have to confirm my email address and indicate they don't have my permission to send me spam. Hmm, too difficult to embed my email in that link, when the other techtargetmail.com link did embed my email?
• Then after submitting it, another page pops up telling me that I'll soon receive an email with additional instructions! In this email there's a link -- to avaya.com with my email address embedded -- that I must click, I guess to double plus confirm that yes, I really really really do wish never to hear from you again. Clicking that link takes me to a page that promises my "permissions have successfully been set. Thank you."

A pox on both your houses, TechTarget and Avaya. I never asked for your stuff. Go away.

Spam, my friends, is only going to get worse. It was so easy to ban junk faxes in 1991. But even those regulations were weakened in 2005. So do you really think we'll see anything even remotely logical for outlawing spam? I doubt it, unless we the citizens foment a revolt. Let's get cracking!

Received: from SVC-EXGWY-E801.partners.extranet.microsoft.com (10.251.24.242)
by tk5-exhub-c102.redmond.corp.microsoft.com (157.54.18.53) with Microsoft
SMTP Server (TLS) id 8.1.291.1; Tue, 16 Sep 2008 11:27:56 -0700
Received: from mail139-wa4-R.bigfish.com (216.32.181.113) by
mail04.microsoft.com (10.253.160.184) with Microsoft SMTP Server (TLS) id
8.1.291.1; Tue, 16 Sep 2008 11:27:55 -0700
Received: from mail139-wa4 (localhost.localdomain [127.0.0.1])    by
mail139-wa4-R.bigfish.com (Postfix) with ESMTP id 018C11184C2    for
<steriley@microsoft.com>; Tue, 16 Sep 2008 18:27:50 +0000 (UTC)
X-BigFish: ps16(zz18c1K1936K2b7wcak69jzzzz2af1jz2fh6bh5eh65h)
X-Spam-TCS-SCL: 4:0
Received: by mail139-wa4 (MessageSwitch) id 1221589667478982_28100; Tue, 16
Sep 2008 18:27:47 +0000 (UCT)
Received: from pp.techtargetmail.com (pp.techtargetmail.com [65.211.80.227])
    by mail139-wa4.bigfish.com (Postfix) with SMTP id 46566978071    for
<steriley@microsoft.com>; Tue, 16 Sep 2008 18:27:47 +0000 (UTC)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pp.techtargetmail.com; b=iOmibOrM91/1Ugy2gj3QbWo74T2m3GuhmwxZCXJQpFT+nwRES8QKg+4vjt48SNp7WWJExG61Ge+DtnKD3KVI3KwqTKzkPRVrEBF0DCHhYot6VAG/EyEr5vb5RhBz+91yvNhbIqITzGnuQ+uBDJzyc6gU0FHfBl0Fa3S/phcPELM=;
Message-ID: <a818b044.724694.236c8ee748f7dd97.1.n.4.2971370188@pp.techtargetmail.com>
Date: Tue, 16 Sep 2008 14:27:47 -0400
thread-index: a818b044.724694.236c8ee748f7dd97.1.n.4
Reply-To: Avaya <a818b044.724694.236c8ee748f7dd97.1.n.4@pp.techtargetmail.com>
From: Avaya <Avaya@pp.techtargetmail.com>
To: Steve Riley <steriley@microsoft.com>
Subject: 7 Tips to Ensure Readiness for UC Deployment
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4133
Return-Path: a818b044.724694.236c8ee748f7dd97.1.n.4@pp.techtargetmail.com
X-MS-Exchange-Organization-PRD: pp.techtargetmail.com
Received-SPF: Pass (SVC-EXGWY-E801.partners.extranet.microsoft.com: domain
of Avaya@pp.techtargetmail.com designates 65.211.80.227 as permitted sender)
receiver=SVC-EXGWY-E801.partners.extranet.microsoft.com;
client-ip=65.211.80.227; helo=mail139-wa4-R.bigfish.com;
X-MS-Exchange-Organization-PCL: 2
X-MS-Exchange-Organization-Antispam-Report: DV:3.3.6916.600;SV:3.3.6916.813;SID:SenderIDStatus Pass;OrigIP:65.211.80.227
X-MS-Exchange-Organization-SCL: 2
X-MS-Exchange-Organization-SenderIdResult: PASS

The following message was sent to you as a subscriber to third party offers from a TechTarget property, including our network of Search sites, Bitpipe.com, CIO Decisions Magazine, Information Security Magazine, Storage Magazine, KnowledgeStorm, TheServerSide.com and/or TheServerSide.NET. To unsubscribe, see below.
____________________________________________________________

How should you evaluate the move to unified communications (UC)? Who within which parts of an organization will benefit? Will UC reduce the time to market? Read this E-Guide for answers to these questions and a better look at how the value of UC will, at first, be less of a financial issue and more of a productivity improvement issue that translates into financial benefits. Download this white paper now: http://pp.techtargetmail.com/c.asp?724694&236c8ee748f7dd97&1

When implementing unified communications, there are a number of important issues to think about and questions to ask. This E-Guide analyzes seven phases to ensure you reap the full benefits of UC in each. If you're ready to take the plunge but you're not sure your business or your infrastructure is - download this E-Guide now.

Click here to learn more: http://pp.techtargetmail.com/c.asp?724694&236c8ee748f7dd97&1

"If you do not wish to receive future promotions directly from Avaya please forward this e-mail to {link removed} ; please note that there is a separate opt-out procedure below to be removed from the list from which this email originated."
____________________________________________________________

Please do not reply to this email.  To unsubscribe from all future third party offers from all TechTarget properties, simply click here: {link removed}

TechTarget | 117 Kendrick Street, Suite 800 | Needham, MA 02494

It's a man-in-the-middle attack. "The Internet's Biggest Security Hole"  has been that interior relays have always been trusted even though they are not trustworthy.

That could apply word for word to how MQ Series and other enterprise messaging systems are deployed. Let's say you are a bank and have been happily running your business on a mainframe for decades. Life is good, come in at 9 leave at 5, count the cash. Then some dotcommer comes along and tells you that you need to get online. What are you gonna do? Rewrite your whole system from scratch? Hard to make that case.

It's a man-in-the-middle attack. "The Internet's Biggest Security Hole" (the title of that first link) has been that interior relays have always been trusted even though they are not trustworthy.

Blogger: Pete Lindstrom

Microsoft’s Security Development Lifecycle (SDL) is the main product of its Trustworthy Computing Initiative, launched from the now-famous Bill Gates memo in 2002. Six years into the initiative, Microsoft surely must be reaping the benefits of, for example, the well-publicized security training every developer went through.

So, how do we determine whether the SDL is working? Microsoft suggests that this is a simple exercise – simply compare the number of public vulnerabilities disclosed for products prior to SDL with similar products developed after SDL. The most recent case was comparing Windows XP SP2 to Vista vulnerabilities in the first year. The count is down and Microsoft provides a quick and easy example of the logical fallacy “post hoc ergo propter hoc” which in this case means “public perception is ripe for deception.”

The biggest problem with Microsoft’s assertion is simply that there are too many variables that are uncontrolled and could just as easily be making the difference. There are too many unknowns related to effort of independent researchers and focus on a specific Microsoft platform. At the very least, Microsoft has done an admirable job in making people feel more secure. (I happen to believe the SDL is working as well, but that belief is a matter of conjecture without strong evidence).

If Microsoft wants to use public vulnerability counts as the ultimate arbiter, it needs to create an environment where independent researchers are encouraged to find bugs. Creating a controlled bounty program for a limited time period would increase incentives and at least provide circumstantial evidence of SDL effectiveness. Interestingly, if the number of vuln counts was higher, it still wouldn’t mean SDL is ineffective,  but the framing of the conversation would be entirely different.

The plot thickens when Microsoft makes claims that spending more time and leveraging external resources are a part of SDL. Whether they are or not, there is a big difference between making programmers more secure developers and simply spending more money on a problem. You don’t really need SDL if the latter is more beneficial.

But if public vulnerability counts are not the answer, what should Microsoft be doing to demonstrate the effectiveness of its SDL? Well, it is much easier to determine causality by controlling for all other variables, and conducting a test of two groups – one with SDL training and one without. Comparing vulnerability creation rates per unit output (either developer-hours or lines of code, for example) would go a long way to answering the effectiveness question.

At this stage, it might be difficult to find a group of developers in-house that aren’t SDL trained, and Microsoft is fully vested in the program such that it wouldn’t allow an untrained developer on a real project, so a new experiment may need to be set up using some arbitrary project created solely for the experiment. Alternatively, Microsoft could measure the differences in development skills after an acquisition and during the transition to SDL-trained developers. Or a final option is to conduct a private benchmarking exercise where the effectiveness is compared among multiple groups.

At this stage, it may be even harder to figure out the effectiveness of an SDL-trained QA group. Presumably, QA training will help the group find more bugs earlier, but if the developers are getting better, then the rate of finding vulnerabilities will go down. There are techniques associated with defect density that could be leveraged to determine this effectiveness level as well.

Creating fewer bugs and finding more bugs early, I believe, are the real expectations of SDL, and finding those numbers would provide much stronger evidence for or against its effectiveness. Not only that, but this information would better frame discussions around ultimate effectiveness of software development: Microsoft is likely to have spent more money than anyone else on its SDL efforts, so the benchmarks provided by the company would serve as an upper limit for expectations.