The problem is that user management doesn't demand security

["David A. Wheeler" <dwheeler () ida org>]

George Capehart wrote:


<rant>
Developers are not the people to be making the risk management decisions 
to which I *think* you are referring.  Decisions about how to manage 
risks that affect the confidentiality, integrity and availability of 
systems and data are *business* decisions.  The organization's risk 
management process is responsible for providing the information that 
the organization's leadership needs in order to make these decisions.  
(Information Security) Policies and procedures and decisions about what 
controls to put into place and whether to accept, react to, or prevent 
threats from occurring are management (business) decisions.  This is 
what the risk management process [0] and the certification and 
accreditation process is all about.[1]  The outcome of those decisions 
become *requirements* for the SDLC.  The developer doesn't have any say 
in that.  Management should be held accountable for lack of risk 
management, but *rarely* is . . .




I agree in general with your rant, but I think there's an important 
distinction
that isn't sufficiently clear in it.  There are at least TWO KINDS of 
management:

software project management, and end-user management.
And that makes all the difference.

I would argue that the problems you noted - insufficient management 
attention

to risk - are serious, but are fundamentally an _END-USER_
management issue.  Managers either don't ask if the products are
sufficiently secure for their needs, or are satisfied
with superficial answers (Common Criteria evaluated is good enough;
please don't ask about the evaluation EAL level, or
if the tested functions or environment are related to my needs.
And certainly don't look at its security history, or its development 
process,

or any other information that might give me a better understanding of my
risks.  I just want to know if everyone else runs it too, so I can do
"management by lemming").

The software development managers for at least most proprietary and
custom programs are doing exactly what they're supposed to do - they're
developing products that users will buy.  The ONLY CRITERIA that
matters for a typical proprietary software product is, "will you buy it?"
If the answer is "yes", then doing anything beyond that is
fudiciarily irresponsible, and potentially dangerous to
their livelihood.  A security problem might even be
a good thing, that means you might pay for the upgrade that includes
a patch for the known vulnerability (without fixing fundamental issues -
else how can I charge you for the NEXT upgrade?).

Since end-user management buys the products, software project management
is doing exactly the right thing for their customers.
There have been software development projects in the past that
worked hard to develop secure products.  End-user management didn't
buy those products.  Therefore, those software development managers
were failures (in the market sense), and other software development managers
have learned that lesson very well.  Many widely-used products are
known to be security nightmares.  But people keep buying them.
Therefore, a software project manager has learned to keep ignoring
security (for the most part)... and the market rewards this behavior.

I want improved security in products.  I don't like this situation
at all.  But it's hard to do get more secuirty in an
environment where there is no reward (worse, an anti-reward) for
better security.  The history of security has shown that customers
repeatedly choose the product that is LESS secure.  At least so far;
I can hope that will change.

I think examining the economic motivations for why things are
done the way they're done now is critical.  Making it clearer to
end-users how secure a product is would help, but we have some
ways of doing that and I think it could be easily argued they aren't
helping enough.

We know many techniques that can produce more secure software.
But until there's an economic reason to apply them,
it's unwise to assume that they'll be used often.

Also, don't place too much faith in the CMM etc. for security.
The CMM by itself doesn't have much to do with security.
The SSE-CMM augments the CMM for security
(of resulting products).  However, beware of looking only
at the process. Other factors (like people and the resulting products)
are critically important too.  I've done many SCEs, and reviewed the CMM and
SSE-CMM, and there many important factors they don't cover.
In particular, meeting the training requirements of the SSE-CMM has almost
nothing to do with having good people.

Why do developers fail to apply security techniques/technology?
Because that's what users reward them to do.

--- David A. Wheeler <[EMAIL PROTECTED]>