The level of security within a system represents its ability to protect itself against accidental or deliberate intrusion. It is possible to break security down into three subclasses, integrity, confidentiality and privacy. Integrity is the system’s ability to protect itself from damage (data integrity is an example of this). Confidentiality is the system’s ability to ensure that information is only revealed to those people who have a right and a need to access that information. Privacy is the art of keeping information secluded from the presence or view of others, this information may be personal to an individual or organisation, and could include the anonymity of users within a P2P system. Secrecy is the act of keeping information in a state of concealment, once achieved access should only be allowed through proper access methods known as authorisation.
Ensuring security within P2P systems is more difficult than with standard centralised server systems. On the one hand there are issues such as authenticating your communication partners and sharing information only with the people you trust. And on the other the nature of P2P systems typically involves supporting the anonymity of users.
Security requirements can differ from one system to another, based upon what assets require protection. Some of these assets can even contradict one another (i.e. user anonymity and user authentication). The first goal in building a secure system is identifying the assets that should be protected.
Vulnerabilities are ways in which potential attackers can penetrate a system. Vulnerabilities can occur in a system through many ways: design errors, implementation errors, change in the organisational/computing environment in which the system exists and administration errors, or a combination of them. These are largely generic to any system, including P2P systems. An example of vulnerability was detected in ICQ where a buffer overflow could allow an attacker to execute arbitrary code on a victims system.
Attacks resulting from vulnerabilities in a system are typically performed for some hostile goal. These attacks can originate from within the system/organisational boundaries (e.g. employee saboteurs) as well as from outside these boundaries. Single stage attacks are usually where a vulnerability is known and is immediately exploited, and there are two (or multi) stage attacks where the first attack is simply intended to discover vulnerabilities in the system that could be exploited. Two (multi) stage attacks are commonly used on systems where little is known about their vulnerabilities.
The goals of attacks can be broadly placed into areas such as ‘Denial of Service’, ‘data leakage’ and ‘data corruption’. These goals are the consequences of the attacks and are the main objective of the attacker.
The links between vulnerabilities, attacks and consequences are not clear-cut however. One point is that vulnerabilities may exist that are never known, found or exploited, which always leaves the potential for vulnerabilities and is why any security practices should not be stopped once a system is in place.
There is also no need for a vulnerability to exist for an attack to take place. Professionals, hired by an organisation, can carry out attacks on a system to discover vulnerabilities that can then be patched. Also the consequences of an attack will clearly not transpire if the attack is successfully repelled by the system, or more dangerous, is the fact that the consequences will not be detected until it is too late. This clearly shows that although relationships exist between vulnerabilities, attacks and consequences these relationships are not carved in stone.
Because a P2P system can be viewed as a synergistic system, the emergent system becomes composed of the individual nodes that are connected to it. This can create security problems, as it does in any component-based system incorporating message-passing communication, where the messages that are passing around are exposed to risks of tampering, sniffing and falsification. Security considerations are often incorporated into specific areas of a system (the parts containing the assets to be protected) and this philosophy can sometimes be inappropriate, especially in a P2P environment. The entire system must be taken into account, and the systems architecture from its foundations must be geared to support the security design.
Because P2P is essentially a new technology it raises more concerns, as the application of traditional security techniques to this new technology may not be effective against new and innovative methods of attack. Traditionally security in a system becomes more sturdy as time passes, new vulnerabilities are patched and successful attacks become harder to achieve, P2P is so young it has not had time to mature its basis of security. There are also several perspectives to security, that of the attacker, the user and also those responsible for the implementing the security (both software developers and administrators). These perspectives may or may not have an impact on each other depending on the system; a user for example may want a certain level of security out of the system but without it hampering their usage of it. Likewise a system administrator may want to implement a high level of security within a system, but this may come at the expense of usability. An important point is the fact that administrators creating usable systems, at the expense of security, make the attackers job easier.