Overview#
TLS Maturity Model has five levels, which range from utter chaos in Level 1 to a Level 5 which is probably more security than is necessary for most mere mortals.
Level 4 is were most organizations will want to be, Ristic said.
Here is the model as he described in this post:
- level 1 - there is chaos. Because you don't have any policies or rules related to TLS, you're leaving your security to chance (e.g., vendor defaults), individuals, and ad-hoc efforts generally. As a result, you don't know what you have or what your security will be. Even if your existing sites have good security, you can't guarantee that your new projects will do equally well. Everyone starts at this level.
- Level 2 - configuration, concerns itself only with the security of the TLS protocol, ignoring higher protocols. This is the level that we spend most time talking about, but it's usually the easiest one to achieve. With modern systems, it's largely a matter of server reconfiguration. Older systems might require an upgrade, or, as a last resort, a more secure proxy installed in front of them.
- Level 3 - application security, is about securing those higher application protocols, avoiding issues that might otherwise compromise the encryption. If we're talking about websites, this level requires avoiding mixing plaintext and encrypted areas in the same application, or within the same page. In other words, the entire application surface must be encrypted. Also, all application cookies must be secure and checked for integrity as they arrive in order to defend against cookie injection attacks.
- Level 4 - commitment, is about long-term commitment to encryption. For web sites, you achieve this level by activating HTTP Strict Transport Security (HSTS), which is a relatively new standard supported by modern browsers (IE support coming in Windows 10). HSTS enforces a stricter TLS security model and, as a result, defeats SSL stripping attacks and attacks that rely on users clicking-through certificate warnings.
- level 5 - robust security, you're carving out your own private sliver of the PKI cloud to insulate yourself from the PKI's biggest weakness, which is the fact that any CA can issue a certificate for any website without the owner's permission. You do this by deploying public key pinning. In one approach, you restrict which CAs can issue certificates for your web sites. Or, in a more secure case, you effectively approve each certificate individually.
There might be more information for this subject on one of the following: