How to measure the security of a server

Several delivery and support processes are responsible for the security of systems. The art is to find no-brainer checks that are characteristic for a single process, that are able to separate secure from insecure implementations and that are distinctive. The latter means that there should be a reasonable percentage of servers that fails the test.

Each server is given a security score that is based on a dozen non-intrusive checks in the following categories:

  • (P) Patch management - a (visible) lag in software versions
  • (B) Blacklisted - presence on a blacklist of servers that distribute malware (not spam)
  • (S) SSL/TLS-configuration - weak encryption, expired certificate, etc.
  • (H) SSH-configuration - weak cryptokey
  • (W) Webserver configuration - unsafe HTTP-methods
  • (N) Nameserver configuration - zone transfer
  • (D) Design issues - logon over plain-text connections, etc.

At the beginning of the vulnerability assessment, every server is given a security score of 100 points. For each no-brainer encountered, points are subtracted. If a vulnerability can’t be assessed, no points are lost. Thus, the security score is based on falsification: it is assumed that the server is secure, unless proof of the opposite is found.

An example of the server scores are shown in figure 1. Each unique combination of an IP-address and a dns-name is called a ‘server’. The security scores are colored according to the traffic-light model. Green is OK (0 or 1 no-brainers found), red is high risk (5 or more no-brainers found). If a server cannot be connected to, no security score is given (blank).

Vulnerability assessment result
Figure 1. Example list of servers of an organization and their security score, derived from the no-brainer security check.

The underlying idea is that with a few checks a quick indication is obtained of possibly vulnerable servers. The security score itself is no hard evidence but is a risk indicator that gives raise to further investigation.

Next: 5 tips for a secure use of JavaScript libraries