Session: Making Security Testing Part of Everyday Development
Wednesday began with a bang!  If I had my doubts about dubious presentations on the first day of TechEd, this Wednesday morning presentation removed them.

Tom Gallagher of Microsoft presented on security testing using real-life examples (including security vulnerabilities found in that darn Clipy).  Tom constructed his presentation around five tips.

Tip 1: Think maliciously
For this tip, Tom talked about an old Microsoft service called Free/Busy.  Part of the service allowed users to send email invitations from a Microsoft web page.  Thinking maliciously, Tom showed how you could easily insert HTML into the body of the message that could execute malicious actions on client desktops.  He also showed how that feature could be exploited for phishing attacks.  After all, the sender does say microsoft.com.  

Tip 2: Identify entry points
I don't remember Tom's example for this one, but here's a list of tools he brought up to help you identify entry points to an application:

• netstat (the -anb argument will show all active connections)
• Microsoft's network monitor v3.0
• ViewPlgs (identifies protocol handlers)
• File Extensions association - this tool shows file extensions and the application to which they are mapped.  Also, certain extensions can be marked as "automatic download," meaning that when you click on a file with such an extension in your browser, it will automatically start to download.  This could be potentially dangerous.
• Process monitor

Tip 3: Understand related attacks
For this one, Tom mentioned the phrase, "same bug, different app."  So, this tip seemed to be about recognizing security flaws common across many applications: your application could be just as susceptible as its peers.  In his example, Tom used the name value Bill O'Henry.  O'Henry should be valid last name; however, your application should be careful to ensure that the single quote value is not a setup for a SQL injection attack.

Tip 4: Deeply understand/test the application
For this tip, I wrote down the quote, "always assume people have your code."  We know that .NET code is generally easy to disassemble with tools like .NET Reflector, so, it seems reasonable to make such an assumption.  I wrote down two tools--LogView and Web Proxy Editor--next to this tip in my notes, but I don't recall what value they added to the tip.

Tip 5: Leverage existing tools
To me, this is always one of the more interesting discussions in the security testing space--what tools, particularly free tools, are available to aid you in testing your applications for security vulnerabilities.  Tom began by talking about fuzzers and fuzz testing.  Then he dove into a long list of tools.  Sorry, but I have no links or definitions of these tools--I list these here as a placeholder for later research:

• Debugger
• SQL Profiler
• XSS Detect
• MITM TCP Proxy
• Looking Glass
• Peach (a type of fuzzer)
• WinDbg

So much to learn, so little time.

Session: Pragmatic Architecture: Presentation
I wanted to make sure to catch a Ted Neward presentation: I've found some of his opinions interesting after hearing him on .NET Rocks and reading his blog.  So, I caught his session on Pragmatic Presentation Architecture.  It was another presentation held in one of those frightful theaters--I made sure I got there in plenty of time to get a seat which was a good thing since the session was soon packed to capacity.

Of the few conferences I've attended, I usually go with the hope of picking up new approaches in code and other technical details that I can later apply to my problems at work.  Thus, when I wind up sitting through a presentation that discusses higher level challenges than just the technical details, I get a little crestfallen.  Certainly, there's a time and place for discussing and embracing these "softer skills" and I probably should develop a better attitude toward such studies.  However, there are only so many hours in a day (and conference) and I'd prefer to spend the majority of that time in the bits and bytes.  

Anyway, Ted's presentation was one of these higher-level type discussions.  What are the important facets to consider when architecting a presentation layer of a solution?  Ted postulates at least five points of consideration:

1. Style - should we seek a graphical solution or simply a command line interface?
2. Implementation - how will the presentation layer be implemented: through code, markup, something else?
3. Perspective - UI requirements might change based on the role of the user.  This can be an important consideration in the architecture.  Reporting can also be a factor here.
4. Cardinality - a UI can be composed of a number of unique elements that interact with each other at some level.  The term "mash-up" fits in this space.
5. Locality - are UI resources remote (server-side code, web services), local (desktop, client-side code), or some hybrid in between?

That's all I have to say about that.

Session: ACE Performance Testing and Tuning Methodology Using Microsoft Visual Studio Team System 2008 and the Latest Microsoft Tools
The Assessment Consulting & Engineering (ACE) team is one of the consulting wings of Microsoft.  Edmund Wong of the ACE team conducted the presentation (I couldn't find any blog by Edmund, but here's the ACE team blog).  

Performance testing and tuning is certainly one the less sexy topics in software development, but it's understanding how to squeeze more performance out of your application can be an incredibly powerful skill.  Edmund began by identify three main objectives of the ACE team regarding performance tuning:

1. Resolve single user problems.
2. Remove stress related problems.
3. Perform capacity testing and planning.

As is typical of most of these kinds of presentations, Edmund used Microsoft tools in his demonstrations: namely, Visual Studio 2008 Team Edition Tester and the Web and Load test tools therein.  Some day, I'd like to see someone duplicate many of these TechEd sessions but add the subtitle, "On the Cheap."  Thus, the question would be, how could I perform similar performance testing and tuning not withTeam Edition Tester, but, rather, with any available open source tools?

Anyway, Edmund walked through the different reports and graphs produced by Team Edition Tester and highlighted some of the metrics he considers important including performance counters, SQL trace information, and IIS log information.  He did mention some free tools he's used including SQL Performance Dashboard (I think this is it) and wcfTrace (or maybe he meant WCF Load Test since I couldn't find a tool called WCF Trace).  He also pointed out the team's Performance Testing Guide.

The one thing I really wanted was an Excel spreadsheet he kept referring to that had recommended thresholds for certain performance metrics (eg. a well tuned application running on a single web server of X specification should be able to serve Y requests per second).  I've searched long and hard for such pronouncements from any relatively respectable organization and always came up empty.  Here, in front of me, was the very document I've been looking for.  Of course, Edmund assured everyone that the spreadsheet would be available along side the Powerpoint presentation in the TechEd website, but I've looked several times and have only found the Powerpoint.  Maybe I'll hold my breath until the DVDs come out...or maybe Edmund was just yanking my chain.

Session: Jumpstart Data Driven Web Applications with ASP.NET 3.5 (Part 1 of 2)
Well, I had to get in at least one Scott Hanselman session, so this was it.  Scott suggested a possibly better title for this session could have been, "Stuff with Data isn't as hard as before."  
Scott began the discussion by identifying where we are today: with lots of data access code based on strings and "loose binding" that can't be checked at compile time (nor do we get any intellisense).  He called this paradigm "tunneling".  For example:

He then showed how you could achieve better results--compile-time checking, strong typing, etc.--with LinqToSql.  For example:

The next topic that sparked my interest was his discussion of the new ListView control in ASP.NET 3.5.  he ran through some pretty sweet examples on how to change the look and feel of this control (more examples here).  Another new control he covered was the LinqDataSource control: used to bind LinqToSql queries to data controls.

Overall, though, the topic that really blew me away was his discussion of the new ASP.NET Dynamic Data.  ASP.NET Dynamic Data is Microsoft's adoption of the concepts of scaffolding and templating that I've seen in Grails and, from what I've heard, is a component of Ruby on Rails although I've spent almost no time in that technology (sorry Ruby folks, but there are only so many hours in the day).  The framework will roll out with .NET Framework 3.5 SP1 which is still in beta.  Don't know if I can wait for the RTM, so I might have to work on spinning up a throw-away VM in which I won't feel uneasy about installing a beta service pack.

On a side note, Scott and many other presenters (myself included), take an approach where they like to spend the majority of their presentation time in the IDE writing code.  This is a fantastic way to spend the presentation time because presenters are forced to prove the veracity of their claims and because the attendees get to see real implementations--not just abstractions on a Powerpoint slide.  The downside of this is that, unless you take meticulous notes (or the presenter supplies the code he wrote), when you review the presentation deck days or weeks or months later, you're going to forget virtually all the concepts discussed.  You'll simply have a deck with several slides saying, "demo here".  Personally, the way I try to combat this problem when I do a presentation is to make sure I take snapshots of key portions of the demo code and paste them on slides in the deck--many times annotating those images with circles, lines, and other notes pointing out the key pieces (I also try to provide my sample code along with the slide deck).  That way, someone reviewing the presentation later on can get most of the concepts by simply thumbing through the slides.

Unfortunately, Scott's deck was riddled with "demo here" slides and no code was available for download from the TechEd site (maybe it will be available when the DVDs come out).  That, plus my sparse notes means that I don't have as much content to share on this session as I'd like.

Session: Microsoft Visual C# Compiler Tricks
Scott Cate did this presentation.  Last year, Scott did a great presentation at the Cincinnati .NET User Group on Model-View-Presenter.  

When I saw the title of this presentation (and like every other presentation, failed to read the abstract), I thought Scott would walk us through interesting approaches to compiling your .NET code from the command line with csc.exe.  Perhaps we'd even get into an interesting Domain Specific Language discussion which requires you to do some interesting compiler tricks to get the compiler to understand your made-up language (for example, this).

Scott immediately dismissed these theories: on the contrary, we would be working entirely in the IDE in .NET 2.0 and perform tricks to retro-fit some of the new features of .NET 3.5 back into a purely .NET 2.0 application.  Hmm.  Sounds interesting.  Not sure that I would want to do that in my business applications, but I'll bite.

Scott then went on an interesting tour of ways you can force the .NET 2.0 compiler to allow you to use certain .NET 3.5 syntax.  One of these is the Extension method.  Scott referenced this blog post from Daniel Moth and walked through the example.  One cool thing Scott did was to make sure his compiled DLLs would appear in Solution Explorer of Visual Studio and associate the DLLs to .NET Reflector so that you could easily see the IL code generated by the compiler.

Scott continued to talk about some other features of .NET 3.5 that you could refactor back into your .NET 2.0 code, but that's where my notes start to go fuzzy.  I wrote down Lambda expressions and Linq to SQL and Linq to XML, but now I'm not really sure what I meant to say about those topics.  Fortunately, Scott has been kind enough to post his slide deck and his example code.  (Scott Cate, like Scott Hanselman, is one of these guys who likes to live in the IDE for most of his presentation time, usually beginning with a blank page and coding until his can successfully convey his message.  Thankfully, Scott Cate has pushed up his demo code to the inter-tubes.)

Session: Beer and Mexican Food
I was fortunate enough to find out the Friday before TechEd that my pals Jay and Art would be attending the conference, too.  I've worked with both Jay and Art to a limited degree at my company.  Both live and work in different states.  I met Jay once but never met Art face-to-face, so I was looking forward to hanging around with the two during our week in Orlando.  The TechEd sessions kept the three of us very busy, but we found a bit of a break Wednesday evening (before the Birds of a Feather sessions) to catch dinner at a local Mexican restaurant and catch up on our different activities in our work and personal lives.

Birds of a Feather Session: Microsoft .NET Framework-Based Application Hardening
Art, Jay, and I spent too much time chowing down tacos and we ended up missing the first session of the BOFs.  Frankly, few of the sessions in that first hour seemed very appealing, anyway.  I probably would have taken in either Design for Testability or Dynamic Language and the DLR, but wasn't really upset that I missed either.  In contrast, the next set of BOFs had me at a six-way tie for which session I would attend (if only human cloning were a viable option).  Would the lucky winner be:

1. ASP.NET vs. MVC.  What's your take?
2. Top Considerations for Ensuring Microsoft .NET Framework Based Application Manageability
3. Making Sense of All: Heterogeneous Data Access on the Microsoft .NET Framework 3.5
4. Patterns and Practices in the Real World
5. Code Style and Standards
6. Microsoft .NET Framework Based Application Hardening

Hmm.  Hard decision.  Since, in many ways, my team at work is kind of like a mini Patterns and Practices team, let's try that one.  Well, as I said, we had been busy chowing down tacos and, as a consequence, were about 10 minutes late to the second set of BOFs.  When we tried to enter the Patterns and Practices in the Real World session, we were turned away at the door by the TechEd staff: "this session is already full."  Ok.  Now I'm down to a five way tie.  Well, security is an oft overlooked topic at my company (at least from the development perspective), so let's attend that one.  So, Art and I went to the Microsoft .NET Framework Based Application Hardening; Jay proceeded to a different session.

For a while, I have been keenly interested in the concept of .NET application hardening.  Usually when I hear the term hardening, it's used in a kind of CISSP where security professionals spend time analyzing and locking down network peripherals and server operating systems.  In the .NET space, we hear about ways to prevent SQL injection and cross-site scripting attacks, but there seems to be a large gap between a hardened OS and application code written to avoid certain kinds of attacks.  I'm thinking mainly of what can be done at the machine.config and web.config levels to harden a .NET application.  

It seems to me, the largest consideration in this space is Trust Mode, but I'm sure there are other considerations, too (machine validation key?  code access security?).  Microsoft generally recommends that web servers hosting Internet-facing applications or serving as a shared hosting environment for different applications run in Medium Trust mode (see Stefan Schackow's book, Professional ASP.NET 2.0 Security, Membership, and Role Management, for a good reference on Trust Mode and other ASP.NET 2.0 security considerations).  I do know that Microsoft does have their Security Development Lifecycle (SDL) guidance, but I have not found the time to work through those tools--maybe this BOF would cover that guidance, too.

So, my hope for this BOF was to discuss all the various hardening options that lie between the operating system and your C# code and, as pertains to Trust Mode, are there relatively easy ways to test your application under Partial Trust?  I would hope that the answer is not--install your app on a development server running in Medium Trust and do your testing there.  Rather, I would hope that by now there are ingenuitive ways to test your application in Medium Trust right on your development workstation.  Could NUnit do this or would  you have to do this as part of your integration tests and make sure to set your trust level to Medium in your web.config before running your tests?  It would be nice if there were some button you could flip to suddenly run debug code in Medium Trust, but that may be asking too much.

Anyway, the first thing I noticed as I walked into the room was that there were only six people in attendance--two of which were the moderators and one who was merely an INETA representative.  As soon as Art and I sat down, one of the moderators turned to us and asked us our thoughts on .NET application hardening.  Not blinking, I launched into my diatribe of thoughts on the topic (some of which I've listed above).  Shortly after I began my monologue, two of the attendees left the room.  I'd like to think they were just leaving so that they could get a fresh start on the next days activities, but we all probably know the real reason.

When I finally came up for air, the moderators introduced themselves and their particular angle on the topic.  They were two guys from PreEmptive Solutions: the makers of Dotfuscator.  Their angle on application hardening was to ensure that your IL is sufficiently scrambled so that a malicious person cannot reverse engineer your code.  Hmm.  Hadn't really considered obfuscation in my list of hardening concerns.  It seems to me that if a malicious person made it through to the point where your IL was in danger of being reverse engineered, you were already too screwed to care about that.  Never the less, I guess you could call obfuscation another consideration in application hardening--certainly if you make a commercial desktop application.  

The moderators also talked about the rigor with which their product has been developed.  Since a light version of .NET Obfuscator is distributed with Visual Studio, Microsoft demands that the development effort for .NET Obfuscator adhere to a littany of standards set by the SDL; so, yes, we did talk a little about the SDL, but only in terms of certifying products with the Microsoft seal of approval.  Of course, I don't see the applications I write as requiring Microsoft's security seal of approval, but who knows?  Maybe when that million dollar idea finally surfaces in my brain, I will need the SDL seal of approval.  So, now it's just a matter of waiting on my brain.  Brain?  Hello, you there?