Vulnerability tallies surged in 2006 | The Register

[Kevin.Wall at qwest.com (Wall, Kevin)]

Benjamin Tomhave wrote...
> This is completely unsurprising.  Apparently nobody told the agile
> dev community that they still need to follow all the secure coding
> practices preached at the traditional dev folks for eons.  XSS,
> redirects, and SQL injection attacks are not revolutionary, are not
> all that interesting, and are so common-place that it makes one wonder
> where these developers have been the last 5-10 years.
>
> Solution to date: throw out traditional design review, move to agile
> security testing.  Why?  Because there seems rarely to be a design
> to review, and certainly no time to do it in.  Overall, it's important
> that agile apps be built on an underlying publishing framework so
> that inherited vulns can be found and fixed across the board by
> focusing on a single platform.
 
I think many in the security community have had similar thoughts for
years. IIRC, I think Gary McGraw even made a prediction at one point
that agile development methods would be the worst setback to information
security in years, or something to that affect. (At least I think it
was Gary. If not, my bad memory is at fault. Or perhaps I should say...
my bad...memory?)
 
Agile development is good at things when their users have some idea of
how they'd like to see the system work, so it usually works fairly well
for things like laying out screens, workflow, etc. as well as many
business applications which are presently being done manually. However,
generally these users are clueless when it comes to security. If the developers
were using a more traditional SDLC and their users were writing up business
requirements, the typical requirement (ones I have actually seen) are things
like "The user must login" and "The system must be secure". That's about
as sophisticated as they get. If your have developers are know a lot of
security, then they _might_ make it work, but the agile development
methods, which emphasizing working closely with your users, doesn't
work well for security matters because most users don't even know what
to ask for.
 
IMO, another reason why agile development fails miserably to result in
secure programs is because security cuts across the grain of the entire
application. While you can have a trusted kernel or whatever be a
logically isolated component, much of security has to be DESIGNED IN,
FROM THE START. Because all it takes is a single incorrectly functioning
piece to ruin your entire security. Most agile development teams that I've
seen here think that they can leave security issues to the end that then
put in in that special "security module". One problem is that security
must be anywhere that untrusted input can come from which is usually
quite a few places.  In that sense, trying to add in security to an
application developed using agile methods is similar to attempting to
add concurrency / multi-threading to an application after-the-fact.
Sure, you _can_ do it, but what it results in is a system with a few
course grained locks and very little concurrency. Concurrency cuts across
various aspects, just like security does. That's why I don't see it as
a particularly good fit for agile development. (OTOH, I think it should
be a great fit with Aspect Oriented Programming, but that's another topic.)
And while I'm on a roll (at least in the ego of my own mind ;-) one other
place that I think is a rotten match for agile development. If the
software you are developing is supposed to be a reusable class library,
I don't find agile development a particularly good fit. Publish the
interfaces of a reusable class library for the first release and then
go ahead and just try to refactor those interfaces after you have a 1/2
dozen clients using release 1.0. If they don't skin you alive, they
certainly won't be your clients for your next release.
 
But enough rambling.
-kevin
---
Kevin W. Wall Qwest Information Technology, Inc.
Kevin.Wall at qwest.com Phone: 614.215.4788
"The reason you have people breaking into your software all 
over the place is because your software sucks..."
-- Former whitehouse cybersecurity advisor, Richard Clarke,
    at eWeek Security Summit


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.