Secure Coding mailing list archives
Re: Let's get the ball rolling -- secure application design tools/processes
From: George Capehart <capegeo () opengroup org>
Date: Sun, 07 Dec 2003 17:39:23 +0000
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
Current thread:
- Re: Let's get the ball rolling -- secure application design tools/processes Jerry Connolly (Dec 03)
- Re: Let's get the ball rolling -- secure application design tools/processes George Capehart (Dec 07)
- Re: Let's get the ball rolling -- secure application design tools/processes Crispin Cowan (Dec 08)
- The problem is that user management doesn't demand security David A. Wheeler (Dec 08)
- Re: The problem is that user management doesn't demand security Dana Epp (Dec 08)
- Re: The problem is that user management doesn't demand security Jared W. Robinson (Dec 09)
- Re: The problem is that user management doesn't demand security Erik van Konijnenburg (Dec 08)
- Re: The problem is that user management doesn't demand security Kenneth R. van Wyk (Dec 09)
- Re: The problem is that user management doesn't demand security George Capehart (Dec 09)
- Re: The problem is that user management doesn't demand security Stephen Galliver (Dec 09)
- Re: The problem is that user management doesn't demand security Andreas Saurwein (Dec 10)
- Re: The problem is that user management doesn't demand security Michael Cassidy (Dec 10)
- Re: Let's get the ball rolling -- secure application design tools/processes George Capehart (Dec 07)