O'Reilly logo

Core Software Security by Anmol Misra, James Ransome

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

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
EngineeringSoftware
ProductDevelopment
Group
Product
Business
Unit1
Product
Business
Unit 2
Product
Business
Unit3
Product
Business
Unit4
Product
Business
Unit5
Figure 8.2 The right organizational location.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required