Trust is a well-understood concept each of us uses in our daily lives. This concept helps us by reducing the need to verify every piece of information we receive because the source of that information is trustworthy. We can apply the same kind of logic to information security. Deploying such trust-based models - with appropriate verification - shows great results in improving the security posture of any organization.
Certificate whitelisting is a trust-based security model. If the certificate signer is a trusted party, all content it is signing should also be trustworthy. Depending on the trust we have in the signer, we can opt to trust-but-verify, or to trust implicitly. Both are equally valid when building a secure environment. In fact, implicit trust enables implementation of our most advanced heuristic that detects the most advanced malware attacks, while avoiding the accompanying nightmare that is a high rate of false positives.
Trust-but-verify is a healthy default to have deployed. When applied to certificates, it simply states that any file signed by a trusted party will be considered clean if and only if it is not found to contain any embedded malicious components.
Such logic is sound, and can be used to tackle supply chain attacks where a trusted party infrastructure is compromised and is used to serve malicious content. These types of attacks are infrequent, but devastating when they happen to a commonly deployed piece of software.
Therefore, it is critical to have a system that can inspect every piece of code deployed via software installation packages. ReversingLabs static analysis engine employs advanced file decomposition that unpacks software packages, and can detect such supply chain attacks early in the attack cycle.
Implicit trust also has its place. When applied to certificates, it simply states that any file signed by a trusted party, including the files it embeds, will be considered clean. While not a perfect default, it can be used in parallel with more advanced malware detection techniques to yield better malware detection results while suppressing possible false positives.
Implicit trust is not a solution that can (or that should be) applied to every party we trust. Certain organizations have a proven record, which is why they can be implicitly trusted. In the real world, a certificate-based trust model is a healthy mix of implicit trust and trust-but-verify approaches.
We ship all ReversingLabs solutions in trust-but-verify mode. However, we do believe that every organization should have the power to fine-tune our trust-based models to meet their needs and even enforce implicit trust if the need arises.
ReversingLabs solutions make complex topics, such as trust-based models, easy to implement and understand. The trust we assign to any party can be boiled down to a single number that indicates the level of trust we have in the party. This number is called the trust factor. The lower the number, the higher the trust we have in the party. The best possible trust factor is zero, and the worst is five. Every certificate in our user-customizable whitelist has a trust factor assigned to it.
It is this number - trust factor - that allows us to deploy trust-but-verify and implicit trust models in parallel. Selecting a threshold value lets us separate the two zones. Everything below the threshold would be considered implicitly trusted, and everything above the threshold should be trusted if all checks for malware find nothing troubling.
| TRUST FACTOR | DESCRIPTION |
| High trust zone Values: [0, 1] |
Every digital certificate in this zone refers to a party with highest publishing standards. These parties usually have fine-grained internal security controls and detailed verification checks prior to package, application, or document public release. There is a proven track record for these parties which involves no malicious incidents in the recent past. |
| Medium trust zone Values: [2] |
Every digital certificate in this zone refers to a party that is commonly seen in the organization, but that party doesn’t necessarily have the highest publishing standards. When discussing software installations, this zone is usually limited to shareware authors. There is a proven track record for these parties which involves no malicious incidents in the recent past. |
| Low trust zone Values: [3, 4] |
Every digital certificate in this zone refers to a party that is not commonly seen in the organization, and that party doesn’t have a clear set of defined security controls (or is not expected to have them). When discussing software installations, this zone is usually limited to open source authors. There is a proven record for these parties, or there has been some minor incidents in the past. |
| No trust zone Values: [5] |
Generally not used, as there is no reason to add any non-trusted parties to the certificate whitelist. |
Based on the clear division between the trust zones, it is recommended to draw the line between trust-but-verify and implicit trust at the medium trust zone. Implicit trust propagates downwards to all files extracted from the analyzed package. Trust propagation automatically suppresses any false positives that may be introduced in the system by the more advanced malware detection techniques. It's important to note that none of the classification alerts are actually lost, as they are reported but not taken into consideration when deciding the final classification the package should have.
But, not every certificate is made equal. Since certificates employ cryptography to keep the content of the envelope safe, it is important that the algorithm used is considered safe by today's standards. The same applies to the strength of cryptographic hash functions that help us verify the integrity of the content they are signing.
If either of the two is considered weak, the trust we assigned to the party must be changed to reflect that. Our certificate whitelisting system does this automatically by increasing the trust factor value of such files by one point.
This can make a big difference, because it can change the zone bracket for the trusted party. Combined with the implicit trust zone line, it can convert the party from implicitly trusted to trust-but-verify. This makes perfect sense, as less secure packages should be inspected with greater attention.
ReversingLabs maintains a sizable list of trusted parties in its certificate whitelist. While our default is trust-but-verify, the list is curated in such a way that implementation of the desired implicit trust model is a mere deployment choice. The list itself is transparent and made visible to all of our partners and customers so that it can be modified based on their needs.
This article is the 2nd part of our Digital Certificates series of blogs. Read other blogs in this certificate series:
