Changes between Version 6 and Version 7 of Policies Compliance

Timestamp:

May 11, 2020, 12:41:08 AM (5 years ago)

Author:

msherman

Comment:

—

Policies Compliance

@@ -30 +30 @@
 
 == Emergency Stop Procedures
+All transmit capable devices have either a method to either disconnect the RF front-end, cut the power entirely, or both.
+
+In the event of an emergency, the testbed operators can hard power off any offending device.
+
+In the event of an issue with the central co-ordination service, watchdogs on each node will, after a short timeout, automatically power off the RF components.
 
 == Network and Platform Security
+
+=== External Network Access
+Only authenticated users can log in to the Consoles and and other SSH jump hosts. We assume that the user connecting with a given SSH key is the same user that uploaded it to the portal. 
+
+**Important** The user takes all responsibility for safeguarding their local SSH keys. Best practices, such as strong passphrases should be followed.
+
+Our SSH endpoints are configured following [https://infosec.mozilla.org/guidelines/openssh the Mozilla best practices guidelines].
+
+VPN access is similarly gated on the testbed access credentials. SSH and VPN connections may only be initiated during a reservation, and are closed automatically at the end of said reservation.
+
+All externally facing machines are behind a firewall, as well as having their own security mechanisms configured.
+
+To access their own files, or the testbed resources, a user has to connect through one of the configure Jump Hosts. All Jump Hosts log user access to a central location.
+
+=== Internal Network Access
+External Access, Experiment Control, and Experiment Dataplane networks are isolated with VLANs and ACLs on the core network switches.
+
+To connect to Domain Resources, a User must pass through the Domain's Console.
+
+=== Shared Machines
+User data is safeguarded by standard POSIX permissions. Safe defaults have been set, but it is the users' responsibility to avoid running untrusted code, or setting their own files to world writable.
+
+Shared machines are treated as if public, from a security perspective. It is assumed that all connections, both from external networks, and from experiment networks, are untrusted by default.
+
+Cron jobs or other long running commands are permitted after the end of a reservation, as the management process will kill all processes spawned by said user.
+
+=== Testbed Compute resources
+
+Within a Domain, and during their Reservation, users have full rights to the Compute Resources, and have both root and serial console access. 
+
+These machines are insecure by default, except for these factors:
+
+* No network access from outside. A combination of a stateful firewall and NAT prevents external entities from initiating connections. This is the standard assumption for say, a properly configure Home LAN.
+* No access between experiment networks, unless configured. Users are able to manually bridge networks, during their reservation, if they have the relevant rights. Users must act according to their own security model.
+
+When a compute resource is provisioned, the disk is overwritten. At the same time, if sensitive information is saved to disk, it is the experimenter's responsibility to erase the disk with our provided commands.
+
+