| To get started, we must first identify a process to guide us through the software development life cycle so that we can meet the business and security goals we set forth. Adopting the Unified Process (UP) provides a comprehensive approach for ensuring that business requirements are defined, implemented, and tested within the software development life cycle. UP is an industry standard process with a proven track record. It defines the development disciplines, along with an iterative approach, for gathering, analyzing, implementing, and testing functional business requirements. For these reasons, we have chosen it to achieve our business requirements. What UP fails to address are how to incorporate the non-functional requirements of the system. These requirements are assumed but never adequately defined as part of the process. Security is a non-functional requirement, in particular, that must be baked into the process right from the beginning of the inception phase. Too often, it is retrofitted into the application at the end of the construction phase, leading to vulnerabilities and performance and/or usability impacts. To avoid this situation, it is necessary to extend UP with a security discipline that will ensure that all of the security requirements of the application are defined, designed appropriately, implemented, and thoroughly tested. We will refer to the incorporation of these security disciplines into the Unified Process as Secure UP. Secure UP establishes the prerequisites for incorporating the fundamental security principles. It also defines a streamlined security design process within a software development life cycle. UP introduces a security discipline with a set of new security activities. At first glance, the security disciplines seem to overlap heavily with the standard UP disciplines. Why do we need to split hairs over the difference between business requirements and security requirements, or between implementing a functional use case and a security use case? The answer is that universally, for each of these disciplines, there is a wide gap between the people who know and understand the business needs of the application and those who know and understand the security needs. Figure 8-2 depicts Secure UP and the integrated security disciplines. Figure 8-2. Secure UP: Security disciplines 
The Secure UPSecurity disciplines define the following activities: Security Requirements Security Architecture Security Implementation White Box Testing Black Box Testing Monitoring Security Auditing
These activities coalesce to form the basis of a robust security infrastructure and deliver an end-to-end security solution for an application or service. The security discipline activities pertain to different phases of the software development cycle and do not include the sustaining functions in production, such as managing changes, updates, and patch management. An overview of the activities in the security discipline is broken down as follows: Security Requirements: In this activity, one or more analysts will define the business-mandated security requirements of the system. This includes requirements based on industry regulations, corporate policies, and other business-specific needs. The analysts will be well-versed in regulatory compliance as well as corporate security policies. Security Architecture: This activity focuses on the creation of an overall security architecture. Architects will take the mandated security requirements specified by the analysts and then create a draft of the candidate security architecture. This activity qualifies the architectural decisions through a well-defined risk analysis and trade-off analysis processes in order to identify the risks and trade-offs and how to mitigate them. This candidate architecture will also identify a set of security patterns that covers all of the security requirements within the component architecture and will detail them in a high-level way, addressing the known risks, exposures, and vulnerabilities. The candidate architecture will then be prototyped and refined before the final security design activity is begun. This activity will also address the combination of security design with the other non-functional requirements to ensure that the security implementation does not compromise other functional or quality-of-service requirements. Security Design: The Security Design activity takes the security architecture and refines it using approaches such as factor analysis, tier analysis, security policy design, threat profiling, trust modeling, information classification, and labeling. A senior security developer will create and document the design based on the candidate security architecture, analysis results, and taking into account the best practices and pitfalls regarding the strategies of each of the patterns. Security Implementation: In this activity, security-aware developers will implement the security design. A good security design will decouple security components from the business components and therefore not require the security developers to have strong interaction or integration with business developers. The security developers will implement the security patterns by using the strategies defined in the security design and incorporating the best practices for securing the code. White Box Testing: The White Box Testing activity is for white box, or full knowledge, security testing of the code. In this activity, security testers will review the code and look for security holes or flaws that can be exploited. They will test a variety of security attacks aimed at compromising the system or demonstrating how the security requirements can be bypassed. Black Box Testing: This activity is for black box, or zero knowledge, security testing of the system. During this activity, security testers will attempt to break into the system without any knowledge of the code or its potential weaknesses. They will use a variety of tools and approaches to hack the system. They will use "out-of-the-box" techniques to break into the system by all possible means at the application level and end-user level. This will provide an overall assessment of the security of the system. Monitoring: The monitoring activity is an ongoing activity for the system while it is in deployment. In this activity, operations personnel will monitor the application and all security facets of it. This consists of a broad range of areas, starting at the perimeter with the routers and firewalls and extending all the way back to the application itself. Monitoring is an integral part of security and an ongoing activity. Security Auditing: In this activity, security auditors will come in and audit the system for security. They assure that the systems are in compliance with all industry, corporate, and business regulations and that proper audit trails are being maintained and archived properly. These audit trails may also be reviewed for suspicious activity that may indicate a possible security breach.
These activities take place at different points in the application life cycle and have dependencies on each other. Figure 8-3 shows the roles and activities representing the Secure UP security discipline activities. Figure 8-3. Secure UP Activity diagram 
In the above activity diagram, we see the high-level view of the security specific software development life-cycle activities divided by swimlanes representing the different roles. At the start of the application life cycle, analysts gather the mandated security requirements. Once the requirements gathering process is complete, an architect will create a conceptual model of the security architecture. The architect will refine the model further and then define a candidate architecture. He or she will identify appropriate patterns, risks, and trade-offs. He or she will also represent the relevant security principles and perform some conceptual prototyping to validate the architectural decisions. Based on the results of the prototyping, the applicable patterns and the overall architectural approach will then be transitioned to the designer. The designer will take the high-level candidate architecture, decompose it, and create a security design that addresses all component-level requirements and analyses. The resulting security design is a refinement of the architecture based on other functional requirements, non-functional requirements, factor analysis, security policy design, tier analysis, trust modeling, and threat profiling. Once complete, the design is transitioned to the developers to implement. The developers implement the design with an eye on code-level security. Each security requirement is implemented and verified through unit testing, and all code is unit tested before being turned over to the test team for overall system-level tests, including security tests to verify the systemic qualities of architecture. The designer takes the completed code and performs a variety of system tests to ensure that the functional requirements are met as well as the non-functional requirements. This includes application-specific regression tests and reality checks. The designer is responsible for ensuring the adequacy of all systemic qualities contributing to the QoS and SLA agreements of the system as a whole. Upon verification of the system tests, the designer transitions the application to the testers for further security testing, such as penetration tests, operational security testing, application-level scanning, and probing tests. Probing tests include network mapping, vulnerability scanning, password cracking, file integrity checking, malicious code testing, and so on. Two sets of security testers test in parallel. The White Box testers test the system based on a review of the code and full knowledge of the architecture, design, and implementation of the system. They usually find the most security holes. Black box testers test the security of the application from the outside, with no knowledge of the inner workings. They usually find holes in the system as a whole, not particularly in the application alone. If any holes are found, they are transitioned back to the system designer for security analysis. From there, they may require modification to the design and then go back through that particular flow again. If no holes are found, or if they are labeled as acceptable risks, the application is transitioned to the operations staff. Operations will then deploy the application into production. Once in production, operations will be responsible for monitoring the system for security activity. This includes all aspects of the system from the router to the database and from the hardware to the application. It also means constantly checking for and applying hardware and software patches to keep the system available and secure. Once deployed, the system will also be transitioned to the security auditors for auditing. Like monitoring, auditors will perform routine security audits of the application for the duration of its lifetime. Finally, all activity ceases when the application is retired and pulled out of production. Secure UPArtifacts For each of the security disciplines in our Secure UP, there is a mandated set of artifacts. These artifacts represent the work product of the discipline and serve as milestones that allow for transition to the start of another discipline within the software development life cycle. The following is a list of artifacts by security discipline. Security Requirements: The artifacts from the Security Requirements phase define the security requirements specific to the business, management, and operational security of the applications. Some of those business requirements are represented with organizational roles/rights, policies, and regulatory compliance requirements. These will be in document format with business-functional security requirements broken down and tracked by business-requirement identification number. Create Security Use Cases: The business security requirements are documented as a list of requirements with no real cohesion. To make sense of these requirements, they must be structured into developer-friendly use cases. These use cases will be in document format with business-functional security requirements broken down, combined into logical groups, and assigned use case numbers. The use cases then track back to any supporting business requirements or external policies that drove the use case. Security Architecture: The Security Architecture discipline has several artifacts. The first is a conceptual security model. This model represents the high-level security architecture that addresses the business security requirements defined in the use cases from the security requirements phase. The next artifact is the candidate security architecture. This architecture will be refined through the rest of the security activities in this phase, including risk analysis and trade-off analysis. Finally, a core set of security patterns will be chosen as part of the refined conceptual security model. Security Design: There are four significant artifacts of the Security Design discipline. The first is the policy design document. This document defines the policies for the application based on relevant industry, corporate, and business policies pertaining to the system. The second artifact is the trust model. This is created from factor and tier analyses of the policy design. The third artifact is the threat profile. This document defines the types of attacks and their associated risks based on the trust model, the policy design, and the refined security model. The last artifact of the Security Design discipline is the Security Design itself. This document or set of documents defines the detailed security design formulated from the union of all the artifacts. It will contain the patterns and other design material needed for implementation. Security Implementation: The four artifacts of Security Implementation are the source code, build/configuration, infrastructure, and the security unit tests. The source code in this case is the security-related code, such as the security patterns implementation and any security frameworks. The build artifacts are any security-related configurations (such as J2EE deployment descriptors) or documents for configuring security in third-party products. The infrastructure artifacts specify the firewall rules, minimization, hardening profiles, and so forth. The unit tests artifacts are those tests that developers use to test that their code complies with the use cases and provides the functionality specified in the design document. White Box Testing: This discipline has only one artifact, the test results document. This document will specify the tests performed, and their results identify the source code, configuration, and infrastructure failures/successes as well as status, and severity. Black Box Testing: Black Box Testing has only one artifact as well, the black box test results identifying the code flaws. This document will also contain the tests run, tools used, and any techniques found to exploit the application and its infrastructure weaknesses. Environment Setup: Environment Setup has several artifacts. To begin with, the first artifact is to have all of the hardware and software installed and configured. The next artifact is to have one or more Standard Operating Procedure (SOP) documents detailing how to install, configure, maintain, and troubleshoot the environment as well as how to manage crises in the operations center. Another artifact will be completion of a change management request (CMR) system for tracking and fulfilling change requests. Also, the infrastructure layout and design is an important artifact. This would consist of the network design (VLANs and DMZs), ACLs, and trust zones. In some instances, honey pots may be implemented in order to detect and observe and possibly capture intruders. System hardening, minimization, business continuity, and other system setup tasks may be treated as artifacts individually or as a whole. These and other artifacts are better described in a book focused on data center operations. Patch Management: The artifacts for Patch Management are similar to those for Environment Setup. A patch management tool in conjunction with the patch management procedures is the foremost artifact. This allows operations staff to patch and track all of the various systems within the data center. This is often a severely underestimated task. It is also the source of many production outagesjust ask anyone whoever tracked down a random bug that turned out to be caused by a missing patch. Patch management is an ongoing task and therefore the artifacts are evolutionary in nature. Monitoring: Service-level agreement (SLA) is usually associated with monitoring. It is represented as an ongoing task using a logging mechanism that captures all the security-specific alerts and issues. This artifact could be a periodic activity report for designating monitoring tools and procedures used in production as well as a method of support for forensic investigation. Security Auditing: Security Auditing delivers many artifacts associated with SLAs, including organizational policies, verifying compliance requirements, application/host/network configuration, and user activity. These artifacts will be outlined in the policy design. Like monitoring, security auditing is an ongoing process.
Iterative Development One of the major tenets of the Unified Process is iterative development. The activities stated thus far resemble a waterfall approach in terms of how they are tied together in sequence. This is merely a by-product of the representation of the activity diagram tool and not intended to imply that the process is not iterative. It therefore must be stated clearly that the security disciplines are intended to fit into the overall iterative approach to development. Each use case will be addressed in an incremental and iterative manner. While the swim lanes in the activity diagram illustrate some parallelism, the exact breakdown of what can be done in parallel and to what extent tasks are performed iteratively will vary from application to application. It is beyond the scope of this book to discuss the intrinsics of iterative development, and therefore we will simply state that the security activities should be performed iteratively, the same as any other Unified Process activities. |
Risk Analysis (RA) RA is the process of describing threatstheir impacts, possible consequences, and their probability and frequency of occurrence. RA also helps determine how to mitigate those identified risks by establishing the selection criteria for safeguards and countermeasures meant for preventing or reducing those risks to an acceptable level. The acceptable risks are termed as transferred risks that are manageable. Depending upon the security requirements, the RA process may include a range of activities such as risk identification, risk assessment, risk characterization, risk communication, risk mitigation, and risk-specific policy definition. RA influences the security design process by helping the decision making process related to choosing applicable tools and mechanisms. This ensures that security measures are appropriate and fully commensurate with the risks to which the application or service is exposed. A typical RA artifact will gather information based on the following techniques: Asset Valuation: This technique is the fundamental process of determining the value of an asset. An assessment of the overall business value of the application or service is made. Factors included are: initial and ongoing cost, insurance value and total estimated value, including the infrastructure and other intellectual properties. Asset valuation helps to justify the cost benefits in preventing or reducing the known risk and to satisfy the stakeholders, legal, and other regulatory requirements. Quantitative Risk Analysis: This technique identifies all key risk elements and estimates the value associated with each risk, such as infrastructure cost, potential threat, frequency, business impact, potential loss value, safeguard option, safeguard effectiveness, and safeguard value. Based on this information, it is possible to estimate the potential losses, analyze the potential threats, compute the Annual Loss Expectancy (ALE), and then identify countermeasures and safeguards. The formulas for computing the ALE are as follows: - Exposure Factor (EF) = Percentage of asset loss caused by the potential threat. - Single Loss Expectancy (SLE) = Asset value x Exposure Factor - Annualized Rate of Occurrence (ARO) = Frequency of threat per year. - Annual Loss Expectancy (ALE) = SLE x ARO
Qualitative Risk Analysis: This technique identifies the threats and vulnerabilities specific to applicable scenarios identified through security reality checks. Based on the findings, it helps to mitigate the risks by identifying the appropriate safeguards and countermeasures to prevent them or to reduce the likelihood and effect of occurrence.
Table 8-1 represents an example template of a qualitative risk analysis artifact that identifies the known risks in aspects of architecture tiers, possibility of occurrence expressed in terms of number of prospects, probability expressed in terms of likelihood of possible occurrences, Impact expressed in terms of effect that affects the overall architecture, and Exposure expressed as the level of acceptability. Table 8-1. Sample RA Template for Qualitative Risk AnalysisNo | Known Risks | Tier/Component | Possibility Of Occurrence (Single/Multiple) | Probability
1 Low
5 Medium
7 High
10 Extreme | Impact
1 Low
5 Medium
7 High
10Extreme | Exposure
1 Low
5 - Medium
7 High
10Unacceptable |
|---|
1 | | | | | | | Issue: | Mitigation: |
Trade-Off Analysis (TOA) The purpose of trade-off analysis is to improve the quality of security architecture with explicit, efficient, and rational decisions. TOA provides stakeholders with a systematic way of improving and validating the security architecture with its use of multiple security criteria, options, alternatives, and recommendations. In the security architecture discipline, it helps to weigh choices of security features against potential threats or vulnerabilities. This assists in justifying a financial case or identifying alternative options. A typical TOA artifact contains all of the security architecture criteria and safeguard options and alternatives. It will also include an Effect Matrix, where the security options/alternatives are represented in columns and security criteria are represented in rows. The cells have two values: the top value indicates the magnitude of impact on a scale from 10 to 10, and the bottom value indicates the relative importance of that security criterion on a scale from +1 to +10. Table 8-2 illustrates an example Effect Matrix. Table 8-2. Effect Matrix Table (An Example)Trade-Off AnalysisEffect Matrix |
|---|
| | Safeguard Option 1 | Safeguard Option 2 | Safeguard Option 3 | Safeguard Option 4 |
|---|
Security Criterion A | +7 | +6 | +5 | +8 | 8 | 8 | 8 | 8 | Security Criterion B | +2 | 0 | 0 | +3 | 9 | 9 | 9 | 9 | Security Criterion C | 3 | 0 | 2 | +2 | 7 | 7 | 7 | 7 |
Thus, TOA is a ranking index for making architectural security decisions with clear assumptions and for addressing associated uncertainties. |
