Here at Avecto we believe that security products should be secure by design, meaning that they are designed from the ground up to be secure. A key principle is that you should be able to share details of the design without compromising its security, as opposed to security by obscurity, where you are reliant on keeping the solution secret to prevent a compromise.
This approach allows us to share details of our Sandboxing solution with clients to show that we have adopted an approach which is not only secure from the ground up, but is also secure by default. A great example of this is how Defendpoint Sandboxing doesn’t try to keep applications and content within the sandbox, it is only responsible for enabling the flow of content in and out of the sandbox so that the application can function securely and as expected.
The sandbox is analogous to a container full of water. The water represents the applications and content that we want to isolate, and the container is the sandbox. To achieve security by design, we are much better off building a solid container than one that is full of holes. Should we need to transfer some water in or out of the container, we can choose when, and how, this should happen. So the water is isolated by default.
Starting with a container full of holes, the water can very easily escape as we have very little control over it. Even if we have enough fingers and toes to plug all of the holes, what happens when we are no longer there, or if a new hole appears?
The secure design of Defendpoint Sandboxing is based on the use of temporary local user accounts. Defendpoint is responsible for running applications in the context of the temporary local user accounts that it has created specifically for this purpose. This solid container uses the existing, built-in Windows security model to provide isolation of users, and the data stored in their profiles, from other user accounts. This is a mature, well proven security technology that allows Defendpoint to provide a lightweight and secure sandbox.
This unique approach is far more secure than trying to isolate an application running within the same user account. That would result in the container full of holes problem, where you had to constantly patch all the ways the application interacted with the system and totally relied on the solution running for security.
Once an application is running within a sandbox, the Defendpoint agent is no longer required in order for the application to remain isolated. This removes Defendpoint as an attack vector – malware running within a sandbox will be more isolated should it attempt to attack the Defendpoint agent. Obviously, this does not mean that Avecto do not take steps to prevent such an attack!
As an aside, Defendpoint allows for different application control rules to be defined within its sandboxes to help prevent malware from ever running. Typically these rules would be more restrictive, which makes the combination of using Application Control alongside Sandboxing extremely powerful.
In a similar way, there is no benefit in targeting the temporary user accounts that Defendpoint creates. These are standard user accounts with no additional privileges, and no access to other user’s data. Gaining access to these accounts will only provide access to an isolated environment. Of course, Avecto still takes all necessary measures to protect these accounts.
In summary, Defendpoint leverages existing technology to provide a secure Sandboxing solution. The Defendpoint agent is then responsible for enabling content flow in and out of the sandbox, operating from a position of secure by default.
This is a great example demonstrating the simplicity of the Defendpoint approach to sandboxing and our belief in building products that are secure by design.
Over the coming months I look forward to sharing more details of Defendpoint’s features from the development team that makes it all possible.