Tire tracks of vehicles that have gone around a closed entrance gate. Sebastian Lopienski of CERN uses this slide in his presentations on security, with the label “This is not good security.”
Most people are now familiar with the need to keep their computer systems up to date, whether installing Windows updates or Linux updates to ensure that the systems they use do not contain known vulnerabilities. Many are also aware that vulnerabilities make the news occasionally, for example the recent Microsoft Internet Explorer problem “IE Zero day used in Chinese cyber assault on 34 firms.”
Vulnerabilities can be seen as analogous to finding that a type of lock can be easily picked, or that a small hole can let in a tiny creature that then expands into a monster.
So what is happening in the grid world? Are the problems any different? Is anything being done to prevent or fix vulnerabilities? In fact, a lot happens quietly behind the scenes.
Vulnerabilities in the operating systems used as part of the European Grid production infrastructure are dealt with by the supplier of those systems, and the Operational Security team ensures that appropriate patches are rolled out in good time. Vulnerabilities may also occur in the software, known as grid middleware, which enables secure and reliable integration and access to the distributed computing resources owned by separate providers. To handle such vulnerabilities, the Grid Security Vulnerability Group (GSVG) was formed, led by the UK’s Science and Technology Facilities Council's Rutherford Appleton Laboratory, and consisting of members from eight different European institutions.
If anyone finds a vulnerability in the grid middleware, or more generally in the way the production infrastructure is run or used, they should report it to the GSVG email address, and not publicize it elsewhere. Vulnerabilities should not be discussed on mailing lists that don’t have carefully controlled access, because this effectively tells potential attackers how to exploit the system — or at least provides information they might use to attack the infrastructure.
Once a possible vulnerability has been reported, the information is kept in a private database, accessible only by the GSVG, the key developers from the technology providers, and those responsible for testing and distributing patches. The issue is then investigated, and if it is found to be valid, a “Risk Assessment” is carried out and it is placed in one of four risk categories according to the seriousness of the problem.
Worst case scenarios
Because site security officers most fear a vulnerability that gives an anonymous person access to the whole site, such a vulnerability would be in the highest risk category. If ‘root’ or ‘administrator’ access can be gained, this is usually put in one of the higher risk categories.
If a problem may cause a denial of service to one site in an unlikely set of circumstances, this is usually placed in the lowest risk category. A “Target Date” for fixing it is then set, according to the risk category.
In general, vulnerabilities are caused by the way in which the software has been written, and this allows the prioritizing of fixes according to how serious the vulnerabilities are. The appropriate development team then fixes the vulnerability in time for a patch to be released and deployed across the infrastructure before the target date. Advisories are written, which are referred to in the release notes, describing the resolved vulnerability.
It is also important to avoid the introduction of new vulnerabilities into the deployed infrastructure, and work is done to educate developers in secure coding practices. Tutorials on secure coding have been given by members of the University of Wisconsin - Universitat Autonoma de Barcelona Middleware Security and Testing Group. They have also carried out assessments of several major middleware systems, and previously found significant vulnerabilities in many of them, then helped the developers with remediation strategies.
Up to now, most of the work has concentrated on finding and eliminating vulnerabilities in EGEE gLite software. In the coming months, this activity will be folded into the EGI Software Vulnerabilities Group, and will expand to include all of the technology used as part of EGI’s production infrastructure.
Because no system is completely secure, the GSVG has long stated its mission as: “to incrementally make the grid more secure and thus provide better availability and sustainability of the deployed infrastructure.”
The overall aim is to prevent security incidents. Over the last four-and-a-half years, the group has handled a total of 192 potential vulnerabilities.
So far, there have been no incidents due to vulnerabilities in the grid middleware which the team is aware of. Hopefully, there will never be a headline along the lines of “Grid exploit results in $1,000,000 worth of data being lost” or “Grid exploit behind major cyber attack.”
If you don’t hear much more about it, then it is probably working best.
—Linda Cornwall, Rutherford-Appleton Laboratory, UK