340 Core Software Security
and efficiently create, deliver, and manage the best practices described
in this book. It will also assist in the successful buy-in and management
of the tasks through A1–A5 in our SDL model. As an added benefit, by
using the organizational structure suggested, you will be able to deliver
the tasks described in Chapter 8 for post-release support (PRSA1–5),
which are typically conducted by other organizations than your own. By
using the metrics described in each section of the SDL model, you be able
not only to effectively manage and track your software security programs
and SDL success but also provide a dashboard to your corporate manage-
ment and internal customers as to the current state of your program. This
dashboard can also be used to identify gaps, which can be used to justify
headcount, funding, and other resources when needed. Most important,
by building security in, you will maximize the ability to avoid post-release
discoveries of security vulnerabilities in your software and increase your
ability to successfully manage these discoveries on the occasions when
they do occur.
10.3 Software Security Organizational Realities
and Leverage
Although an incremental headcount hire plan based on progressive
increase in workload is typically the norm for most organizations, incre-
mental growth isn’t the right model for what has been proposed in this
book and certainly isn’t a reality for those going through austerity realities
within their organizations. Doing more with less is a reality we all face,
regardless of the risks we are facing. To help solve this conundrum, we
have proposed a model for a software security group that doesn’t depend
on continual growth, linear or otherwise. The virtual team grows against
linear growth, allowing a fully staffed, centralized software security group
to remain relatively stable. We believe that a centralized group comprised
of one seasoned software security architect per main software product
group and one for each software product within that group in your soft-
ware engineering development organization will be sufficient to scale
quite nicely as long as the software security champion program is adhered
to as proposed in this book. In addition, by sharing the responsibility for
a typical product security incident response team (PSIRT) among the key
software security champions for each software product in a development
Pulling It All Together: Using the SDL to Prevent Real-World Threats 341
organization, a single PSIRT manager should suffice given the shared
responsibilities of the task throughout the organization.
As described earlier in the book, excellence is not about increasing
numbers; it is about the quality of staff you hire. Each of these seasoned
software security architects can coordinate and support the implemen-
tation of the SDL within each business unit and software product line
and will:
• Provide the associated software security champion with the central-
ized software security group process and governance.
• Mentor the software security champions in security architecture and
reviews.
• Support the associated business unit software security champion
in the mentorship of each software product line software security
champion.
• Coordinate with product management for early and timely security
requirements.
• Help to calculate project security risk.
• Help to ensure that software security champions institute appropri-
ate and full security testing.
• Ensure that appropriate security testing tools are available (static,
dynamic, fuzzing) for use in the SDL as appropriate.
While these tasks benefit greatly from senior experience and discre-
tion, there is a significant opportunity cost savings in having these senior
technical leaders mentor the software security champions and software
security architects, as both a wonderful growth opportunity for the indi-
viduals involved and a cost savings to the company and the organization.
Someone with the potential to grow into a leader through experience and
mentorship is a perfect candidate for the software security champions in
our model. We are the sum of everything we have ever done, which is
constantly being revised and remembered. The same can be said of soft-
ware security architects; it is a journey, not a point in time, and requires
constant learning, mentoring, and collaboration with those who have
been there before.
In our model, there are multiple paths to appropriate “coverage.”
Unlike a fully centralized function, a virtual team, handled with care, can
be coalesced and led by a far smaller central team. The authors have made
342 Core Software Security
this model work, sometimes numerous times in a number of disparate
organizations, and consider this a proven track record for a model that
will constantly evolve with the ever-changing realities we are faced with in
software security. Each member of the centralized software security group
must be able to inspire, encourage, and lead a virtual team such that the
virtual members contribute key subject-matter expert (SME) tasks, but at
the same time do not become overloaded with additional or operational
tasks. “Just enough” such that the PSIRT function can reap huge benefits
through having true SMEs contribute and enable, while at the same time
making sure that no one person bears the entire brunt of a set of opera-
tional activities that can’t be dodged. Since our model for a centralized
software security group makes use of an extended virtual team, the need
for a large central PSIRT staff, as may be found in other organizations,
is not needed. Tasks that can be managed in a decentralized manner are
done, such as technical investigations, release planning, and fix develop-
ment. However, there is a coordination role that must be sophisticated
enough to technically comprehend the implications and risks involved
in various responses. Peer review is a powerful tool for avoiding missteps.
Further, the central role within the engineering software development
group itself provides coordination across teams, something that is lacking
in most organizations. We must not respond individually to a vulnerabil-
ity that affects many software products in unique and idiosyncratic ways.
Further, it is essential to provide an interface between PR (and sometimes
marketing) support and the technical teams who are involved in respond-
ing. You want your response to vulnerability reporters to be consistent
and to avoid putting your company and your brand at risk, externally.
10.4 Overcoming SDL Audit and Regulatory
Challenges with Proper Governance
Management
In Chapter 2, we gave a brief overview of ISO/IEC 27034. Other than
the various software security maturity models mentioned earlier in the
book, this will be the first software security standard. It will presumably
have a third-party attestation and certification industry built around
it in the near future. Given that this standard does not define applica-
tion security as a specific state of security but rather as a process that an
Pulling It All Together: Using the SDL to Prevent Real-World Threats 343
organization can perform for applying controls and measurements to its
applications in order to manage the risk of using, we believe our model
is applicable to preparing to be in compliance with this standard. The
standard provides guidance for organizations in integrating security into
the processes used for managing their applications and explicitly takes
a process approach in specifying, designing, developing, testing, imple-
menting, and maintaining security functions and controls in application
systems. The requirements and processes specified in ISO/IEC 27034 are
not intended to be implemented in isolation but rather integrated into
an organization’s existing process. The combination of ISO/IEC 27034
compliance with the adherence of our SDL practices or any of the matu-
rity models described earlier in the book should serve you well in meet-
ing any audit, regulatory, or governance challenges, since adherence will
likely be driven by the guidance driven by the latter.
10.5 Future Predications for Software Security
We have divided this section into to two parts. First, the bad news, which
is the things that we see that will likely continue on in industry but that
should be changed; and second, the good things we see with regard to soft-
ware security in the future—the light at the end of the tunnel, if you will.
10.5.1 The Bad News
We’ll start with the bad news. For the most part, other than threat
modeling and architectural security reviews, which is an art, not a sci-
ence, software security isn’t that difficult, but it is an area that industry
has known about for many years and yet has chosen to do almost nothing
about. This is evident in the top software vulnerabilities in the Common
Vulnerabilities and Exposures (CVE), and the OWASP and SANS top-
10 vulnerability lists, which have remained essentially the same over 10
years. Although industry has started to take leadership in this area over
the last few years, and ISO ISO/IEC 27034, 29147, and 30111 have
been announced, we see software security as an ongoing problem for the
foreseeable future. Although the future looks bright in this area, it will
take time to finally steer industry in the right direction. As discussed
throughout the book, building security into the software development
344 Core Software Security
process is more about an attitude change, management acceptance, and
business/operational process changes than about blazing new trails in new
scientific or technical disciplines.
The price to fix vulnerabilities later in the cycle is very high. The level
of effort that is required to tune and maintain current product secu-
rity tools can be more expensive than buying the tool. Although much
of the burden of making this change is on the vendor, we have some
thoughts that may help change this paradigm. We propose a paradigm
shift away from vulnerabilities in software security. Not every vulner-
ability gets exploited, or is even exploitable. Often, mitigations that are
not obvious to vanilla vulnerability scanners make even garden-variety
vulnerabilities unattractive to attackers. We are not suggesting that we
stop fixing bugs in code. Quite the opposite, as should be clear from the
contents of this book. Still, delivering reports with thousands of vulner-
abilities have not made software secure. However, as a collective whole,
the security industry continues to focus on vulnerability: every new type
of attack, every new variation, and every conceivable attack methodol-
ogy. Instead, a focus on correct program behavior aligns well with how
developers approach designing and creating code. Correctness goes to the
heart of the software process. In our experience, developers are rewarded
for correctness. And it should be obvious that vulnerabilities are errors,
plain and simple. Focusing on correctness would, unfortunately, be a sea
change in software security. Tools today often don’t report the one, single
bug that will respond to multiple variations of a particular type of attack.
Instead, too often, tools report each variation as a “vulnerability” that
needs to be addressed by the developer. This is the way security people
think about the situation. It’s an attacker’s view: Which attack methods
will work on this particular system? That is the question that most vulner-
ability scanners address today (as of this writing). However, people who
write code simply want to know what the coding error is, where it is in
the code, and what is the correct behavior that must be programmed.
Often, if the tool contains any programming hints, these tend to be bur-
ied in the tool’s user interface. Instead, we propose that a tool should be
no more difficult to use than a compiler. The results could be a list of
code errors, coupled to line numbers in the code, with a code snippet
pointing out where the error lies. Of course, this is an oversimplifica-
tion. Some kinds of security vulnerabilities lie across code snippets, or
even across a whole system. Still, focus could be on what is the coding
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.