Difference between revisions of "Federated Cloud Security"

From EGIWiki
Jump to: navigation, search
(No difference)

Revision as of 11:50, 18 May 2015

Overview For users For resource providers Infrastructure status Site-specific configuration Architecture

Scenarios: Federated AAI Accounting VM Image Management Brokering IntraCloud Networking
Monitoring VM Management Data Management Information Discovery Security


This workgroup deals with security issues and implications of running a federated cloud infrastructure, namely being able to prevent and handle security incidents.


Role Institution Name
Scenario Leader STFC Linda Cornwall
Collaborator EGI CSIRT / Nikhef Sven Gabriel
Collaborator CESNET Boris Parák
Collaborator EGI.eu/CSIC Enol Fernández
Collaborator GRNET Christos Loverdos


  • Run security challenges
  • Design and implement tools for IR in the context of:
    • User & Identity Management (UM/IM)
    • Virtual Machine Management (VMM)
    • Image Management (ImM)
    • Data Management (DM)


Security Challenges

Communication Channel Challenge

Target Sites: All CRPs, this will likely be part of the certification procedure.

Outline: Use RT-IR to open a ticket for the security contact as defined in goc-db for each CRP.

Description: The Challenge is to hit the reply button in your mail client within 4h.


Security Service Challenges

Target Sites: All CRPs, this likely will get part of the certification procedure in the future.


  • Start a VM
  • Fetch payload from an external IP
  • Extract/run payload, i.e. make connections to external hosts
  • Shutdown VM

Description: The CRPs will get an IP together with a timestamp. Based on that information the CRP should try to get the following information:

  • Minimal
    • DN of the owner
    • VM identifier (meta info)
  • Additional
    • Information on network connections made from/to this VM


VM Management in IR


  • VM image found or reported to contain a Critical Vulnerability.
  • Vulnerable VM image used by different users.
  • We get notified that this Vulnerability is being actively exploited.

Needed Information for "targeted" IR:

To be able to apply the proper IR in this situation EGI CSIRT needs to know a unique identifier of running VM instances along with:

  • Base VM image (endorsed)
  • Targeted IR required Y/N (N means it will likely be shutdown in )
  • Patch/service config status (Security Monitoring data from trusted sources)
  • Contact information (mail, phone, DN) of the operator/user of the running VM instance.

Note: This could be handled by passing necessary information to local (NGI) CSIRT/CERT teams while providing them with necessary guidance and tools from EGI Federated Cloud.

User Management in IR

Ideally we can make use of the Argus-based grid emergency suspension framework. Roughly this framework consists of a central Argus instance at CERN, NGI-Argus instances and site argus(-like) systems. The banning information automatically propagates from the central instance down to the sites. Resource Providers could either fetch the suspension information from their site or from their NGI. Solutions for Non-EGI providers can be implemented rather easily. The suspension information in general consists of a certifcate DN.

The tech expert for Argus questions is Mischa Salle: msalle@nikhef.nl

Note: Connectors for Perun <-> Argus communication are in development. Also direct CSIRT/CERT support (roles, workflow logic, etc.) will be added to Perun in the near future.