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.
No comments:
Post a Comment