Door Security

Giving access to employees and visitors can be a complex task. Yes, you can tell someone they have no authority to go into a particular area, but its another to actually stop them. We were given the opportunity to look at an organisation’s door security.

There was already a door security system, but it needed a refresh. Conversion to a thin-client infrastructure was being hampered by the rich-client needs of the old system, along with a vastly over-complicated rule set, was holding up expanding the system.

We investigated the current system and uncovered a system left far behind. Installed ten years before, it was hosted on old infrastructure, old workstations, and with deteriorating peripherals. The door controllers were installed at the same time, but they were surprisingly up to date.

We contacted the vendor and after a number of discussions agreed a way forward to improve the solution and make it more sustainable. 

The organisation had locations across the country and had to be able to control all doors in all locations. We worked with the security department to start the access matrix from scratch. Instead of working at an individual level, we created a defined set of roles. This allowed us to work out who was allowed where. Test engineers for example were allowed into the laboratories and the test centres, whereas the accounts department were not. C Suite could go everywhere except the clean rooms, where they would need a briefing and an escort.

During this time, we looked over the newer versions of the software. They were thin-client compatible, however, the device to encode the cards were not. The vendor also pointed out there were no guarantees with running the back-end services on virtualised platforms.

Installing the software wasn’t an issue, but it needed to be fully tested. We arranged for a test rig to be set up comprising a door controller, card reader, and a series of indicators to show door release. We were able to fully test every door configuration, from manual to automatic doors, and revolving doors. It also allowed the test engineers to perform a thorough test of every function and expected event the system would be exposed to. It was the first time the organisation had considered approaching the problem this way.

After discovering a number of undocumented features, the vendor was able to plug them with updates and patches, making the system more secure than ever before. We next loaded the system with the access matrix and tested each type of role.

Next, the new infrastructure was deployed and the software loaded. The only issue remaining was the USB-connected peripherals on thin clients. We overcame this with a unique solution, which was rigorously tested for security to ensure the encoded card’s data could not be intercepted.

The rollout was done on a site-by-site basis, with a data transfer occurring between the old and new systems. With the last site migrated, the old system’s data was backed up, and switched off.

The system is now on virtualised servers, resilient databases, and thin clients. This all falls in line with the policy on hosting and user devices.

Rather than leave the system as it is, the support teams can now apply patches and updates in line with the rest of the infrastructure.

Every site is now linked using encrypted lines, and controlled centrally.

A new policy of no tailgating increased the reliability of data. It was possible now for door data to be used for automated contractor timesheets and absenteeism