/
body.tex
48 lines (30 loc) · 6.07 KB
/
body.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
\section{Introduction} \label{sec:intro}
There is a perceived risk that LSST images may be snooped during transmission from the telescope. This concerns the images used for alert processing which are transmitted within a minute and provide a valuable resource for identifying moving objects including satellites. Though our processing will ignore satellites other parties may be interested in this information.
In an email during September 2019 Steve Kahn indicated that all data should be encrypted. This would include transfers to Europe.
The baseline in 2019 remains encryption of controls but not data i.e. authentication is encrypted = data transmission is not.
.
{\bf It would be extremely useful if we agreed on the security rating of LSST data as per NIST \citep{nist800-60}}.
Naively one would assume the security objective would be \emph{Availability}, the potential impact would be \emph{low} for confidentiality, availability and integrity. Hence the Security Category (SC) would be \{low,low,low\} in NIST terms.
\section{Network security}\label{sec:net}
On the mountain and in the base facility LSST networks and computers are in rooms requiring ID card access and the compounds
have 24/7 security staff.
We could increase security but it would be costly and probably not very popular with staff i.e it would require raising the security level of the entire facility to something like FSL\footnote{\url{https://emilms.fema.gov/IS1172/groups/85.html}} 2 .
The transfers from Summit to Base and Base to NCSA go over private networks that are not part of the public Internet. We have our own dedicated fibers running from the mountain to the base \citedsp{LSE-78},
intercepting transfers would require physical access to the fibers - tapping those would probably disrupt our network at least temporarily.
For an added security we could also monitor fiber attenuation.
The network was actively monitored withe Bro\footnote{\url{https://www.corelight.com/about-bro/how-bro-works/}} system which is currently inactive we expect this to come back online under NOIRlab. Hence we would at least known something was up.
Though technically feasible by perhaps bribing or coercing staff somewhere this seems unlikely - a physical tap should also be noticed during fiber inspections. The image as transferred over this line is also in an obscure format (though could be put together with some effort).
International transfers to IN2P3 are still being worked out at this time. This may be done on shared commercial carrier. One assumes
this is relatively secure though not perhaps as secure as our dedicated lines. ESNET could be used for this transfer as well if it did not originate at NCSA. There seems no particular reason to do this transfer from NCSA as opposed to directly from Chile or landing it
temporarily at some ESNET endpoint. One may consider the open storage network \citep{osn} for this also though its not currently the baseline.
\section{Transmission security} \label{sec:trans}
It has been indicated, through DOE, that holding data for some time before releasing to the collaboration is an acceptable approach to securing the images - this can be ensured by limiting the LSST personnel who have access to the files during the night.
We would transmit images for alert processing in near realtime to NCSA. We have suggested a six hour delay - there has been no indication of how long the delay needs to be - is one hour sufficient to prevent detection of satellite maneuvers ?
Currently alert images from the base are to be transmitted using BBCP\footnote{BBCP is an alternative to Gridftp when transferring large amounts of data}. The control channel is encrypted but the data channel is open - this is considered secure in the scientific world \citep{bbcp}. Hence theoretically packets snooped on their way to Illinois could be extracted and processed.
We could encrypt the data channel. This would cost us in compute, potentially doubling or more the number of cores needed for transfer. We would also have some software modification and setup, projects like WireGuard\footnote{\url{https://www.wireguard.com/}} intending to do this at the kernel level could ameliorate this somewhat.
There are also examples of hardware solutions for this which would probably be affordable, INRIA in \cite{10.1007/978-3-642-45073-0_1} have build a FPGA based AES\cite{aes} implementation which gives 100Gbit/s network rates with $\mu s$ additional latency. Table 3 of \cite{10.1007/978-3-642-45073-0_1} lists the hardware which looks modest enough - we work with INRIA already. There is no price given in the document, but considering the cost of components and a contract to put it together one \emph{might} consider it to be under \$1M, but we would need to get a quote.
We could encrypt the images themselves before transmission or even on the FPGA of the camera data acquisition (DAQ) system. The DAQ is complex construction prone to delays so we would rather not jeopardize the project by introducing changes there. Encrypting the files outside would mean more CPU and I/O - it would add a delay in the alerts processing - it may take as much as 20\% of the alerts time budget (1 minute). This would not be very welcome in the science community. This would require some effort on our side to add encryption to the processing chain but this should be order some hundreds \$K depending on how \emph{secure} it is required to be.
\subsection{Keeping it in Chile}\label{sec:chile}
The original baseline was to do alert processing in Chile in the base facility. Some years ago support for computing in Chile was sub optimal but has improved significantly - there is space in the base facility to hold machines for this.
This would make the base data center the prime target of any data attack so we may need to review security there.
However if we agree the base/summit are secure we could avoid on the wire snooping by doing alert processing in the base facility. We would also then have to hold images there for the appointed embargo time before releasing them to the community. We would need to do some work on the cost impacts of this but they should not be insurmountable.