Continuous Improvement

November 2013

At Nexor, one of our company values is continuous improvement. When I say it’s a company value, I’m not talking about a checkbox on a form. This is something that is truly ingrained into everything we do, and it’s why we’re the best. I’m a Software Engineer at Nexor, and for some time now we have been developing our next generation File Guard. It has been humbling for me, because a lot of the investment we have been making in continuous improvement has now all come together, and I have been seeing first-hand the fruits of our labour.

Over a series of short blogs, I’d like to share with you some of the exciting new ways we’re building our products, and why it’s made File Guard the best project I’ve ever worked on. First, let me tell you a bit about our File Guard. Conceptually, File Guard is very simple. Files are dropped into a file share, passed through a guard, and then either delivered to a destination file share or – if there was something about the file we didn’t like – the file is quarantined instead. But File Guard is not a simple thing to build. Look under the bonnet of the simple concept, and there is a tremendous amount of complexity. Like our other Guard products, File Guard is an appliance – not just software, but a physical server, all set up for you, to do the job it needs to do. For the end-user, this is excellent – you know that what you get will work, out-of-the-box. No worrying about hardware requirements, software dependency fulfilment or integration issues. The server is already set up and configured for you to ensure usability, security and efficiency. For us in the Engineering team, it means we have a lot more to consider than just software. We control the networking set-up, the firewall, the packages installed on the OS, and the configuration of both our software and the OS itself. When we threat model, we consider the security of the physical device as a whole, not just our software that runs on it. There’s more. File Guard, of course, needs to provide the user with a simple way to set up and configure file shares. But file shares are a native OS function, not one we write ourselves. So we also need to consider how our software interacts with the native OS software and configuration management system – we need to be able to manage native OS configuration, without upsetting the native configuration management. This all requires a deep understanding of not just software development but the environment in which our software lives. We need to know about the OS, we need to know about the hardware, we need to work seamlessly within that environment, and we need to know about the security of all of it. And this is all a precursor to designing and writing the software itself – no small task. It’s a big challenge that can only be taken on with considerable expertise in design, security and implementation.

In the coming weeks, this blog series will show you how we have met each of those challenges, and why File Guard will be the best product we have ever made.

Disclaimer: This article is written by one member of a team, about a project that is still in progress. Knowledge may be imperfect, and things may change. This article intended to be nothing more than opinion, and should be taken as such.