We all know alarm and event data are valuable commodities, but why? Traditionally the data collected by physical security systems was segregated from the core business and often required bespoke reporting tools to access. The asset, meta, alarm and log data collected by physical security systems can be used to inform not only security management but also other key business areas in such decisions as occupancy monitoring and building utilisation.
Ultimately these reviews and subsequent decisions are only as good as the data they have available. The data within physical security systems should adhere to quality data requirements (data that is secure, structured, consistent, accurate, standardised and most importantly accessible). The data should live within an end user’s core environment and be aligned to core standards to avoid lengthy and costly manipulation before it can be used to future-proof an organisation from potential risks.
Starting with a standard
The naming of physical security (PS) assets within an application is often free text in nature. This presents an opportunity for customisation for the end user but immediately increases risk and decreases value if these assets are named incorrectly, inconsistently, and misaligned with non-approved nomenclature within the end user’s business. Any inconsistency here ultimately feeds through to the information presented as an alarm or event.
To understand the reason behind potential misalignment for PS assets compared to typical IT infrastructure like a network switch, for example, we need to consider the technological development within the industry. This includes how the industry has evolved from using typically offline, analogue systems to the connected, digital systems we see today. The development can be broken up (roughly) into the below three paradigm shifts. With each generation comes increased functionality and exposure.
1st generation – Typical trends include offline, air-gapped, analogue, security by obfuscation and locally managed.
2nd generation – Typical trends include online, siloed, hybrid analogue and digital, security by design and locally managed yet centrally monitored.
3rd generation – Typical trends include online cloud and on-premises software, logically segregated, digital, edge devices, cyber hardened, centrally managed, plugs into the wider ecosystem, increased interaction with the end users’ employees and support teams, and increased governance.
Now that we see the security system is part of the end user’s core IT and business systems, it is imperative the data configured and captured meets the quality data requirements and is aligned with key business and asset registry systems. This allows confidence in the reporting of the asset, meta, alarm and log data collected, and results in the security system being a value enabler, sharing information on day-to-day operations rather than simply being a cost centre.
Reporting and accessibility
If correctly configured and aligned with approved nomenclature, the transactional and alarm data available in a typical enterprise-level security system can provide valuable insights when analysed by the correct suite of applications. Historically, this data was siloed away, unavailable to the core business and used for security investigations only.
In order for the security system to be a value enabler, this data needs to be accessible and subject to the end user’s data privacy regulations. Bespoke and native reporting applications should be replaced with the consumption of transactional and alarm data into a data lake or similar. This allows business intelligence (BI), machine learning (ML), analytics, data science and reports to be conducted on the data, and facilitates trend analysis to detect patterns that would normally go unnoticed with standard reporting. Understanding trends around occupancy monitoring and building utilisation, for example, can only be completed with speed and confidence if the data being analysed meets the quality data requirements.
Analytics engines in combination with security information and event management (SIEM) applications can analyse daily transactions and alarms in context with data from other core business systems and present them as useful dashboards to inform leadership. Analytics engines and SIEM platforms often exist within the end user’s domain. Here we are simply adding an additional data source.
It is worth re-iterating at this point that in order for this to work effectively, the data being ingested needs to meet the quality data requirements. Any analysis, filtering and presentation is only possible by using specific fields or characters within the ingested data. Ultimately, an event or alarm at this stage is simply a string of text.
Maintenance
The capture and standardisation of PS asset data is fundamental to the asset life cycle management. The naming of assets in both the PS system and any digital workflow and enterprise operations platforms should be consistent. This data ideally should be from a single source.
The value here is derived from the end user being able to understand and control their estate. In a typical enterprise deployment, the servers and infrastructure are usually managed by the end user’s core teams. The edge devices (doors, cameras, etc) however, have traditionally been managed by third-party vendors on a local level. Capturing and standardising the data held on edge devices allows mandated maintenance schedules to be driven centrally by the end user’s digital workflow and enterprise operations teams.
This results in efficiency across the enterprise and reduces risk not only from a maintenance perspective but also from a cyber security perspective. The data captured from the edge devices should include manufacturer and firmware version number. Analysis of these and other core metrics is the first step to analysing and mitigating any newly published cyber security vulnerabilities.
Data as a change enabler
Technology changes quickly, meaning the market-leading manufacturer of the day may not be the same from year to year. End user requirements also change, and with this the requirement to migrate from one system to another for commercial reasons will come about.
Understanding the type, size, scale and age of the physical security system, as well as the metrics already discussed, is the first step to planning a migration programme with the least risk. It is only once something is understood that it can be changed.
This article was previously published on Professional Security Magazine.
