SVG:Notes On Risk
|Main page||Software Security Checklist||Issue Handling||Advisories||Notes On Risk||Advisory Template||RAT/Membership||Documents||Assessment||Secure Coding||Info for SVG members|
Notes On Risk
This provides some notes on Risk Categories
The Risk Assessment Team (RAT) put each valid issue in 1 of 4 risk categories:
The RAT decides on the Risk category, according to their judgement. There is no fixed formula for setting the risk category. Various mitigating factors may lower the risk category, such as a vulnerability being difficult to exploit, or only being exploitable in rare circumstances. Certain situations may raise the risk category, such as a public exploit being available. The categories below are simply examples from past experience and discussions of which type of issue falls into which category.
Note that these properties refer to the potential for exploit, and have not been exploited.
Vulnerabilities which have been exploited are classed as Incidents and should be handled according to
by reporting to abuse (at) egi.eu.
Also see the EGI CSIRT Incident Reporting Wiki
- An anonymous or unauthorized user can gain root or admin access
- An anonymous or unauthorized user can carry out widespread damage, data destruction or access to confidential data
- A public exploit is available allowing an authorized user to trivially gain root or admin access
- A public exploit is available allowing unauthorized access
Usually for a vulnerability to be assessed as 'Critical' the problem needs to be widespread, and not only affect a small number of sites.
- Most Root or admin exploits where the vulnerability has not been made public, where no public exploit exists, and only an authorized user can exploit the problem.
- Most cases of identity theft and impersonation
- Most cases in which an authorized user in principle can carry out widespread destruction of data belonging to another group
- An Information leak which is illegal or embarrassing
- Grid Wide denial of service
- Potentially serious, but hard to exploit problems, where no actual exploit has been written and producing one is seen as difficult.
- e.g. hard to exploit buffer overflow
- e.g. hard to exploit Race conditions
- Most types of command injection vulnerability
- Problem where a user can cause disruption to services, but are easily traceable.
- Denial of service at single site
- Vulnerability in actual software - but if configured as instructed not exploitable
- Potential vulnerability identified, but not clear how to exploit it