What Is It? The ASD strategy refers to this as “Automated dynamic analysis of email and web content run in a sandbox” but I prefer to simply call it sandboxing. At one time, to test an application you basically had to gamble on running in and we used a variety of means to do so including stand-alone computers and virtual systems. In both cases, they were built to be destroyed. While somewhat effective, it was highly cumbersome. Modern sandboxing is done on the fly and virtually invisible to the end user, testing content as it traverses the network with the intention of protecting the production systems.

Sandboxing, if one were inclined to look it up on Wikipedia, is “frequently used to test unverified programs that may contain a virus or other malicious code, without allowing the software to harm the host device.” This testing occurs in a variety of ways which I won’t elaborate here. Many of the mainstream security vendors offer sandboxing in their portfolio or products and services, so you have options if you wish to consider it for your enterprise. Maybe you already use these vendor’s products and even have it as part of your subscription; it’s worthwhile asking about.

Funnily enough, the way your computer runs some applications is a form of sandboxing. The programs run inside of one of your applications (for example, a web page within your browser) and would must be deliberately allowed to reach beyond that isolated space. Therefore, you will often get pop-ups that ask you to access other resources, like a site that wants to access your webcam. Even apps running on your mobile devices run in a sandbox and can be managed in isolation. Terminating the app terminates the program running within it. Sure, there are things that can and do work around this, but you get the point.

In a broader sense, before email and web content can execute per this strategy, they are effectively isolated, executed, and their operations verified. It’s like the way a double-door system works in buildings where you enter one door and must close it before being authorised and allowed to proceed through the other door.

Where Do I Start? “Do we need a sandbox” is a loaded question depending on who you ask. Let’s forget the way browsers and mobile apps work and focus instead on the dynamic traffic that flows in and out of your environment. We’re constantly receiving emails and visiting websites virtually loaded with programs and code, so it only makes sense to vet this before it reaches the end user. Few are the organisations that wouldn’t benefit from sandboxing, but many are the organisations that don’t use it.

Given the growing reliance on cloud where some traffic never even reaches our premise yet can wreak havoc on our systems, implementing a sandbox makes good sense. Don’t worry about breaking the bank to start because there is a wealth of options to choose from that will provide great value for your money; you just need to plan appropriately. In some cases, sandboxing may be available from a managed services provider where you won’t need to bear the entire cost, but just the cost of what you consume. We all know how much more attractive OpEx models can be over CapEx!

How do I make It Work? The long and the short is that you make it work by having the sandbox handle your inbound and outbound traffic, either all of it or part of itYour sandbox can be inline, handling everything, or exist in such a manner that your other appliances offload traffic to it for secondary inspection. In a cloud environment, similar and sometimes more flexible options exist.

Traffic that is designated for the sandbox identifies interesting traffic and then isolates it for execution and evaluation. You would be very surprised at the volume of programs that are embedded in the network traffic that traverse our network daily. Many of us even lack the visibility to know any of it is even there, but visibility is another topic for another day. Once the item is “sandboxed” it gets a yay / nay (or you decide) verdict and either continues its way, gets blocked, or lets an administrator decide. For what it’s worth, it’s best not to let the end user decide unless they have the knowledge to understand the risk and impacts.

From the end user’s perspective, they should be virtually unaware this is happening, and it really shouldn’t have an impact on their performance when it’s implemented correctly. Always remember that the more you inspect traffic, the great the possibility of slowing things down with the overhead required. We’ve all stood in long queues at airports to go through security, especially when there has been an incident and the authorities ramp up their inspections!

Pitfalls? Getting too over exuberant with inspection can hinder productivity, just like under-spec’ing the deployment. You must balance performance with security and remember that sandboxing isn’t a be-all and end-all, but just a good part of a defence-in-depth strategy. Also understand that sandboxes are not absolutes in that clever attackers can figure out ways to bypass them, although with recent advances in dynamic analysis and some clever products, this is getting more and more difficult. It also won’t help using legitimate tools and applications against you, so be sure to keep these under wraps.

Ghosts in the Machine? When it comes to sandboxing, there are ghosts as with everything else, and human error can always play a role. Proper planning and design are obligatory, or you won’t get the value you expect. If you don’t have the resources in house, it’s worthwhile to have the experts come in for a conversation to start the ball rolling and then help you on your journey to sandbox implementation.

Anything Missing? Remember to consider ALL ingress and egress points, so if you have multiple service provider connections, ensure you defend all of them. This is more obvious in businesses with many locations that each have their own connection (in which case maybe cloud is the best option). Also make sure that if you have multiple data centres, even if just DR, to include them in the plan. You could find yourself failed over to the DR otherwise and be unaware a critical layer of defence is now absent.

Disclaimer: The thoughts and opinions presented on this blog are my own and not those of any associated third party.  The content is provided for general information, educational, and entertainment purposes and does not constitute legal advice or recommendations; it must not be relied upon as such.  Appropriate legal advice should be obtained in actual situations.  All images, unless otherwise credited, are licensed through ShutterStock

Views: 5

Join the Discussion ...

You need to be a member of CISO Platform to join the discussion!

Join CISO Platform

© 2020   Created by CISO Platform.   Powered by

Badges  |  Report an Issue  |  Privacy Policy  |  Terms of Service