Opens in a new tab

Security Rating Platform.

Enter URL for a free security rating

Why We Are Different

We are completely transparent in the way we do work. It is our ethos. We believe that our open book philosophy allows our clients to trust us.

In our opinion, ratings such as these come with inherent limitations. That is why any security ratings service you choose to use, should always be supplemented with a supplier security assessment.

We provide a description for each of the Loku-7 checks we perform, as well as the limitations that should be considered during the analysis of assessment results.

Results

Scan Summary

Details

The Loku7

The Loku7 Security Ratings Framework

Domain Associated with Malware: We check the domain you entered against a public repository of blocklisted domains that have indicated an association with malware. Failing this check indicates a domain may have been compromised. Limitation: False positives happen, it is a part of working with technology. Malware could also live un-detected by scanners and block-listed sources, something to bear in mind.

Sensitive Ports Exposed: We scan a set of well-known, common ports. This scan checks for sensitive services to indicate potential exposures that could lead to exploits and compromises. Limitation: We do not scan all 65,535 ports. Just because we didn’t detect an insecure Telnet service on Port 23 doesn’t mean it is not running on another port.

Weak Encryption: We check for weak SSL/TLS configurations that could indicate exposure to cryptographic attacks and man-in-the-middle vulnerabilities. Limitation: We always advocate a risk-based approach. For example, where the risk of users being unable to reach their service outweighs the risk of cryptographic attacks, it is a pragmatic risk-based decision and should be considered during the analysis of any negative results.

Server Header Exposures: We check the following header information; X-Frame-Options, X-XSS-Protection, Strict-Transport-Security, X-Content-Type-Options, Content-Security Policy and X-Provided-by. Overall, appropriately configured headers reduce exposures to CSS, HTTPS downgrade, injection and other type of attacks. Limitation: Appropriately configured raw headers is an indication of mature security practice, that said, when assessing low risk suppliers, especially where their website can be particularly static with limited web-presence requirements, it may not be a high risk finding.

Domain Spam Check: We check the mail server against DNS based block lists which, if returning a negative result, may indicate the email from the domain is considered spam. Limitation: Recovery from an event that caused the domain being block listed and considered spam is very difficult. While it indicates that preventative controls may have failed to lead to the event, having fully recovered may still return a spam result for a long-time post-incident.

SPF Policy: We check whether the SPF record is appropriately defined. Inappropriately set SPF record can lead to malicious entities sending email on behalf of that domain. Limitation: Not having an SPF record does not immediately assume a security risk, but certainly configuring an SPF record indicates greater security maturity.

DMARC: We check if the DMARC policy is appropriately set. The lack of any DMARC policy, or a policy configured to ‘none’ increases the exposure of attackers forging emails. Limitation: In general, there are 3 options for configuring a DMARC policy (‘none’, ‘quarantine’ and ‘reject’). Some security ratings services drop points for ‘quarantine’, we do not. A risk-based approach is always advocated. Quarantining emails may not be as definitive as complete rejection, however, should the risk of missing business or critical human safety emails outweigh the alternate risk, we consider this a pragmatic approach.