Policy-Discussion

[Russell Smith <mr-russ AT pws.com.au>]

On Sat, 23 Jul 2005 12:48 am, Duane wrote:
> Russell Smith wrote:
> 
> > What audit, there has been no audit that I am aware of.
> 
> We actually have had a "first run" draft type audit where someone has
> read over everything and inspected what documentation existed and gave
> us some feed back on it.

Do we have a document for what came of the audit "first run", eg what needed 
to be fixed?

> > Only the people who collect it (assurers), the person who supplied it and 
> > people with physical server access.
> > The only information kept (Except for TTP) is Name and date of birth.  
> > Assurers have types of ID used, which is basically pointless for useful 
> > information.
> > Everybody knows they types of ID another person is likely to have.
> 
> Ideally the assurer should get permission from person being assured, but
> this has it's own draw backs but perhaps we should be trying to move in
> this direction.

Should we also move to make sure that the person being assured checks the 
identity of the assurer, as to give both the assured and assuser the same 
information about each other?
This would also help to reduce assurers who have incorrect details, as those 
who are assured will have a few questions about why details are wrong.

> > I'm not sure how much information there is to 'protect' for Web of Trust. 
> >  For code signing certificates and TTP forms, there is physical security 
> > of
> > documents which I have asked questions about before.  How secure are our 
> > Date of Birth and Name anyway?
> 
> Name and Date of Birth are a good start for people wanting to commit
> identity theft, since we also store a location (or a good approximate)
> that would also be useful.

True, employing people is the best way to do identity theft.  Name, DOB, 
Address, Tax File Number :)  But that's hard in AU, I assume in other 
countries it's easier.

> > I'm not sure of the physical server protection, apart from what is 
> > written about server comprimise and security there.
> 
> I'd really like to have Xen setup on the server, and other things that
> don't exist like an SQL proxy to reduce risk if there is a breach and
> limit how much information can be exacted in that situation.

What sort of proxy would you be looking for?  pgpool is a connection proxy 
for postgresql.  However I know MySQL has been chosen for
this project.

Would the SQL server be secured on a third machine, with only network 
connections allowed on the relevant port?
I assume the only way to protect data is to ensure that only certain queries 
can be run.  As if you comprimise the web server, you have all the passwords 
to connect to the SQL server.
I'm not sure how exactly the SQL server could be secured, it needs more 
flexible access than the root key server.

However thinking about it, you could require a limited set of queries which 
include your certificate or password included in the query.  The sql-proxy 
checks those before executing anything.

All just ideas, I'm not sure on the best way to do something like this.

> 
> Currently running a pair of firewalls, jailed processes and things like
> that, the server is in a secure colo facility, which is also a facility
> a number of banks do their web hosting in actually.
> 
Always good for people to  know.  Not sure how banks link their transaction 
management stuff into those machines though.

Regards

Russell Smith