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).
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.