[SC-L] How is secure coding sold within enterprises?
I am attempting to figure out how other Fortune enterprises have went about selling the need for secure coding practices and can't seem to find the answer I seek. Essentially, I have discovered that one of a few scenarios exist (a) the leadership chain was highly technical and intuitively understood the need (b) the primary business model of the enterprise is either banking, investments, etc where the risk is perceived higher if it is not performed (c) it was strongly encouraged by a member of a very large consulting firm (e.g. McKinsey, Accenture, etc). I would like to understand what does the Powerpoint deck that employees of Fortune enterprises use to sell the concept PRIOR to bringing in consultants and vendors to help them fulfill the need. Has anyone ran across any PPT that best outlines this for demographics where the need is real but considered less important than other intiatives? * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Economics of Software Vulnerabilities
Very interesting. Crispin is in the throes of big software. Anybody want to help me mount a rescue campaign from jamaica? gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com -Original Message- From: Crispin Cowan [mailto:[EMAIL PROTECTED] Sent: Mon Mar 19 16:00:48 2007 To: Gary McGraw Cc: Ed Reed; sc-l@securecoding.org Subject:Re: [SC-L] Economics of Software Vulnerabilities Gary McGraw wrote: I'm not sure vista is bombing because of good quality. That certainly would be ironic. Word on the way down in the guts street is that vista is too many things cobbled together into one big kinda functioning mess. I.e. it is mis-featured, and lacks on some integration. This is a variation on not having desired features. And there certainly are big features in Vista that were supposed to be there but aren't (most of user-land being managed code, relational file system). It is also infamously late. So if the resources that were put into the code quality in Vista had instead been put into features and ship-date, would it do better in the marketplace? Sure, that's heretical :) but it just might be true :( Crispin, now believes that users are fundamentally what holds back security -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Training at CanSec West http://cansecwest.com/dojoapparmor.html This electronic message transmission contains information that may be confidential or privileged. The information contained herein is intended solely for the recipient and use by any other party is not authorized. If you are not the intended recipient (or otherwise authorized to receive this message by the intended recipient), any disclosure, copying, distribution or use of the contents of the information is prohibited. If you have received this electronic message transmission in error, please contact the sender by reply email and delete all copies of this message. Cigital, Inc. accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or its contents. Thank You. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Economics of Software Vulnerabilities
Gary McGraw wrote: I'm not sure vista is bombing because of good quality. That certainly would be ironic. Word on the way down in the guts street is that vista is too many things cobbled together into one big kinda functioning mess. I.e. it is mis-featured, and lacks on some integration. This is a variation on not having desired features. And there certainly are big features in Vista that were supposed to be there but aren't (most of user-land being managed code, relational file system). It is also infamously late. So if the resources that were put into the code quality in Vista had instead been put into features and ship-date, would it do better in the marketplace? Sure, that's heretical :) but it just might be true :( Crispin, now believes that users are fundamentally what holds back security -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Training at CanSec West http://cansecwest.com/dojoapparmor.html ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Economics of Software Vulnerabilities
Crispin Cowan wrote: Crispin, now believes that users are fundamentally what holds back security I was once berated on stage by Jamie Lewis for sounding like I was placing the blame for poor security on customers themselves. I have moved on, and believe, instead, that it is the economic inequities - the mis-allocation of true costs - that is really to blame. Vendors are getting better, because they're being shamed by publicity - not because they're bearing more of the costs that users incur due to shoddy software. But as bad as the costs are that are born by users of shoddy software (patch costs, loss of utility, denial of service, licenses for anti-virus software to make up for the egregiously bad code that leaves buffer overflow exploits available that anyone can leverage to take over a system) - as bad as those costs are they're still swapped by the value - increased productivity and adrenalin rush - that commercial feature-ism delivers. Add the slowly-warmed pot phenomenon (apocryphal as it may be) - customers don't jump out of the boiling pot because they're too invested to walk away. Eventually I think they'll get fed up and there'll be a consumer uprising. Until then let's encourage better coding practices and secure designs and deep thought about what policy do I want enforced. (obligatory plug for high assurance) But, let's not confuse code quality with code security, either. It isn't secure (against hostile code) until you can verify that it (a) does what the policy says it should do (functional testing) and (b) doesn't do what the security policy says it shouldn't do (fuzzing is just a way of performing boundary tests on inputs - it tells you nothing about hidden behaviors of the system, and you can't tell anything about those without formal analysis and good life cycle configuration management). Ed ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] How is secure coding sold within enterprises?
In terms of creating a SDLC, pop out to Borders and get Howard and Lipner¹s ³The Security Development Lifecycle² ISBN 9780735622142 http://www.microsoft.com/mspress/books/8753.aspx It is simply the best text I¹ve read in a long time. You may be interested in the work Mark Curphey et al is doing at his new start up. They launched an ISM portal a couple of weeks back. http://www.ism-community.org/ If you¹re just after ideas on how to engage vendors, check out Curphey¹s blog for some nice insider posts: http://securitybuddha.com/2007/03/07/top-10-tips-for-hiring-web-application- pen-testers/ http://securitybuddha.com/2007/03/07/top-ten-tips-for-hiring-security-code-r eviewers/ http://securitybuddha.com/2007/03/08/top-ten-tips-for-managing-technical-sec urity-folks/ He ran Foundstone¹s services for a while, and built up a pretty good consultancy. The sort of metrics you¹re after are notoriously hard to find out in the wild. There¹s some folks capturing screenshots of enterprise dashboards. This may or may not help at all. http://dashboardspy.com/ Thanks, Andrew On 3/19/07 4:12 PM, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] wrote: I agree with your assessment of how things are sold at a high-level but still struggling in that it takes more than just graphicalizing of your points to sell, hence I am still attempting to figure out a way to get my hands on some PPT that are used internal to enterprises prior to consulting engagements and I think a better answer will emerge. PPT may provide a sense of budget, timelines, roles and responsibilities, who needed to buy-in, industry metrics, quotes from noted industry analysts, etc that will help shortcut my own work so I can start moving towards the more important stuff. -Original Message- From: Andrew van der Stock [mailto:[EMAIL PROTECTED] Sent: Monday, March 19, 2007 2:50 PM To: McGovern, James F (HTSC, IT) Cc: SC-L Subject: Re: [SC-L] How is secure coding sold within enterprises? There are two major methods: 1. Opportunity cost / competitive advantage (the Microsoft model) 2. Recovery cost reductions (the model used by most financial institutions) Generally, opportunity cost is where an organization can further its goals by a secure business foundation. This requires the CIO/CSO to be able to sell the business on this model, which is hard when it is clear that many businesses have been founded on insecure foundations and do quite well nonetheless. Companies that choose to be secure have a competitive advantage, an advantage that will increase over time and will win conquest customers. For example (and this is my humble opinion), Oracle¹s security is a long standing unbreakable joke, and in the meantime MS ploughed billions into fixing their tattered reputation by making it a competitive advantage, and thus making their market dominance nearly complete. Oracle is now paying for their CSO¹s mistake in not understanding this model earlier. Forward looking financial institutions are now using this model, such as my old bank¹s (with its SMS transaction authentication feature) winning many new customers by not only promoting themselves as secure, but doing the right thing and investing in essentially eliminating Internet Banking fraud. It saves them money, and it works well for customers. This is the best model, but the hardest to sell. The second model is used by most financial institutions. They are mature risk managers and understand that a certain level of risk must be taken in return for doing business. By choosing to invest some of the potential or known losses in reducing the potential for massive losses, they can reduce the overall risk present in the corporate risk register, which plays well to shareholders. For example, if you invest $1m in securing a cheque clearance process worth (say) $10b annually to the business, and that reduces check fraud by $5m per year and eliminates $2m of unnecessary overhead every year, security is an easy sell with obvious targets to improve profitability. A well managed operational risk group will easily identify the riskiest aspects of a mature company¹s activities, and it¹s easy to justify improvements in those areas. The FUD model (used by many vendors - ³do this or the SOX boogeyman will get you²) does not work. The do nothing model (used by nearly everyone who doesn¹t fall into the first two categories) works for a time, but can spectacularly end a business. Card Systems anyone? Unknown risk is too risky a proposition, and is plain director negligence in my view. Thanks, Andrew On 3/19/07 11:35 AM, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] wrote: I am attempting to figure out how other Fortune enterprises have went about selling the need for secure coding practices and can't seem to find the answer I seek. Essentially, I have discovered that one of a few scenarios
Re: [SC-L] Economics of Software Vulnerabilities
Ed Reed wrote: Crispin Cowan wrote: Crispin, now believes that users are fundamentally what holds back security I was once berated on stage by Jamie Lewis for sounding like I was placing the blame for poor security on customers themselves. Fight back harder. Jamie is wrong. The free market is full of product offerings of every description. If users cared about security, they would buy different products than they do, and deploy them different than they do. QED, lack of security is user's fault. I have moved on, and believe, instead, that it is the economic inequities - the mis-allocation of true costs - that is really to blame. Since many users are economically motivated, this may explain why users don't care much about security :) A competitive free-market economy is really a large optimization engine for finding the most efficient way to do things, because the more efficient enterprises crush the less efficient. As such, I have a fair degree of faith that senior management is applying approximately the right amount of security to mitigate the threat that they face. If they are not doing so, they are at risk from competitors who do apply the right amount of security. What has made the security industry grow for the last decade has been the huge growth in connectivity. That has grow the attack surface, and hence the threat, that enterprises face. And that has caused enterprises to grow the amount of security they deploy. Add the slowly-warmed pot phenomenon (apocryphal as it may be) - customers don't jump out of the boiling pot because they're too invested to walk away. Eventually I think they'll get fed up and there'll be a consumer uprising. Why do you think it will be an uprising? Why not a gradual shift of the vendors just get better, exactly as fast as the users need them to? Until then let's encourage better coding practices and secure designs and deep thought about what policy do I want enforced. Technologists figure out how to do stuff. Economists and strategists figure out what to do. We can encourage all we want, but we are just shouting into the wind until enterprise users demand better security. Crispin ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] How is secure coding sold within enterprises?
Andrew, James, Agreed, Microsoft has put some interesting thoughts out in their SDL book. Companies that produce a software product will find a lot of this approach resonates well. IT shops supporting financial houses will have more difficulty. McGraw wrote a decent blog entry on this topic: http://www.cigital.com/justiceleague/2007/03/08/cigitals-touchpoints- versus-microsofts-sdl/ Shockingly, however, I seem to be his only commentator on the topic. I think James will find Microsoft's literature falls terribly short of even the raw material required to produce the PPT he desires. Let's see what we can do for him. First: audience. I'm not sure of James' position, but it doesn't sound like he's high enough that he's got the CISO's ear now, nor that he's face-down in the weeds either. James, you sit somewhere in- between? James appears to work for an insurance company. Insurance companies do care about risk, but they're sometimes blind to the kinds (and magnitudes) of software risk their business faces. They fall in a middle ground between securities companies and banks. Second, length: If you're going after a SVP or EVP, James, I'd keep the deck to ~3-5 slides. 1) Motivate the problem, 2) Show your org's. status (as an application security framework) and, 3) show the 6mo., 9mo., 12mo. (maybe) roadmap. Depending on the SVP, another two slides comparing you to others might work, as well as a slide that talks in more detail about costs, deliverables, and resource-requirements, and value. Higher? I'd do two slides: 1) framework and 2) roadmap. The end. Place costs and value on the roadmap. What about content? Longer decks I've seen (or helped create) have begun with research from analyst firms, or with pertinent headlines, to motivate the problem (couched as FUD if you're not careful) on slide one. Still, you'd be wise to pick fodder that will appear to the decision maker's own objectives. His/her objectives may be in pursuit of differentiation/opportunity or risk reduction, as Andrew said, or (more probably) they're pursuant to a more mundane goal: drive down (or hold constant) security cost while driving up the effectiveness of the spending. To this end, the decks I've seen quickly moved beyond motivation into solution. Here, you have to begin thinking about your current org. See: http://www.cigital.com/justiceleague/2007/02/22/keeping-up-with-the- jones-security-initiatives/ To summarize my entry, your organization probably didn't start thinking about software security yesterday, and they likely have something in place--even if it isn't to your satisfaction yet. Likewise, true strengths lurk, waiting to be leveraged. Out here in mailing-list-land, we can't be sure of specifics, but, I've got some premonitions. Insurance companies I've seen seem to mix small wild- wild-west (Developers cowboys 'follow' Agile as an excuse to just slam code without process) teams with those following a largely monolithic waterfall-like (regardless of how 'iterative' it's described) development process in their application portfolio. In either case, an in-project risk officer exists, but the function seems overshadowed by deadlines, features, and cost. On the topic of the framework slide, you mentioned a _very_ important quality: who, what, when structure. I wrote an IEEE SP article on this topic long ago: www.cigital.com/papers/download/j2bsi.pdf but you can also look at my talk from OWASP's DC conference in '05 on the same topic for slide help. What about the roadmap--the way forward? Even if currently ineffective, current security items like an architectural review checklist present opportunity with which to start your roadmap. When working on your roadmap focus on how small iterative changes in existing elements (like that checklist) can save you on security effort (spending) later. Pick sure wins and to communicate value, show a metric that will demonstrate the savings. Propose measurements up front, if only verbally, as part of this presentation. For instance: Do your applications have available a custom implementation of input validation routines built on top of Struts' Validator framework? Ask about its use in the architectural checklist. Propose to measure penetration testing results in the input filtering class and correlate it with checklist answers. As you collect data you'll be building (or possibly but not hopefully destroying) the case for your expanded checklist and the savings it provides. There are a host of hidden measures embedded in this example, each shining light in a particular direction. Make sure each and every initiative can make use of such measures as justification. Well, this is long enough for now. If there are topics you'd like me to enumerate more fully, or if I've missed something, shoot me an email. Hope this helps, and sorry I didn't just
Re: [SC-L] Economics of Software Vulnerabilities
On Mon, 19 Mar 2007, Crispin Cowan wrote: Since many users are economically motivated, this may explain why users don't care much about security :) But... but... but... I understand the sentiment, but there's something missing in it. Namely, that the costs related to security are not really quantifiable yet, so consumers are not working with the best information. Then there's simple lack of understanding, such as that exmplified by an individual consumer - their computer gets really bogged down and slow, and they don't know what's happening, so they go buy a new computer, when it was just a ton of spyware from surfing habits that they didn't know were unsafe, or they were running some zombie that was sucking up all their bandwidth for warez distribution. Eventually I think they'll get fed up and there'll be a consumer uprising. Why do you think it will be an uprising? Why not a gradual shift of the vendors just get better, exactly as fast as the users need them to? I really really wish for an uprising, but unfortunately I'm not too optimistic right now. Off the top of my head, I can't think of any consumer uprisings in other industries, although the US' recent decline in fuel-inefficient vehicles is sort of close. Didn't some large brick-and-mortar companies heavily criticize the software industry a couple years ago? I don't know how that played out. - Steve ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
