Hi Andy,

Good point about 4 (tool first).  Sometimes security feature rollout can 
provide a good impetus.  We saw that too, focused around crypto for PCI with 
one of our major customers.

The only real danger with following that path is that you tend to emphasize 
that security is a feature (and only a feature), which as we all know is a big 
misunderstanding among dev people.


company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com

-----Original Message-----
From: Andy Steingruebl [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 09, 2008 10:59 PM
To: Secure Coding Mailing List (SC-L@securecoding.org)
Cc: Gary McGraw
Subject: Re: [SC-L] Darkreading: Getting Started

On Jan 9, 2008 4:48 PM, Gary McGraw <[EMAIL PROTECTED]> wrote:
> hi sc-l,
> One of the biggest hurdles facing software security is the problem of how to 
> get started, especially when faced with an enterprise-level challenge.  My 
> first darkreading column for 2008 is about how to get started in software 
> security.  In the article, I describe four approaches:
> 1. the top-down framework;
> 2. portfolio risk;
> 3. training first; and
> 4. leading with a tool.


I had success with #4, but not using the tools we usually think of for 
bootstrapping a program, namely static analysis or testing tools.
When I took the position they had already settled on using Netegrity's 
Siteminder product for a common authentication and authorization scheme across 
all of the applications.  I managed to get them to settle on doing a quasi-RBAC 
with Siteminder, using it almost as an identity service as well.

Settling on one common high-quality authentication and authorization 
tool/framework had three effects:

 1. It removed these services from the realm of development. They just had to 
integrate with it, but didn't have to figure out all of the corner cases to 
password changes, etc. that so often crop up, and people mess up in homegrown 

 2. It convinced developers to build clean interfaces in their code for things 
like authorization to call out externally and/or have the data provided to them 
in a standard fashion.  By settling on RBAC it also helped a lot with role and 
permission modeling that did need to happen in the app.

 3. In a shop that usually wanted to do everything itself, it broke that cycle 
and people got used to not having to write everything from scratch.

It was a bit of a non-standard way to use a tool to bootstrap a security 
program.  They essentially got sold Netegrity originally for the wrong reasons, 
but they picked it and in implementing it correctly did themselves a huge 

Just one data point on leading with a tool that focused more on architecture 
and design than it did on finding defects.

Andy Steingruebl

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.

Reply via email to