xiii
The global cyber security threat is increasing on a regular basis, if not
daily. The recurring question is how we address the current threat of global
cyber security. The authors have aptly named their book in response to
this question, in that the answer is to create software that has as mini-
mal vulnerabilities as possible. In other words, focus on securing at the
source first, instead of taking shortcuts by only trying to secure network
infrastructure. Perimeter security and defense-in-depth have their place
in security, but software security is the first line of defense and should
come first. If you have fewer vulnerabilities at the source, it also takes out
the financial benefit of nation states or organized crime stockpiling cyber
weapons based on current vulnerabilities. Not only must we get better
at it, we must make the solutions cost-effective, operationally relevant,
and feasible, based on real-world experience, and worth the investment.
Securing at the source requires securing the software, which is at the
heart of cyber infrastructure. One of the things we have been constantly
facing over the last 20 years is that software has become a critical com-
ponent of every part of our critical infrastructure and everyday lives. We
are already seeing software embedded within a vast variety of things we
use in our daily lives—from smart meters in our home to cars we drive.
Unfortunately, software security has not evolved at the same pace, and
many software products are still developed in an environment with the
intent that they fix the problem after release rather than doing it right the
first time around. There are two major issues with this:
1. There are no shortages of threats out there today; therefore, people
who are looking to exploit software vulnerabilities have a pretty
Foreword
fertile field in which to work. As a consequence, we have to make
sure we are doing better vulnerability management. We also have to
look toward the future and ask ourselves, “How can we avoid having
these types of vulnerabilities in future generations of software that
we are increasingly dependent on?” The answer to this question is
particularly important because it is very beneficial to companies to
reduce these vulnerabilities and to stop them during the software
development process. It is significantly less expensive to build security
in through the use of a SDL than to come back and fix it post-release.
2. The second issue is that we need to start looking at a whole genera-
tion of what is referred to as “zero-day vulnerabilities.” If we can
eliminate the likelihood of finding a zero day by not allowing the
vulnerabilities to take place from the very beginning by adhering
to the best practices of a solid SDL, it will save companies money,
make the software and its users more secure, the critical infrastruc-
ture more resilient, and overall, more beneficial to us all.
As the Executive Director of the Software Assurance Forum for
Excellence in Code (SAFECode), a nonprofit organization dedicated
exclusively to increasing trust in information and communications
technology products and services through the advancement of effective
software assurance methods, I currently have a major focus on security
training for developers. The lack of security awareness and education
among the software engineering workforce can be a significant obsta-
cle to organizations working to implement software security programs.
However, better training for software developers so they have the skills
needed to write secure code is just one of the variables in the software
security equation. Software projects are under the constraints of costs
and tight timelines. In those situations, it is inevitable that security is sac-
rificed somewhere because of shortcuts taken. Cost, time, and resources
are typically the triad of software development supporting security, and
if you sacrifice one of the three, security and quality suffer. A software
development environment is built around a programmer who is pressured
on every side to work faster, to cut corners, and to produce more code at
the expense of security and quality.
It is impossible to have 100 percent security, but the developers and
their management should always strive to maximize the mitigation of
risk. It is about making it so difficult to access in an unauthorized man-
ner that adversaries:
xiv Core Software Security
Foreword xv
• Have to utilize traceable and obvious means to gain access, so they
are noticed right away
• Spend so much time trying to gain access that they eventually are
noticed
• Give up and move on to easier targets
Ensuring that everyone touching the product development lifecycle
has the knowledge they need to support an organization’s software secu-
rity process is a fundamental challenge for any organization committed
to software security success. The goal is to remove the pain that organi-
zations face in developing a custom program of their own resource con-
straints and knowledge vacuums.
Developers are often under intense pressure to deliver more features
on time and under budget. Few developers get the time to review their
code for potential security vulnerabilities. When they do get the time,
they often don’t have secure-code training and lack the automated tools,
embedded processes and procedures, and resources to prevent hackers
from using hundreds of common exploit techniques to trigger malicious
attacks. Like it or not, the hard work of developers often takes the brunt
of malicious hacker attacks. So what can software vendors do? A big part
of the answer is relatively old-fashioned: The developers need to be pro-
vided with incentives, better tools, and proper training.
Unfortunately, it currently makes more business sense not to produce
secure software products than it does to produce secure software prod-
ucts. Any solution needs to address this as a fundamental market failure
instead of simply wishing it were not true. If security is to be a business
goal, then it needs to make business sense. In the end, security require-
ments are in fact the same as any business goals and should be addressed as
equally important. Employers should expect their employees to take pride
in and own a certain level of responsibility for their work. And employees
should expect their employers to provide the tools and training they need
to get the job done. With these expectations established and goals agreed
on, perhaps the software industry can do a better job of strengthening the
security of its products by reducing software vulnerabilities.
This book discusses a process and methodology to develop software in
such a way that security considerations play a key role in its development.
It speaks to executives, to managers at all levels, and to technical leaders,
and in that way it is unique. It also speaks to students and developers so
they can understand the process of developing software with security in
mind and find resources to help them do so. The information in this
book provides a foundation for executives, project managers, and techni-
cal leaders to improve the software they create and to improve the secu-
rity, quality, and privacy of the software we all use.
Software developers know how to write software in a way that provides
a high level of security and robustness. So why don’t software developers
practice these techniques? This book looks to answer this question in
two parts:
1. Software is determined to be secure as a result of an analysis of how
the program is to be used, under what conditions, and the secu-
rity requirements it must meet in the environment in which it is
to be deployed. The SDL must also extend beyond the release of
the product in that if the assumptions underlying the software in
an unplanned operational environment and their previously implied
requirements do not hold, the software may no longer be secure and
the SDL process may start over in part or as a whole if a complete
product redesign is required. In this sense, the authors establish the
need for accurate and meaningful security requirements and the
metrics to govern them as well as examples of how to develop them.
It also assumes that the security requirements are not all known
prior to the development process and describes the process by which
they are derived, analyzed, and validated.
2. Software executives, leaders, and managers must support the robust
coding practices and required security enhancements as required by
a business-relevant SDL as well supporting the staffing requirements,
scheduling, budgeting, and resource allocations required for this
type of work. The authors do an excellent job of describing the pro-
cess, requirements, and management of metrics for people in these
roles so they can accurately assess the impact and resources required
for a SDL that is relevant to and work best in their organization and
environment. Given that this is an approached designed from real-
life, on-the-ground challenges and experiences, the authors describe
how to think about issues in order to develop effective approaches
and manage them as a business process.
I particularly like the addition of Brook Schoenfield to the book as
the author of Chapter 9, bringing a seasoned principal enterprise and
xvi Core Software Security
Foreword xvii
software security architect with “in the trenches” experience to explain
how security architecture fits into the SDL process in the “real world.” In
particular, he provides a unique and valuable approach to addressing the
aspects of SDL and security architecture that has been field-tested and
really works in the agile software development process.
I have known Dr. James Ransome for many years, and I am very
pleased that he has chosen this topic for his 10th book on information
security. Having recently served as the Special Assistant to the President
and the Cyber Security Coordinator for the federal government, in addi-
tion to many senior leadership roles in the cyber security government
and enterprise space, I can confidently say that this is currently the most
critical area of information and global cyber security to fix. This has been
and continues to be more of a business and process issue than it is techni-
cal.
Core Software Security: Security at the Source adds great value to the
typical training resources currently available in that it takes the elements
of the best publically known SDLs and provides operational, business-
relevant, cost-effective metrics. I believe that what James Ransome and
Anmol Misra have written has hit the mark on this topic and will serve
the community for many years to come as both a practical guide for pro-
fessionals and as an academic textbook.
Hon. Howard A. Schmidt
Partner, Ridge Schmidt Cyber
Executive Director, The Software Assurance Forum for Excellence in
Code (SAFECode)
About Hon. Howard A. Schmidt
Hon. Howard Schmidt serves as a partner in the strategic advisory firm
Ridge Schmidt Cyber, an executive services firm that helps leaders in
business and government navigate the increasing demands of cyber secu-
rity. He serves in this position with Tom Ridge, the first Secretary of
the U.S. Department of Homeland Security. Prof. Schmidt also serves
as executive director of The Software Assurance Forum for Excellence in
Code (SAFECode).
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.