Applying the SDL Framework to the Real World 285
public Internet, it will be attacked constantly and must prepare itself to
defend against these common variations. However, even if the system will
normally be deployed on a more trusted network, we believe that strong
Web server dynamic testing is important. Sophisticated attackers some-
times manage to breach their way onto these trusted networks. A weak
Web server can be a target in and of itself, or a server can present a hop-off
point to more valuable targets. Therefore, it is good practice to identify all
Web servers in order to benefit from this specialized testing.
Will there be any other inputs to the program?
Beyond Web server inputs, there are myriad other inputs that may be
built into a system: command-line interfaces, configuration files, network
inputs, native forms, scripting engines, and so forth. Each of these is an
attack surface. Each input has the potential for a logic mistake that goes
around access controls such as authentication and authorization. Logic
mistakes may allow the misuse of the program to do unintended things,
such as sell a product for a reduced or nonexistent price. Additionally, in
programming languages where the programmer manipulates computer
memory directly, poor input handling may allow serious abuse of the
program or even the operating system. Memory-related errors often allow
privilege escalation on the system or permit code of the attacker’s choice
to run. Inputs are an important attack point in any program, often the
prime attack surface.
Before the test plan is written, all the inputs to the system should be
enumerated. Each of the enumerated inputs should be tested to deter-
mine that the correct input values are handled properly. Further, tests
must be run to prove that variations of incorrect input do not cause the
system to fail or, worse, act as a vector of attack beyond the boundaries of
the software (as in a buffer overflow allowing privilege escalation and code
of the attacker’s choice). A common tool as of this writing is a fuzz tester.
These tools simulate the many variations that attackers may run against
the software. Once a fuzzer is prepared for a particular input, it will auto-
matically run through a set of variations that attempt improper inputs.
The fuzzer will stop when the program begins to misbehave or crashes.
In this way, unsafe input handling, even improper memory handling, can
be smoked out. We recommend that every input that has been changed
during this development cycle be fuzzed.
286 Core Software Security
There is some overlap between what fuzzers cover and Web vulnerabil-
ity analysis tools. If testing time is short, we recommend that Web vulner-
ability tools be run against the Web server, and all other inputs be fuzzed.
However, it’s not a bad idea to overlap the vulnerability scan by fuzzing
the Web server’s inputs as well. Since Web scanning tools look for known
exploit patterns and fuzzers check generally bad input, employing both
types of dynamic analysis provides better coverage than using either alone.
The test plan will likely include both testing of intended security
functions and dynamic tests to ensure that no vulnerabilities have crept
through manual review and static analysis, as indicated in Figure 9.9.
Is this a major release?
The seventh and last question is about the importance of this project or
release in relationship to the software as a whole. Are the additions to the
software in this development cycle going to be considered a major addition
and/or revision? If there are going to be significant architectural changes,
possibly accompanied by major feature additions or maintenance revi-
sions of currently running code, there is a likelihood of introducing subtle
logical changes, perhaps even errors, into the code base. Some of the most
subtle bugs occur due to unintended side effects affecting other pieces of
the code. Indeed, it is very hard to test thoroughly for inter actions; this
is particularly true when adding new features whose side effects interact
with legacy code in unanticipated ways.
In addition, consumers of software tend to expect more from larger
revisions. A major release will tend to get more scrutiny and perhaps
wider distribution than a minor update.
For these reasons, it may be worthwhile considering a more
thorough and holistic look at the security properties and vulnerabili-
ties of a major release when the release is considered “code complete.”
Figure 9.9 Test plan ingredients.
Applying the SDL Framework to the Real World 287
This can be accomplished through an independent attack and penetra-
tion. “Independent” in this context means independent from building
the software and testing it. Since penetration testing requires significant
skill, experts should be employed. It should also be remembered that no
two testers deliver the same results; each penetration test is more or less
unique to the tester and to the software under examination. Therefore,
it is good practice to have a major release penetration test performed by
someone with significant skills in the deployment model, execution stack,
and even language in which the software is written. Failure to match tes-
ter to software type will likely deliver suboptimal results. You want a tester
who understands how to attack the kind of software you’re producing.
Through the application of a highly skilled attacker against your
software, you can discover the sorts of vulnerabilities that sophisticated
attackers will likely find and exploit. Subtle and sophisticated errors can
be uncovered and fixed before the software goes live. Plus, you will have a
much clearer picture of any residual risks in this release.
In this way, you can deliver both to your organization and to the con-
sumers of the software assurance that the software is indeed self- protective
as well as correct. We have found that for highly competitive markets
and/or widely distributed software; a provable penetration test can be a
competitive advantage, demonstrating not only the security of the soft-
ware but also the commitment of the software maker to customers’ safety.
Answering these seven determining questions can control security task
flow for both Waterfall and Agile processes. Placement of the appropriate
activities into each flow of development differs. These differences will be
described below.
The answer to each of the seven questions answers “What is the mini-
mum set of activities my project must perform?” However, it should
never be suggested to teams that they can’t supplement the minimum set
with other activities if these might provide additional security value. For
instance, if there’s time, even threat modeling an existing architecture and
design may uncover something useful. Attack patterns change over time;
yesterday’s popular attack may be superseded by another, easier or more
successful approach.
Ask “What’s new?” to assess the scope of proposed change. There are
additional activities that flow from each answer. And these earlier, more
architectural activities will lead to the later design, build, and test tasks.
Tables 9.1 and 9.2 describe the selection of activities.
Table 9.1 Architecture and Design Activities Indicated by SDL Determining Questions
Question Step 1 Step 2
Greenfield or redesign? Determine the required security
posture and the intended security
strategy with the stakeholders.
Generate the high-level security
requirements.
Perform “architecture change” steps
flow (see Figure 9.4).
Architecture change? Review the architecture for security
and create a threat model for
architecture. Produce architecture
requirements.
Perform “adding security features”
flow (see Figure 9.5).
Will any security features be added? The design must be reviewed to
ensure correctness and eliminate
logical vulnerabilities.
Add functional tests for each security
feature to the test plan.
Are you adding customer data
(personally identifiable information
[PII])?
Conduct a privacy review.
Are any systems to be hosted by the
organization or its partners?
Review infrastructure security. Perform a third-party vulnerability
test on the software in the
infrastructure before release.
Table 9.2 Coding Imperatives and Testing Activities from SDL Determining Questions
Question Step 1 Step 2
Are you adding any third-party
software?
Perform a legal licensing review. Post-release, monitor for
vulnerabilities that are discovered
in the third-party software.
Is this a Waterfall build cycle or a
cycle of Sprints in Scrum/Agile?
Code securely.
Perform manual code review.
Run static analysis.
Fix defects as discovered.
Is there a Web server? Perform Web dynamic vulnerability
testing.
Fix defects.
Is there a need to enumerate other
inputs?
Fuzz all non-Web inputs. Fix defects.
Is this a major release? Consider an independent vulnerability
assessment and pen test.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.