Learning from the Hawaii ballistic missile alert

The Hawaii false alarm has sparked a national discussion on emergency management systems and the process for using them. This debate has underscored the critical role that these systems play in keeping the public informed. At the same time, it is leading many organizations to ask:

• Could a false alarm happen to us?
• What precautions should I take?

Before diving into best practices, let’s first look at what went wrong that caused the Hawaii false alarm. On January 13th, a ballistic missile alert announcing an immediate threat was sent out to the residents and tourist populationof Hawaii via both the Wireless Emergency Alert (WEA) and the Emergency Alert System (EAS) networks. What was later announced as a false alarm, the alert was distributed to multiple communication channels, including television, radio, and cellphones in Hawaii. According to officials and multiple reports over the past week, the false missile alert was caused by a combination of human error and system design.

Watch our on-demand webinar on: How to Avoid Sending False Alarms – The recent Hawaii False Alarm incident that occurred over the weekend has caused many emergency and security professionals to question whether or not the same thing could happen to them. To help you understand the risks, we organized a team of experts who hosted a webinar outlining best practices to help you avoid this type of incident. WATCH NOW

The underlying design of the actual emergency management system used makes a big difference in addressing this type of situation and avoiding false alarms like the one in Hawaii. At Everbridge, we have built in a number of safeguards that dramatically lower the risk that a wrong message would be accidentally sent broadly over Wireless Emergency Alert (WEA) or the Emergency Alert System (EAS) networks. These include the following:

• We have very distinct Test and Live mode environments for sending messages via EAS or WEA. The system defaults to Test mode and the sender needs to proactively switch to Live mode to send out a message broadly.
• We provide access controls so that the administrator can establish exactly who has permission to send out a message over WEA or EAS.
• To send out messages via IPAWS channels including WEA and EAS, a user needs to enter IPAWS credentials each time. We do not store any IPAWS credentials in the system. In conjunction with the need to have Everbridge credentials to log in, this provides a two-factor authentication requirement that makes it far less likely that someone without the proper authorizations can get into the system and send out messages.

These three elements combined – distinct Live vs. Test Mode, Access Controls providing authorization, and the requirement to enter specific IPAWS credentials – dramatically reduces the likelihood someone would accidentally send out a Test message to a Live audience. Published stories indicate that several, if not all, of these elements were not in place in the system used in Hawaii. Another area of controversy has been the 38 minutes it took to send out a correcting message announcing that it was a false alarm. Some articles have suggested 25 minutes of the delay was related to securing proper authorizations to send out the new message. In our experience, sometimes lags in authorization are due to lack of clarity on process and sometimes they are due to trouble locating the authorized party. A best practice is to pre-determine how to authorize a corrected message and who must be involved. Our system also includes a scheduling function to know who is on duty, who to escalate to, and how to reach all of the parties. Advanced preparation can help with getting corrected messages out quickly—pre-defined notification templates can enable standard processes to be quickly followed. The Everbridge system also includes a “Follow Up” option which enables customers to Update or Cancel IPAWS-initiated alerts. It’s also important for alert initiators to conduct practice training drills in a test environment on an ongoing basis. Simulating circumstances forcing practitioners to respond both quickly and accurately will better prepare them for live situations and will ensure they know the system well. Everbridge provides an IPAWS on-line training module in the Everbridge University, which is available to all customers. This enables the user of IPAWS to understand all of the concepts and the usage of the system. The course is followed by an Everbridge certification test. Although the Hawaii false alarm was not caused by a hack into the system, the incident has raised this topic as well. The Everbridge platform continues to undergo stringent security reviews by many of the largest and most rigorous companies in the world, as well as by State security teams, which are included among our 3500+ enterprise customers. The Everbridge Suite is FISMA (Federal Information Security Management Act) compliant, meeting over 250 controls mandated by our over 40 Federal agency customers, and we are implementing 75 additional controls to satisfy FedRamp compliance standards. We know our customers have the extraordinarily important responsibility of keeping their constituencies safe and informed, and there is a lot of complexity to reliably and continually accomplishing this objective. A delicate balance must be struck: the underlying systems and processes must have safeguards, the right authorizations, and be secure; at the same time, they also have to be nimble so information and instructions get out quickly. We keep learning from our work with our customers to help us ensure that our software strikes the right balance and incorporates best practices. We are excited to continue this journey together.

Related: Avoiding a repeat of Hawaii’s ‘wrong button’ mistake by Matt Leonard on GCN