patterns & practices Security Engineering

As part of our patterns & practices App Arch Guide 2.0 project, we're consolidating our information on our patterns & practices Security Engineering.  Our security engineering approach is simply a collection of security-focused techniques that we found to be effective.  One of the keys to the effectiveness is our security frame.   Our security frame is a collection of "hot spots" that organize principles, patterns, and practices, as well as anti-patterns.  We use the frame to perform security code and design inspections.  Here's a preview of our cheat sheet so far.

Security Overlay
This is our patterns & practices Security Overlay:

It simply shows a common set of activities that customers already do, and then we overlay a set of security techniques.

Summary of Key Activities in the Life Cycle 
Our patterns & practices Security Engineering approach extends these proven core activities to create security specific activities. These activities include:

• Security Objectives. Setting objectives helps you scope and prioritize your work by setting boundaries and constraints. Setting security objectives helps you identify where to start, how to proceed, and when you are done.
• Threat Modeling. Threat modeling is an engineering technique that can help you identify threats, attacks, vulnerabilities, and countermeasures that could affect your application. You can use threat modeling to shape your application's design, meet your company's security objectives, and reduce risk.
• Security Design Guidelines. Creating design guidelines is a common practice at the start of an application project to guide development and share knowledge across the team. Effective design guidelines for security organize security principles, practices, and patterns by actionable categories.
• Security Design Inspection. Security design inspections are an effective way to identify problems in your application design. By using pattern-based categories and a question-driven approach, you simplify evaluating your design against root cause security issues.
• Security Code Inspection. Many security defects are found during code reviews. Analyzing code for security defects includes knowing what to look for and how to look for it. Security code inspections optimize inspecting code for common security issues.
  Security Testing. Use a risk-based approach and use the output from the threat modeling activity to help establish the scope of your testing activities and define your test plans.
• Security Deployment Inspection. When you deploy your application during your build process or staging process, you have an opportunity to evaluate runtime characteristics of your application in the context of your infrastructure. Deployment reviews for security focus on evaluating your security design and configuration of your application, host, and network.

Security Frame
Security frames define a set of patterns-based categories that can organize repeatable problems and solutions. You can use these categories to divide your application architecture for further analysis and to help identify application vulnerabilities. The categories within the frame represent the critical areas where mistakes are most often made.

Category	Description
Auditing and Logging	Who did what and when?  Auditing and logging refer to how your application records security-related events.
Authentication	Who are you?  Authentication is the process where an entity proves the identify of another entity, typically through credentials, such as a user name and password.
Authorization	What can you do?  Authorization is how your application provides access controls for resources and operations.
Configuration Management	Who does your application run as?  Which databases does it connect to?  How is your application administered?  How are these settings protected?  Configuration management refers to how your application handles these operations and issues.
Cryptography	How are you handling 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?  Cryptography refers to how your application enforces confidentiality and integrity.
Exception Management	When a method call in your application fails, what does your application do?  How much do you reveal?  Do you return friendly information to end users?  Do you pass valuable exception information back to the caller?  Does your application fail gracefully?
Input and Data Validation	How do you know that the input your application receives is valid and safe?  Input validation refers to how your application filters, scrubs, or rejects input before additional processing.  Consider constraining input through entry points and encoding output through exit points.  Do you trust data sources such as databases and file shares?
Sensitive data	How does your application handle 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.
Session Management	How does your application handle and protect user sessions?  A session refers to a session of related interactions between a user and your Web application.

Architecture and Design Issues
Use the diagram below to help you think about architecture and design issues in your application.

The key areas of concern for each application tier are:

• Browser. Authenticating users on the client. Protecting sensitive data on the wire.  Preventing common attacks such as parameter manipulation and session hijacking.
• Web Server. Validating untrusted input. Exception handling. Authorizing your users. Securing the configuration.
• Application Server. Authenticating and Authorizing users. Auditing and logging. Protecting sensitive data on the wire. Securing configuration.
• Database Server. Protecting sensitive data in the database. Securing configuration. Locking down database users.

Design Guidelines
This table represents a set of secure design guidelines for application architects. Use this as a starting point for secure design and to improve security design inspections

Category	Guidelines
Auditing and Logging	Identify malicious behavior. Know what good traffic looks like. Audit and log activity through all of the application tiers. Secure access to log files. Back up and regularly analyze log files.
Authentication	Partition site by anonymous, identified, and authenticated area. Use strong passwords. Support password expiration periods and account disablement. Do not store credentials (use one-way hashes with salt). Encrypt communication channels to protect authentication tokens. Pass Forms authentication cookies only over HTTPS connections.
Authorization	Use least privileged accounts. Consider authorization granularity. Enforce separation of privileges. Restrict user access to system-level resources.
Configuration Management	Use least privileged process and service accounts. Do not store credentials in plaintext. Use strong authentication and authorization on administration interfaces. Do not use the LSA. Secure the communication channel for remote administration. Avoid storing sensitive data in the Web space.
Cryptography	Do not develop your own. Use tried and tested platform features. Keep unencrypted data close to the algorithm. Use the right algorithm and key size. Avoid key management (use DPAPI). Cycle your keys periodically. Store keys in a restricted location.
Exception Management	Use structured exception handling. Do not reveal sensitive application implementation details. Do not log private data such as passwords. Consider a centralized exception management framework.
Input and Data Validation	Do not trust input; consider centralized input validation. Do not rely on client-side validation. Be careful with canonicalization issues. Constrain, reject, and sanitize input. Validate for type, length, format, and range.
Parameter Manipulation	Encrypt sensitive cookie state. Do not trust fields that the client can manipulate (query strings, form fields, cookies, or HTTP headers). Validate all values sent from the client.
Sensitive Data	Avoid storing secrets. Encrypt sensitive data over the wire. Secure the communication channel. Provide strong access controls on sensitive data stores. Do not store sensitive data in persistent cookies. Do not pass sensitive data using the HTTP-GET protocol.
Session Management	Limit the session lifetime. Secure the channel. Encrypt the contents of authentication cookies. Protect session state from unauthorized access.

Patterns
Design patterns in this context refer to generic solutions that address commonly occurring application design problems.  Some of the patterns identified below are well known design patterns. Their use in certain scenarios enables better security as a secondary goal. Some of the main patterns that help improve security are summarized below:

• Brokered Authentication. Use brokered authentication where the application validates the credentials presented by the client, without the need for a direct relationship between the two parties. An authentication broker that both parties trust independently issues a security token to the client. The client can then present credentials, including the security token, to the application.
• Direct Authentication. Use direct authentication where the application acts as an authentication service to validate credentials from the client. The credentials, which include proof-of-possession that is based on shared secrets, are verified against an identity store.
• Roles-based authorization. Role-based authorization is used to associate clients and groups with the permissions that they need to perform particular functions or access resources. When a user or group is added to a role, the user or group automatically inherits the various security permissions.
• Resource-based authorization. Resource-based authorization is performed on a resource, depending on the type of the resource and the mechanism used to perform authorization. Resource-based authorization can be based on access control lists (ACLs) or URLs.
• Trusted Subsystem. The application acts as a trusted subsystem to access additional resources. It uses its own credentials instead of the user's credentials to access the resource. The application must perform appropriate authentication and authorization of all requests that enter the subsystem. Remote resources should also be able to verify that the midstream caller is a trusted subsystem and not an upstream user of the application that is trying to bypass access to the trusted subsystem.
• Impersonation and Delegation. The application uses original user’s credentials to access the resource. The application must perform appropriate authentication and authorization of all requests that enter the subsystem and then impersonation or delegation while accessing resources. Remote resources should also be able to verify that individual users are trusted to access the resource.
• Transfer Security. Sensitive data passed between layers or remote tiers should be encrypted and signed to ensure confidentiality and integrity of the data.
• Exception Shielding. Sanitize unsafe exceptions by replacing them with exceptions that are safe by design. Return only those exceptions to the client that have been sanitized or exceptions that are safe by design. Exceptions that are safe by design do not contain sensitive information in the exception message, and they do not contain a detailed stack trace, either of which might reveal sensitive information about the application’s inner workings.

Additional Resources

• Security Engineering Explained (MSDN)
• Security Engineering (GuidanceShare)

My Related Posts

• patterns & practices App Arch Guide 2.0 Project
• App Arch Meta-Frame
• Layers and Tiers
• Layers and Components
• Services Layer
• Scenario Frames for Presentation, Business, Data and Services
• The Architecture Journal

Comments

• Anonymous
  September 11, 2008
  One of my colleagues on the patterns & practices team, David Hill , collected and distilled feedback

• Anonymous
  September 15, 2008
  As part of our patterns & practices App Arch Guide 2.0 project , we're consolidating our information

• Anonymous
  September 17, 2008
  As part of our patterns & practices App Arch Guide 2.0 project , we've created a set of application

• Anonymous
  October 11, 2008
  As part of our patterns & practices App Arch Guide 2.0 project , we've put together an arch frame.