Applying the SDL Framework to the Real World 295
of threat agents and their attack methods whose targets are similar to
the system under consideration. In these strategy sessions, the security
architect should also have a good feel for emerging trends in threats and
attack methods. What new threat agents are just beginning to become
active? Of these new threats, what will be their likely attack methods? As
the threat agents’ organization and sophistication grow, how might they
expand attack patterns? With these sorts of questions, the architecture can
be designed not only for the intended use cases of the present, but also
for the foreseeable future. Typically, enterprise-level architects consider
similar questions regarding the growth of the organization, growth in user
populations, growth in data, and expansion of capabilities. The same sort
of consideration should be given to security needs of the future just as
much as for the present.
Out of any architecture assessment will come requirements that the
architecture must meet. Typically, early requirements are of a more gen-
eral nature: Users will be authenticated, systems will need to be hardened,
Payment Card Industry (PCI) certification (at the appropriate level) will
need to be met, and so forth. The details will then be baked into the
emerging architecture.
As architecting the system proceeds in earnest, the security require-
ments will begin to take on specificity. A particular authentication sys-
tem will be chosen: For a major server farm, for instance, a system may
be chosen which can handle millions of authentications per minute, can
handle millions of user identities, can interface with the appropriate run-
time and execution environments, and so forth. Or, if the authentication
system will be very modest, perhaps there is an integral library, or another
module which will suffice. Using the former implies tremendous growth
and heavy user traffic, perhaps even heterogeneous systems. When using
the latter authentication system, the smaller library may preclude major
server farm growth. In considering the intended use (say, an authentica-
tion system for a customer-deployable appliance), a relatively constrained
mechanism may be warranted. In any event, a particular choice will be
made based on the requirements of the system in the intended deploy-
ment and with respect to the expected growth. The architecture will grow
more specific and particular. The output of the security architecture pro-
cess is specific components providing particular services and communi-
cating using known protocols.
For systems within an existing architecture, any change to that archi-
tecture may have security implications, so the security of each architectural
296 Core Software Security
change should be considered. For instance, the addition of a third-party
partner to whom finance data may flow will engender the addition of
mechanisms to protect that finance data in transit. Further, protections
will need to be put into place such that only the intended partner will be
able to interact. In other words, the security needs of an existing architec-
ture will change in the face of new components, or new communication
flows, or new data types. Changes to any part of the architecture must
be considered in light of the whole architecture, of all the existing secu-
rity services. This work is very similar if not identical to the design work
when building an entirely new architecture. Hence, we specify architec-
tural assessment of the security of the system after the security strategy
for the system has been considered or when any architectural changes are
being made to an existing system. This set of SDL task flows presumes
that the existing architecture has been through a holistic, thorough secu-
rity assessment as required for an entirely new system. If there has been
no previous security assessment, then the existing architecture should be
treated as entirely new.
Once the architecture and all its ancillary components, including the
deployment model and any infrastructure involved, is thoroughly under-
stood, a threat model should be built. A threat model involves setting
trust boundaries and identifying attack surfaces. Every attack method is
not germane to every system. Importantly:
• Deployment models open or close attack surfaces.
• Execution environments provide services and attack surfaces of their
own, which are inherited by the system.
• Existing infrastructure will bequeath security postures and weak-
nesses to the systems deployed on it.
• Different languages and runtime models deliver unique strengths
and weaknesses.
Some components will be more exposed, and thus untrusted, while
other components may need to be shielded, or lie at the heart of a trust
boundary.
Consider the interaction between a user interface and a piece of soft-
ware that must become part of an operating system (e.g., a kernel driver).
The user software will be an obvious point of attack. The attacker might
be after the user’s data or communications. Or the attacker’s goal may be
Applying the SDL Framework to the Real World 297
control of the operating system through the user interface to the kernel
driver. A kernel driver that is poorly protected can be an avenue for privi-
lege escalation. A kernel driver becomes a part of the most trusted heart
of the operating system. The user interface component should protect
itself, but also the kernel driver. However, recognizing that protections
fail, the kernel driver must protect itself as well. The driver must also
protect the operating system, and not add any vulnerability to the kernel,
the highest-privilege core of the operating system.
It should be obvious that there is a natural trust boundary between the
user interface module and the kernel driver. It should also be obvious that
any threat model built for this simple system should consider not only the
user interface, the obvious attack surface, but also the interchange or flow
between user software and kernel. The user software may choose to trust
the kernel driver. However, under no circumstances should the kernel
driver accept communications from any module except the user inter-
face as intended. Also, that user interface must be highly self-protective
against attempts to use it as a way to get to the kernel. From this very
simple threat model, you can see emerging security requirements that
must be built into the architecture and design:
• User interface input validation
• Intermodule authentication
• Kernel input validation from the user interface (in case the authen-
tication or the user interface’s input validation fails)
Depending on the operating system, there may be a slew of require-
ments concerning load order, execution permissions, installation mecha-
nisms, configuration file permissions, configuration file validations, etc.
We do not believe that threat modeling is sufficient by itself.* The
threat model requires the output from the architecture analysis: complete
* Threat modeling systems such as Microsoft’s STRIDE make assumptions that we
do not. STRIDE assumes that the modelers will already be intimately familiar with
the target system’s architecture, as any mature, heterogeneous development team is
likely to be. For highly shared security architects, however, this will likely not be the
case. Further, STRIDE’s aim is to empower non-security-trained development teams
to make a start. Hence, STRIDE is purposely simplified. We applaud STRIDE and
similar methodologies. If your situation matches the intended purpose of STRIDE,
we encourage you to employ it.
298 Core Software Security
understanding of all the components, flows, and data. An architecture
analysis identifies security feature requirements (that is, to fulfill the secu-
rity needs of the potential users). Without this information, the threat
model may be incomplete. With the architecture structure and the secu-
rity requirements in hand, a threat model can be built to understand the
attack surfaces that will be presented by the system. Since, as noted previ-
ously, every attack is not credible against every system, the threat model
considers likely attack scenarios based on analysis of the preferred attack
methods promulgated against similar systems.
It is always true that any requirements output from the threat model
will create new test plan items. These new test cases ensure that the secu-
rity requirements have been built correctly. Thus, if the threat model pro-
duces requirements, the test plan will receive new test cases. Security test
cases are dependent on architecture analysis and threat modeling.
Generally speaking, if there is no architectural change, then archi-
tectural analysis and threat modeling can be bypassed. (This assumes
that the existing architecture went through security assessment and
threat modeling.)
The design of the system must implement all the requirements given
from the architecture. If an architecture is the structure, flow, and data,
then the design is the expected implementation of that structure. The
design must have enough specificity that it can actually be coded.
Given adequate, clear, and detailed enough requirements or user
stories (Scrum), skilled software designers generally have no trouble trans-
lating architecture and its requirements into a software design. This can
be done before coding in a Waterfall process, or for each incremental
build cycle in an Agile process. In either process case, it’s important to pay
particular attention to the security features and requirements. These must
be absolutely correct or the implementation may open up vulnerabilities
or, worse, create a new, unprotected attack surface. The logic has got to
be watertight for critical security functions such as encryption routines
or authorization schemes. Users of the system will be depending on these
features to protect their resources.
We place a security design review at a point when designers believe
that the design is very nearly completed. A security design review should
be performed by a security assessor who understands the architecture
and functionality well; usually, the review is best done by someone who
has experience designing and even implementing security features. We
Applying the SDL Framework to the Real World 299
further suggest that the reviewer be independent of the design team. Peer
review is a powerful tool for validating design correctness and complete-
ness. Another set of eyes can often spot errors which those closer to the
design may have missed. If any security features or requirements are to be
built in the current cycle, perform a security review.
As has been noted, every portion of the intended design must engen-
der a thorough functional test plan. This is true of security just as well
as any other part of the design. If Transport Layer Security (TLS) is to
be added as an option to the network protocol stack, the test plan must
include a test with and without TLS, each case having a pass condition.
Security in the design always means security in the test plan.
How does an organization train people so that they can perform these
difficult, architectural tasks? Software security expert Gary McGraw says:
For many years I have struggled with how to teach people . . . security
design. The only technique that really works is apprenticeship. Short
of that, a deep understanding of security design principles can help.
14
McGraw’s statement implies that, in order to build a qualified team,
each organization will either have to invest in sufficiently capable and
experienced practitioners who can also mentor and teach what they do,
or hire consultants who can provide appropriate mentorship. Neither of
these is likely to be cheap. As of this writing, there is a dearth of skilled
security architects, much less the subset of those who can and want to
impart what they know to others. The architecture and design skills
neces sary to an SDL program are probably going to require time to build,
time to find key leaders, and then time for those leaders to build a skilled
practice from among the available and interested people at hand. In one
such long-running mentorship, even highly motivated junior people have
taken as long as two or three years before they could work entirely inde-
pendently and start to lead in their own right. This is a significant time
investment.
*
In the same blog entry quoted above, McGraw cites Salzer
and Schroeder’s seminal 1975 paper, “The Protection of Information
in Computer Systems,”
15
as a starting point for a set of principles from
* Please note that not every person who begins training will have the aptitude and
motivation to finish. Our experience is that between one-third and one-half of those
starting will not become security architects.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.