...

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

Meeting 8 Jul 16 - Hannah - also overlaps with OS4

[OS6]   

The capability to identify and contact authenticated users, service providers and resource providers.

...

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