Each month I pick a focus or a theme for my improvement sprint.  I find it's easier to start and stop a new sprint each month, rather than start in the middle of a month and try and remember when to stop.  I also like the fact that each month is a fresh start.  Cycling through a new improvement sprint each month, gives me 12 sprints I can allocate to whatever I want or need to focus on.  This keeps me learning and growing throughout the year in a simple, but systematic way.  Each month I can do another sprint on the same topic or pick a new area to explore.  Periodically, I try to inject an improvement sprint that focuses on something physical.  For example, last year I did a living foods improvement sprint and in another sprint I worked up to roller-blading 15+ miles a day.

Here's the improvement sprints I've done so far this year:

• JAN - Leadership skills / Microsoft leadership skills
• FEB - Effective blogging
• MAR - Effective blogging (I continued researching effective blogging practices)
• APR - SEO practices (studying blogging practices lead me down the SEO path)

Sometimes I'll do more than one sprint for a month, but in general I try to stick with one theme.  The power of the sprint is the focus.  Its easier for me to stay focused when I remind myself I can switch focus each month.

My Related Posts

• 30 Day Improvement Sprints
• Why 30 Day Improvement Sprints
• Making 30 Day Improvement Sprints More Effective

What are your key security-related questions with WCF?  More importantly, what are the answers?  For this week's release of our WCF Security Guidance Project, we posted our WCF Security Q&A (Questions and Answers) to CodePlex. 

To create the questions and answers set, we first gathered and organized recurring questions from our field, support, customers and forums.  We then worked through to create precise answers.  What you get is a browsable collection of questions and answers, organized by our security frame.   The security frame maps to actionable categories of your application.

Here's a snapshot of the questions from our Q&A, but you can see our answers explained at our WCF Security Guidance project site.

Design Considerations

• How do I decide on an authentication strategy?
• How do I decide on an authorization strategy?
• When should I use message security vs. transport security?
• How do I use my existing Active Directory infrastructure?
• What bindings should I use over the Internet?
• What bindings should I use over the Intranet?
• When should I use resource-based authorization vs. roles-based authorization?
• When should I impersonate the original caller?
• When should I flow the original caller’s identity to back-end resources?
• How do I migrate to WCF from an ASMX web service?
• How do I migrate to WCF from a COM application?
• How do I migrate to WCF from a DCOM application?
• How do I migrate to WCF from a WSE application?

Auditing and Logging

• What WCF Service security events should be logged?
• How do I enable logging and auditing in WCF?
• How do I enable auditing in WCF?
• How do I stop my service if there has been an auditing failure?
• How do I log important business events in WCF?
• How do I implement log throttling in WCF?
• How do I use Health Monitoring Feature with WCF?
• How do I protect my log files?
• How to I pass user identity information in a message for auditing purpose?

Authentication

• How do I decide on an authentication strategy in WCF?
• When should I use brokered authentication?
• When should I use the SQL Server Membership provider?
• How do I authenticate against Active Directory?
• How do I authenticate against a SQL store?
• How do I authenticate against a custom store?
• How do I protect passwords in my user store?
• How do I use certificate authentication with X.509 certificates?
• What is the most common authentication scenario for intranet applications?
• What is the most common authentication scenario for internet applications?
• How do I support authentication for multiple client types?
• What is federated security?
• How do I send credentials in the message when I am using transport security?
• How do I avoid cleartext passwords?

Authorization

• How do I decide on an authorization strategy in WCF?
• What’s the difference between resource-based, roles-based and claims-based authorization?
• How do I use Windows groups for role authorization in WCF?
• How do I use the SQL Role provider for ASPNET role authorization in WCF?
• How do I use the Windows Token role provider for ASPNET role authorization in WCF?
• How do I use the Authorization Store role provider for ASPNET role authorization in WCF?
• What’s the difference between declarative and imperative roles authorization?
• How do I restrict access to WCF operations to specific Windows users?
• How do I associate roles with a certificate?
• What is a service principle name (SPN)?
• How do I create a service principle name (SPN)?

Bindings

• What is a binding?
• What bindings are available?
• Which bindings are best suited for the Internet?
• Which bindings are best suited for the Intranet?
• How do I choose an appropriate binding?
• Configuration Management
• How do I encrypt sensitive data in WCF configuration file?
• How do I run a WCF Service with a particular identity?
• How do I create a service account for running my WCF Service?
• When should I use a configuration file versus the WCF object model?
• What is a metadata exchange (MEX) binding?
• How do I keep clients from referencing my service?

Exception Management

• How do I implement a global exception handler?
• What is a fault contract?
• How do I define a fault contract?
• How do I avoid sending exception details to the client?

Hosting

• How do I configure a least privileged account to host my service?
• When should I host my service in IIS?
• When should I host my service in a Windows service?
• When should I self-host my service?
• Impersonation/Delegation
• What are my impersonation options?
• What is the difference between impersonation and delegation?
• How do I impersonate the original caller for an operation call?
• How do I temporarily impersonate the original caller in an operation call?
• How do I impersonate a specific (fixed) identity?
• What is constrained delegation?
• What is protocol transition?
• How do I flow original caller from ASP.NET client to WCF Service?
• What is the difference between declarative and programmatic impersonation?
• What is the trusted subsystem model?
• When should I flow the original caller to back-end code?
• How do I control access to a remote resource based on the original caller’s identity?

Input/Data Validation

• How do I implement input and data validation in WCF?
• What is schema validation?
• What is parameter validation?
• Should I validate before or after message serialization?
• How do I protect my service from denial of service attacks?
• How do I protect my service from malicious input attacks?
• How do I protect my service from malformed messages?
• Message Protection
• When should I use message security?
• When should I use transport security?
• How do I protect my message when there are intermediaries routing my message?
• How do I protect my message when there are multiple protocols used during message
• transit?
• How do I implement partial message encryption?

Proxy Considerations

• When should I use a channel factory?
• When do I need to expose a metadata exchange endpoint for my service?
• How do I avoid proxy spoofing?

Sensitive Data

• How do I protect sensitive data in configuration files?
• How do I protect sensitive data in memory?
• How do I protect my metadata?
• How do I protect sensitive data from being read on the wire?
• How do I protect sensitive data from being tampered with on the wire?
• How do I authenticate a message was sent by the expected sender?
• How do I encrypt data within my message?

X.509 Certificates

• How do I create X.509 certificates?
• Do I need to create a certificate signed by the root CA certificate?
• How do I use X.509 certificate revocation?
• How do I authenticate users with X.509 certificates, and then perform role-based access control using an Active Directory domain?

Deployment Considerations

• What are the additional considerations for using WCF in a webfarm?
• How do I configure WCF for NATs and Firewalls?
• How do I configure Active Directory groups and accounts for role-based authorization checks?
• How do I create an X.509 certificate?
• When should I use a Service Principle Name (SPN)?
• How do I configure a least privileged account for my service?

My Related Posts

• patterns & practices WCF 3.5 Security Guidelines Now Available
• patterns & practices WCF Security Guidance: Updated Application Scenarios
• patterns & practices WCF Security Application Scenarios
• patterns & practices WCF Security Guidance Now Available

For this week's release in our patterns & practices WCF Security Guidance project, we released our first version of our WCF 3.5 Security Guidelines.  Each guideline is a nugget of what to do, why, and how.  The goal of the guideline format is to take a lot of information, compress it down, and turn insight into action.

The downside is that it's tough to create prescriptive guidelines that are generic enough to be reusable, but specific enough to be helpful.  The upside is that customers find the guidelines help them cut through a lot of information and take action.  We contextualize the guidelines as much as we can, but ultimately you're in the best position to do the pattern matching to find which guidelines are relevant for your scenarios, and how you need to tailor them.

Here's a snapshot of the guidelines, but you can see our security guidelines explained at our WCF Security Guidance project site.

Categories
Our WCF Security guidelines are organized using the following buckets:

• Auditing and Logging
• Authentication
• Authorization
• Binding
• Configuration Management
• Exception Management
• Hosting
• Impersonation and Delegation
• Input/Data Validation
• Proxy Considerations
• Deployment considerations 

Auditing and Logging

• Use WCF auditing to audit your service
• If non-repudiation is important, consider setting SuppressAuditFailure property to false
• Use message logging to log operations on your service
• Instrument for user management events
• Instrument for significant business operations
• Protect log files from unauthorized access
• Do not log sensitive information

Authentication

• Know your authentication options
• Use Windows Authentication when you can
• If you support non-WCF clients using windows authentication and message security, consider using the Kerberos direct option
• If your users are in AD, but you can’t use windows authentication, consider using username authentication
• If your clients have certificates, consider using client certificate authentication
• If you need to streamline certificate distribution to your clients for message encryption, consider using the negotiate credentials option
• If your users are in a custom store, consider using username authentication with a custom validator
• If your users are in a SQL membership store, use the SQL Membership Provider
• If your partner applications need to be authenticated when calling WCF services, use client certificate authentication.
• If you are using username authentication, use SQL Server Membership Provider instead of custom authentication
• If you need to support intermediaries and a variety of transports between client and service, use message security to protect credentials
• If you are using username authentication, validate user login information
• Do not store passwords directly in the user store
• Enforce strong passwords
• Protect access to your credential store
• If you are using Windows Forms to connect to WCF, do not cache credentials

Authorization

• If you use ASP.NET roles, use the ASP.NET Role Provider
• If you use windows groups for authorization, use ASP.NET Role Provider with AspNetWindowsTokenRoleProvider
• If you store role information in SQL, consider using the SQL Server Role Provider for roles authorization
• If you store role information in Windows Groups, consider using the WCF PrincipalPermissionAttribute class for roles authorization
• If you need to authorize access to WCF operations, use declarative authorization
• If you need to perform fine-grained authorization based on business logic, use imperative authorization

Binding

• If you need to support clients over the internet, consider using wsHttpBinding.
• If you need to expose your WCF service to legacy clients as an ASMX web service, use basicHttpBinding
• If you need to support remote WCF clients within an intranet, consider using netTcpBinding.
• If you need to support local WCF clients, consider using netNamedPipeBinding.
• If you need to support disconnected queued calls, use netMsmqBinding.
• If you need to support bidirectional communication between WCF Client and WCF service, use wsDualHttpBinding.

Configuration Management

• Use Replay detection to protect against message replay attacks
• If you host your service in a Windows service, expose a metadata exchange (mex) binding
• If you don’t want to expose your WSDL, turn off HttpGetEnabled and metadata exchange (mex)
• Manage bindings and endpoints in config not code
• Associate names with the service configuration when you create service behavior, endpoint behavior, and binding configuration
• Encrypt configuration sections that contain sensitive data

Exception Management

• Use structured exception handling
• Do not divulge exception details to clients in production
• Use a fault contract to return error information to clients
• Use a global exception handler to catch unhandled exceptions

Hosting

• If you are hosting your service in a Windows Service, use a least privileged custom domain account
• If you are hosting your service in IIS, use a least privileged service account
• Use IIS to host your service unless you need to use a transport that IIS does not support

Impersonation and Delegation

• Know the impersonation options
• If you have to flow the original caller, use constrained delegation
• Consider LogonUser when you need to impersonate but you don’t have trusted delegation
• Consider S4U when you need a Windows token and you don’t have the original caller’s credentials
• Use programmatic impersonation to impersonate based on business logic
• When impersonating programmatically be sure to revert to original context
• Only impersonate on operations that require it
• Use OperationBehavior to impersonate declaratively

Input/Data Validation

• If you need to validate parameters, use parameter inspectors
• If your service has operations that accept message or data contracts, use schemas to validate your messages
• If you need to do schema validation, use message inspectors
• Validate operation parameters for length, range, format and type
• Validate parameter input on the server
• Validate service responses on the client
• Do not rely on client-side validation
• Avoid user-supplied file name and path input
• Do not echo untrusted input

Proxy Considerations

• Publish your metadata over HTTPS to protect your clients from proxy spoofing
• If you turn off mutual authentication, be aware of service spoofing

Deployment considerations

• Do not use temporary certificates in production
• If you are using a custom domain account in the identity pool for your WCF application, create an SPN for Kerberos to authenticate the client.
• If you are using a custom service account and need to use trusted for delegation, create an SPN
• If you are hosting your service in a Windows Service, using a custom domain identity, and ASP.NET needs to use constrained trusted for delegation when calling the service, create an SPN
• Use IIS to host your service unless you need to use a transport that IIS does not support
• Use a least privileged account to run your WCF service
• Protect sensitive data in your configuration files

My Related Posts

• patterns & practices WCF Security Guidance: Updated Application Scenarios
• patterns & practices WCF Security Application Scenarios
• patterns & practices WCF Security Guidance Now Available

For this week's release in our patterns & practices WCF Security Guidance project, we added new sections to our WCF Security Application Scenarios.  We added sections for analysis, code and configuration examples.  The analysis section explains the rationale behind some of the decisions. 

The idea behind the application scenarios is to show you a before and after look of end-to-end solutions.  Rather than a single solution, we give you a set of solutions to pick from.  The main parameters that vary in each solution include: Intranet vs. Internet, ASP.NET client vs. Windows Forms clients, TCP vs. HTTP, impersonation/delegation vs. trusted subsystem, and AD (domain credentials) vs. a custom user store.

WCF Security Application Scenarios
Intranet

• Intranet – Web to Remote WCF Using Transport Security (Trusted Subsystem TCP)
• Intranet – Web to Remote WCF Using Transport Security (Trusted Subsystem, HTTP)
• Intranet – Web to Remote WCF Using Transport Security (Original Caller, TCP)
• Intranet – Windows Forms to Remote WCF Using Transport Security (TCP)

Internet

• Internet – Web to Remote WCF Using Transport Security (Trusted Subsystem)
• Internet – Windows Forms Client Calling WCF Using Message Security

Note that if there's enough interest and time, we'll add a scenario that shows accessing an existing custom user store (i.e. you aren't using Membership.) 

My Related Posts

• patterns & practices WCF Security Application Scenarios
• patterns & practices WCF Security Guidance Now Available

If you know the underlying principles for security, you can be more effective in your security design.  While working on Improving Web Application Security: Threats and Countermeasures, my team focused on creating a durable set of security principles.  The challenge was to make the principles more useful.  It's one thing to know the principles, but another to turn it into action. 

Turning Insights Into Action

To make the principles more useful, we organized them using our Security Frame.  Our Security Frame is a set of actionable, relevant categories that shape your key engineering and deployment decisions.  With the Security Frame we could quickly find principles related to authentication, or authorization or input validation ... etc. 

Once we had these principles and this organizing frame, we could then evaluate technologies against it to find effective, principle-based techniques.  For example, when we analyzed doing input and data validation in ASP.NET, we focused on finding the best ways to constrain, reject, and sanitize input.  For constraining input, we focused on checking for length, range, format and type.  Using these strategies both shortened our learning curve and improved our results.

Core Security Principles

We started with a firm foundation of core security principles.  These influenced the rest of our security design principles.  Here's the core security principles we started with:

• Adopt the principle of least privilege - Processes that run script or execute code should run under a least privileged account to limit the potential damage that can be done if the process is compromised
• Use defense in depth.   Place check points within each of the layers and subsystems within your application. The check points are the gatekeepers that ensure that only authenticated and authorized users are able to access the next downstream layer.
• Don't trust user input.  Applications should thoroughly validate all user input before performing operations with that input. The validation may include filtering out special characters.
• Use secure defaults.   If your application demands features that force you to reduce or change default security settings, test the effects and understand the implications before making the change
• Don't rely on security by obscurity.   Trying to hide secrets by using misleading variable names or storing them in odd file locations does not provide security. In a game of hide-and-seek, it's better to use platform features or proven techniques for securing your data.
• Check at the gate.   Checking the client at the gate refers to authorizing the user at the first point of authentication (for example, within the Web application on the Web server), and determining which resources and operations (potentially provided by downstream services) the user should be allowed to access.
• Assume external systems are insecure.  If you don't own it, don't assume security is taken care of for you.
• Reduce Surface Area   Avoid exposing information that is not required. By doing so, you are potentially opening doors that can lead to additional vulnerabilities. Also, handle errors gracefully; don't expose any more information than is required when returning an error message to the end user.
• Fail to a secure mode.   your application fails, make sure it does not leave sensitive data unprotected. Also, do not provide too much detail in error messages; meaning don't include details that could help an attacker exploit a vulnerability in your application. Write detailed error information to the Windows event log.
• Security is a concern across all of your application layers and tiers.   Remember you are only as secure as your weakest link.
• If you don't use it, disable it.   You can remove potential points of attack by disabling modules and components that your application does not require. For example, if your application doesn't use output caching, then you should disable the ASP.NET output cache module. If a future security vulnerability is found in the module, your application is not threatened.

Frame for Organizing Security Design Principles

Rather than a laundry list of security principles, you can use the Security Frame as a way to organize and share security principles:

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

Auditing and Logging

Here's our security design principles for auditing and logging:

• Audit and log access across application tiers.   Audit and log access across the tiers of your application for non-repudiation. Use a combination of application-level logging and platform auditing features, such as Windows, IIS, and SQL Server auditing.
• Consider identity flow.   You have two basic choices. You can flow the caller's identity at the operating system level or you can flow the caller's identity at the application level and use trusted identities to access back-end resources.
• Log key events.   The types of events that should be logged include successful and failed logon attempts, modification of data, retrieval of data, network communications, and administrative functions such as the enabling or disabling of logging. Logs should include the time of the event, the location of the event including the machine name, the identity of the current user, the identity of the process initiating the event, and a detailed description of the event
• Protect log files.   Protect log files using  access control lists and restrict access to the log files. This makes it more difficult for attackers to tamper with log files to cover their tracks. Minimize the number of individuals who can manipulate the log files. Authorize access only to highly trusted accounts such as administrators.
• Back up and analyze log files regularly.   There's no point in logging activity if the log files are never analyzed. Log files should be removed from production servers on a regular basis. The frequency of removal is dependent upon your application's level of activity. Your design should consider the way that log files will be retrieved and moved to offline servers for analysis. Any additional protocols and ports opened on the Web server for this purpose must be securely locked down.

Authentication

Here's our security design principles for authentication:

• Separate public and restricted areas.   A public area of your site can be accessed by any user anonymously. Restricted areas can be accessed only by specific individuals and the users must authenticate with the site.  By partitioning your site into public and restricted access areas, you can apply separate authentication and authorization rules across the site.
• Use account lockout policies for end-user accounts.   Disable end-user accounts or write events to a log after a set number of failed logon attempts. With Forms authentication, these policies are the responsibility of the application and must be incorporated into the application design. Be careful that account lockout policies cannot be abused in denial of service attacks.
• Support password expiration periods. Passwords should not be static and should be changed as part of routine password maintenance through password expiration periods. Consider providing this type of facility during application design.
• Be able to disable accounts.  If the system is compromised, being able to deliberately invalidate credentials or disable accounts can prevent additional attacks.
• Do not store passwords in user stores.  If you must verify passwords, it is not necessary to actually store the passwords. Instead, store a one way hash value and then re-compute the hash using the user-supplied passwords. To mitigate the threat of dictionary attacks against the user store, use strong passwords and incorporate a random salt value with the password.
• Require strong passwords.   Do not make it easy for attackers to crack passwords. There are many guidelines available, but a general practice is to require a minimum of eight characters and a mixture of uppercase and lowercase characters, numbers, and special characters. Whether you are using the platform to enforce these for you, or you are developing your own validation, this step is necessary to counter brute-force attacks where an attacker tries to crack a password through systematic trial and error. Use regular expressions to help with strong password validation.
• Do not send passwords over the wire in plaintext.   Plaintext passwords sent over a network are vulnerable to eavesdropping. To address this threat, secure the communication channel, for example, by using SSL to encrypt the traffic.
• Protect authentication cookies.   A stolen authentication cookie is a stolen logon. Protect authentication tickets using encryption and secure communication channels. Also limit the time interval in which an authentication ticket remains valid, to counter the spoofing threat that can result from replay attacks, where an attacker captures the cookie and uses it to gain illicit access to your site. Reducing the cookie timeout does not prevent replay attacks but it does limit the amount of time the attacker has to access the site using the stolen cookie.

Authorization

Here's our security design principles for authorization:

• Use multiple gatekeepers.   By combining multiple gatekeepers across layers and tiers, you can develop an effective authorization strategy.
• Restrict user access to system-level resources.   System level resources include files, folders, registry keys, Active Directory objects, database objects, event logs, and so on. Use access control lists to restrict which users can access what resources and the types of operations that they can perform. Pay particular attention to anonymous Internet user accounts; lock these down on resources that explicitly deny access to anonymous users.
• Consider authorization granularity.   There are three common authorization models, each with varying degrees of granularity and scalability: (1.) the impersonation model providing per end user authorization granularity, (2.) the trusted subsystem model uses the application's process identity for resource access, and (3.) the hybrid model uses multiple trusted service identities for downstream resource access. The most granular approach relies on impersonation. The impersonation model provides per end user authorization granularity.

Configuration Management

Here's our security design principles for configuration management:

• Protect your administration interfaces.   It is important that configuration management functionality is accessible only by authorized operators and administrators. A key part is to enforce strong authentication over your administration interfaces, for example, by using certificates. If possible, limit or avoid the use of remote administration and require administrators to log on locally. If you need to support remote administration, use encrypted channels, for example, with SSL or VPN technology, because of the sensitive nature of the data passed over administrative interfaces.
• Protect your configuration store. Text-based configuration files, the registry, and databases are common options for storing application configuration data. If possible, avoid using configuration files in the application's Web space to prevent possible server configuration vulnerabilities resulting in the download of configuration files. Whatever approach you use, secure access to the configuration store, for example, by using access control lists or database permissions. Also avoid storing plaintext secrets such as database connection strings or account credentials. Secure these items using encryption and then restrict access to the registry key, file, or table that contains the encrypted data.
• Maintain separate administration privileges.   If the functionality supported by the features of your application's configuration management varies based on the role of the administrator, consider authorizing each role separately by using role-based authorization. For example, the person responsible for updating a site's static content should not necessarily be allowed to change a customer's credit limit.
• Use least privileged process and service accounts.  An important aspect of your application's configuration is the process accounts used to run the Web server process and the service accounts used to access downstream resources and systems. Make sure these accounts are set up as least privileged. If an attacker manages to take control of a process, the process identity should have very restricted access to the file system and other system resources to limit the damage that can be done.

Cryptography

Here's our security design principles for cryptography:

• Do not develop your own cryptography.   Cryptographic algorithms and routines are notoriously difficult to develop successfully. As a result, you should use the tried and tested cryptographic services provided by the platform.
• Keep unencrypted data close to the algorithm.   When passing plaintext to an algorithm, do not obtain the data until you are ready to use it, and store it in as few variables as possible.
• Use the correct algorithm and correct key size.   It is important to make sure you choose the right algorithm for the right job and to make sure you use a key size that provides a sufficient degree of security. Larger key sizes generally increase security. The following list summarizes the major algorithms together with the key sizes that each uses: Data Encryption Standard (DES) 64-bit key (8 bytes) , TripleDES 128-bit key or 192-bit key (16 or 24 bytes) , Rijndael 128–256 bit keys (16–32 bytes) , RSA 384–16,384 bit keys (48–2,048 bytes) .  For large data encryption, use the TripleDES symmetric encryption algorithm. For slower and stronger encryption of large data, use Rijndael. To encrypt data that is to be stored for short periods of time, you can consider using a faster but weaker algorithm such as DES. For digital signatures, use Rivest, Shamir, and Adleman (RSA) or Digital Signature Algorithm (DSA). For hashing, use the Secure Hash Algorithm (SHA)1.0. For keyed hashes, use the Hash-based Message Authentication Code (HMAC) SHA1.0.
• Protect your encryption keys.   An encryption key is a secret number used as input to the encryption and decryption processes. For encrypted data to remain secure, the key must be protected. If an attacker compromises the decryption key, your encrypted data is no longer secure.  Avoid key management when you can, and when you do need to store encryption keys, cycle your keys periodically.

Exception Management

Here's our security design principles for exception management:

• Do not leak information to the client.   In the event of a failure, do not expose information that could lead to information disclosure. For example, do not expose stack trace details that include function names and line numbers in the case of debug builds (which should not be used on production servers). Instead, return generic error messages to the client.
• Log detailed error messages.   Send detailed error messages to the error log. Send minimal information to the consumer of your service or application, such as a generic error message and custom error log ID that can subsequently be mapped to detailed message in the event logs. Make sure that you do not log passwords or other sensitive data.
• Catch exceptions.  Use structured exception handling and catch exception conditions. Doing so avoids leaving your application in an inconsistent state that may lead to information disclosure. It also helps protect your application from denial of service attacks. Decide how to propagate exceptions internally in your application and give special consideration to what occurs at the application boundary.

Input / Data Validation

Here's our security design principles for input and data validation:

• Assume all input is malicious.  Input validation starts with a fundamental supposition that all input is malicious until proven otherwise. Whether input comes from a service, a file share, a user, or a database, validate your input if the source is outside your trust boundary.
• Centralize your approach.  Make your input validation strategy a core element of your application design. Consider a centralized approach to validation, for example, by using common validation and filtering code in shared libraries. This ensures that validation rules are applied consistently. It also reduces development effort and helps with future maintenance.  In many cases, individual fields require specific validation, for example, with specifically developed regular expressions. However, you can frequently factor out common routines to validate regularly used fields such as e-mail addresses, titles, names, postal addresses including ZIP or postal codes, and so on.
• Do not rely on client-side validation.   Server-side code should perform its own validation. What if an attacker bypasses your client, or shuts off your client-side script routines, for example, by disabling JavaScript? Use client-side validation to help reduce the number of round trips to the server but do not rely on it for security. This is an example of defense in depth.
• Be careful with canonicalization issues.   Data in canonical form is in its most standard or simplest form. Canonicalization is the process of converting data to its canonical form. File paths and URLs are particularly prone to canonicalization issues and many well-known exploits are a direct result of canonicalization bugs.  You should generally try to avoid designing applications that accept input file names from the user to avoid canonicalization issues.
• Constrain, reject, and sanitize your input.   The preferred approach to validating input is to constrain what you allow from the beginning. It is much easier to validate data for known valid types, patterns, and ranges than it is to validate data by looking for known bad characters. When you design your application, you know what your application expects. The range of valid data is generally a more finite set than potentially malicious input. However, for defense in depth you may also want to reject known bad input and then sanitize the input.
• Encrypt sensitive cookie state.  Cookies may contain sensitive data such as session identifiers or data that is used as part of the server-side authorization process. To protect this type of data from unauthorized manipulation, use cryptography to encrypt the contents of the cookie.
• Make sure that users do not bypass your checks.   Make sure that users do not bypass your checks by manipulating parameters. URL parameters can be manipulated by end users through the browser address text box. For example, the URL http://www.<YourSite>/<YourApp>/sessionId=10 has a value of 10 that can be changed to some random number to receive different output. Make sure that you check this in server-side code, not in client-side JavaScript, which can be disabled in the browser.
• Validate all values sent from the client.   Restrict the fields that the user can enter and modify and validate all values coming from the client. If you have predefined values in your form fields, users can change them and post them back to receive different results. Permit only known good values wherever possible. For example, if the input field is for a state, only inputs matching a state postal code should be permitted.
• Do not trust HTTP header information.   HTTP headers are sent at the start of HTTP requests and HTTP responses. Your Web application should make sure it does not base any security decision on information in the HTTP headers because it is easy for an attacker to manipulate the header. For example, the referrer field in the header contains the URL of the Web page from where the request originated. Do not make any security decisions based on the value of the referrer field, for example, to check whether the request originated from a page generated by the Web application, because the field is easily falsified.

Sensitive Data

Here's our security design principles for sensitive data:

• Do not store secrets if you can avoid it.   Storing secrets in software in a completely secure fashion is not possible. An administrator, who has physical access to the server, can access the data. For example, it is not necessary to store a secret when all you need to do is verify whether a user knows the secret. In this case, you can store a hash value that represents the secret and compute the hash using the user-supplied value to verify whether the user knows the secret.
• Do not store secrets in code.  Do not hard code secrets in code. Even if the source code is not exposed on the Web server, it is possible to extract string constants from compiled executable files. A configuration vulnerability may allow an attacker to retrieve the executable.
• Do not store database connections, passwords, or keys in plaintext.   Avoid storing secrets such as database connection strings, passwords, and keys in plaintext. Use encryption and store encrypted strings.
• Avoid storing secrets in the Local Security Authority (LSA).   Avoid the LSA because your application requires administration privileges to access it. This violates the core security principle of running with least privilege. Also, the LSA can store secrets in only a restricted number of slots. A better approach is to use DPAPI.
• Use Data Protection API (DPAPI) for encrypting secrets.   To store secrets such as database connection strings or service account credentials, use DPAPI. The main advantage to using DPAPI is that the platform system manages the encryption/decryption key and it is not an issue for the application. The key is either tied to a Windows user account or to a specific computer, depending on flags passed to the DPAPI functions.   DPAPI is best suited for encrypting information that can be manually recreated when the master keys are lost, for example, because a damaged server requires an operating system re-install. Data that cannot be recovered because you do not know the plaintext value, for example, customer credit card details, require an alternate approach that uses traditional symmetric key-based cryptography such as the use of triple-DES.
• Retrieve sensitive data on demand.   The preferred approach is to retrieve sensitive data on demand when it is needed instead of persisting or caching it in memory. For example, retrieve the encrypted secret when it is needed, decrypt it, use it, and then clear the memory (variable) used to hold the plaintext secret. If performance becomes an issue, consider caching along with potential security implications.
• Encrypt the data or secure the communication channel.   If you are sending sensitive data over the network to the client, encrypt the data or secure the channel. A common practice is to use SSL between the client and Web server. Between servers, an increasingly common approach is to use IPSec. For securing sensitive data that flows through several intermediaries, for example, Web service Simple Object Access Protocol (SOAP) messages, use message level encryption.
• Do not store sensitive data in persistent cookies.  Avoid storing sensitive data in persistent cookies. If you store plaintext data, the end user is able to see and modify the data. If you encrypt the data, key management can be a problem. For example, if the key used to encrypt the data in the cookie has expired and been recycled, the new key cannot decrypt the persistent cookie passed by the browser from the client.
• Do not pass sensitive data using the HTTP-GET protocol.   You should avoid storing sensitive data using the HTTP-GET protocol because the protocol uses query strings to pass data. Sensitive data cannot be secured using query strings and query strings are often logged by the server

Session Management

Here's our security design principles for session management:

• Use SSL to protect session authentication cookies.   Do not pass authentication cookies over HTTP connections. Set the secure cookie property within authentication cookies, which instructs browsers to send cookies back to the server only over HTTPS connections.
• Encrypt the contents of the authentication cookies.   Encrypt the cookie contents even if you are using SSL. This prevents an attacker viewing or modifying the cookie if he manages to steal it through an XSS attack. In this event, the attacker could still use the cookie to access your application, but only while the cookie remains valid.
• Limit session lifetime.   Reduce the lifetime of sessions to mitigate the risk of session hijacking and replay attacks. The shorter the session, the less time an attacker has to capture a session cookie and use it to access your application.
• Protect session state from unauthorized access.   Consider how session state is to be stored. For optimum performance, you can store session state in the Web application's process address space. However, this approach has limited scalability and implications in Web farm scenarios, where requests from the same user cannot be guaranteed to be handled by the same server. You should secure the network link from the Web application to state store using IPSec or SSL to mitigate the risk of eavesdropping. Also consider how the Web application is to be authenticated by the state store. Use Windows authentication where possible to avoid passing plaintext authentication credentials across the network and to benefit from secure Windows account policies.

Using the Security Design Principles

This is simply a baseline set of principles so that you don't have to start from scratch.  You can build on this set and tailor for your specific context.  I find that while having a set of principles helps, that you can't stop there.  To share the knowledge and help others use the information, it's important to encapsulate the principles in patterns as well as show concrete examples and create precise, actionable guidelines for developers.  Personally, I've found Wikis to be the most effective way to share and manage the information.

Additional Resources

• patterns & practices Improving Web Application Security (MSDN)
• patterns & practices Security Engineering Explained (MSDN)
• Security Design Principles (Guidance Share)

My Related Posts

• Security Frame
• How To Use Guidance Explorer to Do a Security Code Inspection
• Guidance Share Sweep

Dr. Stephen Covey presented at Microsoft today.  It’s one thing to know the information; it’s another to experience the delivery live. 

This post is a bit longer than usual, but hey, it’s not every day that Covey is in the house.  Here are some of my highlights from today’s session.

The Lighthouse Story
Covey opened with a story of Captain Horatio Hornblower.  As the story goes, one night at sea, Horatio awakens to find that a ship is in his sea-lane about 20 miles away and refuses to move.  Horatio commands the other ship to move starboard, 20 degrees at once.  The other ship refuses and tells Horatio that he should move his ship starboard, 20 degrees at once.  Next, Horatio tries to pull rank and size on the other ship, stating that he’s a captain and that he’s on a large battle ship.  The other ship replies, and it turns out it’s not actually a ship, but a lighthouse.

The take away from the story is, there are lighthouse principles.  You don’t break them.  You only break yourself against them.  Don’t break yourself against lighthouse principles.

Values and Principles
Covey distinguished values from principles:

• Values drive behavior.
• Principles drive the consequences of behavior.

The key take aways are:

• If you take the short cuts in life, you pay the price of confidence and trust.
• Build your personal value system on principles.

Personal Mission Statement
Covey asked us whether we had personal mission statements?  Some folks raised their hands.  He then asked us how many have them written down.  A lot less kept their hands raised.  I kept my hand raised because I happen to have my personal mission statement written down.  My personal mission statement is, “To find the best way for any person to succeed in any situation.”    I tie this back at work, where I try to help customers be as effective as possible, building on the Microsoft platform.

Family Mission Statement
Covey then challenged the audience whether we had mission statements for our families?  That one made me think.  He then challenged, if you asked your loved ones, would they know it?  Now there’s a good test! 

He challenged us to go home and ask, “What’s the purpose of our family?”  He warned us though, that our families will know that we’ve been seminar’ed!

Write and Visualize to Imprint on Your Subconscious
Covey reminded us that writing down your mission imprints it in the subconscious mind.  He added that visualizing also imprints on the sub-concsious mind. 

The take away is that you should write and visualize your mission statements.

Keys to a Mission Statement
Covey put it succinctly that a good mission statement is:

• Memorizable.
• Short.
• Follows the natural laws of principles.

Why a Mission Statement
Covey told us that the power of a mission statement is that it governs every other decision.

Sean Covey
Covey introduced his son, Sean Covey.  Sean wrote The 7 Habits of Highly Effective Teenagers and The 6 Most Important Decisions You Will Ever Make.   When Covey introduced Sean, he also mentioned a 49th grand-child on the way.  49 … WOW!  That’s quite the impressive team.

Point to True North
Covey had us close our eyes and point to true North.  When we opened our eyes, it was obvious there was little consistency.  He said he gets similar results when he asks any department, group, or team – “what’s your purpose?”

Urgent But Not Important
Covey asked us how many struggle with work/life balance.  Many hands went up.  He then asked us what we think is the percentage of time we spend on things that are urgent, but not important. 

He said people often report they feel they spend 50% of their time on urgent, but not important tasks.  Why is that?  Covey stated it’s because everybody defines purpose differently.

Office Politics and Dysfunctional Activities
Covey asked us how much time people spend in office politics.    By office politics, he meant, reading the tea leaves, dealing with hidden agendas, fighting cross-group conflict, … etc.  The data says that 75% of people claim they spend 25% of their time on these things.  25% say that 50% of their time is spent in dysfunctional activities.  Urgency replaces important activities.

The key take away is that people feel they spend a lot of time on dysfunctional activities.

Six Metastasizing Cancers (Victimism)
Covey showed us a slide that listed what he called the Six Metastasizing Cancers:

• Criticizing
• Complaining
• Comparing
• Competing
• Contending
• Cynicism

The take away here is that these are ineffective behaviors and you end up acting like a victim.

Are You Utilized to Your Full Potential
Covey asked us whether we can use our full talent and capacity in our organization.   He then asked us whether we feel the pressure to produce more for less.   The point here was to emphasize how there’s a demand for greater results, but that we’re not necessarily utilized to our full potential.

It’s Not Behavior, It’s Not Attitude … It’s a Bad Map
Covey gave us a scenario where somebody gets a map of Seattle.  The problem is, the map maker made a mistake.  It’s not really a map of Seattle.  It’s a map of Oregon.  With this map, you can’t even make it out of the airport.  There isn’t one corresponding point.

Trying harder isn’t the answer.  If you double your speed, now you’re lost twice as fast.  Thinking negatively isn’t the problem.  Covey said some people might try to use a PMA (Positive Mental Attitude.)  Well, that doesn’t help either.  Now you’re all psyched up, but really you are just happy and contented in a lost state.

The take away here is that it’s not behavior and it’s not attitude.  It’s a bad map.

Self-Educating
Covey told us that we need to be self-educating.  School taught us how to learn, but we need to continue to learn.  He said we need to be willing to pay the price to be self-educating, which includes being systematic and disciplined.

Industrial Age vs. Knowledge Worker Age
Covey points out that 20 years ago, it was about goods and services.  Today, it’s about knowledge workers.

Expenses and Assets
Covey asked us what we are called in spreadsheets.   He said that in spreadsheet and financial accounting, people are called expenses and cost centers, while things like microphones, tools, and machines are called assets.  He said this is left-over from the industrial age.

Finding Your Voice
Covey asked how do you help people find their voice?  You ask them what are they good at?  What do they love doing?  What is your greatest unique contribution?

The key is finding a voice that meets a human need.

Inspiration Over Jackass Theory
The Jackass Theory refers to the carrot and the stick.  Covey asked us what kind of supervisor do you need when you have a job that you are passionate about and is using your talents and you feel you are appreciated.

People are volunteers.  You want them to contribute their greatest, unique contribution.

Keys to Effective Large Team
Covey outlined the keys for effective large teams::

• Psychologically committed.
• Accountable to the team / everybody.
• Culture of results.

One person may represent the group, but accountability is to the team versus the boss.  Accountability to the team versus an individual is a knowledge worker concept.

How To Find the Win / Win Performance Agreement
Covey suggested an approach for finding the Win/Win for teams and organizations in terms of performance:

1. Help them find their voice.
2. Find out what individuals are good at and like doing and serves the needs of the business.

When you have that, you have a win-win.  The key is to have a win/win performance agreement where it is mutually beneficial between the individual and the organization.  The individual should be able to use their full talent and passion (there voice.)

Information is the Knowledge Worker's Disinfectant
Covey mentioned that light is the greatest disinfectant in nature.  For the knowledge worker, it’s information.  For a knowledge worker to be effective in a team, they need information, they need the criteria for success and they need to be accountable to the group.

The Whole Person
According to Covey, the whole person includes four parts:

• Body
• Mind
• Heart
• Spirit

Control-Paradigm to a Whole Person Paradigm
Covey reminded us that today’s workforce is about directed autonomy.  You manage (things) that can’t choose.  You lead people.  People have the ability to choose.

The key take aways are:

• Today’s world is about breaking away from a control paradigm and shifting to one of directed autonomy.  
• Help people find their voice.
• You can’t buy the mind, body, heart, and spirit – they are volunteered. 
• Use all four parts of your nature.  If you take one away, then you’re treating a person as a “thing” that you control and manage.

Keeping Top Talent
Covey told us about how Admirals in the Pacific were losing people to better paying jobs.  There was an exception.  Covey got to meet the group that kept their top talent.  The keys to a committed group included:

• The culture was committed in hearts and minds.
• The job was fulfilling and meaningful.

Indian Talking Stick Communication
Covey shared a technique for improving empathic listening.  It’s the Indian Talking Stick:

• You give the stick to the other person first. 
• You don’t get the stick back until the other person feels they are understood.
• The purpose is not to agree, or disagree, but only to understand the speaker.

You don’t need to use an Indian talking stick.  You can use any object.  The value of the object is that you don’t get it back until the other person feels understood.

Industrial Age Concepts
Throughout the session, Covey made reference to some "industrial age concepts":

• People are an expense, tools and machines are assets.
• Supervision is an industrial age concept.
• One-on-one accountability to a boss.
• Comparison systems for the basis of collaboration.

Lighthouse Principles
Throughout the presentation, Covey referred to some lighthouse principles that govern behavior:

• Cultivate an abundance mentality.
• There are four parts to our nature: body, mind, heart, and spirit
• The whole is greater than the parts
• Develop integrity; avoid duplicity (Don’t say one thing, but do another and if you make a promise, keep it.)

Continuum of Communication
Covey showed us a continuum of communication that moves from hostility and transaction-based communication to transformation:

1. Hostility
2. Defensive Communication (Transaction)
3. Respectful Communication (Transaction)
4. Synergy, Third Alternative (Transformation)

Empathic Listening is the No. 1 Communication Skill
Covey stated that communication is the number one skill in life.  He went on to say that empathic listening is the number one communication skill.   Covey explained that empathic listening is listening within the other person’s frame of skills.   Listening empathically is listening with the other person’s frame of reference.  The key is to listen until the other person feels heard and understood. 

Empathic Listening Over Telling and Selling
A satisfied need, no longer motivates.  Covey used the example of air – it’s a satisfied need.  When the other person feels heard and understood, it’s more likely they will listen to you and that you can seek a better solution, that’s mutually beneficial.  You are no longer telling and selling.

Our Experience is the Lens We Use to Interpret Life
Covey showed the audience three pictures.   One half of the audience looked at the first picture.  Next, the other half of the audience looked at the second picture.  Then the full audience looked at a third slide which was a composite of the first two slides.  Depending on which of the pictures you saw first, influenced what you saw in this third picture.

The key take away here was that what you saw was influenced by your experience and that rather that impose your view, first understand the other person’s perspective – there’s a good chance, you’re both right! (This is a good case where the Indian Talking Stick could come in handy.)

Resolving Conflict By Finding the Third Alternative
Covey shared a technique for resolving conflict that works for him in 95% of the cases he runs into around the world.  Here’s the key steps:

1. Put up the two points.
2. Ask the question, “would you be willing to search for a solution that would be better than what either of us has proposed?”

The key here is to listen to the other person first and listen empathically.  The proactive part here is that you can choose to listen to the other person first (seek first to understand, then to be understood.)

Listening to Loved Ones
One of the audience members asked for advice on counseling a loved one.  Covey responded with the following solution:

1. Start by saying, “Honey, I have not spent the time to listen to you, all I’ve done is tell you and evaluate.”
2. Listen in depth; restate to their satisfaction. (Empathic listening)
3. After they feel understood, you ask, “Have I listened to you?  Are you willing to listen to me, as I have listened to you?”
4. Find a 3rd alternative.

The key here that Covey mentioned is that most people will not pay the price of listening empathically.

7 Habits of Highly Effective People
Covey shared a slide that framed out the seven habits of highly effective people in terms of private victory, public victory, dependence, independence, and interdependence.

1. Be proactive.
2. Begin with the end in mind.
3. Put first things first.
4. Think win-win.
5. Seek first to understand, then to be understood.
6. Synergize.
7. Sharpen the saw.

Habits 1,2,and 3 are the foundation for private victories and integrity.  Habits 4, 5, and 6 are the keys to public victories.

Peace of Conscience Over Peace of Mind
Covey made a distinction between peace of mind and peace of conscience.  He explained that integrity is more than honesty.  Integrity means that if you make a promise, you keep it.  If you’re honest, you might have peace of mind, but if you don’t have integrity, then you won’t have peace of conscience.  You have peace of conscience by avoiding duplicity.

Loyalty to the Absent
Covey made his point very simply – only talk about people as if they are there.  You can be critical, but speak as if they were there in front of you.  Don’t bad mouth them behind their back and then sweet talk them to their face.  This is a lack of integrity and creates deep duplicity inside you.  This inhibits your ability to have peace of conscience.

Use I Messages Over You Messages
Meet with the people you have a problem with directly.  Practice the following:

1. Let me listen to you first.
2. Use “I” messages vs. “you” messages.  I messages are “It’s my perception,” “in my experience,” … etc.  You messages are “you are …”

Genuine Happiness
Covey said the key to genuine happiness is to develop integrity.  The key to developing integrity is the first three habits (your Private Victories):

1. Be proactive
2. Begin with the end in mind
3. Put first things first.

Greek Philosophy of Influence
Covey shared the three parts of the Greek philosophy of influence:

1. Ethos – credibility, model trust.
2. Pathos – restate the point of view.  (Seek first to understand …)
3. Logos – Make your presentation. (… Then to be understood.)

You Are the Creative Force of Your Life
Covey challenged us to be a creative force:
1.     Get out of victimism – You’re not a victim of your circumstances.
2.    You are the creative force of your life.

Empathize first.  Grow your circle of influence.  Make tremendous impact.

The Most Important Thing You’ll Ever Do
Covey closed with a powerful message we could take away:

The most important thing you’ll ever do is in the four walls of your own home.

1. Develop personal / family mission statements and help others to do the same.
2. Develop empathic listening and help others to do the same.
3. Find our voices and help others find theirs. 

Personally, I want to make more use of the Indian Talking Stick Communication technique, particularly at some of my more vibrant meetings.

More Information

• Dr. Stephen Covey (Wikipedia)
• Stephen R. Covey's Blog
• Sean Covey (Wikipedia)
• Strange Meeting at Sea (The story of Captain Horatio Hornblower)

We published an updated set of our WCF Security application scenarios yesterday, as part of our patterns & practices WCF Security guidance project.   Application Scenarios are visual "blueprints" of skeletal solutions for end-to-end deployment scenarios.  Each application scenario includes a before and after look at working solutions.  While you still need to prototype and test for your scenario, this gives you potential solutions and paths at a glance, rather than starting from scratch.  It's a catalog of applications scenarios that you can look through and potentially find your match.

Intranet
Common Intranet patterns:

• Intranet – Web to Remote WCF Using Transport Security (Trusted Subsystem TCP)
• Intranet – Web to Remote WCF Using Transport Security (Trusted Subsystem, HTTP)
• Intranet – Web to Remote WCF Using Transport Security (Original Caller, TCP)
• Intranet – Windows Forms to Remote WCF Using Transport Security (TCP)

Internet
Common Internet patterns:

• Internet – Web to Remote WCF Using Transport Security (Trusted Subsystem)
• Internet – Web to Remote WCF Using Message Security (Original Caller)
• Internet – Windows Forms Client Calling WCF Using Message Security

One Size Does Not Fit All
We know that one size doesn't fit all, so we create a collection of application scenarios that you can quickly sort through and pattern match against your scenario.  It's like a visual menu at a restaurant.  The goal is to find a good fit against your parameters versus a perfect fit.  It gives you a baseline to start from.  They effectively let you preview solutions, before embarking on your journey.

How We Make Application Scenarios
First, we start by gathering all the deployment scenarios we can find from customers with working solutions.  We use our field, product support, product teams, subject matter experts, and customers.  We also check with our internal line of business application solutions.  While there's a lot of variations, we look for the common denominators.  There's only so many ways to physically deploy servers, so we start there.  We group potential solutions by big buckets. 

In order to make the solutions meaningful, we pick a focus.  For example, with WCF Security, key overarching decisions include authentication, authorization, and secure communication.  These decisions span the layers and tiers.  We also pay attention to factors that influence your decisions.  For example, your role stores and user stores are a big factor.  The tricky part is throwing out the details of customer specific solutions, while retaining the conceptual integrity that makes the solution useful.

Next, we create prototypes and we test the end-to-end scenarios in our lab.  We do a lot of whiteboarding during this stage for candidate solutions.  This is where we spend the bulk of our time, testing paths, finding surprises, and making things work.  It's one thing to know what's supposed to work; it's another to make it work in practice. 

From our working solution, we highlight the insights and actions within the Application Scenario so you can quickly prototype for your particular context.  We then share our candidate guidance modules on CodePlex, while we continue reviews across our review loops including field, PSS, customers, product team members, and subject matter experts.