Re: [SC-L] OWASP Publicity

2007-11-19 Thread McGovern, James F (HTSC, IT)


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

2007-11-19 Thread James Stibbards
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 

Re: [SC-L] OWASP Publicity

2007-11-19 Thread Benjamin Tomhave
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: