161
Chapter 6
Design and
Development (A4):
SDL Activities and
Best Practices
In this chapter we will describe the SDL activities for the design and
develop ment (A4) phase of our security development lifecycle (see
Figure6.1). This phase can be mapped to the “readiness” phase in a typi-
cal software development lifecycle. We start with the continuation of pol-
icy compliance analysis for this phase and then move on to describe the
elements of security test case execution. Building on the proper process
for security testing that should have already been created, documented,
and tested, analysis will continue until necessary tuning is identified in
order to accomplish the required security level. We then describe the use
of automated tools such as static, dynamic, and fuzz test tools to help
automate and enforce security practices efficiently and effectively at a
low cost. Static analysis analyzes the source code prior to compiling, pro-
vides a scalable method of security code review, and helps ensure that
secure coding policies are being followed. Dynamic analysis monitors
application behavior and ensures that the software functionality works
Figure 6.1 Design and Development (A4): SDL activities and best practices.
Design and Development (A4): SDL Activities and Best Practices 163
as designed. Fuzz testing induces program failure by deliberately intro-
ducing malformed or random data to an application and can be used as
an effective and low-cost way of finding potential security issues prior
to release and potentially throughout the SDL process. Fuzz testing is a
specialized form of dynamic analysis. By using the latest version of these
automated tools, the latest known automated security analysis, vulnera-
bilities, and recommended protections will be identified. After these
multiple automated tools have been used to quickly analyze the flaws
and vulnerabilities in the software, the code is then reviewed manually,
every issue validated, and the code inspected to overcome the limitations
of automated tools and techniques. As part of this process, attack surface
and threat model reviews will ensure that any new attack vectors that
have been created by any design or implementation changes have been
identified and mitigated. Finally, we discuss the need, value, and process
for privacy validation and remediation to be conducted during this phase
of the SDL.
6.1 A4 Policy Compliance Analysis
This is a continuation of the A3 policy compliance review described in
the previous chapter. As you will see, we continue to perform policy com-
pliance analysis during different phases and review it again and again. It
is of paramount importance that you persist through this and not make
an assumption that you have covered everything in previous iterations.
You will be surprised how often things are missed during initial phases/
iterations of this step.
During this phase, any policy that exists outside the domain of the
SDL policy is reviewed (or reviewed again). This may include policies
from outside the development organization that carry security and privacy
requirements and guidelines to be adhered to when developing software
or applications anywhere within the organization. Often, too, policies
are updated during the development process, and new requirements are
added. Thus it is best to obtain a list of updated policies and make sure
you have incorporated any additional requirements.
Corporate security and privacy policies will likely instruct designers
and developers on what the security and privacy features need to be and
how they must be implemented. Other policies may focus on the use of
164 Core Software Security
third-party and open-source software used as part of a software product or
on the protections and control of source code and other intellectual pro-
perty within and outside the organization. Assuming the software secu-
rity group is separate from the centralized information security group, it
is important that the two groups collaborate on all policies and guide-
lines related to the development and post-release security support by the
organi zation. It helps the information security group to fine-tune its poli-
cies not only for corporate security policies/practices but also for software
development. It is also important to collaborate with the privacy function
of your company, whether it be a centralized group or outside legal coun-
sel. If the company identifies potential new markets, privacy policies and
practices (for that particular market) may be updated.
6.2 Security Test Case Execution
Security testing is a time-consuming process that requires proper prepa-
ration, consistency, and coordination with all stakeholders, as well as a
deep understanding of what you are actually testing. It starts early and
continues throughout the SDLC process. The approach for security test-
ing is different from other forms of testing in that its purpose is to identify
various vulnerabilities in a software design which are exposed and due to
improper design or coding issues. The premise of this book is to secure
at the source, and testing at this level will prevent many of the vulner-
abilities that are typically found only when the software is exposed at the
network level. Security, especially at the design level, can help us identify
potential security problems and their impact before they are part of a
larger system and network and perhaps cost-prohibitive to fix. Software
security is a dynamic risk management exercise in that you are balancing
the costs of potential assurance remedies against the skills and resources of
adversaries—and there are always intelligent adversaries who are focused
on breaking and exploiting your software. Thus, the security test itself
must assess the probability of occurrence of an event based on exploiting
a vulnerability and the risk associated with each potential occurrence.
In a typical SDLC cycle, software goes through quality assurance (QA)
testing that includes unit, performance, system, and regression testing.
If the software passes through test criteria for this QA testing, it will be
given a “Go” by the QA team. Basically, this means that the software has
Design and Development (A4): SDL Activities and Best Practices 165
been tested for quality and is good to go. From the authors’ point of view,
QA testing is not complete unless all security tests have been performed
and the security test acceptance criteria are all met. Software cannot be
a quality product unless it has been comprehensively tested for security
issues. Treating security testing as an add-on is a mistake that many com-
panies still make. Once QA testing is complete, the software goes to the
security team for security testing. In our opinion, routine security testing
should be part of the QA cycle. The QA team should treat security testing
just like any other testing, and should create test cases and perform both
manual and automated testing just as they would any other testing. The
QA team, however, often does not have the skills to execute security test
cases, which therefore often means that the QA team relies on the secu-
rity team to perform all testing. This approach is not very effective and
takes time away from the security team, which has to perform basic secu-
rity tests instead of looking at advanced threats/corner cases. QA secu-
rity testing is not meant to replace security testing by the security team.
Instead, it should be looked upon as enabling the security team to focus
on advanced testing. Below are a few examples of issues that QA security
testing should look for:
• Plaintext passwords/weak passwords in configuration files
• Default accounts on the stack (Apache, Tomcat, operating systems)
• Sensitive information in log files
• Input validation (XSS, SQLi)
• Parameter tampering for Web applications
• Insecure services used by the software team (e.g., Telnet)
• Security configurations for various services (e.g., NFS)
The QA team should focus not just on application but also on the
stack on which the software will run. This means testing various configu-
rations of operating systems and related services, Web servers, etc., from a
security point of view. Before QA gives the “Go” for a product, the entire
stack (application, operation system, Web servers, storage) should have
been tested for basic security issues.
Security test case execution is carried out from two primary perspectives:
1. Security mechanisms are tested to ensure that their functionality is
properly implemented; and
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.