WARNING! Gitlab maintenance operation scheduled for Thursday, 18 June between 19:00 and 20:00 (CET). During this time window, short service interruptions (less than 5 minutes) may occur. Thank you in advance for your understanding.
<mark>Editor's Note: The EC advises that the references between verticals should be informative.</mark>
@@ -2355,30 +2357,73 @@ Exlcuding eliminated threats, the final landscape of applicable cybersecurity th
Risk analysis builds on the output of the Threat Modeling process to determines the risk level of the product and to provide visibility into the causes and sources of risk. Risk analysis consists of the following steps:
- For each reduced, transfered, or accepted threat, risk factors are identified and calculated. Risk factors are product-specific characteristics that influence the likelihood of a threat materializing or the impact it would produce. Risk factors may include for example: operational context, architectural choices, attack surface exposure, control presence and effectiveness, data sensitivity, update latency, and third party component integration and dependencies. Each risk factor value is based on its influence over threat likelihood or threat impact and assigned quantitatively based on a numerical scale from 1 (lowest) to 10 (highest). Each scoring is accompanied by documented rationale for the assigned value, which shall reflect the product's risk profile as deployed in its intended context, not in isolation. The output of this step is a list of risk factors categorized as influencing either likelihood or impact and scored separately. The likelihood value for each threat is then set equal to the average score among all its likelihood-related risk factors, and the impact value is set equal to the average score among all its impact-related risk factors.
- The risk level of each threat is calculated as the function of its average likelihood and impact values.
- The product risk level is determined by the highest individual threat risk level across all identified applicable threats. This reflects the inherently high-risk nature of browsers' operational environment and the idea that a browser's overall risk level is better expressed trough its worst-case threat exposure and not its average. The product risk level is considered low when the threat risk level is between 1-25/100, medium when it's between 26-50/100, and high when it's between 51-100/100.
For each reduced, transfered, or accepted threat, manufacturers shall assign a "likelyhood" value and an "impact" value. "Likelyhood" refers to a reasoned estimate for the possibility of a specific threat materializing, while "Impact" refers to the reasonably estimated degree of damage, disruption, and loss suffered if the threat were to materialize. When estimating the likelyhood and impact of a given threat, manufacturers shall identify and assign risk factor values. The OWASP Risk Rating Methodology [\[i.20\]](#_ref_i.20) defines risk factors as characteristics that influence the likelyhood and the impact of a threat, and provide a set of risk factors reported here below.
Below is an example of a risk analysis given four identified threats: Cross-origin separation failure, Capability escalation through permissioned surfaces, OS / kernel compromise below browser controls, and Passive or active network attack.
For this mock risk analysis, the following risk factors, where applicable, were considered:
| T1 | Cross-origin separation failure | Reduced | Attack surface exposure (9) — Web browsers are exposed to untrusted web content / Architectural choices (7) — Spectre-like attacks often undermine process isolation even when implemented correctly. / Third-party component dependencies (7) — GPU process is third-party-derived and historically prone to type confusion and memory corruption attacks. | **7.7** | Data sensitivity (9) — Data stored in user browser profile is highly sensitive. / Control presence and effectiveness (5) — Site isolation, COOP/COEP headers, partially mitigate the threat but do not eliminate it. / Architectural choices (6) — A multi-process architecture is employed to reduce threat exposure but some remaining architectural trust assumptions leave residual risk.| **6.7** | **51.6** | High |
| T2 | Capability escalation through permissioned surfaces | Reduced | Attack surface exposure (8) — Web browsers expose various powerful feature APIs. / Operational context (7) — Users often grant broad permissions without clearly understanding scope and duration of expressed consent. Additionally, permissions persist across sessions, often shared by mutliple users, compounding exposure. / Third-party component dependencies (7) — Web browser extensions and embedded third-party code operate with high privilages within the browser context, representing an important attack vector. Additionally, extensions may abuse powerful features, leading to function creep and increasing threat exposure. | **7.3** | Data sensitivity (8) — Escalated capabilities can expose sensitive user data, including geolocation, device hardware, local file system contents, and persistent device identifiers. / Control presence and effectiveness (5) — Express user consent is mediated through permission prompts, but users often lack full visibility into granted permissions and may in general maintain an insufficient level of cyber hygiene given the risks of powerful features and permissioned surfaces. / Architectural choices (4) — No permission life span is enforced by default and the user is not prompted to expres consent at the start of every session. | **5.7** | **41.6** | Medium |
| T3 | OS / kernel compromise below browser control | Accepted | Operational context (5) — Not a direct browser attack vector. / Third-party component dependencies (6) — Web browsers rely entirely on the host OS for a number of functionalities outside web browser control. / Attack surface exposure (4) — A local kernel compromise would need to defeat architectural web browser isolation. | **5.0** | Data sensitivity (10) — A kernel-level compromise would grant attackers access to all browser state, credentials, private keys, user profile, and memory contents. / Control presence and effectiveness (2) — No browser confinement can meaningfully limit impact once the underlying OS is compromised. / Architectural choices (3) — Web browser sandboxing relies on OS primitives and defence-in-depth therefore stops at the OS boundary. | **5.0** | **25.0** | Low |
| T4 | Passive or active network attack | Accepted | Operational context (6) — Users often access untrusted web content via untrusted public networks (Shared residential networks, Public WiFis, etc.). / Control presence and effectiveness (3) — Most default configurations (TLS 1.3, HSTS preloading, certificate transparency, HTTP-to-HTTPS force-redirect drastically reduce likelihood of such attacks. / Attack surface exposure (4) — Some residual plaintext exposure remains (including unencrypted DNS queries, HTTP traffic, etc.). | **4.3** | Data sensitivity (6) — Intercepted traffic may contain session tokens, credentials, OTPs, as well as other plaintext sensitive user information. / Control presence and effectiveness (4) — Existing cryptographic controls effectively protect the majority of traffic from interception and network attacks, and residual risk is limited to legacy protocols or misconfigured endpoint. / Architectural choices (3) — State of the art architectural choices actively and substantially reduce impact. | **4.3** | **18.5** | Low |
Assuming the worst-case threat actor:
- Skill Level: How technically skilled is this group of threat agents? No technical skills (1), some technical skills (3), advanced computer user (5), network and programming skills (6), security penetration skills (9);
- Motive: How motivated is this group of threat agents to find and exploit this vulnerability? Low or no reward (1), possible reward (4), high reward (9);
- Opportunity: What resources and opportunities are required for this group of threat agents to find and exploit this vulnerability? Full access or expensive resources required (0), special access or resources required (4), some access or resources required (7), no access or resources required (9);
- Size: How large is this group of threat agents? Developers (2), system administrators (2), intranet users (4), partners (5), authenticated users (6), anonymous Internet users (9).
#### Vulnerability Factors
Assuming the threat actor considered above:
- Ease of Discovery: How easy is it for this group of threat agents to discover this vulnerability? Practically impossible (1), difficult (3), easy (7), automated tools available (9);
- Ease of Exploit: How easy is it for this group of threat agents to actually exploit this vulnerability? Theoretical (1), difficult (3), easy (5), automated tools available (9);
- Awareness: How well known is this vulnerability to this group of threat agents? Unknown (1), hidden (4), obvious (6), public knowledge (9);
- Intrusion Detection: How likely is an exploit to be detected? Active detection in application (1), logged and reviewed (3), logged without review (8), not logged (9).
### 2.2 Factors for Estimating Impact
#### Technical Impact Factors
Final **Product risk level**: **High (51.6/100)**
- Loss of Confidentiality: How much data could be disclosed and how sensitive is it? Minimal non-sensitive data disclosed (2), minimal critical data disclosed (6), extensive non-sensitive data disclosed (6), extensive critical data disclosed (7), all data disclosed (9);
- Loss of Integrity: How much data could be corrupted and how damaged is it? Minimal slightly corrupt data (1), minimal seriously corrupt data (3), extensive slightly corrupt data (5), extensive seriously corrupt data (7), all data totally corrupt (9);
- Loss of Availability: How much service could be lost and how vital is it? Minimal secondary services interrupted (1), minimal primary services interrupted (5), extensive secondary services interrupted (5), extensive primary services interrupted (7), all services completely lost (9);
- Loss of Accountability: Are the threat agents’ actions traceable to an individual? Fully traceable (1), possibly traceable (7), completely anonymous (9).
#### Business Impact Factors
- Financial damage: How much financial damage will result from an exploit? Less than the cost to fix the vulnerability (1), minor effect on annual profit (3), significant effect on annual profit (7), bankruptcy (9);
- Reputation damage: Would an exploit result in reputation damage that would harm the business? Minimal damage (1), Loss of major accounts (4), loss of goodwill (5), brand damage (9);
- Non-compliance: How much exposure does non-compliance introduce? Minor violation (2), clear violation (5), high profile violation (7);
- Privacy violation: How much personally identifiable information could be disclosed? One individual (3), hundreds of people (5), thousands of people (7), millions of people (9).
Each risk factor value is based on its influence over threat likelihood or threat impact and assigned quantitatively based on a numerical scale from 1 (lowest) to 9 (highest). Each scoring is accompanied by documented rationale for the assigned value, which shall reflect the product's risk profile as deployed in its intended context, not in isolation. The output of this step is a list of risk factors categorized as influencing either likelihood or impact and scored separately. The likelihood value for each threat is then set equal to the average score among all its likelihood-related risk factors, and the impact value is set equal to the average score among all its impact-related risk factors.
The risk level of each threat is then calculated as the function of its average likelihood and impact values.
The product risk level is determined by the highest individual threat risk level across all identified applicable threats. This reflects the inherently high-risk nature of browsers' operational environment and the idea that a browser's overall risk level is better expressed through its worst-case threat exposure and not its average. The product risk level is considered low when the threat risk level is between 1-25/81, medium when it's between 26-50/81, and high when it's between 51-81/81.
Below is an example of a risk analysis given four identified threats: Cross-origin separation failure, Capability escalation through permissioned surfaces, OS / kernel compromise below browser controls, and Passive or active network attack.
|| Threat ID | Threat | Disposition | Likelihood Factors | L Score | Impact Factors | I Score | Risk (L×I) /81 | Risk Level |
|---|---|---|---|---|---|---|---|---|
| T1 | Cross-origin separation failure | Reduced - The identified threat has been reduced due to implementation of state of the art architectural choices that directly mitigate cross-origin separation failure. | **Threat agent:** Skill level (9) — Exploiting cross-origin isolation failures requires advanced vulnerability research skills and security knowledge. This analysis identifies the worst-case threat actor as posessing these skills. / Motive (9) — Access to cross-origin data represents high reward. / Opportunity (7) — The threat actor requires some access and resources. / Size (9) — Any malintentioned internet user can attempt to serve malicious content on the web. **Vulnerability:** Ease of discovery (7) — Vulnerabilities that allow for Spectre-like attacks are well-documented, meaning that the effort required to find them is moderate. / Ease of exploit (5) — Non-trivial but achievable. / Awareness (9) — The vulnerabilities that this threat exploits is well-researched and documented. / Intrusion detection (8) — Browser-level cross-origin exploitation is typically not logged or reviewed in standard browser deployments. | **7.9** | **Technical:** Loss of confidentiality (9) — Successful exploitation would expose all same-process origin data including session tokens, and credentials. / Loss of integrity (3) — Cross-origin reads and, although less likely, data corruption. / Loss of availability (1) — Exploitation does not inherently disrupt service availability. / Loss of accountability (9) — Completely anonymous. **Business:** Financial damage (7) — Loss of sensistive information including credentials and session data can lead to significant financial impact. / Reputation damage (9) — Severe brand and trust incident if exposed to the public. / Non-compliance (7) — Exfiltration of sensitive user data likely constitutes a high-profile GDPR violation. / Privacy violation (9) — Likely to affect millions of users. | **6.8** | **53.6** | High |
| T2 | Capability escalation through permissioned surfaces | Reduced - The identified threat has been reduced due to existing security controls that directly address it. | **Threat agent:** Skill level (6) — The worst-case threat actor identified is estimated to have network and programming skills / Motive (9) — Access to powerful features represents high reward. / Opportunity (7) — Threat actor would need aither a malicious extension or web page accepted by the user, or compromise a developer's account for an already-existing extension. / Size (9) — The threat actor group extends to anonymous Internet user. **Vulnerability:** Ease of discovery (7) — Permission abuse vectors are well-documented and web browser extensions have been widely leveraged as attack vectors due to their privileged state within the web browser execution context. / Ease of exploit (5) — Social engineering users into granting permissions is fairly straightforward. / Awareness (9) — Widely documented and research threat. / Intrusion detection (8) — Permission use is not systematically logged or reviewed at the browser level. | **7.5** | **Technical:** Loss of confidentiality (9) — Escalated permissions can expose highly sensitive data including precise geolocation, file system contents, biometric data, and persistent device identifiers. / Loss of integrity (3) — This threat is primarily used as an exfiltration vector and integrity impact is limited unless file system write access is abused. / Loss of availability (1) — This threat does not inherently impair service availability. / Loss of accountability (7) — Permission grants are tied to origins, not individuals, making confident attribution very unlikely. **Business:** Financial damage (7) — Large-scale exfiltration of user data has severe financial consequences. / Reputation damage (9) — If publicly reported it would cause severe brand and reputational damage. / Non-compliance (7) — Likely high-profile violation of GDPR and other regulatory frameworks. / Privacy violation (9) — Would likely affect millions of users across a widely deployed web browser product. | **6.5** | **48.8** | Medium |
| T3 | OS / kernel compromise below browser control | Accepted - The identified threat has been accepted as is. | **Threat agent:** Skill level (9) — Kernel-level exploitation requires elite security penetration skills. This analysis identifies the worst-case threat actor posessing these skills as primarily nation-state actors. / Motive (9) — Full access to browser state, credentials, and memory represents a high reward. / Opportunity (4) — Special access or resources required; Threat actor must exploit a OS vulnerability before reaching kernel level. / Size (2) — Realistically limited to highly resourced elite threat actors and not achievable by the general anonymous internet user. **Vulnerability:** Ease of discovery (3) — Kernel vulnerabilities are difficult to discover. / Ease of exploit (3) — Kernel exploits are difficult to develop and successfully use reliably. / Awareness (6) — Kernel attack techniques against browser sandboxes are documented but not easily accessible. / Intrusion detection (8) — Kernel-level compromise is unlikely to be detected and may likely be missed unless careful logging and review is done routinely. | **5.5** | **Technical:** Loss of confidentiality (9) — Kernel access exposes all browser memory, credentials, private keys, and user profile data without restriction. / Loss of integrity (9) — An threat actor with kernel access can modify any browser process, inject code, or alter stored data arbitrarily. / Loss of availability (7) — Kernel compromise can lead to unavailability of browser services. / Loss of accountability (9) — Unlikely to be confidently traceable to a specific threat actor or individual. **Business:** Financial damage (9) — Would likely result in catastrophic financial impact. / Reputation damage (9) — A publicly reported OS-level browser compromise would constitute a severe incident, resulting in high brand and reputational damage. / Non-compliance (7) — Would likely result in regulatory risk. / Privacy violation (9) — Impact would be as broad as the web browser's user base. | **8.5** | **46.8** | Medium |
| T4 | Passive or active network attack | Accepted - The identified threat has been accepted as is. | **Threat agent:** Skill level (6) — The worst-case threat actor identified is estimated to have network and programming skills. / Motive (4) — Possible credential and session token interception has value. / Opportunity (7) — Some access or resources is required and the threat actor needs to be on the same network. / Size (9) — Any anonymous internet user in a network-adjacent position. **Vulnerability:** Ease of discovery (7) — Moderately easy to identify with standard tooling. / Ease of exploit (5) — Complicated by widely adopted encryption but less protected resources remain vulnerable. / Awareness (9) — Extensively documented and tooled. / Intrusion detection (8) — Passive interception doesn't appear in application logs, while active injection may be detectable through anomaly detection systems. | **6.9** | **Technical:** Loss of confidentiality (7) — Intercepted traffic can expose session tokens, credentials, and OTPs if unencrypted, while encrypted traffic can reveal metadata. / Loss of integrity (5) — Threat actors may intercept and inject malicious content into unencrypted HTTP responses. / Loss of availability (1) — Does not directly affect service availability from the browser's perspective. / Loss of accountability (9) — No application-layer trace, thus completely anonymous and difficult to attribute. **Business:** Financial damage (3) — Impact is bounded by the fraction of traffic not protected by TLS and therefore likely minor given current TLS adoption statistics. / Reputation damage (4) — A network interception incident affecting browser users would likely cause moderate reputational damage. / Non-compliance (5) — Might result in a clear but not high-profile compliance violation. / Privacy violation (7) — Could affect all users on the shared network infrastructure, potentially thousands. | **5.1** | **35.2** | Medium |
