Time to rethink your security strategy

As you may have heard, a massive breach of Microsoft Exchange servers was revealed in the last several weeks.

The attack is not over yet. We can always wait for another attack and blame another vendor, but when it comes to Microsoft, well, who can we rely on after that? SolarWinds, Centreon and now Microsoft Exchange… With almost 80% enterprise market share, the Exchange holds the biggest secrets of our times, and now nobody knows where they went. I bet, many of the affected organizations had topnotch security measures and personnel in place. Should we buy and install more security tools then? Well, more isn’t always better, sometimes it’s just more…  

Why now?

Maybe because Microsoft is the most advanced security company in the World with nearly endless resources with the right skills. The company is definitely concerned for its reputation, so nobody can blame them in negligence. Maybe also because Microsoft not just owns the Exchange but also many other security tools like Defender, which was likely installed somewhere along side with compromised Exchange and failed to catch the problem. So, what do we hope will save us in the future?

Several critical vulnerabilities were exploited by the attackers in several waves. For example, Remote Command Execution (RCE) allowed malicious code injection and arbitrary file override allowed to gain persistency and inject remote command & control access. These vulnerabilities remained publicly unknown (so called zero-day) for a long time – at least since Exchange 2013. As Microsoft admitted in this analysis paper while some attackers find and exploit vulnerabilities, others reverse-engineer the patches faster than legitimate customers update their software and this generates massive secondary wave of the attacks. Moreover, often the vulnerabilities are used to sneak in only. In this particular case the attackers have installed web-shells somewhere inside the networks. Therefore,patching the Exchange after the attack has happened, would not help at all.Some attackers were deep enough to remove other attackers from the system, which means that they also will act as a wakeup call for both – software vendors and software users.

Recent study shows that over half of the Docker Hub public container images have critical vulnerabilities in them. Eventually somebody will exploit some of them and we will have nobody to turn to for help. So, what should we do?

Rethinking your security strategy

Some vulnerabilities may exist in the application logic and bad configuration of known tools and protocols. They can be mitigated with proper reviews, penetration tests and tools such as WAF (Web Application Firewall).

The more sophisticated and dangerous attacks usually involve some form of malicious code injection such as process injection, DLL/SO injection, file less malware etc. They may perform the actual attack right away or establish a command & control backdoor helping attackers to slowly recon the environment, move laterally and defer the attack itself.  

The root of the problem is inability to distinguish between the injected malicious code and the genuine one. There are multiple methods to authenticate users and devices, but none of them authenticates the software code itself, especially during the execution. Therefore, the malicious code can access the same interfaces and data assets intended for the genuine software.

One way to approach this problem is to use behavior analysis tools. They aim to identify abnormal behaviors, claiming that malicious code will do something identifiably different from the genuine one. These tools generate a lot of false positives and miss many attack vectors. However, the most fundamental problem here is that even if they were accurate, they would inform you that you have already been compromised, which is too little, too late. On top of this, the attackers know about these tools and therefore take precautions. For example, the Equifax attack was designed to take 86 days to slowly exfiltrate the stolen data flying under the behavioral analysis tool radar. Another interesting question is how these tools have missed so manyExchange attacks for so long time.

An alternative, and more efficient approach is to cryptographically authenticate the software during the execution and establish strong healthy identity for every workload. This identity must be used to verify this software access rights to the interfaces and data assets. Even though many best security practices (e.g.  https://services.google.com/fh/files/misc/designing_and_deploying_data_security_strategy.pdf)require authentication of the software itself, unfortunately nobody did it efficiently so far. ARMO took the challenge and built a product that solves this problem.

ARMO – secure by design

ARMO’s innovative technology is designed to identify and authenticate software code and its configuration parameters “in use” during the entire execution session. Instead of guessing what software does or supposed todo, ARMO continuously verifies what it is. We protect validity of every artifact that is being loaded to the application memory and make sure it was not maliciously altered during the execution. This establishes true software identity that cannot be faked. Such identity is then used to assign the communication policies and data access permissions to every individual workload.All elements – the identity, the communication and data are protected cryptographically,using appropriate signing and encryption facilities. Any software without ARMO identity or without proper authorizations will be automatically locked out of the application virtual perimeter. It will not be able to communicate with anyone and could not decrypt any protected assets.

Even if signed software has a vulnerability in it (known orzero-day), ARMO will protect against the exploitation of this vulnerability. This approach provides wider and more proactive protection strategy against many different types of vulnerabilities, execution environment misconfigurations and dynamic events such as privilege escalation, debugger attachment etc.

ARMO product is transparent and easy to onboard. It does not require any software or architecture changes and therefore can protect practically anything. DevOps and Security teams may apply ARMO protection to software components coming from the open source or third-party suppliers.

ARMO is powered by our proprietary Moving Target Defense technology, intended to significantly raise the reverse engineering resilience bar, and reduce a window of opportunity to attack ARMO protected solutions to the level of seconds before the attackers must start over.

If a product like the Exchange was protected by ARMO technology, the intrusions attempt would have been identified and stopped before it could cause any damage.