Re: [SC-L] Resources to fix vulns
At 8:53 AM -0700 7/18/07, McCown, Christian M wrote: Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary=_=_NextPart_001_01C7C953.D03CBE5C What do you tell a C-level exec in terms of h/c and time it will take to fix web app vulnerabilities discovered in a website? X number of vulnerabilities = Y h/c and Z time. Of course there's a host of factors/variables involved that could wind up looking like actuarial tables or DNA sequences (!), but what we'd like to be able to do is sum it up as an initial swag and let the app owners use it as a factor in calculating the actual time to remediate. Look at the track record for _that_organization_ fixing previous vulnerabilities. -- Larry Kilgallen ___ 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] Resources to fix vulns
I wish formulas were the solution to your question. The problem is that the answer is heavily dependent upon the background of the C-level executive. Some C-Level executives have an analytical background where their backgrounds could have been actuarial, IT, statistics, etc where they would understand intuitively that not all vulnerabilities are equal and that the solution would feel more like describing a design pattern. If your C-Level executive is a process weenie then you have to then get into prioritization and the psychology of dealing with low-hanging fruit vs severity vs occurences and so on. If you C-Level executive is perception-oriented and frequently uses the phrase perception is reality then your answer is simply to grab industry quotes from Gartner or similar entity... From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of McCown, Christian M Sent: Wednesday, July 18, 2007 11:54 AM To: sc-l@securecoding.org Subject: [SC-L] Resources to fix vulns What do you tell a C-level exec in terms of h/c and time it will take to fix web app vulnerabilities discovered in a website? X number of vulnerabilities = Y h/c and Z time. Of course there's a host of factors/variables involved that could wind up looking like actuarial tables or DNA sequences (!), but what we'd like to be able to do is sum it up as an initial swag and let the app owners use it as a factor in calculating the actual time to remediate. Anyone done this or like to take a swipe? Chris McCown, GSEC(Gold) Intel Corporation * (916) 377-9428 | * [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] * 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] Resources to fix vulns
I would actually recommend AGAINST using prior track records for fixing previous vulnerabilities because in all honestly they probably don't track it. Most enterprises prioritize any type of defect based on the importance as declared by business users whom traditionally would prioritize a spelling error on a web page of higher importance than a buffer overflow. Security stuff may get addressed while the developer has the patient open and therefore there is no real transparency in terms of the numbers. Likewise, if you wanted to think of security as a system quality and wanted to compare it to things like performance and scalability, those things haven't been always solved by changing code where the behavior was more like throwing lots of hardware at it. Security has done some of this as well but this will not uncover what you seek. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ljknews Sent: Wednesday, July 18, 2007 3:42 PM To: sc-l@securecoding.org Subject: Re: [SC-L] Resources to fix vulns At 8:53 AM -0700 7/18/07, McCown, Christian M wrote: Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary=_=_NextPart_001_01C7C953.D03CBE5C What do you tell a C-level exec in terms of h/c and time it will take to fix web app vulnerabilities discovered in a website? X number of vulnerabilities = Y h/c and Z time. Of course there's a host of factors/variables involved that could wind up looking like actuarial tables or DNA sequences (!), but what we'd like to be able to do is sum it up as an initial swag and let the app owners use it as a factor in calculating the actual time to remediate. Look at the track record for _that_organization_ fixing previous vulnerabilities. -- Larry Kilgallen * 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] Resources to fix vulns
At 9:50 AM -0400 7/19/07, McGovern, James F (HTSC, IT) wrote: I would actually recommend AGAINST using prior track records for fixing previous vulnerabilities because in all honestly they probably don't track it. Most enterprises prioritize any type of defect based on the importance as declared by business users whom traditionally would prioritize a spelling error on a web page of higher importance than a buffer overflow. Security stuff may get addressed while the developer has the patient open and therefore there is no real transparency in terms of the numbers. If investigation of prior security vulnerability remediation shows it is skewed by low organizational priority, then that _is_ an indication of how fast _that_organization_ will fix a security vulnerability. It seems much more honest that guesses about how long it would take if it were high priority. As for record keeping, the source code archives should show the date a change was made (even if bundled with other changes). -- Larry Kilgallen ___ 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. ___
