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

sub-services belong to different teams, it is a strong indicator that multiple RRAs should be run.

* 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.

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).

* 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:

** Running through the risk table and figuring out what happens if the data is leaked, modified, unavailable, etc - while assigning the standard risk levels.

** Writing down any recommendations for the service.

* Ask the team who owns the service (for example the team that makes decisions if the service must go down), who develops the code and who's operating it.

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

* Where is it running? On which platforms?

* Any URLs to access the service?

** Software source code/scripts (such as if the code is stored on a Git repository, downloaded and ran by the service).

** For example "User attributes, classified INTERNAL, protected by LDAP authentication, used to find out the user's t-shirt size".

This is where the risk impact assessment is done, and where the probability for these impacts is roughly estimated.

| Articles in technical websites such as Hacker News, Ars-Technica, etc. are seen.

| Scandal. National and international news outlets report on the event.

* Tell the team you're now going to look at the impact on the confidentiality, availability and integrity of the service.

** 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).

** Integrity is impacted if the service's data is tampered with (records no longer show trustworthy data, site is defaced, etc.)

* For each, look at how it affects Mozilla's reputation, productivity and finances.

** Finances represent the cost of an impact. For example, abusing an AWS account and running bitcoin-mining instances would cost us money.

* For each row, there is a summary/reference built-in the template that lets you know how the level is set.

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

* Confidentiality => Reputation HIGH impact would mean that Mozilla would get in tech news (HN, Ars Technica, etc.) if the data was leaked.

* 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 incur financial impacts derived from work-force costs.

document will rely on your rationale and they will need to be able to understand why the level is selected. List affected teams

, their sizes and the duration of the impact for example.

* Did the service receive a security review, threat modeling or pen-testing in the past?

* Has the service suffered any security vulnerabilities in the past?

** Did any of the vulnerabilities get exploited or was the service compromised?

* Are we aware of current ongoing attacks on the service? (brute force attempts, DDoS, ...)

* Whenever the productivity impact is HIGH or MAXIMUM, there is probably also a financial impact due to the cost of the workforce being impacted.

* If you have any HIGH or MAXIMUM impacts, propose that a threat model and pen-test be run.

* 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.

While the RRA is not meant as a true security-review, recommendations do come up and this is a great time to

have a quick 5 minute chat about these.

* 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 needed (should this be prioritized?)

* Does this service have an incident response plan defined?

** A service that puts an emphasis on security and uses stronger controls provides HIGH security.

** A service that has been well reviewed via threat modeling and penetration testing, uses strong security controls, and has good privilege and data separation provides MAXIMUM security.

* Which recommendations are the team thinking 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 the summary is what they expected.

* Ask the team if there are any security concerns that they have, which have not been mentioned.

* Ensure you left no "red" fields blank (these are must-fill-in fields).

* Tell the team that you'll follow up with a risk-record, thank them for their time and you're done!