This document providesa briefoverviewofcomputingsecurity for theATLAScollaborationin the UnitedStates (U.S.ATLAS). It refers to comprehensive security plans and other documentation created by organizations offering computing and middleware servicestothecollaboration, and it provides a descriptionofthecontextinwhichthoseplansareapplied.
Introduction and Context
TheATLAS collaboration maintainsa distributedcomputingfacilityconsistingoftheTier-1at BrookhavenNationalLaboratory(BNL),fiveTier-2sites(whichinallbutonecasesconsistofmultiple institutions), and numerousTier-3 sites.This document provides an overview ofthe computing security planforthedistributedfacilities.
Typically an organization's computingsecurityplancontainsexplicitassessments, policies, procedures, andcontrols,allcreatedforandbythat single organization. In thecase of USATLAS, the computing activities take place within a framework of multiple, overlapping security regimes, deriving from severalorganizationstheU.S.ATLASFacilitiesare part of. Instead ofexplicitly listing security policies,theroleofthefacilitiesintherelevantorganizationsisexplained, and reference to their respectivesecurityplandocumentationismade.
Theorganizationsrelevantto USATLAS security are:
Each U.S.ATLAS site complies with any relevantlocalsitesecurity requirementsimposedby theorganizationhostingthesite.
Each U.S.ATLAS site isa participant in Open Science Grid (OSG) and complies with OSG’s security plan.
AsasubsetoftheATLASvirtualorganization(VO), all U.S.ATLAS sites are participants in theWorldwide LHC Computing Grid (WLCG), and they comply withWLCG's security guidelines.
AsasubsetoftheglobalATLASVO,U.S.ATLAS has contacts and interactions with the EuropeanGridInfrastructure(EGI)whichhasits own grid-level security plan that U.S.ATLAS mustremainconsistentwith
ATLAS has security policies purely at theVOleveldrivenbycollaboration-internal requirements, and the U.S.ATLAS Facilities follow them.
None of the sites making up the U.S.ATLAS Facilitiesareontheirown.Theyallreside at institutions (universitiesornationallaboratories)whichimposetheirowncomputer security standards, policies, and procedures. In some cases these standardsarerelativelyinformal,whileothersimpose restrictions/requirementsthatexceedwhatOSG/WLCG or theVO would otherwise follow.
Forexample,inthecaseofBrookhavenNationalLaboratoryandStanfordLinearAccelerator (Tier-1 andTier-2respectively),thosesitesmustfollowDepartment of Energy security policies, and have formal facility security plans thatdocumenttheircompliance.Theserestrictionsmayincludelarge
arrays of system management requirements, specialcontrols,networkregistration,andfirewalls.
Othersites,especiallyinstitutional analysis facilities (Tier-3s) at universities, may have no local requirementsbeyondsigningacampusend-useracceptable use agreement. Systems at these kinds of institutionsareessentiallydirectlyinternet-connected with no institution-driven system restrictions, nor any protection fromoutside attacks.
Ifa U.S.ATLAS facilitysite falls under a local institutionalsiteplan,thenthatconstitutesaminimum standard.Wherever a site standard differs fromanATLAS,WLCG, or OSG standard, the site will comply with the most restrictive.Asurvey ofthe full rangeofsiteplansin forceatU.S.ATLASsitesis well beyondthe scope ofthis document.Access tothe details ofsuch plans are typicallylimited or eventightlyrestricted.Ifadditionaldetailsofsiteplansarerequired,itmaybepossibletoget permission to share them with a limited audience.
Open Science Grid Security
ATLAS'primary distributed computing securityframework is that of the Open Science Grid (OSG).All U.S.ATLAS facilitiesare installed and maintained as OSGgrid sites, using OSG-packaged software.
OSG has a fully developed and documented security plan,comparabletothatof other large institutions and companies. Securityis a top-level administrativeareainOSG,ledbytheOSGsecurityofficer.
Fully documented and definedVO user registration policy and procedures:These govern what steps theVO is obligated to do to verify users'identitiesandmanagetheusermembership lifecycle.
Explicitlydefinedriskassessmentprocedures:OSGsecuritypolicies aredeveloped froma well-definedmethodology for assessing risk, recommendingcontrols,andmitigatingresidual risks.
Explicitly defined and documented organizationalrolesandresponsibilities within OSG and between OSG and others (sites,VOs, users, software developers).
Explicitly documented trust relationships and hierarchies.
TheEuropeanGridInfrastructure(EGI)istheEuropean counterpart to OSG.U.S.ATLAS does not use EGI middleware at its sites, but thefacilitiesdorelydirectlyonglobal/central services provided by sites using the EGI middleware stack. U.S.ATLAS andOSGalsorelyonsoftwaredevelopedunderthe auspices of the European grid organizations. Furthermore, sinceATLAS'workload management systems are global, vulnerabilities or compromises that occur at EGI sites may involve credentials also usedintheU.S.
Like OSG, EGI (formerly EGEE) has a well-developed and formal computing security plan, addressing asimilarrangeoftopicsandconcerns.
EGI securitydocumentation is available at: https://documents.egi.eu/public/ListBy?topicid=33https://wiki.egi.eu/wiki/SPG:Documents
Incident response is coordinatedthroughtheEGICyberSecurityIncident ResponseTeam(CSIRT).
Of particular interest toATLAS, therefore also applicabletoU.S.ATLAS, are policies regarding multi- job pilot frameworks, since PanDA,ATLAS'globalworkload management system, uses an overlay mechanism.
WLCG has adopted the EGI multi-job pilotpolicywhichisdocumentedat:
The worldwide LHC Computing Grid (WLCG) is a cross-cutting organization created to coordinate the global distributed computing activities of thefour LHC experiments (ALICE,ATLAS, CMS and LHCb).
WLCG itself also has security policies, with whichtheLHCVOsitesandusersareexpectedtocomply withregardlessofwhichGridflavortheyare working on.Their respective cyber security related directives refer to EGI and OSG policies and procedures, or set very reasonable best-practice standards similar to those set by other grids. For example, incidentsarereportedthroughthelocalsite,withinter- grid security response handled betweentheEGICSIRTandtheOSGsecurityteamastheincident report moves up the hierarchy.
Acomprehensivelistofrelateddocuments is available at:
ATLAS itself has a security team. For the most part,ATLASVOsecurityfallsundertheCERN-based ITinfrastructure or under theWLCG security groupsandeffortsreferredtoabove.TheVO-specific aspectsfocusonthingslikepromotingbestcodingpracticesamongATLASdevelopers,andensuring that theATLAS workload management systemcomplies with the grid-level security plans.
At this point most critical distributed authentication mechanisms used by U.S.ATLAS are based on the
The usefulness of this infrastructureisbasedonthetrustgivento theCertificateAuthorities(CAs) whichissueenduserandhostcredentialsusedformutual authentication.TheInternational GridTrust Forumis the body which accredits the various CertificateAuthorities andvouchfortheirinternal policiesandprocedures.OSGandEGItrusttheIGTFtovouchfortheCAs, and the IGTF must trust the CAs to comply with their agreements.
Tothe extent thatATLAS relies on this infrastructure, all oftheir policiesand procedures are part of ATLAS'security documentation.
Very little ofthe software used to implement theU.S.ATLAS facilities and the applications is written by the organizations defining the security plansdiscussed here. EGI and OSG (andATLAS)package and distribute software written by a very large numberof external developers.This software includes gridmiddleware,batchsystems,aswellastheopensourceoperatingsystemsthatunderpinthegrids. Froma security standpoint, both theGridorganizations,andtheATLASVO must trust that those developers are providing softwarewritteninaccordancewithvalidcyber security policies, guidelines and best practices.
Incident reporting provides a concrete case that illustrates the security relationships of U.S.ATLAS. All U.S.ATLAS resources and services are hosted atsome site.Thatsiteisobligatedtoreportany
instance of a compromise to the OSG security team.Typicallysitesarealsoobligatedtoinformtheir
institutionalcybersecuritygroup(thisismandatoryatDOEnationallaboratoriesandmany universities). In the case ofthe national laboratories,thisresultsinincident reports being passed on to the Department of Energy's cyber security organization.
TheOSGSecurityteamfollowstheincidentresponseprocedures as documented. Part of this procedure istoassesswhethertheproblemhasaglobalimpact.Ifthenatureoftheincidentsuggeststhatitmay have effects or causes beyond OSG, the OSG securityteaminformsrepresentativesofothermajorGrid organizations (EGI, XSEDE and NorduGrid).
The OSG security teamreports significant incidents to the OSG executive team(ET) and theVO
representative (if theATLASVO is affected the U.S.ATLASFacilityManagerisinformed).U.S.
ATLAS Management is immediately informed about theincident and reports tothe funding agencies as appropriate.