(special thanks to my colleague Jess Burn who assisted with this blog)

Faithful readers of my infrequent Forrester blog posts might remember my penchant for using analogies to discuss specific cybersecurity issues. I am pleased to continue that tradition, so I am going to discuss how crashing a bike is relevant to cybersecurity incident response.

During a recent road-bike ride in MetroWest Boston, I crashed — though “crash” is not an accurate description. A better description would be “going over the handlebars at a very slow rate of speed with no injuries or damage to the bike.”

I remounted my bike, whereupon my fitness watch indicated that it had detected a crash incident and was going to alert my emergency contact. Incident detection is an optional feature on today’s connected fitness devices and allows notifications (provided that the device is paired with a smartphone) to be sent upon things occurring such as drastic deceleration. My fitness device then prompted me to answer whether or not I was OK and gave me 30 seconds to cancel the emergency notification alert. This is a nice digital experience, because fitness devices often cannot discern between normal deceleration versus a crash, especially since the popularity of disc brakes on road bikes now allows for more rapid braking (such as at the bottom of a descent or at a stop sign/traffic light) than what traditional rim brakes provide.

I was unaware of this deactivation feature. My sweaty hands with bike gloves then began a frantic attempt to deactivate the notification in a manner that would have made Jack Bauer proud. Unfortunately, the time pressure and my fat sweaty fingers meant that I was unable to deactivate the notification. So far, my experience paralleled a typical cybersecurity incident: detection followed by notification.

This is where my analogy gets more interesting. The notification was sent to my lovely wife, meaning she received a random text stating that an incident was detected and providing a link to the GPS coordinates of the incident. Since we had never discussed this feature, her initial reaction was that it was a spam/phishing attempt (the hyperlink in the text made her especially worried). Plus, since I had not informed my wife that I was going on a ride, she also lacked context to determine the appropriate response. Was I really on a bike ride? This incident was ultimately remediated by her calling me, whereupon I told her to ignore the warning.

While I don’t cover incident response, this experience has several lessons for security and risk professionals on how to manage a cyber incident effectively, such as:

  • The importance of training/education. We tell clients all the time the importance of tabletops and crisis simulations to test processes post-data breach. These critical dry runs ensure proper communication and minimize business disruption when there is an actual breach. In my case, since we had never discussed this watch detection notification feature (nor had I practiced deactivating the notification), there was confusion as to the appropriate response. What if my wife had called 911 in response to the alert? This is no different than receiving alert of possible anomalous network activity only to find that it was normal business activity.
  • Better fidelity in incident response (IR) alerts. My fitness device did a good job at detecting the incident. But the speed at the time of the accident, the location where it occurred, and the fact that I immediately began riding is additional insight that could have helped better triage the incident. While fitness devices will always have to err on the side of caution with alerting, in cybersecurity, there is often additional telemetry available that can be provided with the alert to help assess the possibilities. This doesn’t mean ignoring alerts and just calling them all false positives, but it demonstrates how providing higher-fidelity alerts can deliver more effective responses.
  • The need for context in IR alerts. Today’s enterprises deploy a full spectrum of cybersecurity solutions to protect data and systems. All these solutions generate logs/alerts that can help detect a breach in progress or other anomalous activity. The challenge is that “alert fatigue” is a real thing for today’s security operations center, which means that orgs could invest valuable post-incident time just trying to interpret or investigate the alert’s context, as opposed to initiating the proper breach response. In my case, my device was good at detection, but it did not give enough context for my wife to make an efficient, informed decision. Going forward, I will always communicate my cycling rides to my emergency contacts in advance; this ensures that, if they receive a notification during that time, they have high confidence that it is a legitimate alert. In cybersecurity, IR teams really need to understand the types of alerts that can be generated and be certain that their teams are prepared to identify and classify the high-priority ones to bring about the most efficient response.

If you are interested in discussing incident detection and response, the good news is that the Forrester security and risk team has complete coverage. If you are a Forrester client, you can reach out to the following analysts. If you want to discuss cycling or connected devices, you can reach out to me!

  • Endpoint prevention — Paddy Harrington
  • Detection and response — Allie Mellen
  • Managed detection and response — Jeff Pollard
  • Incident response services — Jess Burn