2firewalls.tex

\subsection{Install Firewalls and other physical security devices} \label{sec:2firewalls}

This requirement is for physical and cyber security. It includes installing cameras and locks on racks.
Some of this such as Firewalls is already in the project plan but much of it is not.

Items already in the baseline include:
\begin{itemize}
\item Card access to server rooms.
\item Backup network in case main link fails (though the microwave link is a new addition ..)
\item Auditable process to handle onboarding/offboarding
\item Some cameras are in the project but not complete coverage.

\end{itemize}

Additional items may include locks on server racks, sensors and cameras to record the opening of  cabinets, out of band channel for physical security alerts if the main network is disabled, and controls to  prevent booting from USB devices or copying to external media.

The firewalls and physical security will be upgraded to meet the enhanced standard. \tabref{tab:firewalls} includes the items needed for this upgrade.

{\bf Important Note}: We shall ring fence the \gls{camera} in its own firewall with more restricted access than the restricted control network.
However we will treat it as a black box deliverable for this requirement. We shall not expect encryption of the internal disks of the \gls{camera} system. Any perturbation to the \gls{camera} system will have a deleterious effect on the \gls{camera} with significant development and schedule impacts.

Signage and labeling, as required in \gls{NIST} 171 3.8.4 \footnote{\url{https://www.archives.gov/files/cui/20161206-cui-marking-handbook-v1-1.pdf}}, will be developed as appropriate.

NIST 1.7.1 Section 3.10.6 pulls in extra standards for remote work namely \citeds{nist800-46} and \citeds{nist800-114}.
\citeds{nist800-114} is the broader scope and we are pretty much in line with how it is written - we note Section 5.2.1 that we use Onepassword as a vault for \gls{IT} passwords - not paper in a fire proof safe as recommended.
Some other suggestions are understood to be useful in general but often not suitable for developers - personal firewalls, application filtering  and aggressive antivirus \gls{software} often trip over developer code and tools.

\citeds{nist800-46} and other related NIST documentation suggest threat modeling - we do this in a limited way e.g \citeds{SQR-041} and \citeds{SQR-037}. A more exhaustive risk assessment by a third party is not anticipate at this time but the Project team will discuss with SLAC on any plans to review the \gls{USDF}.
We do not store sensitive information on the \gls{VPN} nor bastion nodes.
We do use \gls{NAT} in a limited number of places - this will be more important in operations if/when we move to IPv6.



\input{tables/firewalls}



This enhanced security plan includes support from an outside security provider.
It is estimated running an \gls{SOC} could cost upward of \$1.4M per year\footnote{\url{https://expel.io/blog/how-much-does-it-cost-to-build-a-24x7-soc/}}.
This article\footnote{\url{https://www.linkbynet.com/outsourced-soc-vs-internal-soc-how-to-choose}} outlines the pros and cons of
an outsourced \gls{SOC} and estimates it at between 300 and 800K per year.
For budgeting purposes  \$40K a month is included in \tabref{tab:firewalls}.
Such a contract (or contracts) should cover:

\begin{enumerate}
\item Proactive \gls{monitoring} and alerting (NIST 171 section 3.3.5)
  \begin{itemize}
  \item Write alerts for suspicious behaviors
  \item Analyze collected logs for anomalies
  \end{itemize}
\item Root cause analysis of any alert or anomaly
\item \gls{Incident} response
  \begin{itemize}
  \item Isolation of attacker
  \item Forensic analysis leading to timeline and inventory of compromise
  \item Identifying systems that will need to be rebuilt
  \end{itemize}
\item Vulnerability scanning including filtering out false positives
\item Asset inventory including \gls{patch} status
\item Penetration testing to proactively look for vulnerabilities
\end{enumerate}

This will require extensive coordination and integration with existing \gls{IT}
services and processes, included as part of this cost.

Since we will have to encrypt systems on the summit (see \citeds{ITTN-014}) for a list of systems)
we anticipate upgrade processors and \gls{SSD} are required. Determining the detailed specifications will require experimentation so the
values in the table for this are engineering estimates.

Note that compute facilities for the \gls{Commissioning} Cluster at the Base as well as Alert Production and the Staff RSP at the USDF are not considered to be within the physical security area.
Rubin considers the short-term, ephemeral processing on these resources outside of the enhanced security requirements. Including them would approximately double the cost of this item for \gls{Construction}.