July 2024 Archives

The cyber incident on Friday July 19, 2024 was caused by a code error in an update pushed to Windows machines by CrowdStrike. This was not a malicious attack. CrowdStrike Falcon, the specific product impacted, is a cloud-based product with a small local footprint, designed to detect breaches.

CrowdStrike Falcon is a cloud-based protection product. CrowdStrike describes the product this way: "Falcon is the CrowdStrike platform purpose-built to stop breaches via a unified set of cloud-delivered technologies that prevent all types of attacks — including malware and much more."

A small file, termed a sensor, is installed on the computer. This sensor monitors for viruses, malware, zero-day (emerging), and other types of threats. The sensor communicates with CrowdStrike through the cloud, and if a breach is detected, CrowdStrike can then respond. By keeping the bulk of the service in the cloud, the protected computer isn't bogged down with a resource-heavy software package. The sensor file is only about 5 MB.

CrowdStrike recommends that their Falcon customers use an N-2 update cadence, or at least N-1. This means the sensor file software runs either one update (N-1) or two updates (N-2) behind the current version. Ideally, this allows any issue with an update to be found and resolved before it ever reaches a client computer.

The update that caused the Windows Blue Screen of Death (BSOD) and boot-looping issue last Friday wasn't controlled by the N-1 or N-2 policy that is set up on most systems. The update was to the signature files, which help the Falcon Sensor determine what is a threat, and they need to be updated as quickly as possible. For this reason, they aren't covered by the usual update cadence.

The U.S., Canada, the UK, Europe, and Asia experienced disruptions to various services during the outage. While Mac and Linux computers remained unaffected, over 4,000 flights worldwide were canceled. The financial and healthcare sectors were severely impacted, with many elective medical procedures postponed. Numerous payment systems were also unavailable in the early hours of the incident.

There's much more information about this available online if you want to find it. CrowdStrike has been very transparent in dealing with this issue. But what we're discussing is why this issue manifested the communication troubles some of you saw last week. For that, we'll talk about how alarm communicators are supervised.

Generally speaking, when an alarm system has a signal to report, it does so using whatever channel or channels are available to it. This could be through a POTS phone line, a WIFI or Ethernet connection, an LTE or LTEM Cellular connection, or some combination of these paths. The important thing to know is that when an alarm panel sends a signal, it looks for an acknowledgment that the signal was received successfully. If it doesn't receive that acknowledgment, it will send the signal again (and again) until eventually it either reaches the destination, the retransmission limit, or the time limit, depending on the path used.

At the other end of this communication is the Alarm.com or AlarmNet server. This system receives those signals and processes them. This may include forwarding the information to a central station, to an online platform for logging and distribution to the end-user, or both.

Since the system may never have an alarm, there are measures in place to send periodic test messages from the alarm system communicator to the server. This ensures that all aspects of any communication pathways are open and working. This usually involves setting a communication test interval. For cellular communication in particular, it's desirable to minimize unnecessary signals, so this is customarily a "smart" test.

For example, you may set a system for a daily or 24-hour test. This is a setting at both the alarm panel and the signal processing server. That means every 24 hours, the system will send a test message to the server to verify communication. If no test message is received, the server generates a central station message that the system failed to properly test.

With a "smart" test, any signal sent by the system resets the test timer. So, the only time the server will receive an actual test message is if the system hasn't sent any other type of signal for 24 hours. In either case, based on this example, if the signal processing server goes 24 hours without receiving either a regular signal or a test signal, a trouble condition is generated.

From here, we can only assume that the signal processing server or servers were impacted by the CrowdStrike Falcon update. We can safely assume this because Verizon and AT&T LTE cellular communications were not affected by this issue. The way I see it, this incident was a blessing in disguise.

Though this probably seems like a catastrophic event, it's actually an opportunity. Because this was not a malicious attack, the least possible harm has come from it. Those with robust disaster recovery plans got a real-world chance to put them to use. Those without robust disaster recovery plans now know what's at stake and can plan accordingly. Catalysts for change and improvement are rarely painless, and this is no exception.

It was only supposed to be a simple software update! These words are I'm guessing, being echoed by the cybersecurity giant, CrowdStrike. Over night CrowdStrike pushed out a misconfigured/corrupted update to its customers. This has caused major issues to banks, airports, TV stations, health care organizations, hotels, and you guessed it, the alarm industry.

Early this morning, Alarm Grid became aware of multiple issues concerning alarm systems. Resideo reported issues July 19 at 3:57am EST. They reported All Pro Series and LTEM-P devices failing on all services. Also, TC2 Application notifications and event processing were delayed. They have reported that most systems are already back online.

Alarm.com reported issues July 19 at 1am EST. The reported issues were affecting access to the Partner Portal, Mobile Tech, the customer website, and the customer app, and may cause delayed execution of commands and signals sent to and from customer systems.

CrowdStrike has reported that the fix has been implemented, but that it could take time to get things back up and running. Both AlarmNet and Alarm.com services are reporting improvements.

Please continue to check back here for updates.

UPDATE: As of 10am EST, Alarm.com has reported that all of their services are fully restored.

UPDATE: 3:30p EST. Resideo has reported that most of the systems are back online. And that alarm delivery services are not impacted. Although we saw their service return much earlier than this update.

Thanks for your patience. If you continue to have issues with Alarm.com or Resideo's services, you can email us here.

Rogers has set a date of March 31, 2025 for its 2G/3G network sunset. If you are a Canadian customer with a Rogers 2G/3G communicator, your system will cease to communicate via cellular upon shutdown. At best, you will see a trouble condition. At worst, communication will be cease completely.

Rogers is a large cellular provider in Canada. When AT&T and Verizon announced their respective 2G/3G network sunsets a few years back, Rogers made the decision to keep the portion of their network that is used by alarm communicators active. In the intervening years, it has been working to beef up its infrastructure. The time has now come to sunset the remainder of the older network.

If you have an alarm system with a Rogers cellular communicator you should begin planning an upgrade. This may require that you upgrade your whole system, or just your cellular communicator. Whichever the case, now is the time to begin planning. If your system uses cellular as its only means of communication, and you have one of these Rogers 2G/3G communicators, your system will be left unable to communicate once the shutdown takes place. In addition, you will see a trouble condition displayed on your system that you will be unable to clear.

If you have a dual-path system with a Rogers 2G/3G cellular communicator, then your system will still be able to communicate after the shutdown, but you will have a trouble condition on the system that won't clear until you either disable cellular communication, or correct the problem. In this case, correcting the problem means replacing the cellular communicator. Depending on your alarm panel, this may or may not be possible without replacing the entire panel.

Alarm.com customers who are affected by this sunset will soon begin seeing prompts telling them to upgrade. Starting in October, Alarm.com customers who still have a 2G/3G Rogers cellular communicator will see a trouble message when they log into the customer app or website. The message will instruct them to upgrade their communicator soon in order to avoid a service interruption.

This news may seem dire, but don't worry, Alarm Grid is here to help you through the transition. In future posts, we'll be providing additional information, including special promotional pricing to help you upgrade in the least painful way possible. We'll also be here with plenty of information on how best to upgrade. In the meantime, if you have questions you can send us an email to support@alarmgrid.com.

This year with the holiday falling on Thursday, Alarm Grid will be closed on both Thursday July 4th and Friday July 5th. This break allows our team members to rest and spend time with their families. We'll be back refreshed on Monday, July 8th ready to help you protect your home or business!

For existing Alarm Grid customers, this means that technical support and account activation will be unavailable during the holiday. However, our central station partners are available around the clock to process any alarm signals. If you need to cancel an alarm or put your system on test, you will do those things as you normally would.

If you reside in the US and need to contact the central monitoring station to cancel an accidental alarm, verify a signal, or put your system on test you can contact Criticom Monitoring Services (CMS) by dialing (888) 818-7728 and choosing Option [9].

Canadian customers with the same central station needs can contact Rapid Response at (800) 932-3822. Remember, any time you call either monitoring station, you will be asked for your name, address, and your false alarm password. Providing incorrect information when asked will result in the dispatch of authorities.

If you need to make changes to your account or you have technical support questions monitoring station operators can't help you with those inquiries. Instead, email us at support@alarmgrid.com. Provide as many details as possible about the request or issue. Remember, if you're requesting account changes we'll need your false alarm password or the last four (4) digits of the credit card number we have on file for billing before we can make those changes. Providing this in your initial request will make the process go more quickly.

With hot, dry conditions in some areas, be cautious when using fireworks. Ensure you have proper extinguishing methods available in the event of a fire. Most large scale fireworks displays take place over a large body of water so that accidental fires are avoided.

Also remember that fireworks are likely to scare both pets and wild animals. Many young animals get separated from their mothers at this time of year. If you encounter a seemingly abandoned wild animal baby, contact your local wildlife rescue and follow their recommendations. The Humane Society has a listing of wildlife rehabbers by state.

We hope everyone enjoys a chance to relax this holiday weekend. However, we recognize many will be working. A big thank you to central station operators, wait staff, hospital staff, police, fire, EMS personnel, and anyone else working this holiday. We appreciate your dedication!

Alarm.com now offers a new burglary deterrence feature available from some of its cameras. Alarm Triggered Warning Sounds, once configured, will cause selected cameras to emit a siren when an alarm is triggered. This feature can be activated based on sensors, partitions, or the entire panel.

One crucial note about this feature is that it is only compatible with non-doorbell Alarm.com cameras that support the two-way audio feature. A full list of compatible cameras, with links, is available in our FAQ that walks you through setting up this new deterrence feature.

The requirements for this feature are fairly simple:

• A security service package with Panel/InApp panics enabled by your alarm dealer.
• A video service package with the Audio for Non-doorbell Cameras add-on enabled by your alarm dealer.
• At least one camera compatible with the MTWS feature.
• An IQ4 Panel (IQ Panel 4, IQ4 Hub, or IQ4 NS). You can't do this with a video-only account.

See? Easy peasy! If you have an Alarm.com camera that supports two-way audio, and it's not a doorbell camera, then it likely supports this feature. On general principle, be sure your camera is updated to the latest firmware. For most cameras, the minimum firmware to support this feature is Firmware Version 0.6.7.852+. The exception is the ADC-V515, which requires Firmware Version 0.0.5.476+.

This feature is easy to set up. Just use the Smart Rules Builder through either the customer website or the Alarm.com app available from Google or Apple. Once you log into your account it takes about two minutes to create the rule needed to utilize this feature.

The Alarm Triggered Warning Sounds (ATWS) feature works hand-in-hand with the Manually Triggered Warning Sounds (MTWS) feature. If you have any MTWS capable cameras, then you know you will be able to configure the ATWS feature and vice versa. Manually Triggered Warning Sounds are not automated. Instead, a user must manually trigger the sound while logged into either the app or the website. You can check out how to use MTWS here.

When you manually trigger a warning sound from one or more cameras, the sound duration is 30 seconds, unless you manually turn the warning sound off sooner. When the warning sound is alarm triggered, the duration is five (5) minutes, or until the alarm is canceled by a user disarming the system where the alarm occurred.

Scenario 1: Manual Trigger

You're away from your home or business. You receive an alert that motion has been detected by one of your cameras. You log into the app and, pulling up the live view for your camera see a person or animal in an area of your property where they don't belong. While you're viewing the live video, and assuming this is a compatible camera, you can choose to trigger a warning sound that will hopefully scare the person or animal away. In this scenario the Manually Triggered Warning Sound can be used to great effect.

Scenario 2: Alarm Trigger

You're at home, and your system is armed in the Home mode. While you're asleep an intruder attempts to enter your home by breaking a first floor window. They may have triggered an alert from one of your outdoor cameras, but you slept through it. The window they're attempting to enter through has a glass break detector associated with it and this detector is active when the system is armed in Home mode. The intruder breaks the window, but the alarm goes off. This causes not only the alarm panel, but also your outdoor cameras to begin sounding a siren. The would-be intruder hears the sirens and leaves, preventing an actual break in.

One limitation of all-in-one panels is that they aren't high-current siren friendly. That's not to say that you can't add one of these sirens, but it takes some work and it can get expensive. Not to mention, where do you put the equipment for it? By allowing the cameras that offer siren sounds to use those sirens in an alarm situation you're adding extra sirens to the system at no additional cost, assuming you planned to have compatible cameras anyway. In my opinion, this is a great new feature. It's also an example of how Alarm.com continues to add value to their products without requiring additional investment.