Applying the SDL Framework to the Real World 275
once they are properly configured and tuned. However, if there are vul-
nerabilities, this is the bottom line. These “must not pass” into execut-
able objects that then have the potential for getting into production uses.
“Trust, but verify.” We recommend empowering coders to verify their
work while also verifying implementations before these can be fully com-
mitted for potential release.
At the heart of every development lifecycle, there are three processes that
interlock and complement each other to deliver secure code. Developers
need to be trained and have the discipline to try and write correct, error-
free, vulnerability-free code. This practice and discipline will require train-
ing, practice, and a space in which developers can make mistakes, try new
things, learn, and be relatively free during the learning process. It takes
astute management to work with high-functioning, creative people who
are learning their craft while practicing it at the same time. After the code
is written, the next core step of the secure build process is manual code
review. Like secure programming, manual code review is also a disci pline
and a practice. Code review is also an opportunity for learning and mas-
tery; manual code review is the other side of writing correct code. Great
code reviewers become great coders. Great coders become great code
reviewers. The two processes work hand in hand to deliver cleaner code
and more sophisticated programmers. Finally, at the heart of the devel-
opment process, checking and complementing the code review, is static
analysis. Complementing the human element, static analysis is an auto-
mated procedure that looks holistically across multiple dimensions at the
same time. Whether Waterfall or Agile, secure coding, code review, and
static analysis should lie at the heart of any secure development lifecycle.
9.2 Determining the Right Activities for
Each Project
9.2.1 The Seven Determining Questions
Recurring often, continually, and across every organization with which
we’ve worked, is a sense from developers and engineering teams that add-
ing security will be yet another impediment to delivery. It’s important to
note that many if not most software organizations reward at least in part
upon the delivery of features on time, and under budget. Typically, the
276 Core Software Security
focus on timely delivery is well embedded at the point when a software
security practice is started or improved. It is only natural that teams will
want to know how, in their already busy schedules, they will manage to
accomplish a series of what appear to be additional tasks.
Obviously, one can argue that developers should have been integrating
security into development practices already. Interestingly, many times,
teams have responded that they are, in fact, doing just that: producing
“secure” software. “Secure” here is an operative term; “security” has no
precise meaning and is highly overloaded.
Digging a little deeper, we will be told that the authentication mecha-
nism for the software has been well thought through and is built and
tested. Or, perhaps, all communications going over the network can be
placed within an encrypted tunnel (usually, TLS). Rarely, previous to the
instantiation of a strong SDL program, do teams respond in a holistic
manner, acknowledging the range of tasks that must receive attention,
from design through testing. And that is precisely the problem that work-
ing with the SDL is supposed to address: holistic, built-in security, soup
to nuts, end to end.
Because security is often presented as a matrix of tasks, teams may see
the large number of tasks and become overwhelmed as a result. Time and
again, we have heard team leads and development managers ask, “What
do I have to do?” Since the answer to that question really should depend
on the type of project at hand, the security architect may answer, “Well,
that depends.” This answer is not very satisfying to people who have made
a practice out of timely and orderly software delivery: product managers,
project managers, technical leads, and development managers.
Then, the security person will be asked, “What is the minimum set of
activities that my project will have?” Requesting a minimum task set is cer-
tainly a relevant and worthy question. The answer, “Well, that depends,”
is once again not at all satisfying. We realized that having the security
architect as the sole arbiter of what must be done too often makes a mys-
tery of the entire process. Planning becomes more difficult. Yet again,
security is seen as a hindrance and an obstacle, not as one of the required
deliverables that must be a part of production software.
After much trial and error over many years, on divergent develop-
ment groups operating within multiple enterprise organizations, we
have crystallized a set of questions that can be easily answered by pro-
ject managers, architects, technical and engineering leads, and/or product
managers. These people typically have the understanding to assess the
Applying the SDL Framework to the Real World 277
amount of planned architecture and design change, whether there will
be additions of sensitive data and third-party code, the types of interfaces
to be added or changed, and the expected deployment models. Each of
these dimensions influences which security activities must be executed
in order to generate the correct set of security features and requirements.
Some of these dimensions determine what types of security testing will be
required. Together, the answers to these questions will map the required
SDL security task flows to individual project circumstances.
We do not recommend a “do it all” approach. Threat modeling addi-
tions that make no substantive change to a previously and thoroughly
analyzed security architecture delivers no additional security value. Plus,
requiring this step when it has no value will not engender trust of secu-
rity’s process judgment. Engineers often spot valueless activities (they
tend to be smart, creative people!). Nobody likes to waste time on useless
bureaucracy. Most engineers will quickly realize that requiring dynamic
Web testing when there is no Web server has no value. Rather, let teams
exercise their skills by allowing them to answer fundamental questions
that sensibly add activities only when these are applicable.
These questions can be asked up front, at the beginning of the develop-
ment lifecycle, or at appropriate stages along the way. Timing is critical.
Answering each question after the appropriate time for the associated
activities in the SDL has past will cause delays; required security tasks will
be missed. As long as each question is asked before its results are needed,
your security results will be similar. Architecture questions can be asked
before any architecture is started, design before designing, testing answers
need to be gathered for the testing plan, and so on throughout the life-
cycle. However, asking these seven determining questions at the very
beginning allows those responsible for budgeting and resource allocation
to gather critical information about what will need to be accomplished
during development.
1. What changes are proposed? (The following answers are mutually
exclusive; choose only one.)
a. The architecture will be entirely new or is a major redesign.
b. The architecture is expected to change.
c. Security features or functions will be added to the design.
d. Neither changing the architecture nor adding security features
to the design will be necessary (i.e., none of the above).
2. Will any third-party software be added? Yes/no
278 Core Software Security
3. Will any customer data (personally identifying information [PII]) be
added? Yes/no
4. Will this organization or any of its partners host any of the systems?
Yes/no
5. Is a Web server included? Yes/no
6. Will there be any other inputs to the program? (i.e., non-Web input,
configuration file, network listeners, command line interfaces, etc.)
Yes/no
7. Is this a major release?
Very early in the process, even as the concept begins to take shape, it’s
important to ask, “What’s new?” That is, find out how much change is
intended by this project, through this effort. The question is meant to be
asked at the architecture level; there are four possible answers:
1. Everything is new. This is a “greenfield” project or a major redesign.
2. The architecture will change significantly.
3. Security features will be added to the architecture or design.
4. None of the above.
What changes are proposed?
When everything will be new, there are certain pre-architectural activi-
ties that can help determine the set of requirements and features that will
meet the security challenges for the intended use and deployment of the
software. Figure 9.4 illustrates the task flow for projects that are com-
pletely new, involve major redesign, or where the system has never had
any security review. Having a complete set of requirements has proven to
deliver more inclusive and effective architectures, by far. Among the com-
plete set of requirements must be security. The goal is to “build security
in,” not to bolt it on later. If the required features are not included in the
architecture requirements, they most likely will not get built. This forces
deployment teams to make up for missing security features by building
Figure 9.4 Architecture task flow when a project is new or a redesign.
Applying the SDL Framework to the Real World 279
the required protections into the encompassing runtime or infrastructure,
often as a “one-off,” nonstandard implementation.
When everything or almost everything will be new and there is no
existing, legacy architecture or design for which architects must account,
there is an opportunity to thoroughly consider not only current threats
and their attacks, but the likely attacks of the future against which the soft-
ware must protect itself. This kind of early, strategic thinking is rare in the
world of software re-use. It’s a great advantage to take the time and think
about what the security system will need holistically. Software security
strategy is best done before making decisions that cause the secure design
course to be ruled out entirely or made much more difficult to implement.
If the architecture is changing, then the process should start at archi-
tecture assessment and threat modeling. Figure 9.5 describes the task
flow. The changes must be examined in light of the existing architecture
so that any additional security requirements can be smoked out. The
assumption is that the existing architecture has been assessed and threat-
modeled to ensure that appropriate security requirements have been built
into the design. In cases where there never has been an architecture assess-
ment and threat model, the architecture should be treated the same as a
greenfield project.
Even if there are no additions or changes to the existing architecture,
adding any feature with security implications indicates the necessity for
design work. The design makes the architecture buildable. Programmers
work from the design. So it’s important that any security requirement or
feature be designed correctly and completely. Security expertise is critical;
the purpose of the design review is to ensure that the appropriate security
expertise is applied to the design. Figure 9.6 shows the flow of these two
design-related SDL tasks.
Like any other feature or function, every security function must be
thoroughly tested for correctness in the test plan. Creating the test plan is
part of the design work. The test plan is an artifact of the design.
Figure 9.5 Architecture task flow when there will be changes to the
architecture.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.