|
|
| (15 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| {{svg-header}} | | {{svg-header}} |
| | | {{DeprecatedAndMovedTo|new_location=https://confluence.egi.eu/display/EGIBG/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:
| |
| | |
| *Critical
| |
| *High
| |
| *Moderate
| |
| *Low
| |
| | |
| 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 [https://documents.egi.eu/public/RetrieveFile?docid=47&version=11&filename=EGI-MS405-IRTF-47-V12.pdf EGI CSIRT incident Handling procedure pdf file. ]
| |
| See the [[EGI_CSIRT:Incident_reporting | EGI CSIRT Incident Reporting Wiki ]] by reporting to abuse (at) egi.eu
| |
| | |
| You should then follow the
| |
| | |
| | |
| == Critical ==
| |
| | |
| | |
| 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.
| |
| | |
| | |
| | |
| == High ==
| |
| | |
| | |
| 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.
| |
| | |
| | |
| == Moderate ==
| |
| | |
| | |
| 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.
| |
| | |
| == Low ==
| |
| | |
| 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.
| |
| | |
| | |
| | |
| | |
| | |
| | |
| {{svg-issue-views}} | | {{svg-issue-views}} |
The wiki is deprecated and due to be decommissioned by the end of September 2022.