Re: [SC-L] Let's get the ball rolling -- secure application design tools/processes

[George Capehart <[EMAIL PROTECTED]>]

On Tuesday 02 December 2003 10:34 pm, Jerry Connolly wrote:
> George Capehart said the following on Tue, Dec 02, 2003 at 04:24:33PM
> -0500,
>
> > Don't see much on the SSE-CMM, the relationship between the SDLC
> > and the risk management process, or even how to make "The Process"
> > more secure . . . That's what interested me . . .
>
> On the subject of taking risks into account, it seems to be a tricky
> adjustment for developers to make to start to do this.  However,
> they'll rarely be able to justify spending time reading the risks
> digest or any literature devoted to engineering failures.

You've touched on one of the problems.  Before I start my rant, I'm 
going to stick a stake in the ground and take the following position:  
"The absence of "security" in applications is due to:

 a) Negligent,
 b) Negligible,
 c) Inadequate or
 d) Incompentent management.

It's due to the absence of process which is due to the absence of 
accountability which is due to a lack of governance.

<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 . . .

There are also (software development) project-related risks.  Managing 
those risks is what the CMM(I)[2] and various methodologies like the 
Rational Unified Process [3], XP, etc. are about.  The decision to 
implement (or *not* to implement) methodologies and enforce rigorous 
process is a management decision.  Developers have no say in that.  
Management should be held accountable for the lack of rigorous process 
around the SDLC, but *rarely* is.  If process *does* exist, it is the 
project manager's responsibility to follow the process.  It is also the 
project manager's responsibility to ensure that the tasks and 
milestones in the project are reasonable and clearly defined and that 
the project is staffed with people whose skills match the tasks at hand 
(thereby minimizing the risk of project failure and rework).  I've been 
in the business for a long time and I can count on one hand the number 
of times I have seen a project manager who had any clue whatsoever 
about whether a given individual actually had the skills to do what 
he/she was being tasked with.  *Never* have I seen a project manager 
held accountable for a failed project, yet I *have* seen project 
managers promoted in spite of the mess they made of projects.  I know 
developers who are much better able to understand (software 
development) project-related risks than the typical project manager, 
but they don't have any part of the decision-making process.  This is 
one of the places where developers could contribute to the management 
of risk, but are rarely invited.

There is one risk management decision in which a developer can 
participate.  That is the decision about whether or not to accept a 
position on a project.  If the position requires the developer to do 
something he/she has never done before, unless there is mentoring 
available on the project, the probability that the developer will be 
successful is not significantly greater than zero.[4]  There is a 
reason the apprenticeship system developed.  We are not born with a 
priori knowledge and experience.  No matter what the task, it takes a 
few iterations through the loop before one develops competence in a it.  
The developer who accepts the assignment of a task in which he/she has 
no experience *and for which there is no mentoring available* is 
increasing the risk to the project.  Shame on the developer for 
accepting the position and shame on the project manager for not 
staffing the project correctly.

I hear the chorus:  "But I can't help it if I'm given an assignment for 
which I am not prepared!"  Agreed.  All I'm saying is that when that 
happens, the risk to the project increases.  The developer who 
*attempts* to manage his/her risk by taking the concern to the project 
manager and asking that the manager either provide mentoring or assign 
someone else to the task has done all he/she can do and has discharged 
his/her responsibility.  The ball is then squarely in the project 
manager's court.  But again, I, personally, have never seen a project 
manager (or anyone for that matter) held accountable for a failed 
project.

The point is that managing risk and information and application security 
is a governance issue.  With governance comes real accountability and 
with real accountability comes risk management.  If there is a culture 
of governance and accountability, the risk management will be there.  
If not, there will be pockets "at the bottom" where individuals take it 
upon themselves to "Do The Right Thing" (TM), but the success and scope 
will be limited.  So what should a developer do?  Follow his/her 
conscience, do the best he/she can and live with the frustration.
</rant>

Yes, I know that this list is about secure coding.  What does my rant 
have to do with secure coding?  Well, the basic idea is that there is 
more to secure coding than sanitizing user input and stack canaries.  
Is the development process itself secure?  Is there a rigorous change 
process in place?  Where is the organization in the SSE-CMM?  Does the 
organization even *do* system security engineering?  Are projects 
required to adhere to the organization's enteprise security 
architecture?  *Is* there an enterprise system security architecture?  
Is there a certification and accreditation process?  What kind of 
testing is done?  How secure is the process of managing code 
*throughout the SDLC*?  All of these and more have to do with secure 
coding practices . . .

My $0.02

George Capehart

[0] Executive Guide: Information Security Management: Learning From 
Leading Organizations GAO/AIMD-98-68 -  
http://http://www.gao.gov/special.pubs/ai9868.pdf

[1] Guide for the Security Certification and Accreditation of Federal 
Information Systems -  
http://csrc.nist.gov/publications/drafts/sp800-37-Draftver2.pdf

[2] The Capability Maturity Model Itegration - 
http://www.sei.cmu.edu/cmmi/

[3] The Ten Essentials of RUP: The Essence of an Effective Development 
Process - http://www.rational.com/products/whitepapers/413.jsp

[4] _Practical_Cryptography_, ISBN 0-471-22357-3 - for instance, 15.11, 
page 277

-- 
George Capehart

capegeo at opengroup dot org

PGP Key ID: 0x63F0F642 available on most public key servers

"It is always possible to agglutenate multiple separate problems into a
 single complex interdependent solution.  In most cases this is a bad
 idea."  -- RFC 1925