Daniel Smith

Q: Have you ever encountered an interesting or challenging bug related to rail cyber security, and how did you approach solving it?

A: The rail industry is very unique in its approach to computing. The design of Security Gateway is a good example in that it has features such as isolated Virtual Machine’s (VM’s) (aside from which there are no other external services), the ability to re-asses configurations over time, and it has a minimal attack surface. If you ask a general engineer to run updates in parallel, they’re often in an environment where they cannot guarantee network access, so what is needed are programs that work with limited connectivity. We expect our deployments at RazorSecure to work for 15 years without human involvement, which is why we use VMs. A good analogy would be to imagine there is a flaw in one, and how that wouldn’t affect or damage the rest of the system. Our SGW tool provides secure isolation by using VMs, giving a multilayered approach which prevents attackers moving across systems.

Q: What drew you to the fascinating world of rail cyber security, and did you foresee any challenges in applying your expertise to this niche industry?

A: What drew me to it was the paycheck, but the better question is what keeps me around, which is down to the industry and its unique challenges. No two integrations are alike, and the additional challenge of making our systems configurable and manageable requires a vast amount of knowledge of what our customers want, and what is possible, whilst always maintaining that systems are secure and robust. The general challenge is that almost all the existing knowledge around what you're doing is geared towards an assumption that we’re sitting on a server on the internet with an infinite amount of access to resources, storage, etc., and in rail that is never the case.