Securing the Guard

I have talked previously about the challenge of building a File Guard, and the approach we took to designing it.

Because we are building a physical appliance, there is a lot more to design than software – we have to design the whole system. And because our customers require a high level of assurance, we have to be constantly considering the security of that system at all stages of the project.

Securing a physical server requires a deep knowledge of the whole thing – the hardware, the operating system and the software running on it. This is a challenge that transcends a single project – in fact, it transcends the engineering department. To truly have enough expertise to meet this challenge requires a commitment from the business to provide training for the engineers, and it requires a commitment from the engineers to seek a wider knowledge than you might normally expect of a programmer.

Luckily, as I have previously mentioned, one of our company values is Continuous Improvement. The commitment from the company is there, and the commitment from the engineers is there too. So we have the raw materials in place – what next?

Red Hat Enterprise Linux

Most of our appliances run on Red Hat Enterprise Linux (or RHEL), for various reasons. This includes not just File Guard but all our guards, for example Nexor Sentinel, which is evaluated to Common Criteria EAL4+. That evaluation is a result of the hard work - and hard cash - the business as a whole has invested into building and maintaining a deep pool of expertise in the RHEL operating system, and in secure software development. But don’t take my word for it, see for yourself. My Red Hat certification ID is 120-196-084.

And by no means am I the only engineer at Nexor with Red Hat certificates. In fact, before I joined the company I had never used Linux at all, and even then it wasn’t so long ago that I had used it for little more than compiling my software. My expertise, and the expertise of our other Red Hat certified engineers, is the result of a direct investment from Nexor - and, of course, the excellent quality of the training courses that Red Hat offer.

If you have taken the time to look at some of the articles I linked to above, you might be able to venture a few guesses as to what we do to secure our appliances. In fact, there are many ways we approach securing our appliances - Cyber Shield Secure for example – but let’s focus on the one I know most about: SELinux.

Security-Enhanced Linux

SELinux (Security-Enhanced Linux) is ingrained into the Linux kernel and is on by default in modern Linux distributions (including RHEL). Without getting too technical, it is a means to sandbox processes by limiting what they can access and what they can do. Take for example a webserver process running with administrator privileges. If a remote attacker takes control of this network-facing process, it can then use that process’s administrator rights to gain control of the entire server. SELinux mitigates this risk, by defining exactly what a webserver is allowed to do – regardless of what user privileges the process has. An attacker who gains control of the webserver cannot access any data or perform any action that a webserver would not normally be allowed to. The damage is limited to the process that was compromised.

In File Guard, we build on the SELinux policy provided by RHEL by writing our own SELinux policy for our software.

At design time, we baked in a very simple rule: data sent in must pass through the guard before being sent out. We use SELinux to ensure this is the only route through the system. The file receiving process can only communicate with the guard process – nothing else. The file sending process can only receive communications from the guard – nothing else. If despite our best efforts an attacker gains control of a process, it’s still not possible to bypass the guard, because the communications required to do so are forbidden at the kernel level.

Doing Things Properly

This is just one way we approach the security of our appliances, and you can see how seriously we take it: we are constantly investing in our expertise, constantly thinking about threats and mitigations, constantly thinking about security from analysis and design right through to development and testing. If you go to the Nexor website and hover over “About Us”, the first link is “Doing Things Properly”. Now you know why.
Next time, we’ll take a look at the software development itself.

What other ways are there to secure our products? What approach does your company take? Leave a comment below.

Disclaimer: This article is written by one member of a team, about a project that was 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.