James, You misunderstood my comments wrt older technologies. My points were: 1) We should not expect people rooted in older technology contexts to naturally understand problems in modern technology contexts if their jobs have not required them to evolve their thinking. 2) In trying to effectively communicate challenges to these business leaders, it may be useful to understand their context and provide correlated examples in the context they understand, rather than stubbornly insisting that they update their context. As people age, change becomes increasingly difficult to handle (this is a truth of psychology and neuroscience), so we should not assume that they will be able to easily adjust their context. As responsible security professionals, we should find a way to bridge the gap, getting the same points across in language that they'll understand.
The other point made was that there continues to be a disconnect with business leaders in that they seem fine making "business" decisions, but then panic when it becomes an "IT" decision. The point here is that we should be extremely diligent in casting IT/security decisions as business decisions and reassuring them that the thought processes are the same. The only potential downfall is that it then puts additional responsibilities on our security shoulders to make sure we've presented the business risk analysis adequately to properly support a risk decision. Lastly, yes, I agree it's a red flag when execs meddle in the affairs of techies, but it happens a lot, and we should be prepared for dealing with it. This problem becomes especially challenging in light of #1 above, wherein their context is tied to outmoded technologies and the associated ways of thinking. This does _not_ mean we should limit our options to those outmoded technologies, but that we need to be cognizant of the limited thought context and provide adequate explanation that is _understood_ when challenging what is happening and providing alternatives. cheers, -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/ "We must scrupulously guard the civil liberties of all citizens, whatever their background. We must remember that any oppression, any injustice, any hatred is a wedge designed to attack our civilization." -President Franklin Delano Roosevelt On Mon, November 19, 2007 11:00 am, James Stibbards wrote: > 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 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 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 >> _______________________________________________ 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. _______________________________________________
