Meeting in Vienna 20081222
Meeting opened 10:30 Present: Philipp Dunkel, Rasika, iang (minutes). Action points in bold.
Misc
- Rasika could be added to internal audit team for now
as -> Internal Audit (test taken 2008 december)
- (unknown when final result is revealed)
Disaster Recovery
- discussion consisted of a working attempt to create a Disaster Recovery plan.
(rasika) created a starter list of BusinessProcesses, following CISA guide.
developed plan from processes as per DisasterRecovery
- see SM
- Redundant versus hot standby
- MySQL has online PUSH?
- (Philipp D) we want hot standby, is already in MySQL? sysadm?
- don't want any software development effort put in ....
- Hot standby machines should exist in the same facility.
- cannot secure elsewhere
- could ask HCC
Backups
- where?
- for security and reliability: they should be in the same place
- Disaster Level 1: hard
- Disaster Level BIT: BIT is down
- Availability of backups offsite
- Security cannot be ensured for transmission and storage of remote data...
- offsite backups need to be offsite.
- Suggest
- Make it incremental: dailies stay in the same town
- rotate physical backups: new one arrives; send old one to escrow.
- Weekly fedex packages to somewhere...
- recover from next neighbour jurisdiction
Privacy
- (Rasika) Background Check
- procedure and ruling (recommendation) should be public
- interview, documents should not be public,
- summary of evidence should be in the ruling.
- Arbitrator can rule on the escrow questions of evidence
- New proposal (written by Philipp D) reviewed quickly on laptop screen
- it has been sent to board only so far
- was written in a meeting last week between Philipp D and Philipp G
- Some basic pointers needed
- that is, training + test
ask Ted to set up, start pumping in some questions
- need a legitimacy step for test+questions
- board or policy to be asked to approve at some point
- Go back to board, ask for objections, into SM.
Philipp D: the proposal needs to be distributed, only to board so far
Software Development
- 4 eyes work in the software development
- today, software development == philipp G
- Philipp wants a governance methodology for SD?
- he may want to provide 4 eyes, in software development
- (PG? PD?) has provided a way to do the software development methodology.
Philipp G is writing up the Software Development
- "define this to the point that you can hand it over to someone else"
- 29th Monday after Xmas
- Assurer Change from Software Development to Sysadms.
- Ted has the patch to switch off the old Assurers
Ask Ted to RESEND it as a patch to Philipp G + Philipp D
- mechanism: is it a patch(1) ?
- Software Development Patch procedure, needs to cover
- sending patches to the sysadms
- receiving patches from the sysadms
- (rasika) this is the role of the media librarian
- Governance as it impacts software development
- Philip D: 4 eyes needed over all support actions
means we don't need so much control on TrustCheck
- Software Development cannot install patches, only Sysadms.
- Must be a handover.
- Review of patches
- Sysadms can review the patch; all source code is PHP, non-black
- Sysadms have the responsibility to do a random check:
- "random" means also to include "all" and "none".
- other people can also check it.
- if a check is done, comment added to code in subversion
- sysadms do not write code: they only add comments!!!!
- sysadms will be kicked out if they fix code
- perhaps make the comments into an ACL-controlled file like README or REVIEW-COMMENTS at top of tree
- Software development does not know which checks are done.
- so, code and patches might be checked at time.
Formal meeting closed 18:30.