Ted Demopoulos’
securITy
January 2005
___________________________________________________________
The free newsletter
of Demopoulos Associates,
www.demop.com
We NEVER rent,
sell, or share email addresses.
Please forward
this newsletter to anyone you know who might enjoy it!
-
Our new blog “The Ted Rap” is now
available at
www.demop.com/thetedrap,
containing Ted’s comments on IT, Security, Business and more. It’s a
less formal outlet for information than this newsletter, and Ted
promises not to ramble too much. Recent posts include “Operating Systems
need to be Secure by Default,” The Offshore Threat, is it real?” and
“Killer Apps, Killer Benefits.”
-
Slides and links to relevant
papers from Ted’s recent keynote for the Defense Contract Management
Agency now online at
www.demop.com/DCMA.html.
Worst Practices in
Developing Secure Software, Part I
As I’ve said before,
The “Best Practices Mantra” annoys me.
A major component of
success involves avoiding making any major mistakes. Instead of focusing
exclusively on implementing “Best Practices,” I suggest avoiding “Worst
Practices.” You can do almost everything perfectly, but if you do one thing
horribly wrong you can negate everything. A soldier greatly increases his
chances in a firefight by doing things right, but one serious mistake and
his odds of surviving plummet. Fatal flaws and mistakes are often exactly
that – FATAL!
Part I focuses on
higher level issues while part II will focus on lower level issues. Part II
will be coming in February.
Assuming that only “important” software
needs to be secure.
All programs and
services need to be secure. Even a simple game or utility could be
compromised, contain a Trojan or otherwise harbor malicious code, and lead
to your entire network being compromised.
Prototype code can
be compromised as well and often ends up incorporated into production
applications. Test code can also be compromised. As much as possible,
prototype and test code need to be well written and secure. Of course it
would be naive to state that prototype and test code can always receive the
same amount of attention to detail as production code and can always be as
well written, but they should certainly not be “garbage code.”
Emphasizing hitting deadlines ahead of
writing “Good Code.”
Deadlines are
important, but not at the expense of writing decent code! Can you image an
engineering project in the physical world taking the equivalent attitude?
“That bridge will open August 1st no matter what. We’ll let the
bridge users uncover any unresolved problems and patch them later.”
Of course it’s easy
to preach when in the pulpit, and harder when in the foxhole. Management,
customers, and others might be screaming for the latest release. In extreme
cases getting a software release out soon, any release, might determine
whether the company still exists in a few weeks or not . . .
Bad code goes hand
in hand with increased bugs, security problems, and long term expenses.
In the long term, good code pays.
Having IT make all risk management
decisions.
Every business
decision involves risk. Many important IT decisions are important business
decisions and can involve significant risk.
Some IT decisions
involve enough risk that executive management should be involved in the
decision making process.
For example, how
much risk and which risks are acceptable in protecting the entire customer
database which may include credit card and other sensitive information? This
is NOT a decision that IT should make alone! It is a risk management
decision that requires input from upper level management.
Not considering security during the entire
application lifecycle.
Security should be
considered during the entire application lifecycle. Security must be part of
the system design based on the product security goals, attention must be
paid to security during implementation, and operational issues including
installation are critical as well.
Adding appropriate
security later is difficult if not impossible because the design may be
fundamentally insecure. Adding security can also cause changes to features
and/or application interfaces affecting backwards compatibility.
Adding security is
more time consuming and resource intensive than doing it “right” from the
beginning, hence it is less likely to be done well or given due diligence.
Assuming the software won’t be attacked.
Most software is
attacked! Don’t make the following common and usually false assumptions:
–The users are
friendly
–Input will not be
malicious
–The environment is
hospitable
–The firewall will
shield the application from hostile users and attacks
Not doing any security testing.
Security testing is
*much* different than functional testing and both are important. Instead of
examining a system’s response under fairly normal circumstances, security
testing involves probing the system looking for weaknesses much like an
attacker would.
Security test plans
are critical. Just haphazardly “testing things,” while not entirely useless,
is very far from ideal. The Test Plan, including security testing, should be
an integral part of the systems development.
Testing is NOT
a replacement for good design and implementation. It can discover
vulnerabilities, but cannot prove that no vulnerabilities exist.
___________________________________________________________
The free newsletter
of Demopoulos Associates,
www.demop.com
This newsletter is Copyright © 2004 by Demopoulos
Associates, Durham, New Hampshire, USA. All rights are reserved,
except that it may be freely redistributed if unmodified.
Sharing
securITy is encouraged if the copyright and attribution are
included.
Subscribe to the securITy newsletter
We NEVER rent,
sell, or share email addresses.
Please forward
this newsletter to anyone you know who might enjoy it!
|
