MozillaWiki

Security/Risk management/Rapid Risk Assessment: Difference between revisions

Page Discussion

Security/Risk management/Rapid Risk Assessment (view source)

Revision as of 23:23, 21 December 2016

2,523 bytes added ,  21 December 2016
Automated sync from https://github.com/mozilla/wikimo_content
(Automated sync from https://github.com/mozilla/wikimo_opsec)
(Automated sync from https://github.com/mozilla/wikimo_content)
 
(10 intermediate revisions by 3 users not shown)
Line 3: Line 3:
     <td style="min-width: 25em;">__TOC__</td>
     <td style="min-width: 25em;">__TOC__</td>
     <td style="vertical-align: top; padding-left: 1em;">
     <td style="vertical-align: top; padding-left: 1em;">
'''STATUS: READY'''
<span style="background-color: #14892c; border-radius: .25em; color: #ffffff; display: inline-block; font-weight: bold; margin: .1em 0; min-width: 6em; padding: .05em .5em; text-transform: uppercase; text-align: center;">READY</span>
 
'''RRA Version supported: 2.5.x'''
'''RRA Version supported: 2.5.x'''


Any team uses a risk based methodology when making any decision.
People regularly use a risk based methodology when making decisions.
The Rapid Risk Assessment or Rapid Risk Analysis (RRA) methodology helps formalize these decisions and ensures that they're
The Rapid Risk Assessment or Rapid Risk Analysis (RRA) methodology helps formalize this type of decision making and ensures that the process is
reproducible, consistent and easy to communicate.
reproducible, consistent and the results are easy to communicate.


This document assumes that the reader is familiar with risk definitions, and the Mozilla risk levels from the
This document assumes that the reader is familiar with risk definitions, and the Mozilla risk levels from the
[Risk_management] documentation (i.e. read it first).
[[Security/Risk management|Risk Management]] documentation (i.e. read it first).


The Enterprise Information Security Team (Infosec) maintains this document as a reference guide for security engineers
The Enterprise Information Security Team (Infosec) maintains this document as a reference guide for security engineers
and anyone interested in following our risk management processes.
and anyone interested in following Mozilla's risk management processes.


Updates to this page should be submitted to the [https://github.com/mozilla/wikimo_opsec/ source repository on github].
Updates to this page should be submitted to the [https://github.com/mozilla/wikimo_opsec/ source repository on github].
Line 32: Line 31:
|-
|-
|
|
A typical Rapid Risk Analysis/Assessment (RRA) lasts about 30 minutes.
A typical Rapid Risk Analysis/Assessment (RRA) takes about 30 minutes.
It is not a security review or a full threat-model, peneration test, review, etc. These may however follow an RRA.
It is not a security review, a full threat-modelling, a penetration test, privacy review etc. These types of activites may however follow an RRA if deemed appropriate.


The objective of the RRA is to understand the value and impact of a service on a business, project, company - it does not
The objective of the RRA is to understand the value and impact of a service on a business, project, company - it does not
focus on quantifying and analyzing security controls.
focus on quantifying and analyzing security controls.
'''The RRA process analyze and assess services'''. Analyzing processes, or individual pieces of data is not recommended through the RRA process.
'''The RRA process is intended for analyzing and assessing services, not processes or individual pieces of data'''.
|}
|}


Line 44: Line 43:
Data is the most important item in risk management. Software, websites, infrastructure, networks and people handle, process, exchange and store data.
Data is the most important item in risk management. Software, websites, infrastructure, networks and people handle, process, exchange and store data.


The RRA focuses efforts on creating a summary of the risks associated with our data. In particular it aims to be:
The RRA focuses on creating a summary of the risks associated with your data. It aims to be:


* '''Quick!''' About 30 minutes to 60 minutes maximum.
* '''Quick!''' 30 to 60 minutes maximum.
* '''Very high-level'''. Details are for complete threat models.
* '''Very high-level'''. Details are for complete threat models.
* '''Concise, readable'''. Short table with clear risk levels.
* '''Concise, readable'''. Short table with clear risk levels.
* '''Easy to update'''. Can be run during the architecture phase, and re-run if the project is re-architected or new high level design decisions are made.
* '''Easy to update'''. Can be run during the architecture phase of a project, and re-run if the project is re-architected or new high level design decisions are made.
* '''Informative''' It collects risk impact, an approximate impact likelihood and data dictionary.
* '''Informative''' Collects risk impact, an approximate impact likelihood and a data dictionary.


This helps to make the following type of risk-based decisions:
This helps to make the following type of risk-based decisions:


* Is the security provided by a given platform appropriate to host a specific type of data?
* Is the security provided by a given platform appropriate to host a specific classification of data?
* How much should we care about maintenance, etc?
* How much should we care about maintenance, etc?
* Does this service warrant a full security threat-model, peneration test, privacy review?
* Does this service warrant a full security threat-modelling, penetration test, or privacy review?
* How long should we spend on these tasks?
* How long should we spend on these tasks?
* Is there anything obvious I should really look at fixing right now?
* Is there anything obvious we should really look at fixing right now?


{| class="wikitable"
{| class="wikitable"
Line 67: Line 66:
Firefox accounts store user data:
Firefox accounts store user data:


* What happens if that data is exposed to the world? What happens if the systems go down? What happens if that data is disclosed? What if the data is modified?
* What happens if that data is disclosed to the world? What happens if the service goes down? What happens if the data is modified by someone unauthorized?
* Are we at financial, operational risk? Is our reputation also at risk?
* Do these events put us at financial risk? Is our productivity affected? Is our reputation affected?
* What kind of data does Firefox accounts exactly handle? How sensitive is the primary kind of data used by Firefox accounts?
* What types of data does Firefox accounts handle? How sensitive is the primary type of data used by Firefox accounts?


The RRA table facilitate the answer to these questions.
The RRA risk table facilitates discovering the answers to these questions.
|}
|}


Line 77: Line 76:


RRAs are designed to be updated and re-runnable as needed. That being said, it is recommended to run the first RRA
RRAs are designed to be updated and re-runnable as needed. That being said, it is recommended to run the first RRA
during the design or architecture phase of new services, when an initial data flow diagram for the service has been created.
during the design or architecture phase of new services, once an initial data flow diagram for the service has been created.


== What to run through RRAs? ==
== What should and shouldn't an RRA be run for? ==


RRAs can only be used for services. Any project belongs to or provides a service. Any component, piece of code or data
RRAs can only be run on services. Any project belongs to or provides a service. Any component, piece of code or data
belongs to a service. Find which service it belongs to and RRA that service, not the specific piece of code or data.
belongs to a service. Find which service the element you're interested in belongs to and run an RRA for that service, not for the specific piece of code or data.


Large services should be split into multiple smaller services or sub-services that handle a specific type of data and
Large services should be split into multiple smaller services or sub-services that handle a specific type of data and
expose a limited set of features. This choice has to be made by the security engineer running the RRA. If the
expose a limited set of features. This choice has to be made by the security engineer running the RRA. If the
sub-services belong to different teams, it is a strong indicator that multiple RRAs should be ran.
sub-services are owned by different teams, it is a strong indicator that multiple RRAs should be run.


Large services that cannot be split up not only lead to a complex assessment, but also may indicate that the service
Large services that cannot be split up not only lead to a complex assessment, but also may indicate that the service
Line 94: Line 93:
linked services field of the RRA.
linked services field of the RRA.


== What to focus on during RRAs? ==
== What to focus on during an RRA? ==


* '''Impact assessment'''. The RRA is the authority for impact levels and these are paramount.
* '''Impact assessment'''. The RRA is the authority for impact levels and these are paramount.
* '''Rationales'''. Anyone should understand why you've set a specific impact level by reading  
* '''Rationales'''. Anyone should understand why a specific impact level was chosen by reading the rationale.
* Getting '''value for the team'''. The team needs to understand what is most important to protect.
* Getting '''value for the service owner'''. The service owner needs to understand what is most important to protect.


What to '''NOT''' focus on:
What to '''NOT''' focus on:
* Gathering security controls, figuring out how effective they are, etc. Don't do that! This information may be recorded if it comes up but do not focus on it.
* Gathering security controls and figuring out how effective they are. Don't do that! This information may be recorded if it comes up but do not focus on it.
* Likelihood, Security provided by service. Don't spent much time there! These are "10, 000 feet approximations" and part of a larger risk calculation mechanism.
* Likelihood, Security provided by service. Don't spent much time there! These are "10,000 foot approximations" and part of a larger risk calculation mechanism.


== Guided process: Running your RRA in ~30 minutes ==
== Guided process: Running your RRA in ~30 minutes ==
Line 122: Line 121:


* The discussion languishes (>1 minute) around "how to mitigate this very issue" or "we're doing X to ensure this never happens".
* The discussion languishes (>1 minute) around "how to mitigate this very issue" or "we're doing X to ensure this never happens".
* The discussion focuses on process instead of filling the form.
* The discussion focuses on process instead of filling out the form.
* The discussion about how the service works takes forever (>15 minutes) and the owner has to lookup every single detail.
* The discussion about how the service works takes forever (>15 minutes) and the owner has to lookup every single detail.


Line 128: Line 127:
minutes'''.
minutes'''.
This leaves you with some room for error, and handle services that weren't well understood by their owners.
This leaves you with some room for error, and handle services that weren't well understood by their owners.
In any case, always watch your clock!
In any case, always watch the clock!
|}
|}


=== Getting started (pre-work) ===
=== Getting started (pre-work) ===


* Ensure no previous RRA exist, else re-use the previous RRA.
* Ensure no previous RRA exist; if it does re-use the previous RRA.
* Create a copy of the [https://drive.google.com/open?id=160V89R-VdIe1AEHcT_sX89UToV2gv8mLshhoia2-6mM template] and move it to the correct directory (or your personal Google drive if you're testing the RRA process).
* Create a copy of the [https://docs.google.com/spreadsheets/d/1jxUEQUSAC-q1rVdZ29fH5ijKfIRNBKfCCgWMsfHNqvQ template] and move it to the correct directory (or your personal Google drive if you're testing the RRA process).
* Invite 1 or 2 members (product owners, lead engineers, etc.) related to the service with enough technical knowledge, ensure they will bring a diagram of data
* Invite 1 or 2 members (product owners, lead engineers, etc.) related to the service with enough technical knowledge, ensure they will bring a diagram of data flows and have an understanding of the data being stored or processed by the service. You do not want more than 4 or 5 people total as this will slow down the RRA. Most RRAs are run 1 on 1 (2 people total).
flows and have an understanding of the data being stored or processed by the service. You do not want more than 4 or 5 persons total as this will slow down the RRA. Most RRAs are run 1 on 1 (2 persons total).
* Make sure everyone invited has '''edit''' rights to the document, and has the document opened in front of them when the RRA starts.
Make sure everyone invited has '''edit''' rights to the document, and has the document opened in front of them when the
* If this is anyone's first RRA, ensure they understand what risk impacts are, and the standard risk levels we are using, as well as giving them a short overview of what is going to happen:
RRA starts.
* If this is anyone's first RRA, ensure they understand what risk impacts are, and the standard risk levels we are using, as well giving them a short overview of what is going to happen:
** Filling in header/meta-data information about the service.
** Filling in header/meta-data information about the service.
** Getting an idea of how the service is architected.
** Getting an idea of how the service is architected.
** Recording all data the service may process/store and how sensitive it is.
** Recording all data the service may process/store and how sensitive it is.
** Run through the risk table and figure out what happens if the data leak, is modified, is unavailable, etc - while
** Running through the risk table and figuring out what happens if the data is leaked, modified, unavailable, etc - while assigning the standard risk levels.
assigning the standard risk levels.
** Writing down any recommendations for the service.
** Write down any recommendation for the service.


{| class="wikitable"
{| class="wikitable"
Line 166: Line 162:
** In some cases the scope is critical to the understanding of the RRA.
** In some cases the scope is critical to the understanding of the RRA.
* If you know of linked services (for example if it uses SAML authentication, the linked service could be "SAML SSO")
* If you know of linked services (for example if it uses SAML authentication, the linked service could be "SAML SSO")
* Ask the team who owns the service (takes decisions if the service must go down for example), who develops the code and who's operating it.
* Ask about who owns the service (for example the team that makes decisions if the service must go down), who develops the code and who operates it.
** Generally its a team name and one or more names. Sometimes, it's a third party (SaaS).
** Generally its a team name and one or more individual names. Sometimes, it's a third party (SaaS).
** You never want to leave the service owner blank, and you always want a Mozilla contact as service owner.
** You never want to leave the service owner blank, and you always want a Mozilla contact as service owner.
** You always want at least a team name, as people change teams, etc. A team name and a responsible person name is ideal.
** You always want at least a team name, as people change teams. A team name and a responsible person name is ideal.
* Other fields will be automatically filled in or filled in at a later time.
* Other fields will be automatically filled in or filled in at a later time.


=== General notes (5-10 minutes) ===
=== General notes (5-10 minutes) ===


At this point you want to have a good understanding of the service:
In this phase you want to gain a good understanding of the service:


* Where is it running? Which platforms?
* Where is it running? On which platforms?
* What is it running, what kind of software or technologies?
* What is it running, what kind of software or technologies?
* How is it structured, architected? Do you have your data flow diagram?
* How is it structured, architected? Do you have your data flow diagram?
* Do you have some documentation links?
* Do you have some documentation links?
* Any URL to access the service?
* Any URLs to access the service?
* How is administration performed?
* How is administration performed?
* How is authorization (login) performed?
* How is authorization (login) performed?
* What is logged, where?
* What is logged and where?


Anything of interest may go in the RRA general notes. This can be used during the description of the service as well if you hear interesting details that did not fit in the description.
Anything of interest may go in the RRA general notes. This can be used during the description of the service as well if you hear interesting details that did not fit in the description.


{| class="wikitable"
{| class="wikitable"
Line 203: Line 199:
** Specific configuration data (on disk or in RAM).
** Specific configuration data (on disk or in RAM).
** Credentials used by the applications (keys, logins, etc.).
** Credentials used by the applications (keys, logins, etc.).
** Potentially program code/script (such as if the code is stored on a Git repository, downloaded and ran by the service).
** Software source code/scripts (such as if the code is stored on a Git repository, downloaded and ran by the service).
** Ask again and specify you want to make sure they've listed all sensitive data they can think of.
** Ask again and specify you want to make sure they've listed all sensitive data they can think of.
* Set the data classification for each data type in the dictionary, such as "PUBLIC", "STAFF", etc. Mozilla uses standard classification levels.
* Set the data classification for each data type in the dictionary, such as "PUBLIC", "STAFF", etc. Mozilla uses standard classification levels.
* If some compensating controls are mentioned or there are more details about the data you can fill them in as well.
* If some compensating controls are mentioned or there are more details about the data you can fill them in as well.
** For example "User attributes, classified INTERNAL, protected by LDAP authentication, used to find out the user
** For example "User attributes, classified INTERNAL, protected by LDAP authentication, used to find out the user's t-shirt size".
t-shirt size".
* Based on this dictionary/catalog of data, figure out which is the main data classification the service is handling. If unsure, ask the team.
** For example "mock is mainly used to serve package files that are PUBLIC." (public main data classification).
** Set this in the header section at the top of the RRA template.


=== RRA Risk table (5-10 minutes) ===
=== Risk table (5-10 minutes) ===


This is where the risk impact assessment is done, and where the probability for these impact is roughly estimated.
This is where the risk impact assessment is done, and where the probability for these impacts is estimated.
The risk impact is using ''probable impact'', that is, worst-case scenario impacts that seem possible.
The risk impact represents ''probable impact'', that is, worst-case scenario impacts that seem possible.


==== Levels summary ====
==== Levels summary ====
Line 224: Line 216:
{| class="wikitable"
{| class="wikitable"
|-
|-
| <span style="padding: 0 32px;background-color:lightgrey;">LOW</span>
| <span style="background-color: #cccccc; border-radius: .25em; color: #000000; display: inline-block; font-weight: bold; margin: .1em 0; min-width: 6em; padding: .05em .5em; text-transform: uppercase; text-align: center;">LOW</span>
| Nobody cares.
| Nobody cares.
|-
|-
| <span style="padding: 0 20px; background-color:steelblue;">MEDIUM</span>
| <span style="background-color: #4a6785; border-radius: .25em; color: #ffffff; display: inline-block; font-weight: bold; margin: .1em 0; min-width: 6em; padding: .05em .5em; text-transform: uppercase; text-align: center;">MEDIUM</span>
| Tweets, forum posts, e-mails are seen.
| Tweets, forum posts, e-mails are seen.
|-
|-
| <span style="padding: 0 32px;background-color:#FFF380;">HIGH</span>
| <span style="background-color: #ffd351; border-radius: .25em; color: #000000; display: inline-block; font-weight: bold; margin: .1em 0; min-width: 6em; padding: .05em .5em; text-transform: uppercase; text-align: center;">HIGH</span>
| Articles in technical websites such as HN, Ars-Technica, etc. are seen.
| Articles in technical websites such as Hacker News, Ars-Technica, etc. are seen.
|-
|-
| <span style="padding: 0 14px; background-color:#E77471;">MAXIMUM</span>
| <span style="background-color: #d04437; border-radius: .25em; color: #ffffff; display: inline-block; font-weight: bold; margin: .1em 0; min-width: 6em; padding: .05em .5em; text-transform: uppercase; text-align: center;">MAXIMUM</span>
| Scandal. We appear on TV, BBC, etc.
| Scandal. National and international news outlets report on the event.
|-
|-
|}
|}
Line 242: Line 234:
{| class="wikitable"
{| class="wikitable"
|-
|-
| <span style="padding: 0 32px;background-color:lightgrey;">LOW</span>
| <span style="background-color: #cccccc; border-radius: .25em; color: #000000; display: inline-block; font-weight: bold; margin: .1em 0; min-width: 6em; padding: .05em .5em; text-transform: uppercase; text-align: center;">LOW</span>
| SG (Small Group): affected for < 24h. LG (Large Group): affected for minutes.
| SG (Small Group): affected for < 24h. LG (Large Group): affected for minutes.
|-
|-
| <span style="padding: 0 20px; background-color:steelblue;">MEDIUM</span>
| <span style="background-color: #4a6785; border-radius: .25em; color: #ffffff; display: inline-block; font-weight: bold; margin: .1em 0; min-width: 6em; padding: .05em .5em; text-transform: uppercase; text-align: center;">MEDIUM</span>
| SG: affected for days. LG: affected for hours.
| SG: affected for days. LG: affected for hours.
|-
|-
| <span style="padding: 0 32px;background-color:#FFF380;">HIGH</span>
| <span style="background-color: #ffd351; border-radius: .25em; color: #000000; display: inline-block; font-weight: bold; margin: .1em 0; min-width: 6em; padding: .05em .5em; text-transform: uppercase; text-align: center;">HIGH</span>
| SG: affected for weeks. LG: affected for days.
| SG: affected for weeks. LG: affected for days.
|-
|-
| <span style="padding: 0 14px; background-color:#E77471;">MAXIMUM</span>
| <span style="background-color: #d04437; border-radius: .25em; color: #ffffff; display: inline-block; font-weight: bold; margin: .1em 0; min-width: 6em; padding: .05em .5em; text-transform: uppercase; text-align: center;">MAXIMUM</span>
| SG: affected for a month or more. LG: affected for weeks.
| SG: affected for a month or more. LG: affected for weeks.
|-
|-
Line 260: Line 252:
{| class="wikitable"
{| class="wikitable"
|-
|-
| <span style="padding: 0 32px;background-color:lightgrey;">LOW</span>
| <span style="background-color: #cccccc; border-radius: .25em; color: #000000; display: inline-block; font-weight: bold; margin: .1em 0; min-width: 6em; padding: .05em .5em; text-transform: uppercase; text-align: center;">LOW</span>
| < 100k USD.
| < 100k USD.
|-
|-
| <span style="padding: 0 20px; background-color:steelblue;">MEDIUM</span>
| <span style="background-color: #4a6785; border-radius: .25em; color: #ffffff; display: inline-block; font-weight: bold; margin: .1em 0; min-width: 6em; padding: .05em .5em; text-transform: uppercase; text-align: center;">MEDIUM</span>
| < 1M USD.
| < 1M USD.
|-
|-
| <span style="padding: 0 32px;background-color:#FFF380;">HIGH</span>
| <span style="background-color: #ffd351; border-radius: .25em; color: #000000; display: inline-block; font-weight: bold; margin: .1em 0; min-width: 6em; padding: .05em .5em; text-transform: uppercase; text-align: center;">HIGH</span>
| < 10M USD.
| < 10M USD.
|-
|-
| <span style="padding: 0 14px; background-color:#E77471;">MAXIMUM</span>
| <span style="background-color: #d04437; border-radius: .25em; color: #ffffff; display: inline-block; font-weight: bold; margin: .1em 0; min-width: 6em; padding: .05em .5em; text-transform: uppercase; text-align: center;">MAXIMUM</span>
| > 10M USD.
| > 10M USD.
|-
|-
Line 278: Line 270:
==== Recording risk impacts ====
==== Recording risk impacts ====


The risk impact values in the RRA are the most important as the risk levels are directly derived from them.
As such, the risk impact values must be as accurate as possible.


The risk impact is solely sourced from the RRA when risk is calculated. Thus, the RRA risk impact is the most important
* Tell the team you're now going to look at the impact on the confidentiality, availability and integrity of the service.
value being recorded and must be as accurate as possible.
** Confidentiality is impacted if the data is leaked (all files zipped up and served on a public site).
 
** Availability is impacted if the service is no longer available (DDoS or malfunction, service unreachable).
* Tell the team you're now going to look at the impact on confidentiality, availability and integrity of the service.
** Integrity is impacted if the service's data is tampered with (records no longer show trustworthy data, site is defaced, etc.)
** Confidentiality is what happens if the data is leaked (all files zipped up and served on a public site).
* For each, look at how it affects Mozilla's reputation, productivity and finances.
** Availability is what happens if the service is no longer available (DDOS or malfunction, service unreachable).
** Integrity is what happens if the service data is tampered with (records no longer show trustworthy data, site is
defaced, etc.)
* For each, we'll look at how it affects Mozilla's reputation, productivity and finances.
** Reputation is our public image, both internal and external to Mozilla.
** Reputation is our public image, both internal and external to Mozilla.
** Productivity is our ability to work. If a team can't do their regular work, their productivity is affected.
** Productivity is our ability to work. If a team can't do their regular work, their productivity is affected.
** Finances represent the cost of an impact. For example, abusing an AWS account and running bitcoin-mining instances
** Finances represent the cost of an impact. For example, abusing an AWS account and running bitcoin-mining instances would cost us money.
would cost us money.
* For each row, there is a summary/reference built into the template that lets you know how the level is set.
* For each row, there is a summary/reference built-in the template that let you know how the level is set.


As you go through each row, ensure that the team understands which level you're selecting as impact and why.
As you go through each row, ensure that the team understands which impact level you're selecting and why.


For example:
For example:


Confidentiality=>Reputation HIGH impact would mean that Mozilla would get in tech. news (HN, Ars Technica, etc.)
* Confidentiality => Reputation HIGH impact would mean that Mozilla would get in tech news (HN, Ars Technica, etc.) if the data was leaked.
if the data was leaked.
* Confidentiality => Productivity MEDIUM impact would mean that some small Mozilla teams (SG) would be affected for more than 24 hours, or a large team (LG) for a few hours. If the impact on productivity is higher than LOW, it is possible that we incur financial impacts derived from work-force costs.
Confidentiality=>Productivity MEDIUM impact would mean that some small Mozilla teams (SG) would be affected for more than
24h, or a large team (LG) for a few hours.
If the impact on productivity is higher than LOW, it is possible that we occur financial impacts derived from work-force costs.


For each level, add a rationale on why the level was selected. Remember that anyone reading this
For each level, add a rationale on why the level was selected. Remember that anyone reading this
document will rely on your rationale and need to be able to understand why the level is selected. List affected teams
document will rely on your rationale and they will need to be able to understand why the level is selected. List affected teams
and their sizes, for how long for example.
, their sizes and the duration of the impact for example.




Line 317: Line 303:
Questions to ask:
Questions to ask:


* Is the service code peer-reviewed?
* Is the service's code peer-reviewed?
* Did the service get any kind of security review, modeling, pen-testing in the past?
* Did the service receive a security review, threat modeling or pen-testing in the past?
* Did the service suffer any security vulnerability in the past?
* Has the service suffered any security vulnerabilities in the past?
** Did any of the vulnerabilities get exploited or the service compromised?
** Did any of the vulnerabilities get exploited or was the service compromised?
* How confident are you that this impact may occur during the next year?
* How confident are you that this impact may occur during the next year?
* Are we aware of ongoing attacks on the service? (brute force attempts, DDoS, ...)
* Are we aware of current ongoing attacks on the service? (brute force attempts, DDoS, ...)


The estimated likelihood is then recorded as an estimated occurrence rate per calendar year.
The estimated likelihood is then recorded as an estimated occurrence rate per calendar year.
Line 328: Line 314:
==== Additional tips ====
==== Additional tips ====


* Whenever the productivity impact is HIGH or MAXIMUM, there probably also is a financial impact due to the cost of the workforce being impacted.
* Whenever the productivity impact is HIGH or MAXIMUM, there is probably also a financial impact due to the cost of the workforce being impacted.
* Financial risk is sometimes hard to define, in particular when tied to contracts.
* Financial risk is sometimes hard to define, in particular when tied to contracts.
** If no financial impact is clearly derived, it is OK to set the impact to LOW and rationale to "N/A".
** If no financial impact is clearly derived, it is OK to set the impact to LOW and rationale to "N/A".
** If there is still doubt, you may select "unknown" or "undefined" instead.
** If there is still doubt, you may select "unknown" or "undefined" instead.
* If you have any HIGH or MAXIMUM impact, you will want to propose the team to run a threat model and pen-test, every time.
* If you have any HIGH or MAXIMUM impacts, propose that a threat model and pen-test be run.
* Educate the project owners and/or lead developers of the project about the meaning of these risks and how the RRA can help them make decisions such as which operational environment to select, what technologies to use, or how much effort to put in securing the project.
* Educate the project owners and lead developers of the project about the meaning of these risks and how the RRA can help them make decisions such as which operational environment to select, what technologies to use, and how much effort to put into securing the project.


=== Recommendations (5 minutes) ===
=== Recommendations (5 minutes) ===


While the RRA is not meant for true security-review type work, recommendations do come up and this is a great time to
While the RRA is not meant as a complete review, recommendations do come up and this is a great time to
have a quick 5 minutes chat about these.
have a quick 5 minute chat about these.


* Ensure all recommendations that came up (from you or the team) are mentioned there. It's OK to fill this table as you go, too!
* Ensure all recommendations that came up (from you or the team) are mentioned here. It's also ok to fill this table as you go!
* List the control need (should this be prioritized?)
* List the control needed (should this be prioritized?)
* Ensure logging and access control have been mentioned. Can these be improved? Should we alert on events?
* Ensure logging and access control have been mentioned. Can these be improved? Should we alert on events?
* Does this service have an incident response scenario figured out?
* Does this service have an incident response plan defined?


=== Wrapping up ===
=== Wrapping up ===


* Estimate a security level provided by the service and set it in the RRA header at the top.
* Fill out the "Service Data Classification" field with the data classification of the most sensitive data type in the service. Exclude credentials for service access.
** A service that does not seem safe provides LOW security.
* Which recommendations are the team thinking of implementing ''(If no recommendations are implemented, you have very little impact)''
** A service that seem to follow best-practices provides MEDIUM security.
* Summarize the risk assessment table, the biggest impacts, and ask the team if the summary is what they expected.
** A service that put emphasis on security and uses stronger controls provides a HIGH security.
* Ask the team if there are any security concerns that they have, which have not been mentioned.
** A service that has been well reviewed via threat models, pen-tested, etc. and uses strong controls, privilege and
* Ensure you left no "red" fields blank (these are must-fill-in fields).
data separation provides a MAXIMUM security.
* Tell the team that you'll follow up with a risk-record, thank them for their time and you're done!
* Which recommendations do the team think of implementing ''(If no recommendations are implemented, you have very little impact)''
* Summarize the risk assessment table, the biggest impacts, and ask the team if that sounds like what they expected.
* Ask the team if there is any security concern that they have, which has not been mentioned.
* Ensure you left no "red" field blank (these are must-fill-in fields).
* Tell the team that you'll follow up with a risk-record, thanks them for their time, you're done!


=== Creating a risk record (post-work, 30 minutes) ===
=== Post work (30 minutes) ===


Create a risk record for the service: https://mana.mozilla.org/wiki/display/SECURITY/Risk+Records
* Go back and re-read the rationale fields and the recommendations in the RRA which were filled in and expand on them to ensure they capture the important parts of the discussion and can be understood by a reader of the RRA without the context of the conversation. These fields often initially lack good detail because they're being recorded in real time while the RRA is being run and the conversation is in progress.
* Create a risk record for the service: https://mana.mozilla.org/wiki/display/SECURITY/Risk+Records


== Reference documents ==
== Reference documents ==
Line 368: Line 350:
* http://en.wikipedia.org/wiki/ISO_31000
* http://en.wikipedia.org/wiki/ISO_31000
* http://www.riskmanagementinsight.com/media/docs/FAIR_introduction.pdf
* http://www.riskmanagementinsight.com/media/docs/FAIR_introduction.pdf
== RRA Links ==
* [https://mzl.la/2c4a09F Open RRA requests]
* [https://bugzilla.mozilla.org/enter_bug.cgi?product=Enterprise%20Information%20Security&component=Rapid%20Risk%20Analysis New RRA request]
* [http://mzl.la/1EmxXSU Open risk records]
* [http://mzl.la/1mJ1ldQ New risk record]
Gdestuynder
Confirmed users
502

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/1116997...1157647"