• Subscribe

At Science Node, we need your help. We have ALMOST reached our fund-raising goal. In order to maintain our independence as a source of unbiased news and information, we don’t take money from big tech corporations. That’s why we’re asking our readers to help us raise the final $10,000 we need to meet our budget for the year. Donate now to Science Node's Gofundme campaign. Thank you!

Feature - Grid security vulnerabilities: keeping out of the headlines

Grid security vulnerabilities: keeping out of the headlines


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

Join the conversation

Do you have story ideas or something to contribute? Let us know!

Copyright © 2019 Science Node ™  |  Privacy Notice  |  Sitemap

Disclaimer: While Science Node ™ does its best to provide complete and up-to-date information, it does not warrant that the information is error-free and disclaims all liability with respect to results from the use of the information.

Republish

We encourage you to republish this article online and in print, it’s free under our creative commons attribution license, but please follow some simple guidelines:
  1. You have to credit our authors.
  2. You have to credit ScienceNode.org — where possible include our logo with a link back to the original article.
  3. You can simply run the first few lines of the article and then add: “Read the full article on ScienceNode.org” containing a link back to the original article.
  4. The easiest way to get the article on your site is to embed the code below.