When I began in the security industry - well over a quarter century ago - I spent my days designing product instead of trying to explain to end-users why they were buying the wrong ones. Integration for me back then meant writing device drivers. At least once a month, the sales team in my company would sell some feature that we didn’t actually support, and then it would arrive on my desk to try to make our system talk to somebody else’s product, often across a flakey RS-232 interface.
Our code was all written in assembly language, but having done this dozens of times for all sorts of kit, I had a decent library of routines that I could use to chat with other gear, and I became adept at crafting a million and one variations on the link level protocol in order to get around the fact that nothing was standard and everything was bespoke.
Invariably I would be faced with somebody else’s technical manual in the first instance with a generally incomplete or inaccurate definition of the protocol for me to try decypher. There weren’t many people using TCP/IP back then, or even UTP cable to plug things together, so everything was made up as we went along. Was the other device a DTE or a DCE? Did you need a null modem connection? Did the other product use CTS/RTS? Was the interface even real RS-232 or was it just a TTL level thing?
The number of times I gave up after a dozen phone calls to an equally bemused member of the other company’s tech support team before packing up their product for repair, my only assumption for why I couldn’t get the interface to work being that I’d somehow blown the damned box up… Dedicated Micros were not the only culprit, but I recall on more than one occasion returning product to them in particular only to receive it back a week later with a no fault found sticker and a new version of firmware mysteriously installed that miraculously made my code work…
Those were the interesting days of systems integration.
Today we have a whole bunch of industry standards and we’ve all settled on the idea of doing everything over IP, so you just plug your boxes into a switch, set the IP addresses, and interfacing just ought to happen, right?
For quite a long time - during the period immediately after most products shifted from the old proprietary interfaces to IP - systems integration just stopped. People had protectionist views about their portion of the market and wanted to own everything. There were no APIs in the public domain and everyone was paranoid about opening up to the ‘competition’, fearing that some other company could come in and steal your business.
We moved to a world devoid of real information passing between systems, replaced by nothing more sophisticated than binary status indications toggling on and off.
For some of us - those who lived through it at the coal-face of product manufacture in the UK and Europe in the early 90s - this stagnation of the integration world was also caused by the introduction of the Electromagnetic Compatibility (EMC) Directive and CE marking. In the years prior to the emergence of harmonized standards for security products, we were too afraid to alter any of our code once we’d jumped through the certification hoops in case we lost the CE mark and were deemed illegal under the laws of the time. You could actually be prosecuted for non compliance if you weren't careful.
Thankfully those days are long behind us, but in my opinion the integration space in security has never recovered the loss of talent and experience from the days prior to that period.
So many vendors now have products that claim impressive capabilities, but most end-users are denied access to them because the typical security systems integrator (we’ve somehow retained this as a collective noun even though it no longer accurately describes the majority of organisations, which are in fact security installers) has no in house ability to jump through the appropriate API hoops that would make these features work.
It's worth mentioning that the scarcity of real technical wherewithal in so much of the security community has also left people open to being led down the garden path by vendors. Not to say that all vendors are knowingly and willingly selling snake oil, but unless they're some sort of nonprofit (and none of them are) they have a specific agenda that will always be first and foremost about creating and maintaining demand for the things that they sell. Even if their aim is to make things that do good, and they invest R&D effort into understanding what their market needs, they still need to pay for that effort, and they can only do that by selling the results, over and over again.
If the middleware in the equation (otherwise known as the Security Industry) was actively challenging what the vendor community was up to then I wouldn't have any problem with this, but that's not what’s happening. Instead, we have manufacturers who are Pied-Pipering end users into an alternate reality of hopes and dreams by dangling sexy-sounding concepts from neighboring industries (Open Platform, Deep Learning, AI…) that fix the market’s expectation but make very little difference to the circumstances of risk on the ground.
The Industry has also become such that integrators are afraid to take innovative risks on their projects because they’re scrabbling along on such tiny margins and in such a contractually toxic environment that if they get too adventurous with their efforts it’s likely to come back and bite them on the butt. Multiple systems from different vendors with different upgrade cycles expose you to more risk than the terms of your SLA will allow you to take.
The contracting model of the construction sector is not a motivator for integration or for collaboration between vendors in different disciplines. It might be what some end-users aspire to, and sometimes you will see the more educated of them spending fortunes pulling the strands of disparity back together again in the years after they’ve taken over the buildings they occupy, having missed the opportunity to get what they really wanted at build stage by a rigidly inflexible design process that left them at the mercy of the market norms.
However, for many, they just assume that the disjointed hotch-potch of standalone nonsense they’ve been given is as good as it gets, and never even think of setting foot on the yellow-brick-road of integration.
There might be instances when the absence of technical integration is seen by clever and inventive security teams as an opportunity to find less digital workarounds.
I can imagine a control room full of people, where a CCTV operator spots an anomalous situation in a live feed and takes a screen grab, prints it out on a piece of paper and fridge-magnets it to the notice board for all of the other operators to see. They could talk about it at their rest break and decide how to handle it, maybe sending a memo to the team and 'emailing’ copies of the weird situation to other control rooms or neighbouring facilities so that everyone could share and learn the knowledge.
That’s operational integration. It might happen when the organisation has established a culture of…of what? It could hardly be described simply as a culture of security.
To get people proactively working together like this requires more than just a security mindset, it requires a shared sense of ownership and accountability that is extremely rare where you’re employing security personnel at the lowest cost possible with no vision of what might become a respectable career for those people.
In other areas of business, the concept of the integrated platform is obvious and expected. Office365, Sharepoint, Loop… Tools for integrating software in the business environment are ten a penny, generally ubiquitous and pretty easy to use.
There is no analogue for this in the security world. Sure, you can call your vendor and they’ll attempt to sell you a license for a feature that looks like it was developed in 1973, but it’s virtually impossible to truly mix and match operational management tools into anything coherent that makes sense for a modern business without spending a fortune and getting yourself locked in.
User centric design means making things work in the way that the users work - not hoping that users are going to get educated or that some platform vendor will make your feature available via an obscure plugin that nobody is going to implement (because they’re not getting paid to do that, and will not risk bringing the system down in case it screws up their SLA KPI - in which case they definitely will not get paid…).
The Systems Integrators of old did not go the way of the dinosaur - wiped from the planet in one fell swoop by a cataclysmic event that arrived out of the blue to snuff out their otherwise stable existence.
They went instead the way of the Orange Spotted File Fish, their natural habitat slowly eroded then obliterated by the actions of a species too fixated on its own tunnel-visioned goals to see what it was doing to the valuable things around it.
Integration in security is not just about plugging a few pieces of technology together and hoping they will be compatible, although technical interoperability and the intelligent sharing of data across domains is certainly a thing of value when viewed from the holistic context of Organisational Risk.
But we put security out for tender like it’s toilet paper.
The jumble of jargon and regurgitated references to manufacturer’s meaningless data we see so often in the RFPs produced by consultants and systems specifiers are never going to result in spontaneous blossoming of a multidisciplinary Organisational Risk Management Team, not unless the end-user has an extraordinarily laser-focused vision and a deep set of pockets.
We talk people, process, technology, but ignore two of them when we design our buildings and refuse to spend any more than the bare minimum on the third.
There are some organisations that have a holistic approach to their security and that take integration seriously - both at a technical and at an operational level - and even some that fold these requirements into their information security strategy too, but they’re few and very far between, and even those who know what they’re doing barely have any influence on the construction industry and how it works.
It remains sickening to see the amount of waste that goes into a typical build as a result of the crazy way in which security is designed. Particularly given that the wasted money that’s spent doing the job badly could go to such better use paying for a competent solution provider to do the job right in the first place.
But those are as rare as the Orange Spotted File Fish.
Subscribe to Securiosity to get updates direct into your inbox every Friday, and keep up to date with the conversation on Deconstructing the Security Industry, managing cities in the chaos of the future, and the Real and Imaginary Threats of Advanced Technologies.
Drop me a line if there are things on your mind and shout at me if you think I’ve got it all wrong.