Security Configuration Insecurity

October 31, 2014

The security manager was chuffed about the wonderful new access control system which was installed at his premises. Four hundred users across two campuses, untold number of doors and readers, all logged and monitored. The installation had gone well and he had remained on budget. There was one 'win' he was particularly proud of: A high-ranking director who had forgotten his new proximity card, rang the security manager's mobile and asked if he could remotely unlock the door for him. As the doors were centrally controlled and the security manager could positively identify the staff member, this was easy. However, the security manager was at home. No problem - he was able to remotely connect to the access control computer and what appeared on the screen of his home computer was identical to what he would see if he were in his office.

The security manager in question was boasting to me about a major advantage of this setup - in addition to the career advancing potential of opening doors for management in the middle of the night, if a staff member were terminated or a proximity card stolen, he could cancel access privileges within minutes as he could log in via the closest Internet connection, be it at home, a hotel or potentially an Internet café - although he didn't like those as he knew their computers were often virus riddled.

Any IT network which offers remote access to users, exposes all of the services on that network to increased risk. However this was a particularly interesting case as while cybercriminals can potentially steal information and data in most remote access breaches - and this is well known, in this case they could literally unlock the doors to the building as well. This is not to suggest that remote access cannot be effectively implemented and the associated risk managed like any other system under consideration. However, this is a threat many physical security or facilities managers may not have identified. Worse, like most identity fraud based intrusions, any breach involving your access control software, in the absence of network based logging, might list a valid user whose identity has been spoofed, as the person who unlocked the secure door after hours.

When I pointed this out, the security manager was shocked by all of it which had come as news to him. He immediately issued the IT Department with a "please explain" and they immediately responded that they did not allow remote access in the first place, wanting to know who had configured it for him. The answer, his alarm installation contractor, who had requested the IT department open a port in the firewall to support "remote diagnostics". Given the installation project and not wishing to trifle with security management, they did as asked and gave it no further thought.

It is well known that there is growing convergence between IT security and more traditional security. Much of this is being driven by the technology and particularly the rapid migration from older analogue CCTV and alarm technologies to newer IP-based solutions which can interoperate with existing IT infrastructure. In the past, these were very separate worlds that barely understood each other. Security and Facilities Management often didn't know how to use their computers and conversely IT staff would forget to lock their doors. In modern organisations, these functions are often combined and it is expected each 'side' would co-operate with the other. However technical skills remain quite detached, so where there is a technical crossover - and this is increasingly the case - there is tremendous scope for problems to arise. The specifics of alarm electronics, wiring, fault-finding and camera selection are as much of a 'black art' to otherwise very technical IT staff, as IPv6 and NTFS might be to a highly experienced security operative. Yet this hasn't stopped the two 'worlds colliding' with some rather unfortunate side-effects.

A large part of the problem, stems from the deliberate segmentation of physical security-related software systems. It is still common to see access control software which falls to pieces as soon as it is installed on a properly hardened server. Apply operating system controls and the database won't load. Change user-access permissions and the program won't run, and so forth. Once upon a time, these systems were designed to operate on a standalone PC in a cupboard somewhere, running, say Windows NT or 2000. Remember those? Yet, as soon as you hardened an operating system, as is considered best-practice and mandatory in many organisations, these systems flat-out refuse to run properly. Fail to harden them, and the IT Department will (often rightly) refuse to connect them to a corporate network or provide support for them. Even printing reports from these systems can then become impossible, much less having them properly backed up or accessible remotely.

At the time of writing this, in late 2007, the specifications for GE/Tecom's Challenger control software, Titan, is as follows:

"Operating System: Windows™ NT Workstation Version 4.0 (or higher) for File/Comms Server. Windows™ NT, 95 or 98 for Workstations. (NT Preferred)" (Source:http://www.tecom.com.au/documents/titan.pdf)

Hello? Every single one of those operating systems is no longer even supported by Microsoft and you'd be hard pressed to find the type of large installation which requires a Challenger alarm panel, running them on their corporate LAN. Before you get into the usual arguments over whether Microsoft Windows can ever be a secure operating system, if you believe it can, there is no question the above options won't help. Tecom's more advanced system, ARES has an embedded operating system - QNX which by definition creates problems of its own including connectivity to other infrastructure.

Hardware/software Vendors need to realise that the security control systems are no longer locked away in their own cupboard separate from everything else.

The 'holy war' between fans of GE/Tecom' Challenger and Inner Range Concept often resembles that of Mac versus Windows users. So as not to give succour to the Concept camp, their equivalent software requires "Windows 2000 or better". Well that's not very hard is it?

These type of companies design and make hardware and software designed for the sole purpose of protecting company assets. Yet, their software is fundamentally incompatible with many information security best-practices. As a side note, it amuses me greatly that many of their minimum specifications even state "mouse" as a mandatory requirement, just in case you couldn't guess.

You can even buy brand new alarm panels, today, which are remotely configured by software that runs in DOS, over a modem. Never mind that Microsoft is (rightly) trying to finally move away from DOS, you could be the most hotshot alarm panel installer in Australia. However if you are under 30 years old, there is a very good chance modem strings (remember those?) will confound you. Little wonder that security systems still require Serial Ports as well, even though you will struggle to find a server these days which ships with one. It is as though physical security was left in the Land that Software-Development Forgot. To vendors' credit, at least they are shipping software on CD and not floppy disc...

All of this illustrates how totally lost the physical security world is, when it comes to proper IT security. Unfortunately, the solution has in many cases been for everyone to bury their head in the sand. IT Departments turn a blind eye to 'that' computer and physical security technicians who just want it to work, are quite happy with this. Ignorance is bliss, however it means that connecting 'old-school' security technology to new systems such as remote access, is equivalent to finding a large hole in the wall and hanging a new neon sign over it saying "come on in".

In many cases however, the only way to do anything properly is by clumsily stringing together a large number of 'workarounds'. What is known in the IT world as a "kludge" (see also, "bodge"). This is not an effective approach.

I am a big fan of remote access provided (and here is the important bit) systems are properly risk-assessed, appropriately configured and adequately secured. A sound approach I might add, to considering any online system. The benefits of remote access to staff availability, branch access and even Business Continuity Planning are enormous.

However the lack of knowledge of physical security personnel to the associated risks means the risk may not be effectively managed and the consequences severe. Even if installers know what they are doing (or seek expert advice) they are being badly let down by software vendors...

Have a question?
We'll answer your enquiry within 24 hours.