...
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.
From minutes of 1st June 2016 meeting
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?
Operational Security
[OS1]
...
DaveK - from minutes of the 1/6 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.
...
Dave, I don't know how useful this is without agreeing on a few required threats and actions. Maybe you should be able to block IPs or networks, detect brute-force attacks, lockout accounts, and detect compromised accounts. I don't know what others count as significant.
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.
[OS5]
The capability to regulate the access of authenticated users.
There simply needs to be a way 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.
...
Dave, what do we mean by communities?.
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 - 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.
...
I don't really know what is here that isn't already covered by procedures and communication channels. If this is about communicating with external infrastructures, then maybe all it is about is having a security point of contact and participating in relevant trust groups –Adam.
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
[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.
...