Five ways to get the most out of your sandbox
There’s been a lot of talk lately about the value of sandbox technology as part of a cybersecurity defense. While sandboxes are a valuable tool in the hands of a cybersecurity team to identify and analyze malware and other sophisticated threats, the actual value depends on how well you know how to use it.
To help CISOs and other cybersecurity executives, here are five ways to help you get more out of your sandbox, as detailed by ThreatTrack Security’s Anthony Arrington.
1. Identify all the applications in your stack
One of the big things a sandbox can do is provide analysis across an enterprise’s application stack, which provides the ability to track and detect exploitable threat types and vector types across the stack.
However, the sandbox can’t find all possible exploits if it doesn’t have a complete view of all versions of all applications in that stack, Arrington said.
“You need to know the frequency of where those applications exist on your network. If I have multiple images, endpoints or users, I would want to make sure that application stack matches the general user in my community,” Arrington said.
For example, an enterprise might have seven applications that are commonly used by most users, but there might be several versions of each application in use at any given time, depending on upgrade and patch cycles. Certain threats seek to target combinations of specific versions of applications in order to gain entry into a network or access to data.
“I may have multiple images, on XP systems, Windows 7 systems. I’m supporting those applications with varying Operating Systems and they might be a version or two behind. Say I have Adobe Reader 10.x and Adobe Reader 11 in use. I need to know which of those are vulnerable in that application stack, if they’re being used as a vector to gain access to another application in order to expose vulnerability at the operating system level,” Arrington said.
2. Replicate the real-world environment
While virtual testing is going to be more valuable if your users are using virtual systems in that application, testing applications from a virtual sandbox poses additional risks if your users are not using applications in a virtual environment too.
That’s because certain malware will look to identify it as a virtual environment and respond accordingly, Arrington said.
“Unless your users are working in a virtual environment on a day-to-day basis, virtual testing will not work as well. There are a lot of malware laboratories that submit [samples] to a virtual environment when 100 percent of their systems are physical. The message there is be able to replicate the target completely or as close to reality as possible.”
Expanding on the point above, users should avoid using appliances to simulate network activity, Arrington said.
“It’s either a production box or a test lab. In the sandbox, put the physical network components around the network architecture and use INetSim, a network simulator to configure specific DNS hosts, maybe IP forwarding,” Arrington said.
The physical sandbox can also identify network attributions or anomalies that wouldn’t be able to be pinpointed using an appliance in a malware lab environment, he added.
3. Isolate your network
When an organization connects to many different vendors and devices outside the corporate firewall, it’s more difficult to manage what comes in or out.
You may not want your malware lab connected to another network, you may not want to share vulnerabilities or indicators of compromise with another organization.
Cyber security staff should have the ability to literally shut off the sandbox architecture to the world and collect only data that means something to the organization.
“You don’t want your data being pushed to another vendor’s cloud technology and sharing targeted information and organizational attributes across an unknown community that you have no control over,” Arrington said.
When data is pushed to the cloud, there are no guarantees who has access to the data or that you would be aware if that data was being compromised, Arrington aid.
“That’s a root cause of why you’re not identifying [the problem] and why you’re not making a true assessment of what is actually on those computers. You don’t have a platform to replicate that application stack to leverage what software assets are being tested against in that architecture,” Arrington said. “Virtual systems are just that. They’re virtual representations of physical endpoints that are not collecting specific indicators of compromise based on that. if you have physical endpoints, you need to collect physical data. You’re not replaying the initial attack across a true target in a virtual environment.”
4. Eliminate false positives
“Incident response analysts get reports that have a limited execution layer and get a lot of false positives. They have samples that detonate and die very quickly because the environment is not under the right condition for that malware to execute or trigger. So the reporting will be thrown out
Submitting a sandbox sample to an appliance or something with limited capability, you won’t be able to see true network behavior. The incident response team will be missing hard evidence of an attempted intrusion or physically dropped files.
“Those are misses in the appliance world that won’t detonate. If they can’t identify a file, or you don’t have the application in the application stack, there’s no reporting on that file. It doesn’t get observed,” Arrington said.
Additionally, if there’s a correlation engine that you’re feeding data to from your analysis architecture, key elements are not introduced, Arrington added. No data is being correlated against bad data because it got through the cracks.
5. Utilize a multiple-sandbox environment
If you’re an enterprise charged with managing remote sites with multiple entry points, one sandbox isn’t going to provide you with a true correlation across that enterprise, Arrington said.
“Multiple sandboxes give you better data and give you site-to-site attributed data. You will know the Site A entry point information or the Site B entry point, and you can share information across both access points,” Arrington said.
A multi-sandbox environment also allows you to contrast behavior. For example, one sandbox can be used for whitelisting and one as a malware lab, Arrington said.
“You can send good applications to one sandbox to get an understanding of what’s normal, what good applications look like and to understand their behavior,” he said. “So if you do see something outside that normal activity, you get a better indication of what happened because of the contrast of the good and bad behavior.”
Author: Scott Campbell, Security Threats & Trends Analyst for ThreatTrack Security.