J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

  • J.D. Meier's Blog

    Performance Guideline: Use TryParse Method to Avoid Unnecessary Exceptions


    Prashant Bansode, Bhavin Raichura, and Girisha Gadikere teamed up with Claudio Caldato (CLR team) to create some new performance guidelines for .NET Framework 2.0.  The guidelines use our new guideline template.


    Use TryParse Method to Avoid Unnecessary Exceptions

    Applies to

    • NET 2.0

    What to Do
    Use TryParse Method instead of Parse Method for converting string input to a valid .Net data type. For example, use TryParse method before converting a string Input to integer data type.

    The Parse method will throw exception - ArgumentNullexception or FormatException or OverflowException, if the string representation cannot be converted to the respective data type.

    Unnecessary Throwing Exceptions and Handling the same such as above has a negative impact on the performance of the application. The TryParse method does not throw an exception if the conversion fails instead it returns false, and hence saves exception handling related performance hit.

    If it is required to convert a string representation of a data type to a valid .Net data type, use TryParse method instead of calling the Parse method to avoid unnecessary exception.

    The following code snippet illustrates how to use TryParse method :

        Int32 intResult;
        if (Int32.TryParse(strData, intResult))
           // process intResult result
          //error handling

    Problem Example
    Consider a Windows Forms application for creating an Invoice. The application takes user inputs for multiple items as product name, quantity, price per unit and date of purchase. The user provides these inputs in the text boxes. The user can enter multiple items in an invoice at a given time and then finally submit the data for automatic billing calculation. The application internally needs to convert the string input data to integer (assume for simplicity). If the user enters invalid data in the text box, the system will throw an exception. This has adverse impact on performance of the application.

        private Int32 ConvertToInt(string strData)
                  return Int32.Parse(strData);
            catch (exception ex)
                  return 0; //some default value

    Solution Example
    Consider a Windows Forms application for creating an Invoice. The application takes user inputs for multiple items as product name, quantity, price per unit and date of purchase. The user provides these inputs in the text boxes. The user can enter multiple items in an invoice at a given time and then finally submit the data for automatic billing calculation. The application internally needs to convert the string input data to integer (assume for simplicity). If the user enters invalid data in the text box, the system will not throw unnecessary exceptions and hence improves the application performance.

        private Int32 ConvertToInt(string strData)
            Int32 intResult;
            if (Int32.TryParse(strData, intResult))
                return intResult;
             return o;  //some default value

    Additional Resources


  • J.D. Meier's Blog

    Guidelines Template


    Sometimes the guidelines in our guidance such as Improving Web Application Security, Improving .NET Application Performance and .NET 2.0 Security Guidance are missing some of the important details such as when, why or how.  To correct that, we've created a template that explicitly captures the details.  We use this template in Guidance Explorer.  I'll also be posting .NET Framework 2.0 performance examples that use this new template.

    Guideline Template

    • Title
    • Applies To
    • What to Do
    • Why
    • When
    • How
    • Problem Example
    • Solution Example
    • Related Items

    Test Cases

    The test cases are simply questions we use to help improve the guidance.  The guidelines author can use the test cases to check that they are putting the right information into the template.  Reviewers use the test cases as a check against the content to make sure it's useful. 


    • Does the title clearly state the action to take?
    • Does the title start with an action word (eg. Do something, Avoid something)?

    Applies To

    • Versions are clear?

    What to Do

    • Do you state the action to take?
    • Do you avoid stating more than the action to take?


    • Do you provide enough information for the user to make a decision?
    • Do you state the negative consequences of not following this guideline?


    • Do you state when the guideline is applicable?
    • Do you state when not to use this guideline?


    • Do you state enough information to take action?
    • Do you provide explicit steps that are repeatable?

    Problem Example

    • Do you show a real world example of the problem from experience?
    • If there are variations of the problem, do you show the most common?
    • If this is an implementation guideline, do you show code?

    Solution Example

    • Does the example show the resulting solution if the problem example is fixed?
    • If this is a design guideline is the example illustrated with images and text?
    • If this is an implementation guideline is the example in code?

    Additional Resources

    • Are the links from trusted sites?
    • Are the links correct in context of the guideline?

    Related Items

    • Are the correct items linked in the context of the guideline?

    Additional Tests to Consider When Writing a Guideline

    • Does the title clearly state the action to take?
    • Does the title start with an action word (eg. Do something, Avoid something)?
    • If the item is a MUST, meaning it is prevelant and high impact, is Priority = p1?
    • If the item is a SHOULD, meaning it has less impact or is only applicable in narrower circumstances, is Priority = p2?
    • If the item is a COULD, meaning it is nice to know about but isn't highly prevelant or impactful, is Priority = p3?
    • If this item will have cascading impact on application design, is Type = Design?
    • If this item should be followed just before deployment, is concerned with configuration details or runtime behavior, is Type = Deployment?
    • If this item is still in progress or not fully reviewed, is Status = Beta?
  • J.D. Meier's Blog

    Guidance Explorer Beta 2 Release


    We released Guidance Explorer Beta 2 on CodePlex.  Guidance Explorer is a patterns & practices R&D project to improve finding, sharing and creating prescriptive guidance.  Guidance Explorer features modular, actionable guidance in the form of checklists, guidelines, how tos, patterns … etc.

    What's New with This Release

    • Guidance Explorer now checks for updated guidance against an online guidance store.
    • Source code is available on CodePlex so you can shape or extend Guidance Explorer for your scenario.
    • Guidance Explorer Web Edition is available for quick browsing of the online guidance store.

    Learn More


    Send your feedback to getool@microsoft.com.

  • J.D. Meier's Blog

    ASP.NET 2.0 Internet Security Reference Implementation


    The ASP.NET 2.0 Internet Security Reference Implementation is a sample application complete with code and guidance.  Our purpose was to show patterns & practices security guidance in the context of an application scenario. We used Pet Shop 4 as the baseline application and tailored it for an internet facing scenario.  The application uses forms authentication with users and roles stored in SQL.

    Home Page/Download

    3 Parts
    The reference implementation contains 3 parts:

    1. VS 2005 Solution and Code 
    2. Reference Implemenation Document
    3. Scenario and Solution Document 

    The purpose of each part is as follows:

    1. VS 2005 Solution and Code - includes the Visual Studio 2005 solution, the reference implementation doc, and the scenario and solution doc.
    2. Reference Implemenation Document (ASP.NET 2.0 Internet Security Reference Implementation.doc) - is the reference implementation walkthrough document containing implementation details and key decisions we made along the way.  Use this document as a fast entry point into the relevant decisions and code.
    3. Scenario and Solution Document (Scenario and Solution - Forms Auth to SQL, Roles in SQL.doc) - is the more general scenario and solution document containing key decisions that apply to all applications in this scenario.

    Key Engineering Decisions Addressed
    We grouped the key problems into the following buckets:

    • Authentication
    • Authorization
    • Input and Data Validation
    • Data Access
    • Exception Management
    • Sensitive Data
    • Auditing and Logging

    These are actionable, potential high risk categories.  These buckets represent some of the more important security decisions you need to make that can have substantial impact on your design.  Using these buckets made it easier to both review the key security decisions and to present the decisions for fast consumption.

    Getting Started

    1. Download and install the ASP.NET 2.0 Internet Security Reference Implementation.
    2. Use ASP.NET 2.0 Internet Security Reference Implementation.doc to identify the code you want to explore
    3. Open the solution, Internet Security Reference Implementation.sln, and look into the details of the implementation
    4. If you're interested in testing SSL, then follow the instructions in  SSL Instructions.doc.


  • J.D. Meier's Blog

    patterns & practices Guiding Principles


    As part of our technical strategy on the patterns & practices team, we created a set of guiding principles for our product development teams:

    • Long-term customer success
    • Help customers balanced tension between new product features and application portfolio stability
    • Collaborative, transparent execution
    • Explicit intent and rigorous prioritization
    • Quality over scope
    • Context precision over one-size fits all
    • Framework for evolution and innovation over fixed solutions
    • Skeletal over full-featured
    • Modular over monolithic
    • Easy to adopt; easy to adapt, easy to consume incrementally

    If you're familiar with Stephen Covey, he espoused using principles as a way to govern actions without needing an explicit rule for every situation.  An advantage of this is that you leave flexibility in the tactics while still guiding the outcome.

    To create the princples, we used the approach for the values in the Agile Manifesto which contrasts one value over another (e.g. Customer collaboration over contract negotiation.) Using this approach, we thought of the outcomes we wanted to move away from and outcomes we wanted to achieve.

  • J.D. Meier's Blog

    Test Our patterns and practices Guidance Explorer


    I've been relatively quiet these past few weeks, getting ready to release our patterns & practices Guidance Explorer. Guidance Explorer is a new, experimental tool from the patterns & practices team that radically changes the way you consume guidance as well as the way we create it. If you’ve felt overwhelmed looking across multiple sources for good security or performance guidance then Guidance Explorer is the tool for you. You can use one tool to access a comprehensive, up to date, collection of modular guidance that will help you with your tough development tasks and design decisions. Guidance Explorer will allow you to create and distribute a set of standard best-practices that your team can adhere to for performance and security. The project includes the tool, Guidance Explorer, and a library of guidance for developers, Guidance Library. The Guidance Library will be updated weekly, ensuring you always have the most up to date information.

    What's In It For You

    • If you build software with the .NET Framework, use Guidance Explorer to find the "building codes" for the .NET technologies, in terms of security and performance. They are complimentary to FX Cop rules.
    • If you want to set development standards and best practices for your team, use Guidance Explorer views to build and then distribute your team’s standard rule-set.
    • If you author guidance for development teams, use Guidance Explorer to create guidance for your teams in a more efficient and effective way by leveraging our templates, information models, key concepts, and tooling support.

    What is Guidance Explorer
    Guidance Explorer is a client-side tool that lets you find, filter, and sort guidance. You can organize custom guidance collections into persistent views and share these views with others. You can also save these custom views of the guidance as indexed Word or HTML documents. You can browse guidance by source, such as the patterns & practices team. You can also browse by topic, such as security or performance, or by technology, such as ASP.NET 1.1 or ASP.NET 2.0. Within a given topic or technology, you can then browse guidance within more fine-grained categories. For example, within security, you can browse by input/data validation, authentication, authorization .. etc.

    Guidance Explorer was designed to simplify the creation and distribution of custom guidance. To author guidance, Guidance Explorer, includes a simple editor that uses templates for guidance. Each template includes a schema and test cases. For example, each guideline item should include what to do, why, how, a problem example, and solution example, as well as related items and where to go for more information. We created these templates by analyzing what's working and not working from our several thousands of pages of guidance over the past several years, around security and performance.

    What is Guidance Library
    Guidance Library is the collection of knowledge that is viewable by Guidance Explorer. It's organized by types, such as guidelines and checklists. Each type has a specific schema and test cases against that schema to help enforce quality. The library is also organized by topics, such as security and performance. The library is extensible by design so that we can add new types and new topics that prove to be useful.

    Not every type of guidance goes into the guidance library. For example, you don't use it to find monolithic guides or PDFs. The most important criteria for the modules in the library is that they are atomic units of action. They can directly be tested for relevancy. They can also be tested for the results they produce and how repeatable those results are.

    How To Get Started 

    1. Join the Guidance Explorer project
    2. Download Guidance Explorer
    3. Watch the video tutorials

    The key to getting started is getting the tool up and running so you can play with it, and watching the short videos (1-2 minute long) to learn the main features and usage scenarios.

    Your First Experiment with Guidance Explorer
    For your first test with Guidance Explorer, try creating a Word doc that has just the guidelines you want. 

    To run your first experiment:

    1. Create a custom view of the guidance
    2. Save the view fo the guidance as a Word doc

    How To Get Involved

    1. Join the CodeGallery workspace.  To join the workspace, sign up at the Guidance Explorer Home on Codegallery
    2. Subscribe to the RSS feeds.   To subscribe to the feeds, use the RSS buttons in each section of Guidance Explorer Home on Codegallery
    3. Participate in the newsgroups.  To participate in the newsgroups, use the Guidance Explorer Message Boards on Codegallery
    4. Provide feedback on the alias.  To do so, send email to GETOOL at Microsoft.com.

    What's Next
    These are some of the ideas we'd like to implement:

    • VS.NET integration
    • refactoring additional guidance (e.g. existing patterns & practices guidance such as the data access, exception management, and caching guidance)
    • New guidance types (such as "test cases", "code examples", "project patterns", "whiteboard solutions")
    • New topics (such as reliability, manageability, … etc.)
      integrating bodies of guidance and ecosystems (such as integration with product documentation)

    I also hope to create a model for "Guidance Feeds", where you can subscribe to relevant guidance, as well as integrate many of the emerging social software concepts, such as allowing the network/community to rate the guidance, rate the raters and contributors, and create community-driven, shareable custom views.

    About Our Team
    Our core team consists of:

    • Prashant Bansode.   Prashant was a core member of my Whidbey Security Guidance Project, so he's very seasoned.   I chose him specifically because of his unmatched ability to execute, and because he is one of the best customer champions I know.  What surprised me about Prashant is his ability to not only manage his own work, but help guide others, and he really gets how to deliver incremental value.
    • Diego Gonzalez.  Diego is a coding machine.  He's also capable of bridging dreams and reality with working models.   Usually, by the time you've finished your sentence on what you'd like to see, Diego's already implementing it. 
    • Ed Jezierski.   Ed's simply brilliant.  I've never seen a more impressive mix of people focus and technical expertise.  If you can dream it up, Ed can make it happen.  If you can't dream it up, Ed can dream it up for you.  Just insert a random wish and Ed can turn it into a working prototype, and incredible slideware to match.  Ed brings to the table a ton of social software concepts and ideas around taking guidance to the next level.  I've worked with Ed for many years, but it's been a while since we've partnered up on the same project.  I look forward to many brainstorms, whiteboard sessions, and off the deep end conversations over lunch.
    • Ariel Neisen.  Ariel is a developer on the team.  Ariel works for Lagash with Diego and has been Diego's coding partner.
    • Mike Reinstein.   Mike works for Security Innovation.  He's a Web application security expert.  He not only brings security development and design experience, but strong technical writing skills that have contributed to exceptional content.
    • Paul Saitta.   Paul is previously a member of IO Active, now working for Security Innovation.  He's an expert in Web applications and white-box security audits.  He's been able to distill thousands of hours of customer audits into prescriptive guidance that illuminates common mistakes in the real world.
    • Jason Taylor.   I first met Jason during my Whidbey Security Guidance Project.  He impressed me with his ability to think on his feet, execute at a rate faster than most people can ever imagine, and his ability to distill and document expertise at a level few individuals can go.  Jason has 7 years Microsoft experience under his belt, and was one of Microsoft's first test-architects.  Now he's a V.P. for Security Innovation's security consulting group.  Aside from bringing a wealth of security experience to the table,  Jason has a lot of ideas around how to improve guidance for customers in very practical ways.

    Key Links

  • J.D. Meier's Blog

    Security WebCast - Using Security Code Reviews to Quickly and Effectively Improve the Security of Your Applications


    Rudolph Araujo (or Rudy as we call him), from Foundstone, is doing a Web Cast on performing Security Code Reviews, Using Security Code Reviews to Quickly and Effectively Improve the Security of Your Applications .

    In his Web Cast, Rudy will accomplish the following:

    • Show you key effective strategies for security code reviews
    • Briefly discuss threat modeling and its benefits
    • Discuss how security code review and threat modeling are critical yet just part of an overall software security engineering process

    One of the most important things Rudy will show you is how to use control flow analysis and data flow analysis to analyze application security.  Rudy will also show you how to chunk up your security analysis using security categories such as authentication, authorization, input/data validation ... etc., to perform incremental and iterative analysis.

    Rudy has worked closely with our patterns & practices security team over the years so he's intimately familiar with our approaches around security code review approach and Security Engineering (short-cut: http://msdn.com/SecurityEngineering).  In fact, Rudy played a key role during the development of our How To: Perform a Security Code Review for Managed Code (Baseline Activity), where you can see Rudy listed as a contributing author.

    Event Information

    • Title: Using Security Code Reviews to Quickly and Effectively Improve the Security of Your Applications 
    • When: May 24th 
    • Time: 11:00 AM - 12:00 PM (Pacific)
    • Event Registration page 
  • J.D. Meier's Blog

    Performance and Scalability Checkpoint to Improve Your Software Engineering


    When a patterns & practices deliverable would be ready to ship, our General Manager (GM) would ask me to sign off on the performance and security.  I would usually be pulled thin so I needed a way to scale.  To do so, I created a small checkpoint for performance and scalability.  The checkpoint was simply a set of questions that are a forcing function to make sure you've addressed a lot of the basics (and avoid a lot of "do-overs").  Here's what we used internally:

    Checkpoint: Performance and Scalability

    Customer Validation

    1. List 3-5 customers that say performance/scalability for the product is a "good deal" (e.g. they pay for play)

    Product Alignment

    1. Do you have alignment w/the future directions of the product team?
    2. Who from the product team agrees?


    1. Has Product Support Services (PSS) reviewed and signed off?
    2. Which newsgroups would a customer go to if performance and scalability problems occur?

    Performance Planning

    1. Performance model created (performance modeling template)?
    2. Budget.  These are performance and scalability constraints.  What are the maximum acceptable values for the following?
      1. Response time?
      2. Maximum operating CPU usage?
      3. Maximum network bandwidth usage?
      4. Maximum memory usage?
    3. Performance Objectives
      1. Workload
      2. % of overhead over relevant baselines (e.g. Within 5% performance degradation from version 1 to version 2)
      3. Response Time
      4. Throughput
      5. Resource Utilization (CPU, Network, Disk, Memory)

    Hardware/Software Requirements

    1. List requirements for customer installation.
      1. Hardware?
      2. Minimum hardware requirements?
      3. Ideal hardware requirements?
      4. Minimum software required:

    Performance Testing

    1. Lab Environment.  What is the deployment scenario configuration you used for testing
      1. Hardware?
      2. CPU?
      3. # of CPUs?
      4. RAM?
      5. Network Speed?
    2. Peak conditions.  What does peak condition look like?
      1. How many users?
      2. Response time?
      3. Resource Utilization?
      4. Memory?
      5. CPU?
      6. Network I/O?
    3. Capacity.  How many users until your response time or resource utilization budget is exceeded?
      1. What is the glass ceiling? (e.g. the breaking point)
      2. Number of users?
      3. Response time?
      4. Resource Utilization?
      5. CPU?
      6. Network?
      7. Memory?
    4. Failure.  What does failure look like in terms of performance and scalability?
      1. Does the application fail gracefully?
      2. What fails and how do you know?
      3. Response time exceeds a threshold?
      4. Resource utilization exceeds thresholds? (CPU too much?)
      5. What diagnostic/monitoring clues do you see:
      6. Exceptions?
      7. Event Log entries?
      8. Performance counters to watch?
    5. Stress Scenarios.  What does stress look like and how do you respond?
      1. Contention?
      2. Memory Leaks?
      3. Deadlocks?
      4. What are the first bad signs under stress?


    1. What is the technology/approach used for instrumenting the codebase?
      1. Are the key performance scenarios instrumented?
      2. Is the instrumentation configurable (On/off? Levels of granularity?)?

    The checkpoint helped the engineering team shape their approach and it simplfied my job when I had to review.  You can imagine how some of these questions can shape your strategies.  This is by no means exhuastive, but it was effective enough to tease out big project risks.  For example, do you know when you're software's going to hit capacity?  Did you completely ignore the customer's practical environment and use up all their resources?  Do you have a way to intstrument for when things go bad and is this configurable?  When your software is in trouble, what sort of support did you enable for troubleshooting and diagnostics?

    While I think the original checkpoint was helpful, I think a pluggable set of checkpoints based on application types would be even more helpful and more precise.  For example, if I'm building a Web application, what are the specific metrics or key instrumentation features I should have?  If I'm building a smart client, what sort of instrumentation and metrics should I bake in? … etc.  If and when I get to a point where I can do more checkpoints, I'll use a strategy of modular, type-specific, scenario-based checkpoints to supplement the baseline checkpoint above.

  • J.D. Meier's Blog

    Strategic Stories


    I'm realizing more and more how stories help you drive a point home.  It's one thing to make a point, it's another for your story to make the point for you.  If your ideas aren't sticking, or you're not getting buy in, maybe a compelling story is the answer. 

    Crafting useful stories is an art, and, now, apparently a science.  Srinath pointed me to Stories at Work on 50Lessons.com.    The video shares a story about using stories as a catalyst for change and a recipe for good strategic stories:

    1. Make stories short (1 -2 minutes) so they can be retained
    2. Limit stories to no more than 2 or 3 characters, so it's easy to follow
    3. Build your story around a singular message.
    4. Tell your story in the present tense so participants can relate
    5. Use powerful images to tie to a theme
    6. Repeat a phrase or word that is the essence of your message

    The value of the stories is they help you engage people and they have a more powerful recall than slides, facts and figures.

  • J.D. Meier's Blog

    Security Innovation Security Engineering Study


    The Security Innovation Security Engineering study,  Comparing Security in the Application Lifecycle - Microsoft and IBM Development Platforms Compared, is timely, given the emerging industry emphasis on integrating security in the life cycle. 

    My favorite quote in the study is "The patterns & practices security guidance covers the key security engineering activities better than any other resource we’ve found."  I think this reflects the fact we have more than 2,500 pages of security guidance (see Security Guidance, Security Engineering, Threat Modeling, and Improving Web Application Security) , and we've integrated our guidance into MSF/VS 2005 (see MSF/VS 2005 and p&p Integration.) 

    The study was available from the MSDN Security DevCenter for a while but seems to have fallen off.  I've summarized the study here for quick reference:

    Security Innovation evaluated the guidance and tools of Microsoft's and IBM's development platforms.  The study compared the support available to a development team via security guidance, documentation and security focused features in the life-cycle tool suites.  Gartner reviewed the approach.

    Evaluation Criteria

    • CoverageHow well do the provided tools and guidance cover the key set of security areas? 
    • QualityHow effective and accurate are the tools and guidance?
    • VisibilityHow easy is it to find the tools and guidance and then apply it to your security needs?
    • UsabilityAre the tools and guidance precise, comprehensive and easy to use?


    • Outstanding: 81-100%
    • Good: 61-80%
    • Average: 41-60%
    • Below Average: 21-40%
    • Poor: 0-20%

    Scorecard Categories

    • Basic Platform Security.  When used in accordance with its documentation, a platform should be inherently secure.
    • Platform Security Services.  A mature platform should include services that make it easier for developers to implement security features in their applications.
    • Platform Security Guidance. A secure platform is much less useful if it lacks proper guidance.
    • Software Security Engineering Guidance.  It is not possible to develop a secure application unless security is a focus during every phase of the development lifecycle.
    • Security Tools.  A secure platform should include tools that make it easier to define, design, implement, test, and deploy a secure application.

    Results of the Study

    First, here's a couple key points, then the summaries are below:

    • Microsoft beat IBM in every category around guidance.
    • Microsoft beat IBM in three out of four categories around tools.


    1. Platform Overall
      1. Overall: 36%
      2. Coverage: 62%
      3. Quality: 70%
      4. Visibility: 17%
      5. Usability: 72%
    2. Platform Security Guidance
      1. Overall: 50%
      2. Coverage: 81%
      3. Quality: 85%
      4. Visibility: 17%
      5. Usability: 84%
    3. Security Engineering Guidance
      1. Overall: 25%
      2. Coverage: 50%
      3. Quality: 64%
      4. Visibility: 17%
      5. Usability: 69%
    4. Security Tools
      1. Overall: 32%
      2. Coverage: 55%
      3. Quality: 59%
      4. Visibility: 56%
      5. Usability: 63%


    1. Platform Overall
      1. Overall: 67%
      2. Coverage: 88%
      3. Quality: 85%
      4. Visibility: 61%
      5. Usability: 80%
    2. Platform Security Guidance
      1. Overall: 76%
      2. Coverage: 93%
      3. Quality: 85%
      4. Visibility: 67%
      5. Usability: 91%
    3. Security Engineering Guidance
      1. Overall: 78%
      2. Coverage: 100%
      3. Quality: 89%
      4. Visibility: 67%
      5. Usability: 79%
    4. Security Tools
      1. Overall: 47%
      2. Coverage: 71%
      3. Quality: 78%
      4. Visibility: 50%
      5. Usability: 68%

    Quotes from the Study

    • Microsoft’s overall rating of 67% reflects the impressive level of focus Microsoft has applied to application security in the past several years.
    • IBM’s overall score of 36% is the result of a more disjointed approach to security.  Security guidance is spread throughout the IBM web site and is difficult to discover.
    • The patterns & practices security guidance covers the key security engineering activities better than any other resource we’ve found.

    More Information
    For more information, see Comparing Security in the Application Lifecycle -
    Microsoft and IBM Development Platforms Compared
    at Security Innovation's site.  They created four documents that take you through the details and results: Executive Summary, Research Overview, Full Detailed Reports and Results, and Methodology.

  • J.D. Meier's Blog

    OpenHack 4 (eWeek Labs): Web Application Security


    Whenever I bring up the OpenHack 4 competition, most aren't ware of it.  It was an interesting study because it was effectively an open "hack me with your best shot" competition. 

    I happened to know the folks on the MS side, like Erik Olson and Girish Chander, that helped secure the application, so it had some of the best available security engineering.  In fact, customers commented that it's great that Microsoft can secure its applications ... but what about its customers?  That comment was inspiration for our Improving Web Application Security:Threats and Countermeasures guide.

    I've summarize OpenHack 4 here, so it's easier for me to reference.

    Overview of OpenHack 4
    In October 2002, eWeek Labs launched its fourth annual OpenHack online security contest.  It was designed to test enterprise security by exposing systems to the real-world rigors of the Web.  Microsoft and Oracle were given a sample Web application by eWeek and were asked to redevelop the application using their respective technologies. Individuals were then invited to attempt to compromise the security of the resulting sites.  Acceptable breaches included of cross-site scripting attacks, dynamic Web page source code disclosure, Web page defacement, posting malicious SQL commands to the databases, and theft of credit card data from the databases used.

    Outcome of the Competition
    The Web site built by Microsoft engineers using the Microsoft .NET Framework, Microsoft Windows 2000 Advanced Server, Internet Information Services 5.0, and Microsoft SQL Server 2000 successfully withstood over 82,500 attempted attacks to emerge from the eWeek OpenHack 4 competition unscathed.

    More Information

    For more information on implementation details of the Microsoft Web application and configuration used for the OpenHack competition, see "Building and Configuring More Secure Web Sites: Security Best Practices for Windows 2000 Advanced Server, Internet Information Services 5.0, SQL Server 2000, and the .NET Framework"

  • J.D. Meier's Blog

    @Stake Security Study: .NET 1.1 vs. WebSphere 5.0


    I like competitive studies.  I'm usually more interested in the methodology than the outcome.  The methodology acts as a blueprint for what's important in a particular problem space. 

    One of my favorite studies was the original @Stake study comparing .NET 1.1 vs. IBM's WebSphere security, not just because our body of guidance made a direct and substantial difference in the outcome, but because @Stake used a comprehensive set categories and an evaluation criteria matrix that demonstrated a lot of depth.

    Because the information from the original report can be difficult to find and distill, I'm summarizing it below:

    Overview of Report
    In June 2003, @Stake, Inc., an independent security consulting firm, released results of a Microsoft-commissioned study that found Microsoft's .Net platform to be superior to IBM's WebSphere for secure application development and deployment.  @stake performed an extensive analysis comparing security in the .NET Framework 1.1, running on Windows Server 2003, to IBM WebSphere 5.0, running on both Red Hat Linux Advanced Server 2.1 and a leading commercial distribution of Unix..

    Overall, @stake found that:

    • Both platforms provide infrastructure and effective tools for creating and deploying secure applications
    • The .NET Framework 1.1 running on Windows Server 2003 scored slightly better with respect to conformance to security best practices 
    •  The Microsoft solution scored even higher with respect to the ease with which developers and administrators can implement secure solutions

    @stake evaluated the level of effort required for developers and system administrators to create and deploy solutions that implement security best practices, and to reduce or eliminate most common attack surfaces.

    Evaluation Criteria

    • Best practice compliance.  For a given analysis topic, to what degree did the platform permit implementation of best practices?
    • Implementation complexity.   How difficult was it for the developer to implement the desired feature?
    • Documentation and examples.  How appropriate was the documentation? 
    • Implementor competence.  How skilled did the developer need to be in order to implement the security feature?
    • Time to implement.  How long did it take to implement the desired security feature or behavior? 

    Ratings for the Evaluation Criteria

    1. Best Practice Compliance Ratings
      1. Not possible
      2. Developer implement
      3. Developer extend
      4. Wizard
      5. Transparent
    2. Implementation Complexity Ratings
      1. Large amount of code
      2. Medium amount of code
      3. Small amount of code
      4. Wizard +
      5. Wizard
    3. Quality of Documentation and Sample Code Ratings
      1. Incorrect or Insecure
      2. Vague or Incomplete
      3. Adequate
      4. Suitable
      5. Best Practice Documentation
    4. Developer/Administrator Competence Ratings
      1. Expert (5+ years of experience
      2. Expert/intermediate (3-5 years of experience)
      3. Intermediate
      4. Intermediate/novice
      5. Novice (0-1 years of experience)
    5. Time to Implement
      1. High (More than 4 hours)
      2. Medium to High (1 to 4 hours)
      3. Medium (16-60 minutes)
      4. Low to Medium  (6-15 minutes )
      5. Low (5 minutes or less )

    Scorecard Categories
    The scorecard was organized by application, Web server and platform categories.  Each category was divided into smaller categories to test the evaluation criteria (best practice compliance, implementation complexity, quality of documentation, developer competence, and time to implement).

    Application Server Categories

    1. Application Logging Services
      1. Exception Management
      2. Logging Privileges
      3. Log Management
    2. Authentication and Access Control
      1. Login Management
      2. Role Based Access Control
      3. Web Server Integration
    3. Communications
      1. Communication Security
      2. Network Accessible Services
    4. Cryptography
      1. Cryptographic Hashing
      2. Encryption Algorithms
      3. Key Generation
      4. Random Number Generation
      5. Secrets Storage
      6. XML Cryptography
    5. Database Access
      1. Database Pool Connection Encryption
      2. Data Query Safety
    6. Data Validation
      1. Common Validators
      2. Data Sanitization
      3. Negative Data Validation
      4. Output Filtering
      5. Positive Data Validation
      6. Type Checking
    7. Information Disclosure
      1. Error Handling
      2. Stack Traces and Debugging
    8. Runtime Container Security
      1. Code Security
      2. Runtime Account Privileges
    9. Web Services
      1. Credentials Mapping
      2. SOAP Router Data Validation

    Host and Operating System Categories

    1. IP Stack Hardening
      1. Protocol Settings
    2. Service Minimization
      1. Installed Packages
      2. Network Services

    Web Server Categories

    1. Architecture
      1. Security Partitioning
    2. Authentication
      1. Authentication Input Validation
      2. Authentication Methods
      3. Credential Handling
      4. Digital Certificates
      5. External Authentication
      6. Platform Integrated Authentication
    3. Communication Security
      1. Session Encryption
    4. Information Disclosure
      1. Error Messages and Exception Handling
      2. Logging
      3. URL Content Protection
    5. Session Management
      1. Cookie Handling
      2. Session Identifier
      3. Session Lifetime

    More Information
    For more information on the original @stake report, see the eWeek.com article, .Net, WebSphere Security Tested.

  • J.D. Meier's Blog

    Flawless Execution


    In the book Flawless Execution, James D. Murphey, shares techniques used by fighter pilots to achieve peak performance, accelerate the learning curve, and make performance more predictable and repeatable.

    The essence of the execution engine is a set of iterative steps:

    • Plan.  Evaluate multiple courses of action, evaluate them, and take the best parts.
    • Brief.  Tell everybody how we're going to carry out the plan and what we're going to do today.
    • Execute.  Act out the script you created in the brief.
    • Debrief.  Evaluate execution errors and successes.

    Murphy connects the execution framework to the strategy.  If they aren't aligned, you can win the battle, but lose the war.  He distinguished strategy from tactices, by saying strategy is about four things:

    1. Where are we going to be?
    2. What are we going to apply resources for or against?
    3. How are we going to do this?
    4. When are we going to stop doing this?

    Murphy is very prescriptive.  For every technique, there's a set of steps and checkpoints.  I've successfully scaled down some of the techniques, such as Future Picture, to meet my needs. 

    What I like about the overall execution framework is that its practices are drawn from life and death scenarios.  Fighter pilots need to learn what works from their missions, and share it as quickly as possible.  What I also like is that Murphey illustrates how ordinary people, are capable of execution excellence.

  • J.D. Meier's Blog

    Meeting with Gabriel and Sebastian from PreEmptive


    I met with Gabriel Torok and Sebastian Holst of PreEmptive Solutions, the other day.  PreEmptive makes obfuscator products, including the Dotfuscator that comes with Visual Studio.  Gabriel founded PreEmptive more than 10 years ago, and it was originally a code optimization company (The dual focus on performance and security resonates with me).

    I was familiar with obfuscation and its limitations.  I wasn't as familiar with some of the internals of specific obfuscation techniques, such as identifier renaming, control flow obfuscation, metadata removal, and string encryption, or how you can tweak or tune these.  One surprise for me was that obfuscation for some scenarios could yield a 30-40% reduction in size (the result of shortening identifier names and "pruning" libraries that are never called.)

    Gabriel's interested in creating obfuscation guidance for the community.  I gave him my wish list:

    • Scenarios.  Illustrate how obfuscation fits in, including high level, when to use or not to use, as well as lower-level choices among obfuscation techniques.
    • Anatomy of obfuscation.  From a developer mindset, this means knowing how things work.  Walk me through the bits and pieces and the execution flow.
    • Impact and surprises.  If I introduce obfuscation, tell me things I might run into.  For example, is there impact to my build process?  What about servicing my codebase? Is there a difference between obfuscationg with ASP.NET using dynamic compilation vs. pre-compilation?  What if you need to GAC?  What if you sign your code with a 509 cert?
    • Performance considerations.  Take me through trade-offs and scenarios where performance can be improved or degraded.  Give me insight into how to influence or tweak my obfuscation approach.

    Sebastion and I exchanged some metaphors.  In reference to the limits of obfuscation, I said that just because door-locks don't prevent car thieves, that doesn't mean cars should come without locks.  Sebastion related it to smoke alarms.  In the grand schema of things, smoke alarms play a key role in saving lives and limiting damage, but to the individual, there's not a lot of value until a fire occurs.  The fact that smoke alarms are low cost and simple helps justify their common use.  He added, risk varies by context, so the value to hotels or restaurants may be more obvious.

    It was an interesting and insightful meeting and I look forward to Gabriel's whitepaper.

  • J.D. Meier's Blog

    Code Example Schema for Sharing Code Insights


    This is the emerging schema and test-cases we're using for code examples:

    Code Example Schema (Template)

    • Title
    • Summary
    • Applies To
    • Objectives
    • Solution Example
    • Problem Example
    • Test Case
    • Expected Results
    • Scenarios 
    • More Information
    • Additional Resources

    Code Example Schema (Template explained and test cases)

    Insert title that resonates from a findability perspective.

    Test Cases:

    • Does the title distinguish it from related examples?
    • If technology is in the title, is the version included?

    Insert 1-2 lines max description of the intent.

    Test Cases:

    • Does the description crisply summarize the solution
    • Is the intent of the code clear?

    Applies To
    Insert the key technologies/platform the code applies to.

    Test Cases:

    • Versions are clear?

    Insert bulleted list of task-based outcomes for the code.

    Test Cases:

    • Is it clear why the solution example is preferred over the problem example?

    Solution Example
    Insert code example as a blob within a function.  The blob allows quick reading of the code.  It also allows quickly testing from a function, inlining within other code, or refactoring for a given context.  The alternative is to factor up front, but this increases complexity and can negatively impact consumption.  This leaves refactoring to the developer for their given scenario.

    Test Cases:

    • Is the code example organized as a blob within a function that can easily be tested or refactored?
    • Do the comments add insights around decisions?
    • Are the comments concise enough so they don't break the code flow?

    Problem Example
    List examples of common mistakes along with issues.

    Test Cases:

    • Are the mistakes clear?
    • Are the patterns and variations of the problems clear?

    Test Case
    Insert relevant setup information.  Write the code to call the functional blob from Solution Example.

    Test Cases:

    • Is setup Information included?
    • Does the example call the functional blob in the Solution example?

    Expected Results
    Insert what you expect to see when running the test case.

    Test Cases:

    • If you run the Test Case, do the Expected Results match?

    Insert bulleted list of key usage scenarios.

    Test Cases:

    • Usage scenarios are a flat list?
    • Usage scenarios are based on real-world?
    • Usage scenarios convey when to use the code?

    More Information
    Optional.  Insert more information as necessary.  This could be background information or interesting additional details.

    Additional Resources
    Optional.  Insert bulleted list of descriptive links to resources that have direct value or relevancy.

    Test Cases:

    • The links starts with the pattern "For more information on X, see ..."?
    • The links are directly relevant versus simply nice to have?

    We're using this schema for our Security Code Examples Project.

  • J.D. Meier's Blog

    Project Success Indicators (PSI)


    In the book, "How To Run Successful Projects III, The Silver Bullet", Fergus O'Connell uses a scoring system to predict project success.

    1. (20) Visualize the goal
    2. (20) Make a list of jobs
    3. (10) There must be one leader
    4. (10) Assign people to jobs
    5. (10) Manage expectations, allow a margin of error, have a fallback position
    6. (10) Use an appropriate leadership style
    7. (10) Know what's going on
    8. (10) Tell people what's going on
    9. (00) Repeat steps 1-8 until step 10
    10. (00) The Prize

    What this means is that having clarity on what you want to accomplish and being able to identify the work to be done (steps 1 and 2) are the more significant indicators of project success. 

    After managing several projects over the years, I tend to agree.  Step 2 is particularly interesting because it not only helps you calculate schedule and budget, but it helps you identify the right people for the jobs.

  • J.D. Meier's Blog

    Ten Steps for Structured Project Management


    In the book "How to Run Successful Projects III, The Silver Bullet", Fergus O'Connell identifies ten steps to structured project management:

    1. Visualize the goal
    2. Make a list of jobs
    3. There must be one leader
    4. Assign people to jobs
    5. Manage expectations, allow a margin of error, have a fallback position
    6. Use an appropriate leadership style
    7. Know what's going on
    8. Tell people what's going on
    9. Repeat steps 1-8 until step 10
    10. The Prize

    These ten steps help make project management consistent, predictable, and repeatable.  The first five steps are about planning your project.  The last five are about implementing the plan and achieving the goal.  These steps are based on 25 years of research into why some projects fail and others succeed.

    I like to checkpoint any project I do against these steps.  I find that when a project is off track, I can quickly pinpoint it to one of the steps above and correct course.

  • J.D. Meier's Blog

    Security Code Examples Project


    I'm working with the infamous Frank Heidt, George Gal and Jonathan Bailey to create a suite of modular, task-based security code examples.  They happen to be experts at finding mistakes in code.  Part of making good code is knowing what bad code looks like and more importantly what makes it bad, or what the trade-offs are.  I've also pulled in Prashant Bansode from my core security team to help push the envelope on making the examples consumable.  Prashant doesn't hold back when it comes to critical analysis and that's what we like about him.

    For this exercise, I'm time-boxing the effort to see what value we produce within the time-box.  We carved out a set of candidate code examples by identifying common mistakes in key buckets, including input/data validation, authentication, authorization, auditing and logging, exception management and a few others.  We then prioritized the list and do daily drops of code.  The outcome should be some useful examples and an approach for others to contribute examples.

    Sharing a chunk of code is easy.  We quickly learned that sharing insights with the code is not.  Exposing the thinking behind the code is the real value.  We want to make that repeatable.  I think the key is a schema with test cases.

    Here's our emerging schema and test cases ....

    Code Example Schema (Short Form)

    • Title
    • Summary
    • Applies To
    • Objectives
    • Solution Example
    • Problem Example
    • Test Case
    • Expected Results
    • More Information
    • Additional Resources

    For more information on the schema and test cases, see Code Example Schema for Sharing Code Insights.

    Today we had a deeply insightful review with Tom Hollander, Jason Taylor, and Paul Saitta.  Jason and Paul are on site while we're solving another class of problems for customers.  They each brought a lot to the table and collectively I think we have a much better understanding of what makes a good, reusable piece of code. 

    We made an important decision to optimize around "show me the code" and then explain it, versus a lot of build up and then the code.  Our emerging schema has its limits and does not take the place of a How To or guidelines or a larger resuable block of code, but it will definitely help as we try to share more modular code examples that demonstrate proven practices.

  • J.D. Meier's Blog

    Axiomatic Design


    A few folks have asked me about Axiomatic design that I mentioned in my post on Time-boxes, Rhythm, and Incremental Value.  I figure an example is a good entry point. 

    An associate first walked me through axiomatic design like this.  You're designing a faucet where you have one knob for hot and one knob for cold.  Why's it a bad design?  He said because each knob controls both temperature and flow.  He said a better design is one knob for temperature and one knob for flow.  This allows for incremental changes in design because the two requirements (temperature and flow) have their independence.  He then showed me a nifty matrix on the board that mathematically *proved* good design.

    At the heart of Axiomatic Design are these two Axioms (self-evident truth):

    • Axiom 1 (independence axiom): maintain the independence of the Functional Requirements (FRs).  
    • Axiom 2 (information axiom): minimize the information content of the design.

    For an interesting walkthrough of Axiomatic Design, see "A Comparison of TRIZ and Axiomatic Design".

  • J.D. Meier's Blog

    MSF/VS 2005 and patterns and practices Integration


    Around mid 2004, Randy Miller approached me with "I want to review MSF Agile with you with the idea of incorporating your work."  I didn't know Randy or what to make of MSF Agile, but it sounded interesting. 

    Randy wanted a way to expose our security and performance guidance in MSF.  Specifically he wanted to expose "Improving Web Application Security" and "Improving .NET Application Performance" through MSF.  I was an immediate fan of the idea, because customers have always asked me to find more ways to integrate in the tools.  I was also a fan because my two favorite mantras to use in the hallways are "bake security in the life cycle" and "bake performance in the life cycle".  I saw this as a vehicle to bake security and performance in the life cycle and the tools.

    We had several discussions over a period of time, which was a great forcing function.  Ultimately, we had to figure out a pluggable channel for the guidance, the tools support and how to evolve over time.  My key questions were:

    • how to create a pluggable channel for the p&p guidance?
    • what does a healthy meta-model for the life cycle look like?
    • how to integrate key engineering techniques such as threat modeling or performance modeling?
    • how to get a great experience outside the tool and a "better together" experience when you have the tools?

    These questions lead to a ton of insights around meta-models for software development life cycles, context-precision, organizing engineering practices and severl other concepts worth exploring in other posts.

    My key philosophies were:

    • life cycle options over one size fits all
    • pluggable techniques that fit any life cycle over MSF only
    • proven over good ideas
    • modular over monolithic

    Randy agreed with the questions and the philosophies.  We came up with some working models for pluggable guidance and integration.  His job was to make the tools side happen.  My job was to make the guidance side happen.  I now had the challenge and opportunity of making guidance online and in the tools.  This is how I ended up doing guidance modules for for .NET Framework 2.0.  This also drove exposing p&p Security Engineering which is baked into MSF Agile by default.

    Randy summarized our complimentary relationship best ...
    “The Patterns and Practices group produces an important, complimentary component to what we are building into MSF. In Visual Studio, our MSF processes can only go so deep on a topic. Our activities can provide the overview of the steps that a role should do but cannot provide all of the educational background necessary to accomplish the task.
    As many of the practices that we espouse in MSF (such as threat modeling) require this detailed understanding, we are building links into MSF to Patterns and Practice online material. Thus the activities in MSF and the Patterns and Practices enjoy a very complimentary relationship. The Patterns and Practices group continues to be very helpful and our relationship is one of very open communication.“

    Mike Kropp, GM of our patterns & practices team, liked the results ...
    “– it was great to see the progress you’ve made over the past couple of months.  here’s my takeaway on what you’ve accomplished:

    • you’ve agreed on the information model for process and engineering practices – I know this was tough but it’s critical to achieving alignment 
    • the plug-in architecture allows us to evolving the engineering practices and serve them up nicely for the customer – in context 
    • the model you’ve come up with for v1 allows us to adapt & evolve over time (schemas, types, etc..)
      ... this is a great example of how we can work together to help your customers and partners.”

    I remember asking Randy at one point, why did you bet on our security and performance work?  He told me it was because he knew we vetted and proved our work with customers and industry experts.  He also knew we vetted internally across our field, support and the product teams.  I told him if anybody wondered who we worked with, have them scroll down to the contributors and reviewers list for the security work as an example.

    We have more work ahead of us, but I think we've accomplished a lot of what we set out to do and for that I'm grateful to Randy Miller, David Anderson and their respective team.

  • J.D. Meier's Blog

    Time-boxes, Rhythm, and Incremental Value


    Today I had some interesting conversations with Loren Kohnfelder. Every now and then Loren and I play catch up. Loren is former Microsoft. If you don't know Loren, he designed the CLR security model and IE security zones. He created a model for more fine-grained control over security decisions and he's a constant advocate for simplifying security.

    You might think two guys that do security stuff would talk about security. We didn't. We ended up talking about project management, blogging, social software, and where I think next generation guidance is headed. I'll share the project management piece.

    I told Loren I changed my approach to projects. I use time boxes. Simply put, I set key dates and work backwards. I chunk up the work to deliver incremental value within the time boxes. This is a sharp contrast from the past where I'd design the end in mind and then do calculated guesstimates on when I'd be done, how much it would cost and the effort it would take.

    I use rhythm for the time boxes. I use a set of questions to drive the rhythm … When do I need to see results? What would keep the team motivated with tangible results? When do customers need to see something? I realize that when some windows close, they are closed forever. The reality is, as a project stretches over time, risk goes up. People move, priorities change, you name it. When you deal with venture capitalists, a bird in hand today, gets you funding for two more in the bush.

    Loren asked me how do I know the chunks add up to a bigger value. I told him I start with the end in mind and I use a combination of scenarios and axiomatic design. Simply put, I create a matrix of scenarios and features, and I check dependencies across features among the scenarios. What's my minimum set of scenarios my customers want to have something useful? Can I incrementally add a scenario? Can I take away scenarios at later points and get back time or money without breaking my design? Sounds simple, but you'd be surprised how revealing that last test is. With a coupled design, if you cut the wrong scenario you have a cascading impact on your design that costs you time and money.

    We both agreed time boxed projects have a lot of benefits, where some are not obvious. Results breed motivation. By using a time box and rhythms, you change the game from estimating and promising very imprecise variables to a game of how much value can you deliver in a timebox. Unfortunately sometimes contracts or cultures work against this, but I find if I walk folks through it, and share the success stories, they buy in.

  • J.D. Meier's Blog

    patterns and practices Security Training Modules Pilot


    Want to see some short training videos and labs by Keith Brown on some common security issues? 

    I thought it would be great to do a pilot around modular, self-paced training.  By modular, I mean you get a video that's 10 minutes or less, and a lab that's 20 minutes or less.

    The Pilot

    Modular, Relevant, Real-World

    To make the training valuable, I wanted to improve on a few things:

    • Whenever, wherever.  I didn't want to have to be in a class-room to get the quick and dirty training to get my job done.
    • Modular.  I don't have big chunks of time.  I need training I could incrementally consume as I want it or have time for it.
    • Relevant.  I wanted to be able to get training for a specific task at hand.  Again, it helps to be modular.
    • Realworld.  Sometimes training can be academic.  I wanted training that was relevant to both the guidance and tempered with real-world scenarios.

    For some simple usage scenarios, I had the following in mind:

    • See a single lab page for a specific task (for example, cross-site scripting)
    • Watch a short video.
    • Work through a small lab.
    • Get the relevant guidance.

    The idea was that the community could help point each other to more fine-grained training or big picture as needed.  On my end, I could point to the training to help walk customers through our patterns & practices Security Guidance.

    Training Layout
    The modules are laid out as follows:

    All pages are simple and bare by design (to render more as we learn more and based on feedback).  The key to having a page per lab means we'll be able to provide fine-grained access and jumps from guidance.

    More Information

    For more information about the patterns & practices Security Training Modules, see About the patterns & practices Security Training Modules

  • J.D. Meier's Blog

    Security Wiki on Channel9


    Today, I cleaned up my Security Wiki on Channel9 at http://channel9.msdn.com/Security

    The purpose of this Wiki is to let me share information that may not be completely fit and finish like on MSDN.  This comes in handy for a few things:

    • EcoSystem.  It's a part of my security information ecosystem.  Effectively, I flow information from my internal Wiki to Channel9 and then to MSDN at http://msdn.com/SecurityGuidance, as the information morphs from quick and dirty to more polished.  Think of it as incrementally rendering guidance and various degrees of "good enough".
    • Emerging and volatile information.  I like carving out the volatile information from the more stable information.  If the information is too volatile, I prefer to keep it on the Wiki and let the churn wear down before moving to MSDN.  For example, while we continue to learn the FAQs, I like having the ASP.NET 2.0 Security FAQ on the Wiki.
    • Experiments.  I like using the Wiki to explore ideas.  This could be a new way to see information or a new way to capture information.
    • Feedback.  I like proactive feedback.  With the Wiki, I can send links to Wiki pages to my customer base and ask their thoughts.  It's also easy to for customers to add comments to the end of a Wiki page.
    • "Good enough" information.  This may be the single most important feature.  Some information never quite makes the bar to be published on MSDN, but gets 80% of the way there.  For example, we didn't flesh out our ASP.NET 2.0 Security Scenarios and Solutions during our Security Guidance for .NET 2.0 project, but that doesn't mean you can't use them as is, to maybe save yourself a few cycles of your own pathfinding.
    • Indexes and views.  The Wiki let's me quickly mock up new ways to see information.  For example, I was able to create indexes for security checklists, security guidelines, and security how tos.  I later used this model on MSDN.  It also let me test out a way to present FAQs (see the ASP.NET 2.0 Security FAQ)
    • Stories and meta-information.  The Wiki is a good place to share some of the thinking and the behind the scenes.  In one example, I put together the key components of our application security methodology.  It's a bit choppy and more visual than text, but some customers were curious about the foundation of our guidance.  In another example, Ward shares his experience walking through end to end application scenarios with our p&p security team in "Making My First Scenario and Solution"

    What's in store going forward for Security Wiki?  Well, potentially a lot.  I'm still thinking through some of the possibilities.  If you have things you'd really like to see more of, let me know, and I'll see what I can do.

  • J.D. Meier's Blog

    Web Application Security Frame


    The Web Application Security Frame is a set of categories you can use to scope security and improve your effectiveness.  It consists of the following categories:

    • Auditing and Logging
    • Authentication
    • Authorization
    • Configuration Management
    • Cryptography
    • Exception Management
    • Input and Data Validation
    • Sensitive Data
    • Session Management

    We created these categories during Improving Web Application Security to represent two things:
    1.  Where are the most common mistakes made
    2.  Where are the most actionable improvements

    How do you use these to be more effective?  You use these categories to focus and prioritize your security work.  For example, if you know the most prevalent security issues occur in the input validation, authentication and authorization categories, you can start there.

    You can immediately put the Web Application Security Frame into action.  when you perform Security Design Inspections or Security Code Inspections you can use the frame to walk categories of common security issues.  To do so, see the following:

    For more information on the Web Application Security Frame, see Cheat Sheet: Web Application Security Frame.

  • J.D. Meier's Blog

    Domain Specific Categories


    As a software engineer, how do you cope with information overload?  I suggest domain specific categories.  If the basic idea of domain specific languages (DSL) is a software language targeted at a specific area of problems, then domain specific categories (DSC) are an idea to create categories specific to an area of problems.

    Here's some practical usage for the categories:

    • Organize sets of recommendations
    • Organize sets of principles, practices, patterns and anti-patterns
    • Organize sets of questions for more effective design inspections, code inspections, and deployment inspections
    • Improve communication and information sharing across teams and orgs by using the categories
    • Prioritize categories for effectiveness
    • Chunk up or partition work effectively

    Here's practical examples illustrating domain specific categories:

    In the examples above, notice how the headings are carefully chosen categories.  Each category that organizes recommendations is evaluated against both the problem space, such as security or performance, the application type, such as Web application, and then the specific technology at hand. 

    Also notice how the baseline categories in the Web Application Security Frame become more specific and relevant in two ways:

    1. Information within each category is more specific (e.g. general Web Application input validation vs. input validation in ASP.NET)
    2. Categories are added or modifed based on the domain (e.g. ASP.NET has specific categories beyond than Web Application baseline set) 

    Are there down-sides to not using a one set of categories fits all approach?  You bet ... but based on the results I've seen from practitioners, I'd bank on using more thoughtful and empirical categories that are tested against how actionable and relevant they are.

Page 44 of 45 (1,108 items) «4142434445