...
I propose a mean of no combined score (Adam Slagell).
DaveK - I agree.
Hannah (meeting 8 July 16) - but what if is something essential marked zero? We could have mandatory and optional sub-requirements.
Adam - Since there is is not an audit, I don't believe it makes sense to talk about mandatory vs. optional. The whole guide is informational as I have viewed it. IF certain subcomponents are important to you as a consumer of the information, you would look at those individual scores.
Standardize Language
The spreadsheet and SCIv1 document have ambiguities. For example, one refers to service providers and another to service operators.
...
Minutes of meeting on 13 May 2016 - Alf also notes that the Refeds Sirtfi activity has changed some of the wording in Incident Response. We should consider merging their changes back into SCI V2.
Meeting on 8 July 16 - Hannah - still try to avoid forking wherever possible, even if we do the full merging later. Was also noted that the scopes of SCIV2 and Sirtfi are different.
Base-level Examples
There are always questions of scope and completeness in filling out this evaluation form. While no implementation or documentation is ever exhaustive or covers every corner case, if there are significant holes then noting the scope that is covered is useful. For example, there may be centrally managed services for an infrastructure, while there are shared infrastructure at the resource providers that follow different policies. Or there may be different policies for different tiers of infrastructure worth noting.
...
Adam suggests that we could see the section OS to be more of a "baseline standard". He will send a copy of the XSEDE Baseline Security document.
Eric points out that we need to include post-mortem analysis as a way of learning lessons. Do we expand IR2 or create a new bullet?
Adam- I think a new bullet makes more sense than stuffing it in IR2 IMO.
Operational Security
[OS1]
...
Authorization models might include something like VOMS or a central database to manage allocations and a corresponding process to decide which projects or communities get allocations. Another important process is how PIs authorize who can be on their projects.
Access control example Dave?
DaveK - from minutes of the 1st June 2016 meeting - "Access control" for files relates to role-based authZ to read/write/delete/control files. For XSEDE, Adam comments that their most important example of central access control is to for accounting.
Confidentiality example Dave?
DaveK - No access unless authorised. Hide the existence of jobs and their details
Integrity example Dave?
models may be as simple default file permissions for protecting user home directories and shared project spaces on filesystems.
Confidentiality models might describe how job and user details are hidden from the public or other users.
Integrity models may be as simple as providing tools for integrity at rest or in transit (e.g., encrypted GridFTP) that users can use to ensure data integrity. It does not require controls to be mandatory.DaveK - Researchers like to be sure that their data has not been tampered with. It is interesting to know what has been done to ensure integrity during data transfer and then also during storage
Examples of compliance mechanisms are top-level security policies, resource provider agreements, and terms of service that allow the organization to enforce policies for entities bypassing the model. For example, a resource provider setting up a gateway which bypasses authentication and authorization by sharing an account might be cut off from resources for breaking the model.
Dave, does this just duplicate OS7?
DaveK - I guess it could do but I think the idea was that OS1 talks more about the management commitment to ensure compliance and the policies requiring this, whereas OS7 is more about the escalation and enforcement procedures. The words don't make this clear so we need to modify These are the foundational organization commitments to compliance, not the technical mechanisms of enforcement itself.
[OS2]
A process that ensures that security patches in operating system and application software are applied in a timely manner, and that patch application is recorded and communicated to the appropriate contacts.
...
DaveK - Me neither! I guess that we meant that because of changing threats it may be necessary to modify the process and this should be possible
Meeting 8 July 16 - what about using the words "flexible and adaptive".
Adam - Can you give an example of being flexible to a changing threat environment or a process that is not?
[OS4]
The capability to detect possible intrusions and protect the infrastructure against significant and immediate threats on the infrastructure.
...
DaveK - Minutes of 1st June 2016 meeting.
What about IDS? Do we mean host-based or network-based? Best practice would be to implement at least something in this area.
Eli: Can also be done after the event by analysing log files.
Questions like "can you detect brute-force SSH attacks? Do you have centralised logging? Can you correlate these logs?
We can put details in the guidance document. It doesn't all have to be done - the main document needs to stay light-weight.
Meeting 8 July 16 - Alf - Good to describe best practices and things that have been found to work. DaveK - main thrust is to gather evidence that an infrastructure has addressed the issue.
Adam - I find this far too broad to be useful. You could monitor syslogs, but have no host-based IDS on endpoints. You could monitor networks, but not host-data. You could monitor border traffic, but not internal. You could monitor central services run by the infrastructures, but the service operators at independent organizations vary. You might be able to detect brute-force SSH attempts, but not other scans. I imagine what is considered IDS by CERN vs. EGI is very different, too. I would consider scoping this to particular threats or changing it to something about maintaining the log reords necessary to investigate an intrusion.
[OS5]
The capability to regulate the access of authenticated users.
There simply needs to be a way technical mechanism to suspend access and terminate existing sessions and jobs in an emergency.
Dave, how does this differ from OS7?
DaveK - This is more about technical controls, OS7 relates to managerial controls
[OS6]
The capability to identify and contact authenticated users, service providers and resource providers.
...
DaveK - A community is a grouping of end-users. Could be a Research Infrastructure, a Virtual Organisation or an application community, often this is the entity to which resources are allocated and access is granted. There is probably a definition in the SCI V1 document glossary - need to check
Expected incident response times for an infrastructure must be documented and shared, and do not necessarily need formal SLAs, MOUs, charters, etc.
Meeting 8 Jul 16 - Warren - LIGO has a hierarchy of contact points
I guess I am still confused. Let's take XSEDE as an example, anyone can create an account, and if a PI adds them to an allocation they are in our user community. If they are at a US university, I suppose we have security contacts through REN-ISAC and expected response times. If they aren't then I think we can only be guaranteed a method to contact the user. I would expect OSG and EGI to be similar w.r.t. end users.
[IR2]
A formal Incident Response procedure. This must address: roles and responsibilities, identification and assessment of an incident, minimizing damage, response & recovery strategies, communication tools and procedures.
...
DaveK - I think IR2 was aimed at having the procedure to handle incidents inside your infrastructure. IR3 is more about the management backing and the policy and procedures to do the "collaboration" with others
Adam- Well, I think in v2 we might want to state that this is about collaborating with external infrastructures rather than within an organizational boundary like EGI or XSEDE.
[IR4]
Assurance of compliance with information sharing restrictions on incident data obtained during collaborative investigations. If no information sharing guidelines are specified, incident data will only be shared with site-specific security teams on a need to know basis, and will not be redistributed further without prior approval.
...
Some explanations from Dave Kelsey (my personal views - recalling the history)
Section 4 - Operational Security
OS1 - What is meant by a "security model"?
Here we were considering an architecture or an agreed set of technical and managerial/policy components. In EGI for example this means - authentication is today based on an X.509 PKI with an approved set of CAs (as accredited by IGTF). Authorisation is in the hands of the VOs using VOMS attribute certificates together with a set of technical components at the service level for policy enforcement (LCAS, LCMAPS, ARGUS, etc.). We have security policies on the approved CAs, on the VO membership management procedures (registration, renewal, suspension, etc). And a top-level security policy which specifies what happens in non-compliance.
This works for eInfrastructures (or did work) because we had a single security architecture and we needed all participants and services to use it.
With the current move to different technologies, more generalised federated identity management and different levels of assurance, not forgetting new types of service like the EGI Federated Cloud service, this is no longer true.
OS1.3 - What is meant by "access control"?
"Access control" is the technical means to enforce authorisation policy and decisions. In EGI, VOMS specifies VO and sub-group membership and possession of other generalised attributes. The Access Control system then decides whether a job can be run, whether a file can be written or read based on the authorisation attributes.
to be continued