Touchpoints Methodology

(Seven touchpoints for software security)

Haya Ali Joudeh
M.Sc. student in Information security and digital Criminology
Princess Sumaya University For Technology
Abstract The software development in any company is
no different from creating any other product. For example
,IEEE standard for software development requires the
development team to produce source code but the related
software methodologies tell the organization how to
produce this source code. Software security professionals
should seek to use touchpoints (which means the best
practices) throughout the software development
lifecycle,In addition this methodology is one of the
advanced methodologies that will help improve the
process, developing code and get us closer to the silver
bullet dream in developing secure software.
Index TermsTouchpoint,
methodology, Seven touchpoints

software

development

1. INTRODUCTION
The touchpoints methodology are one of the main pillars
of software security that mention by McGraw which are : Risk
Management Framework, Software Security Touchpoints(best
practices ), and Knowledge Catalogs. Each of them is a
necessity for software security. Software security is not
security software. acquiring software security means applying
a number of simple best practices throughout the software
development lifecycle more than it means the application of
security characteristic like cryptography .This methodology
allow software development team to build the emergent
property of security while building the software . In addition ,
you don't have to apply all seven touchpoints to begin to apply
security features in (though doing so is highly
recommended).actually the touchpoints are designed to close
the gap between the state of the art and the state of the practice
[1] - something that can be done only through the common
adoption of touchpoints activities. Touchpoints are
destructive and constructive activities. Destructive activities
are about all negatives activities that may effect on the
software availability , integrity and confidentiality such as
attacks, exploits, and breaking software. These kinds of
attacks and exploits are represented by the black hat .
Constructive activities are about all how to deal with a
software in positive side such as design, defense, and
functionality.[1]

2. WHAT IS TOUCHPOINTS
Touchpoint are activities that the development team needs
to do during a particular phase of the software development
life cycle .This methodology strictly focuses on security
designs, principles and features if a software application rather
than the functionality of this software .For example, instead
of focusing on what the software requirement is assumed to
do, the touchpoint method will focus on how that software
requirement can make the application vulnerable to security
risk if implemented (which is abuse case).
And because the Touchpoints method focus strictly on
security issues, it can blend right in with any other software
methodology used for quality measure and functionality. This
methodology for software security can be applied during each
phase of a standard software development life cycle process.
Using the touchpoint method provides security activities in
every phase and forces security to be worked into the software
package from concept to implementation .So putting software
security into practice requires making some changes to the
way organizations build software.
The below figure show the software security touchpoints and
shows how software practitioners can apply them to the
different software artifacts produced during software
development. Although in this figure artifacts are developed
according to a traditional waterfall methodology, most
organizations follow an iterative model today, which means
that best practices will be iterate through more than once as
the software evolves.

Here are the touchpoints, in order of effectiveness:

1. Code review

2. Architectural risk analysis

3. Penetration testing
4. Risk-based security tests
5. Abuse cases
6. Security requirements
7. Security operations
3. TOUCHPOINTS ACTIVITIES
(Seven Terrific Touchpoints)
3.1 Code Review with a Tool
As We know that the artifacts of each software projects are
guarantee to have one in common which is source code.
Because of this common artifact, it makes sense to focus on the
source code itself in a software assurance activities phase .
Plus, simple bugs that we may found it in the code caused a
large number of security problems (e.g., The following
functions all pose a risk of buffer overflow due to misusing it :
_mbsinc _mbsdec _mbsncat _mbsncpy in C and C++ ) [2].
Regarding bugs and flaws, code review activity is about
discovering and fixing the bugs.

Static analysis tools also called source code analyzers examine

the source code of a program (software) statically, without
attempting to execute it. Basically, they can examine either a
program's source code or a compiled form of the program to
equal benefit, although the problem of decryption and
decoding the latter can be difficult.
The latest security risks and vulnerabilities are identified and
managed in the software lifecycle. And there is no single
touchpoint or tool can solve all of software security issues.
Static analysis tools are the same. For starters, static analysis
tools look for fixing set of rules ,or patterns in the source code.
In addition there is more advanced tools allow adding new
rules over time, if a rules haven't been written yet to find a
specific issues, the tool will never find that issues. A static
analysis tool's output still requires human evaluation.
There is no way for any tool to discover automatically all the
problems are more or less critical to you, so there is no way to
avoid finding it through the output and making a judgment call
about which problems should be fixed and which ones are
acceptable level of risk. In addition ,people who required this
program still need to get its design right to avoid any bugs.
Static analysis tools can find errors (bugs) in accurate details,
but they can't even begin to criticize design. Don't expect any
tool to tell you, "I see you're implementing a funds system
including transfer ,saving ,and deposition processes. You
should let the user have multi authentication before enter the
system such as user name password and biometric
authentication such as iris .
Static analysis tools suffer from false negatives (in which the
program contains bugs that the tool doesn't report) and false
positives (in which the tool reports bugs that the program
doesn't really contain). False positives cause immediate
sorrow to any analyst who has to audit through them, but false
negatives are much more dangerous because they lead to a
false purpose of security
Example of risks found: Buffer overflow on line 138
3.2 Architectural Risk Analysis

Programmers make little mistakes all the time-for example

extra parenthesis here, missing semicolon there. Most of the
time, such simple mistakes are inconsequential; the compiler
catch the error and the programmer try to fix it in the source
code, and the development process continue. This quick
process of feedback and response stands in sharp contrast to
what happens with most security vulnerabilities, which can lie
dormant (sometimes for years) before discovery.[1]
One of the main problems is that the programming curriculum
is not mention security as a standard in development life
cycle. You can't really accuses programmers who introduce
bugs and spot any security vulnerable into their code if
nobody ever told them what to avoid or how to avoid and
build a secure software. Another important problem and we
must take it in consideration is that most programming
languages were not designed with built-in security features .
Unintentional (mis)use of various functions built into these
languages leads to very common and often exploited
vulnerabilities.

Most of risk analysis process descriptions describe that the

risk identification , mitigation, and ranking is a continuous
process and not simply an individual step to complete at each
phase of the development lifecycle. Risk analysis feedback
and risk categories thus drive both into specification (which is
the requirement determined early in the development
lifecycle) and into testing (where risk results can be used to
determine and plan specific tests).

A prototypical risk analysis approach involves several major

activities that often include a number of basic sub steps. [1]
A.
Learn as much as possible about the target of
analysis: by analyze and understand the requirements,
specification documents, plus other design requirements.try
to determine system limitation and sensitive or critical data.
Study the code and other software artifacts .determine threats
and agree on relevant sources of attack.
B. Discuss security problems surrounding the software: this
step done by argue about how the product works and
determine areas of disagreement or opacity. And identify
possible vulnerabilities, risks that may effect on software
functionality.
C. Determine probability of compromise: this step done by
Map out attack scenarios for exploits of vulnerabilities.
Balance controls against threat capacity to determine
likelihood.
D. Perform impact analysis: this step done by Determine
impacts on assets and business goals. consider impacts on the
security posture
E. Rank risks.
F. Develop a mitigation strategy: by Recommend
countermeasures to mitigate risks.
G. Report findings: by Provide basic information regarding
where to spend limited mitigation resources. and describe
carefully the major and minor risks, with attention to impacts.

canned black box penetration test show that you're in very

deep trouble indeed.[1]
Artifact: System in its environment. Example of risks found:
Poor handling of program state in Web interface.

Artifact: Specification and Design

Examples of risks found: Poor compartmentalization and
protection of critical data.[1]
At the architecture and design phase , a system must be
consistent and present a unified security front. Designers,
Developer , and business analysts should clearly document
assumptions and identify possible attacks. At both the
specifications stage and at the design stage, architectural risk
analysis is a necessity. So security analysts at this point
uncover and rank architectural flaws so that mitigation can
begin.
Disregarding risk analysis at this level will lead to costly
problems down the road. Note that risks appear during all
phases of the software development lifecycle, so a constant
risk management thread, with recurring risk-tracking and
observation activities, is highly recommended.

Security testing must include two strategies: (1) testing of

security functionality with standard functional testing
techniques and (2) risk-based security testing based on attack
patterns, risk analysis results, and abuse cases. A good
security test plan embraces both strategies. Security problems
aren't always clear, even when you work a system directly, so
standard issue QA is unlikely to uncover all critical security
issues. QA is about making sure good things happen. Security
testing is about making sure bad things don't happen. Thinking
like an attacker is essential. Guiding security testing with
knowledge of software architecture, common attacks, and the
attacker's mindset is thus extremely important.

one of interesting tools that help in penetration testing is Fault

Injection Tools : Software fault injection has an interesting
future as a potential security technology ,For example
Cenzic tool.
3.4 Risk-Based Security Testing

3.3 Penetration Testing

Penetration testing is very useful, especially if an architectural
risk analysis informs the tests. The feature of penetration
testing is that it gives a full understanding of the final software
in its real environment. However, any such testing that doesn't
take the software architecture into account it won't uncover
anything needed about software vulnerabilities and risk.
Software that fails during the kind of canned black box testing
practiced by prefab application security testing tools is truly
bad. Thus, passing law-octane penetration test reveals little
about your actual security status or experience , but failing a

Artifact: Units and system

Example of risks found: Extent of data leakage possible by
leveraging data protection, risk analysis results, and abuse
cases.
3.5 Abuse Cases

Abuse cases are tool that will help you to figure out how the
attacker contemplating to attack the system or to know how
the system behavior will be under attack ,so building an abuse
case (sometimes called misuse cases as well ) allows thinking
beyond the normative features and functions and also
contemplating negative or unexpected events, software
security professionals come to better understand how to create
secure and reliable software. by asking some questions
like(What might some bad person cause to go wrong here? )
or better yet, "What might some bad person cause to go wrong
here?" software development team are more likely to uncover
exceptional cases and frequently overlooked security
requirements.
Building abuse cases is a great way to get into the mind of the
attacker. it's the same of building use cases, but abuse cases
describe the system's behavior under attack; building abuse
cases requires explicit coverage of what the parts should be
secure and protected , from whom (target ), and for how long
(determine the time if possible).

overt functional security by applying for example

cryptography. And emergent characteristics by applying abuse
cases(which is defined previously in 3.5 section)
Security Requirements Vs. Abuse case
Security requirements specify the security apparatus for
software systems. In addition to capturing and describing
relevant attacks, abuse cases allow an analyst to think
carefully through what happens when these functional security
mechanisms fail or are compromised.

Artifact: Requirements
Example of risks found: No explicit description of data
protection needs.
3.7 Security Operations

Creating Useful Abuse Cases

The simplest, most practical method for creating abuse cases
is usually through a process of informed brainstorming. There
exist a number of theoretical methods that involve fully
specifying a system with rigorous formal models and logics,
but such activities are extremely time and resource intensive.
The good news is that formal methods are often unnecessary
in the real world. A more practical approach that covers a lot
of ground more quickly involves forming brainstorming teams
that combine security and reliability experts with system
designers. This approach relies heavily on experience and
expertise.

Software security can benefit highly from networks security.

Well-integrated security operations allow and encourage
network security professionals to get involved in applying the
touchpoints, providing experience and security knowledge that
might otherwise be missing from the development team.
Battle-scarred operations people carefully set up and monitor
fielded systems during use to enhance the security posture.
Attacks do happen, regardless of the strength of design and
implementation, so the defensive technique can be executed
by gathering Knowledge about software behaviors that are
causing the attack and definitely exploits should be cycled
back into software development.

Artifact: Requirements and use cases.

Example of risks found: Susceptibility to well-known
tampering attack.
.
3.6 Security Requirements
The most important level in security is the requirements level
that deserves broad treatment, to obtain good security
requirements we must cover overt functional security and
emergent characteristics.

Artifact: Fielded system

Example of risks found: Insufficient logging to prosecute a

known attacker.
* External Analysis
This is not one of the touchpoint activities and it's not a
priority element as the previous activities . External analysis
such analysis by someone outside the design team , is often
important when you mention security subject while
implementation or testing phase. All software security
touchpoints are best applied by someone outside the team that
not involved in the design and implementation phases of the
system.
Every programmer has been stuck for hours working on a bug
only to have a buddy (coming to drag you off for pizza) show
up and point out the error: "How come you did that?!" This
always explain a huge groan. This phenomenon can happen in
all stages of the software lifecycle one reason why external
analysis is a necessity.[1]

4. CONCLUSION
Most of Methodology to software security are way too bulky
for most project to be followed by any company or team . By
reducing the touchpoints to seven best practices, McGraw hope
to make effective best practices easier to adopt while still
making a huge impact on software security. The touchpoints
are not only changeable to whatever process you already
follow to make software but also simple and easy to use. If you
apply the seven terrific touchpoints outlined here, your
software will be much more secure.

5. REFERENCES
[1] McGraw,G.Software
Wesley,2006.

Build

Security

In,Addison-

[2] http://cwe.mitre.org/data/definitions/251.html
[3]
http://www.drdobbs.com/the-7-touchpoints-of-securesoftware/184415391