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
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 W. Stibbards
Sr. Director - Sales Engineering
email: [EMAIL PROTECTED]
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
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