Re: Wanted: hackers for tiger team (new england area)

[rouilj () cs umb edu (John P. Rouillard)]

> > % As long as we can be sure the person/group is going to tell _all_
> > % that they found..... then we are interested in paying/contracting ect..
> > % We don't want to pay someone to bang on the doors and then tell us 1/2
> > % of our bugs and then tell the cracker comunity the other half :-) :-(
> > %:-(.... The half we get is commonly the half we already know e.g. not
> > % worth our time/money.
> >
> > This is rich... You get a tigerteam to bang on the doors, and you
> > haven't even plugged all the old holes yet? I could understand this if
> > you were a normal everyday company, just on the road to get their
> > internet connection up and running. But not from Sun Microsystems Inc.
> > You guys are supposed to be able to fix things from source, right?

One problem with tiger teams that I have difficulty getting through to
clients on is that a tiger teams can not prove that the system is
trustworthy. It can uncover holes in the security model, (when I do
tiger team work, I get full details of the firewall/security
installation), show that things aren't working as expected, but it
doesn't prove that things are secure.

Thas said, some sites that have had tiger teams leave/install holes
for the tiger team to find. The rational is that the team will do its
job and should discover darn near 100% of the known holes. If they
don't then there is usually something missing in the testing
methodology. If they only manage to find 50% of the holes/traps that
were planted, then I would have serious doubts about their attack
methodology, or the trustworthyness of some of their members.

On strategy that often works for testing tiger teams is to put traps
into active bugs. I was hired to do this to a few
programs/daemons. Weren't we surprised when we didn't see these bugs
listed on the report that they returned to us 8-).  I knew this bug
had been caught since my logs showed its use.  It was later found out
that one of their people was "less than honest" about all of the bugs
he had found.

                                -- John
John Rouillard

Senior Systems Administrator              IDD Information Services
rouilj () dstar iddis com                         Waltham, MA (617) 890-1576 x225

Senior Systems Consultant (SERL Project)  University of Massachusetts at Boston
rouilj () cs umb edu (preferred)                  Boston, MA, (617) 287-6480
===============================================================================
My employers don't acknowledge my existence much less my opinions.