Why The Era Of Software Sandboxing May Not Be Over Yet

 

As it has been apparent from the blogs, I have been writing that software developers need to be as much on the hook as possible to make sure that the source code they compile is as safe and secure as it can be. 

Unfortunately, this is an issue in which many developers just ignore, or if they actually do it, it is often at the very end when there is really no time to do it all, as the project has to be delivered on time to the client.

If testing source code is done properly, software developers will very often use a tool called which is known as “sandboxing”.  This is essentially where a cut of the production environment is simulated in a testing environment. 

From here, the source code is tested in order to discover any flaws, or vulnerabilities that might be present.

In this regard, there are three types of sandboxing environments that evolved over time, and these primary ones include the following:

*Full environment testing:

This is where the complete source environment is tested in a sandbox before it is released off to the client or the production environment.

*Operating System (OS) Testing:

This is the kind of environment where only the OS is tested, for example if newer updates are coming out, or a whole new one is going to be released.

*Cloud based Testing:

This is where a Virtual Machine (VM) can be configured and deployed either on the likes of the AWS or Microsoft Azure, and this is what is used for the sandbox environment.  

But, given the digital transformation that is beholden upon us so quickly pretty much by COVID19, sandboxing may soon be a thing of the past, despite how long it has been in the IT world.  Why is this so?  Well, there are five primary reasons cited for this, and here they are:

1)     It can only be used on a static basis:

`      It is important to note that sandboxing is not only used to test for source code, but it can also be used to test malicious threat variants, by literally “exploding” them.  For example, if your       company is hit by a malware, and once the .EXE files of that have been recovered, it can           triggered once again to determine how it actually worked, and the possible ways it could have infiltrated through your lines of defense. In other words, sandboxing can only be used from the             standpoint of investigation, and not really predicting what future variants of it could look like in the future.

2)     Sandboxes themselves are prone to hacks:

Yep, you heard me correctly.  The environment that has been created to test the safety of the source code needs to be protected as well.  In many ways, this is like a password manager.  They are great to use keeping your passwords secure, but they themselves need a master password to log into first.  You may be asking why a Cyberattacker would be interested in a testing environment?  Well, as I mentioned before, it replicates to some degree or another the actual production environment.  By hitting this key area first, the Cyberattacker will know firsthand what the weaknesses and gaps are in the actual IT/Network Infrastructure, and go from there, unhindered.  Also, sandboxes are prone to Social Engineering attacks as well.  For example, it could be the case that someone claiming to be a contractor that does work for your company could call a member of your software development team, and have them give out access.  Of course, this is not going to happen all at once, it will happen in stages.

3)     It is not a perfect solution:

Traditionally, it is has been the Virtual Private Network (VPN) that has been at the heart of securing the lines of communications for remote workers.  But this is assuming it is only about 20% that are remote.  But when COVID19 hit, the remote workforce has been now at almost 99% capacity.  The VPN simply cannot sustain this kind of workload.  Thus, is has shown signs of wear and tear, to a great degree.  The only other solution is the Next Generation Firewall, which some businesses in Corporate America have now started to implement.  This is the same situation with the traditional sandbox.  Whie it has been designed to be able to handle only a certain amount of workload at a time, it simply cannot keep up with the advancements in the digital apps that are coming out today.  It too is showing signs of its breaking point, and Cyberattackers are taking full advantage of that as well.

My Thoughts On This

Just as a disclaimer, I am not at all a software developer by any means.  I may know very little Python, but that is only source code that I have used in recent books.  Many people firmly believe that the era of sandboxing is over. 

But before we jump the gun here, keep in mind that just like the VPN, the sandbox was designed with technical limitations in mind.

Just because it cannot keep up with what is all that is happening now, it does not at all by many means that it should be simply discarded.  Rather, it should be used as part of a holistic solution when testing the security of source code.  For example, I have always been an advocate of testing source code at a modular level, rather than waiting till the very end.

So, sandboxing should be used along with other tools like Pen Testing in order to ensure to the customer that their deliverable is about as safe as it can be (again, there are no 100% guarantees in this either).  If you are going to use a sandbox environment, do it an AWS or Azure, as stated before. 

Create a VM, test your stuff, and then once you are done, you can simply delete that VM, leaving no traces behind for the Cyberattacker to latch onto.

Remember, whatever route you choose to go with the sandboxing, make sure you have the buy in that is needed, and that everybody is in the loop of what is going on.