Applying the SDL Framework to the Real World 265
essentially follow a foreshortened SDL cycle to get the errors remediated,
tested, and released.
Testing shows the presence, not the absence of bugs.
2
Out of the population of extant errors, some proportion will have
effects that can be manipulated to the advantage of an attacker; that is, these
errors will be security “vulnerabilities.” We focus here on vulnerabilities.
There is reasonable certainty that developers will produce incorrect
code at least some of the time and some of those errors will be subject
to malicious manipulation, ergo, there will be vulnerabilities in the
code. This is not a reason to abandon efforts to write correct code. The
advantages of correctness at the outset far outweigh the expenditure; it
is an established fact that achieving correctness as early as possible in the
develop ment cycle is by far cheaper and easier. The earliest point will be
when the code is written.
There are several complementary activities that, when put together,
will contribute to fewer security defects as code is being written: developer
training, safe libraries, and proven implementations generalized for reuse.
Obviously, developers must know what is expected of them, where
to pay attention to security, and what the correct behavior is that must
be programmed. Any and all training approaches have benefit, although
some approaches have less effectiveness than may be obvious.
Developers should understand, at a very high level, that some defects
have profound effects within the software they write. Functional speci-
fications describe how the software will be used. Among these specifi-
cations will be those security attributes and features that users and the
owners of the software require. Generally, that which has been specified
gets built. That is not to say that errors don’t creep in; they do. But since
the properties are a part of the requirements, developers have an organic
exposure to systems such as authentication and authorization, and to the
API functions and classes that implement communications protections,
such as TLS/SSL. If specified, the developer will generally attempt to
build the functionality.
The security industry has primarily been interested in vulnerabil-
ity (something that can be exploited), that is, in security weakness.
Vulnerabilities are defects that when manipulated cause side effects
that can be used to advantage; vulnerabilities are bugs. Since security
266 Core Software Security
practitioners ultimately must assess risk, a part of which is vulnerability,
it is a natural focus of the occupation. Unfortunately, developers do not
focus on vulnerability. They must focus on correctness. Is the algorithm
written correctly? Does this code implement the specification exactly?
Will this logical series produce the correct paths? Is this code clear enough
to be maintained by someone who has never seen it before? Will this code
reject invalid input? Can this code fail and the program recover after that
failure? These are the sorts of questions that dominate developer thinking.
Vulnerability is generally a side effect of error, often not an error by itself.
Tracking back from vulnerability to defect or code error is one of the
big misses in information security as of this writing. Security people talk
about vulnerability. Developers want to know where the bug is and how
to fix it: Developers typically ask, “What is the correct behavior that must
be implemented?”
It’s useful for coders to understand that bugs can make a program vul-
nerable. However, training should focus on what is correct, self-defensive
behavior. US-CERT’s Key Practices for Mitigating the Most Egregious
Exploitable Software Weaknesses
3
are a refreshing start, focusing on cor-
rect, secure programming. The focus of this publication is not vulner-
ability side effects or attack patterns, but rather, on the system pro perties
and algorithms that will prevent issues. For instance, for cross-site script-
ing (XSS, also represented as XXS) errors, which are endemic to today’s
Web applications, Key Practices recommends complementary program-
ming solutions that together will prevent XSS. The following quote rec-
ommends a specific algorithm which would then be “correct” and also
prevents one variation of the vulnerability, XSS.*
When the set of acceptable objects, such as filenames or URLs, is
limited or known, create a mapping from a set of fixed input values
(such as numeric IDs) to the actual filenames or URLs, and reject
all other inputs.
4
Training that focuses on correct behavior is a key to fewer security
vulnerabilities. A secure coding training program might begin with the
neces sary high-level attributes of a secured system. There are any number
* The algorithm quoted is not intended to be an XSS “fix-all”; it is chosen for specifi-
city, not for its completeness.
Applying the SDL Framework to the Real World 267
of security design principle collections. The Open Web Application
Security Project (OWASP) provides a distillation of several of the most
well known sets of principles:
• Apply defense in depth (complete mediation).
• Use a positive security model (fail-safe defaults, minimize attack
surface).
• Fail securely.
• Run with least privilege.
• Avoid security by obscurity (open design).
• Keep security simple (verifiable, economy of mechanism).
• Detect intrusions (compromise recording).
• Don’t trust infrastructure.
• Don’t trust services.
• Establish secure defaults
5
Even if developers thoroughly understand these principles without
further training, as they design and implement, security correctness will
be one of the key attributes that will emerge as programs take shape.
Training must be readily available and easily consumable. Generally,
week-long courses are very difficult to schedule broadly due to lost pro-
ductivity and lost opportunity costs. While an immersive approach cer-
tainly has benefits, any material that is not quickly applicable to tasks at
hand may be rapidly lost. Instead, shorter segments that can be taken
in small doses and then practiced on the job will likely deliver better
results. One pattern that we’ve found very effective is to establish a base-
line understanding and skill level with:
• High-level application vulnerability introduction
• Secure design and coding principles
• Three to five required, easily understandable short courses (30 min-
utes maximum), demonstrating correct fixes for common vulner-
abilities applicable to the developer’s platform and language.
Once the baseline training has been established, provide additional
training on common fixes. Training in these commonly encountered pat-
terns must be easily consumable. Developers tend to be very jealous of
their time. Alongside highly focused, shorter pieces, also provide more
268 Core Software Security
i n-depth training on software security. In this manner, developers may
follow their own interests. If they have to fix a particular error, they may
choose to take the short, focused training. Or, if they catch the “security
fire,” they may want to pursue such deeper topics as encryption implemen-
tations or access control systems. Any training program should remind
engineering staff that security skills are marketable and a premium skill.
Training by itself is less effective without opportunities to use the
learned skills. Practice definitely makes perfect. This is a strong reason to
give developers time between training sessions to apply the new skills. A
natural rhythm of training then practice should be established:
• 30–60 minutes of secure coding training
• Several weeks of practical application
Those who become experts can assist those with less skill. Further,
these experts become senior code reviewers, capable not only of finding
defects during manual code review, but also disseminating the correct
approaches and algorithms.
Alongside a robust secure coding training program, thoroughly
debugged implementations can be created. These libraries should be
designed to generalize solutions across many implementations. They
should provide easily implementable Application Programming Interfaces
(APIs) to the correct implementations contained within the library. These
correct libraries may then be included in each software project with the
knowledge that security has been well implemented. And, if an error is
found in the library, it can be fixed in only one place rather than in many
disparate implementations.
The OWASP Enterprise Security API
6
is an example of a vetted imple-
mentation that solves various security problems within a Web applica-
tion. For instance, to prevent XSS, there are functions that will validate
all input against a whitelist before passing on the input for use within the
application:
All input must be validated against a strict whitelist pattern using
the Validator.* methods before used.
7
Whether correct APIs are built internally or acquired, these should
be a key technology to ensure that code is correctly secure. Creating and
using vetted libraries ensures that correct implementations are used and
Applying the SDL Framework to the Real World 269
reused. This will also avoid the problem of implementation errors creep-
ing into each coder’s individual realization.
Another solution that may be of help is pairs programming. Kent Beck
defines pairs programming as follows:
Pairs of programmers program together. Pairs don’t just make test
cases run. They also evolve the design of the system. Changes aren’t
restricted to any particular area. Pairs add value to the analysis,
design, implementation, and testing of the system. They add that
value wherever the system needs it.
8
In this manner, both design and implementation are improved by the col-
lective skill of the pair of programmers.
Writing secure, correct code is a product of several approaches taken
together. Training complements practice. Practice creates expertise that
can be applied to vetted implementations, which can be reused to mini-
mize implementation errors. Collaborative approaches build team exper-
tise while catching errors during the writing process. However, secure
writing is not enough; correctness must be verified.
9.1.2 Manual Code Review
Due to the expressive nature of computer languages and the infinite vari-
ety of logical problems tackled in programs, it is important to employ
independent, skilled reviewers who can provide a safety net for the coder,
and a check on correctness. Manual code review is particularly good at
finding errors in the logic of the code. If the reviewer understands what
the code will be doing but has not been involved in writing the code, he
or she can often spot errors, especially logical errors. The reviewer can
certainly check to see that coding standards have been adhered to. If the
reviewer has security expertise, she or he may also spot security defects as
well. Since there is a dearth of secure coding experts, it may be necessary
to focus on logical and stylistic elements. However, if every developer
is trained in basic defensive programming, particularly with respect to
inputs, manual code review can at least find the egregious input valida-
tion errors that plague so much of the code produced today. In any event,
code review is not panacea. While it is possible to get expert manual code
reviewers who can literally rewrite your code to be not only secure but
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.