Difference between revisions of "Security Information"

From GridPP Wiki
Jump to: navigation, search
(Security 'How To' and other useful info)
Line 9: Line 9:
 
==Security 'How To' and other useful info==
 
==Security 'How To' and other useful info==
  
 +
* [[Security system errors and workarounds]]
 
* [[Security monitoring/updates]]
 
* [[Security monitoring/updates]]
 
* [[How to ban/blacklist user on CE and SE]]
 
* [[How to ban/blacklist user on CE and SE]]
Line 14: Line 15:
 
* [http://www.gridpp.ac.uk/deployment/users/myproxy.html How can I renew a proxy used by an automated process?]
 
* [http://www.gridpp.ac.uk/deployment/users/myproxy.html How can I renew a proxy used by an automated process?]
 
* [[Linux Kernel: 64-bit Compatibility Mode Stack Pointer Underflow CVE-2010-3081]]
 
* [[Linux Kernel: 64-bit Compatibility Mode Stack Pointer Underflow CVE-2010-3081]]
 
  
 
==EGI documents and Links ==
 
==EGI documents and Links ==

Revision as of 12:21, 5 November 2015

Security Incident and Vulnerability reporting

These apply to GridPP and NGS.

Security 'How To' and other useful info

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

SVG

SPG

SCG

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

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

Info for the UKNGI Security Team