Why The Public Sector Will Never Support Bug Bounties

Would you believe there are some public sector sites that are still running SSL v2? This protocol version is completely riddled with holes…

Why The Public Sector Will Never Support Bug Bounties

Would you believe there are some public sector sites that are still running SSL v2? This protocol version is completely riddled with holes and could open up the private keys used by a site. Overall it leaves a web site vulnerable to BEAST, FREAK, POODLE DROWN, and lots of downgrade attacks.

Leading companies such as Google and Microsoft have an active bug bounty scheme, and public sector sites should do the same. Unfortunately many public sector Web site are in poor state, and could be at a great risk of exposing citizen data. One must wonder why the public sector does not put more in place of actively scans their sites, as many of the vulnerabilities would be spotted by a simple scan from an external tool. Surely there must be weekly threat reports on the externally facing web sites?

If they supported bug bounties, many of their problems would be almost instantly fixed, as most of them are simple fixes. But as there are so many problems, a bug bounty would actually be extremely costly to put in-place.

There is often a drive by governments to transform public services in countries, but one must wonder if something gets lost along the way. For a few days I implemented a Python script which calls up the SSL Labs tool and assesses the cryptography on a range of sites.

The results for public sectors that I sample were poor in places, with many sites actually failing. A common grade is a “T” grade, which defines that the site has mismated certificates, and which do not match the name of the site. But even if the certificate is fixed, there were a few which did not come near getting an “A” rating:

But the great worry is that some of the servers gain an “F” grade and which is open to DROWN, FREAK, POODLE and MITM attacks:

This above site still supports SSL v2 and SSL v3, and which NEVER should be supported, as they are highly vulnerable. Basically it breaks every rule in the book, and is completely unpatched.

As a minimum, I believe that all public sector sites should, as a minimum, should match to the following:

  • NEVER NEVER NEVER EVER support SSL v2 or SSL v3. A Web site running these should be shut down immediately!
  • Gain an A grade from an SSLabs scan, with sites containing citizen data, focusing on gaining an A+ grade. To gain an A+ grade sites should support X-header integration.
  • Should NOT support the export of 512-bit export suites, as 512-bit Diffie-Hellman keys have been long cracked.
  • Should NOT support 1,024 bit RSA key or less.
  • Should pass a Google Chrome test for trust.
  • Should aim to switch off HTTP support, and redirect fully to HTTPs.
  • Should NOT support TLS 1.0.
  • Should have a matched certificate.
  • Should never support legacy cryptographic, including RC4, DES and MD5.
  • Must have scanned, at least, every week with standard OWASP tools.
  • Must be scanned, at least, every each for cryptography reports.
  • Have migration paths for TLS 1.3.

There should be a dashboard provided by government, and which defines KPIs for the security of Web sites, and which should report on the matching against these KPIs. Otherwise, how are we to properly build new digital services for the public sector, without even getting to the first base?

We need an investment in digital services for the public sector, and it needs to happen soon. This includes training on the most simplest of security scanning, and improved reporting.