+ malicious projects
 - may start off harmless, but at the last minute does data theft

+ project servers could be compromised
 - hack via ssh vulnerability, etc...
 - compromise key, data, etc.

+ what to tell people who don't understand?
 - "distributed computing has been around a long time, never been compromised"
 - each project in control of its own certificates

+ fundamental thing -- need cookbook on a default, secure server
 - how to protect your key
   - also contingency plan to change key, clients will get new key
   - if machine is compromised, only a matter of time

+ certificates that are signed by verisign, etc?
 - each project is its own CA
 - in theory, each project's certs could be signed by root authority
 - could be prohibitively expensive for the kind of cert from verisign that we'd need

+ users have to trust a nice-looking website (the project sites)
 - malicious application code -- can sign it, but have to trust the project
 - could have a secure, trust-worthy site w/ a project admin who's malicious

+ WCG looked into some security company to audit and certify
 - could be close to $80K
 - results wouldn't be acceptable to everyone

+ method to secure the (gridrepublic) website
 - port scans, intrusion detection, monitoring, etc
   - bastille or one of the automated detection suites
 - central interface to monitor more than 1 server
 - get volunteers to monitor 24/7
 - virtual full-time security staff?
 - present that to boinc_projects and see who bites:
 -- majority hosted by universities w/ huge regulations, etc.
 -- most don't like people doing security scans outside their own IT people
 -- but, if a university has its act together so much, this isn't as much an issue
 ---- a lot of co-location ISP things don't care and don't check
 ---- have to pay a lot extra for full management

+ malicious code on your computer:
 - restricted user for applications
  - mac w/ user sandbox will be first
 - app still runs on the OS
  - can still do chroot()
 - eventually need real virtual machine -- entire OS as its own process.

+ php attacks, SQL injection, etc -- forum software w/n BOINC
 - recently found SQL injection vulnerability, fixed quickly, but projects didn't upgrade

+ get across to everyone who runs a project that the risks they take impact all projects, not just their own
 - any project being compromised would ruin (or severely harm) BOINC's reputation
 - want to certify the BOINC projects themselves?
 - too many restrictions on server stack?

+ projects have mail servers -- yet another risk?
 - not included in the BOINC bundle?
 - things handled independently shouldn't be excused from list to worry about?
 - such a list would be enormous -- BOINC should probably focus on BOINC vulnerabilities

+ publishing anything about security is a challenge?
 - DC is already a challenge to hackers...

+ first pass document on how to security
 - private code signing key on a completely secure, not-on-net security
 - doc needs to be updated, improved, and re-released
 - want to provide access/links to tools

+ "i want to know what to tell grandma"
 - IBM's name on there is best we can tell
 - IBM's CIO gave it a bill of health

+ many constituencies with different requirements/needs/stories

+ infrastructure for security
 - mailing lists for announcements
 - what should the CVS commit message say
 - how to handle announcements, vulnerabilities
 - process for emergency messaging?
 -- trying to get projects to upgrade to BAM was a lot of work
 -- security would take more precedence, but mostly ad hoc
 - could add a boinc security emergency broadcast list "boinc_announce"?
 -- do we need a boinc_projects_announce?
 - security@boinc for the core security team for reporting/discussing vulnerabilities
 - new messages in the BOINC client to alert for new releases?
 -- new protocol between AMS (or projects) and the client to notify?

+ huge subject
 - BOINC itself, projects, apps, servers, etc...
 - have to prioritize the list
 - if you put a project on the BOINC website, it's sort of like endorsing it...
 - minimum standard of security practice

+ projects that allow others to submit into their project
 - submitting data sets into a known application
 - submitting their own applications?

+ certification of applications as well as projects
 - need to be able to audit the source code

+ ability to have a stop-switch to halt all computation in an emergency?
 - if a project is compromised, and is distributing malicious code, how to shut it down?
 - BOINC client software could poll central server (AMS, boinc.berkeley.edu?) for suspending a project or even all projects...

+ US-based -- own problems
 - U.S. gov't wouldn't want cuba, north korea, etc, to run a project.
 - someone doing "bomb design" with BOINC?
 - if there was a malicious project, it'd be rooted out pretty quickly
 - (united devices grid.org -- story about anthrax research)

+ can see BOINC as just providing software, takes no responsibilty for projects, or BOINC has to take some responsibility and then it becomes more of a problem...
 - app audits
 -- entirely specific to each science domain -- hard to standardize
 - project audits
 -- can have cookbook, but can't enforce it
 - what's BOINC's responsibility vs. projects?
 -- if BOINC's not going to do more, who is?

+ accountability, responsibility, reporting, etc.

----------------------------
action items:
----------------------------

- creation of boinc security team/list

- emphasize security responsibility for projects -- 1 mistake hurts all projects

- updating the project security cookbook

- research/code on sandboxing/virtual machines, etc
-- preventing harm even if compromised

- potential protocol for emergency shutdown of work, e.g. via BAM or boinc.berkeley.edu