For our January focus on cyber and data security, we were joined by Harry Lykostratis. Harry is Managing Director, Lead Engineer and Founder of Open Medical, as well as a practising orthopaedic surgeon.
On his background and current role
As well as founding Open Medical and my role as the managing director, I am also the lead engineer. My background is a little unusual – I became interested in software when I was about 12 when I got my first PC. I wanted an Amstrad CPC 6128 so that I could play games, but my dad got me a different one. I couldn’t play games on that one – to be honest I couldn’t do much on it at all! Since there was little use to do with it, I started looking into it and got into programming. So that’s how it all started. I ended up selling a programme I had written when I was 14 and another when I was 16.
When I was 19, I went to study medicine at the University of Leicester, and I became a doctor and trained as an orthopaedic surgeon. All the while, I was keeping up with programming as my hobby.
Eventually I wrote some grassroots software which took off, and a few years later, Open Medical was born.
I’m still practising as a doctor, I enjoy it and feel it’s important to stay close to the users. Although I have a development team now and I mainly architect our software, I still do some coding myself.
Aside from that, my role involves managing the team. They are an exceptional group of talented individuals, so it is not as challenging as it could be.
Security by design
There’s really only one security strategy that people should use in 2022, and that is to create software by considering security from the get-go.
Security by design means considering security fundamentally. Security should be ingrained in everything – not just the design of your software itself but every facet of your service; operations, recruitment, training, user support and more.
As an example, we recently had to migrate because our primary cloud provider was going out of business and we felt an immediate threat to the service, the company, and to the data that we have custody of. We acted immediately to execute our migration. That’s where security by design comes in – we have provision in a multi-cloud environment, so we already had network and data centre redundancies, and procedures down on paper for a full infrastructure migration. We had already conducted dry runs so that the processes were tested beforehand. Security by design was in our thinking all along.
The software itself has been designed to be portable and to not to rely on specific technologies, so it is never locked in. This is uncommon in enterprise software development. Over three days, we executed a full migration of 60 systems, which is an immense amount of data. We didn’t cut any corners – we ensured confidentiality of data throughout and we continuously tested the integrity of the systems. For us, the migration was a massive undertaking, but for the users, availability of service was unaffected. We informed them with proper documentation, but they probably wouldn’t have realised it was happening otherwise.
I think that’s a good example, because a lot of people think that security is just about data breaches and ransomware, but it’s more than that. You have to be secure by your own users, your own dependencies, suppliers, staff. There’s a bit of a ‘trust no-one’ mentality, really, which would be unhealthy in any other aspect, but when it comes to cloud software and healthcare, I think it is the right way to go.
Challenges and how to tackle them
In a single word: legacy. In healthcare, legacy is absolutely the main barrier. It often feels insurmountable. There are so many legacy softwares out there, some are quite widespread and popular, such as EPRs that were designed 30 years ago.
This software needs to be applied into new ways of working and new ways of provisioning services that it is just not compatible with. It has been designed with older security principles in mind that are not necessarily considered to be the current best practice.
So I think the biggest challenge is transitioning out of legacy. Health IT systems are complex machines and require a big investment. It’s hard to stop relying on legacy; it will take years to get past it.
Modern cloud or hybrid infrastructures have been implemented to be secure by design and more people are moving in that direction. On-premise hosted software, which has been primarily designed to work in isolated intranets, is now being more and more connected to public networks. This is likely to expose more attack surface area than cloud-designed services.
The main problem for health organisations moving to cloud will be the technical debt that has been created over the years. There is a big burden to recruit talent to ensure cloud security; we need people with the knowledge and skills to make it work.
Another challenge in health tech in particular is the sensitivity of the data that we are handling, and our instinct to retain sovereignty as much as possible. Essentially, you need to recruit locally to ensure the best security by design, but many organisations, even suppliers, are forced to recruit remotely. They are forced to outsource a lot of that development, which poses a risk in itself.
It’s not easy to fix this, but I think that one way of tackling this as an organisation would be to essentially shift the burden. Organisations can require suppliers to share or take on the burden of security. Organisations have their operational security to deal with in terms of staff training, information governance and so on, and they will still need to provide the identity of the users and maintain the mechanisms of control over the services and the suppliers. If they move the security complexity to the side of the supplier, I think that is probably a good way to tackle that technical debt issue.
You’d become an expert at vetting the suppliers and ensuring that they can do what you need them to, and I think there are some initiatives to do that. It would be good for the market and it would also support sovereignty, because there would be an increased need for local talent rather than reliance on outsourcing. By moving that burden, I believe you will incentivise the suppliers a lot more to recruit and increase their expertise locally.
Another challenge is complexity. I have been deploying on cloud for about 30 years and the complexity is increasing rapidly, especially in multi-cloud environments. Ensuring that your security is consistent can be a challenge. As an example, we are deploying on AWS and Azure, and they have different processes, paradigms and implementations. Despite that, we need to be consistent so that we can detect, monitor, and be proactive. That complexity puts a lot of burden and investment on our side to ensure that consistency, reliability, and governance runs through all our operations without exceptions.
Thoughts on the future
I would like to see security as more than a checkbox exercise. Bringing it back to my previous point about having a ‘trust no-one’ mindset, as people move more towards the cloud, they start having choices such as provisioning infrastructure, platforms or services. I think it would be safer to see a trend towards service, rather than infrastructure. Tying into my previous point, it would mean that you start shifting the burden of security more to your suppliers, whilst as an organisation you maintain the job of identifying the suppliers and services. I think that is happening, but accelerating would be a good idea.
I would also say that people need to think about what needs to be centralised versus what needs to be decentralised. There is merit in both strategies, but you need to decide the best route forward in order to achieve your highest performance and a good level of control of governance, whilst not increasing your attack surface areas. It’s important to remember that you only need one breach to have access to every UK citizens’ data.
Key security advice
It’s like I said before – in this area, it’s good to have a fundamental mistrust. The architectural challenge for software engineers is to always provide meaningful value to the users without compromising the security principles of the service.
In security, you need to look at it in depth and go multi-layer. You cannot have security as one thing. You need to defend your application at every layer, from the bottom all the way to the surface, and you need to have that mistrust built into your architecture. You need to separate your authentication from your authorisation, and you should never authorise more than you need to authorise. Create security with high granularity where you control every action, and then find ways to control the complexity that this brings.
When you start, make security and access control fundamental. Then, think about how you can create your data model around that, how you can create your user experience and connect your interfacing capability. Start from the security and build from there.
My final comment would be that healthcare organisations need to start doing more due diligence. When they are selecting suppliers, they need to understand what the supplier’s security culture is. It’s not only about the software, it’s about the decisions of the organisation, their historical records, how they work operationally, their locality, the way they communicate their own development processes. Concentrate a lot more on that, because most of the risk is coming from choosing the wrong supplier.
Alongside this, I would encourage everyone to accelerate the replacement of legacy systems as much as possible. Essentially, they are potential vulnerabilities, and you want those reduced.
Many thanks to Harry for taking the time to share his thoughts.
