Is there anything more boring than access control?
...and will it ever change?
When Luke Skywalker blasted the bridge controls onboard the Death Star my first thoughts were “why did the doors close? Who designed that access control system?”
It was long ago and in a galaxy far away, so maybe they were still considering building hybrid credential readers with door controllers built in - in the same way that HID attempted years back. It didn’t take long before everyone realised the obvious fact that if you put all the critical electronics and lock controls out in the open they're really vulnerable to being tampered with…or blasted by wayward Jedi apprentices…
More of my days in security product design were spent designing and redesigning access control electronics than anything else. Everything from power supplies and timer relays to biometric readers and entire Electronic Access Control platforms, and all the time I kept thinking to myself “surely this is the last time I'm going to have to do this”. But it never was (until the day that it was).
It seems incredible to me that there are still people who wake up each day and go to work somewhere on this planet designing access control products yet again. Over and over again.
Status Quo could release a single called Locking All Over the World in tribute to these people perhaps?
Now, don’t get me wrong. Access Control is fundamental to Situational Crime Prevention and CPTED, along with the various components of identity management it remains prominent in ISO-27001 and it’s one of the measures included in the PROTECT function in NIST. I was once told be the head of a Regulatory Agency for the Security Industry that I’m not going to name that Access Control is nothing to do with security, but is instead a management function. That statement made my jaw land on the carpet.
If the threat or hazard cannot get to the asset then there is no risk. We all agree on that, don’t we?
Fundamentally all access control is the same. There is a controlled point of connectivity (either physical or virtual) and there is an agent in possession of a number of privileges in relation to that connection point that are activated in response to some set of identifying characteristics somehow associated with the agent.
In the Electronic Access Control System world the connection point is usually a door with a lock of some kind, the agent is a person, the identifying characteristics will be one or more credentials (the factors of authentication), and the privileges will be the ability to gain physical access through the door in accordance with some logical conditions.
In antiquity, the credential might have been a key or a secret spoken word that the guard behind the door might need to verify before allowing you through. Security relied upon not telling everyone what the secret password might be…just like with your Netflix account…
In the world of computers the connection point might just be the path to a piece of information. The agent could be a user and their security credentials but it might also be a service, and the identity could be all manner of encrypted or obfuscated data exchanged as part of a complex interaction that enables permanent, temporary or transient availability or enablement.
It's all access control.
It's all a bit dull.
You get in or you don’t get in.
The rest is just logic and some sort of database.
It’s hard to see where there’s much opportunity to revolutionize what’s going on in such a simple world, but let’s look at some of the nuts and bolts and see what feels loose.
Working from the bottom up, there is obviously alway a need for connectivity between the authentication mechanism and the control of the portal, no matter whether that’s a card reader and a lock or if it’s a software token and a bunch of data. Each of these components needs to be connected securely and reliably to the others, and each component requires its own resources - most often, this resource is power or electrical signals when we're talking about physical access.
Despite all the developments and advancements in technologies that do not require wired connectivity, it is difficult to imagine a simpler, more dependable and generally cost effective way of making that connection than some physical link that kinda looks like a piece of wire.
That bridge controller on the Death Star still needed to trigger the bridge to extend. I think that trigger was probably sent along a piece of wire. Whether it was electrically conductive, optically transmissive or organically chemical in nature, there were dangly things connecting the bits together.
The centralised management of credentials and users also needs a medium through which the information can be disseminated out to the edge in a timely manner at the same time that incidents at the edge report back status information to the core. Those commoditized wireless networking solutions so often relied upon by the IoT and everything else definitely give us more options, but these systems need to be resilient enough to keep on working even when they’re under attack from Rebel Forces.
It’s going to be some time before a piece of cable - whether it’s made of copper or glass or plasma transfer synapses - becomes less reliable or less cost effective than any form of wire-free alternative, and while there may be ways to get a permanent low-latency connection from the edge to our central database, it would be risky to believe that link might be totally dependable, and so it’s hard to see a situation where retaining a local copy of the database would not be convenient…which means we’re going to need a door controller…in a box…screwed to the wall.
For people who didn’t notice, those smartlock devices that have become so popular in domestic nerd-ville are just a lock, a reader and a door controller all in one box that manages to survive on battery power even with their Bluetooth or WiFi connection chattering away. There’s nothing any different in that world, and that’s why they cost what they cost.
Even under the Galactic Empire of Palpatine, I bet there would still be a Quantity Surveyor or a Project Controls professional keeping an eye on the budgets as they built (and re-built) the Death Star. The job of balancing cost, efficiency and real-terms reliability will not go away as a driver for the selection of systems and technologies in construction, even out in the vacuum of space.
Personally, I do think that setting role-based permissions and assigning them to users is already being really well achieved by a bunch of Identity & Access Management systems from the ICT world, and as a result I would expect (and actually hope) that more AD based systems will come to dominate the EACS world over the traditional, closed, dinosaur-shaped platforms that we still see being perpetuated by short sighted clients and consultants every day of the week, but that is not going to remove the need for a lock, a reader, a power supply and a bunch of logic.
Long Live The Door Controller
However, despite my personal desires, the area in which EACS continues to drag its feet - willfully and willingly, in my opinion - is in the area of real IAM integration.
IAM does not equal AD.
It’s a simple matter to connect most Enterprise Class platforms to a HR solution and seed identities from one to the other, along with role information and privileges, but many organisations have more complex structures of people than exist in the staff phone directory.
Visitors never even come near your HR system, and because people with deskless roles (cleaning staff, drivers, maintenance personnel etc) have no email address, they also have no presence in AD. This means that if you think you're getting the IAM job done by Integrating with AD you're actually missing a whole bunch of the people with some of the most risk-laden roles in your organization.
Contractors might exist in the ERP system because they need to get paid, and as a result of that it would often be very handy to have some integration with site occupancy information to feed into a Time & Attendance solution, but once again, they’re not in the HR system and the EACS in the typical commercial office application has rarely been designed to accommodate highly accurate occupancy measurement.
Despite all the ways we've learned to ignore tailgating and coerce some of the more compliant cohorts of our team into compliance, it remains, like an unauthorized elephant in every room without a turnstile.
Where payroll is the only thing impacted by our inability to do accurate occupancy monitoring we can probably load the dice in our favor so that we never give employees the benefit of the doubt. They'll learn how to comply pretty quickly - probably just after they see their next pay cheque…
But in life-safety applications we need to do better. Perhaps if we were running a petrochemical site and needed to guarantee evacuation in the event of a H2S leak, we'd probably have no problem justifying full height turnstiles and a security fence, but those are not the conditions most people work under. For most of us we live with the hazard of fire in buildings, or perhaps the impact of major weather events that might demand rapid, thorough and well organized evacuation of the space.
Typical access control implementations don't actually help a whole lot - despite things like muster reporting features because of all those elephants hanging around the coffee machines. Anti-pass-back - one of the simplest but most useful security features of your access control system - also isn't much use when your boundaries leak.
The industry's response to the problem has been to keep on demanding fancy (costly) speedlanes and turnstiles, but we all know that clients hate them, and while they're often justifiable for their value as a physical barrier with built in anti tailgating features, that doesn't mean they're what everyone needs. But what else is there?
Good question. There are many pieces of contextual information that could be interpreted along with access control and surveillance information to provide clues to the likely presence of individual identities in an area if we were only able to pull them all into the same domain.
I've been just as guilty as everyone else at times in the past in regurgitating the same old accepted wisdom that the best way to get a verified record of presence was to advocate speedlanes, but I'm not at all certain that I still believe that as a fact.
Although a recent card activity somewhere in the building could be a clue, it's not nearly as useful or granular in most offices as your live connectivity to a wired or wireless network access points will be, not just once but actually from the three or more devices you're likely to be associated with.
Persistent facial identification aside, there are plenty of ways to capture and encrypt biometric characteristic from your person at key pinch points as you move through a secure environment and use these to repeatedly authenticate and verify your presence - particularly when you're inside a space within which you've entered into a contract (however transitory), and have therefore passed up a certain amount of the freedom to be identified you might otherwise expect to retain privately if you happened to be wandering through the public domain.
In some ways this is as close to a physical version of Zero-Trust as we’re likely to achieve, although this is the topic of another post planned for the near future here at Securiosity, in which I will also be talking about the opportunities for things like the blockchain in maintaining our assured identity everywhere we need to use it, so subscribe to keep up to date on new posts as they arrive.
There are many ways to know who is in your building and what they are doing. Only a few of these ways exist exclusively within the electronic access control world.
COVID-19 and the evolving remote working arrangements have added even more nuance to the situation, with the daily movements of staff, visitors, contractors and service providers changing completely - partially altering the style of identity credential we’re using to eliminate touch, but also in some cases eliminating physical presence altogether. ICT based solutions for monitoring the presence of remote workers and their engagement have started to be adopted by many, but these do not sit anywhere near - physically or conceptually - the EACS.
The complexity of building and integrating a common platform that will work for regular and irregular staff, visitors and contractors, on-site and off-site workers is too much for most people to want to pop the lid on that can of worms, and their systems integrator will tut-tut and shake heads at such a concept, offering some ludicrous cost quotation and a cobbled-together bespoke solution, likely to fall apart after a couple of Windows updates.
Kicking the problem over the fence into the ICT department won’t even give you a workaround, with most ICT specialists having become so indoctrinated into the ways of uniformity that many of them believe that IAM is simply another way of spelling AD…and as we’ve already discussed, that just leaves you with fragmented data sets from different systems that you cannot connect up.
We've always had to deal with the issue of how closely a credential used to identify an individual is indisputably bound to that individual, although for the most part we've kicked that conundrum down the road by combining factors and adding physical or logical interlocks because that’s relatively cheap to do and doesn’t require the Access Control System to talk to anything else. Despite numerous good efforts at grabbing a place in the limelight, biometrics continue to skulk on the periphery of the physical security world with reader products that are generally more expensive and less reliable than end users are willing to stomach.
As is often the case in security, Joe (or Joanne) Public sees what they have readily available and ‘for-free’ bundled into their mobile phone and cry foul when the security industry tries to do something that doesn’t seem as good but costs more money. We see it with camera technology, facial recognition, analytics, data integration, mapping and GIS… We see it all over the place in the commoditized world of smart telephony, in fact, and now people are cottoning on to the fact that they already have a bunch of biometric authentication capabilities in their pocket, as well as a way to hook these up with location-based OTP functionality via your device’s inherent connectivity, and regardless of how precise or flawless those capabilities might be, they’re a heck of a lot cheaper and more readily accessible than attempting to purchase any of the half-hearted (and often half-arsed) components that the security sector peddles.
Is it entirely fair of me to poke holes in the biometric readers offered by security vendors? To some extent I believe it is. For much of the past twenty or so years we’ve been trying to simultaneously grow-up too many interdependent parts of a sector that has never really got onboard with the idea of cooperation.
There certainly are (and have been) biometric readers of one form or another that have been pretty good at what they do, but that’s a relative thing, and that’s within the specific context of there being no viable alternatives.
We teetered along for a while with some fairly inadequate sensors that we balanced on top of under-resourced or hard to use platforms, made by organisations who hated the idea of relying on anyone else’s infrastructure to build systems. In pre-mobile days we just had no other choice than to use these Frankensteinian monstrosities, if we could afford them.
The fact that we can refer to the entire topic of biometric credentialing with that single, simple expression is highly misleading and completely obscures the fact that there are barely any agreed standards for the interchange of identities or for the levels of confidence the various technologies deliver.
Eyes, fingers, faces and hands are all very different objects, and with so many fiercely defended patents and vociferously held viewpoints among the major players, it is no surprise that the possibility of mixing and matching to fit the preferences of different user types simply has never been an option.
1:1 and 1:n scenarios with varying connectivity capabilities and the misaligned credential handling preferences of different EACS platforms just adds to the problems, where perceived cost and complexity of infrastructure during the ELV design phase can end up driving an end-user down a dead-end towards a solution that is technically achievable and within budget but that simply does not work from an operational or security perspective.
No wonder that the frictionless dreams of so many clients remain abandoned and forgotten on the Quantity Surveyor’s office floor because the infrastructure and integration challenges of the biometric credentialing technology pushed the function off the end of the table…
Today we have sensors that actually work (thanks to developments that were accelerated by the mass market of mobile phones) and we can put enough computing power inside a tiny box with a neat little screen on it to make the user interface reliable (thanks to the…hang on…am I typing the same thing again…?), we have the potential to build quite good biometric readers, but we’ve already got one sitting in our pocket, and able to do a bunch of other things besides (including remote connectivity to another authentication service and NFC based comms to low cost transponder technology). With all of this literally in hand, we can forget about many of the standards issues we might need to worry about in an access control context because specifics of the stored data no longer really matter.
So now that we can build a good biometric reader the question changes to should we build another biometric reader?
The possibility of live One-Time-Credentials-For-All with built in biometric authentication and live connectivity to third-party certification sits in the palm of everyone’s hands, and the public have almost universally adopted it for applications we’d expect them to be much more conservative about - such as accessing their banking and health records - so why shouldn’t/wouldn’t we piggy-back on that, at least a little bit for the significantly less risky and generally more layered authentication needs of getting in and out of the office (or anywhere else, for that matter)?
Sure, there are wrinkles to be worked out, but let’s face it, there are so many barriers in the way of this happening, put in place by the vested interest manufacturers who have so much to lose if we were to entertain this sort of concept that I am not sure how realistic it might be. There are businesses that could be forced to shut up shop if all of the points I’ve raised here came to pass…
Getting all of these diverse but closely-related issues pulled under a single technical umbrella that is easy to deploy and support for any size and style of enterprise is probably one of the most interesting problems that still exists in access control. It’s way more interesting than biometrics…but it needs cooperation and collaboration between vendors to agree on standards and relinquish the stranglehold some of them have on their clients, keeping legacy systems with stone-age functionality alive and forcing Enterprises to make unfortunate decisions around their choice of business tools.
Even with systems that are currently identified as being Enterprise Class I have seen large end-users being forced into antiquated practices such as using :
T&A systems that need manual CSV exports and imports to do anything
Visitor Management Systems that do not provide mobile support and are so clunky to use that the client ends up just making a drawer full of reusable visitor cards
Site entry management using pieces of paper that can be photocopied or passed around to record competency of contractors in high risk spaces because it’s too difficult to integrate the training information from the Training Records
As was described earlier, access control is all the same. Agents with credentials, some logic and a portal of some sort. When there are more complex sets of functions that hang off the logic you need to be sensible and realistic about where you choose to put those functions. Today’s business landscape is not the same as it was a quarter century ago when many of these EACS platforms were originally designed.
Business owners see exciting functionality being served up oven-ready from cloud-based providers today, agile and responsive, with timely features that respond rapidly and readily to the whims of the market. That is not a description that you could apply to any of the major EACS vendors in the market right now, even though migrating the core functionality of EACS into the cloud is probably one of the more obvious and reasonably justifiable moves for security managers (as long as it’s done right).
The justification for having yet another database running on premises has mostly evaporated since the days of the proprietary access control solution as an isolated system for managing the opening and closing of doors with barely any value-added business functionality. It made a little bit of sense back then - bolting on ancillary functions that were also associated with people and doors - but those days are gone. All that is keeping people using these aging platforms today is a version of FOMO (Fear Of Moving On), where the cost and disruption of replacing the mechanism that lets people into the office to do their jobs is just something that many people do not want to stomach.
That - and very little else - has kept all of these old platforms in business for the last decade and more.
Sure, there are a handful of companies who have wandered up the stairs into the clouds over the same period - not least our friends at Cisco - but for those small few, the opportunities remain primarily in greenfield micro-enterprises where there’s no legacy to overcome and the company accountant is not breathing down your neck pointing at past investments in physical hardware, or sweating about the need to recall and re-issue a few thousand employee ID badges.
That’s a tricky thing to fix.
Door controllers themselves are also not very interesting. A bunch of I/O, some memory and a power supply that you can hook up to a network. How much space is there in the market for commodity OEM door controllers? If you take away manufacturer-specific door controllers in the same way that the industry gave up on most manufacturer-specific readers for a handful of commodity brands, there really isn’t much else left for the vendors to sell. Buy the core platform once then maybe a few dollars for an SLA…gulp…where did all the revenue go?
HID, Mercury and Axis aside, we’re unlikely to see anyone else dive into the commodity door controller market unless it’s somebody like HIK or similar (who already make their own bespoke version), pumping out something ultra-cheap that half of the developed world is going to refuse to buy for one reason or another.
If that remains the same and nobody invents some other method of transmitting lock power and database updates via the medium of thought, it will still be possible for Star Wars heroes to blast the reader on the bridge controls, and it’s still going to be possible for synchronisation issues between the core and edge databases to let the wrong people in or keep the wrong people out.
Same old same old access control boringness…
And somewhere. maybe in a galaxy far, far away, some poor person is going to keep on designing and re-designing the same products, over and over, and over…
Being the Securiositizer is a lonely job, and there’s so much in this nonsense industry to expose and complain about. If you’re excited or frustrated or fascinated by the things that go on then why not get involved.
For a start, subscribe to Securiosity and keep up to date with what we’re ranting about.
Tell us what’s on your mind or drop me a line with some contributions.
Put the word out to the world and let’s broaden the word to all of the Securious.