Grid computing and related distributed computing technologies, are moving into the commercial sector. They offer the ability to tackle extremely complex problems by utilising processing power from multiple, geographically distributed machines. The special features of Grids include their aggregation of resources across multiple administrative domains, and resource management that offers specified performance, cost and quality of service. However, these features also create possible security risks.
Gateway Inc. has set up a grid of its approximately 8,000 display PCs in showrooms around the USA and it intends to offer a grid-computing service to businesses interested in processing computing jobs that would ordinarily require the power of an expensive supercomputer. This appears to be a perfect example of a company utilising an otherwise wasted resource - for the vast majority of the time, the display PCs are required to look attractive to potential customers, but not actually do any processing. Security was also considered in building the grid: the central server controlling it is physically secure and encryption technologies are used to protect data in transit. Data confidentiality is also protected by the nature of the grid - stealing useful data involves infiltrating many machines.
A rather different distributed computing project is SETI@Home, where people can assist in analysing radio telescope data in the search for extra-terrestrial intelligence by running a screensaver. The SETI@Home FAQ does have some information about security. They protect the participants from malicious data and Trojans by ensuring the screensaver will only download data from their data server, and only allowing screensavers that have been downloaded from their webpage to participate. To protect the project, they do not make the source code of the screensaver available, and there is a mechanism to detect forged results, which they do not describe for security reasons.
The security issues can be divided into problems for the computing power providers, and problems for the computing power users. The providers will be concerned that the software is not a Trojan, that it will only act as specified and not steal data, or open new security holes, or consume too much processor time. This is no different from the concerns of using any other software, and can be addressed in the same way: only use software from trusted suppliers. The users have different problems: their data might be stolen, or wrong results returned. This is similar to outsourcing processing to a traditional data centre, but addressing it in the same way, by only using trusted providers, fails because there are multiple providers in multiple administrative domains.
In the case of Gateway, the computers are all under Gateway's administration, but they are in insecure locations - members of the public enter the showrooms and try out the machines. A determined attacker has the opportunity to take away a copy of the software, reverse engineer and modify it for the desired result, and then re-introduce it to the showroom computers. The attacker could package the modification as a worm that could infect the other showroom PCs on the network, changing their software in the same way - there is then no difficulty in infiltrating enough machines to be able to steal a useful amount of data.
In the case of SETI@Home, the FAQ reveals the vulnerability - they admit to being concerned about falsified results. Their protection is to not release the source code, and to have an unspecified method to detect forged results. This is "security through obscurity" and detailed reverse engineering of the screensaver would reveal the tricks used.
However, I am not concerned about an attack on SETI@Home because there is no pay-off to falsifying results. The owner of the computer where the data demonstrating the existence of aliens was processed would get a special place in world history, but a positive result will be carefully checked so the lie will be quickly revealed. Most results will be negative, and the only benefit for a cheater reporting another negative might be that they could "process" more blocks of data, as they are not actually doing the work. The security through obscurity of the project makes cheating difficult enough that no one will bother. Actually, a false negative result would benefit an attacker who wanted to conceal the existence of ETI, but the concept of a worldwide conspiracy of aliens sabotaging SET@Home is probably best left as a plot for an X-files episode. So we assume that the data is being processed correctly, and, as it is data that would probably never be processed otherwise, there is a significant benefit in the project.
The situation changes when Grid computing becomes commercial because there could be a significant pay-off. If providers are paid for the processing power they supply, then not processing the data and returning a "normal" result would allow a cheater to "process" more data, and be paid more. False results may also give an advantage to a competitor, for example, if Grid computing is used for molecular modelling for drug design, a rival drug company could benefit by disrupting your research programme. In general, falsified results are not a security risk for grid computing if results that give a benefit to an attacker can and will be easily checked. That can be restated, results that will not be checked give no benefit to an attacker. However, the attacker's objective might be to steal the data being processed - this vulnerability can be fixed if the data can be effectively "anonymised".
So Grid computing has great potential for making massive or special computing power available to customers that could not otherwise afford it, but its nature, in particular, the fact that it involves machines across multiple administrative domains (and, therefore, under different security policies) create special security vulnerabilities. Potential users should evaluate the risks carefully.