Академический Документы
Профессиональный Документы
Культура Документы
Document
CH-1211 Geneva 23
Switzerland
1062503
ABSTRACT A Security Baseline defines a set of basic security objectives which must
be met by any given service or system. The objectives are chosen to be pragmatic and
complete, and do not impose technical means. Therefore, details on how these security
objectives are fulfilled by a particular service/system must be documented in a separate
Security Implementation Document [1]. These details depend on the operational
environment a service/system is deployed into, and might, thus, creatively use and
apply any relevant security measure. Derogations from the baseline are possible and
expected, and must be explicitly marked.
At CERN, for each service/system used in production, such a Security Implementation
Document must be produced by its system/service owner, and be accepted and
approved by the Computer Security Officer. All systems/services must be implemented
and deployed in compliance with their corresponding Security Implementation
Document. Non-compliance will ultimately lead to reduced network connectivity for the
affected services and systems (i.e. closure of CERN firewall openings, access blocked to
other network domains, and/or disconnection from the CERN network).
This document describes the Security Baseline for File Hosting services laptops used in
a CERN production environment.
Prepared by:
Checked by:
Approved by:
IT Security Contacts
Department Security Contacts
Experiment Security Contacts
Distribution:
Unrestricted
Document
History of Changes
Rev. No.
Date
0.5
0.6
0.9
2010/02/02
2010/02/24
2010/05/20
1.0
1.1
2010/05/20
2010/09/06
Reference
Several
Several
FILE-AC-1/2
FILE-AC-7
Description of Changes
Draft
Comments from the Security Team
Comments from IT Security Contacts, Department
Security Contacts, and Experiment Security Contacts
Approved version
Added the category of restricted data.
Removed the timescale (in weeks).
Document
Requirement
Comment
FILEAC1
DefinetheconcretemeaningofPrivate,Restricted, and
Publicwithregardstothefilesystem(followingthe
definitionin[3]).
Privatedataisusually
confidentialtooneindividual,e.g.
privatecorrespondenceor
authenticationcredentials.
Publicdataisnotconfidential
andcanbesharedwithavery
largegroupofpeople,e.g.
DomainUsers.
Allotherdatamustberestricted
inaccess,e.g.information
confidentialtoa(small)groupof
individualslikemeetingminutes,
MARSassessments.
FILEAC2
Classifyallstandardfilesandfoldersintothedataclasses
Private,RestrictedandPublic(asdefinedin[3]).
Standardfilesandfoldersinthiscontextarethosecreated
bydefaultorcreatedduringthenormalusageofthatfile
service.
Restrictdefaultaccesstothecorrespondingdataownerforall ApplyingtheRuleofleast
filesandfoldersclassifiedasPrivate.
privilegereducesthelikelihood
ofdatadisclosure.
Definedefaultaccesstoallfilesandfoldersclassifiedas
Public.
Disablepublicwriteaccesstoany folder.
Dropboxeswithrestrictedread
accessarepermitted.
Definehowaccessrightsareinheritedbysubfolders.
EnforceregularlyFILEAC3andFILEAC5bycorrectingall
settingswhichdeviatefromthedefaultsettings.Themeaning
ofregularlymustbeexplicitlydefined.
Informthedataownerwhensettingshavebeencorrected.
Documentpubliclythedefaultsettingsforallstandardfiles
andfoldersasdefinedinFILEAC2,theinheritenceschemeas
wellastheenforcementpolicy.
FILEAC3
FILEAC4
FILEAC5
FILEAC6
FILEAC7
FILEAC8
FILEAC9
1.2 PROVISIONING
Ref.
Requirement
Comment
FILEPRV1
Documentalldependenciesofstoringfiles.
Forexample,thestorageofsome
webcontentsdependsonAFS,
AFSbackupsdependonCASTOR,
etc.
Document
Requirement
FILEADD1
ImplementtherequirementsdefinedinmostrecentSecurity
BaselineforServers[4].
Comment
2. REFERENCES
[1] The CERN Security Team, Security Implementation (Template), EDMS 1062504
[2] Network Working Group, RFC2119, http://www.ietf.org/rfc/rfc2119.txt
[3] The CERN Security Team, Data Protection Policy, in draft
[4] The CERN Security Team, Security Baseline for Services, EDMS 1062500