Considerations That can Help Enterprises Protect Themselves Against Malware
Thus far 2011 has had the ignominious distinction of being the year of the breach, and modern malware has been one of the key transformative technologies that have enabled hackers to become far more intelligent and persistent in their attacks.
| Read Wade’s Previous Column: An Introduction to Modern Malware |
At the heart of the problem, malware has gone from being relatively dumb replicating code to more of a remote hacking application that gives attackers a foothold within an organization. In a very real sense it represents the convergence of dangerous security threats. The blackhat hacker can now occupy the chair of the insider threat.
We will break this analysis into two parts. Beginning with a look at how to prevent modern malware infections. In our my column I will shift to practices that identify and disrupt an existing infection.
Control Risky Applications
Malware delivery has always sought out the path of least resistance to reach its intended target. When corporate email was the default method of communicating, it was also the default method of malware delivery. Today users have hundreds of applications beyond corporate email that can transmit malware. To identify these applications, you need only look to where people are active; webmail, social media, instant messaging, collaboration and peer-to-peer applications are all infection vectors and demand the same quality of security found in the corporate email application.
Controlling these applications can be broken down into two steps. Step one is to get rid of the high-risk applications that you don’t need. Step two is to ensure visibility and inspection of the applications that you allow.
For step one, consider blocking peer-to-peer applications for everyone except the few who have a legitimate business need. Limit file-sharing applications and proxies to those approved by the business, and block circumventors such as Hamachi and UltraSurf entirely.
You will likely need to spend a bit of time to verify that you are actually blocking these applications, because many of them are evasive – meaning if they are detected and blocked initially, they will begin bouncing to other ports to find an alternate path into the network. BitTorrent and Skype are two well-known examples, and you will need to watch how they behave after they are initially blocked.
Step two is about the safe enablement of useful applications. Ensuring visibility into these apps is sometimes easier said than done. More and more often social networking, webmail and instant messaging applications are protected by SSL. If you are sipping a coffee and checking your Gmail, this may be a nice added bit of privacy, but from an IT security perspective it has the potential to cloak some of the most active conduits of malware into the enterprise. For this reason, enterprises should strongly consider adding the ability to decrypt and inspect SSL-encrypted traffic based on the application or a URL category.
Get in the Middle of the Drive-by-Download
While application sprawl has created more conduits for malware, the drive-by-download has provided a new delivery technique that often leaves an end-user completely unaware that a file was ever downloaded at all. This has made the drive-by-download one of the most popular malware delivery vehicles today. The trick here is that the delivery begins with a remote exploit against the end-user’s machine. This can be something as inconspicuous as an infected image on a webpage. The exploit can target the browser, OS or some other application to gain root access on the target. At this point the user is owned, and malware is delivered in the background with no indication that anything out of the normal has occurred. Of course, browsers and operating systems regularly prompt the user about file downloads, but this is hardly reliable given that they are often the same targets of the exploit. As a result, enterprise security needs a control point in the middle that is not actively involved in the conversation. In-line network security provides just the opportunity.
Since we will be dealing with real-time applications, we will need to have anti-malware capabilities that are both in-line and real-time. Keep a close eye on performance when testing this functionality as many anti-malware were never designed for this sort of real-time work and can quickly bog down.
Additionally, we will need the ability to recognize a file transfer within a variety of applications to ensure it does not simply blend in with the rest of a valid session. This may require decryption and decoding of a variety of protocols to ensure the file transfer is not hidden within a tunnel in otherwise seemingly valid traffic.
Finding the Unknown Malware
So far, we have gotten control of the applications delivering malware, and established the ability to actually see and identify the delivery in-line. One critically important task remains – actually recognizing the malware for what it is. Modern malware is highly networked and manageable and allows attackers to be far more surgical in how they use malware. This enables very targeted and customized malware, which will almost assuredly not be captured in traditional AV honeypots. Thus, new techniques are required. Enter, the sandbox.
The concept of a sandbox has been around for some time, yet its application in the context of in-line network security is still pretty novel. The overarching idea of a sandbox is to place an unknown file in a vulnerable test environment, that is sequestered (“sandboxed”) from the real assets of the network, and then observe the file for malicious behaviors. This sort of lets security teams catch targeted and zero-day malware that even without a signature.
However, as always, the devil is in the details. Just as we have seen earlier in the drive-by-download example, we must ensure that we can see the malware being transferred in order to even get to the sandbox phase. This means looking inside of SSL, tunneled applications and transfers over non-standard ports. A shiny new sandbox won’t do much good if the attacker knows how to sneak his malware past the sandbox.
Secondly, sandboxing is not a real-time process. You are essentially waiting to a see a bad behavior, which can require patience. We humans (and our applications) tend not to be patient creatures, so typically an unknown file will need to be delivered to the recipient before the sandbox renders its judgment. This means that the when a file is found to be malicious, security teams will be in a race against time to pinpoint exactly who was infected, how to stop it and to protect the rest of the organization as quickly as possible. In these cases context is king. You will need user information to see who was infected, detailed visibility and control of traffic to pinpoint and block command-and-control traffic. Staff will need to build in process to create reliable signatures for the malware and update the URL database to prevent further infections. In all cases, you will want to avoid silos of information. You need your threat prevention technologies to work together and you need all of your locations and devices to share the intelligence when a targeted threat is found.
These are only some of the considerations that can help enterprises protect themselves from malware, but hopefully it provides some helpful guidance beyond the basics of keep your antivirus up to date and your OS and applications patched (by the way, keep your antivirus up to date and your OS and applications patched). In the end, visibility and context are two of the most important assets for preventing modern malware infections. These same features will come in handy when rooting out existing malware infections, but we will save that for part two of this article…
Read Getting Your Hands Dirty In the Fight on Malware, Part 2
Read Wade’s Previous Column: An Introduction to Modern Malware
