Difference between revisions of "Security Information"

Revision as of 15:37, 18 July 2013

Security Incident and Vulnerability reporting

These apply to GridPP and NGS.

• How to Report a Security Incident
• How to Report a Software Vulnerability

Security 'How To' and other useful info

• Security monitoring/updates
• How to ban/blacklist user on CE and SE
• Glexec, LCAS, LCMAPS and Pilot Job
• How can I renew a proxy used by an automated process?
• Linux Kernel: 64-bit Compatibility Mode Stack Pointer Underflow CVE-2010-3081

EGI documents and Links

GridPP sites are certified as part of the EGI infrastructure, hence the EGI security policies and procedures apply to GridPP sites.

CSIRT

• EGI Computer Security Incident Response Team description

• EGI Security Incident Handling Procedure

• EGI CSIRT Wiki

SVG

• EGI Software Vulnerability Group description

• EGI Software Vulnerability Group Wiki

• EGI Software Vulnerability Issue Handling Process

SPG

• EGI Security Policy Group Description

• Security Policy Group Wiki This contains detailed policies which apply to GridPP sites.

SCG

• EGI Security Co-ordination Group description

Some of Mingchao Ma's Security Related Presentations and Training talks

• GridPP Tier2 Sites Security Review, April 2010, GridPP24 Collaboration Meeting
• Manage Security and Handle Security Incident training talk, March 2010, International Symposium on Grid Computing (ISGC) security training workshop
• Security Incident Investigation training talk, June 2010 UK HEPSYSMAN workshop
• Risk Assessment training talk, November 2010 UK HEPSYSMAN workshop

GridPP SSC6 Common Issues and Recommendations

DN banning/suspension

A considerable number of sites were unsuccessful at banning the compromised DN on their first attempt. This was complicated by inconsistent documentation, a diverse number of configuration files and limited ability to test banning configurations.

In the future, Argus is intended to provide a central service to manage authorisation decisions within the site. This should ease the large number of different configuration settings which are currently required to completely block a DN from CE, WMS and SE nodes. EGI-CSIRT is also developing a central user banning capability linked to Argus which should result in sites not having to perform any specific action to block a compromised DN. A few sites found it useful to additionally temporarily block a locally available DN as this allowed them to test if the blocking configuration was complete.

Since this was a common problem for the sites involved in the challenge we are planning to conduct a lightweight exercise in user banning across all sites in the near future. This is expected to consist simply of a request to all sites to ban a test DN from their resources, that will then be checked remotely, and any issues worked through with sites. The principle is that this will be very much an exercise intended to help, not a test.

Security contact information and acknowledgement

A number of sites included their University CERT team within the recipients list of their site-security-contacts email address. This was particularly valuable at smaller sites where there was limited resource available from the local admins and should be standard practice at all GridPP sites.

Network monitoring

No sites demonstrated any network monitoring from their sites. Whilst the large volumes of data transfer conducted within GridPP precludes full PCAP forensic capture of network traffic it should be possible to collect summary data such as Argus (qosient) or Netflow/Sflow statistics. Whilst the SSC malware simply performed some clear text HTTP and traceroutes real malware may perform more nefarious actions. It would be immensely useful for site admins to be able to relate network activity to a user DN (in the same way as storage or CPU currently is attributed).

In a previous run of the exercise, one site managed to include useful network connection information gleaned from firewalls logs collected by their upstream (site level) network. While many sites will not have access to similar logging we would encourage all sites to:

• Investigate what, if any, network monitoring is carried out by their site networking or security teams, and whether it is possible to access such logs in the event of an incident.

• To consider flow monitoring features that may be available in their existing network equipment (e.g. cluster core switches)

• To share any examples of interesting good practice with other sites.

EGI TF 2011 Security Training Session

• 2 talks about Middleware Security
• 6 talks about Operational Security

Info for the UKNGI Security Team

• Security_Duty
• Security Duty Rota