Secure Coding mailing list archives

Darkreading: Getting Started


From: steingra at gmail.com (Andy Steingruebl)
Date: Wed, 9 Jan 2008 19:59:06 -0800

On Jan 9, 2008 4:48 PM, Gary McGraw <gem at cigital.com> 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.

Gary,

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 approaches.

 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 service.

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

-- 
Andy Steingruebl
steingra at gmail.com


Current thread: