General Clarifications

How do we combine subcategories into a score?

For example, OS1 has several subcomponents, many of which you may have or not to different levels. I propose a mean of no combined score (Adam Slagell).

Standardize Language

The spreadsheet and SCIv1 document have ambiguities. For example, one refers to service providers and another to service operators.

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 filling in the scope that is covered in the form is useful. For example, there may be centrally managed services for an infrastructure, while there are shared infrastructure at the service providers that follow different policies. Or there may be different policies for different tiers of infrastructure worth noting.

Operational Security

[OS1]

A security model addressing issues such as authentication, authorisation, access control, confidentiality, integrity and availability, together with compliance mechanisms ensuring its implementation.

Examples of an authentication model might be a Kerberos system or PKI use to identify users. Other things that may be included in an authentication model is how one federates with other identity providers.

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 and how they can authorize their users.

Access control example Dave?

Confidentiality example Dave?

Integrity example Dave?

Examples of compliance mechanisms are top-level security policies, service provider agreements, and terms of service that allow the organization to enforce policies for entities bypassing the model. For example, a service provider setting up a gateway which bypasses authentication and authorization by sharing an account might be cut off from resources for breaking the model.

[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.

A simple patch management process might be regular vulnerability scans, with a process to assign tickets to owners, and regular reviews of tickets to ensure that they are resolved within timelines following security policies. Sometimes this may be the responsibility of the the distributed infrastructure, but other times it may be part of the the service operators. Patch management policies may differ for different classes of resources.

Recording and communication could be as simple as assigning tickets to appropriate service operators.

[OS3]

A process to manage vulnerabilities (including reporting and disclosure) in any software distributed within the infrastructure. This process must be sufficiently dynamic to respond to changing threat environments.

This item differs from the patch management process in that it is about software owned or distributed by the infrastructure to the service providers. In OS2 we might be talking about an XSS flaw in the user portal or website for the infrastructure, whereas her we might be talking about accounting or job submission software pushed out to all the service operators.

This process could be as simple as a regular meeting to discuss new vulnerabilities, e.g., the latest OpenSSL flaws, to determine the impact on software distributed by the infrastructure along with an email list to distribute such information to each service operator.

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