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] Bugs and flaws

2006-02-03 Thread James Stibbards
Hi Gary,

In one of your prior posts you mentioned documentation.  I believe that the
problem with WMF was that someone had not examined WMF as a postential
source of vulnerabilities, since the embedded code was an legacy capability.

My belief is that one of the keys to finding flaws lies in the proper
capture of the requirements/contract of a software component, and then
examining and testing against that. Without the proper requirements that
speak clearly to security,  we can inspect and examine, but we won't know
what we're measuring against.  That doesn't solve the problem of knowing
when we're done, I realize.

See you at SSS.
- James

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Gary McGraw
Sent: Friday, February 03, 2006 11:13 AM
To: Kenneth R. van Wyk; Secure Coding Mailing List
Subject: RE: [SC-L] Bugs and flaws

To cycle this all back around to the original posting, lets talk about the
WMF flaw in particular.  Do we believe that the best way for Microsoft to
find similar design problems is to do code review?  Or should they use a
higher level approach?

Were they correct in saying (officially) that flaws such as WMF are hard to
anticipate? 

gem




This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.


___
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

___
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