One of the best ways for making sense of a space is to have a lens for looking at it.  The productivity and results space are well-traversed and the body of knowledge is enormous.  That’s part of the problem.  Without an effective lens, it can be difficult to find, organize, and share the productivity strategies, tactics, etc.

Knowledge Areas
You can think of a “frame” or a “lens” as a set of knowledge areas that make it easier to learn a space.  Together, the knowledge areas form a constellation of knowledge.  For example, the PMBOK (Project Management Body of Knowledge) and SWEBOK (Software Engineering Body of Knowledge) use knowledge areas to cluster related topics, concepts, tasks, and terms to help share the information more effectively.  It’s a way to frame out the space.

Productivity Body of Knowledge
While working on Getting Results the Agile Way, one of the first things I needed to do was carve out the space into meaningful buckets.   By “framing out” the results and productivity space, I created a more effective lens to look at productivity.   This is how I created a “Productivity Body of Knowledge".   I named the collection of knowledge areas for productivity and results, the Results Frame.  Giving it a name and putting it into a simple table, made it easier to refer to and to share as a mental model with others.

The Results Frame (Productivity Knowledge Areas) 
Here is the Results Frame:

Hot Spot Description Action How you take action and manage your activities towards results. Efficiency and Effectiveness How you manage the cost and speed of your results, as well as how you manage the quality of your results. Energy Management How you manage your energy in terms of thinking, feeling, and doing, as well as how you take care of your eating, sleeping, and working out. Expectations How you set and reset expectations with yourself and others. Focus How you focus your time, energy, and attention. Goals and Objectives How you set meaningful goals and objectives for your results. Information Management How you organize and manage information, as well as avoid information overload. Learning How you find the lessons, improve, and correct course. Mindsets and Motivation How you get your head in the game. Planning How you map out the work to be done. Pioritizing How you choose what’s more important. Self-Awareness How to improve your knowledge about yourself in terms of achieving results. Self-Discipline How you correct your behavior. Task Management How you manage your tasks and action items. Time Management How you manage and schedule your time.

The key with these knowledge areas is that they are can contain insight and action.  They are great containers or buckets for productivity principles, patterns, and practices.  To create the buckets, I first gathered up all the “rocks” (the individual principles, patterns, practices, terms, concepts, etc.) , then I group the collections, and then I labeled the buckets.  This is the opposite of making up buckets and then looking to fill them.  I was more interested in creating buckets for proven practices and applied knowledge, rather than treating productivity as an abstract or academic exercise.

Not only did the Results Frame help with organizing my own body of knowledge for results and productivity, but it made it incredibly simple for me to very quickly parse just about any body of knowledge or significant work in the productivity space.  This frame also helped me quickly pressure test productivity systems against a more holistic view, as well as to find their more specific strengths and weaknesses.  Interestingly, you can also use the categories to help evaluate project management approaches and software development approaches.  The frame is useful whether you use it to organize your own knowledge base on productivity, or you use it for teams, or organization.  Don’t just take my word for it though … test drive it and you decide what works for you … you’re the ultimate expert on your context and scenario.

These are some of the best ways I’ve found to master time management, get great results, improve your productivity, and amplify your impact:

1. Monthly Improvement Sprints. Use Monthly improvement sprints to cycle through things that you want to focus on. For example, focus on getting in shape in January; use February to learn a new skill. By using a month’s chunk of time, you give yourself enough of a timebox to achieve meaningful results. By using monthly themes, you give yourself a chance to cycle through a variety of your key interests and goals.
2. Balance your time across your Hot Spots. Balance your results across your meaningful buckets. For me, I use a life frame: mind, body, emotion, career, financial, relationships and fun. Each Hot Spot can be broken down into more Hot Spots. For example, my career bucket includes execution, thinking, administration, improvement and relationships.
3. Build a library of reference examples. Collect working examples to learn and model from. Actively looking for the positive examples of successful people around you helps keep your mind focused on success patterns. If you want to manage your time better, model from somebody who is effective. If you want to mange projects better, find somebody with a proven track record and learn from them. Keep in mind that what works for them, may not work for you, but there is no need to start from scratch.
4. Diversify your results. Think in terms of a portfolio of results. This means both producing results in different categories (such as relationships, career, and fun) as well as having some results you count on and some that are risks. Balance this with quitting when you aren’t going to get good at something, or you aren’t getting the return on investment. Diversify your results to avoid having all your eggs in one basket. For example, at work, you might have your flagship project that you can count on, but then add a couple of experimental projects to test the waters.
5. Establish a rhythm of results. Don't let the tail wag the dog. Factor when you create from when you release. This frees you up to focus on creation, without the immediate burden of production or release. Your release rate should match absorption rate and demand. Your production and release can occur at different times and at varying rates. For instance, you could write your eight blog posts on Sunday, then trickle them out over the week.
6. Find a way to flow value. Chunk your results down. Deliver incremental value to yourself or to others. Focus on value-delivered, not backlog burndown. Don't settle for being productive but ineffective. Focus on delivering value keeps you asking the right questions and making the right calls on priorities. Remember that backlogs tend to suffer from rot over time. If you focus on value delivered you won't miss windows of opportunity when they do appear. The other secret here is that focusing on value can be more energizing than tackling an overwhelming backlog, even if all you really changed is perspective.
7. Improve your network. Who you spend time with probably has the largest impact on getting results, personal growth, your quality of life, your career, etc. Here’s a tip: build a mind map of your personal and professional networks and see where you need to tune, prune, or grow. Your purpose is your guide, whether it’s seeing others’ perspectives to keep creative juices flowing, connecting with others you can model and learn from, or simply providing you with the support you need.
8. Make it a project. If you want to get something significant done, make it a project. This includes anything that takes several stages to complete or something that you know probably won’t get done otherwise. List the work to be done and estimate how long it will take.Allocate enough time, energy, and resources to accomplish the work and establish a timeline. Dedicate time to your project and see it through. It’s a simple but proven practice for achieving results. By giving something a start and an end, and by getting your head around the work, you dramatically improve your chances for success. By packaging up the work as a project, you can also look at it in terms of investment and ROI (return on investment). If you don’t think it will be worth the investment, you can make that call. Making it a project provides a lens you can both evaluate the opportunity and manage the work more effectively.
9. Stay flexible in your approach. Be flexible in the "how." If you have a compelling "what" and "why," you'll find the strategies. If something's not working, change your approach. A good sanity check is to ask yourself, "Is it effective?”
10. Sweeping. Periodically sweep up the mess you’ve left behind. Sometimes it’s easier to go back and clean things up than to try and get things right up front. It can be more efficient to batch and focus your time at a later point, than to try and keep things in order the whole time through. Consider sweeping as a deliberate strategy to maximize your energy by batching the work at a specific point in time. Sweeping as a practice gives you a chance to go back and improve things as well as integrate new learnings.

For more patterns and practices for improving results, see my book, Getting Results the Agile Way.

patterns & practices Parallel Programming with Microsoft .NET is now available.  The book shows design patterns to help developers use the .NET 4 Task Parallel Library (TPL) to write parallel applications successfully.

Contents at a Glance

• Authors and Disclaimers
• Foreword
• Preface
• Acknowledgments
• Introduction
• Parallel Loops
• Parallel Tasks
• Parallel Aggregation
• Futures
• Dynamic Task Parallelism
• Pipelines
• Appendix A: Adapting Object-Oriented Patterns
• Appendix B: Debugging and Profiling Parallel Applications
• Appendix C: Technology Overview
• Glossary
• References

The Patterns
The book describes six key parallel patterns for data and task parallelism and how to implement them using the TPL.

The Book

• Free in HTML -  Parallel Programming with .NET (MSDN)
• Print / EBook -  Parallel Programming with .NET (O’Reilly)

The Code Samples

• Parallel Programming Code Samples (CodePlex)

The Talk

• Patterns of Parallel Programming (TechEd)

The Community

• Parallel Programming with .NET Community KB (CodePlex)

This is a behind the scenes look at my involvement in the creation of the MSDN Hub pages. 

The MSDN Hub pages you get to from the main “buttons” on the MSN home (pictured above.)   Specifically, these are the actual pages:

• Cloud Hub
• Desktop Hub
• Phone Hub
• Web Hub

The intent of the MSDN Hub pages to create some simple starting points for some of our stories on the Microsoft developer platform.  For example, you might want to learn the Microsoft cloud story, but you might not know the “building blocks” that make up the story (Windows Azure, SQL Azure, and Windows Azure platform AppFabric.)    A Hub page would be a way to share a simple overview of the story, a way to get started with the technology, common application paths and roadmaps, and where to go for more (usually the specific Developer Centers that would be a drill down for a specific technology.)

Why Was I Involved?
If you’re used to seeing me produce Microsoft Blue Books for patterns & practices, and focusing on architecture and design, security, and performance, it might seem odd that I was part of the team to create the MSDN Hub pages.   Actually, it makes perfect sense, and here’s why -- They needed somebody who had looked across the platform and technology stacks and could help put the story together.  Additionally:

• The purpose of the MSDN Hubs was to tell our platform story and put the platform leggos together in a meaningful way.  This is a theme I’ve had lots of practice with over the years on each of my patterns & practices projects.
• I was already working on the Windows Developer Center and the Windows IA (Information Architecture), and the .NET IA, so I was part of the right v-teams and regularly interacting with the key people making this happen.
• I shipped our platform playbook for the Microsoft Platform – the patterns & practices Application Architecture Guide, second edition.
• I had put together a map of our Microsoft application platform story, as well as created maps, matrixes, and drill downs on our stories for key clusters of our Microsoft technologies including the presentation technology stack, the data access technology stack, the workflow technology stack, and the integration technology stack, etc. 
• I had previously worked on specific projects to create a catalog to organize and share the patterns & practices catalog of assets. (Internally we called this the “the Catalog Project”.) 
• I had worked on an extensive catalog of app types, which served as the backbone for some downstream patterns & practices projects while influencing others, including factories, early attempts at MSF “app templates”,  our patterns & practices catalog (so we could  enable browsing our catalog by application type), and then of course, the Microsoft Application Architecture Guide.
• I teamed across product teams, support, field, industry experts, and customers to create a canonical set of app types for the App Arch Guide.  Here’s what Grady Booch, IBM tech fellow, had to say about the App Types work -- “an interesting language for describing a large class of applications.”  Naturally, this work fed into the MSDN Hub pages since we need to map out the most common application patterns, paths, and combos. 

My Approach
My approach was pretty simple.  I worked closely with a variety of team members including Kerby Kuykendall, Howard Wooten, Chris Dahl, John Boylan, Cyra Richardson, Pete M Brown, and Tim Teebken.  I started off working mostly with Kerby, but eventually I ended up working closest with Tim because he became my main point of contact for influencing and shaping the work.  That said, it was still a lot of mock ups, ad-hoc meetings, whiteboard discussions, and group meetings to shape the overall result.  Tim did a stellar job of integrating my feedback and recommendations, as well as sanity checking group decisions with me.

I also sanity checked things with customers, and I worked closely with folks on the Microsoft Developer Platform Evangelism team including Tim Sneath and Jaime Rodriguez.  They were passionate about having a way to tell our platform story, show common app pathy, and how to put our leggos together, and make technology choices.  I tried to surface this in the design and information model for the Hub pages.

The Hubs
For the Hubs, at one of our early meeting in November of 2009, I recommended a we use “deployment targets” as a way to help slice things up and keep it simple.  Specifically:

• Cloud
• Desktop
• Games
• Mobile
• Server
• Web

As you can see, it maps very well to the App Types set I created circa 2004, but I evolved it to account for a few things.  First, I included learnings from working on the App Arch guide (such as moving away from Rich Client to just “desktop.”) Second,  I tried to pin it more directly to physical deployment targets to keep it simple.  As a developer, you can write apps to target the Web (a “Web” browser app), a desktop (such as a Windows client, or Silverlight, or WPF, etc.), a game (game console), etc.   Third, I aligned with marketing efforts, such as recommending we use the “deployment target” metaphor and I renamed the “Mobile” bucket to “Phone” (which worked, because it extended the “deployment target” metaphor, was still easy to follow, and kept things simple.

I also kept the physical aspect of the “deployment target” metaphor loose.   For example, “Web” could run on server, or “desktop”, etc.  Instead, I wanted to bubble up interesting intersections of application types plus common deployment targets, and keep it simple.

The Server Hub
For the server hub, I recommended addressing our story from a few lenses.  First, we have server-side products that can be extended, such as SharePoint, Exchange, SQL Server, etc.  That lens is pretty straightforward.  Second, I recommended focusing on “Service.”  Here’s where it’s hard for folks to follow if they aren’t familiar with server-side development.  While you can lump “service” under “Cloud” (as a cloud developer, I can write a Web app, a service, etc.), the “service” story is a very special one.  It’s the evolution of our “middleware developers” and our “server-side developers.”  It’s the path that the COM builders and server-side component builders shifted to … a more message-based architecture over an object-based one, as well as a shift to replacing DCOM with HTTP.

So if we had a Server Hub, it realistically should address building on our server-side products/technologies (SharePoint, Exchange, SQL Server, AppFabric, etc.) and it should address “Services.”  Sure you could also lump SharePoint under Web or Services under Cloud, but you can also bubble up and give focus to some of the fundamental parts of our Microsoft application developer platform.

To be fair, a lot of folks moved around during the MSDN Hub page project, and as new folks came on board, the history, insights, and some of the work may have gotten lost.

How To Solve the Issue of Too Many Hubs
This was my suggestion for dealing with too many Hubs:

“I think one thing that helps to keep in mind is that different people will want different views – but I think it’s simpler to choose the most useful one across the broadest set of scenarios.   That’s why Burger King and McDonald’s have a quick simple visual menu of the most common options … then you can drill in for more with their detailed menu if needed.  I like that metaphor because it addresses the “simple” + “complete”  Platform is a pretty solid bet – with an orientation around “tribes” (I’ll walk you through when we sync live) – after all, we do competitive assessments against platforms and that’s where we need to win.”

I also made a few additional recommendations to deal with the problem of “simple” + “complete”:

1. Add an “Office/SharePoint”, and a “Server” (SQL Server, Windows Server, Exchange) – the Office/SharePoint platform tends to have a tribe of customers that speak the same language and share the same context … different than your everyday .NET dev.   It’s like BizTalk in that it’s a specialized space.
2. Use a carousel approach to feature the main 4, then a “view more…” pattern so show the full 6 or so top level – and leave breathing room.  I would go to a page that shows the full set at the top, but then shows the full set of products against a durable backdrop.  This would address the “AND” solution of both “Simple” and “Complete”

This would provide a “durable” + “expandable” … AND… “simple” + “complete” … and in the end, a “platform guidance” approach.

While I’m not a graphic artist, I had done some mockups to help illustrate the point …

Home with “View More >>”

View More … (full dev center against a durable backdrop, full tech stack, Roadmaps)

This is blowing up a section of the “Microsoft Developer Products and Technologies” map above that I had created to illustrate the point:

… etc.  and the map of course, continued with the technology stack, but used a robust backdrop.  The map would need to be vetted across product teams but that’s just the point … have a common map that shows our “catalog” of technologies that customers could easily browse, and that product teams stand behind, while providing simple jump points to either MSDN Developer Centers or Product Team sites.

The Information Model for the Hub Pages
I tried to be inclusive in the information model and I wanted to address and integrate customer pain points I’ve heard about how we tell our story over the years, as well as keep the pages simple and useful, based on what I know about customer usage patterns.   These are the main sections I recommended:

• Key Technologies
• Overview
• Common Paths
• Download and Install
• Build Your First Apps
• Arch / Design
• Roadmaps
• Developer Centers and Home Pages

A picture is worth a 1000 words (note this is a picture of the “Information Model” – NOT the page mockups):

My key customer scenarios and questions I used for test cases were:

1. Can I quickly make sense of the particular story? (cloud, web, etc.)
2. Can I figure out what technologies are relevant?
3. Can I figure out how to choose which technology combination to use?
4. Can I quickly install whatever I need to get up and running?
5. Can I build a quick Hello World app to get my feet wet and some quick confidence?
6. Can I figure out the roadmap for the technology or technologies?
7. Can I get a quick sense of the most common application patterns, app types, and design patterns?
8. Can I figure out my key architecture and design issues if necessary?
9. Can I figure out where to go for more? (which Dev Centers, which landing pages, which resources, etc.)

My key recommendations included:

• Provide  the most common application paths for the given stories (based on the App Arch guide and DPE feedback.)
• Start with text-based articles and if feasible, add video.
• If we have video overviews, then have the PG teams create them so that they stand behind them and connect with customers
• Keep the areas repeatable across the Hub pages
• For a metaphor, think of the Hubs as the centralizing story for our “building blocks” … and think of our building blocks as the technologies and the “Developer Centers”
• Name the articles “How To –“ and make them actionable and step-by-step
• Name the videos “Explained” if they explain a concept and “How To” if they provide a set of steps.
• Eventually create “Getting Started Guides” for each of the Hubs.

Tim Teebken and I had many late night discussions and drill-downs, which made the work interesting and exciting.  It’s always great to work with smart people.  We pushed each other, challenged each other, and ultimately we stayed on the same page on the journey.

Well, that’s the story in a nutshell.   That’s a behind the scenes look at the making of The Design of the MSDN Hubs and the role that I played.

If you have feedback on the information model, please feel fee to send my way.  You can use the contact form on my blog.

David Zinger has shared his take on Getting Results the Agile Way in a review on his blog at http://www.davidzinger.com.  You can check out David’s review of Getting Results the Agile Way at:

•  Employee Engagement and Getting Results the Agile Way

If you don’t know David, he’s a writer, educator, speaker, consultant, and all around good guy, that lives and breathes employee engagement, which is all about how individuals, teams, and leaders can be more engaged in the work that they do.   His passion and super skill is helping people get more out of their work, and unleash their passion on the job.

You can see David in action at The Employee Engagement Network and you can check out his amazingly concise and insightful book, Zengage.  In a nutshell, Zengage is a short powerful book to help you get more out of your work by getting more into your work.

Today was the final day of 30 Days of Getting Results, based on my book Getting Results the Agile Way.

It’s basically free training on many of the key skills for:

• Making meaning / Finding purpose
• Focus
• Productivity
• Time Management
• Energy Management

It’s the synthesis of what I’ve learned at Microsoft in the trenches and my travels in life, as well as from many very good mentors.  Mostly, it’s what I’ve learned from the school of hard knocks, trial and error, and necessity (I think of it as a collection of Microsoft Survival Skills in a box.)

Agile Results
Agile Results is a personal results system for work and life.  It’s a simple system for meaningful results that you can apply whenever you need it.  It’s a way to help you make the most of what you’ve got.  It’s a way to be the author of your life, and write your story forward.

Problems Addressed

• How to improve your personal productivity and personal effectiveness
• How to achieve work-life balance
• How to find your motivation and drive
• How to find your purpose and your passion
• How to deal with being overloaded or overwhelmed
• How to change a habit and make it stick
• How to focus and direct your attention with skill
• How to manage your time
• How to spend more time on the things that really matter to you
• How to play to your strengths and spend less time in weaknesses
• How to make the most of your your moments, days, weeks, months, and years

It’s been a fun ride and I’ve heard some amazing stories from people around the world.  I’ve enjoyed the emails and stories from people who have used the system to enhance their life, a day at a time, a story at a time.

30 Lessons on Getting Results the Agile Way

• Day 1 – Take a Tour of Getting Results the Agile Way
• Day 2 – Monday Vision – Use Three Stories to Drive Your Week
• Day 3 – Daily Outcomes – Use Three Stories to Drive Your Day
• Day 4 – Let Things Slough Off
• Day 5 – Hot Spots – Map Out What’s Important
• Day 6 – Friday Reflection – Identify Three Things Going Well and Three Things to Improve
• Day 7 – Setup Boundaries and Buffers
• Day 8 – Dump Your Brain to Free Your Mind
• Day 9 – Prioritize Your Day with MUST, SHOULD, and COULD
• Day 10 – Feel Strong All Week Long
• Day 11 – Reduce Friction and Create Glide Paths for Your Day
• Day 12 – Productivity Personas – Are You are a Starter or a Finisher?
• Day 13 – Triage Your Action Items with Skill
• Day 14 – Carve Out Time for What’s Important
• Day 15 – Achieve a Peaceful Calm State of Mind
• Day 16 – Use Metaphors to Find Your Motivation
• Day 17 – Add Power Hours to Your Week
• Day 18 – Add Creative Hours to Your Week
• Day 19 — Who are You Doing it For?
• Day 20 — Ask Better Questions, Get Better Results
• Day 21 – Carry the Good Forward, Let the Rest Go
• Day 22 – Design Your Day with Skill
• Day 23 — Design Your Week with Skill
• Day 24 – Bounce Back with Skill
• Day 25 – Fix Time. Flex Scope
• Day 26 – Solve Problems with Skill
• Day 27 – Do Something Great
• Day 28 – Find Your One Thing
• Day 29 – Find Your Arena for Your Best Results
• Day 30 – Take Agile Results to the Next Level

Key Links

• 30 Days of Getting Results (All 30 self-paced lessons and nuggets)
• The Book – Getting Results the Agile Way
• Getting Started with Agile Results

If you visit just one lesson, check out Day 27 – Do Something Great.   If you check out two, check out Day 10 – Feel Strong All Week Long.

I've been sharing this lens with some of the people I mentor and they've been finding it helpful.  It's a simple lens for looking at the organizational culture you’re in and helping make sense of what you see:

• Results - This is a focus on results (what, why, outcomes, measures/metrics, tests for success, scorecards, etc.)
• Social - This is a focus on the people (It's who knows who, friends, enemies, politics, and agendas, etc.)
• Process - This is a focus on the process of things (how, charters, roles, policies, procedures, etc.)

You can usually get a sense for what an organization values by looking to the writing on the wall.  The key word here is “valued.”  You need to know what’s valued so that you can tailor your behavior and expectations for the context.  It helps you more effectively adapt your behavior, adjust the situation, or avoid situations with skill.

The ideal scenario is a balance of the results + social + process.   In my experience, I’ve found that usually an organization tends to be out of balance – they lean more towards one end than another.   Here are some of the symptoms you see when an organization is skewed toward one end:

• Too much “Results” focus -- leaves too many wakes and a trail of bodies
• Too much “Social” focus -- turns into the “old-boys club”, “mafia management”, favors, and back-door deals.
• Too much “Process” focus -- comes at the expense of good people, death by 1000 paper cuts.

When you know the context of the org you are in, you know what counts and what does not.  This helps you reshape your expectations and your behavior accordingly which leads to your success.

I’ve been coaching individuals, teams, and leaders on getting results.  Basically, for several years I’ve tested and applied various patterns and practices for improving focus, improving motivation, improving time management, and improving personal productivity.  I’ve also applied these practices to distributed team settings for several years (I’ve lead distributed teams since 2001, working with Argentina, UK, India, etc.).  The system itself is a combination and synthesis of proven practices learned from project management, software management, positive psychology, and sports psychology.  It’s also battle tested in some of the most extreme scenarios.  It’s ultimately a simple system for meaningful results that scales up and down, from individuals to teams and leaders.

At the heat of the system is a story-driven approach or a “3x3” approach:

By using three stories to drive your day, your week, your month, and your year … you identify your most important results, you connect to your values, and you flow value on a regular basis.

I’ve wrapped up and shared this getting results system as a guide.  The book is called Getting Results the Agile Way and you can read the testimonials which includes people inside and outside of Microsoft (it’s generalized to work beyond the Microsoft context.)  It’s one of my most important contributions back to the community … distilling all the of the best of the best of what I’ve learned about getting results from my various mentors, my multiple projects over many years, and from the school of hard knocks.  It’s the playbook I wish somebody gave me when I started.

For this month, I’ve been doing a Monthly Improvement Sprint to help teach you the system and to learn how to improve personal productivity, improve energy, and improve time management.  Basically, I want you to get the system on your side.  Monthly Improvement Sprints are one of the core practices from the system, so I’m effectively, using the system to  teach the system.  Each day, I share another nugget in the form of a post on my personal effectiveness blog.  Each nugget is self-contained so you can pick up from anywhere. 

Here is a description of the project:

• 30 Days of Getting Results

Here are the daily lessons so far on improving personal productivity, time management, focus, and prioritization:

• Day 1 – Take a Tour of Getting Results the Agile Way
• Day 2 – Monday Vision – Use Three Stories to Drive Your Week
• Day 3 – Daily Outcomes – Use Three Stories to Drive Your Day
• Day 4 – Let Things Slough Off
• Day 5 – Hot Spots – Map Out What’s Important
• Day 6 – Friday Reflection – Identify Three Things Going Well and Three Things to Improve
• Day 7 – Setup Boundaries and Buffers
• Day 8 – Dump Your Brain to Free Your Mind
• Day 9 – Prioritize Your Day with MUST, SHOULD, and COULD
• Day 10 – Feel Strong All Week Long
• Day 11 – Reduce Friction and Create Glide Paths for Your Day
• Day 12 – Productivity Personas – Are You are a Starter or a Finisher?
• Day 13 – Triage Your Action Items with Skill
• Day 14 – Carve Out Time for What’s Important
• Day 15 – Achieve a Peaceful Calm State of Mind

Join anytime and pick up from wherever you are.  The most important theme is this:

Be the author of your life and write your story forward … a day at a time, and a moment at a time.

Heuristic evaluation is one of the most common types of expert reviews for Web sites.  It was developed by Jakob Nielsen.  In the book, The Design of Sites, by Douglas K. Van Duyne, James A. Landay, Jason I. Hong, the authors explain heuristic evaluations.

What Is a Heuristic Evaluation
Van Duyne, Landay, and Hong write:

“The basic idea is to have three to five expert judges independently evaluate a site, using a list of usability heuristics or principles.“

How To Perform a Heuristic Evaluation
Van Duyne, Landay, and Hong write:

“In a heuristic evaluation, the judges go through the site, often with a set of sample tasks as a guide, looking for violations of the heuristics.  They note each violation and make a suggestion for fixing it. ... The judges also rate each violation with a level of severity.  Severity levels are usually assessed on the basis of the expected customer impact and frequency of the violation.”

7 Design Principles / Heuristics (The Design of Sites)

1. Be consistent throughout.
2. Offer informative feedback.
3. Rely on recognition over recall.
4. Help customers prevent and recover from errors.
5. Support customer control and freedom.
6. Help frequent customers use accelerators.
7. Strive for aesthetic and minimalist design.

10 Usability Heuristics (Jakob Nielson)

1. Visibility of system status.
2. Match between system and the real world.
3. Use control and freedom.
4. Consistency and standards.
5. Error prevention.
6. Recognition rather than recall.
7. Flexibility and efficiency of use.
8. Aesthetic and minimalist design.
9. Help users recognize, diagnose, and recover from errors.
10. Help and documentation.

For an explanation of Jakob Nielson’s 10 usability heuristics, see Ten Usability Heuristics.

When it comes to prototyping Web site design, paper prototypes tend to have an advantage.  In the book, The Design of Sites, by Douglas K. Van Duyne, James A. Landay, Jason I. Hong, the authors explain some of the advantages.

Iterate and Explore the Design with Paper Prototypes
Van Duyne, Landay, and Hong write:

"Research shows that designers who work out conceptual ideas on paper tend to iterate more and explore the design space more broadly  whereas designers using computer-based tools tend to take only one idea and work it out in detail."

Low-Fidelity Prototypes Over High-Fidelity Prototypes
Van Duyne, Landay, and Hong write:

“Nearly every one of the designers we have talked to has observed that the discussions is qualitatively different when people are presented with a high-fidelity prototype.  Clients often respond with comments like, 'I do not like your color scheme,' or 'These two buttons need to be aligned correctly.'  When presented with a low-fidelity prototype, however, clients are more like to say something like, 'These labels on the navigation bar do not make sense to me,' or 'You're missing a link to the shopping care here on this page.'  In other words, with low-fidelity prototypes, which lack irrelevant details like color, font, and alignment to distract the eye, people focus on the interaction and on the overall site structure. “

However, it's worth noting that software that emulates paper prototyping can be very helpful.  One example is Balsamic Mockups.

When you’re prototyping sites in the early stage, the three main artifacts are: sitemaps, storyboards, and schematics.  In the book, The Design of Sites, by Douglas K. Van Duyne, James A. Landay, and Jason I. Hong describe the three artifacts as follows:

• Sitemaps - a high-level diagram showing the overall structure of a site.  You use it to reflect an understanding of the information structure or architecture of the site as it's being built, and the navigation structure or flow through the entire site, at the macro level.
• Storyboards - a sequence of Web pages depicting how a customer would accomplish a given task.  You can use storyboards to show important interaction sequences or flows through  a site.
• Schematics - represent the layout of the content that will appear on individual pages.  They don't usually include images, instead they have placeholders and labels.

There’s often confusion over the distinction between information architecture, navigation design, and graphic design.  One of my favorite books that explains what these terms are and the distinctions is the book, The Design of Sites, by Douglas K. Van Duyne, James A. Landay, Jason I. Hong.

Van Duyne, Landay, and Hong define the terms as follows:

• Information Architecture - Identifying, structuring, and presenting groups of related content in a logical manner.
• Navigation Design - Designing methods so that customers can find their way around the information structure.
• Graphic Design - Developing the visual communication of information, using elements such as color, images, typography, and layout.

Note that information and navigation design are typically done before graphic design. 

Also note that the authors mention that there's often a debate in the design community about the boundaries between information architecture and information design.  They point out that information architecture focuses more on structure and language, while information design focuses on presentation and perception.  At the end of the day, the key point is that the two disciplines are about helping customers find, understand, and manage complex information.

It’s also worth knowing the terms “Information Model” and “Data Models” since they often come up in discussions regarding information architecture:

• Information Model -    A model of the concepts, relationships, constraints, rules, and operations for a given domain, and it can provide a sharable, stable, and organized structure of information requirements.  See Information Model (Wikipedia)
• Data Models – Describes how the data are represented and accessed and defines the data elements and relationships among data elements for a given domain.  See Data Model (Wikpedia)

So many Web sites fail at helping users complete tasks or find the information they need in a simple way.   E-Commerce sites like Amazon tend to do a better job than a lot of sites here because they have a tight feedback loop for customers completing their tasks.  Basically, they keep the score on their customer success against their goals.  If customers can’t find what they need, perform their transactions in a fast and simple way, easily give feedback, or provide useful reviews to the community at large, then Amazon fails and customers look for alternatives.  It’s a self-re-enforcing loop and Amazon does a lot of A/B testing to find the most effective way to improve customer success on their Web site.

The good news is  … Success leaves clues in the form of principles, patterns, and practices.

There’s really no reason for Web sites to fail at basic user experiences, given that so many problems are already solved.  Not only are the problems solved, but user experience solutions even have names in the form of patterns.  Better yet, you can check each pattern against live examples on the Web.   It’s effectively a living catalog of success.

Lessons Learned on Site Design
While working on one of my information architecture projects, I analyzed more than 350 Web sites, mostly in the consumer space, to learn interaction patterns, site design, and user experience patterns.  I apply these lessons to many of my CodePlex sites, Wikis, SharePoint sites, and blogs within the bounds of things that I control.   For example, on my personal effectiveness blog Sources of Insight, I regularly test site design principles, user experience, and interaction patterns.  The downside during all of my research is that I didn’t think to name all the patterns I learned.  Because I didn’t name the patterns, it’s difficult to share the lessons learned or to create a simple catalog of the cornerstone concepts.  All is not lost though …

User Experience Patterns for Effective Site Design
When you need to design effective user experiences for Web sites, you don’t have to start from scratch.  You can model from the success patterns of existing sites.  However, distilling all the successful principles, patterns, and practices can be a challenge.  One of my favorite guides that does the distillation for you is The Design of Sites.   It’s a comprehensive catalog of proven practices for designing effective Web sites in terms of customer-centered design, information architecture, interaction patterns, and task-completion.

Patterns Catalog from The Design of Sites
You can actually browse the full catalog of patterns from The Design of Sites book.  I like to be able to scan the patterns in alphabetic order by category, so I put them into a summary table to do so:

Category Patterns Homepage

• HOMEPAGE PORTAL
• UP-FRONT VALUE PROPOSITION

Site Genres

• BLOGS
• COMMUNITY CONFERENCE
• EDUCATIONAL FORUMS
• ENABLING INTRANETS
• GRASSROOTS INFORMATION SITES
• NEWS MOSAIC
• NONPROFITS AS NETWORKS OF HELP
• PERSONAL E-COMMERCE
• SELF-SERVICE GOVERNMENT
• STIMULATING ARTS & ENTERTAINMENT
• VALUABLE COMPANY SITES
• WEB APPS THAT WORK

Content

• CONTENT MODULES
• DISTINCITIVE HTML TITLES
• HEADLINES AND BLURBS
• INTERNATIONALIZED AND LOCALIZED CONTENT
• INVERTED-PYRAMID WRITING STYLE
• PAGE TEMPLATES
• PERSONALIZED CONTENT
• PRINTABLE PAGES
• STYLE SHEETS
• WRITING FOR SEARCH ENGINES

E-Commerce Basic

• CLEAN PRODUCT DETAILS
• EASY RETURNS
• ORDER CONFIRMATION AND THANK-YOU
• ORDER SUMMARY
• PAYMENT METHOD
• SHOPPING CART
• QUICK ADDRESS SELECTION
• QUICK-FLOW CHECKOUT
• QUICK SHIPPING METHOD SELECTION

Advanced

• CROSS-SELLING AND UP-SELLING
• FEATURED PRODUCTS
• GIFT GIVING
• MULTIPLE DESTINATIONS
• ORDER TRACKING AND HISTORY
• PERSONALIZED RECOMMENDATIONS
• RECOMMENDATION COMMUNITY

Mobile

• LOCATION-BASED SERVICES
• MOBILE INPUT CONTROLS
• MOBILE SCREEN SIZING

Navigation

• ALPHABETICAL ORGANIZATION
• BROWSABLE CONTENT
• CATEGORY PAGES
• CHRONOLOGICAL ORGANIZATION
• HIERARCHICAL ORGANIZATION
• MULTIPLE WAYS TO NAVIGATE
• POPULARITY-BASED ORGANIZATION
• SITE ACCESSIBILITY
• TASK-BASED ORGANIZATION

Navigation (Simplifying)

• ACTION BUTTONS
• DESCRIPTIVE, LONGER LINK NAMES
• EMBEDDED LINK
• EXTERNAL LINKS
• FAMILIAR LANGUAGE
• HIGH-VISIBILTIY ACTION BUTTONS
• JUMP MENUS
• LOCATION BREAD CRUMBS
• MEANINGFUL ERROR MESSAGES
• OBVIOUS LINKS
• PAGE NOT FOUND
• PERMALINKS
• PREVENTING ERRORS
• UNIFIED BROWSING HIERARCHY
• NAVIGATION BAR
• SITE MAP
• TAB ROWS

Page Layouts

• ABOVE THE FOLD
• CLEAR FIRST READS
• CONSISTENT SIDEBARS OF RELATED CONTENT
• GRID LAYOUT
• EXPANDING SCREEN WIDTH
• FIXED SCREEN WIDTH

Performance

• FAST LOADING CONTENT
• FAST-LOADING IMAGES
• HTML POWER
• LOW NUMBER OF FILES
• REUSABLE IMAGES
• SEPARATE TABLES

Search Relevancy and Speed

• ORGANIZED SEARCH RESULTS
• SEARCH ACTION MODULE
• STRAIGHTFOWARD SEARCH FORMS

Task Completion

• ACCOUNT MANAGMENT
• CLEAR FORMS
• CONTEXT-SENSITIVE HELP
• DIRECT MANIPULATION
• DRILL-DOWN OPTIONS
• FLOATING WINDOWS
• FREQUENTLY ASKED QUESTIONS
• GUEST ACCOUNT
• PERSISTENT CUSTOMER SESSIONS
• PREDICTIVE INPUT
• PROCESS FUNNEL
• PROGRESS BAR
• SIGN IN/NEW ACCOUNT

Trust and Credibility

• ABOUT US
• E-MAIL NOTIFICATIONS
• E-MAIL SUBSCRIPTIONS
• FAIR INFORMATION PRACTICES
• PRIVACY POLICY
• PRIVACY PREFERENCES
• PREVENTING PHISHING SCAMS
• SECURE CONNECTIONS
• SITE BRANDING

Not only are the names intuitive but when you use the book, you can drill into each pattern for concrete examples, as well as the design philosophy behind it.

Windows Azure Security Notes (PDF) is a collection of our notes and learnings from exploring the cloud security space and working through Windows Azure security scenarios.   Note that this is not a guide and it’s not a Microsoft patterns & practices deliverable.  It’s simply a way to package up, hand-off, and share what we learned during the exploration stage of our patterns & practices Windows Azure Security Guidance project.

The key things you’ll want to explore in the notes are the various application scenarios, the cloud security threats and countermeasures, and the checklist.

Download

• Download Windows Azure Security Notes (PDF)

Contents at a Glance
Here is a quick look at the Windows Azure Security Notes:

• Ch 1 - Our Cloud Security Approach
• Ch 2 - Cloud Security Threats and Countermeasures
• Ch 3 - Design Guidelines for Improving Cloud Security
• Ch 4 - Choosing Web Application Security Architectures
• Ch 5 - Web App Security Scenarios
• Ch 6 - Choosing Web Services Security Architectures
• Ch 7 - Web Services Security Scenarios
• Ch 8 - Choosing Data Security Architectures
• Ch 9 - Data Security Scenarios

Reference

• Security Checklist for Cloud Applications
• Visual Threats for Web Applications
• Visual Threats for Web Services
• Cheat Sheet - Web Application Security Threats and Countermeasures
• Cheat Sheet - Web Services (SOAP) Security Threats and Countermeasures
• Cheat Sheet - Web Services (REST) Security Threats and Countermeasures
• Cheat Sheet - Data Security Threats and Countermeasures
• How To - Use Forms Authentication with Azure Table Storage
• How To - Use Forms Authentication with SQL Azure
• How To - Enable SSL with a Self-Signed Certificate on Windows Azure

Acknowledgements
Many thanks to the following folks for sharing their time and expertise along the way:

• External contributors and reviewers: Adam Grocholski; Andy Eunson; Bill Collette; Christopher Seary; Jason Taylor; John Daniels; Juval Lowy; Kevin Lam; Long Le; Michael Smith; Michael Stiefel; Michele Leroux Bustamante; Norman Headlam; Rockford Lhotka; Rudolph Araujo; Sarang Kulkarni; Steven Nagy; Terrance Snyder; Will Clevenger
• Microsoft contributors and reviewers:  Akshay Aggarwal; Alik Levin; Andreas Fuchsberger; Babur Butter; Bharat Shyam; Dave Brankin; Danny Cohen; Diego Dagum; Don Willits; Eugenio Pace; Gabriel Morgan; Jeff Mueller; John Steer; Julian Gonzalez; Mark Curphey; Mohit Srivastava; Pat Filoteo; Rahul Verma; Raul Rojas; Scott Densmore; Sesha Mani; Serena Yeoh; Sriram Krishnan; Stefan Schackow; Steve Marx; Stuart Kwan; Terri Schmidt; Tobin Titus; Varun Sharma; Vidya Vrat Agarwal; Vikram Bhambri; Yale Li

While we’ve been thinking through content strategies and content experiences, one of the phrases I started using to quickly share an idea is “CRUD for Content.”   It’s modeled after CRUD operations for applications – CREATE, READ, UPDATE, DELETE.  It’s simple, but it quickly helps folks relate to the simple operations you can do with content as a user:

• Browse it
• Search it
• Save it
• Share it

Sure there are plenty of variations off of that, but it’s a helpful backdrop to start from when thinking through experiences for finding, searching, saving, and sharing content on MSDN.

At the end of the day, if I’m going to throw my time and energy at something, I want to know that it will make impact.  I also want to make sure that I’m on path, meaning it connects to my values and my purpose, and that I’m using proven practices to make things happen with skill. 

There is a lot of science and wisdom of the ages but it’s tough to pull everything we know about thinking, feeling, and taking action in the most effective way.  Add to that the challenge that we’re all different and we have to apply any principles, patterns, or practices to our specific scenario or context.

Getting Results the Agile Way is a way to pull it all together and get the system on your side.  It’s the system I’ve honed over years and it’s principle-based, which means you can tailor it very easily to yourself or the situation.

To make it easy to learn some of the key ideas, I created three short slide shows to share the three key parts of Agile Results:

• The Rule of Three Slide Show - The Rule of 3 is a simple concept.  Think in three’s.   The Rule of 3 helps us deal with information overload.  It’s a simple way to set limits and chunk things down.
• Hot Spots Slide Show - Hot spots are a simple metaphor for thinking about what’s important.  Imagine your life as a heat map with Hot Spots.  Hot Spots are the key investment areas or choice points that need your attention.  Hot Spots are a lens and each Hot Spot can represent pain or opportunity or pleasure.
• Monday Vision, Daily Outcomes, Friday Reflection Slide Show - Monday Vision, Daily Outcomes, and Friday Reflection is a simple pattern for weekly results.  It's a way to use stories to make your week more meaningful and spend more time achieving what you want.

For August, I’m putting a strong emphasis on sharpening and honing my execution skills – a tune up of the system.  As part of the process, I decided to make my August theme all about getting results.  You can follow along at 30 Days of Getting Results where each day I will share another nugget from the book of getting results.

"I love it when a plan comes together." -- Colonel John "Hannibal" Smith, The A-Team

Project plans are tough.  No matter how many times you do them – they are always tough.  I’ve been doing them for years, and yet the path from zero to a "good enough" plan is always a lot of work.  But it's worth it.  It's often what separates the failed projects from the successful ones.  When a project fails, you can usually find clues in the plan (or lack of.)

Regardless of how you get there or how you share the plan, the following are essential elements:

• Problem statement
• Customer / who’s it for
• Vision / strategy
• Goals
• Outcomes
• Deliverables
• Timeline
• Tests for success
• Measures / metrics
• Scenarios / stories
• Resource map
• Risks
• A map of the work (work breakdown structure)

In question form, some simple checks are:

• What are the most important outcomes?
• Do we know what good looks like?
• Who's doing what when?
• What's the minimum we need to accomplish or it's not worth it?

It's worth noting that projects often fail because

• Lack of clarity on the goal
• Lack of understanding the work (work breakdown structure)

Interestingly, I know of some executive reviews that boil down to two cutting questions:

• What's the investment?
• What are the results?

It helps answer the higher question -- “Why are we doing this and does it make business sense?”

"Don’t count the days, make the days count." - Muhammad Ali

If you've ever wanted to learn the key principles, patterns, and practices for getting results, now's the time.  I'm making August a focus on Getting Results the Agile Way.  It's a simple system for meaningful results.  It's been helping individuals, teams, and leaders improve their results and get on top of their game (see reviews and success stories.) 

Throughout August, I'll write a new post each day on Sources of Insight to help you adopt Agile Results, a nugget at a time, starting with 30 Days of Getting Results.  If you want to follow along, subscribe to the RSS feed for Sources of Insight.

Here are some of the key topics I'll be addressing:

• How to get "on path," make meaning, and find your purpose with skill
• How to be the author of your life and use three stories to drive your day, your week, your month, and your year
• How to deal with being overwhelmed and deal with information overload
• How to inspire yourself with skill, and find your motivation and drive
• How to bounce back with skill
• How to make more time for the right things and stop spending time on the wrong things
• How to break out of analysis paralysis
• How to create a rhythm of results that supports you in everything you do
• How to let things slough off, instead of adding the straw that breaks the camel's back
• How to achieve work-life balance while growing your capacity for results
• How to enjoy the journey AND the destination
• How to use your super skill to get more done in the same amount of time with less effort and better results
• How to spend more time in your strengths, and less time in your weaknesses
• How to use some simple practices from positive psychology for feeling good, finding happiness, and a peaceful calm
• How to add power hours to your week, a day at a time
• How to design your day with skill and set yourself up for success
• How to get a fresh start each day and each week to get a new chance for your best results

Agile Results is the system I talk about in the book, and it's a simple system for meaningful results.  You can think of it as a personal results system for work and life.  It's based on both studying success and applied research over a number of years, and it draws from a number of disciplines, including positive psychology, project management, software development, etc.

It's not about software development, but it is the same system I've used to mentor others, coach teams, and lead distributed teams for more than 10 years.  You can think of it as "Scrum for Life" or "Story-driven results" or "Lean for Life."   You can use the system to improve your mind, body, emotions, career, financial, relationships and fun.  It's ultimately about writing your story forward, driving from your "why", and leveraging proven practices for thinking, feeling, and taking action.

I know a number of people are going through significant changes in their life.  Having a system and science on your side, helps you stack the deck of success in your favor.

If you want to get started fast without reading the book, here is a One-Page Guide to Getting Started with Getting Results the Agile Way.

Several years back, I did an exercise in mapping out families of application architectures and application types.  It was an extensive archeological expedition.

Key Goals / Outcomes
There were several goals of the exercise:

• Identify canonical application architectures and app types
• Figure out a useful way of sharing architectures
• Figure out whether it's better to focus on the business architectures or the technical architectures
• Find a simple way to overlay patterns work on top of technical architectures
• Find a simple way to share architectural styles
• Find a way to simplify and share visuals of end-to-end architectures

The exercise fed into a number of later works years later, including:

• Re-shaping the patterns & practices catalog to be organized using app types -- and this literally drove our product-line more formally toward app types (a pre-cursor to the patterns & practices "factories" effort in 2005)
• Identifying a canonical set of application types for the Microsoft platform as part of the Application Architecture Guide.
• Shaping the path of the home/hub pages on MSDN toward "deployment targets" and application types

Key Activities
Some of the key activities of this early exercise included:

• Creating an exhaustive catalog of application types grouped and sliced in various ways
• Interviewing many of our best application architects in the trenches
• Sanity checking with many of our top architects at head quarters, including Rico Mariani, Pat Helland, and Jim Gray
• Reverse engineering many available sample applications inside and outside of Microsoft
• Checking with industry experts on their lessons learned about the types and the shapes of all the applications they've seen and built over the years
• Creating an extensive inventory of application patterns from various sets of our  key customers that had a wide range of applications and platforms
• Evaluating competitive efforts to index and catalog application shapes and types, and making sense of various patterns efforts

Keep in mind, that going into this, I already had the benefit of doing more than 650 customer architecture and design reviews -- yet still, this was an overwhelming exercise.  It forced me to find new ways to deal with large bodies of data and information, and somehow turn them into  shared maps, browsable, reusable knowledge nuggets, and backdrops for deeper conversations and elaboration.

Lessons Learned from Architectural Exploration
Some of the surprises for me or things that I learned that I didn't expect include:

• Focusing on business architectures and verticals was less effective and less reusable than focusing on technical architectures as a baseline (from there, we could overlay business architectures)
• Knowing the deployment patterns was the fastest way to get a good sense of the application patterns (it's where the logical met the physical against the infrastructure)
• Looking through quality attributes as a lens made it easy to find and explore patterns for security, performance, reliability, manageability, etc.
• So many applications boiled down to simple CRUD (Create Read Update and Delete)
• The biggest variation among applications was the business logic and workflow
• IBMs simple model of user, process, and data was useful as one lens
• Views and viewpoints were a powerful way to change perspective and drill into another aspect of applications
• At a high-level, you could capture a customer's core system by capturing the data, workflows, and workloads (the workloads significantly shaped the design of the app)

In retrospect, the simplicity and common denominators of CRUD make a lot of sense.  It's all about interacting with information at a fundamental level.  People are just trying to get things done and there's only so many things you can do with information -- find it, browse, save it, share it, transform it, etc. as part of your workflow.

Early Map of App Types
I included one of the many early maps of the application types that helped us figure out what to throw out and what to keep as we moved forward.   One of the key distinctions that Ward Cunningham helped me figure out was to distinguish between the shape of the application architecture and design, and the actual “purpose” of the application.  Some purposes were more business-oriented, while some were more technically oriented, and this helped me find and distinguish different families of apps.

It's circa 2004, but the irony is how timeless the backdrop really has been.  It’s rough and raw, but like I said, it’s just one sampling of the many braindumps behind the scenes of mapping out app types.

 

Category Items Base Archetypes

• Rich Client
• Web Client
• Web Service
• Mobile / Phone
• Video Game

• Framework
• Component/Library
• Subsystem
• Service

Pool of Stuff

• OLAP
• Data Mining
• Data Warehouses
• Data Management
• Business Process Integration
• Business Intelligence
• BAM

• Server-side
• Desktop
• Peer-to-peer
• Mobile
• Web-centric
• Data-centric
• Middle-tier

• Transactions
• Read-Only data
• Workflow
• Batch

• Portal
• Community
• Commerce
• Task-Tracking

Business Applications

• Accounting and Finance
• Customer Service
• Distribution and Warehousing
• Education and Training
• Engineering, Design and Drafting
• Facilities Management
• General Office Automation
• Groupware and Collaboration
• Human Resources
• Knowledge Management
• Legacy Systems Analysis and Upgrade
• Logistics and Procurement
• Manufacturing and Process Management
• Other Business Application Tools
• Project Management
• Reporting, Analysis and Decision Support
• Sales and Marketing

Accounting and Finance

• Account Activity Analysis
• Accounts Payable
• Accounts Receivable
• Billing and Invoicing
• Budgeting, Financial Planning and Analysis
• Consolidation Statements and Performance Reporting (CS-PR, Aggregation)
• Currency and Foreign Exchange Management
• Electronic Funds Transfer (EFT)
• Fixed Asset Management
• General Ledger
• Integrated Accounting Solutions
• Integrated Financial Management Solutions
• Inventory Accounting
• Investment and Portfolio Management
• Job Costing
• Payment, Clearing and Settlement Systems
• Payroll and Personnel Accounting
• Purchasing
• Quotation, Order Entry and Order Processing
• Risk Management
• Small Business Accounting
• Tax Preparation and Reporting
• Time and Billing

Customer Service

• Automatic Page-Voice Notification
• Call Center Management
• Customer Service
• Help Desk and Call Management
• Interactive Voice Response Systems
• On-line Customer Support
• Scheduling

Distribution and Warehousing

• Distribution and Warehousing (Integrated)
• Freight Dispatch
• Freight Handling
• Other Distribution and Warehousing Industry Sectors
• Route Scheduling
• Truck-Fleet Management
• Wholesale Distribution and Warehousing

Education and Training

• Computer-Based Training
• Courseware Development
• Web-Based Training

Engineering Design and Drafting

• Cartography-Mapping-Geographic Information Systems (GIS)
• Computer-Aided Design (CAD)
• Computer-Aided Manufacturing (CAM)
• Electronics Design Automation (EDA)
• Materials Analysis
• Mechanical Computer-Aided Design (MCAD)
• Mechanical Computer-Aided Engineering (MCAE)
• Mechanical Computer-Aided Manufacturing (MCAM)
• Modeling
• Sampling and Testing
• Structural Analysis

Facilities and Management

• Building Security
• Communications Management
• Computer Maintenance Management (CMMS)
• Energy Analysis and Management
• Enterprise Asset Management (EAM)
• Equipment Maintenance and Field Service
• Facilities Maintenance
• Facilities Management (Integrated)
• Heating, Ventilation and Air Conditioning (HVAC)
• Lighting Analysis and Control
• Other Facilities Management Industry Sectors

General Office Automation

• Appointment Management
• Calculators
• Calendaring & Scheduling
• Data Entry
• Desktop Management
• Desktop Publishing
• Electronic Mail
• Fax Management
• Flowcharting
• Graphics (Raster)
• Graphics (Vector)
• Mailing List Management
• Multimedia and Animation
• Office Suites (Integrated)
• Presentation Applications
• Spreadsheets
• Time Management
• Time and Expense Reporting
• Voice Recognition Software
• Web Browsers
• Word Processors

Groupware and Collaboration

• Chat and Discussion Systems
• Collaborative Writing Systems
• E-mail Clients
• Group Calendars
• Integrated Groupware Solutions
• Newsgroup Management
• Resource Scheduling
• Video Conferencing and IP-TV
• Workflow Automation

Human Resources

• Benefits Administration
• Employee Self-Service Software
• Human Resource Management
• Integrated Human Resources Utilities
• Personnel Administration
• Professional Services Administration
• Recruiting
• Resume Tracking
• Time & Attendance
• Travel Management

Knowledge Management

• Computer Output to Laser Disc (COLD)
• Document Imaging Systems
• Document Management Systems
• Idea Management
• Knowledge Base Management
• Workflow

Legacy Systems Analysis and Upgrade - Logistics and Procurement

• Import and Export Management
• Partnership Relationship Management
• Requisitioning and Procurement
• Supply Chain Management
• Transportation Management
• Warehouse Management Systems

Manufacturing and Process Management - Capacity Requirements Planning (CRP)

• Data Reduction
• Distribution Management
• Enterprise Resource Planning (ERP)
• Equipment Maintenance and Management
• Factory Automation and CIM
• Factory Data Collection
• Inventory Management
• Machine Tools
• Machine Vision
• Maintenance, Repair and Operating Supplies (MRO)
• Manufacturing Automation Protocol
• Manufacturing Execution Systems (MES)
• Manufacturing Simulation
• Manufacturing Solutions (Integrated)
• Material Requirements Planning (MRP)
• Materials Manufacturing
• Metrology
• Numerical Control (NC)
• Operations Planning
• Plant Maintenance and Service
• Process Control (HMI-SCADA)
• Product Information Management (PIM)
• Product Service
• Production Planning
• Production Scheduling
• Quality Control
• Reliability Modeling and Analysis
• Robotics
• Shop Floor Control
• Test Development
• Test Information Integration
• Test Simulation
• Work Load Control

Project Management

• Project Accounting
• Project Estimating
• Project Management (General)
• Project Scheduling
• Purchasing
• Resource Planning

Reporting, Analysis, and Decision Support

• Business Planning
• Business Process Reengineering
• Competitive Analysis
• Data Mining and OLAP
• Decision Support Systems
• End-User Query and Reporting
• Executive Information Systems
• Expert Systems
• Mapping and Visualization
• Multi-Dimensional Analysis
• Needs Analysis Systems
• Neural Networks
• Statistics and Technical Data Analysis
• Trend Analysis

Sales and Marketing

• Contact Management
• Customer Relationship Management
• Demographics
• Enterprise Marketing Automation
• Lead Distribution Management
• Market Research
• Marketing Management
• Media Planning and Buying
• Mobile Field Sales
• Partnership Management
• Product Configurators
• Sales Analysis & Reporting
• Sales Force Automation (SFA)
• Sales Management
• Telemarketing

Industries

• Aerospace & Defense
• Automotive
• Chemicals
• Communications
• Consumer Products
• Education & Research
• Energy
• Engineering & Construction
• Financial Services
• Healthcare
• High Technology
• Industrial Manufacturing
• Life Sciences
• Professional Services
• Public Sector
• Retail
• Travel & Transportation
• Utilities

Business

• Contact Management
• Customer Management
• Accounting

Data

• Datawarehouse
• Data mining
• OLAP

Desktop

• Photo Editing
• Graphic Design
• Web Publishing

Desktop Business Software

• Email Client
• Spreadsheet
• Presentations
• Word Processing

Home and Hobbies

• Cooking and Health
• Fashion
• Gardening and Landscape
• Genealogy
• Hobbies
• Home Design
• Home Publishing
• Instrument Instruction
• Legal
• Mapping
• Movies and Television
• Music Appreciation
• Personal Improvement
• Script and Screenwriting

Personal Finance

• Investment Tools
• Money Management
• Tax Preparation

Utilities

• Virus Protection
• PC Maintenance

A

• Batch
• BPM (business process management)
• BIM (business intelligence management)
• EAI (enterprise architecture integration)
• Document Management

B

• Operating System
• Framework
• Component/Library
• Service
• Subsystem

C

• Portal
• Community
• Commerce
• Task-Tracking

D

• Transactions
• Read-Only data
• Workflow
• Batch

E

• Server-side
• Desktop
• Peer-to-peer
• Mobile
• Web-centric
• Data-centric
• Middle-tier

F

• Content Management

G

• Web Server
• Application Server
• Database Server

H

• Collaboration Suite

I

• OLAP
• Data Mining
• Data Warehouses
• Data Management
• Business Process Integration
• Business Intelligence
• BAM

Cloud security has been a hot topic with the introduction of the Microsoft offering of the Windows Azure platform.  One of the quickest ways to get your head around security is to cut to the chase and look at the threats, attacks, vulnerabilities and countermeasures.  This post is a look at threats and countermeasures from a technical perspective.

The thing to keep in mind with security is that it’s a matter of people, process, and technology.  However, focusing on a specific slice, in this case the technical slice, can help you get results.  The thing to keep in mind about security from a technical side is that you also need to think holistically in terms of the application, network, and host, as well as how you plug it into your product or development life cycle.  For information on plugging it into your life cycle, see the Security Development Lifecycle.

While many of the same security issues that apply to running applications on-premise also apply to the cloud, the context of running in the cloud does change some key things.  For example, it might mean taking a deeper look at claims for identity management and access control.  It might mean rethinking how you think about your storage.  It can mean thinking more about how you access and manage virtualized computing resources.  It can mean thinking about how you make calls to services or how you protect calls to your own services.

Here is a fast path through looking at security threats, attacks, vulnerabilities, and countermeasures for the cloud …

Objectives

• Learn a security frame that applies to the cloud
• Learn top threats/attacks, vulnerabilities and countermeasures for each area within the security frame
• Understand differences between threats, attacks, vulnerabilities and countermeasures

Overview
It is important to think like an attacker when designing and implementing an application. Putting yourself in the attacker’s mindset will make you more effective at designing mitigations for vulnerabilities and coding defensively.  Below is the cloud security frame. We use the cloud security frame to present threats, attacks, vulnerabilities and countermeasures to make them more actionable and meaningful.

You can also use the cloud security frame to effectively organize principles, practices, patterns, and anti-patterns in a more useful way.

Threats, Attacks, Vulnerabilities, and Countermeasures
These terms are defined as follows:

• Asset. A resource of value such as the data in a database, data on the file system, or a system resource.
• Threat. A potential occurrence – malicious or otherwise – that can harm an asset.
• Vulnerability. A weakness that makes a threat possible.
• Attack. An action taken to exploit vulnerability and realize a threat.
• Countermeasure. A safeguard that addresses a threat and mitigates risk.

Cloud Security Frame
The following key security concepts provide a frame for thinking about security when designing applications to run on the cloud, such as Windows Azure. Understanding these concepts helps you put key security considerations such as authentication, authorization, auditing, confidentiality, integrity, and availability into action.

Hot Spot Description Auditing and Logging Cloud auditing and logging refers to how security-related events are recorded, monitored, audited, exposed, compiled & partitioned across multiple cloud instances. Examples include: Who did what and when and on which VM instance? Authentication Authentication is the process of proving identity, typically through credentials, such as a user name and password. In the cloud this also encompasses authentication against varying identity stores. Authorization Authorization is how your application provides access controls for roles, resources and operations. Authorization strategies might involve standard mechanisms, utilize claims and potentially support a federated model. Communication Communication encompasses how data is transmitted over the wire. Transport security, message encryption, and point to point communication are covered here. Configuration Management Configuration management refers to how your application handles configuration and administration of your applications from a security perspective. Examples include: Who does your application run as? Which databases does it connect to? How is your application administered? How are these settings secured? Cryptography Cryptography refers to how your application enforces confidentiality and integrity. Examples include: How are you keeping secrets (confidentiality)? How are you tamper-proofing your data or libraries (integrity)? How are you providing seeds for random values that must be cryptographically strong? Certificates and cert management are in this domain as well. Input and Data Validation Validation refers to how your application filters, scrubs, or rejects input before additional processing, or how it sanitizes output. It's about constraining input through entry points and encoding output through exit points. Message validation refers to how you verify the message payload against schema, as well as message size, content and character sets. Examples include: How do you know that the input your application receives is valid and safe? Do you trust data from sources such as databases and file shares? Exception Management Exception management refers to how you handle applications errors and exceptions. Examples include: When your application fails, what does your application do? Does it support graceful failover to other application instances in the cloud? How much information do you reveal? Do you return friendly error information to end users? Do you pass valuable exception information back to the caller? Sensitive Data Sensitive data refers to how your application handles any data that must be protected either in memory, over the network, or in persistent stores. Examples include: How does your application handle sensitive data? How is sensitive data shared between application instances? Session Management A session refers to a series of related interactions between a user and your application. Examples include: How does your application handle and protect user sessions?

 

Threats and Attacks

 

Category Items Auditing and Logging

• Repudiation. An attacker denies performing an operation, exploits an application without trace, or covers his or her tracks.
• Denial of service (DoS). An attacker overwhelms logs with excessive entries or very large log entries.
• Disclosure of confidential information. An attacker gathers sensitive information from log files.

Authentication

• Network eavesdropping. An attacker steals identity and/or credentials off the network by reading network traffic not intended for them.
• Brute force attacks. An attacker guesses identity and/or credentials through the use of brute force.
• Dictionary attacks. An attacker guesses identity and/or credentials through the use of common terms in a dictionary designed for that purpose.
• Cookie replay attacks. An attacker gains access to an authenticated session through the reuse of a stolen cookie containing session information.
• Credential theft. An attacker gains access to credentials through data theft; for instance, phishing or social engineering.

Authorization

• Elevation of privilege. An attacker enters a system as a lower-level user, but is able to obtain higher-level access.
• Disclosure of confidential data. An attacker accesses confidential information because of authorization failure on a resource or operation.
• Data tampering. An attacker modifies sensitive data because of authorization failure on a resource or operation.
• Luring attacks. An attacker lures a higher-privileged user into taking an action on their behalf. This is not an authorization failure but rather a failure of the system to properly inform the user.
• Token stealing. An attacker steals the credentials or token of another user in order to gain authorization to resources or operations they would not otherwise be able to access.

Communication

• Failure to encrypt messages. An attacker is able to read message content off the network because it is not encrypted.
• Theft of encryption keys. An attacker is able to decrypt sensitive data because he or she has the keys.
• Man-in-the-middle attack. An attacker can read and then modify messages between the client and the service.
• Session replay. An attacker steals messages off the network and replays them in order to steal a user's session.
• Data tampering. An attacker modifies the data in a message in order to attack the client or the service

Configuration Management

• Unauthorized access to configuration stores. An attacker gains access to configuration files and is able to modify binding settings, etc.
• Retrieval of clear text configuration secrets. An attacker gains access to configuration files and is able to retrieve sensitive information such as database connection strings.

Cryptography

• Encryption cracking. Breaking an encryption algorithm and gaining access to the encrypted data.
• Loss of decryption keys. Obtaining decryption keys and using them to access protected data.

Exception Management

• Information disclosure. Sensitive system or application details are revealed through exception information.
• Denial of service. An attacker uses error conditions to stop your service or place it in an unrecoverable error state.
• Elevation of privilege. Your service encounters an error and fails to an insecure state; for instance, failing to revert impersonation.

Input and Data Validation

• Canonicalization attacks. Canonicalization attacks can occur anytime validation is performed on a different form of the input than that which is used for later processing. For instance, a validation check may be performed on an encoded string, which is later decoded and used as a file path or URL.
• Cross-site scripting. Cross-site scripting can occur if you fail to encode user input before echoing back to a client that will render it as HTML.
• SQL injection. Failure to validate input can result in SQL injection if the input is used to construct a SQL statement, or if it will modify the construction of a SQL statement in some way.
• Cross-Site Request Forgery: CSRF attacks involve forged transactions submitted to a site on behalf of another party.
• XPath injection. XPath injection can result if the input sent to the Web service is used to influence or construct an XPath statement. The input can also introduce unintended results if the XPath statement is used by the Web service as part of some larger operation, such as applying an XQuery or an XSLT transformation to an XML document.
• XML bomb. XML bomb attacks occur when specific, small XML messages are parsed by a service resulting in data that feeds on itself and grows exponentially. An attacker sends an XML bomb with the intent of overwhelming a Web service’s XML parser and resulting in a denial of service attack.

Sensitive Data

• Memory dumping. An attacker is able to read sensitive data out of memory or from local files.
• Network eavesdropping. An attacker sniffs unencrypted sensitive data off the network.
• Configuration file sniffing. An attacker steals sensitive information, such as connection strings, out of configuration files.

Session Management

• Session hijacking. An attacker steals the session ID of another user in order to gain access to resources or operations they would not otherwise be able to access.
• Session replay. An attacker steals messages off the network and replays them in order to steal a user’s session.
• Man-in-the-middle attack. An attacker can read and then modify messages between the client and the service.
• Inability to log out successfully. An application leaves a communication channel open rather than completely closing the connection and destroying any server objects in memory relating to the session.
• Cross-site request forgery. Cross-site request forgery (CSRF) is where an attacker tricks a user into performing an action on a site where the user actually has a legitimate authorized account.
• Session fixation. An attacker uses CSRF to set another person’s session identifier and thus hijack the session after the attacker tricks a user into initiating it.
• Load balancing and session affinity. When sessions are transferred from one server to balance traffic among the various servers, an attacker can hijack the session during the handoff.

Vulnerabilities

Category Items Auditing and Logging

• Failing to audit failed logons.
• Failing to secure log files.
• Storing sensitive information in log files.
• Failing to audit across application tiers.
• Failure to throttle log files.

Authentication

• Using weak passwords.
• Storing clear text credentials in configuration files.
• Passing clear text credentials over the network.
• Permitting prolonged session lifetime.
• Mixing personalization with authentication.
• Using weak authentication mechanisms (e.g., using basic authentication over an untrusted network).

Authorization

• Relying on a single gatekeeper (e.g., relying on client-side validation only).
• Failing to lock down system resources against application identities.
• Failing to limit database access to specified stored procedures.
• Using inadequate separation of privileges.
• Connection pooling.
• Permitting over privileged accounts.

Configuration Management

• Using insecure custom administration interfaces.
• Failing to secure configuration files on the server.
• Storing sensitive information in the clear text.
• Having too many administrators.
• Using over privileged process accounts and service accounts.

Communication

• Not encrypting messages.
• Using custom cryptography.
• Distributing keys insecurely.
• Managing or storing keys insecurely.
• Failure to use a mechanism to detect message replays.
• Not using either message or transport security.

Cryptography

• Using custom cryptography
• Failing to secure encryption keys
• Using the wrong algorithm or a key size that is too small
• Using the same key for a prolonged period of time
• Distributing keys in an insecure manner

Exception Management

• Failure to use structured exception handling (try/catch).
• Revealing too much information to the client.
• Failure to specify fault contracts with the client.
• Failure to use a global exception handler.

Input and Data Validation

• Using non-validated input used to generate SQL queries.
• Relying only on client-side validation.
• Using input file names, URLs, or usernames for security decisions.
• Using application-only filters for malicious input.
• Looking for known bad patterns of input.
• Trusting data read from databases, file shares, and other network resources.
• Failing to validate input from all sources including cookies, headers, parameters, databases, and network resources.

Sensitive Data

• Storing secrets when you do not need to.
• Storing secrets in code.
• Storing secrets in clear text in files, registry, or configuration.
• Passing sensitive data in clear text over networks.

Session Management

• Passing session IDs over unencrypted channels.
• Permitting prolonged session lifetime.
• Having insecure session state stores.
• Placing session identifiers in query strings.

 

Countermeasures

 

Category Items Auditing and Logging

• Identify malicious behavior.
• Know your baseline (know what good traffic looks like).
• Use application instrumentation to expose behavior that can be monitored.
• Throttle logging.
• Strip sensitive data before logging.

Authentication

• Use strong password policies.
• Do not store credentials in an insecure manner.
• Use authentication mechanisms that do not require clear text credentials to be passed over the network.
• Encrypt communication channels to secure authentication tokens.
• Use Secure HTTP (HTTPS) only with forms authentication cookies.
• Separate anonymous from authenticated pages.
• Using cryptographic random number generators to generate session IDs.

Authorization

• Use least-privileged accounts.
• Tie authentication to authorization on the same tier.
• Consider granularity of access.
• Enforce separation of privileges.
• Use multiple gatekeepers.
• Secure system resources against system identities.

Configuration Management

• Using insecure custom administration interfaces.
• Failing to secure configuration files on the server.
• Storing sensitive information in the clear text.
• Having too many administrators.
• Using overprivileged process accounts and service accounts.

Communication

• Use message security or transport security to encrypt your messages.
• Use proven platform-provided cryptography.
• Periodically change your keys.
• Use any platform-provided replay detection features.
• Consider creating custom code if the platform does not provide a detection mechanism.
• Turn on message or transport security.

Cryptography

• Do not develop and use proprietary algorithms (XOR is not encryption. Use established cryptography such as RSA)
• Avoid key management.
• Use the RNGCryptoServiceProvider method to generate random numbers
• Periodically change your keys

Exception Management

• Use structured exception handling (by using try/catch blocks).
• Catch and wrap exceptions only if the operation adds value/information.
• Do not reveal sensitive system or application information.
• Implement a global exception handler.
• Do not log private data such as passwords.

Sensitive Data

• Do not store secrets in software.
• Encrypt sensitive data over the network.
• Secure the channel.
• Encrypt sensitive data in configuration files.

Session Management

• Partition the site by anonymous, identified, and authenticated users.
• Reduce session timeouts.
• Avoid storing sensitive data in session stores.
• Secure the channel to the session store.
• Authenticate and authorize access to the session store.

Validation

• Do not trust client input.
• Validate input: length, range, format, and type.
• Validate XML streams.
• Constrain, reject, and sanitize input.
• Encode output.
• Restrict the size, length, and depth of parsed XML messages.

Threats and Attacks Explained

1.  Brute force attacks. Attacks that use the raw computer processing power to try different permutations of any variable that could expose a security hole. For example, if an attacker knew that access required an 8-character username and a 10-character password, the attacker could iterate through every possible (256 multiplied by itself 18 times) combination in order to attempt to gain access to a system. No intelligence is used to filter or shape for likely combinations.
2. Buffer overflows. The maximum size of a given variable (string or otherwise) is exceeded, forcing unintended program processing. In this case, the attacker uses this behavior to cause insertion and execution of code in such a way that the attacker gains control of the program in which the buffer overflow occurs. Depending on the program’s privileges, the seriousness of the security breach will vary.
3. Canonicalization attacks. There are multiple ways to access the same object and an attacker uses a method to bypass any security measures instituted on the primary intended methods of access. Often, the unintended methods of access can be less secure deprecated methods kept for backward compatibility.
4. Cookie manipulation. Through various methods, an attacker will alter the cookies stored in the browser. Attackers will then use the cookie to fraudulently authenticate themselves to a service or Web site.
5. Cookie replay attacks. Reusing a previously valid cookie to deceive the server into believing that a previously authenticated session is still in progress and valid.
6. Credential theft. Stealing the verification part of an authentication pair (identity + credentials = authentication). Passwords are a common credential.
7. Cross-Site Request Forgery (CSRF). Interacting with a web site on behalf of another user to perform malicious actions. A site that assumes all requests it receives are intentional is vulnerable to a forged request.
8. Cross-site scripting (XSS). An attacker is able to inject executable code (script) into a stream of data that will be rendered in a browser. The code will be executed in the context of the user’s current session and will gain privileges to the site and information that it would not otherwise have.
9. Connection pooling. The practice of creating and then reusing a connection resource as a performance optimization. In a security context, this can result in either the client or server using a connection previously used by a highly privileged user being used for a lower-privileged user or purpose. This can potentially expose vulnerability if the connection is not reauthorized when used by a new identity.
10. Data tampering. An attacker violates the integrity of data by modifying it in local memory, in a data-store, or on the network. Modification of this data could provide the attacker with access to a service through a number of the different methods listed in this document.
11. Denial of service. Denial of service (DoS) is the process of making a system or application unavailable. For example, a DoS attack might be accomplished by bombarding a server with requests to consume all available system resources, or by passing the server malformed input data that can crash an application process.
12. Dictionary attack. Use of a list of likely access methods (usernames, passwords, coding methods) to try and gain access to a system. This approach is more focused and intelligent than the “brute force” attack method, so as to increase the likelihood of success in a shorter amount of time.
13. Disclosure of sensitive/confidential data. Sensitive data is exposed in some unintended way to users who do not have the proper privileges to see it. This can often be done through parameterized error messages, where an attacker will force an error and the program will pass sensitive information up through the layers of the program without filtering it. This can be personally identifiable information (i.e., personal data) or system data.
14. Elevation of privilege. A user with limited privileges assumes the identity of a privileged user to gain privileged access to an application. For example, an attacker with limited privileges might elevate his or her privilege level to compromise and take control of a highly privileged and trusted process or account. More information about this attack in the context of Windows Azure can be found in the Security Best Practices for Developing Windows Azure Applications at http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0ff0c25f-dc54-4f56-aae7-481e67504df6
15. Encryption. The process of taking sensitive data and changing it in such a way that it is unrecognizable to anyone but those who know how to decode it. Different encryption methods have different strengths based on how easy it is for an attacker to obtain the original information through whatever methods are available.
16. Information disclosure. Unwanted exposure of private data. For example, a user views the contents of a table or file that he or she is not authorized to open, or monitors data passed in plaintext over a network. Some examples of information disclosure vulnerabilities include the use of hidden form fields, comments embedded in Web pages that contain database connection strings and connection details, and weak exception handling that can lead to internal system-level details being revealed to the client. Any of this information can be very useful to the attacker.
17. Luring attacks. An attacker lures a higher-privileged user into taking an action on his or her behalf. This is not an authorization failure but rather a failure of the system to properly inform the user.
18. Man-in-the-middle attacks. A person intercepts both the client and server communications and then acts as an intermediary between the two without each ever knowing. This gives the “middle man” the ability to read and potentially modify messages from either party in order to implement another type of attack listed here.
19. Network eavesdropping. Listening to network packets and reassembling the messages being sent back and forth between one or more parties on the network. While not an attack itself, network eavesdropping can easily intercept information for use in specific attacks listed in this document.
20. Open Redirects. Attacker provides a URL to a malicious site when allowed to input a URL used in a redirect. This allows the attacker to direct users to sites that perform phishing attacks or other malicious actions.
21. Password cracking. If the attacker cannot establish an anonymous connection with the server, he or she will try to establish an authenticated connection. For this, the attacker must know a valid username and password combination. If you use default account names, you are giving the attacker a head start. Then the attacker only has to crack the account’s password. The use of blank or weak passwords makes the attacker’s job even easier.
22. Repudiation. The ability of users (legitimate or otherwise) to deny that they performed specific actions or transactions. Without adequate auditing, repudiation attacks are difficult to prove.
23. Session hijacking. Also known as man-in-the-middle attacks, session hijacking deceives a server or a client into accepting the upstream host as the actual legitimate host. Instead, the upstream host is an attacker’s host that is manipulating the network so the attacker’s host appears to be the desired destination.
24. Session replay. An attacker steals messages off of the network and replays them in order to steal a user’s session.
25. Session fixation. An attacker sets (fixates) another person’s session identifier artificially. The attacker must know that a particular Web service accepts any session ID that is set externally; for example, the attacker sets up a URL such as http://unsecurewebservice.com/?sessionID=1234567. The attacker then sends this URL to a valid user, who clicks on it. At this point, a valid session with the ID 1234567 is created on the server. Because the attacker determines this ID, he or she can now hijack the session, which has been authenticated using the valid user’s credentials.
26. Spoofing. An attempt to gain access to a system by using a false identity. This can be accomplished by using stolen user credentials or a false IP address. After the attacker successfully gains access as a legitimate user or host, elevation of privileges or abuse using authorization can begin.
27. SQL injection. Failure to validate input in cases where the input is used to construct a SQL statement or will modify the construction of a SQL statement in some way. If the attacker can influence the creation of a SQL statement, he or she can gain access to the database with privileges otherwise unavailable and use this in order to steal or modify information or destroy data.
28. Throttling. The process of limiting resource usage to keep a particular process from bogging down and/or crashing a system. Relevant as a countermeasure in DoS attacks, where an attacker attempts to crash the system by overloading it with input.

Countermeasures Explained

1. Assume all input is malicious. Assuming all input is malicious means designing your application to validate all input. User input should never be accepted without being filtered and/or sanitized.
2. Audit and log activity through all of the application tiers. Log business critical and security sensitive events. This will help you track security issues down and make sense of security problems. Skilled attackers attempt to cover their tracks, so you’ll want to protect your logs.
3. Avoid storing secrets. Design around storing secrets. If necessary, sometimes they can be avoided by storing them after using a one-way hash algorithm.
4. Avoid storing sensitive data in the Web space. Anything exposed to the public Internet is considered “web space.” Sensitive data stored in a location that might be compromised by any member of the public places it at much higher risk.
5. Back up and regularly analyze log files. Some attacks can occur over time. Regular analysis of logs will allow you to recognize with sufficient time to address them. Performing regular backups lowers the risk of an attacker covering his tracks by deleting logging of his activities.
6. Be able to disable accounts. The ability to reactively defend an attack by shutting out a user should be supported through the ability to disable an account.
7. Be careful with canonicalization issues. Predictable naming of file resources is convenient for programming, but is also very convenient for malicious parties to attack. Application logic should not be exposed to users in this manner. Instead, you use file names derived from the original names or fed through a one-way hashing algorithm.
8. Catch exceptions. Unhandled exceptions are at risk of passing too much information to the client. Handle exceptions when possible.
9. Centralize your input and data validation. Input and data validation should be performed using a common set of code such as a validation library.
10. Consider a centralized exception management framework. Exception handling frameworks are available publically and provide an established and tested means for handling exceptions.
11. Consider authorization granularity. Every object needs to have an authorization control that authorizes access based on the identity of the authenticated party requesting access. Fine grained authorization will control access to each resource, while coarse grained authorization will control access to groups of resources or functional areas of the application.
12. Consider identity flow. Auditing should be traceable back to the authenticated party. Take note of identity transitions imposed by design decisions like impersonation.
13. Constrain input. Limit user input to expected ranges and formats.
14. Constrain, reject, and sanitize your input. Constrain, reject and sanitize should be primary techniques in handling input data.
15. Cycle your keys periodically. Expiring encryption keys lowers the risk of stolen keys.
16. Disable anonymous access and authenticate every principle. When possible, require all interactions to occur as an authenticated party as opposed to an anonymous one. This will help facilitate more effective auditing.
17. Do not develop your own cryptography. Custom cryptography is not difficult for experts to crack. Established cryptography is preferred because it is known to be safe.
18. Do not leak information to the client. Exception data can potentially contain sensitive data or information exposing program logic. Provide clients only with the error data they need for the UI.
19. Do not log private data such as passwords. Log files are an attack vector for malicious parties. Limit the risk of their being compromised by not logging sensitive data in the log.
20. Do not pass sensitive data using the HTTP-GET protocol. Data passed using HTTP GET is appended to the querystring. When users share links by copying and pasting them from the browser address bar, sensitive data may also be inadvertently passed. Pass sensitive data in the body of a POST to avoid this.
21. Do not rely on client-side validation. Any code delivered to a client is at risk of being compromised. Because of this, it should always be assumed that input validation on the client might have been bypassed.
22. Do not send passwords over the wire in plaintext. Authentication information communicated over the wire should always be encrypted. This may mean encrypting the values, or encrypting the entire channel with SSL.
23. Do not store credentials in plaintext. Credentials are sometimes stored in application configuration files, repositories, or sent over email. Always encrypt credentials before storing them.
24. Do not store database connections, passwords, or keys in plaintext. Configuration secrets should always be stored in encrypted form, external to the code.
25. Do not store passwords in user stores. In the event that the user store is compromised, an attack should never be able to access passwords. A derivative of a password should be stored instead. A common approach to this is to encrypt a version of the password using a one-way hash with a SALT. Upon authentication, the encrypted password can be re-generated with the SALT and the result can be compared to the original encrypted password.
26. Do not store secrets in code. Secrets such as configuration settings are convenient to store in code, but are more likely to be stolen. Instead, store them in a secure location such as a secret store.
27. Do not store sensitive data in persistent cookies. Persistent cookies are stored client-side and provide attackers with ample opportunity to steal sensitive data, be it through encryption cracking or any other means.
28. Do not trust fields that the client can manipulate (query strings, form fields, cookies, or HTTP headers). All information sent from a client should always be assumed to be malicious. All information from a client should always be validated and sanitized before it is used.
29. Do not trust HTTP header information. Http header manipulation is a threat that can be mitigated by building application logic that assumes HTTP headers are compromised and validates the HTTP headers before using them.
30. Encrypt communication channels to protect authentication tokens. Authentication tokens are often the target of eavesdropping, theft or replay type attacks. To reduce the risk in these types of attacks, it is useful to encrypt the channel the tokens are communicated over. Typically this means protecting a login page with SSL encryption.
31. Encrypt sensitive cookie state. Sensitive data contained within cookies should always be encrypted.
32. Encrypt the contents of the authentication cookies. In the case where cookies are compromised, they should not contain clear-text session data. Encrypt sensitive data within the session cookie.
33. Encrypt the data or secure the communication channel. Sensitive data should only be passed in encrypted form. This can be accomplished by encrypting the individual items that are sent over the wire, or encrypting the entire channel as with SSL.
34. Enforce separation of privileges. Avoid building generic roles with privileges to perform a wide range of actions. Roles should be designed for specific tasks and provided the minimum privileges required for those tasks.
35. Enforce unique transactions. Identify each transaction from a client uniquely to help prevent replay and forgery attacks.
36. Identify malicious behavior. Monitoring site interactions that fall outside of normal usage patterns, you can quickly identify malicious behavior. This is closely related to “Know what good traffic looks like.
37. Keep unencrypted data close to the algorithm. Use decrypted data as soon as it is decrypted, and then dispose of it promptly. Unencrypted data should not be held in memory in code.
38. Know what good traffic looks like. Active auditing and logging of a site will allow you know recognize what regular traffic and usage patterns are. This is a required step in order to be able to identify malicious behavior.
39. Limit session lifetime. Longer session lifetimes provide greater opportunity for Cross-Site Scripting or Cross-Site Request Forgery attacks to add activity onto an old session.
40. Log detailed error messages. Highly detailed error message logging can provide clues to attempted attacks.
41. Log key events. Profile your application and note key or sensitive operations and/or events, and log these events during application operation.
42. Maintain separate administration privileges. Consider granularity of authorization in the administrative interfaces as well. Avoid combining administrator roles with distinctly different roles such as development, test or deployment.
43. Make sure that users do not bypass your checks. Bypassing checks can be accomplished by canonicalization attacks, or bypassing client-side validation. Application design should avoid exposing application logic, and segregating application logic into flow that can be interrupted. For example, an ASPX page that performs only validations and then redirects. Instead, validation routines should be tightly bound to the data they are validating.
44. Pass Forms authentication cookies only over HTTPS connections. Cookies are at risk of theft and replay type attacks. Encrypting them with SSL helps reduce the risk of these types of attacks.
45. Protect authentication cookies. Cookies can be manipulated with Cross-Site Scripting attacks, encrypt sensitive data in cookies, and use browser features such as the HttpOnly cookie attribute.
46. Provide strong access controls on sensitive data stores. Access to secret stores should but authorized. Protect the secret store as you would other secure resources by requiring authentication and authorization as appropriate.
47. Reject known bad input. Rejecting known bad input involves screening input for values that are known to be problematic or malicious. NOTE: Rejecting should never be the primary means of screening bad input, it should always be used in conjunction with input sanitization.
48. Require strong passwords. Enforce password complexity requirement by requiring long passwords with a combination of upper case, lower case, numeric and special (for example punctuation) characters. This helps mitigate the threat posed by dictionary attacks. If possible, also enforce automatic password expiry.
49. Restrict user access to system-level resources. Users should not be touching system resources directly. This should be accomplished through an intermediary such as the application. System resources should be restricted to application access.
50. Retrieve sensitive data on demand. Sensitive data stored in application memory provides attackers another location they can attempt to access the data. Often this data is used in unencrypted form also. To minimize risk of sensitive data theft, sensitive data should be used immediately and then cleared from memory.
51. Sanitize input. Sanitizing input is the opposite of rejecting bad input. Sanitizing input is the process of filtering input data to only accept values that are known to be safe. Alternatively, input can be rendered innocuous by converting it to safe output through output encoding methods.
52. Secure access to log files. Log files should only be accessible to administrators, auditors, or administrative interfaces. An attacker with access to the logs might be able to glean sensitive data or program logic from logs.
53. Secure the communication channel for remote administration. Eavesdropping and replay attacks can target administration interfaces as well. If using a web based administration interface, use SSL.
54. Secure your configuration store. The configuration store should require authenticated access and should store sensitive settings or information in an encrypted format.
55. Secure your encryption keys. Encryption keys should be treated as secrets or sensitive data. They should be secured in a secret store or key repository.
56. Separate public and restricted areas. Applications that contain public front-ends as well as content that requires authentication to access should be partitioned in the same manner. Public facing pages should be hosted in a separate file structure, directory or domain from private content.
57. Store keys in a restricted location. Protect keys with authorization policies.
58. Support password expiration periods. User passwords and account credentials are commonly compromised. Expiration policies help mitigate attacks from stolen accounts, or disgruntled employees who have been terminated.
59. Use account lockout policies for end-user accounts. Account login attempts should have a cap on failed attempts. After the cap is exceeded the account should prevent further login attempts. Lockout helps prevent dictionary and brute force attacks.
60. Use application instrumentation to expose behavior that can be monitored: Application transactions that are more likely to be targeted by malicious interactions should be logged or monitored. Examples of this might be adding logging code to an exception handler, or logging individual API calls. By providing a means to watch these transactions you have a higher likelihood of being able to identify malicious behavior quickly.
61. Use authentication mechanisms that do not require clear text credentials to be passed over the network: A variety of authentication approaches exist for use with web based applications some involve the use of tokens while others will pass user credentials (user name/id and password) over the wire. When possible, it is safer to use an authentication mechanism that does not pass the credentials. If credentials must be passed, it is preferable to encrypt them, and/or send them over an encrypted channel such as SSL.
62. Use least privileged accounts. The privileges granted to the authenticated party should be the minimum required to perform all required tasks. Be careful of using existing roles that have permissions beyond what is required.
63. Use least privileged process and service accounts. Allocate accounts specifically for process and service accounts. Lock down the privileges of these accounts separately from other accounts.
64. Use multiple gatekeepers. Passing the authentication system should not provide a golden ticket to any/all functionality. System and/or application resources should have restricted levels of access depending on the authenticated party. Some design patterns might also enforce multiple authentications, sometimes distributed through application tiers.
65. Use SSL to protect session authentication cookies. Session authentication cookies contain data that can be used in a number of different attacks such as replay, Cross-Site Scripting or Cross-Site Request Forgery. Protecting these cookies helps mitigate these risks.
66. Use strong authentication and authorization on administration interfaces. Always require authenticated access to administrative interfaces. When applicable, also enforce separation of privileges within the administrative interfaces.
67. Use structured exception handling. A structured approach to exception handling lowers the risk of unexpected exceptions from going unhandled.
68. Use the correct algorithm and correct key length. Different encryption algorithms are preferred for varying data types and scenarios.
69. Use tried and tested platform features. Many cryptographic features are available through the .NET Framework. These are proven features and should be used in favor of custom methods.
70. Validate all values sent from the client. Similar to not relying on client-side validation, any input from a client should always be assumed to have been tampered with. This input should always be validated before it is used. This encompasses user input, cookie values, HTTP headers, and anything else that is sent over the wires from the client.
71. Validate data for type, length, format, and range. Data validation should encompass these primary tenets. Validate for data type, string lengths, string or numeric formats, and numeric ranges.

SDL Considerations
For more information on preferred encryption algorithms and key lengths, see the Security Development Lifecycle at http://www.microsoft.com/security/sdl/ .