NextAlarm Fail

[davestr]

I've been a NextAlarm customer for at least 3 years and never had a problem until now.

I keep on getting notices emailed to me that alarms are being reported, but not from my registered phone number. Indeed, no dialing here, as My Elk M1 has nothing in the log or the keypad.
I haven't touched my Elk in months- nothing changed- it's defintely not dialing.

Until now, they seemed to have ignored these, and not dispatched anyone.
Today however, they did a fire dispatch despite it not coming from my number.

I called the number being reported in the email from NextAlarm (#in California I'm in Chicago) and the lady said the same thing is happening to her. She's called the phone #'s reported to her and the
other people says the same thing- they are getting reports too.

They must have their database scrambled or something.

Several Emails to their technical support go unanswered.
I tried to call them and nobody home in customer support on the weekend.

If I was out of town and had another false fire dispatch, it would be a bummer to cancel a trip, or be real worried.

This is driving me nuts and NextAlarm doesn't seem equipped to address this issue!
This does NOT instill confidence in their service.

Anyone else had this happen to them?

 

[Del91574]

I've had similar, however explainable actions happen to an account or two of mine over the years, however it only turned out to be someone else (another dealer) duplicated the account number I had within their new install.

I don't know of any reputable UL listed central station that would not dispatch on an alarm based soley on it not coming from "your number" as all alarms should be treated as valid, especially a fire alarm. It would be negligent at minimum to not dispatch on a fire alarm no matter where it came from.

In these days, with people modifying their phone services as a flavor of the week between POTS, VOIP and cell to landline conversions, basing the dispatch on a CID number is scary.

Sounds like they might have some SOP's out of wack in addition to a large database corruption or failure. Part of UL CS requirements are the specific requirement for redundancy and disaster mitigation, which it doesn't sound exists with your CS.

 

[electron]

Keep us posted please, I did some searching, and couldn't find any reports of people experiencing similar issues. This is a pretty serious issue, hopefully they'll offer an explanation soon.

 

[davestr]

I hear you about the dispatches. Of the several messages I have received, only one resulted in a dispatch. Sounds like several accounts are experiencing the same thing.

Hope to have it resolved pronto. Will follow up.
Thanks for the feedback!

 

[michelkenny]

When I trialled NextAlarm a few months ago I was experiencing the same thing. No dispatching, but I was receiving reports that were not coming from me. Assumed the account number was duplicated, but was also disappointed with NextAlarm so I never went passed the trial.

 

[Sandpiper]

You may want to ask for a new account number.

 

[ddennerline]

This does sound rather serious that someone could accidently fat finger a wrong account number. I hope that NextAlarm uses callerId to cross-check account number if alarm is triggered. NextAlarm only requires a six digit code according to ElkRP. Because there’s no password required or allowed for CID protocol (http://www.google.co...wWBpuc9xKxJTJxA), how does the CO know the communication is trustworthy?

I understand CID protocol was designed before security was critical, but this seems like a major oversight. What's stopping someone in foreign country from using a bank of VoIP numbers and executing an alarm war dialing attack?

Do any of the other non-IP alarm protocols support/require a password (even in the clear)?

 

[Del91574]

This does sound rather serious that someone could accidently fat finger a wrong account number. I hope that NextAlarm uses callerId to cross-check account number if alarm is triggered. NextAlarm only requires a six digit code according to ElkRP. Because there’s no password required or allowed for CID protocol (http://www.google.co...wWBpuc9xKxJTJxA), how does the CO know the communication is trustworthy?
I understand CID protocol was designed before security was critical, but this seems like a major oversight. What's stopping someone in foreign country from using a bank of VoIP numbers and executing an alarm war dialing attack?
Do any of the other non-IP alarm protocols support/require a password (even in the clear)?

I think one is overthinking the academic way alarms function in comparison to how an alarm or security system functions. Honestly, pasword protecting an account is only a minor inconvenience for someone performing a brute force attack. Can it happen, sure, however CS's have redundancies and UL sets standards on incoming lines to a reciever, maximum # of accounts per line card, etc. There's a lot of fine layers before a brute force attack would cause armageddon. Worst case scenario, if a block of accounts goes into alarm, the reciever sums the information to automation software, which would prioritize how the CS and operators act on signals, such as fire and duress before a burglar or supervisory signal. Actually, honestly, IP reporting is subject to the same, if not worse, security holes, as MAC addresses can be spoofed, as location of the connection can also be spoofed or is unreliable if run through a proxy or other, let alone DNS servers.

I've installed IDS and ACS systems for the federal government and military, as well as part of the non-proliferation securtity systems for the DOE, domestic and abroad, and the fact of the matter, is any system that is that mission critical is not monitored using a standard digital communicator and POTS, they're monitored over dry copper, modem on each end, secure SIPRNET, and really critical systems have encryptors installed on both ends, not basic functionality.

 

[wuench]

The worst part of this in my mind as a Next Alarm customer also, is the inability to get in touch with them quickly to resolve the issue. I would insist on a credit if you intend to stay with them after this.

 

[apostolakisl]

This does sound rather serious that someone could accidently fat finger a wrong account number. I hope that NextAlarm uses callerId to cross-check account number if alarm is triggered. NextAlarm only requires a six digit code according to ElkRP. Because there’s no password required or allowed for CID protocol (http://www.google.co...wWBpuc9xKxJTJxA), how does the CO know the communication is trustworthy?

I understand CID protocol was designed before security was critical, but this seems like a major oversight. What's stopping someone in foreign country from using a bank of VoIP numbers and executing an alarm war dialing attack?

Do any of the other non-IP alarm protocols support/require a password (even in the clear)?

Interesting thought. If someone knew you were with a specific CS, they could perform a telephone denial of service attack. They wouldn't need to do anything but setup a bank of voip numbers to repeatedly call, as you mentioned. They wouldn't need to know any account numbers or anything, just keep tieing up the lines until they get busy signals. I don't know how many lines someone like next alarm has, but I bet it isn't that many. Maybe 1 for every couple hundred customers.

I suppose that you could set your system up to call more than one CS as a redundancy.

But frankly, I think it is a huge deal that Next Alarm has swapped account numbers around. Especially if they misread a true panic or fire and don't send the EMS or Fire (or send it to the wrong place). If someone gets robbed, the liability is just the stuff, but fire and EMS is life saving (or getting robbed while you are home).

 

[ddennerline]

IMHO unauthenticated safety/security transactions in today’s crazy world is a real concern. I was a little shocked how insecure CID protocol is – all you need is six digit account number, a phone number, and CID capable modem to wreak havoc.

Even if CO had enough incoming lines to handle flood, the manual verification procedures would be enough to kill service to any legitimate users. It only takes one phone 139 days to cycle through every account number with a five calls/minute rate. In 30 days, I am certain a few account numbers could be guessed.

I am not an alarm protocol expert, but the SIA (not Ademco CID) standard seem to support more fields (http://www.basshome.com/sia-standard-communications-protocol.htm) that could be used for authentication. It appears that account numbers are restricted length decimal only fields.

I would have thought there would be some shared passcode or deviceID required. In looking at NextAlarm account, there’s no provision allowed for entering a deviceID.

 

[Sandpiper]

Wrong account numbers being reported to the central station is a problem that they don't want you to know about. There are major differences in the way some central stations deal with this issue. For example, one national company uses caller-id from the reporting phone call to verify that the calling phone and the account number match up. This same company also requires a test signal (a special signal which means "test only") to be sent from each alarm panel, with the caller-id and account number matching before they will put the account on-line. The chance of having a wrong account number by mistake is greatly diminished with their system. However, not all central stations are so sophisicated.

Here is an example of another company.....I had a block of reserved account numbers used for future customers,,,that no-one was using. However, a daily central station report from them showed that one of the reserved accounts was reporting alarms. I called the central station to ask how this could happen and they told me that it could be anyone sending signals using my reserved account number and they had no way to trace it or find out who is was. A few days later it stopped, so whoever did the fat-fingering must have finally caught their mistake.

I have also had customers report to me that the authorities were dispatched to their house but they had no alarms at all. Caused by a fat-fingered account number......

 

[Del91574]

Interesting thought. If someone knew you were with a specific CS, they could perform a telephone denial of service attack. They wouldn't need to do anything but setup a bank of voip numbers to repeatedly call, as you mentioned. They wouldn't need to know any account numbers or anything, just keep tieing up the lines until they get busy signals. I don't know how many lines someone like next alarm has, but I bet it isn't that many. Maybe 1 for every couple hundred customers.
I suppose that you could set your system up to call more than one CS as a redundancy.
But frankly, I think it is a huge deal that Next Alarm has swapped account numbers around. Especially if they misread a true panic or fire and don't send the EMS or Fire (or send it to the wrong place). If someone gets robbed, the liability is just the stuff, but fire and EMS is life saving (or getting robbed while you are home).

The better CS's, when they're designed and put together, have items to address receiver jams, and honestly, if something like this was attempted, I'd wager they'd cause the Telco's slick site to crash/lock up first. The other thing to think about is being able to "phish" all the lines that come into a CS and know what receivers they go to, format they accept, etc.

Also, for Dennerline, you can dial into any CS receiver and dump any account # and the receiver will provide the handshake and kissoff, with the event going to an event printer. The automation software is what handles and sums the information. If the receiver doesn't get a handshake within X seconds, it'll drop the line. You can send an improper CS ID to any receiver, and if the information isn't correct for the template and automation software, it's garbage, so honestly, it's almost impossible to guess any account number on any line card on a CS receiver.

As Sandpiper alluded to, there are ways to mitigate the effects, however it does happen, with the exception of an item like a cell or similar communicator, which is based of specific information, but there are still errors (alebit less often) on any unit that goes through a 3rd party.