Re: [SC-L] OWASP Publicity
d" or "could" be done, so that they're not confusing. For example, > a > question of policy with a question of choice of technology selection. > > A few days early, but Happy Thanksgiving, to all! > > - James > > James W. Stibbards > Sr. Director - Sales Engineering > Cloakware, Inc. > email: [EMAIL PROTECTED] > phone: 703-752-4836 > cell: 571-232-7210 > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Benjamin Tomhave > Sent: Sunday, November 18, 2007 10:08 AM > To: Secure Coding > Subject: Re: [SC-L] OWASP Publicity > > I agree and disagree with these comments, as I think they possibly > represent > an outmoded way of thinking when it comes to IT management. > Execs and senior mgmt _must_ have a certain understanding of security that > will at least give them a basis for making risk decisions. It seems today > that they are fine (generally) making business risk decisions, but then > believe falsely that making an IT risk decision requires following a > completely different set of rules (when, in fact, it's just another kind > of > business risk decision). I'm of the belief that this directly correlates > to > their lack of fundamental understanding of IT and security issues. > > Where I agree is the level of detail that needs to be imparted. OWASP Top > 10 > is probably too much detail to communicate to the average exec or sr > manager. However, we must not overlook that these business leaders were > once > individual contributors. Yes, it's true that some of these folks came up > through a strictly business route, but for the most part these days I see > these careers originating in at least a semi-technical role. We should be > seeking to leverage those backgrounds to educate them and bring them to > modern times. > > On Crispin's later comments about bad vs good managers, I think he's very > much hit the nail on the head (see the quote in my sig). However, there's > one aspect that's overlooked, which is outdated prior history. > If an executive's understanding of technology is founded in their first > contributions as an individual contributor 10-20 years ago, then this > means > their understanding of modern technology may be severely limited. > I'm sure all of us understand how difficult it is to stay on top of > current > trends as technology evolves, and it's often our job to do so. > What if it's not your job to keep current? The times will change while > your > focus is elsewhere, but only a truly savvy person will think to check that > context before making decisions that affect it. This seems to be a rarity. > > So, to conclude, I think that it would be valuable, in broad brush > strokes, > to educate leaders about secure coding - and security in general - but > perhaps not to the level of detail we might really desire to see. We want > execs and sr managers to drive their folks toward secure coding practices, > but that doesn't mean they themselves have to know how to code securely. > As > such, in targeting these other publications, the message should be refined > to be business-oriented, extolling the business risks associated with > ignoring these practices and providing a big arrow pointing in the direct > of > orgs like OWASP. > > fwiw. > > -ben > > -- > Benjamin Tomhave, MS, CISSP > [EMAIL PROTECTED] > Web: http://falcon.secureconsulting.net/ > LI: http://www.linkedin.com/in/btomhave > Blog: http://www.secureconsulting.net/ > Photos: http://photos.secureconsulting.net/ > > [ Random Quote: ] > "If a man is offered a fact which goes against his instincts, he will > scrutinize it closely, and unless the evidence is overwhelming, he will > refuse to believe it. If, on the other hand, he is offered something which > affords a reason for acting in accordance to his instincts, he will accept > it even on the slightest evidence. The origin of myths is explained in > this > way." > Bertrand Russell > > Crispin Cowan wrote: >> McGovern, James F (HTSC, IT) wrote: >>> I have observed an interesting behavior in that the vast majority of >>> IT executives still haven't heard about the principles behind secure >>> coding. My take says that we are publishing information in all the >>> wrong places. IT executives don't really read ACM, IEEE or other the >>> sporadic posting from bloggers but they do read CIO, Wall Street >>> Journal and most importantly listen to each other. >>> >>> What do folks on this list think about asking the magazines and >>> newspapers to publish? I am wi
Re: [SC-L] OWASP Publicity
Ben, Good comments. It may be true that "older" technology is what today's Sr Managers have the most familiarity with, however... In my opinion, it's not that familiarity that we (or they) should rely on, in order to be well-informed, and thus be making good security-related decisions. It's no longer their job to be into the details of that technology, unless they are the CTO (for example), and if they are into the details... That's actually a red flag to me that they're likely *not* doing their actual job, today, as a Sr. Manager. [Slight rant: It *is* the responsibility of the management team of the organization, overall, to be sure that information which is critical to the organization be conveyed, abstracted or not, up and down the layers of the entire omanagement and individual contributors... to accomplish whatever organizational goals exist. (see more, below).] If a Sr Manager was once familiar with COBOL (I chuckled at the recent COBOL SC-L postings...), but the issues are now WinMobile and AJAX, then it's really the responsibility of someone in the organzation to have synthesized and presented the security issues, opportunities, and costs as they relate to WinMobile/AJAX/etc. to senior management as Business Issues. At other layers in the organization, yes, there are Technology issues, concerns, joy and grief... But not at the Executive levels, because that's not their job(!). As an aside...since security means so many things to so many people, here is a 4-layer model that I use with a lot of my customer to help position what we do, in the "vast" landscape of security: 1. Business/Mission objectives - what are "we" trying to accomplish? 2. Systems Architecture - how is this being instantiated, in terms of systems, communication, storage, etc? 3. Security Architecture - what specific technology and processes are we using to reduce risk, introduce control mechanisms, etc. 4. Protection Technology - how do we lock down the #3, so it can be resistant to attack, itself. I've used this over and over again, in helping to frame discussions of what "should" or "could" be done, so that they're not confusing. For example, a question of policy with a question of choice of technology selection. A few days early, but Happy Thanksgiving, to all! - James James W. Stibbards Sr. Director - Sales Engineering Cloakware, Inc. email: [EMAIL PROTECTED] phone: 703-752-4836 cell: 571-232-7210 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin Tomhave Sent: Sunday, November 18, 2007 10:08 AM To: Secure Coding Subject: Re: [SC-L] OWASP Publicity I agree and disagree with these comments, as I think they possibly represent an outmoded way of thinking when it comes to IT management. Execs and senior mgmt _must_ have a certain understanding of security that will at least give them a basis for making risk decisions. It seems today that they are fine (generally) making business risk decisions, but then believe falsely that making an IT risk decision requires following a completely different set of rules (when, in fact, it's just another kind of business risk decision). I'm of the belief that this directly correlates to their lack of fundamental understanding of IT and security issues. Where I agree is the level of detail that needs to be imparted. OWASP Top 10 is probably too much detail to communicate to the average exec or sr manager. However, we must not overlook that these business leaders were once individual contributors. Yes, it's true that some of these folks came up through a strictly business route, but for the most part these days I see these careers originating in at least a semi-technical role. We should be seeking to leverage those backgrounds to educate them and bring them to modern times. On Crispin's later comments about bad vs good managers, I think he's very much hit the nail on the head (see the quote in my sig). However, there's one aspect that's overlooked, which is outdated prior history. If an executive's understanding of technology is founded in their first contributions as an individual contributor 10-20 years ago, then this means their understanding of modern technology may be severely limited. I'm sure all of us understand how difficult it is to stay on top of current trends as technology evolves, and it's often our job to do so. What if it's not your job to keep current? The times will change while your focus is elsewhere, but only a truly savvy person will think to check that context before making decisions that affect it. This seems to be a rarity. So, to conclude, I think that it would be valuable, in broad brush strokes, to educate leaders about secure coding - and security in general - but perhaps not to the level of detail we might really desire to see. We want execs and
Re: [SC-L] OWASP Publicity
The vast majority of IT executives are unfamiliar with all of the principles of security, firewalls, coding, whatever. Are they unfamiliar because of background or they feel that their staff has a handle on it and therefore don't need to pay much atention to it. Both have different characteristics in terms of getting the word out. The important thing to understand is that such principles are below their granularity; then are *right* to not care about such principles, because they can't do anything about them. Their granularity of decision making is which products to buy, which strategies to adopt, which managers to hire and fire. Suppose they did understand the principles of secure coding; how then would they use that to decide between firewalls? Web servers? Application servers? Executives don't need to care about the details but they can care enough to embrace the notion of procuring secure software. They can care about the fact that much of their code that they outsource doesn't have any metrics attached to them and that acceptance shouldn't be on meeting functionality alone. If anything, the idea that needs to be pitched to IT executives is to pay more attention to "quality" than to shiny buttons & features. But there's the rub, what is "quality" and how can an IT executive measure it? The best way for IT executives to measure things are metrics that indicate a trend. Regardless of what they decide to measure, it should trend positive. I have lots of informal metrics that I use to measure quality, but they largely amount to synthesized reputation capital, derived from reading bugtraq and the like with respect to how many vulnerabilities I see with respect to a given product, e.g. Qmail and Postifx are extremely secure, Pidgin not so much :) But as soon as we formalize anything like this kind of metric, and get executives to start buying according to it, then vendors start gaming the system. They start developing aiming at getting the highest whatever-metric score they can, rather than for actual quality. This happens because metrics that approximate quality are always cheaper to achieve than actual quality. This is a very, very hard problem, and sad to say, but pitching articles articles on principles to executives won't solve it. My notion wasn't just pitching to them as this is what has occured to date. I was also suggesting that the media take on secure coding has to go well beyond the frequent consultant and vendor types that post here. If you think for a moment about other successful marketing campaigns in IT such as CMMi, ITIL, etc, the vast majority of executives know and embrace it but can't tell you who even invented it as the community let it grow past the founding members. We haven't yet came to same realization here... Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work * 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] OWASP Publicity
I agree and disagree with these comments, as I think they possibly represent an outmoded way of thinking when it comes to IT management. Execs and senior mgmt _must_ have a certain understanding of security that will at least give them a basis for making risk decisions. It seems today that they are fine (generally) making business risk decisions, but then believe falsely that making an IT risk decision requires following a completely different set of rules (when, in fact, it's just another kind of business risk decision). I'm of the belief that this directly correlates to their lack of fundamental understanding of IT and security issues. Where I agree is the level of detail that needs to be imparted. OWASP Top 10 is probably too much detail to communicate to the average exec or sr manager. However, we must not overlook that these business leaders were once individual contributors. Yes, it's true that some of these folks came up through a strictly business route, but for the most part these days I see these careers originating in at least a semi-technical role. We should be seeking to leverage those backgrounds to educate them and bring them to modern times. On Crispin's later comments about bad vs good managers, I think he's very much hit the nail on the head (see the quote in my sig). However, there's one aspect that's overlooked, which is outdated prior history. If an executive's understanding of technology is founded in their first contributions as an individual contributor 10-20 years ago, then this means their understanding of modern technology may be severely limited. I'm sure all of us understand how difficult it is to stay on top of current trends as technology evolves, and it's often our job to do so. What if it's not your job to keep current? The times will change while your focus is elsewhere, but only a truly savvy person will think to check that context before making decisions that affect it. This seems to be a rarity. So, to conclude, I think that it would be valuable, in broad brush strokes, to educate leaders about secure coding - and security in general - but perhaps not to the level of detail we might really desire to see. We want execs and sr managers to drive their folks toward secure coding practices, but that doesn't mean they themselves have to know how to code securely. As such, in targeting these other publications, the message should be refined to be business-oriented, extolling the business risks associated with ignoring these practices and providing a big arrow pointing in the direct of orgs like OWASP. fwiw. -ben -- Benjamin Tomhave, MS, CISSP [EMAIL PROTECTED] Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ [ Random Quote: ] "If a man is offered a fact which goes against his instincts, he will scrutinize it closely, and unless the evidence is overwhelming, he will refuse to believe it. If, on the other hand, he is offered something which affords a reason for acting in accordance to his instincts, he will accept it even on the slightest evidence. The origin of myths is explained in this way." Bertrand Russell Crispin Cowan wrote: > McGovern, James F (HTSC, IT) wrote: >> I have observed an interesting behavior in that the vast majority of IT >> executives still haven't heard about the principles behind secure >> coding. My take says that we are publishing information in all the wrong >> places. IT executives don't really read ACM, IEEE or other the sporadic >> posting from bloggers but they do read CIO, Wall Street Journal and most >> importantly listen to each other. >> >> What do folks on this list think about asking the magazines and >> newspapers to publish? I am willing to gather contact information of >> news reporters and others within the media if others are willing to >> amplify the call to action in terms of contacting them. >> > The vast majority of IT executives are unfamiliar with all of the > principles of security, firewalls, coding, whatever. > > The important thing to understand is that such principles are below > their granularity; then are *right* to not care about such principles, > because they can't do anything about them. Their granularity of decision > making is which products to buy, which strategies to adopt, which > managers to hire and fire. Suppose they did understand the principles of > secure coding; how then would they use that to decide between firewalls? > Web servers? Application servers? > > If anything, the idea that needs to be pitched to IT executives is to > pay more attention to "quality" than to shiny buttons & features. But > there's the rub, what is "quality" and how can an IT executive measure it? > > I have lots of informal metrics that I use to measure quality, but they > largely amount to synthesized reputation capital, derived from reading > bugtraq and the like with respect to how many vulnerabilitie
Re: [SC-L] OWASP Publicity
der Mouse wrote: >> The vast majority of IT executives are unfamiliar with all of the >> principles of security, firewalls, coding, whatever. >> > ... > >> The important thing to understand is that such principles are below >> their granularity; the[y] are *right* to not care about such >> principles, because they can't do anything about them. >> > Perhaps - but then, they have to stop second-guessing the people who > *do* know what they're talking about. Trying to have it both ways - > management that is inexpert but nevertheless imposes their opinions on > design or buying decisions - is a recipe for disaster, and, while > hardly universal, is all too common. > I submit that really *good* managers do listen to the experts around them. That is really basic to good management; surround yourself with experts, and then listen to them. Of course there's lots of bad managers, because managing is so subjective that bad managers find it easy to survive. Measuring the quality of management is about as difficult as measuring the quality of software. > I've never understood why it is that managers who would never dream of > second-guessing an electrician about electrical wiring, a construction > engineer about wall bracing, a mechanic about car repairs, will not > hesitate to believe - or at least act as though they believe - they > know better than their in-house experts when it comes to what computer, > especially software, decisions are appropriate, and use their > management position to dictate choices based on their inexpert, > incompletely informed, and often totally incompetent opinions. (Not > just security decisions, either, though that's one of the cases with > the most unfortunate consequences.) > Because the kind of personality that seeks to become a manager is a self-important arrogant snot, myself included :) It thus takes conscious effort to listen to the opinions of others, and let them win when they have a persuasive argument. Even more simple: this trait of believing your own opinions more than those of others is nearly universal in humans. Managers simply have the power to indulge themselves, and only occasionally have the wisdom to *not* indulge themselves. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work ___ 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] OWASP Publicity
| ...I've never understood why it is that managers who would never dream | of second-guessing an electrician about electrical wiring, a | construction engineer about wall bracing, a mechanic about car | repairs, will not hesitate to believe - or at least act as though they | believe - they know better than their in-house experts when it comes | to what computer, especially software, decisions are appropriate, and | use their management position to dictate choices based on their | inexpert, incompletely informed, and often totally incompetent | opinions. (Not just security decisions, either, though that's one of | the cases with the most unfortunate consequences.) This is perhaps the most significant advantage to licensing and other forms of official recognition of competence. At least in theory, a licensed professional is bound by an officially-sanctioned code of conduct to which he has to answer, regardless of his employment chain of command. In reality, of course, things are not nearly so simple, along many dimensions. Theory and practice are often very different. However ... the next time you run into a situation where you are forced into a technically bad decision because some salesman took a VP to a nice golf course - imagine that you could pull down some official regulation that supported your argument. The world has many shades of gray -- Jerry ___ 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] OWASP Publicity
> The vast majority of IT executives are unfamiliar with all of the > principles of security, firewalls, coding, whatever. > The important thing to understand is that such principles are below > their granularity; the[y] are *right* to not care about such > principles, because they can't do anything about them. Perhaps - but then, they have to stop second-guessing the people who *do* know what they're talking about. Trying to have it both ways - management that is inexpert but nevertheless imposes their opinions on design or buying decisions - is a recipe for disaster, and, while hardly universal, is all too common. I've never understood why it is that managers who would never dream of second-guessing an electrician about electrical wiring, a construction engineer about wall bracing, a mechanic about car repairs, will not hesitate to believe - or at least act as though they believe - they know better than their in-house experts when it comes to what computer, especially software, decisions are appropriate, and use their management position to dictate choices based on their inexpert, incompletely informed, and often totally incompetent opinions. (Not just security decisions, either, though that's one of the cases with the most unfortunate consequences.) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ 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] OWASP Publicity
Thanks gunnar. That was a gratifying article that I am proud of. We've garnered good coverage as a field in CIO magazine too. I don't think it's as simple as having ink in the right locations, but I do agree with james that that helps. Software security is continuing to spread and grow, and we need to keep the good work coming. gem - Original Message - From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> To: James McGovern <[EMAIL PROTECTED]>; Secure Mailing List Sent: Thu Nov 15 15:46:13 2007 Subject: Re: [SC-L] OWASP Publicity Local boy makes good http://online.wsj.com/article/0,,SB112128453130584810,00-search.html -gp On 11/15/07 10:25 AM, "McGovern, James F (HTSC, IT)" <[EMAIL PROTECTED]> wrote: > I have observed an interesting behavior in that the vast majority of IT > executives still haven't heard about the principles behind secure > coding. My take says that we are publishing information in all the wrong > places. IT executives don't really read ACM, IEEE or other the sporadic > posting from bloggers but they do read CIO, Wall Street Journal and most > importantly listen to each other. > > What do folks on this list think about asking the magazines and > newspapers to publish? I am willing to gather contact information of > news reporters and others within the media if others are willing to > amplify the call to action in terms of contacting them. > > > > * > 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. > ___ > ___ 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. ___ ___ 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] OWASP Publicity
But, if you get the ideas in front of the C-Suite folks and it resonates, then they push it down the lines in their organization where, one hopes, those who should pay attention will pay attention. Awareness, I would think, is what matters. My $0.02 for the week. Bernie Bernie Rosen Director, Juniper SIRT 1-408-936-4809 Direct 1-650-714-8255 Mobile -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Crispin Cowan Sent: Thu 15 Nov 2007 12:29 To: McGovern, James F (HTSC, IT) Cc: Secure Coding Subject: Re: [SC-L] OWASP Publicity McGovern, James F (HTSC, IT) wrote: > I have observed an interesting behavior in that the vast majority of > IT executives still haven't heard about the principles behind secure > coding. My take says that we are publishing information in all the > wrong places. IT executives don't really read ACM, IEEE or other the > sporadic posting from bloggers but they do read CIO, Wall Street > Journal and most importantly listen to each other. > > What do folks on this list think about asking the magazines and > newspapers to publish? I am willing to gather contact information of > news reporters and others within the media if others are willing to > amplify the call to action in terms of contacting them. > The vast majority of IT executives are unfamiliar with all of the principles of security, firewalls, coding, whatever. The important thing to understand is that such principles are below their granularity; then are *right* to not care about such principles, because they can't do anything about them. Their granularity of decision making is which products to buy, which strategies to adopt, which managers to hire and fire. Suppose they did understand the principles of secure coding; how then would they use that to decide between firewalls? Web servers? Application servers? If anything, the idea that needs to be pitched to IT executives is to pay more attention to "quality" than to shiny buttons & features. But there's the rub, what is "quality" and how can an IT executive measure it? I have lots of informal metrics that I use to measure quality, but they largely amount to synthesized reputation capital, derived from reading bugtraq and the like with respect to how many vulnerabilities I see with respect to a given product, e.g. Qmail and Postifx are extremely secure, Pidgin not so much :) But as soon as we formalize anything like this kind of metric, and get executives to start buying according to it, then vendors start gaming the system. They start developing aiming at getting the highest whatever-metric score they can, rather than for actual quality. This happens because metrics that approximate quality are always cheaper to achieve than actual quality. This is a very, very hard problem, and sad to say, but pitching articles articles on principles to executives won't solve it. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work ___ 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. ___ ___ 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] OWASP Publicity
McGovern, James F (HTSC, IT) wrote: > I have observed an interesting behavior in that the vast majority of IT > executives still haven't heard about the principles behind secure > coding. My take says that we are publishing information in all the wrong > places. IT executives don't really read ACM, IEEE or other the sporadic > posting from bloggers but they do read CIO, Wall Street Journal and most > importantly listen to each other. > > What do folks on this list think about asking the magazines and > newspapers to publish? I am willing to gather contact information of > news reporters and others within the media if others are willing to > amplify the call to action in terms of contacting them. > The vast majority of IT executives are unfamiliar with all of the principles of security, firewalls, coding, whatever. The important thing to understand is that such principles are below their granularity; then are *right* to not care about such principles, because they can't do anything about them. Their granularity of decision making is which products to buy, which strategies to adopt, which managers to hire and fire. Suppose they did understand the principles of secure coding; how then would they use that to decide between firewalls? Web servers? Application servers? If anything, the idea that needs to be pitched to IT executives is to pay more attention to "quality" than to shiny buttons & features. But there's the rub, what is "quality" and how can an IT executive measure it? I have lots of informal metrics that I use to measure quality, but they largely amount to synthesized reputation capital, derived from reading bugtraq and the like with respect to how many vulnerabilities I see with respect to a given product, e.g. Qmail and Postifx are extremely secure, Pidgin not so much :) But as soon as we formalize anything like this kind of metric, and get executives to start buying according to it, then vendors start gaming the system. They start developing aiming at getting the highest whatever-metric score they can, rather than for actual quality. This happens because metrics that approximate quality are always cheaper to achieve than actual quality. This is a very, very hard problem, and sad to say, but pitching articles articles on principles to executives won't solve it. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work ___ 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] OWASP Publicity
Local boy makes good http://online.wsj.com/article/0,,SB112128453130584810,00-search.html -gp On 11/15/07 10:25 AM, "McGovern, James F (HTSC, IT)" <[EMAIL PROTECTED]> wrote: > I have observed an interesting behavior in that the vast majority of IT > executives still haven't heard about the principles behind secure > coding. My take says that we are publishing information in all the wrong > places. IT executives don't really read ACM, IEEE or other the sporadic > posting from bloggers but they do read CIO, Wall Street Journal and most > importantly listen to each other. > > What do folks on this list think about asking the magazines and > newspapers to publish? I am willing to gather contact information of > news reporters and others within the media if others are willing to > amplify the call to action in terms of contacting them. > > > > * > 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. > ___ > ___ 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. ___
