When malware sneaks inside your network, it needs to communicate back to the internet whether to exfiltrate sensitive datasets it found, accept commands of its evil masters or even simply let them know it has successfully infiltrated your infrastructure (with ransomware being one of the rare exceptions that doesn’t need such connection).

Somehow, the focus of security in the past few years has shifted way too much to only “detect” and away from the more valuable principle of “detect and protect.” If you focus mostly on detection, you will be too late. Research shows that exfiltration usually starts 20-30 minutes after an attacker gets on your network.

Is your organization capable of reacting in this short amount of time? We haven’t heard of such a company yet. (Unfortunately, it’s oftentimes the case that the bigger the company, the slower their reaction.)

Regardless of who is the malicious actor and what their motivation is, they rely in most cases on automated hacking tools (HackDevOps, anyone?) to either transfer sensitive information from your network out to their internet lairs or to command and control their malware.

But what if it the malware, operating on your systems, could not connect to the internet at all?

A lot of enterprises are not practicing fundamental, yet simple and effective security controls: disable direct outbound access to the internet.

An application, running on your server, should have outbound access only to those other components it needs to connect in order to perform its business function. So why does that internal database server have outbound access to the web?

Do you have an outbound proxy through which all systems on your network access the internet? It’s good if you do! That’s because automated malware is not capable of finding your proxy settings. Most (Read more...)