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

Jim Manico jim at manico.net
Thu Aug 13 17:49:05 EDT 2009


> I think it is nearly impossible to protect a large, complex software
product against a determined, competent attacker who is a software
developer writing the code for said product.

I concur. In fact, Jeff Williams (disclosure: [one of] my [many] boss[es]) 
gave a detailed talk on this topic at Blankhat and at Java One.

http://www.blackhat.com/presentations/bh-usa-09/WILLIAMS/BHUSA09-Williams-EnterpriseJavaRootkits-PAPER.pdf

So back to the nearly impossible part - specifically Java policy and .NET 
code managment features come to mind. Java policy lets you give specific 
classes specific file/IO and network access. For example, you can block all 
classes from outbound socket connections by default, and only permit certain 
classes (like your webservice clients) to make connections.

This is a pain to get right, even more of a pain to maintain - especially 
since the tools to manage Java policy are poor, at best. But I think it's 
our best defense in protecting an enterprise against the insider evil coder.

- Jim



----- Original Message ----- 
From: "Eugene Kuznetsov" <kuznetso at gmail.com>
To: "Mat Caughron" <mat at phpconsulting.com>
Cc: <websecurity at webappsec.org>; "Hoffman, Billy" <billy.hoffman at hp.com>
Sent: Thursday, August 13, 2009 10:17 AM
Subject: Re: [WEB SECURITY] code review techniques for when you don't trust 
your developers or testers


>> for when you don't trust your developers or testers
>
> While we're being controversial, when you say "don't trust" do you mean
> mistakes and negligence, or really active malice, as others have taken
> to mean it?
>
> Because if it's really "insider threat", I will add to the controversy
> to say the following:
>
> I think it is nearly impossible to protect a large, complex software
> product against a determined, competent attacker who is a software
> developer writing the code for said product. One should obviously make
> use of all automatic and manual processes conceivable, but the issue is
> similar to the problem of insider threat in espionage -- if you have a
> trusted employee who has gone over to the other side, and they have
> years in which to plan and do their damage covertly, you're probably
> better off with weekly polygraph tests than software testing tools.
>
>
>
>
>
> ----------------------------------------------------------------------------
> 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



More information about the websecurity mailing list