Talk:Policy Framework

From JSPGwiki

Aims of the Policy Framework

Specification of a Security Policy Framework to enable interoperation of collaborating Grids.

The framework specifies those policy components necessary to create trust between collaborating Grids. We started from the current set of JSPG policies. We are not re-writing these, just taking a high-level view to identify those components necessary for the framework. There are other components of current JSPG policies which are either too EGEE-specific or are operational policies rather than related to security and are therefore not part of this framework. Each Grid will have security policies consisting of the framework components and their own Grid-specific components.

It specifies the issues that need to be addressed in a Grid's security policy, but at this stage does not define minimum standards or requirements. These details may come later.

This is aimed at Grids preparing or revising security policies, not at end users, sites, application communities etc.

As an aside ... we found it very useful to have been through the whole JSPG "experience" to identify those issues which need to be addressed!

Next steps:

Create template of generic wording for these components. This will necessarily involve setting minimum standards and therefore reaching agreement will take time.

There is also a need for people with different roles (Site/resource managers, users, etc.) to easily idenitify policy components that apply to them.

Input from Romain Wartel 12Aug09

As discussed, I tried to add some wording to the "operational security" and "incident response" boxes on the diagram we produced.

This is basically the generic part of the policy that could be adopted by all "compatible" grids. I tried to think of it as a set of components that, once adopted by another grid, would make collaboration on operational security issues smooth and with a sufficient degree of trust with that grid.

I deliberately tried to go quite far in the assertions in the hope it would foster some discussions in what we are really trying to achieve. All assertions must be true in order for the "box" to be deemed validated. It might be completely wrong and unreasonable, but at least the text is short!

User Responsibility section update, Denise Heagerty 26Aug09

Do we need a bullet along the following lines for the User Responsibility section:

- a documented user management process to ensure that users can be contacted and/or user related action taken in response to security incidents. The process should cover at least the following: registration, removal, suspension and authorisation.