Difference between revisions of "Federated Cloud Security"
(2 intermediate revisions by the same user not shown) | |||
Line 3: | Line 3: | ||
{{FedCloud_TF_Menu}} {{TOC_right}} | {{FedCloud_TF_Menu}} {{TOC_right}} | ||
= Scope = | |||
= Scope = | |||
This workgroup deals with security issues and implications of running a federated cloud infrastructure, namely being able to prevent and handle security incidents. | |||
= Members= | = Members= | ||
{| | {| class="wikitable" | ||
|- | |- | ||
! Role | ! Role | ||
Line 16: | Line 18: | ||
! Name | ! Name | ||
|- | |- | ||
| Scenario | | Scenario Leader | ||
| | | STFC | ||
| | | Linda Cornwall | ||
|- | |||
| Collaborator | |||
| EGI CSIRT / Nikhef | |||
| Sven Gabriel | |||
|- | |- | ||
| Collaborator | | Collaborator | ||
| | | CESNET | ||
| | | Boris Parák | ||
|- | |- | ||
| Collaborator | | Collaborator | ||
| | | EGI.eu/CSIC | ||
| | | Enol Fernández | ||
|- | |- | ||
| Collaborator | | Collaborator | ||
| | | GRNET | ||
| | | Christos Loverdos | ||
|} | |} | ||
=Roadmap= | = Roadmap = | ||
=Documentation= | |||
=References = | * 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) | |||
= Documentation = | |||
== 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. | |||
'''Status:''' <span style="color: green;">COMPLETED</span> | |||
=== Security Service Challenges === | |||
'''Target Sites:''' All CRPs, this likely will get part of the certification procedure in the future. | |||
'''Outline:''' | |||
* 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 | |||
'''Status:''' <span style="color: yellow;background-color: black;">ONGOING</span> | |||
== VM Management in IR == | |||
'''Situation:''' | |||
* 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. | |||
= References = | |||
<references /> | |||
[[Category:Federated_Cloud]] | [[Category:Federated_Cloud]] |
Latest revision as of 12: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 |
Scope
This workgroup deals with security issues and implications of running a federated cloud infrastructure, namely being able to prevent and handle security incidents.
Members
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 |
Roadmap
- 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)
Documentation
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.
Status: COMPLETED
Security Service Challenges
Target Sites: All CRPs, this likely will get part of the certification procedure in the future.
Outline:
- 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
Status: ONGOING
VM Management in IR
Situation:
- 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.