wiki:SecurityUseCasesInternal
Last modified 11 years ago Last modified on 07/23/2008 10:20:43 AM

Internal Use Cases and Workflows

Telescope

  • Want to limit the number of people on the summit
  • Definitely need to control from base
  • Would be nice to have option to control remotely
  • Remotely operated telescopes
  • Controls
    • Goal: mostly robotic -- want as little human interaction as possible during normal operation
  • Risks
    • Always keep somebody on the summit
    • Trust sensors up to a point

Camera Remote Access

The camera team would like to enable remote access to the instrument itself.

  • Risks:
    • Hardware designed to self-protect against damage. A basic principle of camera design.
    • Danger is of getting into a faulty configuration that takes time to recover from, meaning
      • Lost time
      • Lost data
    • Denial-of-Service from too many diagnostic inquiries, or from expensive inquiries
    • If we give rules that are likely to be broken, let's figure out how to still be safe:
      • Have a procedure for violating the restrictions
      • Human ability in the loop -- "Three people say ..."
  • Use cases:
    1. Remote monitoring -- read-only
      • Visualization of raw data
      • Diagnostics
    2. Remote troubleshooting
      • During initial deployment, when working out kinks
      • Once operation begins, troubleshooting only necessary in exceptional cases, since normal operation is automated
      • Most troubleshooting will be passive data collection
      • Active troubleshooting -- tweaking settings -- will be rare and will be done by experts, who may not be on the mountaintop when we need help
  • Security design (from perspective of user interface)
    • A human will be on the summit during operation
    • Base facility control system is an extension of the control system on the summit
      • A copy of the console
      • Rich feedback from camera
      • Dictates when the camera can take exposures
    • Changes to camera settings
      • What are they?
        • breaking automated control & cadence
        • changing parameters and thresholds
        • opening, closing valves
        • defeating alarms
      • Require possession of "token" to make changes (singular if interface doesn't allow concurrency, or multiple if it does)
      • "Token" is approved by on-site operator, who monitors changes being made
        • Can only be granted to known experts; built in to camera control software
        • Operator monitors changes being made -- may not have expert knowledge of all of them, but can provide a sanity check
        • Auth'n and security gated by both computer (password, VPN, etc) and human (telescope operator)
        • Need to trust control software. How much do we trust software running on operator's machine? How much do we need to -- can we run it all on the server side?
    • Does the remote operator's location make a difference?
      • from base facility
      • from nearby, for example Santiago
      • from anywhere else in the world
      • from an unsecure computer or location