The situation
A regional software company serving government offices across 12 US states was facing a hard deadline: their cyber insurance renewal was contingent on improving their SecurityScorecard rating. Their score at the start of the engagement was 53 out of 100 — an F.
Their IT team was small, their infrastructure was sprawling, and the findings in the SecurityScorecard report were dense and technical. They needed help fast.
We scanned their external infrastructure using Kaspera Shield and got to work.
What the scan found
The SecurityScorecard report identified issues across several categories. Here is what was actually there when we looked under the hood.
TLS weak protocol (-10.3 points)
Thirteen external-facing IPs were still accepting TLS 1.0 and TLS 1.1 connections — protocols that have been deprecated since 2020. These older protocol versions are vulnerable to attacks like POODLE and BEAST, and most compliance frameworks and insurers now treat their presence as a critical finding.
Weak cipher suites (-5.2 points)
The same servers were supporting 3DES cipher suites, which are vulnerable to the SWEET32 birthday attack. 3DES was deprecated by NIST in 2019.
Apache CVEs (58 findings across multiple scoring categories)
The company's primary web server was running Apache HTTP Server 2.4.52. SecurityScorecard detected 58 CVEs against it — including several from 2024 and 2025. The findings spanned critical, high, and medium severity categories.
nginx CVEs (7 findings)
A separate Linux server running nginx 1.18.0 had 7 known CVEs flagged, including CVE-2021-3618 (ALPACA attack), CVE-2022-41741, CVE-2022-41742, and CVE-2024-7347.
Missing security headers (multiple categories)
Across 15+ web properties — including production portals, internal tools, file sharing servers, and a video platform — security headers were either missing or misconfigured. Findings included missing Content-Security-Policy, missing X-Content-Type-Options, missing HSTS, and HSTS max-age values that were too short.
FTP exposed publicly (-2.0 points)
Port 21 was accessible from the public internet on a dedicated FTP server. FTP transmits credentials in plaintext and is a well-known attack vector.
DNS server accessible (-2.7 points)
Port 53 was externally accessible on one of their servers, flagging a potential DNS amplification or zone transfer risk.
How we fixed it
TLS remediation
The first challenge was mapping which external IPs corresponded to which internal servers. The company used two ISPs and had multiple servers behind NAT, each with their own external IP.
We built an accurate external-to-internal IP map using DNS lookups, internal IP resolution, and outbound IP checks from inside each server via RDP. Once mapped, we applied IIS Crypto's Best Practices template to each Windows Server — disabling TLS 1.0, TLS 1.1, SSL 2.0, SSL 3.0, RC4, DES, and 3DES, while keeping TLS 1.2 fully enabled with strong cipher suites.
A full server reboot was required for the registry changes to take effect. We coordinated reboots outside business hours to minimize impact on county government staff using the portals.
After reboots, we verified the fixes by running nmap ssl-enum-ciphers against all 13 flagged external IPs from an independent external server. Every IP returned TLS 1.2 only — TLS 1.0 and 1.1 were completely absent from the cipher negotiation output. We provided this output to the insurance company as external, third-party verification.
Apache and nginx CVEs
This is where understanding how Linux package management works matters.
The Apache server was running version 2.4.52 — the version string that SecurityScorecard flagged against 58 CVEs. However, the server was running Ubuntu 22.04 LTS, which backports security patches without changing the version number.
We inspected the installed package version and Debian changelog, which confirmed that every single CVE in the SecurityScorecard report — including 2025 CVEs like CVE-2025-23048, CVE-2025-49630, CVE-2025-58098, and CVE-2025-53020 — had been backported and patched. SecurityScorecard was fingerprinting the version string and assuming the worst. The actual code had all the fixes applied.
The same was true for nginx: version 1.18.0-6ubuntu14.8 had backported patches for CVE-2021-3618, CVE-2022-41741, CVE-2022-41742, and CVE-2024-7347 — confirmed via changelog inspection.
We submitted these findings through SecurityScorecard's remediation portal with documentation that Ubuntu LTS backports security patches without changing the upstream version string, and that the installed package version confirmed the patches were applied.
Security headers
This was the most time-consuming part — not because any individual fix was hard, but because headers needed to be added across 15+ servers running different technology stacks: IIS on Windows Server, Apache on Ubuntu, nginx on Ubuntu, and Synology DSM's built-in nginx.
For each IIS server, we added headers at the server level via IIS Manager. For Apache, headers were added via the server's security configuration file. For the Synology NAS serving multiple subdomains — files, wiki, docs, video — we added a persistent custom configuration that survives DSM updates, and added headers directly to the reverse proxy server blocks for each subdomain.
The header set applied across all servers:
- Strict-Transport-Security: max-age=31536000; includeSubDomains
- X-Frame-Options: SAMEORIGIN
- X-Content-Type-Options: nosniff
- Referrer-Policy: strict-origin-when-cross-origin
- Permissions-Policy: geolocation=(), microphone=(), camera=()
- Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval' data: blob: https:;
FTP and DNS
The DNS finding had already been resolved by the time we verified — a firewall rule had been added blocking port 53 externally, confirmed via external port scan.
For FTP, the server turned out to be running IIS 10 on Windows Server 2019 — not IIS 7.5 as SecurityScorecard had fingerprinted from the banner. The associated CVEs were false positives from version detection on an already-suppressed banner. The underlying finding — port 21 publicly exposed — is being addressed via a firewall IP allowlist restricting FTP access to known client IPs only.
Results
Starting score: 53/100 (F) Projected score after rescan: 70-80+ (B)
Key score impacts addressed:
- TLS weak protocol: +10.3 points
- TLS weak cipher suites: +5.2 points
- Security headers across 15+ servers: +3-5 points
- 58 Apache CVE findings submitted for remediation
- DNS server finding resolved: +2.7 points
Total timeline: under one week of active remediation.
What this means for your business
SecurityScorecard scores are increasingly used by insurers, enterprise procurement teams, and clients as a proxy for security posture. A failing score can affect your ability to renew coverage, win contracts, or pass vendor security reviews.
The good news: most of what moves the score is not exotic. It is configuration — TLS versions, cipher suites, security headers, patching cadence. These are findable and fixable.
The pattern we see repeatedly is that organizations are not insecure because they made bad decisions. They are insecure because the issues accumulated quietly while the team was focused on building product and serving clients. Nobody was watching the external attack surface.
Kaspera Shield scans your external infrastructure, identifies the findings, and helps you understand exactly what needs to change. If you need hands-on remediation support, we can help with that too.
Run a free security assessment to see where you stand — before your insurer, a client, or an attacker tells you.
