Cheat Sheet – patterns & practices Security Engineering
J.D. Meier, Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher, Akshay Bogawat
- Understand the concepts of security engineering.
- Learn the key activities and patterns related to security engineering.
- Understand the common security architecture and design issues.
- Learn the key design principles for security engineering.
This cheat sheet summarizes the patterns & practices approach to Security Engineering, with the emphasis on architecture and design. To design, build and deploy secure applications, you must integrate security into you application development lifecycle and include specific security-related activities in your current software engineering processes. The key design-focused security engineering activities include identifying security objectives, applying security design guidelines, conducting security architecture and design reviews, and creating threat models. Each activity will improve the security of your application; for best results you should implement them all, but you can incrementally adopt any of these activities as you see fit.
Figure 1 shows how security engineering topics fit with the core activities of application design.
Figure 1 - Security engineering topics as part of the core architectural design activities.
Summary of Key Activities in the Life Cycle
The security engineering approach extends the proven core activities shown in the previous section to define security-specific activities. These activities ensure that all aspects of security are tested, and that sufficient considerations are made for deployment. The core activities you should consider performing include the following:
- Security Objectives. Setting objectives helps you to 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. You should think of security objectives with respect to the confidentiality, integrity, and availability of your data and application.
- Threat Modeling. Threat modeling is an engineering technique that can help you to 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. Threat modeling is an iterative process and should be used throughout the application lifecycle as and when new environmental facts are seen.
- 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 into actionable categories. Using tried and tested design principles to identify the critical areas where mistakes are often made.
- 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 evaluation of your design against root-cause security issues. You should review the application’s design in relation to the target deployment environment and associated security policies.
- Security Code Inspection. Many security defects are found during code reviews. Code analysis requirements for locating security defects include knowing what to look for, and how to look for it. Security code inspections optimize the task of inspecting code to detect common security issues.
- Security Testing. Use of a risk-based approach and the output from threat modeling activities to help establish the scope of your testing activities and definition of 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 the configuration of your application, host, and network.
Security frames define a set of pattern-based categories that organize repeatable problems and solutions. You can use these categories to divide your application architecture for further analysis, and to help you identify application vulnerabilities. The categories within the frame represent the critical areas where mistakes are most often made.
|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 identity of another entity, typically through credentials, such as a user name and password. |
|Authorization ||What can you do? Authorization refers to 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 information 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? Exception management refers to how you handle exceptions within your application. |
|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? Does your application protect confidential user and application 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
To apply the security frame to your application, it is useful to think about each category as it applies to your application scenarios and its specific deployment. For example, the Figure 2 shows how you could analyze security architecture and design issues for a typical Web application.
Figure 2 - A typical Web application security architecture.
Separate your security concerns by application tier to get a clearer view of attack points, potential weaknesses and mitigations. For example, the key areas of concern for each application tier in the diagram above 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 un-trusted 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.
- Data Server. Protecting sensitive data in the database. Securing configuration. Locking down database users.
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.
|Auditing and Logging ||Identify malicious behavior. |
| ||Know what good network 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. |
| ||Do not log sensitive data. |
|Authentication ||Partition your application or Web site based on the set of permissions required to access. |
| ||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. |
|Authorization ||Use least privileged accounts. |
| ||Consider using granular authorization mechanisms. |
| ||Enforce separation of privileges. |
| ||Restrict user access to system-level resources. |
|Configuration Management ||Use least privileged process and service accounts. |
| ||Do not store credentials or connection strings in plain text. |
| ||Use strong authentication and authorization on administration interfaces. |
| ||Do not use the Local Security Authority (LSA). |
| ||Secure any communication channels used for remote administration. |
|Cryptography ||Do not develop your own cryptography, use platform supplied cryptographic routines. |
| ||Minimize the opportunity to steal sensitive data by reducing the amount of time it remains un-encrypted, and clearing it after use. |
| ||Use the right algorithm and key size for your scenario. |
| ||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. |
| ||Use a global exception handler to catch unhandled exceptions. |
|Input and Data Validation ||Do not trust any input. |
| ||Do not trust any data that the client can manipulate. |
| ||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. |
| ||Echo input back to the user after validating and/or encoding the data |
|Parameter Manipulation ||Encrypt sensitive cookie state. |
| ||Do not trust fields (query strings, form fields, cookies, or HTTP headers) that the client can manipulate. |
| ||Validate all values sent from the client. |
| ||Use HttpOnly cookies. |
|Sensitive Data ||Avoid storing secrets. |
| ||Encrypt sensitive data passing over the network. |
| ||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. |
| ||Avoid storing sensitive data in sessions. |
Design patterns in the context of security engineering 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. The most commonly used patterns that help to 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 independently trust 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. Use role-based authorization 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 security permissions defined for that role.
- Resource-based authorization. Use resource-based authorization to authorize direct access to a resource. Resource-based authorization can be based on access control lists (ACLs) or URLs.
- Trusted Subsystem. Use trusted subsystem model when you trust an upstream layer or tier to perform authentication and authorization. After the user is authenticated and authorized, pass system credentials to the downstream layers or tiers in order to access resources. Remote resources should also be able to verify that the midstream caller is a trusted subsystem, and is not an upstream user of the application trying to bypass authentication checks made by the trusted subsystem.
- Impersonation and Delegation. Use impersonation and delegation to pass the original user’s credentials to downstream layers or tiers in order to access resources. Impersonation is used to pass credentials to a local layer on the same machine; delegation is used to pass credentials to a remote tier on another machine.
- Transfer Security. Use transfer security to encrypt and sign sensitive data passed between layers or remote tiers. Encryption protects data from being stolen. Signing protects data from modification in transit and confirms the origin of the data.
- Exception Shielding. Use exception shielding to 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.
For more information on security engineering, see the following resources: