9
Design Considerations
In this chapter you will
• Examine how to design security into an application using core security concepts
• Learn the roles of confidentiality, integrity, and availability with respect to designing in information security principles
• Explore designing in security elements using authentication, authorization, and auditing
• Explore how to use secure design principles to improve application security
• Learn how interconnectivity provides opportunities to design in security elements
Designing an application is the beginning of implementing security into the final application. Using the information uncovered in the requirements phase, designers create the blueprint developers use to arrive at the final product. It is during this phase that the foundational elements to build the proper security functionality into the application are initiated. To determine which security elements are needed in the application, designers can use the information from the attack surface analysis and the threat model to determine the “what” and “where” elements. Knowledge of secure design principles can provide the “how” elements. Using this information in a comprehensive plan can provide developers with a targeted foundation that will greatly assist in creating a secure application.
Application of Methods to Address Core Security Concepts
In Chapter 1, we explored the basic principles of security. In this chapter, we will examine how to design in security by utilizing these concepts. The concepts of confidentiality, integrity, and availability, widely lauded as the key elements of information security, do not happen by accident—they must be designed into the application to be effective and to provide specific protections.
Confidentiality, Integrity, and Availability
The principles of confidentiality, integrity, and availability are commonly used in information security discussions. For these elements to be effective in an application, they need to be designed into the application during the design phase. This is done by using tools such as encryption, hashing, and recovery methods. Encryption can preserve confidentiality by making information unavailable to unauthorized parties. Integrity can be ensured through the use of hash codes. Designing in proper recovery methods provides for a more resilient application that can support higher availability.
Confidentiality
Confidentiality is the concept of preventing the disclosure of information to unauthorized parties. Keeping secrets secret is the core concept of confidentiality. One of the key elements in the design phase is determining what elements need to be kept secret. The threat model will identify those elements. The next aspect is to examine the state of the data that is to be kept confidential. If the data is at rest, then encryption can be used to restrict access to authorized users. If the data is in transit, then encryption can also be used, but the method of encryption may be based on the transport method. Data that needs to be kept confidential in use, i.e., encryption keys, will require special attention.
Once the elements are determined, the next part of the confidentiality equation is to determine who the authorized parties are. The concepts of authorization are covered later in this chapter.
Integrity
Integrity refers to protecting data from unauthorized alteration. Alterations can come in the form of changing a value or in deleting a value. Integrity builds upon confidentiality, for if data is to be altered or deleted, then it is probably also visible to the user account. Users can be authorized to view information, but not alter it, so integrity controls require an authorization scheme that controls update and delete operations.
Protecting integrity can be done through the use of access control mechanisms. Individual specific levels of access with respect to read, write, and delete can be defined. Applying controls is just a piece of the integrity puzzle. The other aspect involves determining whether data has been altered or not. In some cases, this is just as important, if not more so, as the access control part. To determine whether the information has been altered or not requires some form of control other than simple access control.
If there is a requirement to verify the integrity of a data element throughout its lifecycle, the cryptographic function of hashing can be used. Hash functions can determine if single or multiple bits of data change from the original form. The principle is simple: Take the original data, run it through a hash function, and record the result. At any subsequent time, running the current value of the data through the same hash function will produce a current digest value. If the two digest values match, then the data is unchanged. This can be for something small, such as a few bytes, to an entire file system—in all cases, the digest size is fixed based on the hash algorithm.
The design issue is how does one implement this functionality? When are hash digests calculated? How are the digests stored and transmitted by a separate channel to the party checking? Adding the necessary elements to allow hash-based checking of integrity requires the designing of the necessary apparatus for parties to be able to verify integrity. In some cases, like in Microsoft Update Service, this entire mechanism is designed into the transfer mechanism so that it is invisible to the end user. The design phase is where these decisions need to be made so that the coding phase can properly implement the desired behavior.
Availability
Availability is defined as a system being available to authorized users when appropriate. Numerous threats can affect the availability of a system. The threat model should provide significant information as to what aspects of a system need availability protected and what aspects are not sensitive. Designing the best defenses against availability issues depends upon the threat to availability. Backups can provide a form of protection, as can data replication. Failover to redundant systems can also be employed. The key is in determining the specifics of the availability need and expressing them in a requirement that is then designed into the system.
Authentication, Authorization, and Auditing
The functions of authentication and authorization are foundational elements of employing controls such as access control lists. Designing these elements into an application is one where decisions need to be made as to integration with existing—i.e., operating system–provided functionality—or designing and building a stand-alone system. Auditing or logging is another system functionality, essential to security, where a design decision is needed as to the level of integration with existing operating system functionality. In both of these situations, it might seem easier to build your own system, but the true functionality needed in most system environments comes from integration into the larger enterprise-level security system, and this means integration of authentication, authorization, and auditing functionality into the existing operating system functionality.
Authentication
Authentication is the process used to verify to the computer system or network that the individual is who they claim to be. It is a key element in the security of a system, for if this system is bypassed or spoofed, then all subsequent security decisions can be in error. One of the key design questions is the level of assurance needed with respect to authentication. If an application is web-based, where users need to log in to establish their identity, then the design and securing of this information becomes an important part of the security equation. Authentication data is highly valuable data to an attacker and needs to be protected. This shows the interconnected nature of security, authentication, and confidentiality issues, as well as many others.
Authentication systems are complex, and the difficulty in designing and implementing them can be a daunting task. Whenever possible, it is best to leave authentication to established systems, such as the operating system. This makes it easier to integrate with existing operational security systems, and most operating system (OS) authentication systems are well tested and vetted. If the OS method is not appropriate, such as in web app login systems, then adherence to proper security design patterns for authentication systems is essential.
Authorization
After the authentication system identifies a user to a system, the authorization system takes over and applies the predetermined access levels to the user. As with authentication, authorization systems can be complex and difficult to implement correctly. For elements that can be covered by the operating system authorization system, i.e., access control lists for critical files and resources, these built-in and integrated systems should be utilized. If custom authorization elements are needed, they must be carefully designed using proper security design patterns for authorization systems.
Accounting (Audit)
Accounting is the function of measuring specific IT activities. This is typically done through the logging of crucial data elements of an activity as it occurs. The key elements in the design phase are the determination of what crucial elements should be logged and under what circumstances. Several sources of information can be used for determining what to log and when. The simplest rule is to include error trapping in every module and log what developers would need to understand the source of the problem. Caution should be exercised in the logging of data associated with records in the system. Data records could contain sensitive information that should be protected and not exposed in logs. Should sensitive data need to be logged, then encryption of the data is needed to protect the confidentiality requirements.
 | NOTE When logging information associated with a failure or error, care must be taken to not disclose any sensitive information in logs. This includes elements such as personally identifiable information (PII) and programmatic elements such as paths and filenames. |
Secure Design Principles
Implementing secure design principles requires specific design elements to be employed. Using the information from the attack surface analysis and the threat model, designers can pinpoint the places where specific design elements can be employed to achieve the desired security objectives. Security controls can be chosen based on the design to implement the desired levels of protection per security requirements. This can include controls to ensure confidentiality, integrity, and availability.
Secure Design Principles
The following are secure design principles that are employed to achieve application security:
| Good Enough Security | Economy of Mechanism |
| Least Privilege | Least Common Mechanism |
| Defense in Depth | Psychological Acceptability |
| Separation of Duties | Leverage Existing Components |
| Fail Safe | Weakest Link |
| Complete Mediation | Single Point of Failure |
| Open Design |
Good Enough Security
When designing in security aspects of an application, care should be exercised to ensure that the security elements are in response to the actual risk associated with the potential vulnerability. Designing excess security elements is a waste of resources. Underprotecting the application increases the risk. The challenge is in determining the correct level of security functionality. Elements of the threat model and attack surface analysis can provide guidance as to the level of risk. Documenting the level and purpose of security functions will assist the development team in creating an appropriate and desired level of security.
Least Privilege
One of the most fundamental approaches to security is least privilege. Least privilege should be utilized whenever possible as a preventative measure. Embracing designs with least privilege creates a natural set of defenses should unexpected errors happen. Least privilege, by definition, is sufficient privilege, and this should be a design standard. Excess privilege represents potentially excess risk when vulnerabilities are exploited.
Separation of Duties
Separation of duties must be designed into a system. Software components can be designed to enforce separation of duties when they require multiple conditions to be met before a task is considered complete. These multiple conditions can then be managed separately to enforce the checks and balances required by the system. In designing the system, designers also impact the method of operation of the system.
As with all other design choices, the details are recorded as part of the threat model. This acts as the communication method between all members of the development effort. Designing in operational elements such as separation of duties still requires additional work to happen through the development process, and the threat model can communicate the expectations of later development activities in this regard.
Defense in Depth
Defense in depth is one of the oldest security principles. If one defense is good, multiple overlapping defenses are better. The threat model document will contain information where overlapping defenses should be implemented. Designing in layers as part of the security architecture can work to mitigate a wider range of threats in a more efficient manner.
| | NOTE It’s not that I’m assuming your code will fail. It’s that I’m assuming all code can fail, including mine. You are not a special case. – Dan Kaminsky, security guru |
Because every piece of software can be compromised or bypassed in some way, it is incumbent on the design team to recognize this and create defenses that can mitigate specific threats. Although all software, including the mitigating defenses, can fail, the end result is to raise the difficulty level and limit the risk associated with individual failures.
Designing a series of layered defense elements across an application provides for an efficient defense. For layers to be effective, they should be dissimilar in nature so that if an adversary makes it past one layer, a separate layer may still be effective in maintaining the system in a secure state. An example is the coupling of encryption and access control methods to provide multiple layers that are diverse in their protection nature and yet both can provide confidentiality.
Fail Safe
As mentioned in the exception management section, all systems will experience failures. The fail-safe design principle refers to the fact that when a system experiences a failure, it should fail to a safe state. When designing elements of an application, one should consider what happens when a particular element fails. When a system enters a failure state, the attributes associated with security, confidentiality, integrity, and availability need to be appropriately maintained.
Failure is something that every system will experience. One of the design elements that should be considered is how the individual failures affect overall operations. Ensuring that the design includes elements to degrade gracefully and return to normal operation through the shortest path assists in maintaining the resilience of the system. For example, if a system cannot complete a connection to a database, when the attempt times out, how does the system react? Does it automatically retry, and if so, is there a mechanism to prevent a lockup when the failure continually repeats?
Economy of Mechanism
The terms security and complexity are often at odds with each other. This is because the more complex something is, the harder it is to understand, and you cannot truly secure something if you do not understand it. During the design phase of the project, it is important to emphasize simplicity. Smaller and simpler is easier to secure. Designs that are easy to understand, easy to implement, and well documented will lead to more secure applications.
If an application is going to do a specific type of function—for example, gather standard information from a database—and this function repeats throughout the system, then designing a standard method and reusing it improves system stability. As systems tend to grow and evolve over time, it is important to design in extensibility. Applications should be designed to be simple to troubleshoot, simple to expand, simple to use, and simple to administer.
Complete Mediation
Systems should be designed so that if the authorization system is ever circumvented, the damage is limited to immediate requests. Whenever sensitive operations are to be performed, it is important to perform authorization checks. Assuming that permissions are appropriate is just that—an assumption—and failures can occur. For instance, if a routine is to permit managers to change a key value in a database, then assuming that the party calling the routine is a manager can result in failures. Verifying that the party has the requisite authorization as part of the function is an example of complete mediation. Designing this level of security into a system should be a standard design practice for all applications.
Open Design
Part of the software development process includes multiple parties doing different tasks that in the end create a functioning piece of software. Over time, the software will be updated and improved, which is another round of the development process. For all of this work to be properly coordinated, open communication needs to occur. Having designs that are open and understandable will prevent activities later in the development process that will weaken or bypass security efforts.
Least Common Mechanism
The concept of least common mechanism is constructed to prevent inadvertent security failures. Designing a system where multiple processes share a common mechanism can lead to a potential information pathway between users or processes. The concepts of least common mechanism and leverage existing components can place a designer at a conflicting crossroad. One concept advocates reuse and the other separation. The choice is a case of determining the correct balance associated with the risk from each.
Take a system where users can access or modify database records based on their user credentials. Having a single interface that handles all requests can lead to inadvertent weaknesses. If reading is considered one level of security and modification of records a more privileged activity, then combining them into a single routine exposes the high-privilege action to a potential low-privilege account. Thus, separating mechanisms based on security levels can be an important design tool.
Psychological Acceptability
Users are a key part of a system and its security. To include a user in the security of a system requires that the security aspects be designed so that they are psychologically acceptable to the user. When a user is presented with a security system that appears to obstruct the user, the result will be the user working around these security aspects. Applications communicate with users all the time. Care and effort are given to ensuring that an application is useable in normal operation. This same idea of usability needs to be extended to security functions. Designers should understand how the application will be used in the enterprise and what users will expect of it.
When users are presented with cryptic messages, such as the ubiquitous “Contact your system administrator” error message, expecting them to do anything that will help resolve an issue is unrealistic. Just as care and consideration are taken to ensure normal operations are comprehensible to the user, so, too, should a similar effort be taken for abnormal circumstances.
Weakest Link
Every system, by definition, has a “weakest” link. Adversaries do not seek out the strongest defense to attempt a breach; they seek out any weakness they can exploit. Overall, a system can only be considered as strong as its weakest link. When designing an application, it is important to consider both the local and system views with respect to weaknesses. Designing a system using the security tenets described in this section will go a long way in preventing local failures from becoming system failures. This limits the effect of the weakest link to local effects.
Leverage Existing Components
Modern software development includes extensive reuse of components. From component libraries to common functions across multiple components, there is significant opportunity to reduce development costs through reuse. This can also simplify a system through the reuse of known elements. The downside of massive reuse is associated with a monoculture environment, which is where a failure has a larger footprint because of all the places where it is involved.
During the design phase, decisions should be made as to the appropriate level of reuse. For some complex functions, such as in cryptography, reuse is the preferred path. In other cases, where the lineage of a component cannot be established, then the risk of use may outweigh the benefit. In addition, the inclusion of previous code, sometimes referred to as legacy code, can reduce development efforts and risk.
 | EXAM TIP The use of legacy code in current projects does not exempt that code from security reviews. All code should receive the same scrutiny, especially legacy code that may have been developed prior to the adoption of secure development lifecycle (SDL) processes. |
Single Point of Failure
The design of a software system should be such that all points of failure are analyzed and that a single failure does not result in system failure. Examining designs and implementations for single points of failure is important to prevent this form of catastrophic failure from being released in a product or system. Single points of failure can exist for any attribute, confidentiality, integrity, availability, etc., and may well be different for each attribute. During the design phase, failure scenarios should be examined with an eye for single points of failure that could cascade into entire system failure.
Interconnectivity
Communication between components implies a pathway that requires securing. Managing the communication channel involves several specific activities. Session management is the management of the communication channel itself on a conversation basis. Exception management is the management of errors and the recording of critical information for troubleshooting efforts. Configuration management is the application of control principles to the actual operational configuration of an application system. These elements work together to manage interconnectivity of the elements that comprise the overall application.
Session Management
Software systems frequently require communications between program elements, or between users and program elements. The control of the communication session between these elements is essential to prevent the hijacking of an authorized communication channel by an unauthorized party. Session management is the use of controls to secure a channel on a conversation-by-conversation basis. This allows multiple parties to use the same communication method without interfering with each other or disclosing information across parties.
Designing session management into a system can be as simple as using Hypertext Transfer Protocol Secure (HTTPS) for a communication protocol between components, or when that is not appropriate, replicating the essential elements. Individual communications should be separately encrypted so cross-party disclosures do not occur. The major design consideration is where to employ these methods. Overemployment can make a system unnecessarily complex; underdeployment leaves a system open to hijacking.
Exception Management
All systems will have failures; it is why error checking and failure modes are important to security. When the software encounters a failure, communicating with the user and logging the failure condition are important to the security of the application. As mentioned earlier, it is important to communicate the proper information so that failures can be diagnosed and corrected. It is also important to ensure that there is no information leakage in the process of recording the critical information.
During the design phase, it is important to consider the process of failures and communications associated with them. This is called exception management. Failures should be anticipated, and planned response mechanisms should be part of the overall system design. Building in a secure exception management process improves overall usability and security.
Configuration Management
Dependable software in production requires the managed configuration of the functional connectivity associated with today’s complex, integrated systems. Initialization parameters, connection strings, paths, keys, and other associated variables are typical examples of configuration items. The identification and management of these elements are part of the security process associated with a system.
During the design phase, the configuration aspect of the application needs to be considered from a security point of view. Although configuration files are well understood and have been utilized by many systems, consideration needs to be given to what would happen if an adversary was able to modify these files. Securing the configuration of a system by securing these files is a simple and essential element in design.
Interfaces
Applications operate in a larger enterprise environment. As previously discussed, it is advantageous to use enterprise resources for the management of security. During the design phase, it is incumbent upon the design team to determine the level and method of integration with enterprise resources. Logging provides the data, but the design team needs to plan how this data can be accessed by the security team once the application is in operation. There are a variety of ways that access to the data can be handled—management consoles, log interfaces, in-band vs. out-of-band management—each with advantages and limitations. In most cases, a combination of these techniques should be utilized.
In-band management offers more simplicity in terms of communications. But it has limitations in that it is exposed to the same threats as the communication channel itself. Denial of service attacks may result in loss of the ability to control a system. If an adversary sniffs the traffic and determines how the management channel works, then the security of the management channel becomes another problem. Out-of-band management interfaces use a separate communication channel, which may or may not solve the previous communication issues. Properly provisioned, out-of-band management allows management even under conditions where the app itself is under attack. The disadvantage to this approach is that separate, secure communication channels need to be designed.
Creating a separate management interface to allow users to manage security reporting is an additional functionality that requires resources to create. The advantage is that the interface can be designed to make the best presentation of the material associated with the application. The limitation is that this information is in isolation and is not naturally integrated with other pertinent security information. Sending the information to the enterprise operational security management system—typically a security information and event management system—has many advantages. The security operations personnel are already familiar with the system, and information can be cross-correlated with other operational information.
The important aspect of interfacing the security functionality with the enterprise is in the deliberate design to meet security objectives. Ensuring a solid design for successful integration into the enterprise security operations will enable the customer to minimize the risks of using the application.
Chapter Review
In this chapter, we examined the use of the core concepts of confidentiality, integrity, availability, authentication, authorization, and auditing as part of a security-focused design process. The secure design principles and their role in designing a secure application were considered. The interconnectivity components of session management, exception management, and configuration management were examined with respect to designing essential components.
Quick Tips
• Including confidentiality, integrity, and availability concepts in an application and understanding what the specific requirements are for each of these elements help provide an essential foundation for software.
• Authentication needs to be designed into the system, as this function is a precursor to other aspects of security functionality.
• Whenever possible, the use of enterprise-level functionality for security functions, such as authentication, authorization, and logging, provide enterpriselevel operational benefits.
• When logging information associated with a failure or error, care must be taken to not disclose any sensitive information in logs.
• During the design phase, the attack surface analysis and threat model provide information as to the elements that need to be secured in the application.
• Secure design principles can be employed to assist in the development of a comprehensive security solution for an application.
• Design attention should be paid to critical foundational elements such as configuration management, exception management, and session management.
Questions
To further help you prepare for the CSSLP exam, and to provide you with a feel for your level of preparedness, answer the following questions and then check your answers against the list of correct answers found at the end of the chapter.
1. The primary source of security information for the design phase of an application will be contained in the:
A. Configuration file
B. Threat model
C. Security controls analysis
D. Bug tracking database
2. Designing overlapping mitigations to reduce the chance of failure is an example of:
A. Complete mediation
B. Least common mechanism
C. Defense in depth
D. Open design
3. Reusing components to reduce risk is an example of:
A. Leverage existing components
B. Separation of duties
C. Weakest link
D. Least common mechanism
4. The use of standardized design functions for similar or repeated functionality is referred to as:
A. Psychological acceptability
B. Complete mediation
C. Open design
D. Economy of mechanism
5. Security management interfaces in an application are best served by:
A. Logging exception data
B. Integration into existing enterprise security management systems
C. Exception management systems
D. Separate management interface within the application
6. Out-of-band management interfaces solve which of the following problems?
A. Require separate communication channel
B. Require less bandwidth
C. Reduce development risks
D. Reduce operational risks
7. Designing a secure communication channel system based on separate conversations is referred to as:
A. Configuration management
B. Exception handling
C. Confidentiality-based communications
D. Session management
8. Complete mediation is an approach to security that includes:
A. Design using defense in depth and least privilege
B. A security design that minimizes the opportunity to be circumvented
C. The design of layered security to provide overlapping defenses
D. The integration with enterprise security elements of authentication and authorization
9. Exception management is involved in the management of:
A. Audit data
B. Confidentiality, integrity, and availability (CIA) data
C. Psychological acceptability
D. Separation of duties
10. Hash functions are commonly employed with respect to:
A. Authorization systems
B. Authentication controls
C. Integrity checking
D. Confidentiality controls
11. Logging of errors and failure information should be designed to protect:
A. Sensitive information
B. Availability through resilient controls
C. Separation of duties
D. Fail-safe designs
12. Designing a system so all parties can easily understand design objectives and maintaining a simple design embrace the principle of?
A. Single point of failure
B. Least common mechanism
C. Fail safe
D. Open design
13. The use of legacy code improves development efficiency through reduced development time, but still requires:
A. Complete mediation
B. Defense in depth
C. Exception management
D. Complete security testing
14. The security principle of fail safe is related to:
A. Session management
B. Exception management
C. Complete mediation
D. Single point of failure
15. Using the principle of keeping things simple is related to:
A. Defense in depth
B. Complete mediation
C. Economy of mechanism
D. Least privilege
Answers
1. B. The threat model is the primary mechanism to communicate information about threats, vulnerabilities, and mitigations in an application.
2. C. Defense in depth is accomplished by the design of overlapping mitigations.
3. A. Leveraging existing components reduces risk by using proven elements.
4. D. Reusing components is an example of economy of mechanism.
5. B. Integration into the enterprise security system provides many operational benefits to an organization through increased operational efficiencies.
6. D. Out-of-band management interfaces are less prone to interference from denial of service attacks against an application, reducing operational risk from loss of management control.
7. D. Session management involves encrypting communications on a conversation-by-conversation basis.
8. B. Complete mediation involves the verification of authority prior to use to avoid being circumvented.
9. A. Exception management is the management of log or audit data.
10. C. Hash functions are used to verify integrity.
11. A. When logging information, care should be taken to prevent the inadvertent disclosure of sensitive information.
12. D. Open design is all about communicating the design in clear, simple terms to all members of the design team.
13. D. Legacy code may not have been developed using an SDL, so it still requires complete security testing.
14. B. The principle of fail safe means that when failure occurs, the system should remain in a secure state and not disclose information. Exception management is the operational tenet associated with fail safe.
15. C. The principle of economy of mechanism means to limit complexity to make security manageable, or keep things simple.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.