8
Design Processes
In this chapter you will
• Examine the concept of attack surfaces and attack surface minimization
• Examine the use of threat modeling to reduce vulnerabilities
• Examine the integration of enterprise security controls to mitigate threats in software
• Explore risks associated with code reuse
• Learn how security gate reviews can use threat modeling and attack surface information to improve security
Security implementation begins with requirements, and becomes built in if designed in as part of the design phase of the secure development lifecycle (SDL). Designing in the security requirements enables the coding and implementation phases to create a more secure product. Minimization of vulnerabilities is the first objective, with the development of layered defenses for those that remain being the second objective. To achieve these goals, the software development team needs to have a detailed understanding of the specific threats and vulnerabilities in the software under development.
Attack Surface Evaluation
The attack surface of software is the code within the system that can be accessed by unauthorized parties. This is not just the code itself, but can also include a wide range of resources associated with the code, including user input fields, protocols, interfaces, resource files, and services. One measure of the attack surface is the sheer number or weighted number of accessible items. Weighting by severity may change some decision points, but the bottom line is simple. The larger the number of elements that can be attacked, the greater the risk. The attack surface of software does not represent the quality of the code—it does not mean there are flaws; it is merely a measure of how many features/items are available for attack.
A long-standing security practice is not to enable functionality that is not used or needed. By turning off unnecessary functionality, there is a smaller attack surface and there are fewer security risks. Understanding the attack surface throughout the development cycle is an important security function during the development process. Defining the attack surface and documenting changes helps enable better security decision making with respect to functionality of the software.
Software is attacked via a series of common mechanisms, regardless of what the software is or what it does. Software is attacked all the time, and in some remarkably common ways. For instance, weak access control lists (ACLs) are a common attack point, and these can be regardless of the operating system. Attacks against the operating system can be used against many applications, including software that is otherwise secure. Attack surface evaluation is a means of measuring and determining the risks associated with the implications of design and development.
Attack Surface Measurement
To understand a product’s attack surface, you need to measure the number of ways it can be “accessed.” Each software product may be different, but they will also share elements. Like many other security items, the first time a team builds a list, it will be more difficult. But, over time, the incremental examination will detail more items, making future lists easier to develop. In this light, here is a published list from Microsoft on attack surface elements associated with Windows. Although this list may not be totally applicable, it does provide a starting point and acts as a guide of the types of elements associated with an attack surface.
• Open sockets
• Open remote procedure call (RPC) endpoints
• Open named pipes
• Services
• Services running by default
• Services running as SYSTEM
• Active web handlers (ASP files, HTR files, and so on)
• Active Internet Server Application Programming Interface (ISAPI) filters
• Dynamic webpages (ASP and such)
• Executable virtual directories
• Enabled accounts
• Enabled accounts in admin group
• Null sessions to pipes and shares
• Guest account enabled
• Weak ACLs in the file system
• Weak ACLs in the registry
• Weak ACLs on shares
Another source of information is in the history of known vulnerabilities associated with previous developments. Determining the root cause of old vulnerabilities is good for fixing them and preventing future occurrences, and it is also valuable information that can be used in determining the attack surface.
The list of features that form the attack surface is the same list that attackers use to attack a specific piece of software. The items on the list are not necessarily vulnerabilities, but they are items that attackers will attempt to compromise. These elements are at the base of all vulnerabilities, so while a particular vulnerability may or may not exist for a given attack surface element, there will be one under each vulnerability that is uncovered. This makes measuring the attack surface a solid estimation of the potential vulnerability surface.
It is important to note that each software product is different, and hence, comparing attack surface scores from different products has no validity. But counting and measuring the attack surface provides baseline information from which security decisions can be made. Different elements may have different scoring values, as a service running as a system is riskier than a nonprivileged service. Services that are run by default are riskier than those on the same level only running on demand.
Attack Surface Minimization
The attack surface is merely a representation of the potential vulnerability surface associated with the software. Once a baseline is known, the next step is to examine ways that this metric can be lowered. This can be done by turning off elements not needed by most users, as this reduces the default profile surface. Services that are used can be on or off by default, only on when needed, run as system, or without privilege. The lower the privilege, the less a service is running, so these factors can reduce the attack surface.
Attack surface minimization is not necessarily an “on or off” proposition. Some elements may be off for most users, yet on for specific users under appropriate circumstances. This can make certain features usable, yet not necessarily exploitable. Reducing the exposure of elements to untrusted users can improve the security posture of the code. Minimization is a form of least privilege, and the application of it works in the same manner. If the application is network aware, restricting access to a set number of endpoints or a restricted IP range reduces the surface.
The attack surface should be calculated throughout the development process. Work done to reduce the attack surface should be documented throughout the process. This will assist in lowering the default surface level at deployment, but the information can also be provided to the customer so they can make informed decisions as they determine specific deployment options. As with all changes, the earlier in the development process a change is made, the lesser the impact will be to surrounding elements.
Attack surface minimization should be considered with design efforts. Determining the design baseline and listing the elements and details assists the development team in achieving these objectives. As the process continues and decisions are made that affect the surface, the documentation of the current attack surface area helps everyone understand the security implications of their specific decisions. Although security may not be easy to measure directly, the use of the attack surface as a surrogate has shown solid results across numerous firms.
Threat Modeling
Threat modeling is a process used to identify and document all of the threats to a system. Part of the description will include the mitigating actions that resolve the exposure. This information is communicated across all members of the development team, and acts as a living document that is kept current as the software progresses through the development process. Performing threat modeling from the beginning of the development process helps highlight the issues that need to be resolved early in the process, when it is easier to resolve them. Threat modeling is an entire team effort, with everyone having a role in the complete documentation of the threats and issues associated with the software.
Threat Model Development
The threat model development process is a team-based process. The threat model development occurs across several phases. The first is defining the security objectives for the system. Following that is the system decomposition, then the threat identification, followed by mitigation analysis. The final step is the validation of the model.
Identify Security Objectives
As part of the requirements process, one of the essential elements is the determination of the security objectives associated with the system under development. These requirements can come from a number of sources, including legal, contractual, and corporate standards and objectives. Both security and privacy elements can be considered. Documenting an understanding of the business rationale for obtaining and storing data; how it will be used; and the related laws, regulations, and corporate standards for such behaviors will assist in later stages in the understanding of what is required. Leaving the decision of what data to protect and how to protect it up to a development team is a mistake, as they may not have the breadth or depth of knowledge with respect to these requirements to catch all of the possible associated threats. Laws, regulations, contractual requirements, and even corporate standards can be complex and byzantine, yet if they are to be properly covered, they need to be enumerated as a list of requirements for the development effort.
System Decomposition
Once the security objectives are defined for a system, designers need to ensure they are covered in the actual design of the system. Numerous modeling systems are used in the design of a system. Unified Modeling Language (UML), use cases, misuse cases, data flow diagrams (DFD), and other methods have been used to define a system. For the purposes of threat modeling, since the target is typically the information being manipulated, the DFD model is the best choice to use in documenting the threats.
Beginning in the design phase, as part of a system decomposition exercise, the designers can use DFDs to document the flow of data in the system. When using DFDs, it is important to identify and include all processes, data stores, and data flows between elements. Special attention should be given to trust boundaries, where data crosses from one zone of trust to another. In large, complex systems, breaking down the DFD into scenario-based pieces may make documentation easier. Every assumption and every dependency should be enumerated and described. This is the baseline of the document. As the development process progresses, any changes to the items in the threat model should be documented and updated.
DFD Elements for Threat Modeling
The following are examples of elements to identify as part of the threat modeling process:
External Entities
• Users (by type)
• Other systems
Data Stores
• Files
• Database
• Registry
• Shared memory
• Queues/stack
Trust Boundaries
• Users
• File systems
• Process boundaries
Data Flows
• Function calls
• Remote procedure calls (RPCs)
• Network traffic
Trust boundaries are key elements, as they represent points where an attacker can interject into the system. Inside a trust boundary, items share the same privileges, rights, access, and identifiers. Machine boundaries are obvious trust boundaries, but inside a system, if privilege changes, this is a trust boundary, too.
Threat Identification
Once the system is well documented, then the process of identifying threats begins. Threat identification can be done in a variety of manners, and in most cases, several methods will be used. An experienced security person can provide a series of known threats that are common across applications, although this list needs to be tailored to the application under development. During the DFD documentation process, as security objectives are documented, the question of what issues need to be protected against is answered, and this information describes threats. The use of the STRIDE method can be repeated across processes, data flows, trust boundaries—anywhere you want to understand the security implications of that portion of the application under development. Using each of the elements of STRIDE, the threat model is documented as to what happens as a result of each element of the STRIDE acronym. Not every STRIDE element will warrant documenting at every location, but this exercise will uncover many important security considerations.
As the threats are enumerated and documented, try to avoid becoming distracted by things that the application cannot control. For instance, if the system administrator decides to violate the system (machine) trust, this is an operating system issue, not an application issue. Likewise, with elements such as “someone steals the hard drive,” other than encrypting essential data at rest, this is an outside-the-application issue.
By this point, a lot of data will be associated with the threat model. There are tools to assist in the collection and manipulation of the threat model data, and it is wise to use an automated tool to manage the documentation. All of the described elements up to this point need to be numbered, categorized, and managed in some fashion. The next step is an examination of mitigations that can be employed to address the threats.
STRIDE
The acronym STRIDE is used to denote the following types of threats:
| Threat | Security Property |
| Spoofing | Authentication |
| Tampering | Integrity |
| Repudiation | Nonrepudiation |
| Information Disclosure | Confidentiality |
| Denial of Service | Availability |
| Elevation of Privilege | Authorization |
Mitigation Analysis
Each threat requires mitigation. Mitigation can be of four types: redesign to eliminate vulnerability, apply a standard mitigation, invent a new mitigation, or accept the vulnerability. If redesign is an option, and it may be in the early parts of the development process, this is the best method, as it removes the risk. The next best method is to apply a standard mitigation. Standard mitigations are common security functions, such as ACLs, and have several advantages. First, they are well understood and are known to be effective. Second, in many cases, they will apply across a large number of specific vulnerability points, making them an economical choice. Developing new mitigation methods is riskier and more costly, as it will require more extensive testing. Accepting the vulnerabilities is the least desired solution, but may on occasion be the only option.
The threat model is a dynamic document that changes with the development effort; so, too, do the mitigations. For a threat that is documented late in the development cycle, elements such as redesign may not be practical for this release. But the information can still be documented, and on the next release of the software, redesign may be an option that improves the security.
In picking the appropriate mitigation, one needs to understand the nature of the threat and how it is manifested upon the system. One tool that can assist in this effort is an attack tree model. An attack tree is a graphical representation of an attack, beginning with the attack objective as the root node. From this node, a hierarchical tree-like structure of necessary conditions is listed. Figure 8-1 illustrates a simple attack tree model for an authorization cookie.
Figure 8-1 Attack tree
When describing a threat, it is also useful to gauge the priority one should place on it. Some attacks are clearly more serious than others, and risk management has dealt with this using probability and impact. Probability represents the likelihood that the attack will have success. This is not necessarily a numerical probability, but typically is described using nominal values of high, medium, and low. Impact represents the loss or risk faced by a successful attack, and it, too, is frequently scored as high, medium, or low. To convert these to a numerical score, you can apply numbers (high = 3, medium = 2, low = 1) to each and multiply the two. The resulting scores will be between 9 and 1. This provides a means of differentiating threats, with those scoring higher clearly more important to address.
Another method is referred to as DREAD, with DREAD being an acronym for damage potential, reproducibility, exploitability, affected users, and discoverability. To use DREAD, one can assign a value from 0 (nothing), to 5 (moderate), to 10 (severe) for each of the elements. Then the total risk can be obtained by summing and dividing by 5, which will yield a score from 0 to 10. Another method is to set discoverability to 10, assuming discovery when doing the analysis. DREAD can be mapped into the probability impact model by taking the following factors into account: probability (reproducibility + exploitability + discoverability) and impact (damage potential + affected users).
Threat Model Validation
As the software development process moves through the phases of the SDL, at gates between the phases, an opportunity to examine materials presents itself. The current version of the threat model should be validated at each of these opportunities. The purpose of the validation phase is to assess the quality of the threats and mitigations. For the threats, it is important to ensure that they describe the attack and the impact in detail relevant to the context of the application. For mitigations, it is important that they are associated with a threat and are completely described in terms relevant to the context of the application.
Any and all dependencies should be documented. Documenting both what other code bases you are relying on and the security functions associated with that code is important. Ensuring all dependencies are documented is important at each phase of the SDL. Any assumptions that are made as part of the development process are also important to document.
Control Identification and Prioritization
Security controls are the primary mechanisms that enterprises use to manage security. These controls form the backbone of the enterprise security function and can be applied as part of the mitigation package for the application under development. Using enterprise controls such as ACLs implements security mitigations and does so in a manner where the enterprise can operationally perform the tasks efficiently and correctly.
Priority should be afforded to any security control that exists in the enterprise. Although some applications may have the ability to maintain their own access control mechanism, managing the security of the user base adds duplicative work. Aligning the access control, user authentication, and other security mechanisms to those employed in the enterprise reduces the operational security workload and still achieves the desired mitigating actions.
Software programs and applications do not exist in a vacuum. Part of the Microsoft SDL process is to have systems be secure by design, by default, and in deployment. Using design elements to ensure integration into appropriate enterprise security controls assists in these objectives. Use of security provisions of existing protocols, such as IPSec, Hypertext Transfer Protocol Secure (HTTPS), Secure Shell (SSH), and others, can provide significant security mitigation efforts that are supported by the platform and the enterprise and are optimally managed. Reducing any duplication of security functionality reduces development risks and improves deployment and operations of the software.
Risk Assessment for Code Reuse
Code reuse has been a practice in the software development industry since its beginning. The reasons are many: saving time, reducing work, and providing consistency. Software libraries are the ultimate example of code reuse. However, code reuse does not come without risk. Reuse of older code has resulted in errors in the past and will do so again in the future. Legacy code from products as old as Windows for Workgroups has resulted in security issues in products up to Windows XP.
When old code is reused in a project, it should be subjected to the same scrutiny as the new code under development. Old code should be included in threat modeling and attack surface minimization efforts. Code reviews and walkthroughs can provide valuable insight into risks associated with legacy code. Vulnerabilities that did not exist in the code at the time it was developed can arise due to changes in the environment that the code operates in. Examining the code in the context of the current operating environment can reveal issues that would not have been discoverable in the original environment.
Documentation
The documentation associated with threat modeling and attack surface minimization provides a wealth of security-related information. Keeping this documentation up to date is not just a paperwork exercise to satisfy an auditor or regulation, but provides value as a roadmap and encyclopedic repository for team use.
The purpose of the documentation is to communicate essential information across the development team. Beginning with requirements and progressing all the way through the development process, the information compiled in the documentation provides a guide to keep all team members on the same plane throughout. As each new phase of the development process is started, the documentation provides a running narrative of the security issues that have been identified, the plans to mitigate, and the expectations of the development process with regard to achieving these objectives. As the attack surface area is always a dynamic issue, each phase should monitor this issue and keep the plan updated with current options and measurements. Making this an issue that is tracked helps draw attention to subtle creep that increases this risk without a full understanding of the causes and ramifications.
In this same vein, the threat model documentation provides a wealth of detailed information concerning security objectives, an enumeration of threats, how vulnerabilities and mitigations are being handled, and documentation on dependencies and assumptions. This information can be used by the software development team to ensure that issues are not overlooked or that design elements are not providing the best platform options for minimizing security risk. As with other aspects of the security documentation, the living nature of the threat model portion is, by design, encouraging improvement of the threat model at every step of the development process. Keeping the team aware of and focused on what can be done to mitigate the specific vulnerabilities enables the entire team to assist in creating the most secure implementation possible.
Design and Architecture Technical Review
Using the results of the documentation from the attack surface area and the threat model enables the development team to properly design and implement security functionality in the application under development. Periodic reviews of the development progress should include reviews of the security progress as well. Code walkthroughs, design reviews, examination of the attack surface area, and threat modeling documentation with an eye toward completeness are key elements of these reviews.
The periodic reviews are not just technical to ensure that the products of the SDL process are technically complete and accurate, but are also process focused. Equally important is the notion that the SDL process is functioning as planned to achieve the desired objectives. The security review process is really a two-pronged effort. The primary effort needs to be done by the development team during each phase of the development process. Security cannot be added in after the fact by the security team, but instead must be baked into the product as part of the development effort. The attack surface minimization and threat modeling efforts provide a process-wide vehicle for managing these issues and building security into the application. The SDL process is designed to specifically support this effort. As part of the review efforts at every level, ensuring that proper attention is being devoted to the security posture is the entire team’s responsibility. The primary function of the security review at the process gates is to ensure that this activity is occurring and performing at the desired levels. Thus, the security review is oriented to the process, not just to ensuring that all of the security bases are being covered.
Chapter Review
This chapter opened with an examination of attack surfaces and how they play a role in security software. The chapter continued the coverage of attack surfaces, examining how they are defined, measured, and ultimately minimized. This information is documented in a report that is updated throughout the development process. Threat modeling was presented as the tool and mechanism used to understand and mitigate the threats against the application. A detailed examination of how threat modeling is performed, what is documented, and how the information is used to reduce vulnerabilities was presented. The integration of threat modeling continued with a discussion of the risks associated with code reuse and an examination of how security controls are used to improve security in the product.
The chapter concluded with an examination of how the documentation from the attack surface and thread modeling efforts can be used to achieve team coordination in the pursuit of application security objectives.
Quick Tips
• The attack surface of an application represents a measure of how many features/items are available for attack.
• The actual measure of an attack surface is useful across the development process to measure improvement on numbers of potential vulnerabilities.
• Threat modeling is a process used to identify and document all of the threats to a system.
• Threat modeling has five phases: define security objectives, system decomposition, threat enumeration, mitigation analysis, and validation of the model.
• STRIDE represents spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.
• Attack trees provide causal information with respect to attack vectors.
• DREAD represents damage potential, reproducibility, exploitability, affected users, and discoverability.
• When securing vulnerabilities, priority should be afforded to any security control that exists in the enterprise.
• Attack surface and threat modeling documentation are living documents to communicate security information across the development team.
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 increasing value for the attack surface of an application during development is indicative of:
A. Excess risk
B. Declining code quality
C. An increase in addressable resources
D. An improvement in security
2. You have moved to a new project, and the attack surface measurement indicates an attack surface only half of the value of the project you just left. This indicates:
A. More work on minimization is needed.
B. The previous project was more secure from a security perspective.
C. The previous project was twice as big; no problem.
D. Nothing. Attack surface measurements are not comparable across different projects.
3. The attack surface of your project seems to grow faster than it should. Which of the following is probably not a fruitful place to look?
A. Number of modules/routines in the project
B. Privilege level of the credentials used to run the application
C. Network address space from which the program is addressable
D. Privilege level of users using the application
4. The first step in threat modeling is:
A. Define security objectives for the application.
B. Pick a threat model team.
C. Decompose the application into smaller pieces.
D. Measure the attack surface of the application.
5. STRIDE stands for:
A. Spoofing, trust violation, repudiation, information disclosure, denial of service, elevation of privilege
B. Spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege
C. Spoofing, tampering, reproducibility, information disclosure, denial of service, elevation of privilege
D. Spoofing, tampering, repudiation, information disclosure, denial of service, exploitability
6. DREAD stands for:
A. Damage potential, reproducibility, exploitability, affected users, discoverability
B. Damage potential, repudiation, exploitability, affected users, discoverability
C. Damage potential, reproducibility, exploitability, asset value, discoverability
D. Damage potential, reproducibility, elevation of privilege, affected users, discoverability
7. Inside a trust boundary, items:
A. Share the same ACL access
B. Share the same privileges, rights, access, and identifiers
C. Share the same user account
D. Are not observable
8. A threat model is validated for all of the following except:
A. Appropriate mitigations are assigned to all threats listed.
B. All security threats are identified.
C. Dependencies have been considered and are documented.
D. The quality of mitigations is adequate.
9. To reduce the risk associated with reusing code, the development team should:
A. Never reuse code, but develop all code via the SDL process
B. Identify and document the risk of reused code
C. Perform testing and validation on reused code in the same fashion as new code
D. Only use code certified for the project
10. If there is not sufficient time to finish documentation on threat model, the team should:
A. Request a waiver from the security team
B. Push the documentation into the next phase as an item to be finished
C. Delay the gate until the documentation is complete
D. Don’t worry about the documentation if the work is done correctly
11. The primary purpose behind security reviews is to:
A. Ensure that all steps of the SDL are being properly followed
B. Ensure that the attack surface model is updated at each phase
C. Assess the quality of security actions, including mitigations for vulnerabilities
D. Ensure that the threat model is updated at each phase
12. The STRIDE model is applied to:
A. Attack surfaces in the attack surface model
B. Threat model threat identification efforts
C. Determine the risk from a threat
D. Every threat found during the attack surface area measurement effort
13. The best method of system decomposition for threat modeling is the construction of:
A. Misuse cases
B. Use cases
C. UML
D. DFD
14. Which of the following is not a mitigation method for threats identified in threat modeling?
A. Redesign to eliminate vulnerability.
B. Apply a standard mitigation.
C. Change the security requirements to eliminate the threat.
D. Accept the vulnerability.
15. The preferred security mitigation to use during threat modeling is:
A. A custom control created specifically for the threat
B. Encryption from an approved library to prevent information disclosure
C. Acceptance of the vulnerability
D. Standard enterprise-level security controls in common use, such as ACLs
Answers
1. C. An increase in the value of the attack surface indicates an increase in the number of addressable resources.
2. D. Attack surface measurements are defined by the breadth and scope of addressable elements, and thus are not strictly comparable across different projects.
3. A. The number of modules a program is composed of does not factor directly into attack surface calculations.
4. A. Defining the security objectives for an application form the foundation for all threat modeling efforts.
5. B. STRIDE is an acronym for spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.
6. A. DREAD is an acronym for damage potential, reproducibility, exploitability, affected users, and discoverability.
7. B. This is the definition of a trust boundary; inside a trust boundary, items share the same privileges, rights, access, and identifiers.
8. B. It is never possible to identify all threats to a system.
9. C. Legacy code can be included in new projects, but it should be subjected to all of the same security steps and tests as new code.
10. C. The security review should block advancement under the SDL process until all aspects of a phase are complete and properly done.
11. A. The primary purpose of security reviews is to assess the efficacy of the SDL, with that efficacy having the desired security effects, not the review itself.
12. B. STRIDE is used during the threat identification phase to identify types of threats.
13. D. Data flow diagrams are best suited for the identification of threats to a system.
14. C. Changing the security requirements does not eliminate a threat; it merely results in it being ignored.
15. D. The preferred set of mitigations are enterprise-level security controls already in place and used in the enterprise.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.