[WEB SECURITY] code review techniques for when you don't trust your developers or testers

Mike Duncan Mike.Duncan at noaa.gov
Thu Aug 20 17:01:46 EDT 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Kinsella wrote:
> Hey guys - 2 thoughts:
>  * (topic-creeping a little, but...) On the education aspect, I think
> there's a decent bang-for-buck to a development org by trying to move
> towards a secure SDLC.  Getting the devs to think about SQLi is nice,
> but if the resources are there, start thinking about security a little
> earlier in the game.

It is essential really in my mind. Training is only the beginning of
trying to implement this. But, as you stated below...maturity-wise, a
big sign of a development shop's knowledge is their SDLC and training
budgets. Also, as I was trying to state below but may have lost it, the
auditor must be involved in the planning stages of SDLC for effective
and timely audits later. I absolutely hate it when a project comes up
for deployment and everything is hinging on our scan results but we have
no idea when/where/how this application fits in the whole picture.
AppSec is a lot more than just scanning application code for
vulnerabilities, but it seems some management personnel do not quite get
this. <rant sorry="yes" />

>  * Regarding Mike's point on VCS...I think I'd have a hard time doing a
> code audit of a cilent who didn't have the basic pieces like that in
> place.  That's the sign (to me) of a hugely immature organization that,
> quite frankly, I don't think would benefit from a review.  I guess,
> looking from a maturity model, I think of code reviews coming higher up
> the curve.  That does sound like a flaw in my thinking compared to the
> previous bullet, but...comments?

Good point. It is more wide spread than one may think though. At some
locations, developers "do not like to share power" (Gandalf) or insights
to what they are up to and management may value them over you.

The auditor is part of the development process and thus should be aware
of the code at any given point. VCS is essential to all development and
is equally essential in assuring the auditor can see the code which
needs to be deployed -- no matter how small the shop (IMO).

> 
> OK, one more thought...I think a mix of static+dynamic will provide the
> best results - when I've pointed out flaws in a web app's source and the
> client is trying to tell me that the web server is configured so that
> will never happen...very nice to be able to have scan results to see if
> that's truely the case...think about a medium-large sized organization
> where you're delivering a report to a engineering manager, his
> developers are saying one thing and you're saying another...nice to have
> a bit more ammo behind your report when possible.  Kinda circles back to
> the issue of management/developer trust...

Ah, I forgot to mention that using dynamic (black-hat) and static
(white-hat) scans are also very important. Great point and thanks for
the additional thoughts. I think this is great for the cases when the
developers think a WAF well be the catch-all for everything and your own
results using manual and/or automated scans can prove differently.

> 
> John

Mike Duncan
ISSO, Application Security Specialist
National Climatic Data Center, NOAA, US DoC


> 
> On Aug 20, 2009, at 1:07 PM, Mike Duncan wrote:
> 
> Mat Caughron wrote:
>>>> All:
>>>>
>>>> Have we all attained the realization that static analysis is where the
>>>> real work of appsec gets done?
> 
> Oh yeah. I find it hilarious that most security firms rely solely on
> dynamic scans to this day to give them a complete picture of application
> pitfalls.
> 
>>>>
>>>> I'll argue that source review (automated, manual) and enlightened DBA's
>>>> are broadly better at solving the insider threat problem than dynamic
>>>> techniques.
> 
> I would argue the same with the additional caveat that without regular
> training, the tools can only provide so much, so a developer's
> protection (the tool and their knowledge combined) blanket is limited.
> 
>>>>
>>>> Would love to hear from others who have been successful at uncovering an
>>>> insider threat with source code review/static analysis.
>>>> Specifically: what worked, what didn't?  How helpful, or not, was
>>>> version control or other typical controls around the development
>>>> process?
> 
> Primarily, as a developer for a long time and now a AppSec specialist, I
> found that development from project to project brought about limited
> scope to the developer for the said specific project. So, an outside
> developer or auditor should always be used for application reviews.
> 
> Additionally, as I stated above, training is a must for all developers.
> Relying on the tool(s) to do all the work will never fully protect the
> applications/systems because the tools really lag behind on most of
> their scans. Fortify for example, will do a great job telling you that
> something is not sanitized properly, but then fail to tell the developer
> that they are properly authorizing the user for a specific zone of the
> application. Tools have limited knowledge of the business and project
> requirements.
> 
> The auditor, although not a developer for this project, must be a
> developer or have been one in the past really. I have found in my time
> as an auditor there are too many people whom don't know the language
> constructs, libraries/dependencies, and/or technologies being used to
> effectively provide audit information. They often rely solely on the
> tool to provide all the information and we all know what that will lead
> too.
> 
> Also, and I know I am rambling here but, the auditor should be familiar
> with the project and business requirements for it. The auditor should
> know about the technologies being used before the first audit so they
> can effectively drive the developer(s) in a more secure fashion from the
> beginning. All too often the development begins, the auditor then is put
> up against a business objective (deadline) and everyone then starts to
> blame security for being the reason for development time-line failures.
> 
> It is a lot easier for application patching as well if the developer(s)
> are using proper source control. The auditor can then just look to
> changes from a good/gold version of the code. Also, the auditor will be
> able to decrease the time for the audit, knowing the language and
> constructs behind the project, because the changes are arguably much
> smaller. I have found personally, that patches/updates to existing code
> is much easier and does not require a complete source code review using
> a tool at all most of the time. But, I do complete [bi-]annual code
> audits to ensure that (forgotten) projects are protected against newer
> threats. If the changes to the code are great, requiring a major version
> numeric change, then I will use tools as well.
> 
> Great topic. Thanks Mat.
> 
> Mike Duncan
> Application Security Specialist
> National Climatic Data Center, NOAA, US DoC
>>
-
----------------------------------------------------------------------------
>>
Join us on IRC: irc.freenode.net #webappsec
>>
Have a question? Search The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/archive/
>>
Subscribe via RSS:
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>>
Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>>

> ----------------------------------------------------------------------------

> Join us on IRC: irc.freenode.net #webappsec

> Have a question? Search The Web Security Mailing List
> Archives:http://www.webappsec.org/lists/websecurity/archive/

> Subscribe via RSS:http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqNubkACgkQnvIkv6fg9hbXzQCgkrmGr+Wpg6N2WoQyQFrxVXr8
DzMAn1MhGpXkx7Dyd/82dyfvN6EFH6ef
=OCxd
-----END PGP SIGNATURE-----

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA



More information about the websecurity mailing list