If you have been in this industry for more than a few years, you have probably heard the sales pitch, “What keeps you up at night?” It’s a typical sales tactic to elicit an emotional response to threats that seem to be out of your control. It’s designed to draw you out, start a conversation, and ultimately, prey on your fears.
We have enough security issues to concentrate on without having to prey on fears. That is one of the reasons I never liked this sales pitch. I have always felt it is better to address the challenges facing network security and do what we can to face those threats.
Growing up in Santa Cruz California, I learned to swim in the ocean with some pretty scary waves. If you did not see a wave coming, you would get swamped by the wave. But if you faced the wave and dove under it, the threat was mitigated. If we do not see the threats in network security, we too can be swamped. For this same reason, we must look into encrypted packets to mitigate those threats. We cannot face what we do not see.
The SonicWall 2017 Annual Threat Report shows that over half the mechanisms delivering malware utilized encryption to mask the threats. The threat actors who create malware know that if they encrypt their payload, the odds of end system infection are very high while intrusion detection is low. As far as effort to create an encrypted session than a standard, plain-text session, is minimal. So, there is little extra work to create encrypted payloads while the reward is large.
In the last few months, there have been some tests and claims from well-respected Web Browser vendors making the claim that Security Devices doing Deep Packet Inspection (DPI) of encrypted packets weaken security. Their testing showed that many security product vendors deploying ‘Man in The Middle’ tactics to de-crypt and re-encrypt packets for the inspection, re-encrypted with a lower quality of encryption. This effectively did weaken security, and by doing so, drew the conclusion that security devices performing DPI-SSL weaken your protection.
This position is understandable, however, SonicWall takes this opportunity to actually increase security by hardening HTTPS encryption when weaker cyphers or invalid certificates are presented.
Workstations and end systems do a very good job of updating browsers, checking for revoked certificates and supporting strong encryption methods. But there are many times in which we find the same is not true for hosted sites that contain many servers but have limited IT resources. Encryption methods get depreciated, but these often to not get updated and within the server negotiation of Transportation Layer Security (TLS) session, older and outdated methods still exist today. Secure Sockets Layer 1, 2 and 3 protocols are no longer recommended for sensitive data and should not be used.
The SonicWall next-generation firewall can detect when a server is presenting these weak encryption methods and block session initiation. Of course, there are times when this is not desirable. In that case, we also have the ability to let these connections establish. When I am confronted with incidents where TLS is not supported from a host that contains sensitive data, I have been successful in reaching out to that organization and letting them know they are not complying with Transport Layer best practices.
When networks are breached, sometimes the only time you find out is when these compromised devices “phone home.” In doing so they will use encryption. Trojans, malware, and botnets leverage Command and Control Centers for updates and orders. They use non-standard ports and are not typically web connections. SonicWall is not dependent on port numbers or browsers but all ports. Every packet in each direction is inspected, securing your network.
The next time someone comes into your office and asks you, “What keeps you up at night,” don’t fall into this fear trap. With SonicWall, sleep sound. Protect More and Fear Less.
0 comments