Walk into any modern security operations center and you'll see the same scene playing out: operators frantically switching between five, six, sometimes seven different screens, each one demanding attention with its own set of alarms, interfaces, and protocols. It's chaos masquerading as security. So, how did we get here?
Settle in, everyone; here’s the history lesson: Security used to be either manual – think the old “guards, gates, and guns” adage – or passive, a very tired security guard staring at a matrix of dozens of tiny squares of CCTV feeds with bloodshot eyes looking for any indication of trouble with a finger on a radio dispatch button.
Security moved from decades of hardware-driven analog technology with very defined expectations and accountability to where we are now: a matrix of sensors pushing data to a matrix of software, run on a matrix of virtual processors, stored in a matrix of flexible cloud storage solutions – all gathering petabytes of data for everything from basic security events to complex business intelligence, predictive risk assessments, and operational efficiencies.
It’s a virtual world where software is king, and hardware has become, for the most part, commoditized. (I said, for the most part; don’t come at me, hardware guys.)
Once software dominated the security space, there was an explosion of bespoke platforms, each created to alleviate some element of a known vulnerability in the safety of an organization, or to gather information for forensic case building. The manufacturers worked to perfect their offerings within their own platform, with their specific hardware requirements, firmware, timelines for software releases and updates, and their go-to-market strategies. All of this siloed and competitive product development advanced the technology, but what was designed to make a security professional’s job easier just made it more complicated. Luckily, expectations were low at first, and the security world was wowed by the technology’s potential. Interoperability wasn’t on the table yet, and the swivel chair between platforms was just how it was done.
Over time, these changes in technology also created a new type of security professional; they couldn’t simply be low-voltage specialists; they had to be IT savvy as well as understand the needs of security. As the audience adapted to the technology, the demand for it increased. Rules could be written to make access control functionality more specific and more nuanced. And if software could have rules to influence decisions on one platform, why not another?
Integrations between platforms were initially basic. Manual relays, the all-important but basically “dumb” I/O boards used to trigger cameras upon a reader badge swipe, etc. Intercom buttons relaying to an interface that could create an access control event, and so on. Integrations that didn’t require much collaboration across platforms were the quick and easy way to create an “integrated’ security solution. But the new security/IT/electrician/integrator professional demanded more. \
The first integrations across platforms that weren’t purely manual and hardware-driven were basic ASCII “integrations.” ASCII essentially relied on software using the same language and custom-written code to allow some sort of interoperability, mostly through triggers like relays, but within the software. This quickly moved into the SDKs and APIs we know today, which allow for the exchange of information and functionality between systems.
Some manufacturers were very open about sharing their SDK/API, but with proper guardrails in place to ensure they didn’t lose business by being too open.
Some manufacturers gate-kept theirs to have control and leverage over how integrations were created and monetized the added functionality they were “allowing” from their platform to work and play well with others.
Enterprising newcomers to the industry saw a gap in the market and created a category called ‘Middleware’, which is a third-party bridge type of integration, sometimes with added customization and specialized features.
Some manufacturers took a different approach, opting not to integrate with platforms that manage other aspects of the security ecosystem. Instead, they adopted a proprietary strategy, either developing or acquiring complementary platforms to create the unified security platforms that are prevalent today.
So, as you can tell by making things “easier,” things got even more complicated and a whole other set of decisions had to be made. Is the right choice an all-in-one unified solution from one manufacturer and hope what they’ve created fits the needs of an increasingly more complex security solution? Or should you choose the “best of breed” for each platform and then figure out how to get these systems to talk to each other via either an API, write an integration via an SDK, or buy middleware that can handle the functionality of integration? There are caveats on all sides.
The big question: Should I compromise customization for simplicity?
So, while the manufacturers, integrator resellers, and decision-makers are embroiled in a tussle over sales, marketing, development, engineering, and licensing, the poor security operator is now back where we started. They are still staring at the wall of video squares, but now with added monitors displaying a grid of access point events, a master station phone with a screen for the intercom system, a badge printer, and a visitor management tablet on their desk, among other items. And they sat through hours of training on these platforms just to be able to use them.
The IT/security budgets get maxed out with attempts at integrations, the professional services needed to make the integrations work, the added servers, storage, power supplies, hardware, specialized sensors, and cameras, etc.
With all this added functionality, integration, customization, and unification, the one thing that nearly the entire industry still hasn’t addressed is: now what?
Our Security Infrastructure is Broken
The average organization runs between five to seven core physical security systems at a time – even with integrations between some solutions, there’s still specialized analytics, risk monitoring, mass notification and intercom systems, visitor management, ID management, parking solutions, and the growing list of IoT sensors and dashboards all providing an endless stream of information clutter.
Granted, data is vital, but when it’s received and how it’s used is sometimes even more important.
When a security operator is in their seat, all this noise needs to at least be triaged. But the security industry has been so focused on building these robust data gathering platforms and specialized sensors that give you all the forensic research fodder you could hope for, that they forgot that in the moment, these tools need to be used to stop a threat as it’s occurring, not just analyse the aftermath. So, once again, now what?
Things get missed.
The result is this: 28% of alerts are simply never addressed, according to the Forrester study. Operators are missing genuine threats buried in the noise. When each system has its own alerting logic and priority levels, everything becomes urgent, which means nothing is truly urgent. Even then, these platforms rarely address what happens after the alert comes in, if it isn’t missed in the first place.
Real-World Consequences
An example of this happening can be found in a retail chain experiencing a coordinated attack from an organized crime ring. The criminals might have studied their target, knowing that there was continuous video recording for the sales floor, while the less active stockroom and loading dock area had active access control, but the video was based solely on motion. Being able to bypass access via social engineering to gain an active credential allowed the theft to occur without being detected until it was too late. Security personnel didn’t have video verification showing a door being held open, and since the thieves had a credential, the access was granted, and the door-held alert was dismissed.
In another example, security personnel may be notified that unauthorized access occurred at one of their perimeter doors, however, they would still be required to manually search through the video surveillance footage to find details on the incident. This manual correlation process can add critical minutes to incident response times, which many organizations can’t afford.
What Actually Works
After being in this industry and watching the evolution described in detail above, I've learned that successful integration isn't about finding the perfect technology or throwing a lot of money to buy all the necessary technology to ensure the bases are covered. It’s about widening the aperture to see the bigger picture. This means looking at the security deployed and prioritizing your efforts to create a solution that operates in this order: plan. mitigate, manage, investigate, and revise. Then start from the beginning again.
Plan systems, protocols, and solutions to best fit the needs of the organization.
Mitigate any potential risks by proactively deterring threats before they can happen.
Manage security by being operationally efficient and handling threats as they occur.
Investigate any incidents that slipped by the security systems and protocols in place.
Revise your solution as needed based on the successes or failures experienced.
This tactic will work, but it will take some time to get all the right pieces in place, and sometimes troubleshooting security can be not only costly but also dangerous. Trial and error can be disastrous, but sometimes necessary.
The platform approach that can help
I know I’ve overused the word platform in this blog already, but it’s not just a buzzword. The most successful organizations have moved beyond trying to force disparate systems to play nice together. Instead, they've adopted security operations management platforms that serve as the central nervous system for all security activities.
The tricky part is that a lot of security manufacturers will label their products as a “unified security operations platform,” but I challenge you to find more than a handful that can actually meet that expectation.
Here’s my qualification to be called an “Operations Platform.” Ready?
It’s answering: now what?
Any platform that doesn’t offer threat resolution, such as dispatch or emergency service notification, without laborious or costly integrations, falls short of qualifying as an Operations Platform.
Associating disparate security systems into one streamlined platform that enables security personnel to unlock the high-level visibility they need to identify, assess, and defend against emerging threats is the Holy Grail. And just like Indiana Jones III, The Last Crusade (the second best Indy movie, yeah, I’ll die on that hill), the most gilded, complex, expensive, shiniest software or device isn’t necessarily the most valuable for the solution.
Companies like HiveWatch have built their entire platform around this reality, creating what we call a GSOC Operating System that consolidates security operations across multiple technologies. HiveWatch can associate video and access control without the need for integrations, giving security operators a multi-faceted view of the threat that can be pushed to dispatched services as well as stored with a complete audit of the actions taken to manage the security event.
Data aggregation and reporting that give you a complete picture of your security incident management efficiency can result in vast response time improvements. A good operations platform typically reduces response times by 50-70%. Ultimately, reducing the busy work of administrative tasks which enables operators to work more efficiently.
Reviewing and reporting from multiple software platforms can provide a lot of information, but it’s not telling you the complete story you need in the sequence needed. A statistic of door events or video captured anomalies can be valuable, but out of context, it might be harder to see the big picture of how a security blind spot is developing. Our brains are good at data correlation to a point, but the time and effort aren’t well spent if it can be done more accurately and faster, allowing man-hours to be used more efficiently elsewhere.
How to find the Holy Grail
If you're reading this and you feel like you might want to take a step back and evaluate your security operations, fantastic!
The good news is that you don't have to rip and replace everything to start seeing improvements. Chances are that you have most of the right pieces in place, but you need to revisit the Revise stage (see above) and make some adjustments to optimize the performance of your systems and protocols.
Go back and review your security “stack,” taking a hard look based on some of the points mentioned above. You might find a feature overlap that you don’t need. You may also find that some integrations are unnecessary when it comes to how your organization operates. Conversely, you may find that there are integrations that you need to invest in. Slow response times, higher operational costs, and dangerous security gaps are indicators of disparate systems that should communicate with one another.
So, what’s next? Evaluate what you have in place. Check in with your team. Review the data you have and identify any gaps in the stages of mitigating, managing, and investigating security incidents.
Then make a plan to make some changes. I'm happy to help.