133
Chapter 5
Design and
Development (A3):
SDL Activities and
Best Practices
The design and development (A3) phase (see Figure 5.1) is when the
end user of your software is foremost in your mind. During this phase
you will do an analysis of policy compliance, create the test plan docu-
mentation, update your threat model if necessary, conduct a design secu-
rity analysis and review, and do a privacy implementation assessment so
you can make informed decisions about how to deploy your software
securely and establish development best practices to detect and remove
security and privacy issues early in the development cycle. You will per-
form static analysis during both the design and development (A3) and
the ship (A4) phases of your SDL . We will provide a detailed description
of static analy sis in the next chapter. You will build the plan for how you
will take your project through the rest of the SDL process, from imple-
mentation, to verification, to release. During the design and development
(A3) phase you establish best practices for this phase using functional and
design specifications.
Figure 5.1 Design and Development (A3): SDL activities and best practices.
Design and Development (A3): SDL Activities and Best Practices 135
5.1 A3 Policy Compliance Analysis
A3 policy compliance analysis is a continuation of the A2 policy compli-
ance review described in Chapter 4. During this phase, any policy that
exists outside the domain of the SDL policy is reviewed. These might
include policies from outside the development organization that set
security and privacy requirements and guidelines to be adhered to when
developing software or applications. Corporate security and privacy poli-
cies will likely instruct designers and developers on what the security and
privacy features need to be and how they must be implemented. Other
policies might focus on third-party and open-source software used as part
of a software product, or on the protection and control of source code and
other intellectual property within and outside the organization. Assuming
the software security group is separate from the centralized information
security group, it is important that both groups collaborate on all policies
and guidelines related to the development and post-release security sup-
port and response of software from that organization. It is also important
to collaborate with the privacy function of your company, whether it is a
centralized group or outside legal counsel.
5.2 Security Test Plan Composition
Testing activities validate the secure implementation of a product, which
reduces the likelihood of security bugs being released and discovered by
customers and/or malicious users. Software assurance and competency
from a security perspective is demonstrated by security testing and the
use of artifacts, reports, and tools. The goal is not to test for insecurity,
but rather to validate the robustness and security of the software products
before making the product available to customers. These security test-
ing methods do find security bugs, especially in products that may not
have undergone critical secure development process changes. The results
of security testing and evaluation may also uncover deficiencies in the
security controls used to protect the software that is under development.
A detailed plan of action and milestone schedule are required to docu-
ment the corrective measures planned to increase the effectiveness of the
security controls and provide the requisite security for the software prior
to its release.
136 Core Software Security
As with the risk analysis methodologies discussed in Chapter 4, a
holistic approach is necessary for security testing to be effective. Security
testing confirms that the software complies with security requirements
through design and code analysis and software behavior investigation.
In other words, security testing is conducted to demonstrate that the
software functions as specified by the requirements, and every software
requirement must be tested using at least one relevant test case. The num-
ber of requirements tested versus the total number of requirements can
be traced from test cases to functional requirements; then the ratio of
requirements tested to the total number of requirements will become a
test requirement metric.
Another element of security testing is to identify software weaknesses
so that security violations and noncompliance with security requirements
that could cause the software to fail or be out of compliance with any of
software security requirements are avoided. As discussed in the risk analy-
sis ranking section, due to resource limitations, security test plan efforts
typically focus only on software requirement items that are considered
to be critical. A master test plan is used to outline the entire test process,
and is augmented by detailed test plans for individual test stages and indi-
vidual modules.
While traditional requirements-based testing is important to the cor-
rectness and adequacy of security functions implemented by software,
no amount of testing can fully demonstrate that software is free from
vulnerabilities; any such testing can only provide a small-scale view of
what is needed to verify the security of the software. Even the most
robustly specified security requirements are not likely to address all pos-
sible conditions under which the software may be forced to operate in
the real world, including the behavior of software under anomalous and
hos tile conditions.
Generally, the shortcomings of requirements-based over risk-based
software security testing can be summarized as follows:
• The changing nature of threats to the software you have in develop-
ment may result in new attack methodologies both pre- and
post-release.
• Your software may change its position as a functional component of
a SaaS or cloud-based solution, which may also change the attack
surface and thus require new security fixes or mitigations.
Design and Development (A3): SDL Activities and Best Practices 137
• In today’s competitive and rapidly changing environment, the design
assumptions on which the requirements were based may be obsolete
by the time the software is ready for testing.
• Other factors often change frequently and likely more rapidly than
your specification can keep up.
• If the software is going to use components acquired from a third
party, the original architecture may not account for future versions
that were not planned for in the initial implementation.
• The original design assumptions may not account for vulnerability
susceptibilities due to design changes or new external attacker capa-
bilities or exploits that may occur during the time taken to develop
later versions of the software.
This list highlights why software risk-based security testing as
described in this section should always augment traditional requirements-
based testing.
As mentioned previously and used as a continuing theme throughout
this book, problems found early in the software lifecycle by “building
security in” are significantly easier and less costly to correct than problems
discovered post-implementation or, worse, post-deployment. This is why
it is imperative that a disciplined approach to security reviews and tests
begin early in the SDL/SDLC process and continue post-release until the
software reaches end of life.
Software security testing takes the perspective that the tester is the
attacker. Test scenarios should be based on misuse and abuse possibilities
developed through the methodologies and threat modeling described in
Chapter 4, and should incorporate both known attack patterns as well as
anomalous interactions that seek to invalidate assumptions made by and
about the software and its environment. Comprehensive test scenarios,
test cases, and test oracles should be derived. Be sure that all that mis-
use cases developed in the previous stage are executed and thoroughly
tested. The testing of each development iteration, use case, and misuse
case will identify major design flaws early in the SDL and should catch
up to 95percent of defects well before the last phase.
1
The test environment should duplicate as closely as possible the antici-
pated execution environment in which the software will be deployed, and
it should be kept entirely separate from the development environment.
It should also provide for strict configuration management control to
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.