Thinking security: Is security all about cryptography?
Author(s): Michael Kain, Posted on November 28th, 2017
This is the 31st blog in a series about security and how security is about how you think.
Thanks to Dr. Glen Newton and Jason Schultz for the OS 2200 insight used in this blog.
I recently had the opportunity to talk with a high school senior who was interested in computer security. He said that he couldn’t wait until he started learning about keys, encryption, hashes, and all of those “security” topics. It took me a few seconds to realize that he thought security was all about cryptography.
So first, yes – using keys, ciphers, hashes, certificates, and shared secrets in our communications make them more secure. It’s also about using the latest security protocols – TLS 1.2, SSH 2.0, AES-256, AES-GCM, AES-CCM, ECC, ECHDE, etc. – all of the “alphabet soup” of cryptography that makes our systems more secure.
But also, no – using cryptography incorrectly doesn’t help with security. It also doesn’t help if the underlying security is bad. Take the example of your home router, with a default login of “admin” and “password”. Requiring SSL/TLS to connect to it doesn’t help, especially if it also uses a self-signed certificate and one that you can’t change to use a specific hostname and unique private key. As I’ve documented in this blog, it’s how you THINK security: How do I make the router more secure by using security? Can I change the usercode and password as well as the certificate (and underlying private key)? To make the home router more secure, we could also require secure communications over SSL/TLS and ensure that we’re only allowing administrative connections from the internal network (not the external network).
There is also another dimension to this issue – knowing what cryptographic algorithms and network security protocols are in use by all connections to my system – whether it is a home router, local server, or ClearPath Forward™ system. The protocols and algorithms negotiated and in use affect the security of the system . So if I have connections that use old cryptographic algorithms (for example, DES or RC4) or older versions of network protocols (SSLv3 or even TLS 1.0), then I need to know the business reason for the use. For example, I may need them because I have to connect to a computer system that hasn’t yet been upgraded.
As we continuously use our systems, we have to also “move the window” (my term) with regard to cryptographic algorithms and network protocols. This means that we have to constantly evaluate and improve the default security of the system. The ClearPath Forward Engineering group constantly examines the algorithms and protocols for each release and even between releases. For each major release, we add newer and stronger algorithms and versions of network protocols. We constantly monitor the working groups for the latest standards to see when they are approved. We also constantly deprecate (remove from the default lists of algorithms) all of the versions and algorithms that have been designated as such or broken. This means that they can be re-enabled for those clients who need them, but are not available by default. Then at a later release, they are de-implemented and removed from the system software.
The logging of the system helps the analysis of this process. For example, in the ClearPath® MCP system, every OPEN of a network connection logs the version of the networking protocol along with all of the cryptographic parameters in use. Similarly, tracing can be configured in ClearPath OS 2200 systems to record network connection details (protocol, cipher suite, the exact contents of the handshake messages, etc.). Tools are available (for example, Locum SecureAudit for MCP and the CPComm/CPCommOS STATUS commands for OS 2200) that allow clients to analyze all connections to their systems to uncover which connections are using older algorithms. Then security administrators can understand and uncover security risks in their environment.
In conclusion, security is NOT all about the cryptography that it is based on – it’s how you THINK about cryptography. Which algorithms are in use? Are they the latest? If not, what is the business reason for their use and do I also need a compensating control around their use? ClearPath Forward systems allow security administrators to understand the cryptography of their systems and how they THINK about it.