225
Chapter 8
Post-Release Support
(PRSA1–5)
Many of the functions and their associated activities and best practices
described in this chapter (see Figure 8.1) are handled by groups other
than the software security group that would have the principal oversight
over SDL activities and best practices (A1–A5) described in the previous
chapters. In this chapter we will describe them as activities that are the
responsibility of the centralized software security group in an organiza-
tion. We have found that this is a much more cost-effective and efficient
way to manage these activities using existing resources. This is precisely
the reason we highly recommend that the core software security group be
composed of senior software security architects who have hard “dotted-
line” relationships with the software security champions, who in turn
have the same relationships with the software security evangelists. There
should also be a strong relationship between the software security archi-
tects in the centralized software security group and the product managers
of each Tier 1 software product, just as there is for the software security
champions. It is also important that the software security group and func-
tion be in the right organization so they can be most successful.
Figure 8.1 Post-release support (PRSA1-5): SDL activities and best practices.
Post-Release Support (PRSA1–5) 227
8.1 Right-Sizing Your Software Security Group
First we will walk through each of the software security group relation-
ships and the importance of putting everything into perspective in order
to “right-size” the building of a successful software security program.
Doing this means having
• The right organizational location
• The right people
• The right process
8.1.1 The Right Organizational Location
Although there have been great advances in software security technology
over the last few years, we believe that people are still the most important
element of a successful software security program that includes the imple-
mentation and management of the activities and best practices. In order
to facilitate the best use of the people responsible for software security,
they must be part of the right organization (see Figure 8.2). Having been
in seven Chief Security Officer (CSO) and Chief Information Security
Officer (CISO) roles, James Ransome, one of the co-authors of this book,
has had software security reporting to him in several of his roles. Based on
both his experience and communication with his peers in the industry, it
is clear that the software security function ideally should fall within the
engineering (software development) function and, in particular, within
the quality function. The general consensus is that the application security
role typically reports to the centralized information security role CSO/
CISO position and should not be confused with the software security
function. Typically, those who are in an application security role within
an IT security organization are great at running tools but do not have the
software development background necessary to fully interpret the results.
To make this point clear, it is important to differentiate between software
and application security. Perhaps the best way to clarity this distinction is
with a quote from Gary McGraw:
Software security is about building secure software: designing
software to be secure; making sure making sure that software is
secure; and educating software developers, architects, and users
228 Core Software Security
about how to build security in. On the other hand, application
security is about protecting software and the systems that soft-
ware runs in a post facto way, only after development is complete.
1
Another advantage of having the software security experts reporting
to the engineering organization is that they are empowered by the fact
that they are part of the same organization; are directly responsible for
implementing the SDL policies and procedures and associated tools; and
understand software development, its architecture, and the level of effort
required to fix the same. Earlier in this book we described the importance
of software security as an element of quality and organization, and the
same relationship should exist within the engineering organization.
ProductQualityGroup
(EngineeringͲ Software)
ProductSecurityGroup
(Software)
Principal
Software
Security
Architect
Senior
Software
Security
Architect
Software
Security
Architect
Senior
Software
Security
Architect
Software
Security
Architect
Architect
Architect
Architect
EngineeringSoftware
ProductDevelopment
Group
Product
Business
Unit1
Product
Business
Unit 2
Product
Business
Unit3
Product
Business
Unit4
Product
Business
Unit5
Figure 8.2 The right organizational location.
Post-Release Support (PRSA1–5) 229
The authors believe that software security should be a group of its own
within engineering/software development and should work very closely
with the central security group; it may even have a “dotted-line” relation-
ship to the CSO/CISO.
A few reasons for our preference for the software security group to
report to the software quality group include the following.
1. Security vulnerabilities are, by definition, quality issues.
2. Security features are architectural functions with a very close rela-
tionship to product management.
3. Based on (1) and (2) above, security is both a feature and a quality
function.
4. Quality is best served when it is integral to the development process
(engineering) and includes security.
8.1.2 The Right People
In Chapter 2 we discussed the talent required to make the SDL model
we describe in this book a success. This will include a minimum of one
principal software security architect, a mix of senior and general soft-
ware security architects, and, ideally, one software security architect in
the software product security group per software product security group
in the organization. This relationship is represented in Figure 8.3. This
talent pool provides the ability to scale in that there will also ideally be
one software security champion (SSC) per Tier 1 software product within
each engineering software product development group. Another element
of the talent is the software security evangelists (SSEs) for organizations
that are large enough to have extra candidates for the software security
champions’ (SSCs) role, who can be candidates for SSEs until there is a
slot for them as a SSC. SSEs have two roles, as a SSC in training and as an
evangelist for the overall software product security program promulgated
policy, enforcing policy, and evangelizing the overall SDL process.
8.1.3 The Right Process
The right process is the core SDL activities and best practices described
in this book so far and summarized in Figure 8.4. In addition to the
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.