EGI CSIRT team monthly meeting

Thursday 18 Nov 2010, 14:30 → 15:30 Europe/Amsterdam

EVO - EGI CSIRT meeting

Mingchao Ma (STFC - RAL)

A monthly team meeting to discuss team activities and issues It will be on EVO (http://evo.caltech.edu/evoGate/). Meeting can be found in Universe community, please search EVO meeting with keyword "EGI CSIRT" Access information can be found at: https://wiki.egi.eu/csirt/index.php/EGI_CSIRT_monthly_meeting EVO Phone Bridge Telephone Numbers: --------------- - USA (Caltech, Pasadena, CA) +1 626 395 2112 - Switzerland (CERN, Geneva) +41 22 76 71400 - Slovakia (UPJS, Kosice) +421 55 234 2420 - Italy (INFN, several cities) http://server10.infn.it/video/index.php?page=telephone_numbers Enter '4000' to access the EVO bridge - Germany (DESY, Hamburg) +49 40 8998 1340 - USA (BNL, Upton, NY) +1 631 344 6100 - United Kingdom (University of Manchester) +44 161 306 6802 - Australia (ARCS) +61 Adelaide 08 8463 1011 Brisbane 07 3139 0705 Canberra 02 6112 8742 Hobart 03 623 70281 Melbourne 03 8685 8362 Perth 08 6461 6718 Sydney 02 8212 4591 - Netherlands (Nikhef, Amsterdam) +31 20 7165293 Dial '2' at the prompt - Canada (TRIUMF, Vancouver) +1 604 222 7700 - Czech Republic (CESNET, Prague) +420 95 007 2386 - USA (MIT, Cambridge, MA) +1 617 715 4691 - France (RAP, Paris) +33 144 27 81 50

14:30 → 14:35 Minutes taker and Project update

Minutes taker - DC of the week or the backup Please add upload minutes to: https://wiki.egi.eu/csirt/index.php/EGI_CSIRT_monthly_meeting#Monthly_Meeting_Minutes

14:35 → 14:40 CSIRT and SVG Vulnerability assessment

Copy of Linda's most recent email: Definitions: ------------- SLA software - Software distributed by EGI UMD (gLite, Unicore etc from EMI), IGE, or any software for which there is (or planned to be) SLA between provider and EGI. Operating system software - Software that is part of the operating system (e.g. SL) or distributed with the operating system. (e.g. openssl) EGI Non SLA software - e.g. VO software etc. Other Software - Software deployed in EGI which comes from elsewhere. (Unlikely to be much from discussions with software providers) Situations: ----------- Incidents: ** Clearly CSIRT ** although SVG may get involved if they are due to exploiting software vulnerabilities. Vulnerable systems due to: Operational mis-configuration of sites (i.e. NOT due to e.g. scripts in gLite configuration which are software vulnerabilities) ** Clearly CSIRT ** Sites not updating their software to incorporate available patches ** Clearly CSIRT ** Vulnerabilities in operating systems - where patch is made available prior to announcing publicly: CSIRT may enter in report-vulnerability and asks for risk assessment if they wish. Always/if needed/not SVG task/only if potentially critical? CSIRT ensures sites up to date. ** CSIRT/SVG - needs discussion ** Vulnerabilities in operating systems - BEFORE patch available (whether found by EGI members, reported to report-vulnerability, or announced publicly). Entered in report-vulnerability. CSIRT added to request Risk Assessed using SVG criteria. (public raises risk usually) Target Date set as for other SVG issues. CSIRT members (or RAT members who are also in CSIRT) chase operating system providers for fix. ** CSIRT/SVG -needs discussion ** Vulnerabilities in SLA software: Clear that SVG issue handling process followed. If made public, CSIRT also added to request (hopefully rare) ** Clearly SVG ** EGI Non SLA software - same as SLA software. Other software - same as operating system software. In all cases - if critical, critical issue handling process is invoked. (I hope to work on it again today.) ** SVG/CSIRT collaboration for SLA Software, probably for all software ** Once a risk category is set, and the patch is available, and advisory distributed, then a vulnerability is no longer an SVG task - it becomes CSIRT to ensure sites patch. ====== Option 1: all vulnerabilities including OS vulnerabilities are assessed and tracked by EGI SVG; But for OS vulnerabilities CSIRT free to do anything they choose operationally, and override RAT's opinion on Risk if they choose. If critical - move to critical vulnerability handling process. Options 2: OS vulnerability, initial assessment is doen by EGI CSIRT: if it is time critical then it will be handled as a ad-hoc manner by EGI CSIRT, non-time critical will report to SVG and follow the SVG risk assessment procedure

14:40 → 14:45 Information disclosure policy/guidline

Copy of Linda's email for reference

CSIRT Vulnerability Disclosure Policy

The principal of the disclosure policy is to maximize the security of the EGI infrastructure, and not to release information that compromises the security of other systems.

Note that CSIRT has a 'traffic light' system for information distribution https://wiki.egi.eu/wiki/EGI_CSIRT:TLP

The EGI Software vulnerability issue handling process is available from
https://documents.egi.eu/public/ShowDocument?docid=47 and has been approved by the EGI PMB and OMB.

CSIRT Members

For information learnt as a result of membership of the CSIRT team, CSIRT members MUST adhere to this policy.

For information on vulnerabilities in software found in the EGI UMD and the IGE, or any other software covered by a Service Level Agreement between software providers and EGI, CSIRT members MUST adhere to this policy.

For other information CSIRT strongly requests that members of the CSIRT team adhere to this policy, unless there is a good reason not to.

If members find a vulnerability

If members of the CSIRT team find a vulnerability, it should be reported to the appropriate software provider via an established mechanism for that software.

For vulnerabilities in the EGI UMD and the IGE or other software subject to an SLA between EGI and the software provider, vulnerabilities must be reported by e-mail to report-vulnerability@egi.eu.
Other vulnerabilities may be reported by this mechanism.

Non-disclosure

The CSIRT team will not publically disclose information on vulnerabilities that is not already public, when no available software updates are available to resolve the vulnerability.

This includes:

The existence of vulnerabilities, with the exception below in the absence of response from software providers.

Any exploit that a CSIRT member has written or become aware of. This includes exploits which are not already public even if the existence of a vulnerability is public.

Information or technical details that may help an attacker exploit the vulnerability or write an exploit.

Limited disclosure

If CSIRT needs to warn sites of the existence of a vulnerability that is not public, or provide information to sites which is not public, then the information must be sent by e-mail using the 'Traffic light protocol', usually amber or green. This includes technical details of any recommended mitigating action which may expose information useful to an attacker. Such information will of course not be posted on a publicly readable web page by CSIRT.

Disclosure in absence of adequate response from software provider

If a CSIRT member reports a vulnerability, the software provider should have some time to resolve the problem. For vulnerabilities in middleware distributed by the EGI UMD and the IGE, or any other software covered by a Service Level Agreement between software providers and EGI, vulnerabilities MUST be reported by CSIRT members by this mechanism and they MUST not disclose information. This process includes a responsible disclosure policy, which discloses vulnerabilities on a target date according to risk.

In the case where there is a vulnerability in other software such as an operating system, then the preferred method of handling is jointly with the Software Vulnerability Group to follow the vulnerability issue handling process. If there is no feedback from the software provider, then the existence of the vulnerability may be disclosed but any exploit written and/or information that allows an attacker to write an exploit should be excluded. Similar principles to the EGI Software Vulnerability issue handling process should apply.

After updates are available

Usually, when updates are available, the existence of the vulnerability will be made public by the provider of the software. Such public information may then be re-distributed by CSIRT. However, further technical details which are not public and may help an attacker will not be made public by the CSIRT team, until at least 6 months after the vulnerability has been resolved to ensure all users of the software (not just in EGI) have had ample time to update their systems.

14:45 → 15:00 Group activities update and forward planning

Update from group coordinators: --IRTF (Leif) Last month activites update Wiki page update: https://wiki.egi.eu/wiki/EGI_CSIRT:Incident_reporting update incident handling flowchart? Critical Vulnerability handling procedure (Linda's draft)? Plan for the coming month and quarter? --Security monitoring (Daniel) Last month activities update Pakiti development Nagios development Security dashboard and integration Plan for the coming month and quarter? --Security drill (Sven) Last month activites update preparation for SSC4 NGI run - Spanish NGI Plan for the coming month and quarter? --Security training & dissemination (Dorine) Last month activities update https://wiki.egi.eu/csirt/index.php/Development_area_for_the_security_dissemination_website Plan for the coming month and quarter?

15:00 → 15:20 RTIR Discussion (Carlos and all)

- Negotiation with egi it-support - RTIR setup/installation package for egi it-support - RTIR extensions/development works and possible timeline * security officers information from GOCDB * fine-grain access control (EGI SSO) for CSIRT, NGI security officers, site security officers etc. * Pakiti/Nagios intergration * Security dashboard/operation dashboard integration - RTIR email templates

15:20 → 15:25 update from team members

A quick roundtable update

15:25 → 15:30 Action review and AOB

To review any pending actions and ongoing issues https://rt.egi.eu/rt/index.html A list of new actions from this meeting AOB Next monthly meeting: 21-Dec-2010?