Needs attention:

• When Steve finds out how large the repo is, update the storage section
• Someone investigate encrypted loopback images and expand that section
• Policy issues needs more work

Running the malware

Infrastructure security

Revisit the firewall rules on router to prevent leakage channels. Absolute minimum set of services should be allowed from testbed -> users/boss/etc.

Isolation from other experiments

Control net separation

Storage and Leakage

Primary goals are to allow vetted users to access the malware safely and prevent unauthorized users from gaining access.

Leakage of binaries

Some belt-and-suspenders support to prevent leakage is to export NFS shares read-only:

• /proj, /groups, /share, etc.
• home directories

Storage

Where/how we store it depends on how large it is. Steve is looking into this.

• Loopback encrypted file system on users:/share, read only
  • Encryption options
  • Shared password
  • Revocation (is this necessary)
• OS ID with strict access controls
  • Is it possible to limit the projects this is exported to?

Policy Issues

• Do not copy it off experiment
• Do not attempt to run on non-malware experiment

Miscellaneous

Updates will probably be done via HTTPS with a client certificate. This depends on the GA guys.

How will we annotate the experiment file to let the testbed know this needs special treatment (i.e., read-only mounts, copy encryption key/token to box)?