Case study: behind-the-scenes IT architecture deployment, or the cyber secret life of SMBs

At the start of a company’s activity, cybersecurity is just one of many challenges. Building an IT architecture and network is essential, and securing it is crucial. However, there’s sometimes a big gap between principle and reality when it comes to ensuring that good cyber practices are implemented as soon as an infrastructure is deployed – and from scratch at that.

Ivan Kwiatkowski, Lead Cyber Threat Researcher, who had the opportunity to carry out missions as a consultant, integrator and system administrator, shares his view on the importance of designing an IS that is “secure by design”. He discusses the concrete case of a small company he worked with in the healthcare sector.

Do you get the impression that good cyber practices are being overlooked in the design of an infra for SMEs?

Ivan Kwiatkowski: Today, I wouldn’t tend to phrase the problem like that. To begin with, a project to set up an SME from A to Z can encompass an enormous number of things: building premises (with construction site, architects, workers, etc.), a financial component involving banks, a considerable number of administrative procedures, recruitment… and generally setting up a computer network. Is cybersecurity often overlooked at this level? It certainly is. But IT is only one stage of the rocket, and I’m convinced that similar oversights occur at every stage.

The usual recommendations made by cybersecurity experts on a daily basis (applying updates as quickly as possible, having a good password policy, limiting user rights, etc.) seem simple on paper. However, when I was helping to set up a very small business, I came face to face with a number of structural obstacles that make it very difficult to put into practice. Today, the factors of cyber insecurity appear to me more clearly than ever.

What do you think is the main obstacle to implementing these cyber best practices?

I.K.: Surprisingly, it’s not about the budget. Take, for example, the project I was involved in: around 2 million euros were borrowed for the entire set-up of the practice, the majority of which was spent on creating the premises and acquiring medical equipment – some machines costing in excess of €100,000. Compared to this, IT represents a relatively minor item of expenditure, and if we’d needed a few tens of thousands of euros more to protect the network, I have no doubt we’d have found them.

The real obstacle lay elsewhere. Firstly, the initiators of this project were not IT specialists – as is the case with most entrepreneurial projects. They therefore had to rely on outside consultants to help them define their needs and carry out the installation. It turns out that, having worked in the field of cybersecurity for almost fifteen years, I had a particular sensitivity to the subject. But that’s not necessarily the case with an external service provider. What’s more, they will have committed themselves to a precise number of man-days, which will generally not allow them to take account of cybersecurity issues beyond the strict minimum. This is where the budget constraint comes back through the back door: not in terms of the customer’s initial budget, but in terms of competitiveness: a consultant who plans a solid network architecture will necessarily be more expensive than his competitors, for an invisible gain that the decision-maker is not competent to appreciate.

Having said that, this project in which I was involved had all the conditions for success: I was able to choose the hardware to be purchased, take care of the deployment… And despite the best intentions in the world, I don’t feel I managed to achieve the level of security I was hoping for. It’s a painful lesson, because despite my ambitions, my expertise, and an appropriate budget, securing the network was difficult. This suggests that in many cases where a company does not benefit from such support, the reality of deploying an IT infrastructure must be even further removed from security precepts. It is therefore crucial to upgrade the skills of external service providers called in to deploy an IT infrastructure, especially in cases where none of the company’s resources are dedicated to security.

First, how did you set up the workstations to guarantee both security and the operation of business applications?

I. K.: In the case of the company I worked with, the schedule was completely turned upside down: the launch date was brought forward by two months. Despite this time compression, suppliers need a certain amount of time to deploy hardware and software solutions, which left me with just four days to set up a minimal base: installation of ESXi on the server, commissioning of each machine, enrolment in an Active Directory, configuration of switches (there are some 90 RJ45 wall sockets in the cabinet)..

To make matters worse, only one of the two switches was delivered on time, and for obscure administrative reasons, the company could not be connected to the Internet. A service provider graciously provided us with a 4G router, whose 80 GB of data were immediately consumed by a fleet of Windows devices, which, switched on for the first time, were all downloading their updates in chorus.

Under normal conditions, my cyber roadmap foresaw a nice network segmentation based on VLANs according to the different business lines. However, the priority was to ensure that the first service provider (of a long series) could deploy its application by Friday. In the case of the medical data centralization software, any delay in deployment prevented the installation of subsequent solutions, and thus the rescheduling of interventions by a whole herd of service providers with busy schedules. With this constraint on the one hand, and the inevitable imponderables on the other (always to be dealt with without real Internet access), we had to make do with a network that worked rather than a well-segmented one. I promised myself to rectify the situation later, knowing full well that it’s rare to be able to go back on “temporary” measures…

It’s easy to see that any IT infrastructure deployment project is fraught with unforeseen circumstances. So how do you ensure that security remains a priority, especially when it comes to using service providers?

I. K.: Let’s start by stressing that, at this stage, you don’t choose your partners. End-users designate the software they want to work with, and then you have to come to an agreement with the solution provider, whatever its practices.

An ideal installation scenario would be as follows: the service provider sends an MSI package, which is then deployed on the corresponding machines via a group policy (GPO) at Active Directory level. This deployment mode has never been proposed. I’ve been able to identify two possible scenarios.

1. The service provider sends someone to the site. As this person does not have a network of technicians covering the whole of France, he or she is actually the local representative, usually available for sales questions. His role is limited to double-clicking on the installation program, carrying out any initial configuration of the software, and training users. As a result, he or she has only a limited IT culture, and none when it comes to cybersecurity.
2. A technician takes control of the machines remotely to carry out the installation, using TeamViewer-type software. The profile can range from the highly skilled to the completely unskilled.

In both situations, I was astounded to discover that, barring exceptional circumstances, service providers assume that users will have administrator rights on the machines. In reality, the very concept of multisession is totally foreign to them, and I was met with looks of anguish and perplexity when I explained that the software had to work regardless of who was logged on. So I demanded that they find a permanent solution in this respect.

Ultimately, the only way to ensure that security remains a consideration when external service providers are involved is to constantly monitor them and impose best practices. You have to be prepared to impose your expertise, and possibly miss a few deadlines. When I’ve let a service provider intervene without being able to be present, I’ve always ended up having to assist them by telephone, or fix something afterwards. It’s a colossal waste of time, and in most cases, there’s rarely a dedicated IT specialist to supervise the deployment.

Last but not least, how can we ensure that end-users also feel concerned by cybersecurity issues? How can we find the right compromise between user experience and security?

I. K.: Unfortunately, the real problem lies elsewhere: technology doesn’t solve everything, especially when users are resistant to the most basic principles of digital hygiene. I’m thinking specifically of the issue of multisession: one account per user, with permissions adapted to each one, it seems obvious.

It turned out that, in the case I’m describing, the doctors and medical staff as a whole expressed strong opposition to the idea of having an account each, as it meant logging off and on again every time you went into a new consultation cubicle – which happens about once every fifteen minutes, at the very least. Typing your password a few dozen times a day is seen as an unacceptable waste of time (and to hell with the RGPD!). It also happens that a user forgets to close a patient file, resulting in it being locked: it is then impossible to remedy the situation without finding the culprit and bringing him back to the corresponding machine.

This mistrust of IT tools is widespread in the medical profession; all those interviewed attributed it to their experience in the hospital environment. For practical reasons, account sharing is ubiquitous: IT teams are overworked, there’s a lot of turnover… in the end, it’s common for all interns to use the account of a professor who retired years ago. The confraternity that reigns between practitioners does not predispose them to consider that the data of some might be inaccessible to others – on the contrary, the transmission of information must be as fluid as possible to ensure that patient care runs smoothly.

Ultimately, doctors setting up in a new practice find it hard to understand why practices tolerated in a university hospital would not be tolerated in their smaller setting. We therefore need to educate them, explaining the implications in the event of a security incident (even if they remain convinced that it only happens to others), or finding concrete examples: should employees have access to their employer’s emails and accounting documents? In the end, we came up with a compromise: everyone would have their own session, but there would be no restriction on the complexity of passwords – the only constraint being that they had to be at least 4 characters long.

We can loop back on the technology here, and hope that it provides early warning of a computer attack – the medical equivalent of treating the symptoms. But you have to bear in mind that once the practice is up and running, it no longer has dedicated IT resources. Who will read the alerts? Who will disinfect the system? Hiring the services of an MSSP can be a solution for structures that don’t have the expertise or resources to manage a cybersecurity solution. And I deplore the fact that, all too often, especially in smaller organizations, awareness of the risks and stakes comes after the worst has happened.

In conclusion, what lessons have you learned from this project?

I. K.: I’ve learned a lot, particularly about the structural causes of insecurity. When you set up a company, there are so many things to coordinate, and IT is only one piece of the puzzle. In the final analysis, despite a stated desire to put cybersecurity at the heart of the project, the end result fell short of my expectations… and this experience paints a worrying picture: in VSEs, SMEs and even ETIs, at every stage of IS deployment, cybersecurity is likely to become the fifth wheel. I identify the following causes:

• Time constraints, no doubt common to any project, make it difficult to establish a completely sound basis.
• Evolution in a software ecosystem where external service providers, whether for financial reasons or because of inexperience, actively discourage or prevent the implementation of best practices.
• A lack of understanding of the risks and stakes on the part of end-users (who also have the last word on everything).

I’ve also learned that the password issue is more fundamental than ever, and that the password managers we usually recommend are not suited to this type of user. I’ll have to look into authentication systems using physical dongles(Smart Cards) in the future, but there’s no guarantee that they’ll be more widely accepted.

Ultimately, if we can’t change the practices of an entire sector (decision-makers, employees and service providers), we have to rely on defensive technologies. Nevertheless, I insist that security must remain a priority in IS design, because you can’t cover a whole wooden leg with band-aids!

In practical terms, you’re wondering how to deal with threats
and how best to anticipate attacks?
Here are 5 essential reflexes: