| 1 | [[TOC]] |
| 2 | |
| 3 | '''Needs attention:''' |
| 4 | * When Steve finds out how large the repo is, update the storage section |
| 5 | * Someone investigate encrypted loopback images and expand that section |
| 6 | * Policy issues needs more work |
| 7 | |
| 8 | == Running the malware == |
| 9 | |
| 10 | === Infrastructure security === |
| 11 | |
| 12 | Revisit the firewall rules on router to prevent leakage channels. Absolute minimum set of services should be allowed from testbed -> users/boss/etc. |
| 13 | |
| 14 | === Isolation from other experiments === |
| 15 | |
| 16 | Control net separation |
| 17 | |
| 18 | == Storage and Leakage == |
| 19 | |
| 20 | Primary goals are to allow vetted users to access the malware safely and prevent unauthorized users from gaining access. |
| 21 | |
| 22 | === Leakage of binaries === |
| 23 | |
| 24 | Some belt-and-suspenders support to prevent leakage is to export NFS shares read-only: |
| 25 | |
| 26 | * /proj, /groups, /share, etc. |
| 27 | * home directories |
| 28 | |
| 29 | === Storage === |
| 30 | |
| 31 | Where/how we store it depends on how large it is. Steve is looking into this. |
| 32 | |
| 33 | * Loopback encrypted file system on users:/share, read only |
| 34 | * Encryption options |
| 35 | * Shared password |
| 36 | * Revocation (is this necessary) |
| 37 | * OS ID with strict access controls |
| 38 | * Is it possible to limit the projects this is exported to? |
| 39 | |
| 40 | == Policy Issues == |
| 41 | |
| 42 | * Do not copy it off experiment |
| 43 | * Do not attempt to run on non-malware experiment |
| 44 | |
| 45 | == Miscellaneous == |
| 46 | |
| 47 | Updates will probably be done via HTTPS with a client certificate. This depends on the GA guys. |
| 48 | |
| 49 | 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)? |