perfsonar development work

[maxim <>]

Hi Loukik,
Please review the text below with following template of Security plan
applied to MDM service deployment document.
Feel free to ask any questions and please redistribute to all interested
people.
It seems like more closer discussion is needed to complete this document.
 Thanks,
             Maxim Grigoriev.
----------------------------------------------------------------------------
----------------------------------------------------------------------------
--------------- 

On overall deployment model:

1. The Service Specification is not setting well defined boundaries on the
monitoring domain. 
For some unexplained reason the proposed service boxes will be open for
on-demand tests to the whole world. 
The title of the document says "MDM Service for LHCOPN". That means the
service should be used explicitly for LHCOPN monitoring. The whole
deployment must be tweaked down to satisfy requirements of the LHCOPN
network for now. Any other extensions should be introduced in different
document since every one of them will introduce extension to the current
operantional and security policy.

2. The deployment model should  scale beyond 1 Router - 2 Routers - Triangle
of routers use cases.
In general this appliance should be able to monitor N links on M routers and
the best way to achieve that
is to introduce collection webservices  localized  by  the owners of the T1
infrastructure. This leads us to the next item.

2. There is no clear understanding who will be the owners of the monitoring
data.  From the T1 NOC center 
point of view the owner of the data is T1 and   T1 NOC is responsible for
managing the data.
This service is taking over this role, but without introducing even
contingency plan ( risk assessment, 
backup procedures ..etc) for the monitoring data. If there is no such
intention to own the monitoring data
but merely publish it then another deployment model must be proposed. For
example MDM service will be
used for some limited on-demand tests and will be publishing all results to
locally deployed and maintained MA(s).
From this perspective the whole service should be divided to   data
publishing part ( open to the whole world, possibly supported by centralized
service desk) and local data collection  part.
 The late one should have an option to be deployed as software service on
the local host and configured and supported by the local NOC.

3. It does not seem that having a single centralized point for  all aspects
of configuration management of such boxes (named DANTE service desk) is  a
scalable and robust model to pursue. 
I can understand the need for centralized OS and software updates but I am
convinced that network related details ( local routers config, SNMP polling
etc.) must be carried by local NOC and therefore the configuration
management service ( interface ) should be provided for that. Also its not
clear from the proposal who will be defining alarm thresholds for the every
measurement carried by those boxes, although this
feature is mentioned for the every  type of measurement.

4. Hardware configuration of the boxes are too constrained and detailed (
Cat 6 cabling !?  ) . The T1 NOC should have an option to deploy software
solution on their own
equipment if there is a hardware configuration available  which satisfies
requirements for proposed  measurements. 

5. Proposed hardware support does not scale well beyond European NOCs and
there is an absence of contingency plan for hardware related problems (
backups, failover  ???)

6.The Security part of the document should be rewritten with Security Plan,
Risk Assessment and Contingency plan for the whole service and with some 
additional details, covering an each hardware piece.
      a.  for example having inbound SSH connection to terminal server is a
considerable security risk and security plan for such server should be
appended as well
          -  explicit limit on specific IPv4 address range for inbound SSH
access, 
          - SSH public key renewal policy, password aging policy
          - local computer security team should be notified about SSH
service running on this box and 
            regular scans from the Fermilab's security scanners should
arranged with results copied  to the local security team
         -  regular access log examination should be arranged
         - risk assessment of most anticipated security risks must be
provided and mitigation points must be presented
         - contingency plan should be attached with description of the
procedures needed if this box will lose its network access,    console login
for the Fermilab personnel should be provided 
         - service agreements and MOUs should be provided for hardware and
software support 

7.  Putting words like "The strengths of the UNIX operating system, the
built-in firewall and Red Hat support will be used to make sure that high
levels of Operating system security can be guaranteed"  is not a proper way
to describe the kind of security plan will be provided.
  For example,  Fermilab is a home for Scientific Linux (SL) operating
system (https://www.scientificlinux.org/ with special tighten up edition
called Scientific Linux Fermi (SLF). 
There is already existed centralized patching solution called YUM to make
sure that operating system is
patched with all the recent patches and software is updated on time.  At
Fermilab we have a long and productive
history of dealing with security issues on the open lab campus and therefore
SL system is already  in compliance with
security policy here at Fermilab, BNL, CERN and almost every University in
US. Its open source, supported by dedicated professionals here at Fermilab
on regular basis.

----------------------------------------------------------------------------
--------------------
Please see below an example template of the Security plans:
----------------------------------------------------------------------------
-----------------

  Based on our experiences with developing security plans 
conformant with US National Institute of Standards & Technology (NIST)
recommendations, we would suggest a security plan template consisting of the
following components:

I.  Background:
 

Description of the system, its function, network connectivity requirements,
and network access requirements

 

II.  Risk Assessment:

Identify general classes of vulnerabilities, then assess the system’s
specific vulnerabilities, or lack thereof, to each general class of
vulnerability.  The general vulnerability classes typically identified in
our risk assessments are: 

–        Remote access vulnerabilities

–        Operating system vulnerabilities

–        Application vulnerabilities

–        Inappropriate use or user vulnerabilities

–        Physical access vulnerabilities

 

III.  Security Controls:
 

Describe security controls that will be put in place to mitigate the
identified risks.  Several specific security controls that we would expect
to see in place:

–        A set of documented software maintenance procedures.  This 
would include regular & routine update service, as well procedures for
becoming aware of and fixing newly discovered vulnerabilities.
 

–        A regular security testing & evaluation (ST&E) process for 
ensuring that the system’s configuration conforms to its specified 
configuration
 

–        The capability to detach the system from the facility network 
without impacting LHCOPN operations
 

–        Designation of a site contact person with assigned local 
responsibility for the system

  

IV.  Contingency Planning:

 

In the event of system failure, or forced removal from the network, 
describe the procedure(s) for recovery and return to service.  This 
section would logically include procedures for removal from the network, 
any interim steps toward a temporary or partial return to service, and 
procedures for replacing, rebuilding, or restoring components of the 
appliance. 

 

V.  Variance on local policies or procedures:
 

It is highly likely that the system’s security plan will not precisely 
conform to local security policies and procedures.  This section would 
be a site-specific description of the variance(s) necessary for 
installation of the appliance, including any mitigations required.  This 
section is presumed to be the outcome of discussions between DANTE and 
appropriate local site personnel on the conditions for approving 
deployment of the system at the site. 



---------------------------------