Difference between revisions of "Security Information"
(→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.
- How to Report a Security Incident
- How to Report a Software Vulnerability
- How to Generate Emergency Argus Credential Suspension on the UK NGI Argus
Security 'How To' and other useful info
- Security system errors and workarounds
- 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
SVG
SPG
- Security Policy Group Wiki This contains detailed policies which apply to GridPP sites.
SCG
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
Info for the UKNGI Security Team
