1.4 A Call to Arms
You probably knew that the security of Internet software was a mess
before you started this book. How do we extricate ourselves?
In addition to advocating the widespread adoption of the techniques
and practices described in this book, we also call for advances in
three particular areas: education, standards, and metrics.
- Education
-
Clearly, we must do a better job of
educating engineers about the principles and techniques of secure
coding.
We must also ensure that the public understands the demonstrably poor
security of Internet software today, and that the various facets of
government comprehend the magnitude of the disasters that can strike
us if we don't make drastic improvements.
We also need to convince the press that those who attack systems are
not geniuses; they're merely criminals. It would
help, too, if the media would stop publicizing dramatic names for the
various vulnerabilities and exploitation programs, such as (to invent
an example) the "Red Slammer." Will
it take a decade or more of severe or deadly incidents to change
public attitudes about computer attackers?
- Standards
-
Many people have compared the software
vulnerability situation today to the carnage endured before the
advent of mandatory seat belts in private automobiles.
Having reached the point where we agree, we now call for the
development of true secure coding standards—standards that can
be used by companies, governments, and consumers to promote
prosperity and ensure our safety. It is the only way we can see to
get software vendors to invest in
quality. If every company is forced
to participate, none will be able to make the excuse that they
can't afford to divert resources from more
competitive pursuits.
- Metrics
-
A critical step in the widespread adoption
of safe programming techniques and standards is the development of
competent security metrics. Until we can apply an accepted
measurement tool to two programs (or two versions of the same
program) and determine which has fewer security vulnerabilities, we
can expect very slow progress in this field.
Until we have reliable security metrics, consumers will lack the
means to reward manufacturers who produce good code and punish those
whose products reek with vulnerabilities. Governments will lack the
confidence to develop standards, and citizens may never be sure that
they are justified in goading government to enforce the laws and
requirements that do exist. Engineers will still struggle to refine
their own techniques, and hesitate to condemn their
colleagues.
Toward this end, you'll find in the final chapter of
this book a discussion of some of the automated tools and techniques
available today that can help you flag and fix security bugs. We also
discuss briefly a simple script we've used for the
rudimentary "security scoring" of
application software.
|