Building Security In Touchpoints

The Touchpoints by McGraw (2006) also utilizes the lifecycle approach to software security, similar to the SDL. It essentially consists of the three security process areas as in the SSE-CMM. The root of this methodology are the seven key techniques for implementation of secure software, or the

Touchpoints, addressing seven identified problem domains susceptible to ex-

ploitation in software development.

source that presented the Microsoft SDL. Touchpoints conform with other security and software development lifecycle models and can be seen as an independent extension and enhancement to the SDL, with many practical insights how to implement it. The activities included in the Touchpoints are presented in Table 2.5, divided by the development lifecycle phase. For mu- tual comparability, artifacts affected by each activity are derived from the Common Criteria: these may be SFR documentation, SAR documentation, the TOE itself, or the Operating Environment (see Figure 2.5).

Table 2.5: Touchpoints

Phase Touchpoint Target Requirements Security requirements SAR and SFR

Design Architectural risk analysis Security arch. description Abuse cases SFR

Implementation Code review Source code Verification Risk-based security tests TOE

Penetration testing TOE, Operating Env. Release Security operations TOE, Operating Env.

Code reviews, the sole activity to be performed in the implementation phase, is identified as the most important and effective security practice of the seven Touchpoints. The importance of code reviews is supported by e.g. Glass (2003), although Glass stresses that there is no single method to remove coding errors: a combination of methods, tools and techniques is required. Implementation errors are the traditional center of attention in software security, categorized into a taxonomy by Tsipenyuk et al. (2005). Software quality issues introducing exploitable security vulnerabilities, as well as the difficulty of tracing security bugs through traditional quality assurance methods, have been a main cause for creating the current security development models and methodologies.

The Touchpoints places the rest of the practices into order by their ef- fectiveness, from most to least effective. This order is Architectural risk analysis; Penetration testing; Risk-based security tests; Abuse cases; Se- curity requirements; Security operations. When examined in the context provided by the Common Criteria, as presented in Table 2.5, the practices affecting the TOE directly are ranked more important, and practices target- ing the Operating Environment are given less importance. This is consistent with the idea of building security into the product, not “bolting it on”.

The implementation-specific part, as written in 2006, held the following areas that require special attention: 1) Input validation and representation; 2) API abuse; 3) Security features; 4) Time and state; 5) Error handling; 6) Code quality, and; 7) Encapsulation. These conform with the security engi-

neering base practices in the SSE-CMM presented in Section 2.1.3, although differently named and formalized as processes.

To effectively address the security threats, security engineering requires a risk definition and management process. Without domain-specific knowl- edge the risk analysis cannot produce tangible and usable results. The book defines five stages for risk management but advises referring to external sources for more refined risk management processes. The five-phase model presented by McGraw is presented in Table 2.6. This model is a rudimentary version of ISO/IEC Standard 27005:2018 (2018). It does, however, capture the key elements of risk management.

Table 2.6: BSIMM Risk Management Framework by Synopsys Software Integrity Group (2018)

Level Activity Actions

1 Analysis Understand the business context 2 Identification Identify the business and technical risk 3 Prioritization Synthesize and rank the risks

4 Mitigation Define a risk mitigation strategy 5 Implementation Carry out fixes and validate

and verification

The risk management framework is based on an analysis process, requir- ing knowledge of security issues combined with knowledge of the business domain. After composing a list of identified security risks, the risks are prioritized. The priority scale can be as simple as High, Medium or Low: use of a context dependent risk prioritization framework may be necessary. The risk mitigation strategy is the result of the prioritized risk list, which is analyzed and mitigation methods selected based on the business and tech- nical risks, the TOE and the Operating Environment; the product of this analysis is a Risk Analysis Report. In the implementation and validation phases, the risk mitigation methods are verified and the fixes are carried out as necessary; here McGraw’s framework is very testing-oriented, and the verification is generally compared to following a test plan. The frame- work goes on stressing the importance of metrics and measurability, calling for quantitative decision support. This can be achieved by setting up for- mal criteria for measurement by case, or using software-based tools with predefined measurement criteria.

The methodological framework presented by McGraw, which includes Touchpoints, is a collection of best practices and tools. It was one of the first software security engineering methodologies and continues to be relevant to both industry and research. McGraw also has helped creating the Building

Group (2018). The BSIMM model is updated by annual industry surveys about security activities and provides central statistics about the industry’s software security initiatives. The primary contribution of the BSIMM is highlighting the current issues in software security, and actively reporting the industry’s best practices on software security.