Search the Community

As many of you know, I spent some time researching the CSL CS2300-R SPTs last year. I found a series of issues that I think are serious problems. CSL have had 17 months to deal with these issues, and after them dawdling, I opted for co-ordinated disclosure of the issues via CERT/CC. CSL have had 45 days to respond to CERT/CC, and only did so on Friday with a statement that is largely spin and distraction. In summary, the issues found: CSL have developed incredibly bad encryption, on a par with techniques state-of-the-art in the time before computers. CSL have not protected against substitution very well CSL can’t fix issues when they are found because they can’t update the firmware There seems to be a big gap between the observed behaviour of the CS2300-R boards and the standards It’s likely that the test house didn’t actually test the encryption or electronic security Even if a device adheres to the standard, it could still be full of holes CSL either lack the skill or drive to develop secure systems, making mistake after mistake I have written a blog post detailing these issues, which also links to the full PDF report. Until CSL can demonstrate that their products are standards compliant and secure, I would advise not using them, especially for higher grades.

　 Bigger = Better? Many barriers currently exist for businesses which are planning to run their own Alarm Receiving Centre (ARC). In the coming months we could potentially see some of those barriers crumble and a whole new way of doing business materialise. 　 　 Winners & Losers Traditionally setting up an ARC from scratch has been an expensive and time consuming process, which can rely upon expertise in the field to implement and is surrounded by very little shared information or open resources (ARCs for Dummies is not out yet). Existing ARCs face to lose out if more competition enters the fray and yet at the same time suppliers could benefit if more new business is generated. 　 Barriers So what exactly are the barriers to setting up a modern ARC? Building / Structure Buildings and structures must comply with specific requirements of the standards Equipment / Hardware In some cases specialist equipment may be required Communication Networks From voice communications to PSTN to IP via fibre links and all flavours in between AE Platforms Software packages used to monitor remote system Licensing / Accreditation Strict standards must be met in order to escalate calls to authorities Employees Skilled and capable staff are needed (You can automate some of this process but not all - yet Processes & Procedures You can have all of the above but without the correct procedures they will fall over Investment A large amount of money must be spent before you can earn a penny back If you think of any others please add them in a reply... 　 　 What's so 'Super' about that?... These and I am sure other points which I have likely overlooked, all make that first step of implementing an ARC a tough proposal. Given an ever improving core broadband network, with rapidly reducing prices and a growth in 4G wireless IP communication, can we now consider another approach though? ARCs usually build in a certain amount of spare capacity at any given time; this is good practice and is recommended at all times. Could some of this spare capacity be utilised to allow an ARC to operate as a 'Super ARC' by receiving and processing signals on behalf of a client ARC and relaying these processed alarms and signals back to them for handling? Why even go to another ARC? Could suppliers of alarm handling software packages not offer their own hosted 'Super ARC' platform? Maybe signalling providers could operate their own Super ARC to encourage more startups or extend reach? Why would a user choose to go to an ARC outsourcing to a Super ARC? Well, maybe they prefer the personal service offered by the smaller ARC but want the assurance of the capacity of the larger ARC. This could give rise to a stepping stone approach to bringing an ARC online, streamlining costs whilst allowing processes and procedures to be ironed out. The current standards would not lend to such a proposal, however the incoming standards allow a much less restricted approach and this type of centralised cloud based processing of signals is going to become a reality in many industries. Current latency and bandwidth restrictions will simply not exist in the same way in future. 　 Questions, questions... As usual we can end up with more questions than answers so I would like to ask you all to consider the following: 1. What problems would you foresee with such an approach? 2. Would you use an ARC which outsourced it's platform in this way? 3. Would you want to host services on behalf of a.n.other ARC? 4. What pros and cons do you see with this type of solution? 5. Is more ARCs a good thing or a bad thing? As always, please feel free to discuss, debate or disagree...

The technology used to transmit alarm and UDL data from premises to ARC and installer is becoming ever more powerful. In this series of blog's we aim to provide you with unbiased information on subjects such as SIA transmission (this edition), standards and how the advance of communications technology will continue to benefit all stakeholders in security. In our business we love technology, but you won't hear from us "you can't do this" or "you shouldn't use x technology". There are horses for courses and it's essential for end users and installers to use the appropriate solution dependent on premises, risk etc. In this first edition we'll look at SIA alarm transmission. You can watch the video .Naturally, the security sector focuses on systems which detect risk local to a given premises, making effective use of intruder, fire, CCTV and access control solutions for the host organisation. Alarm transmission services help manage those risks ‘remotely’, ensuring that event information is sent to an operator who can detect that communication has failed and then summon the relevant emergency services (police, fire) and/or key holder, security installer/systems integrator). That said, transmission networks can also be the bottleneck, sometimes reducing the amount of data that the user would like to send/see. They might also compromise the security of the premises unless appropriate security measures are in place. In this regular monthly blog, we’ll appraise some of the key elements of signalling – and we’re going to begin by examining the prime uses (and benefits) of extended format alarm transmission. Extended format alarms: a quick summary Extended format alarms help those involved to save time and money. You can avoid site visits and interruption to the end user business as well as improve installer services, manage events and faults on a remote basis. There are also improvements to be had in terms of Alarm Receiving Centre (ARC) reports, adding value to the monitored service. The lowest cost transmission is via IP over radio (GPRS) or fixed line (ADSL/Internet). Even Grade 2 systems should use encryption (reference EN table 10, Option D). Why hasn’t the industry used SIA for so long? In the context of this discussion, ‘SIA’ is the Security Industry Association of America and not the Security Industry Authority you all know to be the Regulator for the UK’s private security world. The ‘SIA protocol’ we talk about next was developed to bring together many alarm transmission formats. Its benefits are detailed in due course. Sending every SIA alarm over an analogue telephone call is expensive. A system sending just an ‘Open’, ‘Close’ and ‘Test’ call in 2012 over a working year of 265 days could incur call charges of £100-plus (and certainly isn’t ‘for free’). To reduce costs the security sector turned to inputs/channels as the solution. Inputs relate many detectors to one transmitted event, the unforeseen consequence being the reduction in value of the security system and increased site visits. The event received is not the original event created by the panel, just a translation. As ‘Pins’ are a physical connection from the panel to the communications device, only a limited number of inputs/channels could be transmitted without making the device large in size. Generally speaking, up to 16 channels only will be supported (even for sites which could have dozens of zones or alarm types). Why use extended format alarms? Extended format alarms are not solely for the larger sites. Installers who implement SIA can provide a better level of service to domestic or business sector customers, identifying what has happened before visiting or otherwise eliminating a site visit altogether. We’ve seen the impact of the recession on loss prevention teams. Installers need to manage their bottom line closely as operating costs continue to increase in the recession. For their part, extended format alarms can help end users and installers alike to better manage their situations by providing detailed event information without having to visit a given site. The majority of alarm panels built in the last decade support the SIA protocol alarm format. That protocol includes site ID, date, time, the alarm type, zone, area, entry code and user (if programmed). A simple example is that a Pin 4 alarm for ‘Open’ now becomes ‘Open, J Smith’ or ‘Open, Cleaner’. BA (Burglar Alarm) is now ‘BA, Zone 2, Reception’ etc. By transmitting SIA to the ARC, reports become richer and more useful. Loss prevention professionals or installers now have access to the original data from the panel. This speeds up the understanding of an event, or helps the installer diagnose a fault without having to go to site. Why can the industry use SIA now? Using digital transmission technology, SIA can be sent more cheaply and securely than before. A hybrid alarm transmission systems is a solution which uses a radio IP path (GPRS) as the ‘Primary’ method to transmit alarms, network polls and provide UDL (Upload/Download, ie remote management/service) to the alarm panel. The cost of GPRS bandwidth to transmit every SIA event, UDL and network polling per annum is less than 15% of the cost of sending three alarms per day over PSTN dial-up. A pure digital alarm transmission system will use the IP fixed line path (ADSL) as its primary and radio IP (GPRS) as the back-up.