Secure Coding mailing list archives
The problem is that user management doesn't demand security
From: "David A. Wheeler" <dwheeler () ida org>
Date: Mon, 08 Dec 2003 19:00:29 +0000
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]>
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)
- Re: The problem is that user management doesn't demand security George W. Capehart (Dec 10)
- Re: The problem is that user management doesn't demand security Julie Ryan (Dec 11)