Coordination of Trust and Security Project Clustering

Abstract

The DG Connect Unit H4 Coordination and Support Actions and Networks of Excellence took part in two conference sessions during the Cyber Security and Privacy EU Forum (CSP 2013) to collectively address their roles, and, in particular, how they might work together within a Project Cluster framework to the advantage of the research and innovation projects and to the programme as a whole, and particularly in the context of significant recent EU initiatives concerning Cyber Security Policy and a Network Information Security Platform. The morning session examined goals and timescales of the projects; the afternoon session looked in further detail at options and possibilities for the structure and modus operandi for a project cluster, ways forward towards a NIS Platform, and extending participation, influence, and effect to projects outside the immediate ICT trust and security community.

Appendix – Workshop Recommendations

(MEM) – membership; (NWI) – new work items, content, initiatives;

(ORG) – organisational; administrative; (OPS) – cluster operations

• R1. Membership of the Trust and Security Project Clusters should be open to all Framework Programme projects; those outside Trust & Security itself that have inherent or implied Trust & Security issues would be most welcome (e.g., health, transport, legal, economic, infrastructure, …). (MEM)

• R2. Membership of clusters should be free; a project will coordinate the cluster activities and, if necessary, Descriptions of Work (DOWs) should be examined and changed if necessary to align a project’s tasks with the responsibilities taken up in the cluster.

  Note: The SecCord (CA) project already has such cluster coordination responsibilities in its objectives; it could act as a “contact point” for the cluster community. (MEM)

• R3. The cluster of CSAs/NoEs should make a start on areas that are more concerned with community building (e.g. conferences, workshops, research roadmaps …).

  Note: Assistance from the Commission will be needed to provide contact points and short descriptions of all projects, especially those in new Calls. (NWI)

• R4. The Unit H4 Trust and Security should be take part in the cluster activities, and should strongly encourage its projects to play an active role in the clusters. (NWI)

• R5. In order to provide continuity through H2020 (and even beyond), clusters should have a span beyond a set of projects arising from a single call; responsibilities in the clusters and allocations of activities may change over this lifespan, partners in newly-funded projects taking over tasks from completing projects. (ORG)

• R6. The Commission should also consider the need for specific cluster-supporting project(s) when drafting future calls. (ORG)

• R7. Cluster priorities should be the responsibility of the cluster-members themselves, but taking full account of the requirements of such as the Cyber Security Strategy, the NIS platform, the societal pillar in H2020, etc. (NWI)

• R8. There should be provision for rotation of certain periodic responsibilities to lessen the burden on some projects e.g., hosting meetings, organizing sessions, specific work activities required. (ORG)

• R9. The appropriate stakeholders (people/projects/initiatives) should be brought together to begin scoping cluster activities, to get active membership, and to gain agreement on who does what and when. There should be draft plan for 2013 cluster activities, with allocated responsibilities, available for the next cluster meeting. (NWI)

• R10. Earlier and current cluster models should be reviewed, e.g. Effectsplus, SecurIST, PRIMCLUSTER, GEANT, IN-HOME, etc., to see how they have been organized, their benefits and/or problems encountered. (ORG)

• R11. Clustering should be supported by all Trustworthy ICT projects. A number of coordination and support activities in the security domain already have some associated cluster activity that they should look with a view to taking on further clustering responsibilities. (ORG)

• R12. The clusters should build activity streams around EU strength areas: e.g. cryptography, smart card, embedded systems, biometry, privacy, and others. (OPS)

• R13. The cluster should examine benefits and possibilities for collaboration on utilising summer schools of the projects. (OPS)

• R14. Similarly, the cluster should look at possibilities for theme-based conferences/workshops: a continuous effort in order to share data, capitalizing in the “scale effect” of a big cluster for small companies could be provided. (NWI)

• R15. The cluster should encourage white papers, to be made available in a central featured repository (as in BIC), in which authors are invited to submit articles via the projects, keeping in mind that the basic data sometimes comes in a fairly rough format and the responsible project compiles into a nice glossy format for publication. (OPS)

• R16. The clusters should be used as a vehicle to promote the trust and security message and promote it as a central consideration for all projects. The audience is our community, including the European Commission, research, industry, policy, decision makers (and eventually NIS platform). (OPS)

• R17. There would ideally be an annual book from the clusters. (possibly along the lines of this CSP Forum volume; another example was the yearly FIA book). The annual trust and security book should take care to support the identity of the trust and security clusters (of course, it also links in the Future Internet, telecommunication, mobile, smart grid, and many other topics, but the competence of the trust and security community should be the dominant contributor. (OPS)

• R18. Each project that is a member of the Trust and Security cluster should put an executive summary on-line on the cluster web platform. The choice for the web platform has not yet been made but the CSP forum would be a candidate. There should be formal agreement from all projects to communicate their public deliverables to the cluster website; the cluster website should be a collaboration platform that offers broad functionality to the cluster members (e.g. to upload deliverables themselves, to update entries in the cluster agenda, to release news items, …). (OPS)

• R19. Research agendas/roadmaps should be catalogued. (OPS)

• R20. There should be a directory or atlas of roadmaps, taking into account the diversity of the various topics. They could use the rendezvous concept, where the roadmaps have been analysed and points of contact determined so that matters may be coordinated along technology (or other) lines. (OPS)