Last modified 11 years ago Last modified on 05/23/2008 05:28:34 AM

This page is part of the Security topic

Security Breakout Session Notes

LSST All-Hands Meeting 2008

Friday, May 23, 8-10 am, NCSA room 2100

Presentation Slides

1. Feedback on Security Plan

The Security Working Group is preparing an outline of a security plan for inclusion in NSF PDR (Preliminary Design Review) in October 2008. We'd like to hear comments from LSST participants to help us develop the plan.

2. Internal Use Cases

LSST participants: What remote access do you want within the LSST network? We need to collect internal security use cases.

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

3. Experience from Other Projects

Other science projects have faced similar requirements & challenges. What can we learn from them?

  • Spitzer
  • Sloan Survey