Risk Submission

Page Breakdown

1. Subject - The subject is the only default required field in SimpleRisk. General guidelines for setting a helpful risk subject should include a description of the risk or event that would be taking place or has taken place. As an example “Unencrypted SSH Key on Server X” is not a very good risk as it does not accurately depict the risk involved with the described situation. A better example would be “Data and Revenue Lost Due to Unencrypted SSH key on Server X”. This field allows for fairly long entries with a 300 character limit. This risk subject is the most used unique description of a risk besides the risk ID associated with a risk and will be displayed in notification emails as well as most reports. Keeping these unique can be an important tool.
   
   
2. Risk Mapping - The Risk Mapping field provides 32 high-level risks that your risks may be mapped against.  These risks may be added or removed under the “Risk and Threat Catalog” link under the “Configure” menu.  These mappings are another way to help you to group different risks together in order to report on them to the management.

1. Threat Mapping - This field allows you to select if the risk is man-made or natural and the sub-category.
   
   
2. Category - This field allows you to select and categorize your risk. This field is able to have options added/removed/changed in the “Configure” menu at the top followed by “Add & Remove Values” on the left. Category can be a helpful tool for reporting and making use of the category field will contribute to the ability to narrow down search results that much faster.
   
   
3. Risk Source - This field is for tracking the source of the risk. This field can be edited from “Add & Remove Values” and the default values include: External, People, Process, and System.

1. Site/Location - Similar to Category this field can be edited in the same way as explained with Category in the “Add & Remove Values” menu. Site/Location doesn’t necessarily have to be the same place as say the affected asset. This site/location is generally where this risk takes place however depending on the situation this could mean the affected asset is nowhere near the actual site/location recorded with the risk.
   
   
2. Risk Scoring Method - This field is where you select the type of scoring you wish to use for a given risk. By default we support 6 methods: Classic, CVSS, DREAD, OWASP, Custom, and Contributing risk. Some short descriptions of each follow:
   Classic Risk Rating: This risk rating methodology uses a Likelihood value and an Impact value with a mathematical formula applied to come up with a risk score.  Typically something like Risk = Likelihood x Impact.  This is covered more in the Normalizing Risk Scores Across Different Methodologies blog post.
   
   CVSS: Also known as the Common Vulnerability Scoring System, CVSS is developed by the Forum of Incident Response and Security Teams (FIRST) organization and is what is used to rate all of the Common Vulnerabilities and Exposures (CVEs) found in the National Vulnerability Database (NVD).  It consists of a Base Vector, which has multiple values to estimate likelihood and impact, along with optional values to estimate the Temporal and Environmental impact on your environment.
   
   DREAD: The DREAD risk assessment model was initially used at Microsoft as a simple mnemonic to rate security threats on the basis of Damage, Reproducibility, Exploitability, Affected Users, and Discoverability.  We don't see it being used by customers very often, but it has been included in SimpleRisk since very early on in our product history.
   
   OWASP: The OWASP Risk Rating Methodology was created by Jeff Williams, one of the Founders of the OWASP organization, as a means to easily and more accurately assess the likelihood and impact of a web application vulnerability.  It's an application-centric play on the Classic Risk Rating described above, where the Likelihood is assessed based on Threat Agent and Vulnerability factors and the Impact is assessed based on Technical and Business factors.
   
   Contributing Risk: This risk scoring methodology came about in SimpleRisk as a custom development effort for a large data center customer in the UK.  It is also a play on the Classic Risk Rating described above, but assesses the Impact of the risk against multiple different, customizable, weighted values such as Safety, SLA, Financial and Regulation.
   
   Custom: This is by far the most simple, and potentially the most subjective, risk assessment methodology implemented in SimpleRisk.  The idea here is that you simply specify a number ranging from 0 through 10 to assess your risk.  Ideally, you would have some external method that you used to calculate that value and attach as evidence, but that may not always be the case.
   
   
3. External Reference ID - This field allows you to store any other aliases or ticket numbers this particular risk may have.  Another function of this field is if enter a CVE reference # the information of the risk will automatically be filled out  as long as your instance can reach out to the internet to retrieve that information.
   
   
4. Current Likelihood - This is where you set the likelihood when using class risk rating. Values in this field can be added/removed/renamed in the “Configure Risk Formula” page of the “Configure” menu.

1. Control Regulation - This field allows you to assign a controlling regulatory framework. This list is populated by the frameworks currently defined in the “Governance” section of SimpleRisk.
   
   
2. Current Impact - This is where you set the Impact when using class risk rating. Values in this field can be added/removed/renamed in the “Configure Risk Formula” page of the “Configure” menu.

1. Control Number - This field gives you a space to store any control numbers that may be relevant or govern the risk being created.
   
   
2. Risk Assessment - This field gives you a clear place to describe the current risk in question in detail. What is currently known about this risk, what damage it will cause, how it can occur, these are all types of information you might fill the risk assessment field.

1. Affected Assets - This field can be used to select assets already in the system or define a new one. Depending on if the option in the “Configure” menu is checked or unchecked you can set whether newly entered assets are automatically considered to be verified or not. If they are not automatically verified they will not appear in the list for the next risk or user to recall until they are verified via the Asset Management menu.
   
   
2. Technology - This field allows users to track the affected or involved technology/technologies. The values of this field are adjustable from the “Add & Remove Values” menu in “Configure” and include the following by default: Anti-Virus, Backups, Blackberry, Citrix, Datacenter, Live Collaboration, Mail Routing, Messaging, Mobile, Network, Power, Remote Access, SAN, Telecom, Unix, VMWare, Web Systems, Windows.
   
   
3. Team - This field is used for recording the team associated with a given risk. The entries for this field can be edited from “Add & Remove Values” in the “Configure” menu. This field is used as a determining factor for what risks, assets, and compliance audits a user may have access to when using the Team-Based Separation Extra (A paid feature requiring annual subscription). Users will also find a fair deal of reporting based around teams regardless of the Team-Based Separation Extra making this a vital field in creating meaningful reporting. The default teams available in SimpleRisk are: Branch Management, Collaboration, Data Center & Storage, Database, Information Security, IT Systems Management, Network, Unix, Web System, Windows.
   
   
4. Additional Stakeholders - This field allows users to select any other person to receive updates or notifications about the risk.

1. Owner - This is your risk owner field. This is generally assigned to the user who is directly responsible for overseeing the risk moving forward, they may not be the person who directly mitigates the risk but they generally govern the system or process the risk represents. This is a user select dropdown that allows you to select any already defined user in the system.
   
   
2. Owner’s Manager - This field is meant for the risk owner to select their superior in order for them to receive updates or notifications.

1. Additional Notes - This field is for anything that would be outside your given process for filling out the risk assessment field but is still relevant to the risk. Think of this as your free bonus field for information that may be important but has no pre-designated place.

1. Supporting Documentation - This button allows users to upload files to be attached to the risk. There is no strict limit on how many files can be uploaded to a risk and the size maximum is set on the “Settings” page in the “File Upload” tab in the “Configure” menu. Please note that the maximum set in the “Configure” can not exceed the maximum file size PHP is currently configured to handle. This page is also used for controlling the file upload types and extensions that are allowed. For more information on adjusting the maximum upload size please see the following: How to Configure Max File Size in Simplerisk.

1. Jira Issue Key - This field is to mention any associated Jira ticket number/key if it’s available.

1. Tags - The Tags field is for storing easy to search terms that apply to a given risk. Tagging has nearly endless possibilities for ensuring users are able to locate and group risks by meaningful and helpful terms. Tags are reusable and searchable by just starting to type the tag in question into the Tags field or clicking the field and scrolling through the dropdown to find your tags.
   
   

Instruction

The risk life cycle begins with submitting a risk. We designed this page to be intuitive in nature and powerful in practice. The only requirement for submitting a risk unless configured otherwise is a subject. Depending on the size and scope of your risk management program you may have situations where users submitting risks may not be a part of the risk management team or even particularly risk savvy. This is why we have left the bare minimum low for risk submission. We felt it would always be preferable to have an incomplete risk that is valid rather than miss that risk altogether because adequate information was not available at the time of submission.

When it comes  to entering risks we suggest that careful thought be taken when creating your risk subject. Subjects like “Unsecured terminal in building A” tend to be a little thin as they aren’t actually describing the risk at hand. Another way to pose this same example would be “Unsecured terminal resulting in release of private information in building A” tend to be better descriptions although you may want to consider exactly what information is necessary. Since we give both a Site/Location field and an Asset field you may just leave off the location entirely. This would help us to arrive at the subject of “Unsecured terminal resulting in release of private information”. This would be considered concise and immediately descriptive to all levels of the organization who might read it.

Once you have a subject in place it’s time to start defining the details, things like where this risk takes place, or details about the actual particulars of what damage could be done or how this could be achieved are also welcomed details to add to your risks. When users are entering risks we should be in the mindset that the individuals reviewing or creating mitigations for this risk may have no prior experience or knowledge of this risk. Every detail that helps paint a realistic picture of the situation is important. SimpleRisk offers a plethora of fields to help you in this endeavor and if you find yourself needing more there is the Customization Extra to fill that void allowing you to add as many fields as you need to accurately describe your risks.

After the completion of the details of a risk it’s time to submit. When a risk is submitted it is automatically pushed to the plan mitigation and plan review ques. If the Notification Extra is present and turned on then this would also send off any emails notifying that a risk has been submitted. Depending on the configuration this can include the Owner, Owner’s Manager, and any Additional Stakeholders. 

Now that submission has been completed you will be moved to the Risk Details page for the risk that was just submitted. At this point the risk life cycle of mitigation and review can begin.

Summary

The Risk Submission page in SimpleRisk is your #1 stop for entering risks into the system to begin the risk management lifecycle. This page should have served to answer all questions related to risk submission but if you feel anything has been missed or just seek further clarification please reach out to us at support@simplerisk.com.