Firewalla Security Bug Reporting Process

Summary:

At Firewalla, we take software security very seriously. We understand that security breaches can have a devastating impact on our customers, and we are committed to doing everything we can to protect their data and privacy.

We use a variety of security measures to mitigate risks, including:

Secure code review, static code analysis, dynamic application security testing
Penetration testing
Continuously monitor our systems for security threats and vulnerabilities
Work closely with security researchers (individuals and organizations)

Security Exposure

We focus on security exposure, which is calculated as Risk Exposure = Likelihood of Threat × Impact of Threat. We identify and prioritize security risks based on the likelihood of a threat occurring and the potential impact of that threat.

In software engineering, risk exposure is a measure of the potential damage that could be caused by a security threat. It is calculated as the likelihood of the threat occurring multiplied by the impact of the threat.

Some quick examples:

A CRITICAL vulnerability in the Linux NVIDIA driver may have a critical impact, but the likelihood of threat is 0 (that piece of code is never used). So the risk exposure is 0.
A Javascript library may have a privilege escalation bug. Assume the likelihood of the threat is high, but the impact of the threat is 0 since all Firewalla processes are running with sudo access, so the risk exposure is 0.
An SSH DOS bug that’s classified as minor and very difficult to attack. Here the likelihood of the threat is low, and the impact of the threat is minor, so the risk exposure is LOW.

How we select what to fix:

When risk exposure is HIGH or MEDIUM, we will fix them in the next release.
When the risk exposure is LOW, we may or may not fix it. The development team will evaluate this.

Why not fix everything?

Software will always have bugs, and fixing software may also introduce new bugs (maybe even critical bugs). This is the reason we do extensive analysis and fully understand the problem upfront before digging in and fixing it.

Security Bug Reporting Process

Following the security bug reporting process ensures vulnerabilities are disclosed responsibly, preventing potential misuse by attackers before a fix is available. Posting security issues randomly can put users at risk, while this structured approach helps protect everyone by coordinating fixes and public disclosure.

1. Discover the Vulnerability

Can be done by anyone: security researcher, customer, etc.
If you run an automatic tool, please filter the output, we will not accept a “dump” directly from the tool. (We do acknowledge that tools are useful, but the number of false positives is very high.) What we need are the ones you know with a high possibility of an issue.

2. Report the Problem

Please DO NOT post it in public! (We will NOT respond to anything posted.) We may remove the post to prevent any potential harm to existing users.
Please send help@firewalla.com an email on this vulnerability; please include all details.
Please do include:

Description of the vulnerability
Steps to reproduce
Affected Firewalla Product
Additional technical information or proof of concept

3. Firewalla Confirms the Issue

The Firewalla team verifies the problem and starts working on a fix. Or, responds clearly on why the issue is “not” an issue, or if there is a PLAN or NO PLAN for a fix.
At this step, Firewalla may or may not agree with the severity of the security bug; but must provide an explanation.
Firewalla will reply in less than 2 business days.
Initial Investigation takes up to 7-14 days; Depending on the vulnerability type, this can be shorter or much longer.

4. Assign a CVE ID

Optional step from the submitter.

5. Create and Test Fix

The Firewalla Team develops a patch or workaround and tests it for effectiveness.

6. Plan Disclosure

The Firewalla Team and reporter agree on when to share details publicly, usually after the fix is ready.

7. Apply Fix

A software fix is deployed to the customer.
The Firewalla team will decide if it is needed to include the fix in the release notes.

8. Publish CVE Information (Optional)

The CVE is made public with details about the issue, affected versions, and fixes.

9. Monitor After Disclosure

The community watches for any problems with the fix or new related vulnerabilities.

FAQ:

You are using an older version of XYZ Linux package, why not update?

Firewalla is not a generic computer. The Firewalla team maintains the core packages required by the Firewalla software. If updates are needed (security, bugs), we will push upgrades/updates to fix them.

We strongly believe in deep analysis before doing any update/upgrade. If the Firewalla system does not need a feature update, it is not needed. Our goal is to make your firewalla secure, perform, and do what it is supposed to do.

If you need to update, please see https://help.firewalla.com/hc/en-us/articles/4406630307091-How-to-manually-upgrade-Linux-package-on-your-Firewalla-box