Current documents

The document listing is as follow:

• Online Computers variance
  Purpose: The purpose of this variance document is described in the background section of this document. To achieve a complete security package, at least one variance has to be provided. This process is indivisible of a an enclave document. An enclave may however relate to several variance document.
  Submitted: 2007/02/15
  Re-submitted: 2007/03/30
  Contributors: Jerome Lauret
  Feedback: Re-submission added feedback from CS team. Main additions to initial document: need for better explaination of keyboard lock, explain local account, explain physical access security, explain mode of updates
  Status: Pending
• Physical Access Problem statement & Proposal
  Date: 2007/01/12
  Contributors: Jerome Lauret (lead), Wayne Betts after a visit to the DAQ, CR, WAH, Gas rooms and review of access control.
• Variance-Form-v0.4-STAR-GeneralDesktop
  Submitted: 2006/11/07
  Contributors: Jerome Lauret
  Feedback: None
  Status: Rejected 2006/12/19 by Samuel Aronson, Laboratory Director. "Explaination" below.

  The requested exemption from Remote Registry services defeats the ability to manage 
  STAR Windows systems remotely. Exemptions require there to be an operational need. 
  I see only a statement that more access = higher risk. While I agree that's so, in 
  the interest of managing the cyber security of the whole laboratory, I will consider 
  variances only for systems that will not operate properly if subjected to remote 
  configuration management.  Given that, I am not approving the request.
  
  Sam
  

  Follow-ups: We offered to kindly demonstrate the Remote Registry service vulnerability to Peter Bond (2006/11/30), Tom Schlagel (2006/12/01), Andrew Ferguson (2007/01/02) and J.D. Fluckiger (2007/01/09) and have been consistently turned down as attempting a demo. Sam Aronson informed of the risk on 2006/12/19.
• Proposed Windows Policy based (commented) modifications.
  1. STAR Operational Need Policy XP
     STAR-OperationalNeed-Policy_XP-20070111.pdf
     Date: 2007/01/11
     Contributors: Jerome Lauret, Wayne Betts, Valeri Fine, Jeff Landgraf
     STAR-OperationalNeed-Policy_XP
     Date: 2006/10/24
     Contributors: Jerome Lauret (lead), Wayne Betts, Valeri Fine
  2. STAR-General-WorkstationsPolicy_XP
     Date: 2006/10/24
     Contributors: Jerome Lauret & Wayne Betts (leads), Valeri Fine
  Color code includes
  • red/orange: we have a concern with this item and will ask for alteration if allowed and consistent with BNL CS plan. We consider the BNL setting a reduction of our security posture (not an enhancement)
  • yellow: general discussed item, refer to comment
  • green: we recommend this item as additional setting in the policy
• SDAS-v0.8
  This document was created from tghe 2006/07/19 document (Contributors: Jerome Lauret (lead), Wayne Betts, Jeffery Landgraf, Michael DePhillips, Jon Engelage and Mike Cherney) submitted to DOE CyberSecurity. The document went through one more reshape (comments and additional questions) and accepted on 2006/10/13 . STAR management board inform of documen acceptance on 2006/10/17, author on 2006/10/27 (during You do not have access to view this node)
  

  Note that physical access is described in the SDAS document and core part of "the plan". We suggested (at STAR's managerment meetings) that a PASS card control system, card sweeper locks or combination locks should be installed to ensure further physical access requirement and pro-actively prepare for the question of "how do we control access". This was requested on 2006/12/19, 2006/12/11, 2006/11/28, 2006/10/24, 2006/10/17, 2006/10/02, 2006/09/05, 2006/08/29. Further reminders were made on 2007/03/13, 2007/02/27, 2007/01/23, 2007/01/09. The scope of physical access is VERY broad (could come for ANY of the components we have, from network to nodes to hardware). It was mentionned consistently time that it is my VERY strong beleif that we WILLL be challenged on our model for physical access control (especially during shift). Only a question of time. I suggested a strict revision of shift-crew responsibilities (and challenge anyone who is not known). An online Physical Accessdocument and statement was sent 2007/02/27, 2007/01/13, 2007/01/10 (statement only) upon inaction on this items, spaning from as early as August 2006 to March 2007.

 

Document creator's note ...

 

 

... but at what price?

 

Background

Please consult 2006 documents for past document and information left for historical purposes. However, the documents herein ar ethe most up-to-date and should be referred to as startup.

As before, the bottom of this page displays several Cyber-Security documents we provided to DOE and the BNL/ITD describing our sub-systems in the research enclave. An enclave is defined by its level of security, controls and accessibility. A sub-system is defined as a sub-division of an enclave and may be a "sub-enclave". Each eclave requires documentation and a clear description of how the components interact with each other, including the human component (physical access).

The role of an variance document is to describe how and why a set of computer within an enclave need to diverge (as per its baseline settup) from the BNL base policies. Some wording in a variance document may be a repeat of the information related to the enclave itself. The wording MUST remain consistent however. As an example, an exemption of the screen saver requirement may be described in the enclave document but would benefit from being described in each variance document.

An enclave document is a live document and should be revised as necessary in conjunction of one or more variance document. Changes may be justified by:

• the need to reshape our security model based on a change of architecture, software layout, component interaction
• a change in the BNL baseline policies requiring additional items in our variance document
• a reshape of the network
• ...

... and so on. Revision could be made due to internal or external to STAR (DOE/CS level) modification of the Cyber Security plan.

 

 

Othe readings

Before you read the documents below, you may consult the following pages and references for a bakcground philosphy of what we are trying to achieve.

1. Extracted topics
2. The Run VII preparation page (and notes from referenced meetings wherever available and especially meetings #3, #5, #7, #8)
3. You do not have access to view this node slide 14 to 17
4. You do not have access to view this node slides 24 to 27
5. Online and Offline Computing (STAR Critique) slides 10 to 13

In short, we are trying to understand DOE requriments (sometimes changing) and map those requirement to tangible realities (technical solutions) we can (a) describe i.e. document and (b) implement (deploy).